适合与不适合的场合，以及需要注意的地方

　　SOA 是一种组织化的方法，用于应用到由面向服务和分布式对象计算组合而成的应用程序体系结构中。让我们来将这个定义分为几部分进行分析。应用程序体系结构 是应用程序各部分的宽泛组织，通常作为层实现。体系结构指定包含哪些部分以及它们如何一起工作。面向服务将功能封装为服务——宽泛的可重用任务，可以在没有任何前一上下文(除承载服务的系统的当前域状态外)的情况下运行。服务的上下文是作为从调用方传递的参数提供的，和函数调用的参数非常相似。分布式对象 以特定方式运行在独立进程中，通过这种方式，一个进程中的对象可以调用另一个进程中的对象上的方法。

　　SOA 向分布式对象添加面向服务，从而可以在进程之间调用服务。它是一种用于设计应用程序体系结构的方法，以便应用程序的各个部分可以在不同的进程中运行，而且还允许不同的应用程序共享和重用正在运行的部分。它是分布式对象计算的演变，用以在多个对立方之间获得更好的平衡:需要访问彼此功能的应用程序;需要封装自己功能的应用程序;需要限制在其应用程序编程接口 (API) 中描述的对外公开的功能的应用程序;需要限制分布式调用的交互应用程序。服务支持访问通过各种任务定义良好的 API 公开的封装良好的功能，从而可以通过低频率的调用实现功能的高重用性。SOA 或许是所有方法中最好的一个。

　　以下给出了一些简单的技巧，用以确定何时采用 SOA 和何时不应采用 SOA 以及需要提高警惕的情况。

　　首先，适合采用 SOA 的情况:

　　﹡　当数据分布程度非常高时，使用 SOA。将操作数据的代码放置在与数据较近的位置，然后将其包装为服务，以供在任何地方进行访问。
　　﹡　希望功能具有高可用性时，使用 SOA。将功能作为服务部署在多个冗余的提供程序中，以在其中一些不可使用时，可以使用其他的对等服务。
　　﹡　当应用程序的各个部分需要独立开发、维护和更新时，使用 SOA。只要保持各个部分之间的接口，每个团队(如两个不同的 B2B 公司)就可以使用其喜爱的技术按照自己的计划实现各自的部分。
　　﹡　当多个应用程序需要重用功能和数据时，使用 SOA。共享的代码仅重用功能;服务则允许各个独立应用程序重用一组共享的企业数据，而无需将数据分发给所有应用程序。

　　以下是不适合使用 SOA 的情况:

　　﹡　当希望开发尽可能简单时，不要使用 SOA。使用一种语言实现，在单个线程中运行，且没有远程访问问题的应用程序复杂性较低一些，因此构建和调试更为方便。
　　﹡　当希望操作环境尽可能简单时，不要使用 SOA。要对松散耦合、事件驱动的分布式应用程序进行故障排除要困难得多，要求对应用程序实现细节和操作环境配置细节及其当前状态有全面的了解。
　　﹡　当网络不可靠或网速慢时，不要使用 SOA。服务组件运行于独立的计算机上，通过网络进行通信，因此，其速度和可靠性依赖于这些计算机及连接这些计算机的网络。
(注:分布式冗余服务可以帮助减少硬件不可靠和网络延迟的影响。)
　　﹡　进行原型设计时，不要使用 SOA。原型开发应该简单，而 SOA 并不简单。

　　对于何时需要提高警惕的问题，坦白地说，随时都要提高警惕才行。以下是一些需要谨慎行事的具体情况:

　　﹡　当服务接口不确定时，使用 SOA 需小心。服务接口允许使用者和提供者独立地进行更改，但接口本身必须稳定。SOA 中的接口变化比在单个应用程序(特别是非分布式应用程序)中复杂得多，因为有很多在其他情况下不相关的开发团队必须就接口的更改进行合作。

　　﹡　当安全性极为重要时，使用 SOA 需小心。每个服务都是一个新的易受攻击的点，必须保证其安全性。可以轻易访问服务的人越多(如在公共 Internet 上的服务)，可以尝试攻击该服务的人就越多。

　　﹡　当性能极为重要时，使用 SOA 需小心。进程之间的每个服务调用都比进程内的方法慢得多。

　　希望功能具有高可用性时，使用 SOA 需小心。正如所指出的，冗余服务可以提高可靠性;但同时，活动部分越多出现故障的可能性就大。SOA 应用程序只与其服务一样可靠。

　　这些列表根本不足以包含所有方面，但我希望这能让您更好地了解什么是 SOA 以及适合使用 SOA 的情况。如果您需要这方面的专业帮助，请访问 IBM Software Services for WebSphere，在其中可以找到各种参考资料。