什么是面向服务的体系结构（SOA）？

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

这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。 松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而另一方面，紧 耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。

对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为按需（On demand）业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。

虽 然面向服务的体系结构不是一个新鲜事物，但它却是更传统的面向对象的模型的替代模型，面向对象的模型是紧耦合的，已经存在二十多年了。虽然基于 SOA 的系统并不排除使用面向对象的设计来构建单个服务，但是其整体设计却是面向服务的。由于它考虑到了系统内的对象，所以虽然 SOA 是基于对象的，但是作为一个整体，它却不是面向对象的。不同之处在于接口本身。SOA 系统原型的一个典型例子是通用对象请求代理体系结构（Common Object Request Broker Architecture，CORBA），它已经出现很长时间了，其定义的概念与 SOA 相似。

然而，现在的 SOA 已经有所不同了，因为它依赖于一些更新的进展，这些进展是以可扩展标记语言（eXtensible Markup Language，XML）为基础的。通过使用基于 XML 的语言（称为 Web 服务描述语言（Web Services Definition Language，WSDL））来描述接口，服务已经转到更动态且更灵活的接口系统中，非以前 CORBA 中的接口描述语言（Interface Definition Language，IDL）可比了。

Web 服务并不是实现 SOA 的惟一方式。前面刚讲的 CORBA 是另一种方式，这样就有了面向消息的中间件（Message-Oriented Middleware）系统，比如 IBM 的 MQseries。但是为了建立体系结构模型，您所需要的并不只是服务描述。您需要定义整个应用程序如何在服务之间执行其工作流。您尤其需要找到业务的操 作和业务中所使用的软件的操作之间的转换点。因此，SOA 应该能够将业务的商业流程与它们的技术流程联系起来，并且映射这两者之间的关系。例如，给供应商付款的操作是商业流程，而更新您的零件数据库，以包括进新 供应的货物却是技术流程。因而，工作流还可以在 SOA 的设计中扮演重要的角色。

此外，动态业务的工作流不仅可以包括部门之间的操作，甚至还可以包括与不为您控制的外部合作伙伴进行的操作。因此，为了提高效率，您需要定义应该如何得知服务之间的关系的策略，这种策略常常采用服务级协定和操作策略的形式。

最后，所有这些都必须处于一个信任和可靠的环境之中，以同预期的一样根据约定的条款来执行流程。因此，安全、信任和可靠的消息传递应该在任何 SOA 中都起着重要的作用。

我可以用面向服务的体系结构做什么？

对 SOA 的需要来源于需要使业务 IT 系统变得更加灵活，以适应业务中的改变。通过允许强定义的关系和依然灵活的特定实现，IT 系统既可以利用现有系统的功能，又可以准备在以后做一些改变来满足它们之间交互的需要。

下 面举一个具体的例子。一个服装零售组织拥有 500 家国际连锁店，它们常常需要更改设计来赶上时尚的潮流。这可能意味着不仅需要更改样式和颜色，甚至还可能需要更换布料、制造商和可交付的产品。如果零售商 和制造商之间的系统不兼容，那么从一个供应商到另一个供应商的更换可能就是一个非常复杂的软件流程。通过利用 WSDL 接口在操作方面的灵活性，每个公司都可以将它们的现有系统保持现状，而仅仅匹配 WSDL 接口并制订新的服务级协定，这样就不必完全重构它们的软件系统了。这是业务的水平改变，也就是说，它们改变的是合作伙伴，而所有的业务操作基本上都保持不变。这里，业务接口可以作少许改变，而内部操作却不需要改变，之所以这样做，仅仅是为了能够与外部合作伙伴一起工作。

另一种形式是内部改变， 在这种改变中，零售组织现在决定它还将把连锁零售商店内的一些地方出租给专卖流行衣服的小商店，这可以看作是采用店中店（store-in-store） 的业务模型。这里，虽然公司的大多数业务操作都保持不变，但是它们现在需要新的内部软件来处理这样的出租安排。尽管在内部软件系统可以承受全面的检修，但 是它们需要在这样做的同时不会对与现有的供应商系统的交互产生大的影响。在这种情况下，SOA 模型保持原封不动，而内部实现却发生了变化。虽然可以将新的方面添加到 SOA 模型中来加入新的出租安排的职责，但是正常的零售管理系统继续如往常一样。

为了延续内部改变的观念，IT 经理可能会发现，软件的新配置还可以以另外的一种方式加以使用，比如出租粘贴海报的地方以供广告之用。这里，新的业务提议是通过在新的设计中重用灵活的 SOA 模型得出的。这是来自 SOA 模型的新成果，并且还是一个新的机会，而这样的新机会在以前可能是不会有的。

垂 直改变也是可能的，在这种改变中，零售商从销售他们自己的服装完全转变到专门通过店中店模型出租地方。如果垂直改变完全从最底层开始的话，就会带来 SOA 模型结构的显著改变，与之一起改变的还可能有新的系统、软件、流程以及关系。在这种情况下，SOA 模型的好处是它从业务操作和流程的角度考虑问题而不是从应用程序和程序的角度考虑问题，这使得业务管理可以根据业务的操作清楚地确定什么需要添加、修改或 删除。然后可以将软件系统构造为适合业务处理的方式，而不是在许多现有的软件平台上常常看到的其他方式。

正如您可以看到的，在这里，改变和 SOA 系统适应改变的能力是最重要的部分。对于开发人员来说，这样的改变无论是在他们工作的范围之内还是在他们工作的范围之外都有可能发生，这取决于是否有改变 需要知道接口是如何定义的以及它们相互之间如何进行交互。与开发人员不同的是，架构师的作用就是引起对 SOA 模型大的改变。这种分工，就是让开发人员集中精力于创建作为服务定义的功能单元，而让架构师和建模人员集中精力于如何将这些单元适当地组织在一起，它已经 有十多年的历史了，通常用统一建模语言（Universal Modeling Language，UML），并且描述成模型驱动的体系结构（Model-Driven Architecture，MDA）。

构成 SOA 的技术是什么？

SOA 本身是应该如何将软件组织在一起的抽象概念。它依赖于用 XML 和 Web 服务实现并以软件的形式存在的更加具体的观念和技术。此外，它还需要安全性、策略管理、可靠消息传递以及会计系统的支持，从而有效地工作。您还可以通过分 布式事务处理和分布式软件状态管理来进一步地改善它。

SOA 服务和 Web 服务之间的区别在于设计。SOA 概念并没有确切地定义服务具体如何交互，而仅仅定义了服务如何相互理解以及如何交互。其中的区别也就是定义如何执行流程的战略与如何执行流程的战术之间的 区别。而另一方面，Web 服务在需要交互的服务之间如何传递消息有具体的指导原则；从战术上实现 SOA 模型是通过 HTTP 传递的 SOAP 消息中最常见的 SOA 模型。因而，从本质上讲，Web 是实现 SOA 的具体方式之一。

尽 管我们觉得 Web 服务是实现 SOA 的最好方式，但是 SOA 并不局限于 Web 服务。其他使用 WSDL 直接实现服务接口并且通过 XML 消息进行通信的协议也可以包括在 SOA 之中。正如在别处指出的，CORBA 和 IBM 的 MQ 系统通过使用能够处理 WSDL 的新特征也可以参与到 SOA 中来。如果两个服务需要交换数据，那么它们还会需要使用相同的消息传递协议，但是数据接口允许相同的信息交换。

既为了建立所有这些信息的适当控制，又为了应用安全性、策略、可靠性以及会计方面的要求，在 SOA 体系结构的框架中加入了一个新的软件对象。这个对象就是企业服务总线（Enterprise Service Bus，ESB）， 它使用许多可能的消息传递协议来负责适当的控制、流甚至还可能是服务之间所有消息的传输。虽然 ESB 并不是绝对必需的，但它却是在 SOA 中正确管理您的业务流程至关重要的组件。ESB 本身可以是单个引擎，甚至还可以是由许多同级和下级 ESB 组成的分布式系统，这些 ESB 一起工作，以保持 SOA 系统的运行。在概念上，它是从早期比如消息队列和分布式事务计算这些计算机科学概念所建立的存储转发机制发展而来的。

从 开发人员的角度来说，他们使用的工具必须知道 SOA 的能力，并允许开发人员有效地使用 SOA 对象。这将设计 SOA 模型、开发服务和服务对象以及测试 SOA 应用程序这些过程包括进来并组成一个整体。因而，开发人员的工作必须为面向服务的应用程序设计/开发（Service-Oriented Application Design/Development，SOAD）做好准备。

SOA 与其他技术的关系如何？

SOA 可以与许多其他技术结合在一起使用，然而，组件的封装和聚合在其中扮演着重要的角色。如前所述，SOA 可以是一个简单对象、复杂对象、对象的集合、包含许多对象的流程、包含其他流程的流程，甚至还可以是输出单一结果的应用程序的整体集合。在服务之外，它可 以看作是单个实体，但是在其自身中，它可以具有任何级别的复杂性（如果必要的话）。出于性能方面的考虑，大多数 SOA 服务并没有下降到单一对象的粒度，并且更适合于大中型组件。

除了可能离不开 XML 和 WSDL 之外，SOA 并不是特定于语言的。可以用任何编程语言来实现服务，只要这种编程语言可以生成服务并且可以与 WSDL 结合在一起使用就可以了。SOAP 本身并不是绝对需要的，但它是通用的消息传递系统。因此，可以使用几乎任何一种编程语言和支持 WSDL 的平台来实现 SOA 中的成员服务。

基 于通用对象请求代理体系结构（Common Object Broker Request Architecture，CORBA）的应用程序有许多组件必须连接到 SOA 中。虽然 CORBA 中的接口描述语言（Interface Description Language，IDL）在概念上类似于 WSDL，但它不是严格的，因而首先需要将其映射到 WSDL。另外，需要使用更高级的 SOA 协议（比如用于流程和策略管理的协议），而不是 CORBA 中的类似的概念。请记住，这是 CORBA 组件（表示为服务）需要与 SOA 服务交互的情况；在 CORBA 模型中，所有的独立子集仍然可以像以前一样工作。

由对象管理组 （Object Management Group）提出并在许多 IBM Rational 产品中得以实现的模型驱动体系结构在一个更抽象的层次上与 SOA 的概念具有很强的相关性。MDA 基于这样的概念，任何软件流程都可以定义为模型甚至是元模型（即模型的模型），然后可以将这些模型和元模型转换成应用程序的实际组件。因此，MDA 创建了一个模型，这个模型先编译成软件应用程序，而软件应用程序接着又编译成可执行程序，这样就可以在平台上运行了。MDA 并不区分服务和对象这两个概念，但是它确实允许模型由其他子集模型本身组成，这类似于 BPEL（SOA 的一个核心组件）中的流程聚合的概念。

SOA 和 Web 服务是独立于编程语言的，但 Java 是主要的开发语言之一。可以使用定义良好的 Java 接口以及各种协议丰富的 Java 实现为正在构建这个模型的开发人员提供了优势。Java 在此担当了开发每个服务的功能、管理数据对象和与其他在逻辑上封装在服务内的对象进行交互的角色。

SOA 与 Web 的另一个重要的关系是自主计算和网格计算的概念。自主计算的概念应用于管理分布式服务体系结构的范围，具体来说，就是帮助维护策略和服务级协议以及 SOA 系统的总稳定性。

另 外，网格计算可以以两个级别与 SOA 系统一起使用。网格是分布式计算的一种形式，它利用分布式特性和服务之间的交互来为 SOA 应用程序提供计算支持。在这种情况下，网格起到了框架的作用，其中实现了一些或所有单独的服务。因此，SOA 应用程序可以是网格服务的消费者。

在 另一方面，网格本身也可以构建在 SOA 之上。在这种情况下，每个操作系统服务都是构成整个 SOA 应用程序的成员，而 SOA 应用程序就是网格本身。因此，单独的网格组件既可以使用 Web 服务进行通信，又可以以 SOA 的方式进行交互。总而言之，网格系统可以是 SOA 本身，也可以提供服务来在其上构建应用程序级 SOA 模型。

我可以如何构建SOA系统？

利用 SOA 的好处不仅是一个软件开发流程，而且还是一个业务开发流程。采用 SOA 有四个层次，您的实现可以跨越从创建特定的软件服务到将您的业务模型全面转换到按需系统的过程。要获得进一步的信息，您应该阅读这一部分的末尾列出的文章 “The Four levels of SOA Adoption” 。

第一个层次是最简单的，因为它只需创建单独的服务。在这一部分列出的 “SOA 新手入门 ” 中对此进行了详细解释，并且提供了更多的资源。

在第二个层次中，您不仅可以创建服务，而且可以开始将业务功能集成到 SOA 中。这涉及多个层次的集成，其中包括应用程序集成、信息集成、流程集成和整个系统集成。 Migrating to a Service-Oriented Architecture 是一篇重要的文章，介绍了这个层次中的问题。

第三个层次涉及将您的企业 IT 基础设施转换到 SOA 模型，而采用 SOA 的第四个层次集中于转换您的业务模型，以使之成为按需就绪的模型。

从 IT 专业人员的角度来看（与业务层相比），要创建 SOA 应用程序，您通常将经历四个阶段：构建、部署、使用和管理。在构建阶段中，您可以定义业务模型或流程、软件模型和 SOA 模型。之后，您就可以创建一组服务，这组服务可以与已发布的通用接口一起重用。

在部署阶段，您提取创建的服务，并把它们放在一个可执行、可管理的环境之中。在使用阶段，您根据前面所讲的 SOA 和软件模型来装配应用程序，并且测试其软件质量以及非功能性需求，比如性能、可伸缩性等等。应用程序现在已经准备完毕并且可用于用户。最后的管理阶段是一个长期的过程，在这个阶段中，您可以监控并管理安全性和使用，以及在许多与您可能已经为 SOA 制订好的服务级协定或策略相对应的方面比较其性能。

这些是 SOA 的生命周期的概念阶段。为了使对应于这些阶段的实际工作角色具体化，有许多角色需要加入到 SOA 应用程序的创建之中。这些角色可能从事相同的工作，也可能跨多个团队成员甚至多个团队。在 Rational Unified Process （ RUP ）中所划分的角色非常好地表达了角色概念。

RUP 角色包括项目经理、分析员、架构师、建模人员、开发人员、测试人员以及部署和操作人员。 SOA 几乎完全照搬了这种角色划分方法，惟一不同之处在于， SOA 建模人员角色的工作是提取概念性软件模型，并且根据 IT 基础设施的 SOA 模型和资源来对其进行测试。开发人员角色还可以包括二级角色像装配人员（在使用阶段），装配人员的角色是提取单独的服务，并且根据定义好的模型构建实际的 SOA 应用程序。不管是显式的还是隐式的，这些角色都存在于支持 SOA 的企业之中。


个人体会：

    SOA 的松耦合特性能够适应业务需求的灵活性，当服务内部结构及实现发生改变时它能够继续存在从而降低了软件二次开发的成本。 SOA 就好比是一个服务中介将不同系统、不同平台上的操作通过它联系起来，而实现各种服务和数据的交互，满足市场快速变化的需求.

定义SOA
如 果您想实施SOA，首先要牢记的一点就是IT部门必须对SOA有明确的理解和定义。您可以试着询问5位IT专家，看看他们心目中的SOA到底是什么。您很 有可能会听到五种完全不同的答案。这主要是因为架构技术的发展速度太快，没有人能精确地说明最新的SOA定义究竟是什么。
但这并不是什么问题。即使IT行业无法在定义方面达成共识，也并不影响SOA的整体发展。但是，您的IT部门内部必须要达成共识，确定SOA对您所在企业的确切意义。
建议您对有关SOA的一些权威文献进行研究，并且总结出一套适合自身需求的SOA理论。您也可以咨询一些该领域的专家，让他们根据您公司的特殊需求来定义一套专有的架构。
最为关键的一点是，您的公司必须拥有一套能够自我发展的SOA定义。IT部门中的每一个人都必须充分理解这套定义，并尽全力支持这种新的架构形式。

员工培训
对许多企业而言，SOA与传统架构有着天壤之别。传统架构侧重的是各种应用间紧密连接的接口，因此员工要想理解SOA就必须经历一段艰苦的学习过程。而通过合理的培训和教育，您可以减轻员工的这种学习压力，更加自信地为SOA的实施做好准备。
建议您采用自上至下的培训顺序。首先，对高级管理人员进行培训，让他们了解SOA的基本要点，以及部署SOA后企业可能获得的利益与优势。
在完成高级管理层的培训后，接下来可以对下一级业务主管开展SOA方面的教育工作。他们不仅需要理解SOA的总体目标，还要深入理解具体实践中遇到的细节，并且需要明确知道SOA是怎样实施的。
最后，您还需要对构建和部署SOA的人员进行具体培训。这种渐进式的培训应该解决一些特定的技术问题，为企业平稳过渡到SOA架构提供有效保障。当然，这一阶段培训的工作量和精力投入都是最大的。
需要提醒您的是，早期培训并不一定会带来彻底的成功。SOA的概念对于许多IT专家来说仍然非常陌生，即便他们对其他架构研究得相当透彻，面对SOA也会显得有些不知所措。
想要理解新的规范总是很困难的。未来主义学者Joel Barker将这种症状称作“规范效应”。他解释说，多数人所感知的世界都有一定的边界。当新的理论试图对这种边界发起挑战时，人们很可能会表现出抗拒的态度，因为这些新的理论与他们原有的信仰显得格格不入。
想征服规范效应，管理层的支持和全面深入的培训必不可少。但是，千万不能灰心。员工完全可以通过再培训来接受这些新概念，在这方面已经有很多成功的先例。

