选择SOA的原因和时机

引言

面向服务的体系结构 (SOA) 已成为了一项事实标准，用于开发基于组件的应用程序，可使用标准接口通过网络(Internet 或其他网络)访问这些应用程序。至少 IBM 高级管理人员和很多其他供应商、分析师、顾问和软件开发人员都这么说。他们还将告诉您，整个行业都在逐步采用 SOA，如果您尚未开始 SOA 开发，将很快跟不上时代的步伐了。

何时采用 SOA，何时不采用 SOA

IBM 的目标之一是在其产品内开发和采用开放标准。通过这样做，就能在您公司的 IT 基础结构中实现 SOA 的价值主张。SOA 能够优化业务需求与 IT 的一致性，能够将业务流程活动从服务实现中分离出来，还能够降低操作成本。只有在不固定供应商的情况下才能真正实现这些功能，此时面向 SOA 实现的技术可以无缝集成(考虑:“开放标准”)，以构造全面的端到端解决方案。

当考虑了策略业务目标和活动时，理论上的 SOA 概念非常具有吸引力，更加容易得到支持。不过，不可轻易决定要实现 SOA。这与改变生活方式有些类似，因为开发和操作团队遵循的 IT 控制模式将完全不同。我提倡进行业务驱动开发。此过程涉及到将业务需求细化为 IT 要求，然后将 IT 要求细化为 IT 功能，以确定满足这些需求所需的技术。根据我过去四年开发基于 Web 服务的解决方案和更为成熟的基于 SOA 的解决方案的经验，以下这些相关因素通常会让我建议采用面向服务的体系结构:

• 集成成本持续增长，而并未因为可提供真正投资回报 (ROI) 的新业务机会而得到缓解。
• 兼并和收购是您公司扩大市场份额和获得新发展机会的业务模式的核心。
• 解决方案要求对来自异构系统和编程模型的业务功能进行集成。
• 业务的生存依赖于根据市场变化快速调整或即时响应竞争威胁的能力。
• 全球经济的影响要求您的公司事半功倍地开展业务，而且有必要依赖业务合作伙伴提供非核心业务功能。
• 就提高收益而言，与业务合作伙伴协作的效率对您的公司十分关键。
• 您公司业务资产的价值在减少，因为不能对其进行评估，以在最初用途之外的其他地方使用。
• 您公司员工的效率出现了问题，因为他们的大部分时间并没有花在提供公司业务模型的核心功能和服务上。
• 您公司的业务充满了机会型的业务工作。
• 您公司从头开始开发新应用程序。(我认为 SOA 应当作为定位将来的新应用程序的缺省体系结构样式，业务条件有其他限制时除外。)

在理想情况下，您和您的业务合作伙伴间没有预算限制、计划期限、技能差距和优先级差异，我想，此时完全可以说每个人都会采用 SOA，或者至少会考虑采用 SOA。不过，我们的选择实际上经常受到过去的决策的影响和限制(例如，技术投资、编程模型采用、服务的合同协定等)。因此，我们并不能总是自由地采用看起来能满足某个业务需求或技术要求的最佳选项。以下的注意事项会让我不建议采用面向服务的体系结构或说明现在实现 SOA 的边际收益:

• 您公司只将小部分 IT 预算用于集成活动。
• 您公司的大部分流程都是手动的或以文档为中心的，自动化的机会几乎为零。
• 您公司的大部分应用程序开发都使用相同的编程模型。
• 您公司的操作由一个或两个客户关系管理 (CRM) 和企业资源规划 (ERP) 应用程序管理，几乎没有集成要求。
• 您公司的现有技能库与实现支持 SOA 的基础结构所需的技能库之间存在重大差异。
• 未发现可从 SOA 提供的功能受益的业务需求或机会。
• 新业务服务的可用性将对现有的收益流带来负面影响。
• 您公司依赖的业务合作伙伴对公司间流程的自动化采用了不同的优先级。
• 您公司的主要业务的开展涉及到海量且同步性和实时性要求非常高的事务。

 前面的列表只是一个示例，用以说明 SOA 是否是您公司最佳选择的原因。当然，每个合同或项目都具有唯一的要求，因此关于何时采用 SOA 的决策取决于您公司的业务状况。SOA 的价值主张十分诱人，但选择何时让您的公司采用 SOA 必须考虑业务环境的实际情况。采用 SOA 不一定要跨一大步，而通常是采用循序渐进的方式进行的。首先找到可以利用 SOA 概念和原则的项目，然后使用主要性能指标测定其价值，这是一种让大家受益的好方法。

