赵翔鹏的Blog Xiangpeng's Thinkpad

初学SOA总结

昨天才意识到，以前虽然看了不少web service的东西，却没有认真的看过SOA，至多是了解一些报纸杂志上的吹嘘而已。今天花了半天时间Google了一下SOA，写个小总结如下。

SOA是一种松散的体系架构。跟管道的、分层的、黑板式的体系结构相比，SOA更松散，它的模块（组件）只是一些service，然后可以任意的组合拼接
以获得新功能来满足新需求，如用BPEL。我觉得这更接近component的核心思想，即只要接口相符，组件是可以任意拼接的；因此SOA是非常
flexible的，具有更好的复用性和伸缩性。

不用说，flexibility是非常好的，“把公司转型为随需应变企业”，
满足各种不同需求，听起来多么诱惑啊～～但正因SOA非常flexible，它也增加了service的接口设计和组合的难度——不像管道结构在设计时只
要考虑两个组件之间怎么连接就可以了，在设计service时必需仔细考虑通用性，可复用性，等等。但跟可获得的好处相比起来，我想这个设计的代价就微不
足道了。JavaOne2004有篇文章Using SOA and J2EE to Ease Integration and Customization While Reducing Overall Implementation and Customization Costs，看题目就知道，SOA其实已经是企业实现customization的最捷径了。

SOA的另一个意义是保护已有投资，因为service只是对原有系统的封装，所以可以降低成本，但也同样可以起到消除信息孤岛和实现EAI(enterprise application integration)的作用。我觉得企业实现“随需应变”是SOA最终的目标，而EAI是实现目标的第一步。根据目前国内现状，我想EAI就已经很能满足大部分传统企业的需要了。

在Internet /
Intranet环境下，SOA比其他架构更适合：因为服务是基于XML的，从而解决了格式不兼容的问题；服务一般是无状态的，而且可以通过服务发现的形
式寻找合适的服务，从而可以降低系统的耦合度（提高可伸缩性），降低出错概率（因为调用都是异步的）；……暂时只想到这几点，肯定还有别的优缺点值得讨论
吧。

问题：

服务是无状态的，但是有些时候组件里是有protocol，有状态的，比如哲学家进餐问题。BPEL，WS-CDL是否可以完全解决这个问题？或者说，为了保证基于Web的服务的易维护和易复用，我们是否必需放弃“状态”这一很有用的特征？

企业是否应该把服务发布给外部？发布服务会不会削弱企业的竞争力？卖书的公司把查询书价的service暴露出来之后，就造就了douban这样的网站，
从而导致卖书的公司要给douban交广告费。这要求不同公司之间的分工更细，单个公司必需把核心竞争力的东西做的更强才行。

自动服务发现真的能行吗？本质上，给定一个需求，寻找满足需求的组件是一个精化关系判定，这要求对需求（契约）的精确描述及实现自动的精化判定，而这二者都是非常难以做到的。

据说SOA可以更容易管理，但是现有的WS-Security, WS-Policy还是比较原始的，未必能满足需求。这方面倒是可以继续做一些研究。

最后，为什么在国内wikipedia还不能访问？不是说解封了吗？郁闷啊……