面向服务的体系结构-SOA

 

   偶长期以来一直想写一篇关于SOA的文字，但是迟迟没有动笔。
   偶今天感冒在家，终于可以有这个机会咯。

   面向服务的体系架构（Service Oriented Architeture，即SOA）在今天这个软件业中，可谓是如雷贯耳，如日中天。其架势直逼当年“面向对象”（Object Oriented ，OO）出道之时。偶们都知道，对象是现实世界中实体的缩影，面向对象编程，即面向现实世界中的实体编程。那么“服务”又是什么涅？如何面向“服务”去架构呢？这个东东虽然大家都听说过，但是真正理解起来的想法可谓是千奇百怪哦。

   偶虽然也不能说真正读懂SOA，但是偶觉得偶想象中的SOA，绝对是架构设计的巅峰之作。更为重要的是，SOA并不遥远，近得唾手可得。

   从面向过程到面向对象到现在的面向服务，软件的抽象程度逐渐提高，软件的复用率也逐渐被人们作为重要话题一再提及，面向过程时期讲的是函数的复用，面向对象时期讲的是类和对象的重用。从零散的函数升级到了整体的对象级别，明显是层次的进步。到了面向服务时代，就应该是组件级、或者说构件级的重用。
   然而项目中可能会出现千奇百怪，种类繁多的各种服务构件。有时候，被调者根本不知道谁会来调用，调用者也不知道应该去调用谁？（您可能觉得不太可能，但是偶可是深有体会的哦，偶要调用的组件可能还没有写好，可能还只出现在计划中，你根本不知道它会部署在哪台server中，是一个什么样的接口，但是偶这边的业务也得进行了）。

   谈到这里，不得不引出所谓的服务中间件的概念了。其实这对偶来说是一个很陌生的概念，也是一个正在探索的概念。像ESB(SUN的openESB)和ogsi都可以作为中间件的基础。偶觉得，既然要SOA,要分布式，就要进行得彻底一点。服务的使用和服务的提供应该围绕着这个中间件来进行，我注册了（不一定要实现），你就可以使用。所以SOA应该不再是点对点式的服务提供和调用的关系。服务调用者不一定要知道服务提供者的接口细节，因为我只关注你在中间件上的服务注册信息而已。至于调用方式到底原则跨平台跨语言的Web Service，还是选择皇家正统的EJB，那就看到底要把这个架构做到何种程度的松散耦合了。

   很多人看到这里（如果能忍受偶的繁体文字和凌乱文笔坚持看到这里的话）都觉得SOA是一个很乱很乱的东西咯。所以不得不再谈谈关于如何将这些乱七八糟的东西整合到一起来，即所谓的集成。
   要做应用集成，就看看以下几种继承的层次
   数据集成：说白了就是用同一个数据库，同一些表啦。需要集成双方知道对象的底细啦（数据库都知道了，还不是底细？）
   方法集成：就是你调我的方法来获取我的数据，你可以不用知道偶的数据库设计结构啦。但是你必须绑定在我的方法上。
   业务集成：在应用系统之间建设业务集成总线，实现业务数据按照一定的规则在应用系统之间流动。这个好像有点SOA的感脚咯。
   表示层集成：通过注册表示层的url和唯一的一个门户系统，就可以把多个应用系统进行集成，偶们现在正是这么做的，偶滴感脚：耦合程度很低，但是很多问题哦。
   B2B集成：跨组织的应用访问，通过传输协议（HTTP）和数据描述（XML）为核心的技术路线，继承程度不可能很高。但是双方耦合程度也最低。

   如果涉及到SOA和应用集成的话，那么传统的一些架构模式可能不再适用了，像什么MVC啦之类，因为最起码，在你的架构里，得多加一个层面“集成层”。

   综上所述，偶要做出一个小小的，不算很严谨的结论啦（各位GGJJ，偶发现自己真是不擅长言辞，不要骂偶肤浅）。SOA是一个架构设计思想，而不是一种具体的技术，要实现SOA，首先得定出game rule。对于多个业务系统之间，这个rule必须保证是中立，不依赖于任何一方的。然后业务系统要想纳入这个SOA的集群中，就必须依赖于制定这个rule的Service Manager，而非另外一个真正要被依赖的业务系统。彼此把接口暴露给Service Manager就可以了。
   SOA的要义就是：

   松散耦合
   位置透明
   规则中立

偶肯定地认为，在不久的将来，SOA必定会大行其道，成为改变软件世界的一次革命。偶将成为SOA的忠实FANS,哈哈