Service-Oriented Architecture，SOA（转）

http://blog.csdn.net/WOOSHN/article/details/8036910

介绍：

     IT体系结构已非常成熟，它是一种成功处理典型IT问题的方法。体系结构中一个受到很大重视且相对较新的分支是面向服务的体系结构(SOA)。SOA经常被吹捧为企业用于解决应用程序灵活性和高维护成本问题的万能药，常常被视为帮助企业提高其IT投资回报（Return On Investment，ROI）的方法。SOA是用于进行IT系统设计以确保业务目标与IT一致的主要体系结构样式，允许构建具有弹性的IT系统来满足新的和不断变化的业务需求。

     SOA是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。

     在企业传统的系统开发中，企业往往在设计架构的时候都是采用了紧耦合形式，这是封闭的，自成一体的。这种架构下的的MRP、ERP、OA等产品很难适应或快速响应市场或客户灵活多变的需求，以及后续的扩展。在这样的市场、及客户需求下，从而催生了软件产品一种新的设计或架构的理念：面向服务架构。

     SOA架构，是一种粗粒度、开放式、松耦合的服务结构，要求软件产品在开发过程中，按照相关的标准或协议，进行分层开发。通过这种分层设计或架构体系可以使软件产品变得更加弹性和灵活，且尽可能的与第三方软件产品互补兼容，以达到快速扩展，满足或响应市场或客户需求的多样化、多变性。

观点：

    SOA架构带来的主要观点是业务驱动IT，即业务驱动和业务更加紧密地联系在一起。以粗粒度的业务服务作为基础来对公司业务进行建模，这样就可以产生简洁的业务和系统视图;以业务服务为基础来实现的IT系统更灵活、更易于重用、也更快地应对企业业务需求的变化;以业务服务为基础，通过显式地方式来定义、描述、实现和管理业务层次的粗粒度服务(包括业务流程)，提供了业务服务模型和相关IT业务之间提供了更好的"可追溯性"，缩小了它们之间的差距，使得业务服务的变化更容易传递到IT。另外，SOA的一条重要的基本原则是，它能跨各种异类功能和基础设施环境提供服务互操作性。SOA 是基于业务需求定义的，他依赖于业务原则而不依赖于软件设计，具有突出的互操作性和灵活的服务即插即用功能。

 

优点：

  1、更易维护：业务服务提供者和业务服务使用者的松散耦合关系及对开放标准的采用确保了该特性的实现。建立在以 SOA基础上的信息系统，当需求发生变化的时候，不需要修改提供业务服务的接口，只需要调整业务服务流程或者修改操作即可，整个应用系统也更容易被维护。

  2、更高的可用性：该特点是在于服务提供者和服务使用者的松散耦合关系上得以发挥与体现。使用者无须了解提供者的具休实现细节。

　3、更好的伸缩性：依靠业务服务设计、开发和部署等所采用的架构模型实现伸缩性。使得服务提供者可以互相彼此独立地进行调整，以满足新的服务需求。

 

