Table 2. The six approaches to SOA

Table 3. Patterns and their corresponding benefits

Often an initial challenge is the concrete determination of the value proposition for using SOA within a project, line of business, or organization. This has to do with flexibility and the ability to alter the actual service provider who implements a service once their quality of service dwindles or they fail to provide the required functionality. This flexibility, which is the primary value of SOA, is overcome by understanding the steps in achieving flexibility through a remote service strategy. There are two more challenges that we describe and overcome with the use of patterns presented here.

SOA is a journey of gradual, small transformations that increasingly decouple service descriptions from service implementations offered by multiple service providers. The solutions below are descriptions of how these issues have been recurrently solved and may serve as a pattern to help you on your next project. Like any other pattern, these must also be adapted to fit the context and the forces that shape your individual problem space: the tradeoffs and considerations of your project, whether organizational or technical, make a difference, and you can determine if you need to skip a step from one pattern to another or to partially implement the pattern

The purely object-oriented strategy pattern primarily relies on inheritance-based polymorphism to create a family of interchangeable algorithms that are swapped out based on context. Rather than have an object hierarchy, in an SOA context, we need to be able to change the service provider with minimal or no impact on the consumer?s perception of the service, thus varying the actual implementer of the service description. The implementer may, in most cases, be a provider of a remote unit of functionality, somewhere in the internal network or Internet. Therefore, for
example, a service provider for a VerifyAddress service in an OrderEntry application may need to be changed because our quality of service needs have changed due to higher transaction volumes or security constraints. Or, the provider has decided to charge twice the amount for the same basic service, which we have relied on, in the past. Now, we would like to have the flexibility of changing service providers with IT and Business impunity, which means minimal changes to IT systems and no impact on the business or customer experience in their online shopping experience.


以上是今天看得两篇英文文章中一些摘要，文章很长，说实话没看太明白。只能在文章中找一些比较重要的东西贴在这，希望能有用。
原文链接：http://www-128.ibm.com/developerworks/webservices/library/ws-soa-soi/
                     http://www-128.ibm.com/developerworks/webservices/library/ws-soa-soi2/

6. 开发过程

尽管以服务为中心的企业集成在开发阶段和普通的应用开发并没有本质的区别，但是它在角色，职责、工具和方法还是有不少自己的特色。下图汇总了本文示例中开发角色，职责，开发方法和工具，仅供大家参考。

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. 描述和决策

现在，让我们更加仔细的描述一下每一层以及每一层之间的合成。

层 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 实现服务质量的标准。

• 企业资源规划（Enterprise Resource Planning，ERP）
• 客户关系管理（Customer Relationship Management，CRM）
• 供应链管理（Supply Chain Management，SCM）
• 其它企业应用程序集成（Enterprise Application Integration，EAI）的应用程序
• 虚拟的数据库管理系统

我也将讨论中心如何接受输入数据——事件和数据——来源于各种资源。我使用 X、Y 和 Z 轴在三维空间中展示图片。

什么是 SOA 整合中心？

SOA 整合中心是 Web 服务与非 Web 服务的合并的 SOA 与后端企业系统的集成。它使得 Web 服务及非 Web 服务能够与运行在不同平台上的服务器、主机和微机上的企业系统交互。

然而，SOA 整合中心不同于面向服务的整合（service-oriented integration，SOI）。SOI 将 Web 服务与运行在不同平台上的主机系统相整合。它使得 Web 服务能够通过网关与主机交互。您需要 ASP.Net 或其它技术获取网关来执行普通的 Web 服务。

SOA 是基于一套业务流程的 Web 服务的交互的体系结构。您可以在第一个 SOA 中获取 Web 服务来在第二个 SOA 中复用代表 Web 服务的服务。Web 服务可能由一些小的 Web 服务组成，它们将服务传递给客户。

您使用描述语言（例如，SOAP）或其它描述交互的方法（例如，REST）来定义交互。每个交互都是独立且松耦合的，以便每个交互都能独立于任何其它交互。这与依赖网关来与 Web 服务集成的紧耦合的主机系统形成对照。

SOA 层

我们看一下二维空间中的 SOA 层。之后，我将向您展示为何三维的整合中心是更好的选择。

SOA 的 IBM 版本的前五层（请见参考资料）是（从下至上）：

• 操作系统
• 基于组件的（系统）
• 服务
• 业务流程
• 表示层

第六层是集成体系结构（也作为企业集成总线（Enterprise Integration Bus）），它垂直覆盖了前五层。下一层是服务质量、安全、管理及监控层。

显而易见，操作层由 EAI 打包的应用程序、遗留、老式的面向对象及商业智能应用程序组成。它们都可以通过使用 SOI（在项目级或企业级）来同第二层的基于组件的系统相集成。然后，将组件结合或集成到复合应用程序中来提供第三层的服务。