将业务与 IT 结合起来

SOA 不仅是一个开发范例。该体系结构用于在业务和 IT 之间构建中间地段，其中包含双方都同意的一组与业务一致的 IT 服务，这些服务结合在一起，以实现组织的业务流程和目标。此范例提供了前所未有的灵活性:它允许将业务流程的结构化组成从为流中每个活动提供功能的服务中分离出来。它还允许将业务实现与其描述分离开来。进行了此分离后，公司能以增量的方式更改其后端遗留系统，并添加新功能来支持新需求，而不用受到供应商选择的限制。因此，可以在最小化对业务流程和 IT 系统的影响的前提下对软件包和自定义应用程序进行替换。

将访问功能从其实现分离的下一步工作就是 SOA。而且，除了此功能方面外，我们还可以将非功能方面外部化。例如，我们可以根据建立的业务策略确定哪些人应该可以访问特定的功能。我们还可以定义如何管理希望以灵活的、可重构的方式访问的技术资源。

软件工程发展的下一步就是此体系结构。它使我们从结构化对象转向分布式对象和组件，然后以一组公共服务为中心来将业务和 IT 加以结合(这些服务结合在一起，可以实现组织的流程和目标)。SOA 还允许将公司的部分业务流程向生态系统中的合作伙伴公开。

当需要支持业务灵活性的 IT 灵活性时，就可以使用 SOA。因此，对于两个程序需要进行通信并访问组合业务流程的行业应用程序而言，就非常适合选择 SOA。

使用 SOA 技术时，实时或被动系统通常不是进行实现的最佳选择，因为当前的技术不支持将 SOA 用于有大量并发使用情况的实时系统。不过，这些系统的建模也可以从 SOA 提供的分离和独立概念获益。

SOA 非常适合用于消除冗余及将业务与未紧密耦合到特定服务实现的 IT 功能相结合。它可以允许服务使用者选择后备服务提供者(不仅基于功能进行选择——我需要类似的功能，但不要此版本的服务中的额外依赖项，还可以基于设计及运行时策略和 Web 服务管理功能进行选择)。

企业体系结构基于 SOA 的公司具有稳定的基础，能从现有系统概念地抽象业务功能。它们还具有允许随着新软件包、系统和资产的提供和新需求的出现以增量的方式进行业务驱动的 IT 转换的基础。

一个重要但略显不足的机制

在企业范围中，大量的创新都出现在以下两个方面:企业边缘和企业之间。在边缘上，我们可以看到在中间件之上的框架投入了很多精力(独立于领域的框架，如 Ajax，以及特定于领域的框架，以特定行业为中心进行结合)，也投入了很多精力进行与设备相关的工作 [ 典型的移动设备和具有无线频率识别(Radio Frequency Identification，RFID)标记的设备 ]。而在企业之间，我们可以看到系统(遗留系统和新系统)的系统的形成。

在此类以 Web 为中心的系统中，服务已被证实为这两个方面的重要机制。在边缘，服务提供超越基础技术的行为。而在企业之间，服务提供了各种系统间语义丰富的强大通信方式。

虽然这样说，但在系统的构造中，服务是一个重要却略显不足的机制。这样说有些过于简单化，但总的说来，服务对于高频率或非常小粒度的连接而言，并不非常适合。而且，服务当然不是唯一适合各个系统的体系结构的分解机制。

SOA、Web 服务与优势保持

 

SOA 是一个使用得有些过量的首字母缩写，被从高级管理人员到开人员等各方面的人用(滥用)来传达多种(有时候是不一致的)语义。在我看来，面向服务的体系结构是一个框架，用于将业务流程和支持技术基础结构作为标准化且管理良好的组件——服务——进行集成，可以对服务进行组合、重用和调整以满足不断变化的业务优先级。