建立SOA管委会
SOA的最终目标是开发出一套灵活的架构，并能够通过一个通用接口将各种离散的异型应用集成在一起。要实现这一目标，就必须设计和开发一些独立于应用的服务，并且使整个企业都能访问和共享这些服务。

为了保证独立应用和服务复用过程中企业的应用重点不发生偏移，企业有必要建立一个SOA的管制委员会。许多SOA文献和实践者将这种组织称为集成能力中心（Integration Competency Center，ICC）
在建立ICC时，有一些关键组件是必须预先考虑到的。当您在确定该中心的参与者时，应确保企业中的每个相关部门（包括IT和业务部门），都派出了掌握实权的人员参加进来。
要记住，此举的目的是减少可能出现的应用孤岛，并且提供充分的资产复用能力。因此，只有企业中所有部门都参与进来后，也就是建立一个“检查与平衡”的体系之后，这些目标才拥有实现的可能。
管理者可以委派最优秀、最机智的助理参加这个管委会，确保他们经过良好的培训，成为精通SOA的专家级人物。请注意，高级管理人员必须理解小组成员参与SOA管委会的重要性，并且愿意重新分配工作任务，使管委会的工作能够被优先处理。

学着“眼高手低”
最 后一点，也是重要的，即在实施SOA的初期不要过于热情了。因为这是一项长期工作。历史证明，在IT行业中使用轰炸式的工作方法很难奏效。小规模的渐进式 发展成功的几率却高许多，因为这种变化更易于管理。幸运的是，事实证明，渐进式的方法在实施SOA的过程中非常有效，因为这种架构允许企业一次实施一项服 务。
在开始时，可以选择一些相对比较简单的功能，也就是说风险较低、但仍然比较重要的功能。例如，从多个系统中提取和合并客户信息的功能就可以当作早期尝试的不错范例。您可以围绕该功能开发一套服务，并为整个企业提供支持。
然后，您可以开始“脱钩”不同系统中的功能，使之不再依赖点到点的接口，而是将其重新定向至全新的共享式服务。
从小处着手可以帮助您的企业在部署重大服务前进行一些初步的测试，并且对流程加以细化。例如，您可以将财务应用重新定向，让它们使用一个通用的接口。另外，这种初步的测试还能监测出企业对SOA的准备情况，以及在新架构下的应变能力

引言

目前，关于由 Service-oriented Architectures（SOA）和它的 Web 服务实现所表现的时机有许多传言 -- 有一些是有事实根据的，但是一些却没有什么事实依据。分析家已经预言，博学者已经声称，教授已经讲演，公司已经匆忙的卖他们的产品，作为 SOA 产品 -- 经常失去 SOA 不是一个产品的要点。它是业务和 IT 之间的桥梁，通过一系列使用一些设计原则、模式和技术的依赖于业务的 IT 服务来实现。

ZDNet 最近报道说，“Gartner 预言到了 2008 年，至少 60% 的企业将使用 SOA 作为创建任务苛刻的应用程序和过程的“指导原则”。

开发和实现 SOA 有很大的需求。因此如果 SOA 不仅仅和产品和帮助实现它的标准相关（比如通过 Web 服务），那么为了实现 SOA 你还需要什么附加的元素吗？ 基于服务的建模需要其他的行为和构件，这些在传统的基于对象的分析和设计（OOAD）中是不存在的。“ 基于服务的分析和设计的元素”这篇文章描述了一些最初的原因，解释了为什么你需要 OOAD 之外更多的内容。它同样描述了业务流程管理或企业架构（EA）和 OOAD 为什么不是管理分析和设计的适当手段。同样，在 IBM Redbook 中名为 “ 模式：Service-Oriented Architecture 和 Web Services”的文章中，我举例说明了基于服务的建模方法的主要活动。

然而，你还需要重视一些额外的重要的需要考虑的事项。首先，目前的 OOAD 方法没有定位 SOA 三个重要的元素： 服务， 流，和实现服务的 组件。你同样需要可以明确定位鉴别、制定和实现服务所需的技术和过程，它们的流程和组合，以及实现和确保所需服务质量的企业级组件。

第 二，需要进行范例的替换，以便更好的区分 SOA 的两个关键角色之间的截然不同的需求：服务提供者和服务消费者。第三，假设为一个企业或者业务线构建的应用程序，现在必须被提升到一个供应链中使用，并且 公开给合作伙伴，这些合作伙伴可能组合、联合和封装应用程序到一个新的应用程序中。这是服务生态系统或者服务价值网的概念。

这 是仅从“分布式对象”的一个微小的进步。它是关于通过网络作用创造的价值：例如，当合作伙伴利用了 Amazon.com 与 Google 搜索的联合，并且与 eBay 服务结合在一起，来构建他们自己的混合解决方案。或者当旅行社深入到机票预订系统，并且与汽车租赁公司以及宾馆相互协调，更新他们的记录并且将旅行计划发 送到你的电子档案中。无论什么样的应用程序，你如果想成功地创建 SOA，需要的都不仅仅是好的工具和标准。你需要一些规范的步骤来支持你的 SOA 生命周期；用来分析、设计、实现服务、流程和组件的技术。因此，对于任何对企业应用程序开发感兴趣的人来讲，理解基于服务的建模和架构中包含的细节步骤是 非常重要的。

在我详细描述这些步骤以前，我们首先应理解你打算要做什么： 什么是 SOA，以及它看起来像是什么？在 定义了 SOA 后面的概念和观点以后，我将描述 SOA 的层和你如何去记录每个层中的关键架构决策，这些层帮助你为 SOA 构建蓝图，这些 SOA 正是那些你试图同一系列实现了 SOA 服务、流程和组件集成以及出现的项目、业务线、企业级成果和价值链所需要的。

回页首

Service-Oriented Architecture：概念模型

这 个概念基于一种架构样式，该样式在三个主要参与者之间定义了交互模型：服务提供者，公布服务描述并且实现服务，服务消费者，他既可以使用统一资源标记符 （URI）来直接使用服务描述，也可以在服务注册中心来查找服务描述并且绑定和调用服务。服务代理提供和维护服务注册中心，然而现在并没有通用公共注册中 心。

图 1 是一个显示了这些关系的元模型。

回页首

架构样式和原理

定义 SOA 的架构样式描述了一系列模式和指导方针来创建 松耦合，依赖业务的服务，由于描述、实现和绑定之间关系的分离，为新业务迹象和机会提供了空前的灵活性。

SOA 是企业级的 IT 架构，用来按需连接资源。在 SOA 中，资源对于价值网、企业、业务线内的参与者时可用的（典型的是在一个企业内或多个企业之间跨越多个应用程序）。它由一系列依赖业务的 IT 服务组成，这些服务共同满足了组织的业务流程和目标。你可以将这些服务设计成合成的应用程序并且通过标准协议来调用它们，如下面的 图 2所示。

服务是一种有具体服务描述的软件资源（可发现）。服务消费者可以搜索、绑定和调用服务描述。服务提供者实现服务描述的功能并且向服务消费者提供所需的服务质量。理论上服务应该统一由公布的方针来管理，并且因此支持动态的 可配置架构样式。

灵活的业务通过灵活的 IT 系统可以实现，主要通过接口、实现和 SOA 提供的绑定（协议）的分离，基于新业务需求，允许在及时给定的点延期 选择服务提供者，（功能和非功能（例如，性能、安全、可伸缩性等）需求）。

你可以在内部业务单元之间或者在业务伙伴之间的价值链之间以 不规则的实现模式来 重用此服务。不规则的实现引用了架构样式的能力来在他的交互模型中通过合成的方式来应用与参与者关联的模式和角色。你可以在架构中的一层上应用它，也可以 在贯穿企业架构的多个层上来应用它。在项目之间，它可以通过统一的、概念上可升级的方式在价值链内部的业务单元和业务伙伴之间。

回页首

上下文

在本文中，我介绍了鉴定、指定和实现的高级别的行为和一些基于服务建模的构件。基于服务的建模是基于服务的分析和设计（SOAD）过程，来建模、分析、设计和生产依赖业务分析、过程和目标的 SOA。

首先我将看一下你想要构建什么，也就是 SOA 和它的层。接下来我将通过讨论创建 SOA 所需主要的活动和技术来描述如何构建 SOA。

作为一个示例，我们假设你正在开发一个项目，并且目标是将一部分具有自服务帐目系统的银行业务线移植到 SOA上。

为了移植到 SOA，你需要一些超出服务建模的附加元素。它们包括：

• 采用和成熟模型。在 SOA 和 Web 服务的采用上你的企业处在那个成熟的相对级别上？采用的每个不同的级别都与它自己的唯一的要求。
• 评估。你有一些领导者吗？你已经涉足 Web 服务了吗？作为结果的架构好到什么程度？你应该继续维持同样的方向吗？这将衡量企业 SOA 吗？你已经考虑了所有应该考虑的事情了吗？
• 策略和规划活动。你如何规划到 SOA 的移植？你需要考虑的步骤、工具、方法、技术、标准和培训是什么？你的路线图和远景是什么？你如何达到目的？计划是什么？
• 管理方法。现有的 API 和能力是否应该变成服务？如果不是，哪个是符合条件的？每个服务都应该以通过某种方式为业务带来价值为目的来创建。你如何样毫无妨碍的来管理这些过程？
• 实行最佳实践。什么是可靠和经过测试的方式来实现安全，确保性能，遵从互操作性标准，设计来作改变？

上 面的关于移植到 SOA 和实现以后附加活动的讨论应该得到它们自己的文章，本系列中我将在随后的列中接触到这个。目前，让我们假设你为项目定义了范围，并且决定了集中在什么地 方：已经定义了一个焦点，用来将现有的系统或服务转化到一系列新的系统和服务。现在你可以开始基于服务建模来构建你的基于服务的架构。

回页首

SOA 的一个架构模板

SOA 的一个抽象观点将它描述为与业务过程结合在一起的合成服务的部分分层架构。 图 3 呈现了这种类型的架构。

服 务和组建之间的关系是，企业级的组件（大粒度的企业或者业务线组件）实现该服务并且负责提供它们的功能和维持它们的服务质量。通过组合这些公开的服务到合 成的应用程序，就可以支持业务过程流。综合的架构通过使用 Enterprise Service Bus（ESB）支持这些服务、组件和流程的路由、中介和转化。为了服务质量和非功能性的需求，必须监视和管理已经部署的服务。

对于每一层，你都必须做设计和架构决定。因此，为了帮助用文件说明你的 SOA，你可能应该创建文档，由每个层相应的部分所组成。

这里是为你的 SOA 架构文档设计的模板：

1. 范围 <此架构适用于企业的哪个领域>
2. 操作系统层
1. 打包的应用程序
2. 自定义应用程序
3. 架构决策
3. 企业组件层
1. 企业组件支持的功能范围
2. <这个企业组件支持业务领域、目标和过程>
3. 关于控制的决策
1. <作为这个客户端组织内部企业组件来选择某物的标准>
4. 架构决策
4. 服务层
1. 服务分类表
2. 架构决策
5. 业务过程和合成层
1. 业务过程可以表现为舞蹈编排（choreographies）
2. 架构决策
1. <哪一个过程需要编排在舞蹈编排里面以及哪一个镶嵌在应用程序里面？>
6. 访问或者表现层
1. <证明这层中 Web 服务和 SOA 的含意；即便要。例如，在用户接口级别上调用 Web 服务的 portlet 的使用，以及在此层机能上的含意。>
7. 集成层
1. <包含 ESB 因素>
1. <我们如何确保使用服务的客户端系统级的一致性（SLA）和服务质量（QoS）？>
2. 安全问题和决策
3. 性能问题和决策
4. 技术和标准的局限性以及决策
5. 服务的监控和管理
1. 描述和决策

层 1：操作系统层。本层包含现有的自定义构建的应用程序，也叫做 遗留系统，包含现有的 CRM 和 ERP 打包应用程序，以及 较旧的基于对象的系统实现，还有业务智能应用程序。SOA 的复合层架构可以利用现有的系统并且用基于服务的集成技术来集成它们。

层 2：企业组件层。本层由那些负责实现功能和保持公开服务 QoS 的企业组件组成。这些特殊的组件是企业和业务单元级支持的企业资产的受管理和控制的集合。 同企业范围资产一样，他们通过架构最佳实践应用程序来负责确保 SLAs 的一致。大多数情况下，本层使用基于容器的技术，比如实现组件、负载均衡、高可用性和工作量管理的应用服务器。

层 3：服务层。业务选择来支持和公开的服务处在这一层。它们可以被 发现或 者直接静态绑定，接下来被调用，或者可能的话，编排到合成服务中。这个服务公开层同样提供了获取企业范围组件，业务单元特定组件，以及有些情况下，特定项 目组建的机制，并且以服务描述的形式具体化了他们的接口子集。因此，企业组件使用它们接口提供的功能在运行时提供服务实现。在这一层的接口公开为一个服务 描述，在这层中他们被公开以提供使用。他们可以独立存在或者作为合成服务。

层 4：业务过程合成或编排层。第三层中公开 的服务的合成和编排在这一层中被定义。通过配合、编排，服务被绑定成一个流程，并且从而作为单独的应用程序而共同作用。这些应用程序支持特殊的用例和业务 过程。这里，可视的流程合成工具，比如 IBM® WebSphere® Business Integration Modeler 或者 Websphere Application Developer Integration Edition，都可以用来设计应用程序流程。

层 5：访问或表现层。尽管这一层经常超出了 围绕 SOA 讨论的范围，但是它却变得越来越有意义。在这里我描述它因为标准越来越集中，比如用于 Remote Portlets Version 2.0 的 Web 服务和其他技术，这些技术追求在应用程序接口或者表现层来利用 Web 服务。你可以把它作为将来的层用来满足将来的解决方案的需求。注意到以下这两点是非常重要的：SOA 将用户接口从组件中分离出来；最终你需要提供从访问路线到服务或者合成服务的端到端解决方案。

层 6：集成（ESB）。这一层使服务可以集成，通过引入一系列可靠的性能的集合，比如智能路由，协议中介和其他转化机制，经常被描述为 ESB（参阅 参考资料）。Web Services Description Language（WSDL）制定了绑定，其包含提供服务的地址。另一方面，ESB 为集成提供了位置独立机制。

层 7：QoS。这 一层提供了监视，管理和维持诸如安全，性能和可用性等 QoS 的能力。这是一个通过 sense-and-respond 机制和监测 SOA 应用程序健康的工具来进行的后台处理过程，包括 WS-Management 和其他相关协议的所有的重要的标准实现以及为 SOA 实现服务质量的标准。

回页首

通过什么步骤来进行基于服务的建模和架构

本节描述了如何利用遗留的投资，来 联合自顶向下的，业务驱动的手段和自底向上的手段。

基于服务的建模手段提供了建模、分析、设计技术和活动来定义 SOA 的基础。它通过在 SOA 的每一层定义元素以及在每一层作严格的架构决策来起到帮助作用。它通过联合服务鉴别的自顶向下、业务驱动方式和通过利用遗留资产和系统引导服务鉴别来实现这一点。

这样，高级别的业务过程功能性为大粒度的服务更加的具体化。小粒度的服务 -- 这些可以帮助实现高级别的服务 -- 通过检查遗留功能性和决定如何创建适配器、封装器，或者组合遗留系统来具体化系统内经常调用的期望功能性可以来鉴别。

最后，使用 针对服务的建模，你使用 跨部分手 段来削减候选的可能已经被确定的服务的绝对数量。一个比较明智的手段应该是首先按照自顶向下来做，接下来进行目标服务建模，最后是自底向上的现有资产的遗 留分析。消息是：你将项目的范围定义至一个可管理、实现的集合越快，你就能更快的通过聚焦在关键服务来公开组成 SOA 基础的服务描述来实现价值。

这个功能性业务需求和遗留系统中现有投资利用的结合，为那些想要快速赢得和移植他们的企业到一个现代的 SOA 的组织提供了有效的解决方案。通过基于服务的集成的软件应用程序的联合因此变得具备可能性。

基于服务的集成是 Enterprise Application Integration（EAI）的一个进化，在 EAI 中，所有的连接通过位置透明的 ESB 概念被基于标准的链接替换，并提供了一系列灵活的路由、中介和转化能力。

回页首

基于服务的建模：服务的分析和设计

迄今为止，我已经通过描述 SOA 设定了阶段。我同样展示了要想构建 SOA，你需要在你 SOA 的每个层中做关键架构决策，并且你的设计必须反映一系列依赖业务的服务和关于他们如何通过编排来合成到应用程序的决策。

与对象不同，你在 SOA 中需要考虑两个观点；他们是服务消费者和服务提供者。服务代理目前不是主流，并且在后面的部分终将被涉及到。

