Web Services是救星?

　　Web services基于很多与Internet和Web相同的技术，它解决了分布式组件模型所具有的很多问题。我假定您已经对Web services有了一些基本的了解。对于想要快速入门的人，可以参考本文结尾处的参考资料部分。在这一节中，我将说明Web services是如何解决CROBA和J2EE之类的分布式组件模型的局限性的。

　　Web services使用HTTP作为其传输协议。HTTP已经被广泛采用和认可，这不仅有助于增强互操作性，而且使用现有的基础架构还可以提高操作效率。注意，Web services实际上是独立于传输协议的，HTTP只是可以使用的传输协议中的一种而已。可以对Web services使用已经在企业中普遍应用的传输协议，比如MQ和IIOP。

　　XML的使用。Web services使用XML来描述接口和需要在服务及其消费者之间交换的消息。可以使用Web services描述语言(Web services Description Language，WSDL)来描述通向某个Web服务的接口。尽管从表面看来，WSDL类似于IDL或Java接口，但是WSDL的功能更为强大，并拥有支持服务松散耦合的构件。例如，WSDL支持多个类型系统，所以可以使用它来描述使用大型主机类型系统的服务。它还支持多种协议和传输方式，例如，可以指定某个特定的服务基于JMS而不是HTTP可用。最后，借助于WSDL，可以以一种抽象方式定义Web服务的操作性行为，然后在不同的网络端点将其绑定到访问它的特定方式。

　　承诺降低复杂性。分布式组件技术之所以复杂，原因之一就是它们规定了自己的编程模型，因此需要学习一组新的API。相比之下，Web services就没有指定任何新的编程模型，您可以继续使用您所熟悉的环境，包括J2EE或CORBA。这还意味着，可以选择使用任何编程语言——C++、Java、Perl。Web services其实是一种接合和消息传递技术。

　　从上面的讨论中可以看出，Web services实际上解决了与分布式组件模型相关的许多问题。Web services最适用于部署SOA。

　　然而，我们尚未完全实现这一目标。前面我曾提到过，当讨论与分布式组件模型相关的复杂性时，造成复杂性的主要原因是难于支持服务的整个生命周期，这不仅涉及到服务的构建，而且还涉及到对服务的部署、版本控制、保护和管理。我们还需要对服务的定义进行扩展，以便包容企业现有的资产，即使企业不是基于SOAP和WSDL之类的Web services技术。这包括在消息解决方案之外构建的集成，比如.NET、MQ Series、TIBCO和遗留及打包应用程序。为了支持真正的重用，我们需要打破企业中存在的屏障。我们还需要使这些服务的发现和使用更为轻松——这不仅涉及到程序员，而且还涉及到操作人员甚至是业务分析师。

　　服务基础架构：新兴解决方案

　　我们看到，行业基于共同的经验教训在继续发展。上述讨论不应该被理解为传统技术在企业中没有存在的位置或价值。我们仍然需要面向对象的编程语言，比如Java、分布式组件技术和消息传递系统，来构建新的系统。正如前面提到的那样，问题在于通过把这些系统中的功能看作服务并支持利用这些服务创建新的复合应用程序，从而跨现有的技术筒仓来支持重用。尽管使用现有技术进行手动构建是可行的，但是这样做既不轻松，也不经济有效。就像我们使用J2EE作为构建应用程序的基础架构一样，我们也需要一个类似的基础架构来组成、消费和管理企业中服务的生命周期。简而言之，我们需要服务基础架构(参见图1)。这类服务基础架构的本质特征应该包括：

　　多中间件支持：CORBA、J2EE、MQ、Tuxedo——这些技术都在企业中用于集成。基于这些产品和技术构建的应用程序已经变成了一个筒仓，因为企业中可能会出现多个无法交互的“域”。服务基础架构应该允许企业基于合适的粒度水平在这些筒仓中公开有用的资产。有了用于发现这些系统中的元数据并基于它们自动创建服务的工具之后，这类服务的公开应该会变得更加容易。所有这类服务都应该以一种统一的方式被公开，并根据它基于的技术进行抽象，例如，我应该能够利用基于MQ的帐单编制功能和基于Tuxedo的呼叫处理功能构建一个新的复合应用程序，而不必学习有关MQ或Tuxedo的任何知识。

