canonical

http://www.xml.com/pub/a/ws/2003/09/30/soa.html
http://canonical.blogdriver.com/canonical/809426.html

   随着IBM, Microsoft这些世界级大厂商不遗余力的推销，SOA(Service Oriented Architecture)已经成为企业应用中的核心概念之一。我的一个同学在IBM做SOA架构咨询，前两天也和他聊到这个话题。从他们IBM的态度来 看，SOA无非是后EJB时代一个profitable enabled的概念而已。现在软件厂商的日子变得愈加艰难了，很多厂商都希望向服务转型，成为所谓IT service provider. 这是某种商业架构上的service oriented, 与技术上的SOA似乎有一些相互映衬的关系。IBM极力希望把SOA中的service概念提升到business layer, 希望在超越BPM(Business Process Management)的层次上提供一站式的打包服务。但是很显然，此service非彼service, 这种SOA的宣传中颇有一些偷换概念之嫌。把所有可以让用户买单的理由用MDA(Model Driven Architecture)做包装，打包到一个独立概念的package中在目前确实是一种可行的商业策略，只不过相对于用户脆弱的技术理解力而言，这种 SOA实在是不可承受之重。大多数用户所能理解的SOA不过是Integration的代名词，与EAI(Enterprise  Application Integration)没有什么可区分性。目前java技术的普及已经使得各个厂商的区别变得很小了，IBM这些巨型厂商鼓吹它们在异构系统集成方面的 优势当然是势所难免，在此过程中加点料也是可以理解的。


   虽然SOA这一概念中混杂了太多的商业因素，它也并不是一种单纯的fantasy. 从技术角度上说，SOA存在着如下关键性特征：
1. 独立运行(standalone)。所谓的service, 它与组件(component)的根本不同，首先在于service是独立于调用者自行运转的。访问service的接口相对狭窄，我们只需要知道 service如何满足我们的功能需求，而不需要管理它的生命周期，不需要理会那些维持service运行所需要考虑的种种细节。即我们对于 service的了解只需要局限于功能接口即可，不需要理会它的那些管理接口，配置接口等。各种service在功能接口这一层面发生交互，整个图景得到 简化。最常见的一个例子就是数据库服务器，调用程序只要知道如何通过sql语言进行数据访问即可，另有数据库管理员去对付各种配置管理问题。从技术上说， 这可以看作是singleton模式的一种扩展。实际上spring容器中管理的bean在某种程度上就可以看作是独立于bean的调用者的，因而 spring这样的容器可以成为SOA架构的自然接入点。

2. 异步调用(asynchronous)。内禀的异步特性是SOA包容真正的商业智能的关键所在。想象一下我们现在需要评估用户的信用度,它对应于函数 evaluateCustomerCredit(customer). 最简单的情况下，我们只需要根据用户的某些指标直接进行算术运算即可。如果评估规则非常复杂，我们可能放弃硬编码，而引入规则引擎（Rule Engine)这种人工智能的解决方案。在更加复杂的情况下，我们可能无法抽象出以数学方式表达的规则，而必须依赖于业务人员的人工处理（真正的智能）。 此时，系统可能需要弹出一个页面，等待业务人员作出判断，部分情况下还需要经过审批流程才能决定对于用户信用度的最终评定。对于计算机系统而言，这些都是 漫长的过程，是同步调用方式所无法容纳的。同样是一个函数调用，只有异步特性才能够包容真正的商业智能，才能在函数这种最小的程序结构单元中引入最复杂的 处理过程。现在SOA的宣传往往集中于机器之间的互相调用，强调异构系统之间的一种包容性，但事实上异步特性所能承载的内容要远远超越机器世界本身。当 然，同步调用方式也是SOA架构的自然组成部分，就像我们既需要email， 也需要手机一样。

3. 基于消息(message based)。基于消息的调用方式是分布式系统的一种内在要求。消息是一种数据，它并不是远程对象指针。distributed object这种基于proxy-stub的方案其内禀要求是远程状态同步（状态的一致性）,而分布式系统是由众多独立的状态空间（进程空间）所构成的， 这种内在的不协调是造成分布式对象方案难以实现可扩展性的关键原因。
  SOA与EBI(event-based integration)的区别主要在于EBI往往是push模式的，消息源向注册的消息consumer推送消息，而SOA往往还是一种pull的调 用。这两种方式各有千秋，在大的scale情况下，pull模式的可扩展性要更好一些。但是两种模式在企业应用中都是必不可少的，可能这些概念很快就会出 现融合。


4. 纯文本协议+元数据(Plaintext Meta)。SOA架构中基于纯文本协议是一个非常关键的技术抉择。当需要跨越众多硬件平台和软件系统的时候，各种二进制的RPC方案总是存在着难以彻底 解决的可理解性的问题。凭借纯文本的结构透明性加上元数据的自描述特性，我们希望实现一种语义透明性，使得各种中间层都能够以通用的方式传递经过的消息， 并理解其中需要理解的部分。与OOP(Object Oriented Programming)中的传统模式不同的是，SOA架构中强调的是结构(structure)与内容(content)的分离，而不是数据与行为的耦 合与封装. 表面上看起来，SOA中的调用方式似乎是对procedure（过程）化调用的回归，但实际上其中有着深刻的不同。在与元数据结合之后，在系统之间传递的 消息（信息）并不是完全被动的，而是具有某种smart特性。当数据这一方面可以包容更多的变化的时候，处理函数这一方面的结构可以得到简化。实际上，在 SOA架构中，我们推崇一种uniform interface, 也只有通过一种通用的接口，信息才能以比较低的代价穿越各种状态空间边界。基于通用接口，我们又重新发现了世界的简单性，而pipe-and- filter这种在unix系统中久经考验的设计模式也得到了新的发挥空间。
    说到纯文本的元语言，xml无疑是这一概念最强势的候选者。作为一种半结构化的文本表述，xml天然就是人机共享的信道。但是，随着应用的深入，当越来越 多的xml设计变得无法让人直观理解的时候，我们也感觉到了一些对于xml滥用的痕迹。W3C的Web Service协议栈提供了非常关键性的思想，并作为标准化的实现方式存在了很长的时间了，但是其实现和调用的繁琐和冗长逐渐引起了开发者的不满。 SOAP虽然号称Simple Object Access Protocol，但是今天已经很难把它和simple这个词拉上什么关系。也许Web Service的未来就如同EJB一样, 渐渐被更加pragmatic的方案所取代。

    在SOA架构中，松散耦合(loose couple)是late binding(discovery), standalone和message based等多种技术策略综合作用之后所达到的一种效果，这为外部灵活的流程配置做好了铺垫。