SOA 的设计策略并不从“自底向上”开始，这是 Web 基于服务途径常有的事情。你必须记住，SOA 更加有战略意义，并更加依赖于业务。Web 服务是 SOA 的巧妙实现。许多关键的活动和决策存在不仅仅影响集成架构，而且还影响企业和应用程序架构。他们包含两个 图 4 中描述的消费者和提供者的活动.

图 4显 示了通过提供者和消费者的每个角色来管理的活动。注意，提供者的活动是消费者活动的父集（例如，提供者同样参与服务鉴别、分类等）。在许多情况下，角色的 区别来自如下的事实，消费者指定他们想要的服务，经常的搜索它，并且一旦他们确信和他们寻找的服务规范相匹配，并且是由服务提供者提供，他们就会根据需要 绑定和调用服务。提供者需要依次发布他们想要支持的服务；即在功能方面，更重要的是在消费者所需的 QoS 方面。这个在消费者和提供者之间的隐含的契约可能在 SLA 方面成熟为明确的契约；自动的或者通过业务和合法区域来处理。

上面描述的活动可以被描述为在基于服务的建模和架构方法内流动，如下面的 图 5 所示。

基于服务的建模和架构过程包含三个主要的步骤：服务，组件和流程（典型地，服务的编排）的鉴别，指定和实现。

Service 鉴别

这个过程由域分解、现有资产分析和目标服务建模的自顶向下、自底向上、中间向外技术的联合组成。在 自顶向下视图中，业务用例的蓝图提供了业务服务的规范。这个自顶向下的过程作为 域分解来被引用，域分解由业务领域到它的功能区域和子系统的分解组成，包含它的流程或过程分解成过程、自过程和高级别业务用例。很多情况下，这些用例是公开在企业边缘的业务服务，或者在贯穿业务线企业边界内所用的非常好的候选。

在过程的 从下到上的部分或者 现有系统分析中，现有的系统被分析和选择作为可行的候选，来为支持业务过程的底层服务功能性实现提供低消耗的解决方案。在这个过程中，你分析和利用了来自遗留和打包应用程序的 API、事务和模块。在有些情况下，为了支持服务的功能重新模块化现有的资产需要遗留系统的组件化。

中间向外视图由 目标服务建模组成，来验证和发现自顶向下或自底向上的服务鉴别手段中没有捕捉到的其他服务。它将服务连结到目标和子目标、关键性能指示和尺度。

服务分级和分类

这 个活动在服务被指定时开始。将服务分级为服务层次是非常重要的，反映了服务的复合或者不规则的本性：服务可以也应该由良好粒度的组建和服务组成，分级帮助 决定合成和分层，以及基于层次的相互依赖服务的协同构建。同样，它帮助减轻服务增值综合症，这种症状中，越来越多的小粒度的服务被定义、设计和部署，却缺 乏控制，导致了主要的性能、可伸缩性和管理问题。更加重要的是，服务增值未能提供服务，这些服务对业务是非常有用的。

子系统分析

这 个活动获取上面域分解过程中发现的子系统，并且指定子系统之间的相互依赖和流程。它同样将域分解过程中鉴别的用例作为子系统接口上公开的服务。子系统的分 析包含创建对象模型来表现内部工作方式，以及所包含的公开服务并且实现它们的子系统设计。这时，“子系统”的设计结构将实现为大粒度组件实现构造，在下面 的活动中实现服务。

组件指定

在下面的主要活动中，实现服务的组件的细节将指定：

• 数据
• 规则
• 服务
• 可配置概要
• 变更

服务分配

服务分配包括分派服务到目前鉴别的子系统。这些子系统具有实现了他们所公布的功能的企业组件。你经常会简单化假定，子系统同企业组件有一对一的联系。 结构化组件在你使用模式来构造 企业组件时会通过以下几点的联合的形式出现：

• 中介体
• Facade
• 规则对象
• 可配置概要
• 工厂

服务实现

这 个步骤指出实现给定服务的软件必须被选择或者自定义构建。其他可用的选项包括使用 Web 服务来集成、转化、订阅和外购不同功能。在这个步骤中，你决定哪个遗留系统模块用来实现给定的服务，以及哪个服务将从基础来构建。服务的其他实现决策不同 于业务功能包括：服务的安全、管理和监视。

事实上，项目趋向于利用任意数量的相应的努力来满足关闭的机会窗口。因此，我推荐并行的管理三个流。

自顶向下的域分解（过程建模和分解，基于变更的分析，方针和业务规则分析，领域特定行为建模（使用语法和图表））是同供组件化（模块化）和服务公开候选的现有遗留资产的分析并行控制。为了获得项目背后的业务意图和使服务同业务意图密切合作，目标服务建模可以来控制。

回页首

结束语

本 文中，我以基于服务架构、它的层和架构决策的相关类型的基础知识来开始。接下来，我通过一种方法，描写了基于服务建模的活动，以及从服务消费者和提供者角 度来看活动的重要性（服务代理将在后面的文章中涉及到）。这种方式为决定基于服务架构的三个基础方面提供了在分析和设计活动方面详细的指导：服务，流程和 实现服务的组件。我还描述了一个模板，你可以用它来在 SOA 的每个层上为你的架构进行决策。

我提到了，对于服务鉴别，自顶向下、自底向上和跨部分、目标模型分析三种手段的结合非常重要。接下来我关注了一下服务指定和实现的主要活动。

这一系列的下一篇文章中，我将应用该方法到帐户管理的空领域中，并且用例子来描述每个步骤。除鉴别、指定和实现之外，我还将讨论基于服务建模手段的其余活动，包含用来支持完整的 SOA 生命周期的部署、监视、管理和控制。

致谢

作 者希望象下面这些尊敬的同事和朋友致谢，感谢他们宝贵的建议和反馈（无特定顺序）：Luba Cherbakov，Kerrie Holley，George Galambos，Sugandh Mehta，David Janson，Shankar Kalyana，Ed Calunzinski，Abdul Allam，Peter Holm，Krishnan Ramachandran，Jenny Ang，Jonathan Adams，Sunil Dube，Ralph Wiest，Olaf Zimmerman，Emily Plachy，Kathy Yglesias-Reece，以及 David Mott。

回页首

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
  
  
• 阅读这篇文章“ 面向服务的分析与设计原理”，（developerWorks，2004 年 6 月）获取关于 SOA 项目的学科间建模手段的信息。
  
  
• 阅读“ 模式：基于服务的架构和 Web 服务”红皮书，SG24-6303-00，2004 年 4 月，Endrei M.， et al。
  
  
• 访问 WebServices.Org ™ 来查找关于 Goal-oriented approach to enterprise component identification and specification 的更多信息，Communications of the ACM，2002 年 10 月，K. Levi，A. Arsanjani。
  
  
• 获取 Ali Arsanjani，James J. Alpigini 和 Hussein Zedan 所著的 Externalizing Component Manners to Achieve Greater Maintainability through a Highly Re-Configurable Architectural Style。Proceedings of the ICSM: 628-. IEEE Press 2002。
  
  
• 访问 Ali Arsanjani 的模式和最佳实践网站来获取 The Enterprise Component Pattern 的更多信息，proceedings of pattern languages of programming 2000。
  
  
• 阅读 Patterns: Implementing an SOA with the Enterprise Service Bus“红 皮书，SG24-6346-00，August 2004，Martin Keen，Susan Bishop，Alan Hopkins，Sven Milinski， Chris Nott， Rick Robinson， Jonathan Adams， Paul Verschueren。
  
  
• 使用 快速启动 Web 服务访问 Web 服务知识、工具和技能，它提供了最新的基于 Java 的软件开发工具和来自 IBM 的中间件（试用版），以及在线教程和文章和在线技术论坛。
  
  
• 通过参与 developerWorks blogs 来加入到 developerWorks 社区。
  
  
• 访问 Developer Bookstore 以获取综合性的技术图书列表，其中包括数以百计的 Web 服务主题。
  
  
• 想获取更多信息吗？developerWorks 的 SOA 与 Web 服务专区拥有许多提供信息的文章和关于如何开发 Web 服务应用程序的入门级、中级的和高级教程。

最初的面向服务的体系结构（Service-Oriented Architecture，SOA） 的实现项目的经验表明，诸如面向对象的分析与设计（Object-Oriented Analysis and Design，OOAD）、企业体系结构（Enterprise Architecture，EA）框架和业务流程建模（Business Process Modeling，BPM）这样的现有开发流程和表示法仅仅涵盖了支持目前出现在 SOA 中的体系结构模式所需的部分要求。

在 Info World 最近的访谈（请参见 参考资料）中，Grady Booch 宣称“像对问题的良好抽象和良好的分离这样的工程基础决不会过时”，不过，他也指出“还是有现实的机会提升抽象的级别。过去的经验表明，必须将抽象的级别提升到公司处理的 业务领域，从而将整个企业 IT 前景都纳入考虑的范畴。

正如 Mark Colan 在文章 “面向服务的体系结构扩展 Web 服务的前景，第 1 部分”中介绍的，SOA 是一种新兴的企业结构形式，可以用于设计下一代企业应用程序。SOA 方法在有力地加强已经制定的良好通用软件体系结构原则（如信息隐藏、模块化和问题分离）的同时，还增添了一些其他的主题，例如服务编排、服务库和服务总线中间件模式。

需要结构化方法或 分析与设计方法来设计高质量的 SOA。因为现有的方法中没有一种能够满足程序设计人员对最新的 SOA 项目的要求，所以他们建议将已经形成的良好实践（如 OOAD、EA 和 BPM）中的原理组合起来，并且使用根据需要创新的原理来对其加以补充。

引言

面向服务的体系结构（SOA）和 Web 服务的基本观念是成为我们日常语言的一部分，并可看作是适于设计现代企业应用程序的体系结构形式。在这种背景下， 什么构成好的服务这个基本问题就成为确保成功实现 SOA 的关键。

像 面向对象的分析与设计（Object-Oriented Analysis and Design，OOAD）、 企业体系结构（Enterprise Architecture，EA）框架和 业务流程建模（Business Process Modeling，BPM）这样的现有建模规则为我们提供了高质量的实践，可以长期帮助标识和定义体系结构内的适当抽象。然而经验表明，这些实践各自单独应用时达不到要求。

在本文中，我们将研究 OOAD、EA 和 BPM 中的适当原理。我们还将推动对混合方法的需求，这种方法把所有这些规则中的原理与许多独特的新原理组合起来。这样得到的交叉学科 OOAD 方法使成功地进行 SOA 开发更容易，我们称之为 面向服务的分析与设计（Service-Oriented Analysis and Design，SOAD），它还有待正式定义。我们还只是刚刚跨入 SOAD 的殿堂。

回页首

面向服务的概念

在发现新的商机或威胁的预期下，SOA 体系结构形式旨在提供企业业务解决方案，这些业务解决方案可以 按需扩展或改变。SOA 解决方案由可重用的服务组成，带有定义良好且符合标准的已发布接口。SOA 提供了一种机制，通过这种机制，可以集成现有的遗留应用程序，而不管它们的平台或语言。

从概念上讲，SOA 中有三个主要的抽象级别：

• 操作：代表单个逻辑工作单元（LUW）的事务。执行操作通常会导致读、写或修改一个或多个持久性数据。SOA 操作可以直接与面向对象 (OO) 的方法相比。它们都有特定的结构化接口，并且返回结构化的响应。完全同方法一样，特定操作的执行可能涉及调用附加的操作。
• 服务：代表操作的逻辑分组。例如，如果我们将 CustomerProfiling视为服务，则 按照电话号码查找客户、 按照名称和邮政编码列出顾客和 保存新客户的数据就代表相关的操作。
• 业务流程：为实现特定业务目标而执行的一组长期运行的动作或活动。业务流程通常包括多个业务调用。业务流程的例子有： 接纳新员工、 出售产品或服务和 完成订单。

  在 SOA 术语中，业务流程包括依据一组业务规则按照有序序列执行的一系列操作。操作的排序、选择和执行称为服务或流程 编排。典型的情况是调用已编排服务来响应业务事件。

回页首

为什么 BPM、EA 和 OOAD 还不够？

早期的 SOA 实现项目经验表明，诸如 OOAD、EA 和 BPM 这样的现有开发流程和表示法仅仅涵盖支持 SOA 范式所需的部分要求。SOA 方法在加强已经制定的良好通用软件体系结构原则（如信息隐藏、模块化和问题分离）的同时，还增添了附加的主题，例如， 服务编排、 服务库和 服务总线中间件模式，在建模时需要对它们给予特别的关注。

图 1展示了现有的 EA、BPM 和 OOAD 建模方法的主要应用领域，也是我们随后讨论 SOAD 的出发点。图中的水平轴表示 项目生命周期阶段；垂直轴表示不同抽象层或 领域之间的区别，而建模活动通常就是在其上进行的。

SOA 的远景是相当容易理解的，因为它的技术基础众所周知。例如，在任何 SOA 工作中，应用通用的软件体系结构原则和 OO 技术都是一个有效的开端。然而，正如我们已经提到的，早期采用者最常询问的问题是如何标识正确的服务。如前所述，OOAD、EA 和 BPM 在各自独立地应用时不能提供满意的答案，而这正是我们现在要说明的。

在由 Booch 和 Jacobson撰 写的开创性的书（大约 10 年前出版的）中介绍的 OOAD 方法在定义 SOA 方面提供了非常好的起点。同样地，虽然许多年来在体系结构层次中应用 OOAD 技术和统一建模语言（Unified Modeling Language，UML）表示法是一个常见的实践，但是 OOAD 还是与像类和单独的对象实例这样的微观层次的抽象有关。由于每个问题域常常都创建单独的用况模型，因此，应用程序开发项目，这个企业的大方向在许多情况下 变得模糊。此外，由于种种原因，用况模型并不总是与其对等的 BPM 保持同步。

诸如 Treasury 企业体系结构框架（Treasury Enterprise Architecture Framework，TEAF）、 面向特征的领域分析（Feature-Oriented Domain Analysis，FODA）和 Zachman这样的 EA 方法都将城市规划级的观点加在解决方案体系结构之上，但是并没有解决如何找到易于重用且具有持久性的高质量企业抽象的问题。

虽然 BPM 方法（如 BPMI）在功能工作单元之上提供了端到端视图，但是它们通常都没有触及体系结构和实现领域。例如，在像 用于 Web 服务的业务流程执行语言（Business Process Execution Language for Web Services，BPEL）这样的语言出现之前，BPM 表示法缺少操作语义。此外，我们还看到了许多流程建模与开发活动彼此分离的情况。

最后，现有的规则中没有一个可以解决如何为 SOA 启用 现有的应用程序的问题；大部分时间都采用自顶向下流程。现有的系统通常都存放有大量的重要数据和业务逻辑，并且不能简单地加以替代。因此，为了研究包装和重构策略，必须对这些系统进行自底向上的分析。因此，对现有应用程序的考虑会将我们带到中间相遇的流程。

由于这些原因的存在，所以需要混合 SOAD 建模方法。这种方法以最佳的方式组合了 OOAD、BPM 和 EA 中的原理，并且融入了一些具有创新性的原理。 图 2展示了这种新的方法的 SOAD 资源（原理和技术）：

EA

将企业应用程序和 IT 基础设施发展成 SOA 可能是一个大的负担，会影响多个业务线和组织单元。因此，需要应用 EA 框架和参考体系结构（如 开放组织体系结构框架（The Open Group Architecture Framework，TOGAF））以及 Zachman，以努力实现单独的解决方案之间体系结构的一致性。

根 据过去的经验，大多数现有的 EA 框架都在一个或多个方面有限制。例如，如果主要的问题是表示技术设备的低级构块如何在宏观层次互连，则无法获得业务层流程或服务视图。然而，在 SOA 的背景下，这种考虑问题的方式必须转换为以表示业务服务的逻辑构件为中心，并且集中于定义服务之间的接口和 服务级协定（Service Level Agreements，SLA）。

此外，许多企业级参考体系结构和框架是相当普通的，并没有触及设计领域。这样的高级体系结构无法为架构师和开发人员提供具体的战术意见，并且常常导致企业体系结构和解决方案体系结构之间出现根本性的分歧。

SOAD 必须帮助 SOA 架构师定义服务前景的整体业务级视图。这是当今的 EA 框架所无法提供的，它们需要未来特定于 SOA 的增强； 按需操作系统（On Demand Operating Environment，ODOE）是 IBM 针对这种趋势制定的主要战略。

BPM

BPM 是一个不完整的规则，其中有许多不同的形式、表示法和资源。另一种常用的技术是定义表示概念性流程流的 事件驱动流程链，正如 Barker 和 Longman所定义的。这第二种技术使用了不同于 UML 的表示法。

此 外，还有许多专用方法（如 BPM 技术）可能被咨询公司和企业资源规划（Enterprise Resource Planning，ERP）软件包厂商视为具有竞争优势。ARIS Implementation Platform 就是这样的产品的一个例子。其他的方法包括： Line of Visibility Enterprise Modeling(LOVEM) 和 IBM 的组件业务建模（Component Business Modeling，CBM）战略。

