【IT168 评论】　　面向服务的架构(SOA)是一种组织信息处理的方法。各系统为协同工作在各方面达成了协议，SOA通过减少这些协议的数量，能够降低信息系统互操作性的成本。如果SOA能得到大范围的应用，系统将呈现与现在截然不同的前景，这就好比当今货运行业有别于集装箱出现前的货运业时代一般。然而，目前的应用方式却导致了额外的开支却并未体现出这些互操作性的优势。将适用于数据库时代的范式应用于SOA中，会招致反效果，往往是愚蠢的，有时甚至是十分危险的设计。这些模式必须由新的思想和行为方式所替代，以确保SOA朝着接口更简单、IT方案更优化以及项目更可控的方向发展。这一点可以通过遵守以下十大戒条来实现。

　　引言：SOA的潜在影响

　　面向服务的架构(SOA)是一种组织信息处理的方法。这种方法以服务的形式描述所有交互活动，服务请求者请求代理完成某些处理，代理确保处理得以完成并将处理结果反馈给服务请求者。这种思维方式可以应用于业务级别，以描述各组织机构之间的交互;应用于功能级别，以描述组成业务流程的活动的交互方式;应用到信息系统级别，以描述系统及系统各部分的交互方式。每个级别的准则都是相同的：代理完成所需工作的方式与请求者无关，乃至与是否完全自动、完全人工亦或两者兼具都无关系。哪怕代理将部分或者甚至全部工作外包给其他代理完成也与请求者无关。所有请求者所需关注的是与代理就以下方面达成一致：请求及响应应该如何制定，以及服务的效果如何。

　　SOA被大肆宣扬为一种具有巨大潜力的范式，能够降低系统发展、测试及维护的成本。特别需要指出的是，SOA承诺可以通过大幅度减少达成协议的因素的数量，从而降低信息系统各模块协同工作的成本。采用SOA，诸如像计算平台和数据格式之间的差别造成的系统间通信屏障会较采用早期的范式要少得多。这使得更大范围上的协作变得可能，因为它减少了障碍，使系统设计师们不必被强行要求相互达成一致，就此而言，也使得系统配置员之间不必被强行要求达成一致。如果这种承诺可以实现，其结果将会是革命性的。就像汽车改变了城市区域形态，集装箱运输革新了货运行业，以及交易费用的降低发展了现代自由市场经济，SOA将开启新的合作模式。当SOA主导我们应用IT的方式，系统前景将与今日迥然不同，好比围绕汽车来设计规划的城市和围绕火车来设计规划的城市截然不同一般。对我们之中那些思维受限于目前技术的人来说，SOA可以产生多大的不同是难以想象的。然而SOA所提供的灵活性优势就好比汽车胜过火车一样：即便火车可以被制造跑得和汽车一样快，火车还是绝不可能像汽车那样提供门到门的运输服务。把火车站安置在每个车道的尽头，亦或甚至把铁轨铺设在每条道路上都是根本不现实的。

　　为何此影响尚未实现

　　为获取新范式带来的好处，我们必须好好利用其所能提供的各种新的可能性。遗憾的是，目前围绕SOA的言过其实的宣传对这些可能性的提及是言之甚少。大部分讨论似乎都关注于如何利用SOA帮助单独信息系统更快速地开发。然而，这并非SOA所能创造的最大价值之处。事实上，SOA是否真正能够改进以往的方法，即各个功能点通过某一共同的数据池(通常是以数据库的方式实现)来实现交互，还存在争议。使用SOA来构建单独、孤立的信息系统就像使用集装箱在加工厂附近搬运货物一样：当然，它限定了内部物流的顺序和组织，但是集装箱更多的是挡了道路而非提供帮助。SOA使信息系统间达到更好的互操作性，就像集装箱促使了运输商之间的互操作性一样。那是一种重要优势，因为从需求确定到信息系统可操作之间的时间周期通常很大程度上是由互操作性决定的。要使某一信息系统能够与其操作环境中的其他系统一起工作，那将会花费比重新构建这样一个系统更多的时间和精力。