第四层向您展示了那些服务是如何根据一套业务流程从一个流向另一个的。更高一层通过远程门户网站 Web 服务（Web Services for Remote Portlet，WSRP）标准或其它面向人的表示层的方法来将 Web 服务应用于应用程序接口中。

二维静态的 SOA 可能是有问题的。幸好，整合中心的发展意味着 SOA 将变成三维动态的。

可复用的体系结构

我们假设该 Web 服务需要在 .Net 平台上或随后的 WebSphere 平台上运行前从主机系统获取信息。您需要将 Web 服务与执行普通 Web 服务的主机网关相整合。

所有 Web 服务彼此以 XML 传递信息——多个 SOA 中的业务流程应当如何整合及其在提供的服务中如何实现。虽然在多个 SOA 中 Web 服务是可复用的，但是我进一步将 SOA 处理成可复用的体系结构。

我有多个实例，它们关于将可复用的 SOA 合并成与主机系统相连的整合中心，我提出如下四步来创建中心：

1. 将作为可复用的体系结构的 SOA 数组划分成两个模块。第一模块主要包括整合 Web 服务的机制，而第二个模块重在服务交互。
2. 为了获得最佳的速度及可靠性，将每个 SOA 优化成更紧凑的形式。检查可能影响性能的磁盘碎片空间。
3. 将 SOA 按照重要性及复用频率区分优先次序。检查用户对于更改 SOA 优先权的需求。
4. 将 SOA 合并成连接到一个或更多主机系统的整合中心，这些主机系统运行在不同的平台上。检查先前没有被提出的互用性问题。

模块化的 SOA 库

您可以开发模块化的和优化的 SOA 库，这些 SOA 被分成了不同类别的层次。每个类别可以通过层次最低级别的 Web 服务被进一步划分成 SOA 的子组。

您可以将库用作到 Web 服务应用程序的动态链接。当应用程序需要访问模块化的 SOA 时，它将自己链接到库中。当它不再需要检索到的 SOA 时，将从库中释放自己，当提高速度及性能时节省磁盘空间。

下列是库中模块化的 SOA 的一些实例：

• 卫生保健 SOA
• 零售管理 SOA
• 物流 SOA
• 无线射频识别（Radio Frequency Identification，RFID）SOA

库用例

假设您使用在库中使用最后三个 SOA（零售管理、物流和 RFID）来开发整合中心并将它们连接到主机网关中。今后，用户的需求改变了——取消零售管理 SOA 并以卫生保健 SOA 代替它。

同时，用新版本更新物流 SOA 使其迎合用户的需求。在 RFID SOA 中包含新的子组之后，将所有子组区分优先次序并将它们优化。

二维非共享的 SOA

我们看一下 Blue Repository 中的三个模块化的 SOA（零售管理、物流和 RFID）的二维中心（请见图 1）。所有都连接到主机网关中。例如，如果您使用 ASP.Net，那么您可以通过网关来执行普通的 Web 服务。

如您所见，SOA 不是共享的。您可以将这三者结合成复合应用程序以减少到主机网关的连接器的数目。

二维共享的 SOA

如图 2 所示，RFID SOA 与物流 SOA 在一边相交叠。交叠区域用黄色带黑色斜线来显示。它包含 SOA 用于生成一个或两个服务的资源。

代表三维空间中的中心

您怎样在二维计算机屏幕上设想三维的中心？处理该问题的一种方法是在二维平面中画出整合中心的 X、Y 和 Z 轴。另一种方法是使用软件简单地将 2D 图片转换成 3D 的版本。

在三维的中心，您可以在不改变 SOA 的情况下将现有的主机替换成新样式或另一供应商的样式。另外，您可以重新配置或更改 SOA 的优先权以适合新的或已更新的主机系统对于更改用户及组织的需求的响应。

第一个三维中心

考虑如图 3 所示的三维空间中的整合中心。如您所见，RFID SOA 中部分位于物流 SOA 之后。RFID SOA 的隐藏部分用到物流 SOA 的蓝色线画出。

如您所见，连接器从 RFID SOA 通过（而不是环绕）物流 SOA 到主机网关。这意味着从 RFID SOA 而来的连接器与物流 SOA 共享了一些资源。

第二个三维中心

设想 RFID SOA 的重叠部分在物流 SOA 的前面，但是不是从任一侧，如图 4 所示。这给了 RFID SOA 更多的选择来共享物流 SOA 中的大量资源。

如您所见，连接器从 RFID SOA 通过物流 SOA。

有多少共享的 SOA？

在三维中心中您可以共享的 SOA 的数目依赖于项目复杂性、合并问题及业务流程中的利弊。向您避免 SOA 的过量开销一样，您需要确保在开发的整个生命周期中不会在三维空间中发生中心超负荷的问题。您应当在周期的每个时刻都测试超负荷。

结束语