最近的趋势是定义表示可执行流模型（如 用于 Web 服务的业务流程执行语言（Business Process Execution Language for Web Services，BPEL））的标准方法。BPEL 将流程的范围从分析扩展到实现。这样的可执行模型引发了一系列的新问题，其中包括：

• 哪些方面应该用 BPEL 描述，哪些方面应该用 WSDL 描述？流程模型和传统的编程模型之间的区别在什么地方？
• 如何将非功能性要求和服务质量特征这样的方面加入模型之中？
• 同更传统的编码（例如在 J2EE 中）相比，在 BPEL 引擎的编程语言扩展中执行多少逻辑？
• 如何评定可执行流程模型的质量，其应用的最佳实践是什么？
• 什么工作角色进行 BPEL 流管理；是业务专家（分析人员），还是开发角色（软件架构师）？

必须利用所有现有的 BPM 方法作为 SOAD 的起点；然而，必须使用流程模型中用于驱动 候选服务和它们的操作的附加技术来对其加以补充。此外，SOAD 中的流程建模必须与设计层用况建模保持同步，并且必须给出与 BPEL 有关的问题的答案。

OO 范式与面向服务 (SO) 范式

OO 分析是一种非常强大且广为赞誉的方法，同样，SOAD 应该尽可能多地利用 OO 分析技术。要将 OO 分析成功地应用于 SOA 项目，您就必须一次分析多个系统。用况模型必须继续扮演重要的角色。然而，SOAD 必须主要是 流程，而不是 用户驱动的。因此，SOAD 需要 BPM 和用况建模活动之间的强链接。

在 设计层， OO 的目标是能够进行快速而有效的设计、开发以及执行灵活且可扩展的应用程序。对象是软件构造，其行为就像它们建模的真实世界的实体。例如，顾客 (Customer) 将有名称和联系信息，并且还可能有一个或多个与之相关的帐户对象。从 OO 的角度看，每件事情都是对象。

OO的基本原则是：

• 封装：软件对象就是包含模拟真实世界的对象的物理属性（数据）和功能（行为）的离散包。例如，帐户对象保持收支平衡并且包含平衡中的借贷机制。
• 信息隐藏：结构良好的对象有简单的接口，并且不向外界显漏任何内部机制。真实世界信息隐藏的例子是，您不需要详细了解汽车的工作原理就能够驾驶它。
• 类和实例： 类是定义特定类型的软件对象具有什么类型的属性和行为的模板，而 实例是具有这些属性值的个别对象。创建类的新实例称为 实例化。利用生物学进行类比，人就是一个类。所有的人都具有一些属性，比如身高、体重、头发和眼睛颜色等等。我们中的每个人都是这个类 HumanBeing 的实例，具有一些特定的身高、体重以及其他的属性值。类是一直存在的，而实例具有有限的生命周期。
• 关联和继承： 在 OO 中，表达类和对象之间的关联的能力是一个关键的概念；继承是关联的强形式，用于表达有关系：按照同样的方式，生物物种由这样的层次构成：界 (Kingdom)、门 (Phylum)、纲 (Class)、目 (Order)、科 (Family)、类 (Genus)、种 (Species)。我们常常发现软件对象的自然层次。例如，当您创建一个财务应用程序实体时，您可能需要构造像 经常帐户（CheckingAccount） 、 储蓄帐户（SavingsAccount） 和 贷款帐户（LoanAccount） 这样的对象。如果您看得更仔细一点（请参见 图 3），您将发现这些类共享许多属性，比如都有收支平衡帐户、借方帐户和贷方帐户等等
  图 3. UML 类继承示例
  
  与其重复定义和管理这些属性的代码，不如创建一个通用的 帐户（Account） 类，该类具有现金收支平衡并且可以处理借贷事务。所有其他的类都是这个 帐户（Account） 对象的专门形式。例如， 贷款帐户（LoanAccount） 将在零和某个约定的最大值之间具有负平衡，而 储蓄帐户（SavingsAccount） 将具有负平衡，并且将展示增加利息的行为，等等。
• 消息传递：为了完成一些有用的工作，软件对象需要相互通信。它们通过相互发送消息来这样做。例如，假定我们想将 $1000 从经常帐户转到储蓄帐户，要达到此目的，可以将带有参数 $1000 的 借消息发送到 经常帐户（CheckingAccount） 实例，并且将相应的 贷消息发送到 储蓄帐户（SavingsAccount） 实例。当实例接收消息时，它执行相应的功能，称为 方法，它有与消息相同的名称。
• 多态：这个术语描述两个或两个以上的类接受相同的消息但是以不同的方式进行实现的情况。例如， 自由经常帐户（FreeCheckingAccount） 实例和 经常帐户（CheckingAccount） 实例将响应 借 ($100) 消息，但是 自由经常帐户（FreeCheckingAccount） 实例将正好 $1000 记入它的帐户平衡的借方，而 经常帐户（CheckingAccount） 实例将 $1000 加上交易费记入它的帐户平衡的借方。

OO 支持应用程序分析、设计和开发的完整生命周期：

• OOAD试图找到最优的对象和最自然的类继承来实现它们。
• OO 开发集中于应用程序的渐进式开发，每次实现一个业务场景或用况。像 IBM WebSphere Studio Application Developer 这样的工具有助于开发人员快速地构造和测试 OO 应用程序。
• OO 运行时环境，例如由 Java 虚拟机提供的，提供应用程序服务（如垃圾收集（删除因使用它们的对象已经被丢弃而不再使用的资源））以及框架（如 J2EE）来为驻留在不同的服务器上的对象提供相互通信的机制。

目前与 SO 有关的 OO 设计实践的主要问题在于，它的粒度级别集中在类级，对于业务服务建模来说，这样的抽象级别太低了。诸如继承这样的强关联产生了相关方之间一定程度的 紧耦合（因而具有依赖性）。与此相反，SO 范式试图通过 松耦合来促进灵活性和敏捷性。目前，在 SOA 中还没有服务 实例的跨平台继承支持和一流的表示法来避免需要处理服务生命周期维护管理问题（如远程垃圾收集）。

这 些考虑事项使 OO 难以与 SO 体系结构样式直接保持一致。然而，对于设计已定义的服务中的底层类和组件结构，OO 仍然是一种有价值的方法。此外，许多 OOAD 技术（例如类、责任、协作（CRC）卡）也可以用于服务建模（如果它们提升到更高层次的抽象的话）。在本文后面，我们将回过头来讨论这一点。

图 4展示了可见性层次和 OO、 面向组件和 SO 设计提供的重点之间的对应关系。它还展示了在 SOA 和 SOAD 背景中它们之间的相互关系。

至于表示法，统一建模语言（Unified Modeling Language，UML）——通过一些附加的定型（Stereotype）和概要加以增强——自然成为 SOAD 的重要基础。

在使用 Rational Unified Process (RUP)—— 被认为是支持迭代软件开发的分析与设计的主流 OOAD 流程之一——的流程方面，使用 UML 模型具有首要价值。然而，RUP 以 OOAD 的原则为基础，因而使其不容易与 SOA 设计保持一致。从 RUP 的角度来看，系统的体系结构是其通过已定义接口交互的主要组件的体系结构。此外，这些组件还由逐渐减小到类级粒度的更小组件组成。相反，在 SOA 中，系统的体系结构通常包括满足普通 业务服务需要的无状态、全封装且自描述的服务组成，它更接近于映射到 BPM，如 图 5所示。

这些服务可能包括许多协作或编排服务。这并没有排除 RUP 采用的 OO 观点，而是在其上实现了另一个抽象层。这个超层的作用是封装作为正式的跨层接口结构中的 RUP 构件（ 软件服务）设计的组件。

回页首

SOAD 原理

在这一部分中，我们将更详细地描述 SOAD 的需求，并且开始确定它的主题和原理。目的是将关于这个主题的讨论引到进一步的设计工作。进一步的工作无疑需要形式化 SOAD 方法。

SOAD 必须提供什么？

已经为 SOAD 确定了下列需求：

• 正如任何其他的项目和方法一样，必须正式（至少半正式）地定义 流程和 表示法。通过选择和组合 OOAD、BPM 和 EA 原理，就可以在需要时确定额外的原理。
• 必须有结构化的方法来概念化服务：
  • OOAD 为我们提供了应用程序层上的类和对象，而 BPM 具有事件驱动的流程模型。SOAD 需要将它们结合在一起。
  • 方法不再是面向用况的，而是由业务事件和流程驱动的。用况建模是在更低的层次上作为第二步进行的。
  • 方法包括语法、语义和策略。这就需要特别的组合、语义代理和运行时发现。
• SOAD 必须提供定义良好的品质因素和最佳实践（例如回答粒度问题）。必须回答 BPEL 提出的角色问题。例如，谁为哪部分工作负责：是开发人员、架构师，还是分析人员？
• SOAD 活动还必须回答这样的问题：什么 不是好的服务？例如：不可重用的任何东西都不可能成为好的一流 SOA 成员（即服务）。另一个例子就是带有挑战性的非功能要求的嵌入式实时系统，它们不能承受任何 XML 处理开销。
• SOAD 必须易于进行端到端建模，并且有全面的工具支持。假如 SOA 给业务带来了灵活性和敏捷性，就应该对从企业到体系结构和应用程序设计领域产生的支持方法有相同的期望。

品质因素

一些通用原则或品质因素已经确定，并且可以作为 SOAD 中的设计基准：

• 构思良好的服务给业务带来了灵活性和敏捷性；它们通过松散耦合、封装和信息隐藏使重构更加容易。
• 设计良好的服务是有意义的，并且不只适用于企业应用程序；服务之间的依赖性减到最少，并且是显式声明的。
• 服务抽象是内聚、完整和一致的；例如，在设计服务和它们的操作签名时应该考虑 创建（Create）、 读取（Read）、 更新（Update）、 删除（Delete）和 搜索（Search）(CRUDS) 隐喻。
• 常常声明的假定是，服务是无状态的（例如非对话式的）；为了要求服务在特定的问题域和上下文中是无状态的，将削弱这种声明。
• 领域专家无需深奥的专业知识就可以理解服务命名。
• 在 SOA 中，所有的服务都遵循相同的设计体系（通过模式和模板连接的）和交互模式；底层体系结构形式可以容易地标识（例如在体系结构复审期间）。
• 服务和服务使用者的开发除了领域知识之外只需要基本的编程语言技能；中间件专业知识只有少数的专业人员才需要，在理想的情况下，这种知识是为工具和运行时厂商所用，而不是为制作像 SOA 这样的企业应用程序的公司所用。

服务标识和定义

自顶向下的业务级建模技术（如 CBM）可以为 SOA 建模活动提供起点。但是正如我们在前面提到的，SOA 实现很少是在全新的项目中开始的；创建 SOA 解决方案几乎总需要涉及集成现有的遗留系统，方法是将它们分解成服务、操作、业务流程和业务规则（同时参见 图 6）：

• 将现有的应用程序和厂商软件包分解成表示相关操作组的离散服务集（自底向上方法）。
• 从应用程序中将业务流程和规则抽象为由业务编排模型管理的单独 BPM。

所有的 OOAD 都同标识和定义服务有关；但是还需要具有更高层的观点。此外，当 SOA 致力于比经典开发项目层次更高的开发时，就有了发挥其他创造性思维的空间。

直接和间接业务分析
通过项目相关人员的会谈和 CBM 来进行 BPM 和 直接需求分析是一个容易理解且非常合适的标识候选服务的方法。

过去的经验表明，这条主要的途径应该通过补充 间接技 术来加以改进。在选择候选服务时，产品经理和其他业务领导应该进行协商。例如，什么是计划付款和开票模型？应该商议假定使用正在构建中的系统的企业的组织 结构图。建议还考虑一下非 SOA 项目中任何现有的用况模型。用于对正在构造的系统进行营销介绍的术语是另一个很好的关于服务操作候选者的来源（特别是动词，很少关注营销动词！）。

域分解
在 Endrei中定义的域分解、子系统分析、目标模型创建和相关技术是 SOA 流程构造方法或 服务概念化框架（它是基于 Levi and Arsanjani先前完成的工作构建的）最有希望的提议。来自 SEI的 FODA 工作也为这方面的讨论做出了贡献。

服务粒度
选择正确的抽象级别是服务建模的一个关键问题。您常常会听到 进行粗粒度建模的建议。这有点过于简单化了。您应该将其改为在不损失或损害相关性、一致性和完整性的情况下 尽可能地进行粗粒度建模。在任何 SOA 中，都有细粒度服务抽象的空间（假定有业务要求的话）。由于 SOA 并不等同于 Web 服务和 SOAP，因此可以使用不同的协议绑定来访问抽象级别不同的服务。另一种选择就是将一些相关的服务捆绑成粗粒度的服务定义，这是门面模式的变种。

命名约定
应该定义企业命名模式（XML 名称空间、Java 包名、Internet 域）。简单的例子就是始终用名词来命名服务，而用动词来命名操作。这种最佳实践来源于 OOAD 空间。

第一类 SOAD 原理

除了组合 OOAD、BPM 和 EA 技术之外，还有几个重要的 SOAD 概念和方面有待充实：

• 服务分类和聚合
• 策略和方面
• 中间相遇流程
• 语义代理
• 服务获取和知识代理

服务分类和聚合
服务有不同的用法和用途；例如，软件服务可以不同于业务服务（如前面的 图 5所示）。此外，还可以将原子服务编排成级别更高、功能齐全的服务。

服务组合可以通过可执行模型（如 BPEL 建模的模型）来加以简化；这是传统的建模工具和方法不能处理的事情。

策略和方面
服务具有语法、语义和 QoS 特征，所有这些都必须进行建模；正式的接口契约必须涵盖的比 Web 服务描述语言（Web Services Description Language，WSDL）的多。因此， Web 服务策略（WS-Policy） 框架是一个重要的相关规范。

除了已经制定的良好 体系结构可跟踪性原则之外， 业务可跟踪性也是一个理想的品质：应该有可能将所有的运行时构件直接与非技术领域专家可以理解的语言联系起来。这对于直接在业务和服务层公开的抽象非常重要。Sarbanes-Oxley (SOX) 法案（请参阅来自 Astor的文章）是需要这种业务可跟踪性的业务驱动程序的一个例子。

流程：中间相遇
在真实世界中，并没有全新的项目，必须始终考虑遗留系统（ 遗留系统是现有系统的同义词）。因此，需要 中间相遇的方法，而不是单纯的自顶向下或自底向上的流程。

在 设计取决于现有的 IT 环境而不是现在和将来的业务需要的情况下，自底向上的方法往往会导致不好的业务服务抽象。而自顶向下的方法可能会产生不足的非功能性需求特征，并且损害其 他的体系结构品质因素（例如因域模型中缺乏标准化而导致的性能问题），另外，也会在服务和组件中产生不匹配的不良问题。

服务获取和知识代理
这是一个知识管理和生命周期问题：如何成功地准备好服务并且使其在概念化之后可以重用？

应该将重用看作是标识和定义服务最主要的推动标准之一。如果组件（或服务）不可能重用，就不无法将其作为服务进行部署。它可以连接到另一个与企业体系结构相关的服务，但是不能单独作为一个服务而存在。

然而，即使从开始就计划好了重用，还必须形式化服务获取流程。由多个使用者使用服务是明确的 SOA 设计目标。构建时服务注册中心（例如企业 UDDI 目录）可能能够解决部分问题。

回页首

示例：汽车工作订单

汽车工作订单（Automotive Work Order）描述了一家汽车维修公司管理其顾客运营的流程。我们将通过这个领域中的问题来阐述 SOAD 的观点。

工作订单代表汽车服务公司和顾客之间的约定，以进行一系列例行维修或应急维修，例如例行 50,000 英里服务，更换刹车片或轮胎，或者换油。

业务场景（如 图 7所示）如下：

• 当顾客打电话预约时创建工作订单。
• 为每个计划的维修活动或操作创建一个独立的工作订单项，其中包括需要使用的零件、备件和劳务的详细情况。
• 在安排预约之前确保所有必需的零件都有库存。
• 需要为每个工作订单项安排具有适当的装备的维修间以及具备适当的条件的机器。
• 计算估计的总成本，接着顾客认可该预约；或者方案终止，随即取消工作订单。
• 在预约之前，立即在选定的维修间装配必需的零件、备件、工具和设备。
• 当顾客到达时，进行计划的活动以及在检查交通工具时显得有必要的任何其他活动。
• 记录所用的零件和备件的实际价值以及劳务。
• 在完成所有的维修时计算总费用。
• 创建发票并且将其交给顾客。

如果您将此作为一个独立的应用程序从头开始创建，您就可能创建一组如 图 8所示的类。

如果您将工作订单构造为一个 OO 应用程序，这些软件对象将包含所有必需的业务规则，并且理解应该遵循的业务流程。

然而，这种方法在实践方面存在着一些缺点：