SOA 新手认为 SOA 和 Web 服务是等效的。可能存在不使用任何 Web 服务，而使用现有 IT 资产(从大型机事务到基于对象的系统)的基于 SOA 的有效解决方案。而且，我曾经看到过几个从部门级别发展出来的不是有效 SOA 应用程序的 Web 服务实现。这些 Web 服务岛通常并不完全遵循所有的核心 SOA 原则和特征——它们可能不是松散耦合、未抽象、不可重用、未组件化或不是独立于平台和协议的，最重要的是，它们可能不提供真正的业务价值。

由于 Web 服务提供了一个 Level 字段，供基础结构和应用程序供应商进行创新和互操作，很多规范、概要、术语都使得这一混淆扩大化了。Web 服务仅是一个标准和技术的集合(还有很多其他技术支持选项)，用以实现基于 SOA 的解决方案。

在快速发展的全球经济环境中，企业要保持竞争优势，必须保持足够的灵活性。通过使用 SOA 原则将 IT 基础结构与核心企业流程结合，可以提供和保持这个优势。因此，理解和采用 SOA 所面临的问题不是如何或为什么，而是什么时候?基于 SOA 的企业解决方案已被证实能简化业务操作、提高效率、降低成本及消除冗余。

不过，为了获得这些好处，必须正确地应用 SOA。必须具有相应企业范围内的远景和转换路线图，必须有业务执行人员的财务支持和承诺，并由有经验的架构师以增量迭代的方式进行部署。这些增量步骤应该首先针对关键业务问题进行，最终的解决方案应该能提供业务价值。这样可以帮助保持和促进使用 SOA 进行端到端企业转换。在采用 SOA 的过程中，SOA 将不断遇到各种重大的挑战，其中包括政治和文化的多样性。

从纯技术角度而言，SOA 平台(包括工具和运行时)也在经历着巨大的转变。开发工具环境包含大量的建模工具、行业根深蒂固的场景、重用模式、方案和丰富的可视表示和控件以及模拟技术。运行时也同样在不断发展，从而提供增强的服务质量、声明性的和基于策略的管理和吸引人的管理和监视 Dashboard(针对 IT 事件和业务事件)，并使用具有自我修复功能的自动工具进行检测。我们正处在对解决方案生命周期的每个方面进行改革的浪尖上，而 SOA 则是关键的催化剂。不过，从长远来看，如果我们不谨慎的话，这个抽象和易用性可能会使 IT 架构师或开发人员和计算机科学与技术的根本基础脱离联系。

模型驱动的开发和虚拟企业

您可能已经选择使用 SOA 了。大部分中型和大型企业都在其应用程序设计中应用了 SOA 元素。结构良好的 CICS® 和 IMS™ 程序通常符合 SOA 的要求。很多公司已构建了由消息驱动的应用程序组成的分布式系统。会话 Enterprise JavaBean 就是“类 SOA 的”。很多 ISV 系统都采用类似于服务的构造;例如 SAP IDocs。SOA 将结构良好的分布式系统的指南系统化，是结构化编程、模型对象 (OO) 的概念的子集和消息驱动的处理的自然发展。

Web 服务是一组用于构建 SOA 解决方案的标准。基础结构供应商 (IBM、BEA、Microsoft) 和应用程序供应商 (SAP、Oracle) 正像采用任何软件技术一样迅速地采用 Web 服务。在很短的时间内，我们行业的运行时互操作性 [简单对象访问协议(Simple Object Access Protocol，SOAP)、HTTP、WS-Security、WS-ReliableMessaging] 和开发工具间的互操作性 [Web 服务描述语言(Services Description Language，WSDL)、WS-Policy、Business Process Execution Language for Web Services (BPEL4WS) ] 就达到了前所未有的水平。这个互操作性降低了迁移到 SOA 的成本，从而更容易获得其带来的好处。

都有什么好处呢?此处将不详细讨论全部或任何单个好处。我将简要地提一下两个好处:

SOA 支持模型驱动的开发和从业务透视图进行解决方案监视。我们通过使用 WebSphere® Business Modeler 产生一个允许分析人员和业务专业人员进行推断和设计他们的业务流程的工具，从而有了很大进步。SOA 操作是流程中的任务或步骤的自然呈现，而组合服务的实现(BPEL4WS，业务状态机)则是流程的自然表示。根据简单业务规则(使用 WebSphere Process Server 启用)，WS-Policy 和服务实现这两种方法都是业务策略的自然表示。

