SOA的过去,现在与未来 --ofeeler

SOA的过去现在与未来,这个题目好大哦.  这些天读了王老师的<<应用服务器原理与实现>>, 感觉王老师对构件与应用服务器的整个演化体系很清楚.  景仰之情有如黄河之水,..... 好了,我就小试一把,我现在总结一下欢迎拍砖,呵呵.
 在PC产生初期我们的程序都是运行在单机上, 也就是说那时的应用系统基本上是建立在程序和文件的基础之上,
随后由于文件越来越多,软件界为了管理巨大的数据信息,不可能用文件的形式来组织了,因此而抽象出数据库系统,
注意这时还没有网络的产生, 所有的系统都运行在单机上,也就是运行在同一地址空间上, 各个模块,函数要完成一项具体的作业,也就是后来抽象出的服务,就需要模块之间的合作,互相调用, 那么他们之间关联都是通过指针也就是地址来完成的. 随着网络的诞生,我们的计算机界为了负载均衡, 因此把数据库系统单独放在一台或几台服务器上,也就是所谓的集群技术,在此基础上建立的应用系统也称之为基于C/S模式的系统，当然如果细分的话可以分为胖客户机模式与瘦客户机模式，也就是业务逻辑在那一端而已，呵呵：）但是上网的人越来越多,应用系统的越来越大，管理的角色，流程越来越多，服务器的连接也随之而迅猛增长,连接池技术也不能解决此类问题了，单纯的数据库服务器似乎无能为力，怎么办？人类最原始的做法最是把复杂问题分治化，软件问题也一样。于是乎,想到了能否把对数据业务逻辑的处理单独抽象出来以构件的技术来管理他们,但对构件的管理需要应用服务器了. 当然了这是应用服务器的雏形,还不是现在这个样子的.它只是管理客户与应用服务器,应用服务器与数据库服务器之间的通讯, 以及对构件运行环境的支持. 那么于之而来的一些问题又是如何解决的呢？ 比如说，参数传递问题，如何象调用本地服务一样调用应用服务器上部署的构件呢。由于客户端进程与服务器端进程时不在同一地址空间因此我们不能通过指针的技术来解决关联问题，由此而产生了指代和服务骨架的概念。通过指代我们可以对网络上的进程之间的信息进行编排与还原，也就是在把信息通过底层协议的封装，与解析而完成网络间的通讯过程。也就是我们平时所说的互操作，互操作由RPC->DCOM->CORBA/J2EE->Web service而经历了一个演化发展的过程。由于互操作根据应用环境的不同，而提出了RPC，ORPC，IIOP，JRMP，SOAP等互操作协议，我们的SOA中用到的是SOAP协议，也就是简单对象传输协议，它是对HTTP协议的封装，是为了穿越防火墙而提出来的。互操作接口也就是对指代与服务骨架的描述而提出了IDL，JAVA，WSDL等接口描述语言。WSDL也是SOA中的核心技术之一，主要是以XML的形式对web服务进行定义，描述。那么后来为什么出现了EJB,以及后来的webservice技术,以及我们现在要讨论的SOA呢. 我们知道在我们软件界一直追求的目标是复用，尽量的复用已有的函数，类，构件，架构，系统等等，早期有“四人帮”提出了著名的24种设计模式，这些模式充分利用了面向对象设计语言（如C++，JAVA）的继承，接口，虚函数等概念，而最大限度地进行了代码级的复用。在信息系统开发领域，人们根据这些模式进一步抽象出面向信息系统的领域的体系架构，如struts,spring等。 这些面向领域的体系架构极大地方便了人们对信息系统的开发。
EJB本质上也是这中架构的一种模式，只不过提出了容器的概念，把原先必须通过代码（主要是类厂）对类的生命周期管理的过程进行了进一步的封装，使软件开发人员更加集中精力在业务逻辑上面。因而利用EJB在构件以及体系结构上都可以得到很好的复用效果。同时也提高的系统的稳定性。与之而来的是企业都根据上面的各种方法建立了ERP，CRM等，然后这些系统并不能够协同工作，以提高商业的流程，但是为了节省资金不可能重新开发一个集成的全新的系统，怎么办呢？SOA正是基于这种市场需求而提出的。它一ESB也就是企业服务总线的形式把各个服务联通起来。也就是在一定程度上实现了应用系统级别的复用。
 呵呵. 我手都写痛了，这两天感冒了。不知道王老师看到这篇文章，是否能把《中间件与构件技术》这门课我70分呢，马上还考试了啊，还有导师的关于TI的DM642的项目没搞定哦。写的好辛苦哦，版权所有,转载请说明，搞笑~
                                                                                                                                       ofeeler at  szpku