• 许多步骤涉及与现有遗留系统和数据库（例如帐单编制、日程安排以及库存系统）的连接，它们不可能遵循 OO 范式进行设计（在这样的情况下，应用适配器或仲裁器会有所帮助）。
• 为了使系统尽可能地灵活，将一些规则外化是有帮助的，这样就可以在不更改代码的情况下修改流程或工作流。例如像下面这样的规则：
  • 标准的 24,000 英里服务包括四公升油。只是在使用四升以上的油或顾客要求优质油（如合成油）时才应该收取额外的邮费。
  • 在遗留应用程序中有一套工业标准为普通汽车维修活动进行劳务估价。除非维修人员收取的费用超过该估价的 X% 并且报告产生差别的有根据的原因，否则顾客就应该支付标准的劳务费。
  • 如果超过估价的 Y% 以上，就应该联系顾客以进行确认。

SOAD 为这些问题提供了极好的解决方案。由于它基于相关的行为对服务进行分组，而不是进行封装（行为及数据），所以这组服务与业务对象略有不同。

例 如，您可能将工作订单（Work Order）和工作订单项（Work Order Item）一起分到工作订单服务（Work Order Services），并且创建日程安排（Scheduling）、目录（Catalog）和库存（Inventory）服务。另外，因为没有服务实例，所 以没有与服务之间的关系等价的东西。工作订单的服务模型可能看起来如 图 9所示。

与 OO 范式不同，这个模型并不表示功能系统。既没有考虑流，也没有描述业务事件或规则。在 SOA 范式中，在服务外面维护的业务流程编排决定了执行服务调用的顺序和时间。

从概念上讲，从第一次顾客联系到完成工作和帐单支付的整个业务表示单个宏观层次的工作单元，并具有数天到数周不等的生命周期。毕竟，从企业的角度来看，工作单元会产生收入。

然而，实际出现的情况是在一段相对长的时间内单独发生的一系列集中活动，例如，定义活动、安排预约、选择零件和备件、进行维修活动等等。在 IT 系统中，没有实际的 流程会持续几分钟以上；事件之间的业务流程状态以数据的形式保存在数据库中。

这种类型的流程可以用状态转换模型（例如 UML 中可用的）很好地进行表示。 图 10显示了用有限状态机（finite-state machine）方法如何对业务流进行建模的示例。它是在业务流程进行时工作订单的状态如何改变的高级视图。

业务流程编排集中于状态之间的这些转变。单独的操作永久地记录相关的状态改变。

图 11显示了部分编排的示例，其中包括 图 10所示的业务场景中的步骤 1 到 5（例如，顾客定义他们的交通工作所需的工作，并且安排预约以进行实施）。

回页首

总结和展望

在 本文中，我们已经讨论和激发了对创新的中间相遇的方法的需求，这种方法搭建了业务和 IT 之间的桥梁，并且支持 SOA 项目的分析和设计阶段。我们还提议将这种新的交叉学科的 SOAD 方法作为一个整体的建模规则，它以现在构建良好且广为赞誉的 OOAD、EA、和 BPM 为基础。

在详细定义 SOAD 表示法和流程的同时，还确定了关键的原理，比如服务概念化（或标识）、服务分类或聚合、策略和方面、中间相遇流程、语义代理和服务获取（以供重用）。

SOAD 需要增强现有的软件开发方法，进一步提高企业应用程序开发项目的可用性和适用性。随着时间的推移，还将发展相关的最佳实践。

我们还认识到，UML 在流程的表示法选择方面将继续占支配地位；可能需要进行增强以满足更广泛的 SOAD 的要求。

完成 SOAD 方法的下一步就是定义所需的端到端流程和表示法，复审活动中的角色和它们的责任，并且继续检查所提议的方法在项目中的有效性。

回页首

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
  
  
• 请访问 IEE Xplore 站点以获得由 Ali Arsanjani 撰写的 A Domain-Language Approach to Designing Dynamic Enterprise Component based Architectures to Support Business Services。
  
  
• 要获得更多关于 Sarbanes-Oxley and Web Services的信息，请访问 SYS-CON 站点。
  
  
• 在 Amazon.com 上获得由 Barker 和 Longman 撰写的 CASE Method - Function and Process Modeling。
  
  
• 在 Addison Wesley 站点获得由 Grady Booch 撰写的 Object-Oriented Analysis and Design with Applications。
  
  
• 在 BPMI.org 上查阅 Business Process Management Initiative。
  
  
• 阅读 面向服务的体系结构扩展 Web 服务的前景，第 1 部分（ developerWorks，2004 年 4 月）。
  
  
• 阅读 Endrei M. 等撰写的 Patterns: Service-oriented Architecture and Web Services 红皮书（SG24-6303-00，2004 年 4 月，Endrei M.）。
  
  
• 在 Carnegie Mellon University Software Engineering Institute (SEI) 站点上学习更多关于 Feature-Oriented Domain Analysis的知识。
  
  
• 访问 InfoWorld.com 以获得更多关于 Interview with Grady Booch的信息。
  
  
• 阅读 Object-Oriented Software Design : A Use Case Driven Approach。
  
  
• 查阅由 Ali Arsanjani 撰写的 A goal-driven approach to enterprise component identification and specification。
  
  
• 阅读由 F. Leymann、D. Roller 和 M.T. Schmidt 撰写的 Web Services and Business Process Management（IBM Systems Journal，2002 年第 2 期第 41 卷）。
  
  
• 了解更多关于 Rational Unified Process (RUP)的信息。
  
  
• 要获得更多关于 Treasury Enterprise Architecture Framework (TEAF)的信息，请访问 Software.org 站点。
  
  
• 访问 Open Group 站点以获得更多关于 The Open Group Architecture Framework (TOGAF)Version 8.1 的信息。
  
  
• 获得关于 Web 服务策略框架的信息： Web 服务策略（WS-Policy）框架。
  
  
• 了解更多关于 IBM 的 on demand Operating Environment的信息。
  
  
• 在 Zifa.com 查阅关于用于企业体系结构的 Zachman 框架的信息。
  
  
• 在 Developer Bookstore购买涉及各种各样的技术主题的打折书。
  

回页首

作者简介

		Olaf Zimmermann 是 IBM worldwide Applied Web Services 组的顾问 IT 构架师。他在分布式计算、面向服务体系结构、Web 服务/XML 和 J2EE 方面颇有专长。在过去的几年里，Olaf 指导了大量与 Web 服务有关的交流项目，包括几本产品参考书。他是 Springer 教科书 Perspectives on Web Services（ISBN 3-540-00914-0）的作者。他还参与了几本 IBM ITSO 红皮书（比如 Web Services Wizardry with WebSphere Studio Application Developer（SG24 -6292-00））的写作。Olaf 从 1994 年开始就与 IBM 合作，涉及的领域非常广泛，其中包括产品开发、技术预售咨询、教学以及系统集成。Olaf 在位于德国 Braunschweig 的 Technical University 获得计算机科学学位。您可以通过 ozimmer@de.ibm.com与他联系。

		Pal Krogdahl 是一名解决方案架构师，在 IGS 的 IBM Business Consulting Services（位于瑞典）工作。他从 1998 年开始就职于 IBM，涉及了多个领域，比如软件开发、售前技术咨询和解决方案体系结构。他擅长的领域包括分布式计算、中间件和应用程序服务体系结构，主要集中在 EAI 和 SOA。Pal 最近撰写了一些范围广泛的文章，探讨的主题有基于 SOA 的 EA、以及它们与 IBM 用于电子商务和按需操作系统环境的模式的关系。到目前为止，他已经完成了 IBM International Technical Support Organization 的一些高级培训，在该组织中，他同人合著了一些与 WebSphere 有关的红皮书，这些红皮书主要集中在 Web 服务和 SOA 方面，例如 Patterns: Service-Oriented Architecture and Web Services(ISBN 073845317X)。在过去的 18 个月里，他一直在向 IBM 内外的技术人员介绍 Web 服务和基于 SOA 的按需操作环境的实现方面的知识。您可以通过 pal.krogdahl@se.ibm.com与他联系。

		Clive Gee 是一名高级解决方案架构师，工作在 IBM Enterprise Integration Services 部。他于 1976 年加入 IBM Europe 并于 1997 年调到 IBM US。1990 年，作为创立 IBM European Object Technology Practice 的一员，他是 IBM 中第一位 OO 的支持者。从那以后，他获得了领导企业 OO 交流项目的大量实践经验，涉及多个行业（如公用事业、金融业、运输业、零售业和电信业）的复杂系统集成和应用程序开发。目前，他正忙于为一个重要的美国客 户配置部署 SOA 解决方案。Clive 从苏格兰的 University of Stirling 大学获得理论物理博士学位。您可以通过 clive@us.ibm.com与他联系。

　　基于SOAP侦听的SOA消息监控是构建高效SOA安全性解决方案基础的一种手段。SOAP侦听

　　图1 一个用于监控SOAP消息的SOAP拦截器用作这个SOA中的安全性基础。SOAP拦截器分析它监控的SOAP消息的标题头中包含的用户身份，并将其与保存在现有安全性基础架构中的名称相比较。结果就是对SOAP消息发送方和接收方进行了身份验证和授权。

　 　就是在web服务消费者和web服务之间来回传递的SOAP消息的路径中放入一个叫做“SOAP拦截器”的特殊软件块。因为其分类、监控、复制和转发包 含大量数据的SOAP消息的能力，SOAP拦截器可以在SOA安全性方面发挥重大作用。如图7所示，一个SOA安全性解决方案“监视”着到达web服务的 SOAP调用消息和对这些服务调用的响应。当它“看见”一条消息时，SOA安全性解决方案就会进行检查，以确保发出请求的实体是经过身份验证和授权可以使 用web服务的。SOA安全性解决方案通过检查SOAP消息标题头中包含的数据实现了这一点。

　　在大多数情况下，SOA安全性解决方案是 对现有安全性解决方案的扩展，而现有安全性解决方案是在迁移到SOA之前为保护整个企业而部署的。因此，SOA安全性解决方案很可能不得不与现有安全性基 础架构进行连接和通信。如图7所示，SOA中的用户身份验证和授权发生在基于企业的授权用户数据库检查用户证书的时候。侦听SOAP消息，并把消息标题头 中列出的用户与保存在现有安全性基础架构中的用户进行比较，便可实现身份验证和授权。

SAML和联邦身份验证

　　当需要 对企业外部的SOA用户进行身份验证和授权时，又会怎么样呢？SOA的开放性使得上述情况比以往任何时候都更可能出现。您可能会面临这样一个难题：在一组 在现有安全性基础架构中没有记录的用户中，搞清楚每个用户的身份。为了解决保护第三方过程中固有的安全性问题，SOA安全性解决方案可以使用联邦身份验 证。联邦身份验证是这样一个过程：通过这个过程，多方可以达成一致，使用一组给定的标准来对一组指定的用户进行身份验证。联邦身份验证方法的使用者可以创 建一个联邦身份管理系统(Federated Identity Management System)，这是一个已验证用户的库。SOA安全性解决方案可以通过检查联邦身份管理系统来对某个用户进行身份验证。换句话说，一些相互通信的系统的 “联邦”，可以一致同意某个用户是合法的。

　　在某些情况下，身份验证过程会导致在SOA安全性解决方案中创建安全断言标记语言 （Security Assertion Markup Language，SAML）断言，用于以一种可为用户调用的web服务所接受的方式表达用户的真实性。SAML是一种基于XML的标准，它为以标准方式 描述安全性信息提供了一个框架。WS-Security是迄今为止得到认可的安全性标准集合的总称。许多SOA安全性解决方案都利用了这些新兴的安全性标 准。如图8所示，SOA安全性解决方案可以侦听SOAP消息，然后使其经过一个对用户进行身份验证的过程。接下来，SOA安全性解决方案把SOAP消息传 递给目的web服务，但是会附加上一个SAML断言。注意：SAML断言不依赖于联邦身份验证过程。

　 　图2 要在SOA安全性中使用联邦身份验证，SOAP拦截器必须把传入的SOAP消息转发给安全性解决方案，该安全性解决方案再把SOAP消息标题头中包含的用 户身份与联邦身份验证数据库中列出的用户进行匹配。如果匹配成功，SOA安全性解决方案就会创建一个安全“断言”，内容是用户已经在安全断言标记语言文档 中通过了身份验证，该文档是在SOAP消息到达它要调用的web服务时附加给该SOAP消息的。

应用程序代理

　　一种非 常有效的保护核心系统的方法是避免让任何人访问驻留平台的服务。可以通过为SOA中的web服务部署一个代理做到这一点。如图9所示，一个受保护的代理可 以代表实际的web服务接收所有web服务请求，并对其做出响应，从而保护web服务免遭恶意的侵害。代理方法的另一个好处在于，它能够减轻企业安全性基 础架构的负担。代理可以降低网络流量，具体方法是集中管理和缓存对web服务请求的身份验证和授权，而不是每次用户想调用web服务时，就在网络上使用大 量消息对该用户进行身份验证和授权。代理还在消息中插入了身份验证和授权SAML断言，从而消除了实际web服务直接查询安全性系统的需要。

契约管理

　 　在下一章中，我们将花大量时间来讲述这个主题，但是作为主要的SOA管理问题之一，契约管理同样在SOA安全性中起着举足轻重的作用。契约就是用于管理 web服务使用情况的一组规则。例如，某个契约可能会规定，某个特定用户有权每天调用某个特定的web服务十次。而且在调用过程中，服务水平必须满足特定 的参数，比如一秒钟的响应时间。

　　在安全性方面，契约有助于确定SOA是否运行正常，或者由于违反安全性规则而误用。如图10所示， SOA拦截器把web服务请求和响应数据发送给SOA安全性解决方案，然后该SOA安全性解决方案再确定是否满足契约。如果某个安全性问题（比如DoS攻 击）使web服务的速度降低到契约规定的服务水平以下，SOA安全性解决方案就会警告管理方有问题存在。当然，一次足够严重的攻击可以导致整个网络崩溃， 但是安全性解决方案至少可以发出有问题存在的通知。

　　图3 通过处理SOAP消息流量，降低企业安全性基础架构的负担，并保护web服务免于误用，web服务代理有助于保护SOA。

　　图4 SOA安全性解决方案监控服务水平，并在安全性问题导致web服务降低到契约规定的服务水平以下时发出警告。

证书、密钥和加密

　 　这些年来，IT领域先后出现了很多消息级的安全性技术，包括密码术。现在，也可以对SOA应用这些技术。这些过程，包括数字签名、证书、密钥和加密，都 可用来保护SOA。在这里我声明一点：对于这4种安全性技术中的每一种，都可以写出一本甚至是好几本著作。请把本节看作是对与SOA相关的基于加密的安全 性的一个概述。

　　如果希望让SOA拥有健壮的安全性，保证web服务的用户都可以得到适当的身份验证，而未经身份验证的人无法读取在 web服务及调用它们的应用程序之间往返的信息，那么无疑需要对SOA安全性解决方案应用功能强大的公钥/私钥加密工具。密钥是一个具有某种特殊的数学特 性的大数（数百个数位）。尽管形式和大小各不相同，但密钥都有一个基本属性，即，可以与另一个密钥进行惟一关联。也就是说，当一个密钥遇到其惟一的匹配密 钥时，双方都会说，“哦，就是你了，我惟一的匹配…不会再有其他的什么人了。”

　　惟一的密钥对具有如下两个基本功能：

• 因为它们是惟一的，所以它们是非常强大的身份验证工具。
• 由于它们的数学特性，它们可用于创建经过不可测知的过程进行加密的惟一消息，这些消息只能被拥有惟一的匹配密钥对的用户所读取。

　 　下面讲述当两个用户想交换加密信息时的工作原理：用户A创建一个惟一的密钥对。然后，他在自己的系统中隐藏其中的一个密钥（“私钥”），却把另一个密钥 （“公钥”）发送到用户B可访问的网络上某处。然后，用户B使用公钥来加密他想要发送给用户A的信息。实际过程涉及到大量让我想一想就头痛的数学知识，但 是基本上，公钥和消息数据是通过一个加密算法来运作的，该加密算法生成一个没有私钥不可能打开的加密文件。接下来，用户B把经过加密的消息发送给用户A， 而用户A则使用最初隐藏的私钥来对加密数据进行解密。结果，用户A是世界上惟一一个能够解密这些加密数据的人，因为（只有）他拥有与用户B的公钥匹配的惟 一私钥。

　　现在，如果您像我一样爱刨根问底，您可能会想，但是用户A如何知道用户B真的是用户B呢？如果某位黑客侵入到用户B的系统中， 并找到了他使用的公钥，那怎么办呢？为了回答这个有效性问题，人们使用了大量实体来确保特定用户的真实性，并授予他们证明其真实性的数字证书。这些实体叫 做certificate authority (认证机构，CA)。CA的一个著名例子是VeriSign，它提供用于电子商务事务的证书。

　 　使用密钥、加密和证书来实现保密性和身份验证的SOA安全性解决方案如图11所示。在我们的制造商例子中，供应商系统想发送一条SOAP消息给制造商的 web服务。为了做到这一点，制造商必须首先发送一个公钥给CA。然后，供应商系统从CA请求一个证书。供应商收到的证书包含与制造商系统中存在的私钥相 匹配的公钥。然后，供应商使用证书的公钥加密其消息，然后再把消息发送给制造商。然而，和前面的例子一样，SOA安全性解决方案侦听消息，并使用CA检查 证书的有效性。这可以验证供应商的身份。只有在通过身份验证之后，加密后的SOAP消息才能被发送给制造商。SOAP消息到达之后，制造商就使用它的私钥 对消息进行解密和处理。

