SOA 比 Web Services 涵义更广

无论何时在街上问一个了解点技术的普通人有关面向服务的架构（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	同步或异步	表单（Get / Post）、XML、SOAP	远程、无安全性、平台无关、组织内部或外部服务访问
HTTPS	同步或异步	表单（Get / Post）、XML、SOAP	远程、安全性、平台无关、组织内部或外部服务访问
JMS	异步	XML、SOAP、Java对象	在通信Java环境中点到点或者发布消息
SMTP	异步	基于上下文的、XML、SOAP	组织内部或外部远程消息传输
Proprietary Message Broker	异步	XML、SOAP专利	在专有环境中点到点或发布消息
CORBA	同步	CORBA对象	在潜在的异构环境中直接远程对象调用
Native Distributed Objects	同步	COM+、EJB /RMI、.NET远程	在本地环境中直接远程对象调用
Native Object	同步	本地数据类型	在本地环境中本地对象访问

应该搞清楚的是，对于分布式和本地对象技术，面向服务方法的应用程序不打算执行很多高粒度的方法调用。如果我们应用最佳的实践，需要假设这些对象包含了可以接收复杂数据结构的商业级别的方法。

通过举例的方法，想像一个管理购货订单的本地对象并使用企业资源达将它们永久保存。该对象可能有用于创建订单、添加一条项目、设置客户信息等的方法。在本地级别调用这些方法不会引起任何问题，但是如果我们使用远程或者异步协议，由很多远程调用引起的性能问题就很明显了。解决方案是提供一个单个方法接收一个包含整个订单全部数据结构的对象来添加一个订单。

该方法可以通过服务接口来描述，并且通过分层技术使得可以通过多种协议来访问。不用更改服务签名，要改的只是通信协议和数据有线格式。下图解释了如何实现分层。

既然这样一个服务可以通过很多协议来访问，决定哪一种协议与特定用例和技术集能最佳匹配就是服务客户的事情了。当考虑数据有线格式的时候，会引出了另外一个复杂问题。正如前面表中所示，每一种协议都支持多种格式的数据。上图中的暗示是根据需要在不同数据格式之间转换数据。为了讨论方便我们假设本地对象提供的方法接受通过所有层次传播的XML。

下表再次列出了这些协议并且解释了什么时候应该使用每种协议来访问由打包的本地对象提供的相同服务。

传输协议	推荐使用方法
HTTP	服务位于可能是在组织外部的远程机器上。提供服务的平台与客户平台不同。可能需要异步访问服务从而使得一个响应可以立刻分程传送到客户。在回调或者轮询结果时可能也需要异步操作。对服务的可靠访问不是问题。对安全性没有要求
HTTPS	除了需要一个安全验证连接之外，其他与HTTP相同
JMS	服务和客户都位于可以访问JMS提供者的Java平台上。不需要服务立即给出响应。服务请求发送确认可能是必要的。发送或接收消息可能是一个事务的一部分。诸如验证和授权等的安全性是可选的
SMTP	服务和客户都可以访问SMTP引擎，但是在直接通信中不是必要的或者是位于全异的平台上。不需要服务立即给出响应。不需要事务支持。确认传输也不是必须的。对安全性没有需求
Proprietary Message Broker	服务和客户都可以访问消息代理，但是可以在全异的平台上。不需要服务立即返回响应。服务请求传输确认可能是必要的。发送和接收消息可能是一个事务的一部分。安全性是可选的
CORBA	服务和客户都可以访问对象请求代理（ORB）并且可以通过IIOP进行通信。可以要求对服务同步访问从而使得响应可以立即分程传送给客户。服务请求可能是一个事务的一部分。安全性是可选的
Native Distributed Objects	尽管不需要位于相同的物理机器上，但服务和客户都位于同样的本地平台并且使用直接通信。可以要求对服务同步访问使得响应可以立即分程传送给客户。服务请求可能是一个事务的一部分。诸如验证和授权等的安全性是一个选项
Native Objects	服务和客户都位于相同的本地平台并且位于相同的物理机器上。可以要求对服务同步访问使得可以将响应立即分程传送给客户。不要求事务支持。对安全性没有要求

要为一个特定用例选择适当的协议，那么就需要考虑服务使用的上下文和总体系统的可靠性、性能和安全性需求。

SOA使得事情变得容易

提供多种方法调用相同服务的一个明显的副作用是在开发中提供必要的分层技术的开销。在本地对象上执行一个方法可能只需要一行代码。创建一个JMS并将它放在一个队列中或查找它并且缩小远程分布式对象需要多得多的工作。要在这样的环境中实现高生产率，所有的这些事情应该变得同样容易。实际上，调用服务应该使用相同的机制，和底层的实现应该是无关的。

在WebLogic平台中，控件正好起到了这样的作用。服务的创建者可以建立接受XML的Java控件并执行比如说创建一个购货订单的所有任务。这是由本地对象来实现的（在这种场景后面，Java控件可能使用了Java过程，它可能依次执行其他服务，但是这在另一篇文章中讨论）。

一个附加的步骤可以用该控件创建一个Java Web Services（JWS）（现在根据需要而支持HTTP或HTTPS）。也可以使用Java控件创建一个Java页面流，从而可以对服务直接进行Web访问（也是HTTP或者HTTPS格式）。如果需要远程对象访问，可以创建一个带有会话Bean（本地分布式对象）的EJB项目，通过一个过程代理将其委托给一个Java过程。另外，EJB控件提供界面来使得通过HTTP或者JMS提供现有的EJB。EJB编译选项允许通过CORBA可以访问EJB并让EJB生成IDL和Stub。

可以通过两种方式添加JMS支持。首先，JWS可以通过@jws：协议标记直接绑定到JMS，或者在WSDL中通过JMS绑定到基于服务的JAX－RPC。另外，可以创建一个Java过程来监听JMS队列并且在接收到消息的时候委托Java控件来处理消息中包含的XML。通过订购一个Email通道，可以使用类似的过程来提供SMTP支持。用同样的方法可以支持其他消息代理。

下表对这些内容做了一下总结：

传输协议	WebLogic 平台部件
HTTP	JWS、JAX-RPC Web Services或者页面流动作
HTTPS	JWS、JAX-RPC Web Services或者页面流动作
JMS	JWS或者JAX-RPC带有JMS绑定的Web Services、带有JMS订购的JPD
SMTP	带有Email订购的JPD
Proprietary Message Broker	带有消息代理订购的JPD
CORBA	EJB编译选项允许生成IDL和CORBA的存根
Native Distributed Objects	带有会话Bean的EJB项目
Native Object	Java控件（JCS）

服务的客户同样很容易使用服务。在Workshop中，可以使用各种内置的控件来轻松地访问Web Services、EJB、JMS队列、消息代理通道、Email或者CORBA实现。当然也可以直接使用自定义的Java控件。

结束语

面向服务的架构比Web Services涵义更广。一个单独的服务可以多种方式提供，从而使得可以通过多种协议进行访问。服务的客户应该选择最合适的协议从而满足特定用例、性能、安全性和可靠性的需求。BEA WebLogic平台为单个服务用多种协议包装提供了简化的构造方法，为服务的使用提供了很大的帮助。Web Services只是服务实现的一种形式，在很多情形下使用可选协议将提供更具伸缩性和健壮的解决方案。