SOA 比 Web Services 涵义更广.docVIP

SOA 比 Web Services 涵义更广 时间：2004-08-31作者：Steve Wilkes浏览次数： 本文关键字：SOA,?Web Services,?WSDL 文章工具?推荐给朋友?打印文章 /techdoc/200408238.html 无论何时在街上问一个了解点技术的普通人有关面向服务的架构（SOA）的概念，首先反应到他的头脑中的东西将是Web Services。尽管SOA已经存在一段时间了，但是这并不令人惊奇，现在术语SOA的清晰度已经大大增强了，以前总是将它混淆为Web Services。 既然我们都处于相同的水平，我们将为本文专门定义SOA如下： “SOA是一种设计和实现企业应用程序的方法，这些应用程序处理那些通过定义良好的、平台无关的接口约定来访问松散耦合的、粗粒度的（商业水平）、可重用部件（服务）的互通问题。” 很清楚的一点是该定义不包含用于调用服务的通信协议或者有线格式。不像其他基于方法的服务那样，真正的SOA鼓励通过不同的方法访问服务――而不只是HTTP之上的SOAP。 本文的目的是基于该点展开的。本文提供可选的服务调用模式并且解释为什么SOA要比Web Services涵义更广。 背景 基于服务的概念在Web Services之前就有很长并且成功的历史了。一般对象请求代理体系结构（Common Object Request Broker Architecture ，CORBA）已经存在了很多年并且提供了许多至今仍被吹捧的SOA优点。 根据我们的定义，很明显CORBA不是一个真正的SOA实现。尽管CORBA有一个通过IDL（接口定义语言）定义的平台无关的服务约定和一个支持不同语言和平台的实现，但是它需要一个名为IIOP（Internet Inter-ORB Protocol）的特定通信协议和标准化的有线格式。此外，编译IDL来产生存根（stub）和骨架(skeleton)的需求表明生成的应用程序是紧密耦合的。 如果我们将SOA的范围缩小为只是Web Services，我们将有一个相似的故事。WSDL代替了IDL，并且服务通过一个特定的（虽然成本较低但更流行）带有标准有线格式（SOAP）的协议（HTTP）来调用。使用现在的开发环境，可以从WSDL生成存根和骨架，但是产生的服务的耦合性比我们所希望的更紧密了。 当我们放宽这些限制并且使得服务可以通过不同的协议来调用的时候，真正SOA的威力就显示出来了。 协议的问题 问你自己这样的问题——“我的组织内部处理互通使用了多少种不同的协议？”根据公司规模的不同，你可能使用了HTTP、HTTPS、消息代理（JMS、MQ、MSMQ等）、CORBA和SMTP。你可能也意识到了，EJB的远程调用或者远程对象上一个方法的简单执行都将利用诸如JRMP这样的协议。 你将意识到的其他事情是，在很多情形下为一个特定的场合选择协议并不是基于真正的用例分析。看起来选择更像建立在当前的实现之上，选择的依据通常是现有的基础设施或者选择最快的和最容易的路线来集成。该问题的另一个方面是集成机制可能通过适配器、打包器或者委托机制使用现有的代码并且没有尝试去确定通信粒度的正确水平。 在一个真正的SOA中，上面提到的所有协议都可以为服务提供一个访问点。 从理论上讲，一个服务可以通过服务接口被定义一次，但可以利用不同访问协议有许多实现。从现在通常用来描述服务的语言WSDL来看，这一点最为明显。 WSDL－去掉W 尽管WSDL的名字是Web Services描述语言，它并没有描述Web Services。它有一个独立于通信协议或数据格式的核心服务定义框架。该核心框架描述了组成一个服务的操作和每次请求和响应中传送的数据。处于该层次之上的是绑定扩展，它将一个特定的协议或格式附加到一个消息、操作或者访问点上。 一般的理解认为WSDL描述了Web Services，而SOA是关于Web Services的，这种理解来自于扩展到SOAP、HTTP和MIME绑定的核心框架的混淆方式就包含在最初的WSDL规范中。 这些绑定作为例子包含在规范中是为了澄清它们的使用方法，但是正如规范中声明的： “不排除在WSDL中使用其他绑定扩展。” 根据上面的说明，我们可以明白WSDL规范的作者原本想用它来从总体上来描述服务。包含的绑定通过将它和用于解决特定用例的现有技术耦合而使得规范增加了相关性。WSDL的完全形式鼓励将服务绑定到多个协议；关键是决定哪个协议最适合特定的场合。 最佳实践产生完美的产品 对于任何单个的服务都有很多调用服务的方法。假设服务已经绑定到很多协议，一个IT建筑师如何决定在一个特定用例中使用哪种方法呢？ 下表总结了流行协议的属性和数据格式： 传输协议 同步性 数据格式 描述 HTTP 同步