Web 服务支持“虚拟企业”。MQ 和 Common Object Request Broker Architecture (CORBA) 等以前的技术主要针对企业内计算进行了优化。Web 服务协议和 WSDL 在 Internet 和内部网络中均可工作。这样就能使用以前用于企业内部应用程集成的相同模型来在 Internet 上实现简单的、快速开发的机会型 B2B 了。

控制问题

SOA 与已在 IT 行业存在了 30 年甚至更长时间的其他软件模块化流程相似。SOA 所不同的硬件和网络已足够成熟，可以支持这项基于标准的技术。从任何方面而言，SOA 都不是过去行业内的风行的热潮技术，但包含了广泛的行业标准和支持。

SOA 为企业提供了一个机会，以标识其核心能力和决定是否将这些核心能力作为服务向其行业和业务合作伙伴提供。另一方面的事实是;企业可以对作为其核心基础结构(不是核心能力)一部分的流程和应用程序进行标识，然后确定进行购买。请注意，其中一些服务(提供的或购买的)可能仅为业务流程。企业架构师可以牵头开展相应的工作，以发现企业中具有公共功能集的业务流程和 IT 流程。可以将执行功能打包为外部依赖性很小的组件，并作为服务提供。这就使得业务流程创建者或应用程序开发人员的工作得到简化，以将精力放在能满足股东的业务动力的唯一功能上。

让 SOA 正常工作在很大程度上不是技术问题。让 SOA 正常工作是一个业务控制和 IT 控制问题。技术专家可以根据很多存在的成功模式构造一个 SOA 实现。然后让企业使用这些服务，而不再自己进行创建，这是另一个问题。恰当的体系结构控制将对其服务可供新应用程序使用的项目进行标识。要使得 SOA 投资最终能物有所值，唯一的办法就是让高级管理人员承诺控制预算，或采取某种方式保证业务线能不受干扰。IT 架构师还需要向执行股东报告业务从其 SOA 投资和投入方面获得的价值。

为了让 SOA 与业务合作伙伴协作，需要涉及企业已经建立的关系。现在，很少(如果有)客户在其建立的合同关系之外为合作伙伴提供或购买服务。服务级别协议和争议解决的相关事项要求配备封闭的协作系统。有关信任和安全的结构化信息系统发展组织(Organization for the Advancement of Structured Information Systems，OASIS)标准在过去两年中取得了长足的发展，但在等式的法律和业务一边，仍然更倾向于和企业已经了解的伙伴开展此类业务。

这里没有神话

关于为什么应该考虑 SOA 有三个简单的理由:

1. 这是目前最热门的领域之一;不要落后于时代的步伐。

2. 工具、基础结构和标准经过组合，可为整个 SOA 生命周期提供全面支持。了解我们的端到端编程模型。按照其中提供的详细步骤开展工作，亲身体验成功。

3. 如果您和我们一样不断地追求事半功倍，那么 SOA 可以为您提供帮助。寻找您可以再次利用的东西;不要所有东西都自己从头做起。寻找现有服务，对其进行调整，并加以使用。然后对其中一些服务进行共享。帮助创建一个生态系统，以便在将来能更快地装配更多有意义的解决方案。

开始采用 SOA 与采用任何其他技术或体系结构没有什么区别。可以通过常识来看这个问题。如果您的项目处于十分关键的位置，而您的团队必须投入大量精力学习工具和 API，它就有可能是错误的选择。如果可以在小项目中试用 SOA，则是不错的选择;利用这个经验，可以帮助您定义和扩展到下一个更大的项目。循序渐进，这里没有神话。

只是业务而已

 

SOA 的支持者不断不畏余力地宣传 SOA 的主要技术优势:松散绑定，能够通过组件封装可重用业务功能，最后(但没有像通常那样刻意强调)还能提供更好的集成。

包括我自己也是 SOA 的支持者之一，但我不断在问自己一个问题:客户真的对这种技术推论感兴趣吗?

