合并三维的 SOA 整合中心

将您的 SOA 合并成三维空间的整合中心，以提高 Web 服务的互用性。Judith M. Myerson 给出了四个合并的实例:非共享的 SOA 的二维中心、共享的 SOA 的二维中心、共享的 SOA 的三维中心的两种视图。权衡各种利弊，确定三维空间中的整合中心可以承载的 SOA 的最大数目是非常重要的，使得能够避免中心超负荷。

　　引言：在本文中，我将谈论如何将 Web 服务及非 Web 服务的多重 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 服务。

图 1. 非共享的 SOA 的二维中心

　　　　

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

　　二维共享的 SOA

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

图 2. 共享的 SOA 的二维中心

　　　　

　　代表三维空间中的中心

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

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

　　第一个三维中心

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

　　　　

图 3. 第一个共享的 SOA 的三维中心

　　如您所见，连接器从 RFID SOA 通过(而不是环绕)物流 SOA 到主机网关。这意味着从 RFID SOA 而来的连接器与物流 SOA 共享了一些资源。第二个三维中心

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

　　　　

图 4. 第二个共享的 SOA 的三维中心

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

　　有多少共享的 SOA?

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