##SOA思想概述

SOA 超越了所有的具体技术,也超越了所有的具体架构,同事soa也包容这些具体的技术和架构。理解soa关键是要理解里面的”S”即service 服务。服务可以说是一种既超越具体技术,又包容具体实现技术的业务功能。

以“ESB服务总线”为例,之所以这样称呼,而不是称呼”RMI总线”、SOAP总线等等,就是因为它既可以同时接受各种不同的传输协议,同时也不限制于这些具体的传输协议。再比如”SCA服务组件架构”,之所以如此称呼,而不是称呼”EJB组件架构”、“Webservice组件架构”等等,就在于SCA实现了业务组件和传输协议的分离。SCA服务组件可以自由绑定RMI传输协议、SOAP传输协议和JMS传输协议等。因为SOA的出现并不是仅仅为了创造一种新的标准,虽然SOA非常受欢迎,也能容纳新的标准。

SOA这种既超越一切具体技术,又包容一切具体技术的思想和《金刚经》中佛陀所说的“所谓佛法者,即非佛法,是名佛法”是相通的。所以,作为SOA的理念思想,首先需要有一种超越一切具体技术的思想。以soa的服务中线思想为例子,在刚开始设计一个具体的服务总线产品的时候,不能只想到我只要能够支持一个soap/http传输协议就够了,应该能够想到需要支持目前所有的和将来有可能新出现的传输协议。在设计中即使现在不能实现,也应该预留这样的扩展空间。

SOA的服务理念思想,本质上是一种业务和技术的完全分离,业务又能和技术自由组合的思想。它达到了目前软件设计思想的最高境界。soa的出现,预示着一个以服务为导向的新的it时代的到来。

##从面向过程到web service

###1.面向过程
面向过程的编程语言写出来的程序是紧密耦合的,整个应用程序依赖于一些预先定义的全局变量,函数的可重用性很差。

###2.面向对象
面向对象的编程将面向过程相关的函数封装起来,消除全局变量,形成能够独立调用的对象。相对于面向过程的含有全局变量的编程,其耦合度已经降低。类可以重用,可以扩展。然而,对象之间还有互相调用,互相组合的现象。还存在一定的耦合度。这些对象只能本地调用,不能远程调用。

###3.面向组件
将面向对象的程序进行封装,定义一些接口让外部调用。如j2ee(ejb) 、corba、dcom等。其最初动机是为了实现远程分布式的调用。它有接口类,另外专门有实现方法类,因为它要实现定义接口类,客户端调用的也是接口类。接口类和接口实现类之间实现了一定程度的解耦。也就是说,客户端调用接口类时,不需要知道接口类是如何具体实现的,不需要引用服务器端的实现类。
但是客户端和远程服务端的传输协议是特定的。比如j2ee采用rmi传输协议,客户端需要安装特定的stub程序。
上述的组件编程需要和特定的程序实现语言绑定。传输协议也是非标准化的,传输协议的不一致,导致各种不同组件之间无法互相调用,例如j2ee和dcom无法互相调用。

###4.标准化的webservice编程
采用标准化的soap协议,不同厂商实现的web service 之间可以互相调用。作为web service,客户端不需要知道服务器端是如何实现的,服务器端所用的是什么样的程序语言,客户端也不需要安装特定的stub程序。

从上面可以看到,程序设计的发展过程实际上是一个逐步降低耦合性的过程,也是一个接口和接口实现逐渐分离的过程。但是web service 的soap传输协议尽管是一种标准的传输协议,但是它毕竟还是一种特殊的传输协议,一种特定的技术。web service 并不支持其他的传输协议。所以说web service还是和特定的soap技术绑定在一起的。

soa的基本思想:面向服务


从本质上来讲,面向对象是面向过程的一次解耦和封装,就是把面向过程的程序进行分解,把逻辑紧密相关的程序结合在一起,封装成独立的对象单元,对象单元里面含有对外公开的api。

面向组件的编程是将面向对象的程序进行进一步的封装,封装成独立的组件,里面含有一些粒度大于api的接口。面向组件和面向对象的最大区别是组件是通过传输协议来进行远程调用的,组件是和传输协议绑定、应用程序服务器的端口绑定在一起的。

理解了上面的思想,就可以进一步理解什么是面向服务了。面向服务的编程是对面向组件的编程的进一步解耦和封装。所谓解耦,就是将业务组件和传输协议和端口解耦,也就是说业务组件可以自由的绑定各种传输协议。目前面向组件的编程,客户端在调用服务组件时,需要知道服务组件的传输协议,从而创建相应的客户端的调用程序来调用服务组件。比如ejb组件,需要创建基于rmi的ejb的客户端调用程序;对于web service组件,需要创建基于soap的传输协议等。

