动态Web services

动态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之间直接路由数据而定义网络的拓扑选择上以最大的灵活性。

•组件级别的安全

     一个SOP给予管理员以完全控制是哪个services被执行，在哪执行，同时确保安全。

SOP让管理员为每个services设定任何数量上的安全属性，并且提供工具配置在任何网络上的点服务的安全设定。

•执行期监测、跟踪和日志

      一个SOP为执行期监测、跟踪和日志包含自身、服务级别支持。所有的services能通过可视化工具进行监测。跟踪级别能在已部署的services上动态改变，并且调试日志能被在任何节点上的软件工具路由传送。这些特点大大简化了在SOP运行的分布式应用的开发、部署和调试。

 •支持可视化过程合成和改变管理工具

一个SOP包含应用程序接口（API）以支持软件工具的开发，它允许分布式应用的迅速合成，通过使用拖和点services面版上的可视图标来构建应用设计者的商业过程。这同一环境也允许监测所有分布式网络上的所有services。

•支持企业标准

一个SOP使用基于标准的Java 消息服务（JMS）与标准的XML进行消息交换，使用XSLT数据能被翻译成Tifosi  SOP和其它任何应用或服务格式。一个组件解决开发包（SDK）让使用者能连接任何使用SOP的已存在的组件或服务。其它企业标准，例如简单邮件协议（SMTP）和简单网络管理协议（SNMP），使得其能与其它企业系统进行集成。

•支持通用目的的services

一个SOP也支持不是实现为特定Web services的组件集成。一个通用目的的service能有任何不变数量的输入和输出端口，而一个Web service逻辑上仅有一个输入和一个输出端口。在他们的集成努力下，通用services为企业提供额外的灵活性。经常，它较容易模型化遗留程序代码为通用目的的软件service而不是特定的Web service。

 

结论

为EAI、BPM和相关企业问题以存的方法不能完全满足这些问题对潜在基础结构的需求。基于service的结构，在完全分布式、对等网络、事件驱动系统上的实现，为企业平台空间带来了整个新级别的通用性。

SOP实现了这种方式，阐述了BPM在应用和人们交互级别上的需要。它在企业内或跨企业的、跨领域的（包含被不同传统解决方案服务的领域）阐述了这些需要。为了所有的分布式计算的需要，为了节省时间和金钱，为了增加跨部门的处理效率，一个SOP保证允许一个企业建立一个统一的计算基础架构。

 

 

About the Author

eAI Journal • April 2003 19

Atul Saini is CEO

and chief technical

officer of Fiorano

Software. Through his

leadership, the company’s

flagship product,

FioranoMQ, has

become a leading

 

 

 

本文地址：http://com.8s8s.com/it/it45439.htm