在过去两年，我一直在与希望获得 SOA 产生的价值主张的客户全面合作。在与客户沟通时，我经常发现客户认为，有很多其他体系结构能提供比我所提到的更多的技术价值。有些客户可能一厢情愿地得出结论，认为非常有经验的架构师和开发团队可以通过使用传统企业应用程序集成 (EAI) 体系结构获得很大价值。很多客户会争辩说，这些方法经过验证，实现风险并没有直接采用 SOA 进行设计的风险大。

这个观点可能会让架构师认识到在有些情况下，SOA 是错误的选择，或者，至少不是最好的选择。SOA 的技术可行性是否是选择其作为解决一系列业务问题的体系结构方法的原因?我会说不是:很多业务及 IT 相关的问题(例如缺乏有力的企业控制模型和策略)将减慢或阻碍任何构思良好的技术 SOA 活动的实现。

在最近一次为期三天的 SOA 研讨会上，一位汽车行业的首席技术官 (CTO) 告诉我下面的话:“我对 SOA 看法是‘只是业务而已’。”他告诉我他采用 SOA 的原因在于:

• 提高他和他的团队实现新产品和流程或更改现有项目的速度
• 降低实现和拥有成本
• 通过外包业务元素或从固定定价改为可变定价(根据业务量)，从而支持灵活的定价模型
• 简化合并和收购所需的集成工作
• 实现更好的 IT 使用率和投资回报

这位 CTO 和他的团队仅关心如何使用其现有的技能(而不必放弃其现有的基础结构)在预算内按时达成这些目标。他们已经在其现有 EAI 基础结构中进行了大量投资。

这位特别的 CTO 的话与很多其他人的说法都不一样。他们只关心关键之处:我如何为股东提供回报?

当然，作为一个有经验的架构师(微笑)，我知道一些解决此问题的体系结构备选方案:

1. 扩展其现有的 EAI 基础结构

2. 计划采用更多的事件驱动体系结构(完全分离的、发布/订阅，等等)

3. 或许可采用 SOA

由于这是一个 SOA 研讨会，而客户为此付费，因此我最初准备选择第三个选项。实际上，对于这个情况，我使用了一点 EAI，一点事件驱动和很多 SOA 方面的东西。SOA 允许在必要时包含 EAI 和事件驱动方法。

对于高速发展的汽车行业，为了保持竞争优势和按时在预算内提供产品，企业必须具有灵活性。这个客户的难点集中在对其业务流程进行管理和合并。正如我的同事在此讨论中指出的，将 IT 基础结构与核心业务流程结合，对于达成目标十分关键。SOA 相关的原则已被证明可以简化业务操作，能减少与实际代码关系很小而集中在人机交互和人员活动上的冗余项。在资金有限的业务环境中，几乎没有客户能为解决特定的业务问题无限制地投入资金，而有时间并愿意对其控制流程进行修整的客户则更少了。这样做听起来不错，但却不会实际这样做。

关键在于对现有基础结构、流程和现有控制模型加以利用和扩展。通过恰当地使用现有 SOA 原则，可以对整个设计和实现流程进行管理，如:

1. 标识问题。

2. 标识组成业务并是难点所在的流程。

3. 对这些流程进行建模，以对其进行简化。

4. 标识现有服务，并编写表示这些流程的其他服务。

5. 将这些服务部署到可提供运行时功能且操作效率高的环境中。

6. 监视这些服务和流程，以获得更高的效率。

那么，网络呢?虽然我们不知道其解决方案到底是什么样的，但应当客观地看待每一个问题。请同时根据技术指标和业务指标来确定是否采用 SOA。如果合适，就使用它。如果不合适，就不用它。SOA 概念和原则将始终可以通过某种方式应用到您的体系结构中。

康庄大道

我们现在都应该知道了整个行业对 SOA 的 ROI 和采用的赞颂之词——松散耦合、重用更好、推向市场的时间更短、易于集成以及互操作性更好。不过，务必了解，我们目前对 SOA 的关注只是实现即插即用企业(或者说是按需企业)的历程中重要的一步而已。

