对于SOA的概念一直很混乱，最近想梳理一下实现SOA的技术。因为我本身不很懂，在学习的过程中发现，有说SOA的重要技术包括Web服务、消息代理和企业服务总线(ESB)； 也有说SOA的核心技术是SCA,SDO和BPEL； 也有说实现SOA的相关技术包括XML，SOAP,WSDL，UDDI和ESB。 其中有些概念比如SCA，SOAP也可以说是标准，所以我就糊涂了。想听听明白人的看法。

SOA是很多技术的集合,这些技术都是为了解决一个最终问题,跨系统的集成与连接,使得在一个地方开发好的软件功能可以在有需要的时候放到其他地方去使用,而且这个过程要尽量地简单和灵活.
要理解这一堆东西,可以从服务(service)这个概念入手,当我们要使用一个系统的业务功能时,首先要描述它.工业界已经达成共识,最好的描述方法就是用WSDL(Web service definition Language)标准来描述.它可以很清楚地表达一个业务功能的入口,操作,输入和输出参数,还有绑定方式.
一个WSDL定义本身就是一个XML数据,这很容易理解,当你定义好了一个接口以后,用什么办法可以交给其他人使用,而其他人又可以很方便地使用,不会有交流上的问题呢?当然是XML这种自描述的结构啦

在WSDL里面描述输入和输出参数的数据结构(message part)的时候,会用XSD(XML Schema Definition)来描述,这样可以比较严格的规定数据的结构,不然的话XML数据可以随意表达,可能产生一些混乱.

解决了表达服务的问题,下一个问题就是如何使用这个服务了.也就是你拿到了一个服务定义WSDL,然后写一个程序去调用这个服务,调用的时候该发出什么样的请求数据呢?

最初的想法是发出SOAP数据,从web service的角度来看,这是再自然不过的事情了.可是人们马上发现了很大的问题.
第一个问题是SOAP数据量很大,里面有价值的数据不多,所以有人认为在企业内部就不必用SOAP数据了,在外网上用一下就算了.
第二个问题是在请求接收方必须有一个SOAP数据的解释程序,做反序列化的工作,然后在得到结果后再做序列化的工作.这个处理消耗了大量的计算资源.为了解决这个问题,引出了很多办法,如WSIF ,JAX-RPC等等.但都没有从根本上解决这个问题.

第三个问题是大数据量的传输,这个和SOAP没有直接的关系.一般的认为SOAP都要通过HTTP传送,所以接收方会开一个HTTP端口,同步地接收这些数据,如果这个SOAP数据特别大,就会出现传输上的问题.

最后一个问题好解决,虽然很多厂商(以M记为首)故意把SOA和Web Service以及SOAP/HTTP混淆起来,让很多可怜的中国客户无所适从,明知这种方法从技术上是行不通的,但别人洋人都这么说了,是不是我们英文不好,没有理解清楚.

其实SOAP还可以通过消息的方法传送,如JMS,甚至是SMTP(就是发邮件),FTP(就是发一个文件),只要解决了传送的问题,接收方总可以处理的.

从这里开始,我们发现,原来SOA不等于web service,敢这么大声说出来的厂家不多,能够说清楚这两者的差别在那里的人就更少了.

如果不用SOAP数据来发送对服务的调用,那用什么办法呢?SCA规范出来了.
SCA(Service Component Architecture )说:你喜欢用什么办法就用什么办法,我给你提供一个API,把你的底层方法给封装起来,这个API的上层和WSDL直接对应,也就是说有了服务,就可以用SCA的API来发出服务的调用了,至于底层怎么做,那是各位自己要解决的问题.

又是一个忽悠.但它是一个把问题考虑得很详细的忽悠,把调用时发生的安全,事务等问题都考虑进去了,提供了一个声明的框架,但是底层实现还是要靠你自己.