　　如果您觉得这听起来更多地像是在发送消息，那么您想得没错。就像在IT的其他领域中一样，SOA中的安全性会带 来大量“开销”。在到达目的地之前，每条消息都必须经过好几个地方。证书文件可能会很大，从而给网络造成很大的负担，而且整个过程往往会降低性能。但是遗 憾的是，它仍然是必不可少的。

XML加密

　　 图 5 在安全性SOA中使用公钥/私钥加密和证书的步进式过程

　　 图字：

1. 制造商将公钥发送给认证机构，并将私钥隐藏在自己的域中
2. 供应商从认证机构请求包含制造商公钥的证书
3. 供应商向制造商发送使用公钥进行加密并包含证书的消息
4. SOA安全性解决方案向认证机构发送证书，以便对供应商进行身份验证
5. SOA安全性解决方案向制造商发送使用私钥进行加密的SOAP消息

　 　为了保留SOA的开放性，同时制订严格的消息级的安全性标准，您很可能想在加密时使用XML。当SOA安全性解决方案使用密钥对消息进行加密时，它会把 消息转换为一段经过加密的XML。消息是XML格式的，但是内容并不可见，因为使用加密算法将其隐藏起来了。这样做的好处在于，接收消息的系统可以把它当 作XML来接收、解密和处理，而不依赖于定制或专有的消息传递标准。这样我们就获得了安全性，同时系统仍然基于开放标准。

数字签名

　 　数字签名是另一种消息级的安全性形式，它是证书、密钥和加密等安全性方法的变体。数字签名就是附加给SOAP消息的证明真实性的数学语句。数字签名是一 个基于密钥的数（同样是一个非常大的数），它对您的身份和消息内容进行惟一的处理，具体方法是对两组数据（密钥和消息）运行一个特殊的算法。举一个简单的 例子，如果您的消息是“hello”而密钥是12345，算法将处理这两种输入——单词“hello”的数值和密钥数12345——并生成第三个数，这第 三个数就是数字签名。当接收系统获得消息和附加的数字签名时，它可以使用密钥来验证以下内容：

• 您是消息的真正创建者（身份验证），
• SOAP消息在传输过程中没有改变。

　 　如果消息被改变了，那么惟一的数字签名将不再与密钥和用于创建密钥的原始消息相匹配。数字签名和先前描述的完整加密过程之间的区别在于，如果使用数字签 名，不必对整条消息进行加密。因此，系统的性能得到了提升。只要您不介意别人可以看到您的纯文本格式的消息，那么数字签名就可以为SOA提供高度的数据安 全性和完整性。

　　签名可以是一个不可否认性（nonrepudiation）组成部分，该特性是一个需要在SOA环境中解决的安全性重要 方面。不可否认性是指一个组织的一种能力：验证发生了特定的处理，并从而不给发送方提供否定进行了处理的机会。例如，如果您针对某种商品下了一份电子订 单，而该订单并没有以某种方式（比如使用数字签名）进行验证，那么对方就有可能否认收到该订单。如果批发商的系统提供不可否认性，那么批发商就可以肯定该 订单已经送达。

重放攻击保护和审计

　　最后，SOA安全性解决方案应该提供一种用于跟踪SOAP请求的工具，从而降低 DoS攻击带来损害的可能性。通常，跟踪特性将监控SOAP消息的发送方及其创建时间。在某些情况下，SOA安全性解决方案将使用一个惟一的识别码给 SOAP消息打上印记。如果解决方案被设置为阻塞复制消息，那么同一条消息是不可能被发送两次的。消除这种可能性有助于降低黑客使用复制请求淹没SOA的 可能性，这是DoS攻击中常用的一种手法。

　　审计是SOAP消息跟踪功能的进一步发展。如果SOA安全性解决方案被配置为跟踪消息，那么 它应该能够生成特定时期中SOA消息流量的使用日志和审计报告。审计有很多用途，但是在安全性领域中，它用于记录所发生的事情，以便研究安全性问题并诊断 潜在的安全漏洞。这类日志已经成为实现管理目标（比如对Sarbanes-Oxley法案的服从）所必不可少的。

明智的管理人员所给出的忠告：不要让安全性吓倒了您

　 　SOA安全性是一个很大的主题。我可以就这个主题写一本书。（事实上，这是一个不错的主意…）在本章中，我的目的是提供一个概述，好让您可以评估自己对 这个主题所掌握的信息。如果您是一位企业主管，我的建议是，要避免被安全性问题吓倒。人们很容易被安全性吓倒，安全人员也不例外，这阻止了他们做些实际工 作以消除对于安全性问题的恐惧。实际上，我本来可以提出一个您正在考虑的IT解决方案，并让您了解到围绕该解决方案的大量安全性噩梦，这些噩梦足以使您远 离该解决方案。

　　相反，我建议您寻求安全性方面的高质量建议，并探讨企业中已经实施了哪些。如果您这样做，那么您的企业就很可能会拥有一 个（或一些）相当健壮的安全性系统。实施SOA的难点在于如何把现有的安全措施扩展成为由SOA构成的web服务。许多SOA安全性解决方案的设计目的就 是为了与现有的安全功能有效互连。如果实现的话，安全性风险可能稍微易于管理一些，而您也可以继续实施您的计划了。

结束语

　 　安全性是SOA中的一个焦点问题，因为SOA强调机器与机器的交互，而大多数IT安全性都是基于人与机器的交互。身份验证和授权在这个环境中变得更加富 于挑战性。在未受保护的SOA中，想要阻止web服务的未授权使用实际上是不可能的；未授权用户可以非常轻松地访问web服务。Web服务不具备跟踪谁在 使用它们或者谁被允许使用它们的固有功能。无法阻止不必要的监听和消息侦听。未受保护的SOA让黑客有机会监听SOAP消息并看到私密信息。此外，在未受 保护的SOA中，侦听SOAP消息并（出于危害和欺骗的目的）重新发送消息或转换消息内容要相对容易一些。

　　由于SOA架构的开放性本 质，您无法保护SOA中未知的第三方。第二级和第三级用户（例如您的合作伙伴的合作伙伴）是可以访问未受保护的SOA的。因此，未受保护的SOA很容易超 负荷运转。如果没有访问控制，未受保护的SOA很容易被来自黑客的大量SOAP消息所“淹没”。结果可能导致DoS攻击损害系统的正常功能。最后，您还没 有处理记录。未受保护的SOA无法跟踪其用户或消息。因此，没有可用于研究安全性问题或诊断安全性漏洞的可审计使用记录。

　　存在一些可以 解决所有这些问题的预打包和定制的SOA安全性解决方案。在分析SOA安全性需求时，可以考虑实现一个支持SOAP消息监控、联邦身份验证、应用程序代 理、契约管理、证书、密钥和加密以及审计记录的SOA安全性解决方案。这个清单似乎很长，但是事实上，如果缺少其中任何一项，SOA的所有优点都可能遭到 破坏。

　　SOAP消息监控利用了一个SOAP拦截器模型，以便在将SOAP消息从调用系统发送给web服务时对其进行侦听和监控。 SOAP消息监控是SOA安全性的基础，因为它让安全性解决方案能够停止和分析每条消息，以进行用户身份验证和授权。为了保护第三方，安全性解决方案可以 利用联邦身份验证。应该通过一个联邦身份验证过程提供对系统中的用户进行身份验证的能力。最终将获得一个为web服务的用户提供可信身份验证的SAML断 言。

　　Web服务应用程序代理在实际的web服务中接收和处理SOAP请求，从而对安全性有所帮助。它可以使所有的用户都远离实际的服务。代理不仅可以减轻网络的负载，还可以为SOA提供一个额外的安全性层。

　　契约管理是另一项对安全性有所帮助的SOA管理特性。契约确立了谁有权使用web服务以及何时可以使用它。契约通过消除非契约方的使用，提高了SOA的安全性。

　 　对于一个真正安全的SOA来说，证书、密钥和加密同样是必不可少的。最健壮的SOA安全性都源于实现了使用来自认证机构的私钥/公钥进行身份验证的加密 消息传递。XML加密允许web服务用户发送保留XML格式的加密SOAP消息。因此，系统实现了安全性，但却仍然基于标准。数字签名是加密模型的一种变 体，它使得web服务的用户可以创建一个惟一确认的数字“签名”，其用途有二：验证用户身份和确保消息数据的完整性。

　　最后，为了跟踪SOA的使用，有必要采用可以保存所有SOAP消息请求和响应的动态审计日志的SOA安全性解决方案。审计日志对于在SOA中研究安全性问题和诊断安全性漏洞，以及实现管理规章服从性，都是必需的。

面向服务的 体系结构（SOA）表示您可以如何使用 Web 服务的大图景。Web 服务规范定义了实现服务以及与它们的交互所需要的细节。然而，面向服务的体系结构（SOA）是一种用于构建分布式系统的方法，采用 SOA 这种方法构建的分布式应用程序可以将功能作为服务交付给终端用户，也可以构建其他的服务。面向服务的体系结构（SOA）可以基于 Web 服务，但是它可能改为使用其他的技术来代替。在使用面向服务的体系结构（SOA）设计分布式应用程序时，您可以将 Web 服务的使用从简单的客户端-服务器模型扩展成任意复杂的系统。

因而，单个的软件资产成为开发其他应用程序的基本构件。您可以通过与新的代码 和遗留代码一起使用的共同交互方式来减少系统的复杂性（CBDi 的 Lawrence Wilkes 开玩笑说，面向服务的体系结构（SOA）可以代表“节省我们的资产（Save Our Assets）”）。有一种标准的方法可以用于表示这些软件资产和与它们交互；现在人们关注的重点已经转移到基于这些构件的应用程序装配上来了。

虽 然在这里讨论的是用于业务应用程序的面向服务的体系结构（SOA），但是面向服务的体系结构（SOA）同样也可以用于其他的分布式系统，比如网格计算和高 级 Web 服务规范（例如，Web 服务分布式管理（WS-DistributedManagement）、Web 服务信任（WS-Trust）以及 UDDI）。

什么是服务？

在 面向服务的体系结构（SOA）中，服务（service）是封装成用于业务流程的可重用组件的应用程序函数。它提供信息或简化业务数据从一个有效的、一致 的状态向另一个状态的转变。用于实现特定服务的流程并不重要，只要它响应您的命令并为您的请求提供高质量的服务就可以了。

通过定义的通信协 议，可以调用服务来强调互操作性和位置透明性。一个服务表现为一个软件组件，因为从服务请求者的角度来看，它看起来就像是一个自包含的函数。然而，实际 上，服务的实现可能包括在一个企业内部的不同计算机上或者许多业务合作伙伴拥有的计算机上执行的很多步骤。就封装的软件而言，服务可能是一个组件，也可能 不是一个组件。如同类对象，请求者应用程序能够将服务看作是一个整体。

Web 服务是以使用 SOAP 消息（它是用像 HTTP 这样的标准协议上的 WSDL 来描述的）的调用为基础的。使用 Web 服务的最佳实践就是与外部的业务伙伴通信。

松耦合

服务请求者到服务提供者的绑定与服务之间应该是松耦合的。这就意味着，服务请求者不知道提供者实现的技术细节，比如程序设计语言、部署平台，等等。服务请求者往往通过消息调用操作——请求消息和响应——而不是通过使用 API 和文件格式。

这 个松耦合使会话一端的软件可以在不影响另一端的情况下发生改变，前提是消息模式保持不变。在一个极端的情况下，服务提供者可以将以前基于遗留代码（例如， COBOL）的实现完全用基于 Java 语言的新代码取代，同时又不对服务请求者造成任何影响。这种情况是真实的，只要新代码支持相同的消息模式。

明确定义的接口

服务交互必须是明确定义的。Web 服务描述语言（Web services Description Language，WSDL）是受到广泛支持的方法，用于描述服务请求者所要求的绑定到服务提供者的细节。服务描述的重点在于与下面几部分交互所用的操作：

服务
调用操作的消息
构造这种消息的细节
关于向何处发送用于构造这种消息的处理细节的消息的信息
WSDL 不包括服务实现的任何技术细节。服务请求者不知道也不关心服务究竟是由 Java 代码、C#、COBOL，还是由某种其他的程序设计语言编写的。它可以描述使用 HTTP 的 SOAP 调用。由于它的扩展机制，它也可以定义其他类型的交互，比如通过 JMS 提交的 XML 内容、直接方法调用、由管理遗留代码的适配器处理的调用（CICS），等等。

WSDL 的通用定义允许开发工具创建各种各样类型的交互的通过接口，同时隐藏它是如何由应用程序代码调用服务的细节。例如，如果服务是以多种交互类型公开的， Web 服务调用框架（Web Services Invocation Framework，WSIF）通过允许运行时决定调用高质量服务的最优方法来使用这种能力。

无状态的服务设计

服 务应该是独立的、自包含的请求，在实现时它不需要从一个请求到另一个请求的信息或状态。服务不应该依赖于其他服务的上下文和状态。当需要依赖时，它们最好 定义成通用业务流程、函数和数据模型，而不是实现构件（比如会话密钥）。当然，请求者应用程序需要服务调用之间的持久状态，但是这不应该与服务提供者分 开。

这里有一个定义会话的错误方法的示例：

Requester: “What is Bruce’s checking account balance?"
Provider: “$x"
Requester: “And what is his credit limit?"
Provider: “$y"
 

提供者被要求记住请求之间 Bruce 的帐号，这就在服务实现中引入了复杂性。无状态的服务设计将重新定义会话，如下所示：

Requester: “What is Bruce’s checking account balance?"
Provider: “$x"
Requester: “What is Bruce’s credit limit?"
Provider: “$y"
 

服务粒度

操 作的粒度是一项重要的设计要点。对于外部的消耗推荐使用粗粒度的接口，而细粒度的接口可能用于企业内部。粗粒度接口可能是特定服务的完整处理，例如 SubmitPurchaseOrder，在这里消息包括定义订购单所需的所有业务信息。细粒度接口可能具有用于以下方法的不同操作： CreateNewPurchaseOrder、SetShippingAddress、AddItem，等等。

虽然细粒度的接口为请 求者应用程序提供了更多的灵活性，它同样也意味着交互的模式可能随着不同的服务请求者而不同。这可能使对于服务提供者的支持更加困难。粗粒度接口保证服务 请求者将以一致的方式使用服务。面向服务的体系结构（SOA）不要求使用粗粒度接口，但是推荐使用它们作为外部集成的最佳实践。服务编排可以用来创建运行 由细粒度操作组成的业务流程的粗粒度接口。

服务质量需要考虑的问题

面 向服务的体系结构（SOA）设计将跨越计算机系统，并且还可能跨越企业边界。您不得不考虑在使用 Internet 时安全性功能和需求以及如何链接伙伴的安全域。Internet 协议并不是为可靠性（有保证的提交和提交的顺序）而设计，但是您不得不确保消息被提交并被处理一次。当这不可能时，请求者必须知道请求并没有被处理。

例如，您可能需要考虑您所部署服务的度量、可靠性以及响应时间，以便确保它们在承诺的范围之内。当您设计使用来自其他业务伙伴的服务的系统时，您就不得不考虑面向服务的管理来以协作方式管理伙伴之间的服务。

　　面向服务的 架构是一种IT策略，它将企业应用程序中包含的分散功能组织为可互操作的基于标准的服务，这些服务可按照业务需求快速组合和重用。只有平衡了企业的长期目 标与短期需求，SOA的益处才会显现出来。通过在开始采用SOA时就指定一组组织、资金、操作、设计和交付准则，就可保持这一平衡。但“大爆炸”式的方法 是不可取的，应按照循序渐进的学习曲线，选择一种往复渐进的方式来部署架构更改，这非常重要。大体而言，SOA路线图就提供了这样一种往复渐进的方式，使 您随着进展得出(重新得出)您的企业的独有规划。

您的SOA路线图应包含3个关键特征:

　　成熟:SOA路线图应该是不 断融入经验和教训的“活动文档”。SOA路线图成熟时，您的SOA行动也就以一种可控的方式达到了一个更为精妙的级别。SOA路线图的创建应该从评估企业 当前在SOA方面的能力和要求开始。此过程可使用 BEA的在线自我评估工具 做为起点。

　　作用域:完整的SOA路线图应包含6个域(如 图1所示)。这6个域之间有明确的界限，但是仍相互关联、相互依赖。各个域的执行情况是企业级SOA行动成功的基石。SOA路线图应清晰地定义SOA行动 的边界，并确定一个实现SOA目标的明晰、灵活的时限。这些目标应该被分散到多个易于管理的阶段中，随后便可以以一种往复渐进的方式实现。

　　质量:通过在各里程碑处使用一个“学习与调整”的过程，同时采用往复渐进的方式，您的路线图将在整个SOA行动中保持相关性。为确保SOA路线图的质量，应在所有涉众之间进行沟通及确认，并向各方征求反馈意见。

　　图1. BEA域模型

构建SOA路线图的步骤

　　SOA路线图的开发共分4个阶段:SOA规划、SOA成熟度评估、SOA前景展望和SOA路线图定义。

SOA规划