　　对多种传输方式的支持：JMS、MQ、FTP、HTTP等都是现今在企业中普遍应用的传输方式，而且在不久的将来还将继续使用。服务基础架构不仅应该支持这些传输方式，还应该提供一种使用企业的专用协议或传输方式扩展它们的方式。另外，服务基础架构应该直接进行协议转换，而不应让服务使用像HTTP这样的通用协议。对于某些高性能的应用程序来说，这很重要，因为转换到标准消息或使用像HTTP这样的协议所带来的开销可能是不可接受的。

　　服务的发布和发现：服务必须先被发现，然后才能被重用。需要使用某种形式的注册库来发现现有的服务(目录应该基于某种查询或浏览格式)，从而注册或发布新的服务。另外，对这些服务使用的策略需要进行定义和注册，这类策略可以描述诸如使用服务的成本和安全特征之类的内容。

　　服务运行时和生命周期管理：这涉及到监控服务的可用性、服务的故障恢复、服务的版本控制，或者停止使用服务。简而言之，必须提供高级的操作性支持。在前几代的集成和中间件产品中，管理和操作性支持似乎是马后炮。这给大多数企业造成了相当大的麻烦，并提高了成本。服务基础架构应该以操作性考虑为核心。另一个重要的方面是，由于可以在多个应用程序中重用服务，服务的不可用性将影响到依赖于它的所有应用程序。因此，应该提供用于服务版本控制和升级的特殊方式。

　　对服务复合的支持：这涉及到使用现有服务构建新的复合应用程序。由于服务本身是应用中立的，可以用在服务的初始设计者预想不到的上下文中，所以必须支持消息转换、基于消息内容的路由和对一些简单条件逻辑的引入。

　　服务安全性：安全性显然是一个大问题，所以必须支持基于某种策略、使用审计、警报触发机制的服务访问控制。此外，由于服务可以横跨具有其独有安全性模型的多个应用程序，所以必须提供与这些安全性模型的集成，从而提供端到端的安全性。

　　易用性：服务基础架构本身不应该引入新的编程模型或API。它在本质上应该是高度声明式的，几乎或完全不需要编码。这应该由非常直观的可视化工具提供。

　　我们的目标达到了吗?

　　服务基础架构在支持SOA和增强重用方面走了很长一段路。这代表着整个行业在支持重用和简化系统构建方面所做出的共同努力。毫无疑问，基于在部署利用这类基础架构的新应用程序方面的经验，整个行业将会继续发展。很多公司都很关心Web services标准的数量，其中一些标准是由相互竞争的供应商阵营所驱动的。供应商之间需要进行更多的合作，不仅要快速聚合Web services和安全性领域中的一些重要标准，而且要解决实际的测试和验证问题，这样才不会由于产品的互操作性而给客户造成不便。

　　我列出了一组有关服务基础架构的长长的需求清单。好消息是市场上已经出现几种支持其中绝大部分功能的产品。然而，有一点必须意识到：仅仅通过购买一种声称支持这些特性的产品，企业还不能拥有能够交付灵活性和敏捷性价值的服务基础架构。SOA和支持SOA的服务基础架构是可以转换的，因此需要对组织、流程管理和文化进行更改。IT组织应该实施架构一致性，并使自身与其业务风险承担者之间的同盟关系更加紧密，以便在进行转换时获得支持和资金。流程应该按照如何交付服务以及如何管理SOA中参与者之间的相互依赖性进行定义。一些被大多数应用程序重用的服务可以是水平的和一般性的，其他的则可以专门用于一些选定的应用程序。一个涵盖如何为这些服务提供资金以及如何开发这些服务的管理模型颇为重要。最后，文化应该鼓励和奖赏对现有服务的重用，而不是从头开始构建一切。

　　所有这些内容听起来可能令人生畏，但是实际情况是，这确实是一项令人生畏的任务。然而，现在出现了一些有利于开发的好兆头。首先，Web服务互操作性(Web Service Interoperability，WS-I)小组特别制定了图表，以便改进跨不同实现的Web服务互操作性。供应商们基于WS-I提供的配置文件进行互操作性测试。尽管这看起来似乎是明显应该做的事，但是CORBA或J2EE并非如此。而专用中间件和EAI产品的情况则更为糟糕。第二个好消息是，用于构建服务基础架构的工具已经越来越成熟，而且更加易于使用。例如，BEA的AquaLogic Service Bus产品是完全配置驱动的——几乎所有任务都能够通过一个图形界面来完成。最后，许多企业都已经部署了SOA，并且已经在应用程序开发速度和成本方面获益。更加成熟的IT组织已经获得了围绕其实现的这些指标和非常好的实践，并向它们的企业证明了敏捷IT可以成为多么具有竞争力的区分点。