工业界的各位猛人开始投入无尽的精力来充实这个框架.并成立了一个叫tuscany的帮会.他们的解决办法和几年来用的办法没有什么两样,或者把调用数据直接封装成一个对象,SDO规范出来了,就是用最精简的办法把二进制的对象传出去,可以通过RMI(没错,就是J2EE里面的RMI)来做,也可以通过JMS或者其他传输途径.
还有人做了C/C++的接口,还有人做了各种各样的封装和解释数据的组件,总之是各尽所能,力求更快更强.

问题解决了吗?没有,才刚刚开始.
当我们千辛万苦把请求发送当初声称可以被调用的那个业务系统时,才发现别人根本不受这一套.
很多原有的业务系统,有自己固有的接口方式,或者根本就不对外开放接口.那个装模作样和我们通讯的程序只是一个代理(proxy),它收到对服务的请求以后,还要把这个请求转给真正执行业务功能的程序.
ESB出场了,它有一个声名显赫(或者声名狼籍,取决于你的价值观)的爸爸:EAI.
它们要解决的就是这个连接业务系统的问题,客观来说,EAI已经做得相当好了,它想尽办法,打开各种业务系统的接口,开发适配器,使得服务代理可以调用原有的业务系统.可惜它被人滥用了,在EAI平台上交换的数据和业务模式没有规范起来,于是ESB决定纠正这种错误,它说所有系统间的连接都要遵守一定的规则,至于它是怎么做的,这是另一个专题了.

ESB做好了以后,我们发现原来从我们的业务系统里居然有这么多服务可以用,都可以通过ESB来调用.幸福的感觉一下冲上心头,有点无所适从了.如果同一个功能,ESB上挂着两个服务,都可以实现,我们应该用那一个呢?会不会有更多的服务也能做相同的事情呢?
该轮到服务目录出场了,我们最初忽略了它,本来web service里面有三大巨头:WSDL , SOAP , 还有UDDI.怎么能把它忘记了呢?因为它已经没落了,其实它从来就没有辉煌过,因为它其实很简单,提供一个服务器,上面按文件夹的方式存放着WSDL文件,美其名日yellow page,你用过黄页就知道它有多简单了.让别人要寻找服务的时候就上去找,找到了就下载这个WSDL来做.
可是我们发现现实生活里的服务之间有着非常复杂的关联关系,甚至有人犹豫着问,这服务间的关系是不是应该和对象间的关系有点类似,面向服务的分析是不是应该和面向对象的分析一样最后得出一个综横交错的class diagram .
对的,这位同学,你说得没错,站出来让大家看一下你好吗?别不好意思.
面向服务的分析最后会得出一个复杂的service portfolio ,表明服务间的关系.可是怎么样存放到服务器上,再提供给面向服务的环境使用呢?这是一个问题,业界作了一些尝试,还没有完全解决,目前已经深入到语义网络(就是人工智能专业的同学学的那个)的领域了.

当所有底层的问题都解决了(或者我们假装解决了)以后,就可以考虑怎么去享受这个成果了.最常见的做法就是组装一些流程,流程里面的工作其实大家都已经开发好系统在做的了,只不过上面领导不知抽了那条筋,时常要大家把顺序改一下,美其名为流程优化,更无耻的叫做业务创新.
不管怎么都好,拿了人家工资,还得去做.BPEL(Business process execution language)出来了,它是一种组装业务流程的标准,就是用一些标准的元素,把一个业务流程里面的工作都串起来.
因为大部分的工作都不是业务流程自己做的,它要调用已有业务系统的工作,用什么方法呢,WSDL , SOAP ,SCA/SDO ,ESB等等,一大串名词重上心头.
BPEL的全称是BPEL4WS,就是说对外的调用是通过Web Services,把忽悠进行到底.

soa是概念不是技术。

问了程永老师，大概理解了一些。
我觉得SOA的重点落在A上，是一种架构，大部分的技术都可以用在SOA中。不管是.NET技术还是Java技术，SOA恰恰可以将它们结合起来。

Thanks ! 蓝色机器