使外部和内部Web服务之间多个面向服务的体系结构(Service-Oriented Architectures，SOA)中的外部Web服务的互操作性最优。Judith Myerson展示了如何更改服务的类型、位置以及每个Web服务的平台，以便实现原始应用程序的业务流程。

　　引言

　　在关于企业级面向服务的体系结构(SOA)系列我的第一篇文章，“使用多重SOA来消除企业系统之间的差异”（参阅参考资料）中，通过说明如何重用一个或多个SOA中的Web服务（以数据为中心(data-centric)和业务逻辑），然后将他们联合到一个受组织控制的组合应用程序中，讨论了使用SOA缩小企业系统差异的方案。

　　当Web服务不受组织所控制时，需要确保它们在外部可以彼此互操作，来共享语义和契约职责。语义的误解（例如所有权）和契约漏洞（例如多平台间的区别）会影响外部企业Web服务之间的互操作性问题。

　　在本文中，我展示了四个实现制造资源规划(Manufacturing Resource Planning，MRP)和客户关系管理(Customer Relationship Management，CRM)服务的实例，如下所示：

　　·企业以前的应用程序
　　·到外部Web服务的动态链接
　　·请求外部Web服务的REpresentational State Transfer/Simple Object Access Protocol(REST/SOAP)共存
　　·使用IBM? WebSphere? Application Server和Microsoft? Visual Studio .Net的Web服务互操作性

　　考虑各种交易时，确定系统可以负载的可互操作的SOA的数量非常重要，这样可以避免SOA过载。

　　企业以前的应用程序

　　假设企业以前的应用程序（参见图1）被分成业务流程的模块化组件。该应用程序的两个重要组件（MRP和CRM）要求不断发生变化且重新编译长期运行的应用程序。

　　图1. 企业以前的应用程序
 
　　动态服务链接

　　为增加运行效率，从应用程序中提取出这些组件并将其重新构建为外部Web服务更有意义。通过这种方式，您可以更改两个Web服务的代码，而不用重新编译庞大的、复杂的长期运行的应用程序。

　　在第一个SOA（参见图2）中以更加紧凑的形式重新设计的应用程序可以动态链接到第二个SOA中的外部企业MRP Web服务，依次的，指向第三个SOA中的外部企业CRM Web服务。一旦收到请求，CRM Web服务将请求和信息发送给应用程序来进行进一步处理。

　　图2. 到Web服务的动态链接
 
　　每个链接机制都是以发送请求或消息，接收响应，或执行SQL或HTTP操作的形式出现的。还可以封装没有MRP组件的应用程序，这样就可以向MRP Web服务发送请求。

　　软件架构

　　需要牢记，在从一个协议转换到另一个，或者从一个软件架构转换到另一个时，可能会引起平台间的互操作性问题。一些实例包括SOAP、REST、.Net架构、企业Java Bean (Enterprise Java Beans，EJB) 以及Java消息服务 (Java Messaging Service，JMS)。

　　运行在HTTP上的.Net Web服务可以以三种不同的方式调用：HTTP GET操作、HTTP POST操作和SOAP。如果需要快速的调用Web服务且没有SOAP客户端的话，GET和POST操作都是非常有用的。可以通过Perl脚本在HTTP上使用REST来执行GET、POST、PUT和delete操作。在这个脚本中，您可以指定SQL查询和简单的消息队列。

　　如果SOAP客户端可用，下面是如何在REST和SOAP之间进行简单的选择。如果应用程序是基于资源的，选择REST。如果应用程序是基于行为的，选择SOAP。在REST中，客户端可以通过HTTP请求执行在一系列资源上的多个操作。对于基于SOAP的请求，可能需要执行请求的每个面向活动的客户端可能仅需要一个调用操作。

　　调用框架

　　要构建SOAP请求，需要使用Web服务描述语言(Web Services Description Language，WSDL)，这是一种描述如何访问Web服务以及将执行什么操作的语言。您可以指定服务的类型，而不用自定义Web服务的代码，也不用重新编译以前的应用程序。

　　为确保WSDL文件能在各种软件架构中工作，您可以利用IBM Web Services Invocation Framework (WSIF)，它让您可以将WSDL作为不同软件标准来描述。这表明您可以通过描述语言周围的API以独立于协议和位置的方式访问WSDL。还意味着您可以通过WSDL将Web服务结合复合成应用程序，在WSDL中您可以在各种条件和异常情况下切换协议和位置。

　　为构建WSIF，无论您打算使用什么提供商，您都需要满足最低需求，该选项包括如下：

　　·JAXP XML解析器
　　·Java API的WSDL
　　·Apache SOAP
　　·Apache Axis。

　　REST和SOAP共存

　　虽然REST请求不像SOAP请求那样依赖WSDL，您仍需要XML Schema来验证REST操作。既然WSDL支持schema规范，REST和SOAP可以作为从一个合成的Web服务应用程序到外部应用程序的请求而共存。