在三维中心中合并 SOA 需要预先规划来设置开发和共享的 SOA 的数目限制。您应当同业务分析师开发组交流有关各种合并问题的信息。您将发现解决合并问题会使您开发三维中心的工作变得非常容易。您可以开发在中心可复用和共享的 SOA。分析师将发现解决该问题会使他们的设计和分析三维空间的中心的工作变得非常容易。他们可以确定在不会导致中心超负荷的前提下哪个主机系统可以连接到中心。

讨论至此，集成已限定为通过基于组件的服务进行的应用程序的集成，但是集成这个主题比这要宽泛得多。在估计一个体系结构的需求时，必须考虑一些集成的类型或“方式”。您必须考虑如下几方面：

• 应用程序集成
• 终端用户界面集成
• 应用程序连接
• 流程集成
• 信息集成
• 构建集成开发模型。

终端用户界面集成涉及如何集成特定用户访问的全部应用程序和服务来提供可用、高效、一致的界面。它是一个正在发展的主题，而新的发展在近期将主要取决于 Portal 服务器使用方面的进展。虽然 Portlet 已经可以通过 Web 服务调用本地服务组件，但是新技术（比如用户远程 Portlet 的 Web 服务）将使内容和应用程序提供者能够创建交互式服务，这些服务在因特网上可以通过 Portal 即插即用，从而为很多新的集成提供了可能。

应用程序连接是一种集成方式，它涉及体系结构必须支持的所有类型的连接。在一个层次上，这意味着数据的同步和异步通信、路由、转换和高速分布、以及网关和协议转换器等等。而在另一个层次上，它还与输入和输出或源（sources）和汇（sinks）的虚拟化有关，正如您在 EWA 的通道（Channel）和协议转换程序（Protocol Handlers）中所看到的。这里的问题在于数据移入、移出以及在实现体系结构的框架中移动的方式。

流程集成涉及开发映射到业务流程和为业务流程提供解决方案的计算流程、将应用程序集成到流程以及集成一些流程与其他一些流程。虽然第一项需求可能看起来似乎无关紧要，不过就是体系结构提供一个模拟基本业务问题的环境，但是，如果在这一层中不进行充分的分析，体系结构的任何实现注定都将失败，不管它采用的技术是多么的巧妙。将应用程序集成到流程可能包括企业中的应用程序，也可能涉及调用远程系统中的应用程序或服务，而这些远程系统多半属于业务合作伙伴。同样地，流程层集成可能涉及整个流程的集成而不仅仅是来自外部源的单个服务，比如供应链管理或金融服务这样横跨多个机构的流程。为了满足这样的应用程序和流程的集成需求，可以使用像 BPEL4WS 这样的技术，而应用程序框架也可以使用程序配置 Scheme（比如在 EWA 中看到的）。实际上，可以在底层使用 BPEL4WS 来构造一个高层配置 Scheme，然后通过一个引擎来驱动，这个引擎不仅提供流管理，而且还提供其他功能。然而，在构建这一切之前，您应该首先了解体系结构方面的需求，然后，再构建合适的基础架构。

信息集成是一个流程，其作用在于为所有需要它的应用程序提供对企业中全部数据的一致访问，而不管这些应用程序是以什么形式需要它，也不受数据的格式、来源或位置的限制。在实现时，这项需求可能包括 适配器和转换引擎，不过它通常要比这复杂。而关键的概念往往是数据的虚拟化，这可能包括 数据总线（Data Bus）的开发，企业中的所有应用程序都通过标准服务或接口从数据总线中请求数据。因此，不管数据是来自电子数据表、本地文件、SQL 或 DL/I 数据库，还是来自内存中的数据存储，都可以将数据提供给应用程序。永久存储中的数据格式可能还不为应用程序所知。应用程序更不知道管理数据的操作系统，因而访问 AIX 或 Linux 系统中的本地文件的方式与这些文件放在 Windows、OS/2、ZOS 或其他系统中时访问它们的方式相同。同样地，数据的位置也是透明的；由于它是由共同的服务提供的，所以是由访问服务而不是由应用程序来负责查询数据（无论是本地的还是远程的），然后按照请求的格式提供数据。

应用程序开发环境的最后一项需求是，必须考虑可能在企业中实现的集成的所有方式和层次，并且为它们的开发和部署做好准备。要想真正做到健壮，开发环境必须包括（和执行）一种方法来明确地规定如何设计和构建服务和组件，以便促进重用、消除冗余和简化测试、部署和维护。

上面列出的所有集成方式在任何企业中都有一定程度的体现，尽管在某些情况下它们可能是简化的，或者没有明确地进行定义；因而，在着手设计新的体系结构框架时，您必须全面的考虑它们。特定的 IT 环境可能只有很少的数据源类型，因此，消息集成可能会很简单。同样地，应用程序连接的作用域可能也很有限。虽然如此，如果希望框架能够随着企业的成长和变化成功地继续得以保持，则框架中的集成功能仍然必须由服务提供，而不是由特定的应用程序来完成。