所以，尽管分布式组件技术为构建SOA提供了明确支持，并且基于行业认可的标准，但上述两个因素在企业层面上妨碍了重用的实现。注意，实际的情况还要更糟，因为要使用这些基于标准的技术，企业需要让系统基于专用的中间件技术，比如MQ和TIBCO。所有这些系统，无论是基于标准的还是基于专用技术的，都应该被认为是企业的IT资产，因为在构建这些系统的过程中企业进行了大量的投资。这些现有系统中已经存在的功能必须被公开为可重用的服务，从而使用它们轻松构建新的系统。使用CORBA和J2EE的经验告诉我们，引入另一组API或另一种传输协议无法解决这个问题。我们需要做的是对消息格式进行标准化，并使用已经在企业中普遍应用的传输协议，比如MQ和IIOP。在下一节中，您将会看到Web services是如何满足这种需求的。
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）。这类服务基础架构的本质特征应该包括：
文章来源于领测软件测试网 https://www.ltesting.net/