作为面向服务的编程,由于服务组件可以和各种传输协议自由绑定。这样作为服务的消费者,就不需要关心服务提供者的具体的技术细节,只需要知道有这么一个完全和技术细节无关的业务接口。我们可以把这种完全和技术无关的接口,称为“服务接口”。作为客户,不需要去理解这到底是web service接口,还是ejb的接口等。这个接口,只和业务相关,和技术无关。

因此,可以这么说,所谓服务,就是只和业务相关,独立于技术的业务接口。所谓面向服务,就是如何实现独立于技术的服务接口。所以soa是以服务为导向的架构,也可以进一步翻译为“以独立于具体技术为导向的架构”。

理解soa和web service的区别,有助于更好的理解soa的思想。soa和web service的区别在于:soa是在web service的基础上发展起来的;而web service实现了松散耦合的服务和粗粒度的服务。但是,web service本质上只是一个服务组件,因而它需要运行于一个特定的应用服务器上。web service服务组件的实现也是和应用服务器紧密关联的,适合应用程序紧密耦合的。客户端如果调用web service组件时,需要知道应用服务器的位置和具体的传输协议。这样一旦应用服务器的位置或者传输协议发生改变时,相应的客户端程序也需要做相应的更改。

SOA的基本要素


如何区分现有编程思想和SOA思想呢?它有下面3个基本的要素,只有这3个基本要素全部都满足了,这个应用才能成为SOA编程。

###松散耦合
松散耦合是指相互之间不依赖,踏实针对目前紧密耦合的应用系统所提出的一个概念,包括3个方面的内涵。

1. 服务之间的松散耦合

一个服务应该能够实现自己所提供的接口的所有功能,不要依赖其他服务。

2. 接口和实现之间的松散耦合

比如用wdsl定义的web service 服务接口,既可以用j2ee来实现,也可以用.net来实现。

3. 业务组件和传输协议之间的松散耦合

这是目前业务组件不能实现的。比如ejb需要rmi的传输协议,web service需要soap的传输协议。jms需要jms的传输协议。
这是新的soa思想要实现的。

###粗粒度

粗粒度的意义就是说,soa中服务的接口应该比面向对象编程的api要大很多,需要更接近用户的实际操作。比如ATM取款功能,包含用户身份校验、账户是否有足够的取款数额、取款3个步骤,作为soa的业务接口,就不能将“用户身份校验”,“账户是否有足够余额”这样的接口公布给用户,这样粒度太细了,不符合用户的操作习惯,所以系统只提供给符合操作习惯的一个服务接口“取款”,它里面包含了前面2个api的功能。

###位置和传输协议透明

位置和传输协议透明是soa最根本的区别于前面面向组件编程的地方。
目前的服务组件比如ejb、web service、jms的发布都是和特定的应用服务器绑定在一起的。比如ibm的websphere服务器、BEA的weblogic应用服务器,apache tomcat应用服务器等。客户端必须知道具体的应用服务器的url才能调用相应的组件.在全球经济一体化的浪潮下,各企业的服务集成是必然的,如果没有新的集成架构思想,那么会导致客户端程序必须要做相应的修改,否则整个集成就不能正常工作了。这就是服务组件的位置的不透明。所谓位置的透明,就是指不论服务组件的实际位置url如何变化,客户端的调用程序的url都不需要改变。

同理,目前的服务组件比如ejb、web service、jms 都只能接受特殊的传输协议,比如ejb只能接受rmi的传输洗衣,web service只能接受soap的传输协议,jms组件只接受jms的传输协议。这样导致客户端调用这些服务组件时,也必须采用相应的传输协议才能调用,一旦组建的传输协议改变了,客户端也必须做出相应的修改,这就是传输协议的不透明。所谓传输协议的透明,就是不论服务组件的传输协议如何变化,客户端的调用程序的传输协议都不需要改变。

目前组件的位置不透明,实际上是对应的信息的保存位置不透明,组件的传输协议不透明,实际上是对应信息的调用方式不透明。SOA的思想通过服务总线对目前的组建的接口进行进一步的封装(新的sca编程模型将可以自由绑定传输协议),将能保证服务的位置的透明和传输协议的透明。
下图显示了soa的服务调用方式,传输协议和位置都是透明的。不论实际服务者的传输协议和位置如何修改,客户端都不需要相应的程序。
soa的传输协议和位置透明的调用方式
图中所说的任何传输协议,是指服务总线所能支持的传输协议。从理论上讲,服务总线应该能够支持任何的传输协议,否则,就不能称为“服务”总线,而只能称为“某种或者某些特殊协议”的总线了。

其实由图中我们可以看出,sca架构是通过让客户端针对服务总线编程,从而达到了客户端不需要和具体的传输协议和应用服务器位置打交道(解耦合),而服务总线和具体的传输协议和应用服务器位置紧密耦合着,服务总线就相当于一个中间件。

Comments

2015-05-11

⬆︎TOP