　　这一阶段组织并定义SOA行动。涉众通过通信和简报等方式参与此过程，并设置一致通过的优先级和参数。由于此阶段牵涉到整个企业的员工，因此清晰、充分的沟通非常重要。在此阶段中，要完成的任务包括:

• 　　定义SOA的作用域。
• 　　确定与其他IT行动的边界并建立合作。
• 　　适当地展示SOA的业务论证。
• 　　展示现有业务行动与未来业务行动的衔接关系。

SOA成熟度评估

　 　在SOA成熟度评估阶段，要为当前所处状态建立一个度量标准。此时将定义当前已经实现、可作为SOA起点的服务和功能，并确定出可作为基础项目的项目。 团队应通过一系列访问调查和问卷调查查看各域——分析、制定基准并验证各域的现状。使用BEA的域模型组织检查如下各方面:

• 　　业务策略与过程:对业务策略与过程进行自顶而下的查看。
• 　　架构:评审当前架构、策略和标准。
• 　　成本与收益:概述现有成本构成与收益情况。
• 　　构造块:对现有服务、过程、工具和技术进行分析。
• 　　项目与应用:评审现有系统以及未完成的和已规划好的项目。
• 　　组织与管理:对现有管理结构和策略进行分析。

SOA前景展望

　　在这一阶段中，团队通过专题研讨会来确定并定义要求的“预期”状态，并确保举办整个企业范围内的联合讨论。

• 　　业务策略与过程:SOA前景展望与业务策略与过程的关联。
• 　　架构:导向原则、需求、策略、标准和参考架构。
• 　　成本与收益:指标和测量要求。
• 　　构造块:共享的服务基础架构需求及标准化的工具。
• 　　项目与应用:对项目与应用的SOA映射。
• 　　组织与管理:管理并遵循结构与策略。

SOA路线图定义

　　从这一阶段起，着手定义SOA路线图。应该根据前三个阶段所收集的信息，对企业的SOA目标和适当的时限进行彻底的差距分析(gap analysis)。近期事件要详细，而较远的事件要灵活——以便在前进中融入所得到的经验教训。

• 　　业务策略与过程:按业务价值排列机会。
• 　　架构:近期、中期、长期参考架构路线图。
• 　　成本与收益:未来指标、成本构成及收益情况的路线图。
• 　　构造块:将共享服务战略和标准化进程列入优先地位。
• 　　项目与应用:项目与应用的影响。
• 　　组织与管理:提出的管理结构与策略。

　　SOA路线图应该是不断融入经验和教训的“活动文档”。SOA路线图成熟时，您的SOA行动也就以一种可控的方式达到了一个更为精妙的级别(如图2所示)。

　　图2. SOA“学习与调整”路线图

结束语

　　我希望通过本文使您在脑海中形成一个创建自己的SOA路线图的框架，文中还说明了“为什么路线图对SOA行动如此重要?”。路线图就是说明开发内容、开发时间、部署所开发内容的一份指南。对于SOA的顺利部署而言，路线图是最为强大的工具。

      传统的Web（HTML/HTTP）技术有效的解决了人与信息系统的交互和沟通问题，极大的促进了B2C模式的发展。WEB服务(XML/SOAP/WSDL）技术则是要有效的解决信息系统之间的交互和沟通问题，促进B2B/EAI/CB2C的发展。SOA（面向服务的体系)则是采用面向服务的商业建模技术和WEB服务技术，实现系统之间的松耦合，实现系统之间的整合与协同。WEB服务和SOA的本质思路在于使得信息系统个体在能够沟通的基础上形成协同工作。

 　 对于面向同步和异步应用的，基于请求/响应模式的分布式计算来说，SOA是一场革命。一个应用程序的业务逻辑（business logic）或某些单独的功能被模块化并作为服务呈现给消费或者客户端。这些服务的关键是他们的松耦合特性。例如，服务的接口和实现相独立。应用开发人员或者系统集成者可以通过组合一个或多个服务来构建应用，而无须理解服务的底层实现。举例来说，一个服务可以用。NET或J2EE来实现，而使用该服务的应用程序可以在不同的平台之上，使用的语言也可以不同。

一、SOA具有的特性

　　SOA服务具有平台独立的自我描述XML文档。Web服务描述语言（WSDL， Web Services DesCRiption Language）是用于描述服务的标准语言。

　　SOA 服务用消息进行通信，该消息通常使用XML Schema来定义（也叫做XSD， XML Schema Definition）。消费者和提供者或消费者和服务之间的通信多见于不知道提供者的环境中。服务间的通讯也可以看作企业内部处理的关键商业文档。

　　在一个企业内部，SOA服务通过一个扮演目录列表（DIrECtory liSTing）角色的登记处（Registry）来进行维护。应用程序在登记处（Registry）寻找并调用某项服务。统一描述，定义和集成（UDDI， UniverSAl Description， Definition， and Integration）是服务登记的标准。

　　每项SOA服务都有一个与之相关的服务品质（QOS， quality of service）。QoS的一些关键元素有安全需求（例如认证和授权），可靠通信（译注：可靠消息是指，确保消息“仅且仅仅”发送一次，从而过滤重复信息。），以及谁能调用服务的策略。

二、SOA三大基本特征

      1 独立的功能实体

      在Internet这样松散的使用环境中，任何访问请求都有可能出错，因此任何企图通过Internet进行控制的结构都会面临严重的稳定性问题。SOA非常强调架构中提供服务的功能实体的完全独立自主的能力。传统的组件技术，如.NET Remoting，EJB，COM或者CORBA，都需要有一个宿主(Host或者Server)来存放和管理这些功能实体；当这些宿主运行结束时这些组件的寿命也随之结束。这样当宿主本身或者其它功能部分出现问题的时候，在该宿主上运行的其它应用服务就会受到影响。

      SOA架构中非常强调实体自我管理和恢复能力。常见的用来进行自我恢复的技术，比如事务处理(Transaction)，消息队列(Message Queue)，冗余部署(Redundant Deployment)和集群系统(Cluster)在SOA中都起到至关重要的作用。

      2 大数据量低频率访问

      对于.NET Remoting，EJB或者XML-RPC这些传统的分布式计算模型而言，他们的服务提供都是通过函数调用的方式进行的，一个功能的完成往往需要通过客 户端和服务器来回很多次函数调用才能完成。在Intranet的环境下，这些调用给系统的响应速度和稳定性带来的影响都可以忽略不计，但是在 Internet环境下这些因素往往是决定整个系统是否能正常工作的一个关键决定因素。因此SOA系统推荐采用大数据量的方式一次性进行信息交换。

      3 基于文本的消息传递

      由于Internet中大量异构系统的存在决定了SOA系统必须采用基于文本而非二进制的消息传递方式。在COM、CORBA这些传统的组件模型中，从服务器端传往客户端的是一个二进制编码的对象，在客户端通过调用这个对象的方法来完成某些功能；但是在Internet环境下，不同语言，不同平台对数据、甚至是一些基本数据类型定义不同，给不同的服务之间传递对象带来的很大困难。由于基于文本的消息本身是不包含任何处理逻辑和数据类型的，因此服务间只传递文本，对数据的处理依赖于接收端的方式可以帮忙绕过兼容性这个的大泥坑。

      此外，对于一个服务来说，Internet与局域网最大的一个区别就是在Internet上的版本管理极其困难，传统软件采用的升级方式在这种松散的分布式环境中几乎无法进行。采用基于文本的消息传递方式，数据处理端可以只选择性的处理自己理解的那部分数据，而忽略其它的数据，从而得到的非常理想的兼容性。

三、面向服务架构（SOA）的原则

      SOA的强大和灵活性将给企业带来巨大的好处。如果某组织将其IT架构抽象出来，将其功能以粗粒度的服务形式表示出来，每种服务都清晰地表示其业务价值， 那么，这些服务的顾客（可能在公司内部，也可能是公司的某个业务伙伴）就可以得到这些服务，而不必考虑其后台实现的具体技术。更进一步，如果顾客能够发现 并绑定可用的服务，那么在这些服务背后的IT系统能够提供更大的灵活性。
但是，要得到种强大和灵活性，需要有一种实现架构的新方法，这是一项艰巨的任务。企业架构设计师必须要变成“面向服务的架构设计师”，不仅要理解SOA，还要理解SOA的实践。在架构实践和最后得到的架构结果之间的区别非常微妙，也非常关键。本文将讨论SOA的实践，即：面向架构的设计师在构建SOA时必须要做的事情。

      SOA的原则

      SOA是一种企业架构，因此，它是从企业的需求开始的。但是，SOA和其它企业架构方法的不同之处在于SOA提供的业务敏捷性。业务敏捷性是指企业对变更 快速和有效地进行响应、并且利用变更来得到竞争优势的能力。对架构设计师来说，创建一个业务敏捷的架构意味着创建这样一个IT架构，它可以满足当前还未知 的业务需求。

      要满足这种业务敏捷性，SOA的实践必须遵循以下原则：

      * 业务驱动服务，服务驱动技术

      从本质上说，在抽象层次上，服务位于业务和技术中间。面向服务的架构设计师一方面必须理解在业务需求和可以提供的服务之间的动态关系，另一方面，同样要理解服务与提供这些服务的底层技术之间的关系。

      * 业务敏捷是基本的业务需求

      SOA考虑的是下一个抽象层次：提供响应变化需求的能力是新的“元需求”，而不是处理一些业务上的固定不变的需求。从硬件系统而上的整个架构都必须满足业务敏捷的需求，因为，在SOA中任何的瓶颈都会影响到整个IT环境的灵活性。

      * 一个成功的SOA总在变化之中

      SOA工作的场景，更象是一个活的生物体，而不是象传统所说的“盖一栋房子”。IT环境唯一不变的就是变化，因此面向服务架构设计师的工作永远不会结束。 对于习惯于盖房子的设计师来说，要转向设计一个活的生物体要求崭新的思维方式。如下文所写的，SOA的基础还是一些类似的架构准则。

      SOA基础

      在IT行业有两个越来越普遍的发展方向，一个是架构方面的，一个是方法学方面的，面向服务的架构设计师可以从中有所收获。第一个就是MDA（模型驱动架构），由提出CORBA的OMG模型提出。MDA认为架构设计师首先要对待创建的系统有一个形式化的UML（也是由OMG提出）的模型。MDA首先给出一个平台无关的模型来表示系统的功能需求和Use Cases，根据系统搭建的平台，架构设计师可以由这个平台无关的模型得到平台相关的模型，这些平台相关模型足够详细，以至于可以用来直接生成需要的代码。

      MDA的核心就在于在设计阶段系统就已经完全描述，这样，在创建系统的时候，几乎就没有错误解释的可能，模型也就可以直接生成代码。但MDA有一些局限 性：首先，MDA假设在创建模型之前，业务需求已经全部描述，而这一点，在当前典型的动态业务环境中几乎是不可能的。第二，MDA没有一个反馈机制。如果 开发人员对模型有需要改动的地方，并没有提供给他们这么一个途径。

      SOA的另一个基础是敏捷方法（AM），其中非常有名的方法是极限编程（XP）。象XP这样的AM提供了在需求未知或者多变的环境中创建软件系统的过程。XP要求在开发团队中 要有一个用户代表，他帮助书写测试来指导开发人员的日常工作。开发团队中的所有成员都参与到设计之中，并且设计要尽量小并且非形式化。AM的目标是仅仅创 建用户想要的，而不是在一些形式化模型上耗费工作量。AM的核心思想就在于其敏捷性－处理需求变更的敏捷性。AM的主要弱点是其规模上的限制，例如，XP 在一个小团队和中型项目中效果不错，但是当项目规模增大时，如果没有一个一致的清晰的计划，项目成员很难把握项目中的方方面面。

      从表面看来，MDA和AM似乎是相对立的－MDA假定需求是固定的，而AM恰恰相反。MDA的中心是形式化的模型，而AM恰恰要避开它们。但是，我们还是决定冒险把这些不同方法中的一些元素提取出来，放入到一个一致的架构实践中。

      在SOA中有三个抽象层次，按照SOA的第一条准则：业务驱动服务、服务驱动技术。AM将业务模型直接和实践连接起来，表现在平台相关的模型之中。MDA 并没有把业务模型和平台无关模型分开来，而是把平台无关模型做为起点。SOA必须连接这些模型，或者说抽象层次，得到单一的架构方法。我们将从五个视图的架构实现方法来实现这个连接。

      SOA的五视图实现方法

      企业架构设计师发现他们的职业非常有竞争力并且值得骄傲，因为他们要从很多方面来通盘考虑IT系统。Kruchten（RUP的开发负责人）将这些方面提取出来，在应用到SOA时，我们称为五视图实现方法（five-view approach）。

      四个方框表示对一个架构的不同审视方法，分别代表不同的涉众（stakeholder）。弟五个视图，use-cASe视图涵盖了其它视图，在架构中扮演的是一个特殊的角色。部署视图将软件映射到底层平台和相关硬件上，是系统部署人员对架构的视图；实现视图描述了软件代码的组织，是从开发人员角度出发的视图；业务分析人员则利用过程视图进行工作，它描述的是软件系统的运行时特性。最后，逻辑视图表示的是用户的功能需求。在SOA中，面向服务的架构必须能够以use-case视图中的用例将用户连接到服务，将服务连接到底层的技术。

      为了表示面向对象的 架构是如何工作在这些视图之上，让我们将他们置于SOA元模型的上下文之中。SOA中两个领域存在重叠：由业务模型和服务模型表示的业务领域和由服务模型 及平台相关模型表示的技术领域（两个领域共享服务模型）。业务用户通过逻辑视图和过程视图处理粗粒度的业务服务，根据变化的业务需求，按照需要将它们安排 在过程之中。另一方面，技术专家的工作是创建并维护服务和地层技术之间的抽象层。表示这些服务的中间模型，起到的是轴心的作用，业务以它为中心进行。

      SOA元模型从MDA中继承平台无关模型和平台相关模型，但是添加了AM和用户交互以及敏捷的反馈这两部分，后者通过椭圆之间的双向箭头来表现。类似地，元模型通过引入由中心的服务模型提供的中间层抽象解决了AM在伸缩性方面的问题。这样，服务模型中的任何需求的变化，都会反映到用户每天的业务处理中。同样，由于底层技术是模型驱动的，技术专家也可以根据这些变化的需求迅速而有效地作出应变。

      SOA实践和过去解决企业架构传统方式的不同之处就在于其对敏捷性的支持。如前所说，SOA的第三条原则就在于它总在变化之中。这种恒在的变化性环境是SOA实践的基石。如图所示，涉众（stakeholders，译者注：RUP中也有这个词，表示软件开发中涉及到的各种角色如：用户、设计人员、开发人员乃至测试人员等等。）在一个必需的基础上影响到整个架构的变化。在当技术专家在每天的日常工作中不断对变化的业务需求作出响应的这种情况下，设计阶段和运行阶段之间的界限变得模糊起来，很难清晰地分离这两个阶段。

      剩下的部分

      我们已经为面向服务的架构提供了一个高层次的框架，其中MDA和AM的元素帮助工具的使用者来创建和维护SOA。但是，SOA中还缺少一些内容－那就是软件开发商和专业的服务组织必需提供的。理想情况下，开发商必需提供面向服务的业务流程、工作流以 及服务的协调工具和服务；另外，能够以一种敏捷的、平台无关的方式充分反映业务服务的建模工具也是必须的；技术专家必须配备可以从模型中自动生成代码，并 在代码变化时更新模型的工具，最后，开发商必须提供支持SOA的软件，帮助面向服务的架构设计师以一种可信并且可伸缩的方式创建位于服务和底层技术之间的 抽象层次。幸运的是，这方面的产品即将上市。

      另外，最重要的就是贯穿本文的自顶而下的SOA实现方法了。今天关于Web services的大部分思考都是自底而上的：“这是如何创建Web services的方法，现在，我们来使用它们集成吧”，对Web services技术的这种方法是伟大的第一步，因为它可以惊人地降低集成的开销，这是现在的技术管理人员最乐意见到的了。但当经济进一步发展，IT走出 低谷，企业会寻求IT的帮助来提高组织战略意义上的核心价值。使用面向服务的架构，IT可以提供给企业实现业务敏捷性的这样一个框架。

四、为什么选择面向服务架构（SOA）？

　 　不同种类的操作系统，应用软件，系统软件和应用基础结构（application infrastructure）相互交织，这便是IT企业的现状。一些现存的应用程序被用来处理当前的业务流程（business processes），因此从头建立一个新的基础环境是不可能的。企业应该能对业务的变化做出快速的反应，利用对现有的应用程序和应用基础结构 （application infrastructure）的投资来解决新的业务需求，为客户，商业伙伴以及供应商提供新的互动渠道，并呈现一个可以支持有机业务（orGAnic business）的构架。SOA凭借其松耦合的特性，使得企业可以按照模块化的方式来添加新服务或更新现有服务，以解决新的业务需要，提供选择从而可以通过不同的渠道提供服务，并可以把企业现有的或已有的应用作为服务， 从而保护了现有的IT基础建设投资。

　　如图1的例子所示，一个使用SOA的企业，可以使用一组现有的应用来创建一个供应链复合应用（supply chain composite application），这些现有的应用通过标准接口来提供功能。