缺点：

    1、安全问题：

    （1）SOA做为一种基于服务的架构，其面向的是流程。这样，当企业真正实施基于SOA的应用软件以后，表面看来，企业的业务流程得到了梳理，内控的能力提高了，但SOA架构要求必须有一个类似于流程管理的程序，来统一管理这些流程。这就带来一个问题，如果这个架构出现问题，那么将导致所有的业务瘫痪。而现在企业信息化的发展趋势是IT和业务结合得越来越紧密，或者可以说业务对IT的依赖程度越来越高，相信如果SOA不能很好地解决安全问题，将会极大地限制其发展。

     （2）SOA强调机器与机器的交互，而大多数IT安全性都是基于人与机器的交互：身份验证和授权在这个环境中变得更加富于挑战性。在未受保护的SOA中，想要阻止Web服务的未授权使用实际上是不可能的。未授权用户可以非常轻松地访问Web服务，而Web服务往往不具备跟踪谁在使用它们或者谁被允许使用它们的固有功能。传统的安全防御对象主要是针对人，而SOA更多地强调了机器与机器的交互，即所谓服务的互操作性，如何应对来自合作伙伴或第三方服务交互请求的威胁(大多数情况下，这些请求被人恶意利用和操纵)将是SOA安全防御的一项重要课题。

     （3）XML通信协议消耗大量带宽，引发安全问题：与传统的二进制通信协议相比，XML最高可以消耗高达50倍的带宽，这不仅会导致交互系统性能下降，而且会为分布式拒绝服务攻击提供可趁之机。因此，未经优化的XML通信将导致严重的安全问题。由于SOA架构的开放性本质，您很难控制SOA中未知的第三方，比如您的合作伙伴，它们可以间接访问未受保护的Web服务。因此，未受保护的Web服务很容易超负荷运转，如果没有访问控制，未受保护的Web服务很容易被来自黑客的大量SOAP消息所“淹没”，结果可能导致拒绝式攻击从而损害系统的正常功能。（为了解决这类问题，市场上已出现了专门的XML加速器。利用基于64位平台架构的语法分析器，该设备可以用来加速XML/SOAP的解析、XML模式的确认、XPath的处理以及 XSLT的功能转换。据公开的产品测试报告称，这种XML加速器能够达到每秒处理1万多条XML消息的能力。）

    （4）基于XML的服务间通信易受到监听和窃取：由于XML的纯文本的本质，未经保护的XML在互联网传输过程中很容易被监听和窃取。为了保障基于XML的通信安全，我们需要从传输层和消息层两个层面进行保护。通过传输安全，可以保证只允许授权用户可以访问基于XML的Web服务，目前可扩展访问控制标记语言(Extensible Access Control Markup Language，XACML)和Web服务策略(WS-Policy)是专门用来解决这个问题的两个标准;通过消息安全，可以保证Web服务环境中交换的XML消息的完整性和保密性，Web服务安全(Web Service Security，WSS)和安全声明标记语言(Security Assertion Markup Language，SAML)则用来解决这方面的问题。

　 2、个性化问题。SOA通过所谓粗粒度服务接口和分级，确实提高了效率。实现流程化以后，也确实简化了开发难度。如果这个流程不适合我这个企业的实际情况，我还是需要个性化开发。国内的中小企业占到了企业总量的70%，他们的需求很具个性化，而且比较在意价格的因素。实际上这和SOA高度集成的性质是不相符的。

 

使用：   

 一些公司把SOA简单地当作一种连接具体的应用程序和创建服务库的技术，而不是使用SOA开发一个基于软件的相关的业务能力组合。如果你把SOA本身当作一种具体的技术解决方案，而不是当作改善你的业务的一种方法，你就不会实现SOA的好处。

    SOA的真正价值和实现是：流程。我们将那些随着时间推移在不断发生变化的业务放在BPM层中，使得核心业务流程的变更变得更加简单。比如说，企业增加一条新产品线可能会导致公司定义销售税的改变，我们可以通过流程，将这样的业务流程变更转变为我们对流程的配置，这种架构能够更好地支持业务变更，为IT带来敏捷的价值。

    尽管大多数人认为SOA的卖点是重用，或在多个系统间重用服务的能力，但是随着时间的推移我们会渐渐发现，SOA的真正价值是提供了无需一连串重新开发、测试和部署，就能改变核心业务流程的能力，我认为这一点才是最重要的，即SOA的价值定位应该是它促进架构敏捷的能力，或是支持架构变更的能力。

    敏捷的价值能够带来战略上的优势。SOA的最终价值来自于它在更大的前景目标中扮演的角色SOA 是从传统的业务竖井向新的业务技术过渡的一个关键的部分。许多技术趋势(从云计算和虚拟化到业务服务管理、商务智能和文件管理)都使用或者支持SOA，或者是与SOA的业务设计重点协调设计的。SOA应该是一个更大的前景目标的基础，如Forrester公司的数字业务架构。这个数字业务架构包括你的所有的技术计划，代表了你的业务能力并且指导你的架构和架构战略的向前发展。

    另外， 在中间件领域，SOA架构日益成为中间件软件供应商争夺的新焦点。谁都希望自己能够先于竞争对手提供最优的SOA技术实现平台。从技术上来说，Web服务、组件技术的采用将有助于SOA的进一步普及，从业务上来说，企业用户要求性价比更高的应用系统，SOA恰恰适应了这样的趋势。

 

