如果您遇到此问题 - 请阅读！希望你会为自己省去很多麻烦。先喝咖啡！
您可能来自传统编程背景，从事与 SOA 无关的领域，现在您正在以“传统程序员”的心态编写 SOA 服务。以下是自构建 SOA 服务以来我学到的 4 个最重要的经验教训。
第 1 条规则
尽量不要编写需要很长时间才能完成的服务。我知道这可能很难完成，但是多次调用较小的操作要比 1 个长服务执行所有工作，然后返回响应要可靠得多。例如最近我写了一个处理所有任务的服务。每个任务都作为 XML 文件存储在 IIS 站点中，每个任务都会将数据导出到系统，例如：SharePoint。在高容量期间的任何给定时间，可能有多达 30 000 个任务等待处理。在过去的 2 个月里，我还没有让它 100% 可靠，这是在深入研究 IIS、AppPools 和 WCF 绑定中的超时设置之后。时不时我会得到 - “线程被中止”，没有任何理由或解释为什么会发生这种情况。我用尽了所有在线知识库，似乎没有人比我更聪明。最终，在无法解决问题甚至无法以可靠的方式重现它们之后，我选择了完全重写。我将代码更改为一次只处理一项任务，而不是处理所有任务。
这实质上意味着调用 1 个 Web 服务 30 000 次，而不是调用一次，但在性能方面，它大致相同。每个呼叫都会快速发出响应，并且工作量要少得多。这还有另一个好处，我可以向客户提供每个操作的即时反馈。在 Long 调用中，您会在结束时立即得到响应。
如果服务调用确实失败了，您还可以更轻松地捕获并重试服务调用，因为您不必为每个操作再次重做整个调用，而只需对失败的操作进行重做。
它也更容易测试，不仅因为实时反馈，还因为您可以测试 1 个内部操作，如果您愿意，无需循环开销。
最后，如果您计划稍后扩展您的应用程序，它会增加更好的扩展性，因为您将事物分解为更易于管理的工作单元。例如：在您有 1 个服务处理所有任务之前，现在您有一个可以处理 1 个任务的 Web 服务，因此，如果您需要处理 10 个任务或选择任务，您可以更轻松地扩展功能。
第 2 条规则
不要仅仅因为您认为它是一种更好的技术而将现有的 ASMX Web 服务升级到 WCF 3。 WCF 3 是过度架构的，使用或部署并不是真正的乐趣。如果您需要使用 WCF，请尽量坚持使用框架的 .net 4 附带的版本，它似乎已经过改造。您会错过的另一件事是 WCF 没有测试表单，因此您不能只是快速启动 Web 浏览器来测试您的服务。如果你像我一样——“保持简单愚蠢”那么 WCF 3.5 会让你感到沮丧。
第 3 条规则
IIS6 可能很狡猾，如果您需要可靠的服务，请尽可能避免在 IIS6 中托管您的服务。我并不是说它不可能在 IIS6 中实现可靠性，但它需要大量的工作和大量的测试。如果您正在处理至关重要的服务，请尽量避免使用 2001 年开发的产品。
第 4 条规则
不要低估创建可靠 SOA 服务所需的开发和测试。老实说，我只能说这是一项艰巨的任务。