　　Figure 1. Supply chain application. Click on thumbnail to view full-sized image.

　　服务架构

　　为了实现SOA，企业需要一个服务架构，图2显示了一个例子：

　　Figure 2. A sample service architecture. Click on thumbnail to view full-sized image.

　 　在图2中， 服务消费者（service consumer）可以通过发送消息来调用服务。这些消息由一个服务总线（service bus）转换后发送给适当的服务实现。这种服务架构可以提供一个业务规则引擎（business rules engine），该引擎容许业务规则被合并在一个服务里或多个服务里。这种架构也提供了一个服务管理基础（service management infrastructure），用来管理服务，类似审核，列表（BIlling），日志等功能。此外，该架构给企业提供了灵活的业务流程，更好地处理控制请求（regulatory requirement），例如Sarbanes Oxley（SOX），并且可以在不影响其他服务的情况下更改某项服务。

五、面向服务架构（SOA）基础结构

　　要运行，管理SOA应用程序，企业需要SOA基础，这是SOA平台的一个部分。SOA基础必须支持所有的相关标准，和需要的运行时容器。图3所示的是一个典型的SOA基础结构。接下来的章节将逐一讨论该结构的每个部分。

　　Figure 3. A typical SOA infrastructure. Click on thumbnail to view full-sized image.

　　SOAP， WSDL， UDDI

　 　WSDL，UDDI和SOAP是SOA基础的基础部件。WSDL用来描述服务；UDDI用来注册和查找服务；而SOAP，作为传输层，用来在消费者和服 务提供者之间传送消息。SOAP是Web服务的默认机制，其他的技术为可以服务实现其他类型的绑定。一个消费者可以在UDDI注册表（registry） 查找服务，取得服务的WSDL描述，然后通过SOAP来调用服务。

　　WS-I Basic Profile

　　WS-I Basic Profile，由Web服务互用性组织（Web Services Interoperability Organization）提供，是SOA服务测试与互用性所需要的核心构件。服务提供者可以使用Basic Profile测试程序来测试服务在不同平台和技术上的互用性。

　　J2EE 和 .Net

　　尽管J2EE和。NET平台是开发SOA应用程序常用的平台，但SOA不仅限于此。像J2EE这类平台，不仅为开发者自然而然地参与到SOA中来提供了一个平台，还通过他们内在的特性，将可扩展性，可靠性，可用性以及性能引入了SOA世界。新的规范，例如 JAXB（Java API for XML Binding），用于将XML文档定位到Java类；JAXR（Java API for XML Registry）用来规范对UDDI注册表（registry）的操作；XML-RPC（Java API for XML-based Remote Procedure Call）在J2EE1.4中用来调用远程服务，这使得开发和部署可移植于标准J2EE容器的Web服务变得容易，与此同时，实现了跨平台（如。NET） 的服务互用。

　　服务品质

　　在企业中，关键任务系统（MISsion-critical system，译注：关键任务系统是指如果一个系统的可靠性对于一个组织是至关重要的，那么该系统就是该企业的关键任务系统。比如，电话系统对于一个电话 促销企业来说就是关键任务系统，而文字处理系统就不那么关键了。）用来解决高级需求，例如安全性，可靠性，事物。当一个企业开始采用服务架构作为工具来进 行开发和部署应用的时候，基本的Web服务规范，像WSDL，SOAP，以及UDDI就不能满足这些高级需求。正如前面所提到的，这些需求也称作服务品质 （QoS，quality of services）。与QoS相关的众多规范已经由一些标准化组织（standaRDSBOdies）提出，像W3C（World WIDE Web Consortium）和OASIS（the Organization for the Advancement of Structured InfORMation Standards）。下面的部分将会讨论一些QoS服务和相关标准。

　　安全

　 　Web服务安全规范用来保证消息的安全性。该规范主要包括认证交换， 消息完整性和消息保密。该规范吸引人的地方在于它借助现有的安全标准，例如，SAML（as Security Assertion Markup Language）来实现web服务消息的安全。OASIS正致力于Web服务安全规范的制定。

      可靠

　 　在典型的SOA 环境中，服务消费者和服务提供者之间会有几种不同的文档在进行交换。具有诸如“仅且仅仅传送一次”（ once-and-only-once delivery），“最多传送一次”（ at-most-once delivery），“重复消息过滤”（duplicate message elimination），“保证消息传送”（guaranteed message delivery）等特性消息的发送和确认，在关键任务系统（mission-critical systems）中变得十分重要。WS-Reliability 和 WS-ReliableMessaging是两个用来解决此类问题的标准。这些标准现在都由OASIS负责。

　　策略

　 　服务提供者有时候会要求服务消费者与某种策略通信。比如，服务提供商可能会要求消费者提供Kerberos安全标示，才能取得某项服务。这些要求被定义 为策略断言（policy assertions）。一项策略可能会包含多个断言。WS-Policy用来标准化服务消费者和服务提供者之间的策略通信。

　　控制

　　当企业着手于服务架构时，服务可以用来整合数据仓库（silos of data），应用程序，以及组件。整合应用意味着例如异步通信，并行处理，数据转换，以及校正等进程请求必须被标准化。在SOA中，进程是使用一组离散的 服务创建的。BPEL4WS 或者 WSBPEL（Web Service Business Process Execution Language）是用来控制这些服务的语言。WSBPEL目前也由OASIS负责。

　　管理

　　随着企业服务的增长，所使用的服务和业务进程的数量也随之增加，一个用来让系统管理员管理所有运行在多相环境下的服务的管理系统就显得尤为重要。WSDM（Web Services for Distributed Management）规定了任何根据WSDM实现的服务都可以由一个WSDM适应（WSDM-compliant）的管理方案来管理。

　　其它的qos特性，比如合作方之間的溝通和通訊，多個服務之間的事務處理，都在WS-COOrdination 和 WS-Transaction 標準中描述， 這些都是OASIS 的工作。

六、SOA 不是Web服务

　 　在理解SOA和Web服务的关系上，经常发生混淆。根据2003年4月的Gartner报道，Yefim V. Natis就这个问题是这样解释的：“Web服务是技术规范，而SOA是设计原则。特别是Web服务中的WSDL，是一个SOA配套的接口定义标准：这是 Web服务和SOA的根本联系。”从本质上来说，SOA是一种架构模式，而Web服务是利用一组标准实现的服务。Web服务是实现SOA的方式之一。用 Web服务来实现SOA的好处是你可以实现一个中立平台，来获得服务，而且随着越来越多的软件商支持越来越多的Web服务规范，你会取得更好的通用性。

七、面向服务架构（SOA）的优势

　 　SOA的概念并非什么新东西，SOA不同于现有的分布式技术之处在于大多数软件商接受它并有可以实现SOA的平台或应用程序。SOA伴随着无处不在的标 准，为企业的现有资产或投资带来了更好的重用性。SOA能够在最新的和现有的应用之上创建应用；SOA能够使客户或服务消费者免予服务实现的改变所带来的 影响；SOA能够升级单个服务或服务消费者而无需重写整个应用，也无需保留已经不再适用于新需求的现有系统。总而言之，SOA以借助现有的应用来组合产生 新服务的敏捷方式，提供给企业更好的灵活性来构建应用程序和业务流程。

八、采用服务驱动型方法的企业体验着以下业务和 IT 好处 

      面向服务架构的业务好处

      效率： 将业务流程从 " 烟囱 " 状的、重复的流程向维护成本较低的高度利用、共享服务应用转变。
      响应： 迅速适应和传送关键业务服务来满足市场需求，为客户、雇员和合作伙伴更高水准的服务。
      适应性： 更高效地转入转出让整个业务变得复杂性和难度更小，达到节约时间和资金的目的。

      面向服务架构的 IT 好处

      复杂性降低： 基于标准的兼容性，与点到点的集成相比降低了复杂性。
      重用增加： 通过重用以前开发和部署的共享服务，实现了更有效的应用程序 / 项目开发和交付。
      遗留集成： 用作可重用服务的遗留应用程序降低了维护和集成的成本。
      如今的服务驱动型企业都在体验着开发的高效率，服务的高可靠性和服务的高质量，以最大限度获得业务机会所带来的这些好处。

九、SOA在国际市场上反响强烈

      自2004年初业界推出SOA后，Bea、IBM、ORACLE、微软等业界巨头纷纷发布自己的SOA战略，建议用户在进行企业IT建设时考虑SOA。

      ZapThink调研公司在最近发表的一份报告中预测，到2006年，基于SOA架构(面向服务的架构)的中间件产品将成为网络化商业系统的主要设计思路，其中70％的商业企业公司将使用SOA架构。

      按照Gartner的预测，到2008年，SOA将成为占有绝对优势的软件工程实践方法，它将结束传统的整体软件体系架构长达40年的统治地位。届时，将有60％的商业公司在进行商业IT建设时会转向SOA。

      IDC预测到 2007年，包括软件、服务和硬件在内的SOA市场将达到210亿美元，其中商业企业方面的市场将达到120亿美元。

      综上所述SOA已经成为大势所趋，有着广阔的市场空间和巨大的发展潜力；而在商业企业中的应用，将成为SOA未来发展的一大亮点。

      SOA已经引起国内商业企业的重视

      国内基于SOA架构Web服务目前还是集中在一些企业内部，而国内一些有影响的行业用户正在搭建其核心业务系统，比如商业领域的流通行业和销售行业的大集 中正在起步。因此当商业企业需要更好地服务客户，需要更好地与上、下游合作伙伴协同工作，并且自己内部的核心业务之间也需要协同工作时，基于SOA架构中 间件产品就会为这类新的业务应用提供理想的底座，这种新的应用被称作面向服务的业务应用。

      现在，很多商业企业都准备在2006年内开始规划使用这些基于SOA架构的应用，可想而知，这些SOA架构的中间件产品将在两年内迅速发展，并在五年内在整个IT行业内获得广泛应用。

      商业企业信息化存在的问题

      商业企业信息系统多数处于封闭运行的状态，企业之间、企业与上游供应商、下游消费者之间信息不对称。商业企业之间无法形成协同效应。信息系统即无法满足消 费者的综合需求也无法达到企业间的商务协同自动化和智能化的需求。信息化的经济效益难以有效发挥。同时信息化标准不健全，如电子交换接口标准、业务流程协 同标准；流通中的票证、单据格式标准；电子数据交换所必须的结构化数据标准等。

     采用传统的系统架构技术和传统的EAI和B2Bi技术则存在系统封闭、厂商依赖性强、耦合度高、重用性差，扩展性差、无法和上下游企业的系统建立统一的接 口等问题。而采用SOA 技术则可以有效解决上述问题，由于SOA基于HTTP/SOAP/WSDL等开放式技术，对于特定厂商产品依赖性小；系统开放、互操作性强，可以建立统一 的WEB服务用于和不同的上下游企业信息系统实现供应链协同。由于SOA的松耦合特性、比较符合集团和各下属机构的商业关系，业务流程整合和项目协调的阻 力会有效降低。

      SOA以服务为基本单元，更加贴近于企业的商业活动，业务梳理和建模的复杂度会有效降低，重用性也会有效提高。另外采用SOA，企业IT系统所提供的服务 会更容易扩展、组合和变更，符合该集团目前业务发展变化较快的特点，可以有效的降低该集团IT系统的长期拥有总体成本。我们将该集团公司作为一个试点，推 进SOA技术的运用，来有效解决上述问题。

      “协同商务”的新经济时代即将到来

      采用SOA技术最终将使得各个商业企业之间、各个关联的经济实体之间实现高效实时的联接，使得整个产业链实现自动化的协同商务，将会有力的提高商业企业的 应变能力，转变现有的商业运作模式，转变经济增长的方式。SOA技术将促进信息系统在商业企业贸易活动中的全面渗入和发展，对于简单的贸易活动，将会由信 息系统自动化实现；对于复杂的贸易活动，信息系统将会为企业管理人员提供足够的决策信息并可以高效的执行决策。SOA技术的应用将会全面提高商务的自动 化、智能化和实时化水平。

      采用SOA技术实现协同商务可以提高城市范围内商流、物流、资金流和信息流的运行效率，扩大北京市商业企业整体规模效益，加强商业企业的整体对外竞争力， 拉动经济增长，降低企业运营成本，推动城市流通信息技术创新体系的建立，提高北京市流通现代化水平，促进城市管理现代化和城市社会经济信息化的进程。

      采用SOA技术可以将将物流企业、物业企业、商业企业、消费者整体整合在一起，对供应链关联企业、物流企业以及网上支付体系、安全认证体系等环境建设具有明显的带动作用，有利于促进支撑环境协同发展。

      促进商业企业信息化标准的制定，完善政府职能

      采用SOA技术为信息系统的沟通提供了技术基础，而随着SOA在商业企业的应用，必将促进统一的商业领域电子商务行业标准的发展和制定，对促进国家商业企业信息标准体系的建立和完善具有重要支撑作用。

      SOA技术为政府对商业经济的运行状况提供了实时监测和指导的技术可能性，将从根本上改变政府对社会经济的管理方式。

      基于SOA的协同商务带来的最直接的好处就是由于贸易范围的空前扩大而产生的全球贸易活动的大幅度增加，因而提高了贸易环节中大多数角色的交易量，因此， 全球范围的经济形势将向一个良好的增长趋势发展。它还可以扩大地方商业企业整体规模效益，加强商业企业的业务整合和商业协同效应，提高商业企业的整体对外 竞争力，通过协同商务有效降低企业运营成本，推动城市流通信息技术创新体系的建立，提高地方的流通现代化水平，促进城市管理现代化和城市社会经济信息化的 进程。

      SOA在商业企业的应用可以将物流企业、物业企业、商业企业、消费者整体整合在一起，对供应链关联企业、物流企业以及网上支付体系、安全认证体系等环境建 设具有明显的带动作用，可推动信息化各环节的全面应用与发展，有利于促进产业链和支撑环境协同发展，从而也创造了更多的就业机会和社会财富。

      信息产业是知识经济的核心和主要的推动力，而企业信息化又是目前信息产业中最具前途的发展趋势，因此说企业信息化的发展，必将直接或间接地推动知识经济的 浪潮。这种知识经济有着大量的无形成本和高附加值，在东南亚金融危机的同时，高科技给美国带来的是"高增长速度、高就业率、低通货膨胀率"。这也是我国在 宣传知识经济的热潮中应注意的一个真正有价值的切入点。

      SOA技术由于其前所未有的信息系统整合与自动协同能力，成为继互联网以来又一个革命性的技术，将会把目前基于WEB/互联网的知识经济推进到一个前所未有的新阶段。

十、SOA 企业考虑事项

      服务驱动型企业在对客户、合作伙伴和雇员的高效化服务方面得到了优化 -- 并加速了业务服务响应时间。然而，成为服务驱动型企业，需要的不仅仅是产品的部署。对实现服务驱动型架构感兴趣的企业将希望能与一个有经验的 SOA 提供商合作，它提供的服务可以保护企业在业务和 IT 方面的投入，他们考虑到了以下几个方面： 

      业务战略： 组织需要明确驱动关键业务流程的业务战略，它将用于成形 SOA 的框架。一旦识别出业务问题，就可以用一种一致的、可复用的方法对其进行定义，并实现解决方案。在这个关键的基础阶段，业务通常需要与一个拥有开发 SOA 业务战略经验、并能共享横向和纵向市场最佳实践的提供商进行合作。
      体系结构： 为了解决方案快速和动态的交付，企业必须开发一种允许装配组件和服务的体系结构框架。通过与有经验的 SOA 提供商合作，企业可以获得相应的参考案例，以快速搭建一个关注复用、避免 " 烟囱 " （ stovepipe ）式应用程序和 IT 资源 " 孤岛 " 的体系结构。此外，有经验的 SOA 提供商还可以帮助企业对项目的易管理性进行设计。

      构建模块： 不管是对体系结构还是对编程模型来说， SOA 都是是思考构建软件模型的一种优秀方式。与 SOA 提供商进行合作能让组织能够识别可在 SOA 实现中使用或重用的构建模块代码、服务、应用程序和组件。与有经验的 SOA 提供商进行合作还有一个好处，企业可以获得对构造组件、企业域（ domains ）、服务和规范数据模型的参考经验。

      项目和应用程序： SOA 创造了一种在更强大、更灵活的编程模式中搭建应用程序的新方法。与 SOA 提供商合作的企业可以更好地识别将被合并到 SOA 结构体系中的现存的和正在使用的应用程序。有经验的 SOA 提供商还将引导项目基础架构的搭建，并对正在进行中的项目提供有效的管理。
成本和收益： 在一个 SOA 项目中，开发和维护成本将大大削减，。有经验的 SOA 提供商可以帮助企业构造 SOA 基金模式，并构建 " 行动案例 " ，包括评估基础构造成本和效益、实现项目的最佳投资回报（ ROI ）以及开发商务案例。

      组织和统辖： 组织需要为新的面向服务的 IT 组织识别角色和职责，并优化经验集便于以后使用。有经验的 SOA 提供商可以帮助企业实现这些目标，同时组织一个有效的设计 " 复用工厂 " （ Reuse Factory ），帮助定义统辖模式，并最终保证客户满意。