误区：

   1、忽略遗留系统的技术限制：

     大量 SOA 工作都非常依赖驻留在遗留系统内的现有数据和应用程序。遗留系统的某些功能通常并不能适应基于 SOA 的应用程序中的实时特性。这种问题的一个典型例子就是单线程遗留应用程序，在此类应用程序中，业务功能的实现仅允许进行单线程访问。遗留系统限制的另一个例子是仅在固定时间运行的计划批处理。

     决定将遗留应用程序或数据作为 SOA 系统的一部分时，务必理解这可能会给整个SOA带来的限制。如刚刚提到的，遗留应用程序的单线程特性就是遗留系统技术限制的一个例子。现代企业的业务功能经常可保证提供远远超过现有系统的功能之外的基础设施事务功能。在此类情况下，可以构建以现代基础设施组合为基础的基于 SOA 的解决方案来逐步淘汰遗留系统。为此，组织需要选择对业务最重要的功能，并使用基于技术先进的基础设施的解决方案来替换其现有遗留实现。完成此阶段工作后，可以随后对其他业务功能进行现代化。此方法提供了用于逐步淘汰遗留系统的可行选择。

  2、将SOA 与Web服务划等号：

   将Web服务实现等同于SOA 是一个典型的SOA反模式，这种情况通常发生在企业希望快速实现SOA 但并未评估其IT系统（包括应用程序和基础设施）的成熟度时。此类企业会将所有内容都作为Web服务实现。IDE的发展已确保进行Web服务创建的技术部分得到无缝支持，并不要求进行大量的学习，从而使得IT部门能非常方便地创Web服务，而不会过多考虑是否与企业的业务目标一致。Web 服务的大量增加带来了管理困难，并为基础设施操作带来了不必要的成本。因此，如果企业的远景仅是实现一组 Web 服务，然后尝试获得SOA所带来的好处的话，最好后退一步，重新对此进行考虑。如果企业希望充分利用SOA，则需要彻底了解体系结构和实现之间的差异，并对这一事实加以尊重。Web 服务是用于实现 SOA 的最流行的实现，SOA 是一种体系结构样式，允许 IT 服务与业务需求保持一致，从而确保IT的业务价值。为了获得SOA的好处，企业IT团队需要完全了解SOA和Web服务间的区别。即，IT团队需要认识到，SOA是一个体系结构规程，而Web服务是目前最流行的SOA实现技术。

   建模和设计SOA时，强烈建议IT团队采用标准方法。IBM 的面向服务的建模和体系结构（Service-Oriented Modeling and Architecture，SOMA）提供了用于进行建模和设计的规定性详细方法。从最高的抽象级别而言，SOMA 提供了包含三个步骤的流程，用于进行服务标识、规范制订和实现，可帮助创建能用于 SOA 实现的输出。另外，还建议在设计 SOA 前对各个领域（如业务角度、组织、应用程序、体系结构）的企业服务集成成熟度进行评估。通过评估这些领域的成熟度水平，可对企业的当前状态进行评估；您可以随后创建增量转换路线图，以达到更高的服务集成成熟度水平。为了帮助您完成此任务，IBM 提供了称为服务集成成熟度模型（Service Integration Maturity Model，SIMM）技术。

  3、细粒度服务：

  甚至在开始 SOA 活动前，业务信息（数据）和应用程序功能也通常存在于当前的企业 IT 投资组合中。这些传统的企业应用程序通常是基于API的。用于访问客户信息的典型API 的示例有getFirstName()、getLastName() 或 getCelPhone()。这些 API 本质上通常是非常细粒度的。   

  一个常见的 SOA 错误做法是，使用服务接口包装这种细粒度API，并将其通过Web服务描述语言（Web Services Description Language，WSDL）定义对外公开。这会导致错误地将服务概念看作不过是“使用昂贵的服务Facade包装的漂亮API”。不仅得到的“服务”仅传递很少的业务数据，而且这种做法也会导致服务数量剧增。从而导致使用者要负责按照正确的顺序聚合服务，以便实现任何高级业务功能。请记住，服务并不是免费的：对于调用每个服务，应用程序都将以损失一定性能为代价。刚刚提到的失误将导致服务间频繁通信，从而导致系统开销增加，所带来的性能损失将对SOA采用造成极大的阻碍。

   正如我们多次提到的，服务必须与业务保持一致，并能为企业提供真正的收益潜力（无论通过减少成本和节约，还是通过产生收入）。创建仅模拟API实现的细粒度服务将不能为SOA或企业提供任何帮助。 

   服务可以通过聚合多个低级细粒度 API 实现的功能来实现。不要将每个细粒度API都作为服务公开；应该从API抽象出粗粒度的、与业务一致的接口，然后将此接口作为服务公开。这不仅能减少网络开销和各个应用程序层次间的通信量，而且还向与业务保持一致的服务接口迈进了一大步。 

    4、点到点调用：

      服务提供者和服务使用者的概念对SOA非常重要。使用者对服务的使用可以通过多种方法实现。在此领域最常见的失误是采用点到点调用。这种方法会导致公开SOA系统中服务使用者和提供者间的连接（糟糕的n*n）。或许您可以让此类系统投入运行，但又如何长期对其进行维护，并同时跟踪所有连接，而且在其中任意一个服务或应用程序被替换或重写时进行必要的更改呢？ 

     当企业在应用程序间采用复杂的紧密耦合时（特别在投资组合中存在大量应用程序时），需要配备恰当的服务调用体系结构。IT系统设计需要创建逻辑体系结构层，以封装和执行（数据）转换、（服务调用）路由和（可能的不同服务的异类实现间的）协议中介。通过这样进行分解，可以在服务提供者和使用者间实现松散耦合。即，一个这样的逻辑体系结构，其中的服务提供者和服务使用者通过逻辑总线进行通信。

     服务使用者通过中间层同服务提供者分离。使用者与逻辑总线进行通信，而后者跟踪来自提供者的可用服务，并负责调用恰当的提供者。这就减少了具有大量服务的系统中的点到点通信导致的问题。在进行服务实现前，如果尚未定义，应该对服务总线的体系结构进行概念化。这个规则特别适用于包含大量需要面向服务和进行集成的应用程序和遗留系统的企业。 

   5、不遵循标准：

     采用SOA时，务必遵循开放标准，而不要尝试忽略这些标准或自己创建替代解决方案。例如，最好创建企业基础设施来使用统一描述、发现和集成（Universal Description, Discovery and Integration，UDDI）作为将来的联合注册中心生态系统，而不要使用服务发现标准或构建服务发现自定义解决方案（如使用服务名称与URL数据库）。 

    在 SOA 中的服务规范制订期间，尤为重要的是，要遵循行业特定的标准XML规范。此类行业特定标准定义消息的格式和业务实体，必须将其作为定义构建服务时使用的消息格式和数据类型的基础使用。 现在亟待针对整个行业提出XML规范来定义企业信息模型及用于与模型一起使用的一组标准服务操作。很多垂直行业正在朝着这个目标快速发展。例如，Agent-Company Organization for Research and Development (ACORD) 是针对保险行业的基XML的标准，Justice XML Data Dictionary (JXDD) 是针对美国国土安全部使用的事故管理规程的基XML的标准,Open Network Video Interface Forum(ONVIF)是视频监控领域国际标准，而OpenTravel Alliance (OTA) 则是旅行和运输行业的标准。这些标准均已作为稳定规范发布，越来越多的基于SOA的工作正在采用这些标准。 

    通过遵循公共消息格式词汇进行消息交换来采用并遵循此类标准，可以使得SOA足够灵活，能在生态系统中的合作伙伴之间进行共享。它还允许对符合并实现这些标准的供应商SOA产品进行即插即用。此灵活性是定义和结构设计良好的SOA的关键元素之一，可支持成功创建大型 SOA 生态系统。 

    在没有此类意识且不进行专门的行业标准分析和采用工作的企业中，开发团队需要考虑标准的重要性，并将其制度化。恰当的控制框架在向涉众说明此消息时将非常有用，可帮助确保遵从性和成功采用。在对标准没有足够重视但仍然需要SOA的情况下，组织将不能得到SOA的很多主要好处。 

     6、使用冗余数据存储：

      在包含具有多年应用程序处理经验的IT部门的典型大型企业中，经常会发现包含重复信息的多个数据存储和数据库系统。之所以这样做的主要原因是采用了典型的竖井方法，在这种方法中，应用程序必须分离，各个应用程序的重点都是企业内的单个组织单位。 

     当企业开始向SOA过渡时，抛开所有现有系统并重新从头构建所有内容的做法并不实际。不过，在此类环境中，针对不同数据源（即使这些数据源中包含完全相同的数据）构建IT服务的做法并不少见。 更为有效的方法是对数据进行整合，以便异类数据系统能形成单个数据视图（例如，创建单个经过整合的数据库来存储客户信息）。处理此问题的另一个方法是创建虚拟数据服务，以将数据冗余封装在企业信息系统中，并通过高级服务或业务流程使用此数据服务。 为每个数据系统分别创建服务并不是使用SOA对企业信息系统的信息进行聚合的好方法，因此必须避免这样做。 

   7、“大爆炸”式SOA：

   SOA的定义并不完全相同，具体取决于您在组织中的角色。对于业务执行人员，SOA创建了企业希望向其客户和合作伙伴或组织的其他部分公开的一组服务。对于架构师，SOA 是一种体系结构样式，此样式至少需要有服务提供者、请求者和服务描述。对于程序员，SOA 是一个由标准、工具和 Web 服务等技术加以补充的编程模型。要理解和认识SOA过渡是整个企业（涉及IT和业务部门一直到相关涉众）的范式转换并不难。此类范式转换最好通过迭代模型实现，在此类模型中，将标识一组对业务非常关键且价值高的功能来进行服务支持工作。此模型可随后供后续服务支持项目和活动使用。如果采用“大爆炸”方法，计划一次性对整个企业投资组合全面启用服务，将给整个组织带来太多的业务风险。 

  SOA 与其他体系结构不同，因为它显式地处理了企业很多的非技术约束。其中一个约束就是，大型组织往往采用增量方式逐步发展。组织的IT基础设施应该支持类似的发展方式。这样的迭代式发展路线可解决以下问题： 

  （1）故障风险：IT正逐渐被视为现代企业的心脏。任何大型的IT故障都可能给公司带来严重的财务和操作后果。因此，开展和执行IT项目时必须非常小心。迭代式发展可通过允许组织逐步进行现代化工作，从而减少出现故障的风险。 

  （2）反对更改：任何组织接受和容纳更改的能力都是有限的。更改将影响涉及手动和自动业务流程的企业日常操作。发展的方法可确保引入新的流程和系统带来的更改非常适应企业的容量，且不会在其人员中引起大的混乱。 

  （3）可行性： 新功能的大小应该是影响其实现在整个企业内的可行性的一个因素。在 SOA 中，新功能并不一定总是仅受单个业务部门（Line Of Business，LOB）的约束，需要考虑很多跨组织的依赖关系。

 由于 SOA 具有两个重要的特征，因此非常适合采用迭代方式逐步过渡到其最终状态： 

 （1）. SOA 允许将大型功能片段分解为更易于管理的、经过了大幅度分解的组件。在将SOA的原则应用到处理企业的特定功能领域的子项目时，可以很容易克服本身就有风险的“大爆炸”方法。这可确保平稳过渡到最终状态，还能确保单个故障（如果出现了）并不会让整个企业陷入崩溃状态。 

 （2）. SOA 在很大程度上与技术无关，因此可以将业务方面和技术方面分离，将其作为能够以独立方式进行修改的独立实体。SOA能以灵活的方式将业务功能及需求与IT功能联系起来，因此业务或为其提供支持的IT都不会受到另一方的影响。 

  想进行“大爆炸”式过渡的企业可能并不适合使用SOA，更不用说实现 SOA 的真正好处了。

  8、忽视服务所有关系：

   业务服务的需求在部门或组织级别标识，其中的每个业务部门都具有特定的业务功能需求。其中一些业务功能直接与企业的业务目标保持一致，而这意味着可能会将其作为通过外部化服务定义说明的服务接口公开。 没有恰当地指明服务所有关系模型时，会出现一个问题。很多企业强调提供大量服务，将这些服务用于进行组合。而这些服务的所有关系需求通常却被忽略了。 

   每个业务服务必须具有其所属的、进行了恰当记录并被一致认可的LOB。伴随所有关系的是满足服务的非功能要求（NonFunctional Requirement，NFR）和负责处理不遵从情况的责任。孤立业务服务的一个典型结果是不遵从服务SLA，而这可能使得服务成为企业级服务组合中最弱的联系。这个最弱的联系甚至可能会破坏此孤立服务参与的业务流程的总体SLA 要求，从而造成企业级的负面影响。 

   虽然对给定服务的LOB所有者而言，此类要求可能很高，但LOB所有者可以提供服务来创建积极的影响。假定LOB所有者将向其他部门的服务使用者收取一小笔费用。反过来，她将严格遵循指定的服务水平 SLA和NFR。这可以帮助她所在的业务单位补偿服务的开发成本。 

   业务域所有关系也同样重要，因为企业服务投资组合不应该交给IT部门进行开发和维护工作。如果IT驱动企业的SOA开发，他们通常会首先以最方便开发服务为目标（这也是可以理解的），而不会太多注意服务的业务价值。这个方法将导致业务目标和所开发的服务间的不一致。在这种情况下，SOA 的好处就不能实现。 

  服务的业务单位所有关系对企业SOA活动的成功至关重要。当未实现业务所有关系模型时，SOA 可能成为企业SOA成功的拌脚石。 

  9、忽视SOA治理：

  治理是一个决策权限和管理框架，可确保在正确时间由经过授权的正确人员进行正确处理。 

  企业进行SOA转换时，由于服务所有关系通常分布在各个LOB中，因此需要认真对待治理问题。由于企业内外各个组织进行维护的移动部件正在快速地增加，这使得有必要进行相应的治理。当且仅当服务得到有效的治理，严格遵循SLA和NFR（如安全性、可靠性、性能等方面）时，业务服务的这种跨组织特性和潜在的跨组织边界的服务组合才能正确而有效地发挥作用。 

   为了标识、指定、创建和部署企业服务，需要通过能够监督企业的服务投资组合的整个服务生命周期的强大而有效的组织进行有效的面向服务的治理。为了保证策略规则和决策及其执行和组织良好的服务生命周期管理要求，需要将SOA治理的实现作为企业SOA转换的策略和计划阶段的一部分，而不是一个事后再添加的东西。 

   在SOA的早期，治理仅是一个不错的可选规程。但随着在具有复杂、集成的价值链的实际企业中SOA实现的不断成熟和复杂性的不断提高，SOA治理如今在整个SOA过渡策略中扮演着不可或缺的角色。 

   未认识到有效治理结构的重要性的企业可能不会从SOA得到太多的好处。事实上，此类企业中的SOA实现会被证明实际上具有破坏性，而且缺乏正确的组织结构来有效地遵循恰当的SOA原则和获得其好处。

 10、其他注意事项（转SOA前三思）：

   企业应该避免为了创建软件组件、基础设施解决方案和服务来解决单个具体业务问题而购买中间件产品、数据库系统和管理解决方案。此类具体的一对一的产品到解决方案映射可能会带来冗余，或被证明成本太高，不适合SOA实现。相反，应该将重点放在确定问题间的共性，然后将这些共性反映到技术解决方案中。 

   不应强制要求在SOA开发的过程中进行问题域间的过度分离。细粒度问题空间之间的此类过度分离可能导致基于服务的总体解决方案过度零碎。这样可能会导致解决方案非常低效，特别在延迟和性能非常关键的情况下更是如此。 

   如果没有恰当的SOA远景，SOA设计人员和实现人员将无法确定企业应该达到的最终状态。服务必须能追溯到一个或多个业务目标，以证明其存在的必要性。如果无法根据某种业务度量标准测定 SOA 的好处，则SOA过渡的整个目的就值得商榷了。显然，在没有恰当标识、定义和记录SOA远景、业务目标和业务灵活性度量标准的情况下就着手进行SOA活动并不明智。 

   最后，企业需要了解自己对灵活性的需求。每个企业的业务灵活性需求并不相同。它们是由竞争和差异化策略、上市时间及各种其他因素驱动的。灵活性需要通过SOA实际实现；灵活性的总体工程工作可能会影响企业的IT系统性能。 

最后：

   SOA无论如何都不是魔术，无法立即解决每个企业IT体系结构的问题。采用SOA时，企业应该充分了解各方面的信息，采取注重实效的方法，从而使得SOA的业务价值主张理论能与其实现的实际复杂性相符。不过，如果正确实现，且能避免此处讨论的种种失误，您将发现采用SOA的很多优势。 

后记：跟web服务打交道也有一段时间了，一直没有时间好好整理一下，故将之前的一些资料和自己的一些见解整合了一下，陆续更新中。。。