** 动态 ** ** Web services ** ** 作者： ** ** Atul Saini ** ** **
在今天的商业环境中，重要信息存在与企业的许多异构系统中。
其包括：
• 客户关系管理（ CRM ）系统
• 金融会计系统
• 企业资源安排（ ERP ）系统
•Web servers
• 遗留系统
这些信息必须通过多触点访问，这些系统已典型地演变为内部隔离的机构。他们注重与产品线和部门职能而不是客户的需要，虽然如此，这些系统还是包含有战略性数据。
包含了重要信息的额外系统通常需要组合，所以商家极力寻找集成和商业过程管理（ BPM ）解决方案，这能扩展先前投资的寿命和增加投资的生产力。
现在有几个平台能实现 Web services ——最著名的不同卖方的 J2EE 应用服务和微软的 .NET Web services 都能提供基于标准的企业内或跨企业的数据存取方案。基于 Web services 的实现集成解决方案允许企业动态减少与企业应用集成相关的传统高额费用，这是因为 Web services 解决方案是基于工业标准的，不需要应用和产品所有者的特定知识。就因为此，许多企业愿意为 EAI 和 BPM 采取基于 Web services 的解决方案。
** EAI ** ** 的平台需要 ** ** **
** ** 不是所有的 Web services 平台能被用于 EAI 的 out-of-the-box 。这些问题包含在实现分布式 EAI 和 BPM 的解决方案中，在潜在的平台中增加特殊的需要。这节剩下部分就要讨论该需要，其是高效性和可扩展性所必需的。
• ** 完全分布式、对等网络、基于事件的架构 **
真实的商业过程是典型的多应用、多硬件和多软件系统的分布式的；他们也是基于事件的，这是因为这些过程是典型的通过一系列事件连接在一起的。因此，一个平台应能努力实现企业内和跨企业需要的商业过程集成，它需要在完全分布式节点上运行这些过程。一个有效的 EAI/BPM 平台必须需要一个对等网络的架构，用软件引擎方法来开发，强调其各种安全性，控制权，动态访问和灵活性。该平台必须是对称的，这意味着同样基于事件基础结构的软件需要执行在企业内的所有机器上。大部分 EAI 和 BPM 解决方案通过中央系统控制商业过程，这样，应用的改变或增加新的应用，就需要在中央系统改变。这种拓扑就存在效率低不够灵活性，从而导致在分布式系统中瓶颈的存在。
• ** 过程路由透明 ** ** **
一个 EAI 基础架构平台应该在组成解决方案的不同过程中提供完全透明的信息流。为了提供不用任何编程的灵活的改变管理能力，系统内各组件对过程的信息路由应该是无须考虑的。
• ** 基于 ** ** service- ** ** 架构的灵活性 **
一个 EAI 平台应该保证其易于部署、管理和能改变参与的过程。这意味着一个基于组件的架构，在这个架构中的应用是由粗糙的组件松散组合的，它们通过基于事件的消息相互束缚，每个 service 潜在地运行在分离过程中。这容许一个快速的部署模型，减少实现解决方案的引导时间。这个架构提供对飞速修改的过程的支持工具，所以分析员能改变和即时重部署过程以满足商业需求的改变。
** • ** ** 远程部署、监测和管理 ** ** **
一个 EAI 基础架构平台应该能提供在网络上的部署、管理和监测的方法。它也应该支持对数据和事件的实时监测，这将明显减少时间和分布式商业过程的部署花费。
• ** 企业标准支持 ** ** **
为了对数据交换、消息传送支持，现存的企业标准和 BPM 能动态减少 EAI 基础架构的整个花费。它无须考虑特定的需要或在部署方案中特定的知识，因为在商业伙伴之间需要交换的内容，扩展标记语言（ XML ）消息和文档就是所期望的格式。大部分的商家欲用已存架构中的消息、组件、 services 、企业数据、轻权路径访问协议（ LDAP ）路径服务、 e-mail 系统，等等来开发系统。所以一个 EAI 平台需要保证容易实现这些标准。
** 现在 ** ** Web services ** ** 架构存在的问题 ** ** **
虽然为了 EAI 对 Web services 的兴趣很高，但是现在的 Web services 平台对实现 EAI 还存在一些问题。这些已存 Web services 平台的原则问题（包括基于 J2EE 应用服务和微软的 .NET ）是：
• ** 请求 ** ** / ** ** 答复语义效率低 ** ** **
现存的 Web services 平台是典型的基于请求 / 答复语义的，每个 Web services 通过使用简单对象访问协议（ SOAP ）请求联系，然后模块等待，直至结果返回给调用者。平台是基于投票表决和需要人工编码来获取 Web services 的输出的，并把它传递给不同的 Web services 或在工作流内的应用。在 Web services 内的数据流缺少事件总线，从而使得 EAI 解决方案中以存的 Web services 平台效率低下。
• ** 集中、不可升级的架构 ** ** **
** ** 现在的 EAI 解决方案通过中央系统控制商业过程，应用的改变或新的应用就需要改变中央系统。而且，在应用间的所有数据交换需要经过中央系统，这种拓扑结构将导致分布式系统的瓶颈，并且引起明显的效率低和不灵活。
• ** 缺少远程部署、监测和日志 ** ** **
** ** 典型的分布式系统有许多 services 运行在跨网络的不同机器上，如果任何这些 services 服务失效，在这系统上的其它组件应该被提醒。一个 EAI 平台应该要为这样的分步式的监测提供 services 的建构，还要加上远程跟踪和日志设施。在远程节点上自动部署 Web services 的另一个目的是可以减少维护和实现的费用。存在的中央 Web services 平台没有对远程 service 部署的支持，这是因为网络的刹车没有为部署提供基础架构级别的支持，导致为了解决方案的开发和部署增加了时间。 ** **
** 使用 services ** ** 操作平台 **
现在 Web services 基础结构平台不能解决相关 EAI 和 BPM 的核心问题，这些问题最好是采用事件方式的 Web services 解决，即我们所提到的动态 Web services 。最好在完全分布式情况下实现，有事件的基础架构我们称之为 services 操作平台（ SOP ）。 SOP 便于分布式的企业应用使用可视化工具进行合成、部署、和修改。一个强大的 SOP 就在于它能为公司的 EAI 、 B2B 集成、 BPM 、合作和通用分布式计算需要提供一个单一整体平台。
图 1 所示为一个典型 SOP 节点的架构。在一个典型企业中，基于这种架构的每个网络节点都运行着一个 daemon ，这些 daemon 通过消息总线相连接，就如图 2 所示。从图 1 中可以看到，一个 SOP 提供为基于事件的消息、透明过程路由、远程监控跟踪和日志、时序安排、现场和可用性、安全和远程部署提供构建支持。
一个 SOP 是个纯粹的基础架构平台，它允许任何种类软件的 services 实现，包括 Web services 。它不同于现存的 Web services 实现就在于它需要一个完全的分布式的对等网络的使用消息的基础架构，而不是一个中央请求 / 答复的基础架构。一个 SOP 能为客户提供这些优点。
• ** 基于 ** ** services ** ** 的应用合成 ** ** **
部署在 SOP 上的应用是由一个或更多的 services （或组件）复合而成的，每个 service 随意运行在分离的进程中。 Services 可能是任何语言编写的并通过 XML 消息相互通信。这允许该结构是灵活的且易于修改的系统。
• ** 在飞速的商业过程中部署和改变 ** ** **
在 SOP 上的动态 Web services 实现是粗糙的 services ，它们很理想是易于改变和替代，而且在 SOP 上的 services 实现是很明显的在 services 距离间路由。这使得它商业过程的飞速的修改动态服务替换或增加变得简易。一个 SOP 也支持执行期 services 的部署，允许改变商业过程为通过网络的即时部署，与传统的解决方案相比这将是数量级上地降低部署费用。
• ** 错误容忍性、可测量性，可靠性 **
SOP 对称的对等网络的结构提供了高可测量可靠的平台，它没有一个单点的失误，缺少中央系统给予了应用开发者在所需 services <SPAN style="FONT-SIZE: 9pt; COLOR: #