Service-Oriented Architecture：概念模型

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

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

图 1：SOA 架构样式的概念模型

回页首

架构样式和原理

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

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

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

图 2: SOA 的属性

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

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

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

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

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

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

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

除了本文中描述的鉴别、制定和实现之外，基于服务的建模方法还包含了支持完整 SOA 生命周期的部署、监视、管理和控制所需的技术。

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

回页首

SOA 的一个架构模板

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

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

图 3：SOA 层

对于每一层，你都必须做设计和架构决定。因此，为了帮助用文件说明你的 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：操作系统层。本层包含现有的自定义构建的应用程序，也叫做 遗留系统，包含现有的 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 实现服务质量的标准。