iweroulsdjf

引言

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

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

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

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

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

企业以前的应用程序

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

动态服务链接

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

在第一个 SOA（参见图 2）中以更加紧凑的形式重新设计的应用程序可以动态链接到第二个 SOA 中的外部企业 MRP Web 服务，依次的，指向第三个 SOA 中的外部企业 CRM Web 服务。一旦收到请求，CRM 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 的。

正如您所见到的，第一个 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 服务向原始应用程序发送一个请求或者信息。

正如您所看到的，第三个 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 超载。