　　例如，SOA #1（参阅图3）中的应用程序首先发送SOAP请求调用SOA #2的MRP Web服务中调用基于活动的服务，接下来发送一个REST请求来操作相同MRP Web服务中的面向行为的服务。所有基于SOAP的请求都是基于IBM WSIF的。

　　图3. REST和SOAP共存
 
　　正如您所见到的，第一个SOA里面的应用程序运行在Unix或者Linux服务器上，而第二个SOA中的MRP Web服务运行在IBM WebSphere Application Server(Application Server)中。您可以使用WSIF来更改基于SOAP的请求的规范版本中的服务类型和位置。

　　WebSphere和.Net产品的互操作性

　　如果您希望开发更加复杂的Web服务，作为Linux或者Window平台上的较大企业系统开发项目的一部分，可以考虑使用用于WebSphere软件的IBM Rational?Application Developer。它同用于Java?和EJB的统一建模语言(Universal Modeling Language，UML)Visual Editor一起提供，并且运行在Eclipse源码开放平台上，允许您扩展您的开发环境。还可以使用Microsoft Visual Studio.Net。

　　您可以使用软件来将应用程序逻辑分割成模块化的多业务流程Web服务组件。IBM通过提供Web Services Navigator（Rational Application Developer插件）更前进了一步，让您直观地同Web服务事务交互。

　　如果您正在使用Visual Studio.Net在Microsoft .Net平台上开发Web服务，可以在Application Server中运行它们。这意味着使两个平台之间的Web服务互操作（参阅参考资料），您所要做的只是开发与两种平台公用的WSDL。

　　例如，运行在Unix或者Linux服务器上的应用程序（参见图4）首先发送SOAP请求来调用运行在Application Server上的MRP Web服务的基于活动的服务。接下来，该应用程序发送一个REST请求来执行同样MRP Web服务上的一系列基于资源的服务。一旦收到请求，SOA #3中的CRM Web服务向原始应用程序发送一个请求或者信息。

　　图4. 多平台外部Web服务
 
　　正如您所看到的，第三个SOA中的CRM Web服务运行在.Net平台上并且访问Application Server。CRM Web服务向第一个SOA中的应用程序发送请求或者信息。您可以为Visual Studio.NET添加一个Visual Perl插件。您还可以使用用于Unix到Windows移植的命令行级别的基于REST的脚本，并且使其适应Visual Perl环境，这取决于简本的复杂性。

　　Visual Studio

　　对于您来说，使用Visual Studio .Net比Visual Basic、C++、Java、Kornshell来封装Unix应用程序为COM组件要更加容易。同样，如果您正在开发应用程序，使用Unix shell脚本来运行Window应用程序，或者如果您将Unix应用程序移植到Window平台下来链接到外部Web服务，使用它也非常容易。

　　这里有一些您应该了解的提示。首先，您应该将自己的WSDL文件发布到一个公共的位置来解决互操作性的差别。您可以跳过Rational Application Developer’s自底向上的方法或者Visual Studio .Net的WSDL First方法中的自动生成WSDL文件。可以使用Rational Application Developer的Skeleton 或者自顶向下的方法来启动您的WSDL文件并填充Java Class实现。或者，还可以禁用Visual Studio的WDSL First方法中的自动生成WSDL文件选项并且发布您自己的WSDL。

　　第二，要为自己提供一个可以使用的WSDL模板，可以考虑Rational Application Developer的自底向上的方法（从Java Bean开始），Rational XDE（基于类模型生成模板代码），或者Visual Studio的Implementation First Approach（在通过编写Web服务代码开始后生成模板代码）。然而Rational Application Developer提供了WSDL，Visual Studio.Net可能没有提供。

　　需要多少SOA？

　　用来连接EAI应用程序的SOA的数量取决于项目、互操作性问题、业务流程和负载性能问题之间复杂性的平衡。如果您避免了SOAP超标，您需要确保SOAP在开发的整个生命周期不会超载。您应该在周期的每一点上测试超载。

　　结束语

　　使多平台SOA之间的外部Web服务互操作性最优需要事先计划好可以开发多少SOA。您应该与业务分析团队和IT专家在各种性能问题上进行交流。您会发现解决互操作性问题将使您的开发工作变得更加得容易。您可以开发外部Web服务，每个服务可以使用不同的平台和请求协议。分析师将发现解决该问题将使设计和分析多个SOA系统的工作更加容易。他们可以确定Web服务可以运行在什么平台上，而不用导致SOA超载。

　　关于作者

　　Judith M. Myerson是一位系统架构师和工程师。她感兴趣的领域包括中间件技术，企业级系统，数据库技术，应用程序开发，网络管理，安全性和项目管理。您可以通过jmyerson@bellatlantic.net与她联系。