随着我们进入下一个十年，我们将开始着手大幅度减少将来自不同 IT 供应商的产品或组件组合成可行的有价值的端到端解决方案所需的工作量。供应商提供的业务组件将不依赖于基础结构，可以在各种平台上执行。因此，软件开发人员会将更多的精力放在有效集成供应商组件和确保有效的互操作性上。

客户的 IT 操作部门将主要负责选择最适合业务需求的运行时平台;即提供恰当部署和管理业务组件所需的必要服务质量和运行时支持的平台。

相反，IT 业务操作部门将主要关注如何通过定义业务组件(将由其对应的操作人员部署和管理)中包含业务规则实现组织的业务策略。这将通过 WebSphere Business Process Server 之类的业务流程管理系统完成。

IT 业务操作部门所属的人员将是业务和企业体系结构专业人士。无论您是如何定义业务或企业架构师的:为了实现这个远景，整个行业将需要更多的具有 IT 和企业体系结构背景的人士。

虽然这个远景可能十分诱人，仍然存在很大的风险，在进入组件天堂之前，我们必须小心地减小这些风险。在开始进行实现模型服务的体系结构的任务时，最重要的减小风险方法可能就是要求有强有力的管理良好的控制流程和策略。只有通过强有力的企业服务控制策略才能够避免更改管理问题、服务间的语义不匹配和系统功能结合方面出现的难于调试的问题。IT 部门可以通过制定的控制策略来减少风险，这些控制策略由执行监督团队(其中包括 CIO、CTO 和业务线执行官)提出并加以支持。

改善信息

当然，您已经对 SOA 有所了解了。您也知道 Web 服务、业务流程的重要性、模型驱动的体系结构和所有这些让人诚惶诚恐的 WS-* 标准。

但或许您是一名信息人员。您需要负责组织的信息的完整性和对其进行分析。您关心表示业务状态的数据库的性能和稳定性。正如您所知的，真正重要的部分。因此，您可能会问:“为什么我应该关心 SOA?”

作为信息人员，我很关心 SOA。我之所以关心 SOA，是因为 SOA 具有直接和间接影响信息管理系统的能力——事实上可以影响信息本身。为了获得成功，我们需要在业务服务所涉及的信息的上下文中对其进行考虑。我们需要知道检索到的信息是准确的。被更新的信息经过了验证。交换的信息的意义对于服务提供者和使用者都是一样的。如果忽略了这些事情，服务的价值和可重用性就会减少。

直接来说，使用 SOA 时，我们需要在提供者和使用者之间形成一个信息协定，以便让各方知晓信息意义的内涵，并且仍然支持异构系统——换句话说，我们必须假定世界是杂乱无章的，必须对其进行整理，以提高信息的价值，了解不同的结构和意义之间的关系，并在可能的情况下就公共对象达成一致。

将信息作为服务公开还将让我们配备额外的信息服务器拓扑来容纳增加的信息负载。它还会要求我们建立可以对信息访问进行虚拟的点(这样用户就无需知道信息的真正位置以及其组织方式)。它还引入了一些方法，允许我们有效地对这些信息进行组合——通过集合或联合。如果没有建立更多的公共机制或引入经过改进的清除机制，则我们稍后很可能被迫投入巨额的额外资金和资源进行清除，从而导致将来的灵活性下降。

可以采用很多办法实现信息协定。其中一个变得越来越重要的就是主数据管理 (MDM) 领域。MDM 系统可为业务应用程序或服务提供经过清除、整合且特定于域的信息。最常见的 MDM 系统是作为客户和产品信息的信息集线器使用的系统。每个集线器都作为中心点使用，可以在此对信息进行添加、更新、审核、清除、搜索和查询。集线器放置于可以将更改传播到相关数据库或可以生产相关服务的事件的位置。MDM 系统可以是事务型的(在操作业务流程的主线中更新)，也可以是引用型的(提供业务流程所引用的信息的一致来源)。但最重要的是，我们可以将 MDM 系统看作其本身提供了一个一致的服务集，以供在各种业务流程内使用和进行重用。

通过 MDM 等方法显式地实现信息提供者和使用者之间的协定，可以帮助我们实现 SOA 所承诺的灵活业务流程和服务可重用性，并同时为我们提供提高所管理信息的质量的机会。

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

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 应用程序只与其服务一样可靠。