　　关注于SOA在信息系统内部而非各系统之间的使用是情况更加恶化的征兆：因为看起来SOA是一种全新的处理我们一直以来所做的事情的方式，我们无法直接获取它所带来的收益。SOA概念和技术正为目前的系统开发范式所利用。这些范式还是数据库时代的开发产物，同时也带有数据库技术的一些限制。在这些限制下应用SOA将会导致额外的开支，而不能获得额外的收益。然而，这些“数据库化”的范式是如此普遍和有害以至于我们常常忽略了它们对我们的思维影响有多大。它们是如此根深蒂固，以至于我们会不自觉将其视作常理。遗憾的是，这样通常招致相反效果，常常是愚蠢的，有时甚至是相当危险的。它们导致了一种不好的方案，这种方案集合了数据库时代的缺点以及SOA不好的一面，而又不能体现SOA必定提供的优点。

　　需要改变什么

　　SOA范式有其自身的常识守则，较之数据库范式的守则截然不同。基本戒律有十项。前五项关于如何简化事物，使其比数据库化的范式要求更加简化——从坚持要点意义上更加简化。如果我们以此种方式简化事物，同一问题的不同解决方案相互间协作的可能性将大大提升。接下来的四项关于使IT解决方案优于同等数据库解决方案，这是通过阻止那些戴着有色眼镜、惯于数据库思维方式的人开发出无效解决方案来实现的。最后一项关于如何使IT更可控，尤其是组织系统开发以降低项目复杂度和风险。SOA使这些成为了可能——同样也是必须的——因为它让更多的功能交付成为基础架构。

　　简化之理论

　　在高空杂技表演中，高效的合作的基础是每个空中飞人演员完全默契地配合，对方会及时地在每个时点出现。一些空中飞人演员非常自信，他们经常蒙着眼进行表演。他们能够接到彼此正因为他们确定在某个特定时刻对方只可能出现在一个可能位置。

　　成功应用SOA以达到最大化的协作性与高空杂技表演非常相似。互操作性要求关于如何进行交流的解决方案从数以百万计减少到只有一个，交互双方都可以依赖该方案。这并不意味着其他方案有问题：这好比我们既可以靠左行驶也可以靠右行驶，但重要的是我们必须都靠同一边行驶。

　　当只有一方执行服务，一方接受服务时，只要双方协议好，具体使用哪种方案其实并没有太大区别。双方中任一方的特异性可以决定最终方案，无需做更多的沟通努力。毕竟，无论使用哪种方案，这些特异性总要被处理。但是如果是多方请求服务或者多方执行服务，那将呈现不一样的情景。此时使通信方案精简非常重要，如此，各方必须处理各自的特异性，无需面对另一方。

　　将信息通信与外科移植手术对比很能说明问题。成功的移植手术，要将一个人身上的器官移植到另一个人身上，要求该移植器官必须在多方面与接收者匹配，而其中大部分匹配因素与该器官的生物功能无关。换句话说，被移植的器官必须和接受者本身有相同的特征。因此，我们的器官不能像拼搭乐高积木一样随便被移植。目前的信息通信恰恰如此。当一个信息系统为另一个系统提供服务时，它们必须在很多方面达成一致。它们必须使用相同的词汇(元数据)、相同的由一方调用而另一方执行的功能集、对于每个功能请求应答数据内容的相同期望、相同的编码系统、相同的技术通讯协议、相同的用于信息传递的寻址模式、兼容的可预期的响应速率、兼容的确保消息不被丢失的技术、兼容的认证机制以确保双方安全通信而不是与冒名者通信、兼容的加密技术以及密钥管理以确保消息不被窃听或者篡改等等。为了促进互操作性，必须确保参与各方从彼此独立制定各自标准变为形成兼容的标准规范。只有当一些非常严谨的规则得到遵守时这才有实现的可能，接口才能减至精要。如此一来特异性将无容身之地。

　　严谨的规则都关注于如何使得服务接口更为简单。我们规定的越少，争议的余地就越小。