引言
面向服务的体系结构 (SOA) 已成为了一项事实标准，用于开发基于组件的应用程序，可使用标准接口通过网络(Internet 或其他网络)访问这些应用程序。至少 IBM 高级管理人员和很多其他供应商、分析师、顾问和软件开发人员都这么说。他们还将告诉您，整个行业都在逐步采用 SOA，如果您尚未开始 SOA 开发，将很快跟不上时代的步伐了。
IBM 的目标之一是在其产品内开发和采用开放标准。通过这样做，就能在您公司的 IT 基础结构中实现 SOA 的价值主张。SOA 能够优化业务需求与 IT 的一致性，能够将业务流程活动从服务实现中分离出来，还能够降低操作成本。只有在不固定供应商的情况下才能真正实现这些功能，此时面向 SOA 实现的技术可以无缝集成(考虑:“开放标准”)，以构造全面的端到端解决方案。
当考虑了策略业务目标和活动时，理论上的 SOA 概念非常具有吸引力，更加容易得到支持。不过，不可轻易决定要实现 SOA。这与改变生活方式有些类似，因为开发和操作团队遵循的 IT 控制模式将完全不同。我提倡进行业务驱动开发。此过程涉及到将业务需求细化为 IT 要求，然后将 IT 要求细化为 IT 功能，以确定满足这些需求所需的技术。根据我过去四年开发基于 Web 服务的解决方案和更为成熟的基于 SOA 的解决方案的经验，以下这些相关因素通常会让我建议采用面向服务的体系结构:
在理想情况下，您和您的业务合作伙伴间没有预算限制、计划期限、技能差距和优先级差异，我想，此时完全可以说每个人都会采用 SOA，或者至少会考虑采用 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，则是不错的选择;利用这个经验，可以帮助您定义和扩展到下一个更大的项目。循序渐进，这里没有神话。
