标题:SOA 比 Web Services 涵义更广 浏览次数: <script language=JavaScript src="http://203.81.25.201:9011/cgi-bin/beadevcount.cgi?d_id=238"></script> 12 时间:2004-08-31
无论何时在街上问一个了解点技术的普通人有关面向服务的架构( 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 只是服务实现的一种形式,在很多情形下使用可选协议将提供更具伸缩性和健壮的解决方案。
http://dev2dev.bea.com.cn/techdoc/other/200408238.html