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

　　引言

　　在企业级SOA系列文章的第二篇——“使外部Web服务互操作性最优”中，我给出了不会导致多个SOA超负荷的服务互用性的实例——从简单的协议共存到复杂的多平台的互用性。我谈论了有关您如何使用Visual Studio .Net来开发Microsoft? .Net平台上的Web服务以及如何在IBM? WebSphere? Application Server上运行它们的相关问题。

　　在本文中，我将谈论如何将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合并成与主机系统相连的整合中心，我提出如下四步来创建中心：

　　·将作为可复用的体系结构的SOA数组划分成两个模块。第一模块主要包括整合Web服务的机制，而第二个模块重在服务交互。
　　·为了获得最佳的速度及可靠性，将每个SOA优化成更紧凑的形式。检查可能影响性能的磁盘碎片空间。
　　·将SOA按照重要性及复用频率区分优先次序。检查用户对于更改SOA优先权的需求。
　　·将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的过量开销一样，您需要确保在开发的整个生命周期中不会在三维空间中发生中心超负荷的问题。您应当在周期的每个时刻都测试超负荷。

　　结束语

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