SOA迷惑
06 Aug 2004现代软件的发展过程无不向这几个方面发展：系统分层，模块之间降低耦合，高重用的开发模式和开发成果等。MDA，SOA的出现应该是这一趋势的必然结果，并且SOA必将成为未来的趋势。但是，我对这个宏大的体系架构（情愿称呼它为体系思想，因为暂时没有看到完整应用SOA思想的实例）充满了不解。
什么是SOA? 直译过来就是面向服务的架构。基本概念是基于Web service来编写一个个的服务，然后这些服务可以重用在项目的各个功能中，甚至跨越不同的项目。三四年前，Web Service出现的时候，大量的报道追捧，说以后可能出现一些专门的提供Web Service功能服务的公司，对普通或者专有的服务进行封装并提供接口供调用。然而若干年过去了，这样的公司没有出现，或者没有什么影响力。更多的此方面尝试只停留在实验室中，就连一向前卫的Amaze网站，它提供的Web服务不过是商品的搜索而已。
我的理解：基于WebService的SOA，既然建立在WebService之上，就只能通过提供类似于loginUser(userid, password)(用户登陆)的方法提供给项目的其他模块调用。然而，其它复杂的调用呢？饱含特定业务逻辑的流程呢？也许可以通过BPEL来进行动态配置，并提供对外统一接口。从这个层面上讲，对于业务不包含界面的功能，SOA可以完成得很好（应该说WebService完成得很好）。但是，很多时候，功能是嵌入在特定界面中的。有这样一种场景：
已经完成了一套系统：用户及用户组管理模块。在很多其他的项目中都要用到，数据结构基本一致。按照SOA的功能点，可能有用户添加、删除、更新等方法。对外有类似于addUser, removeUser, updateUser等，为了达到调用这些WebService，客户端需要建立一些界面。建立界面的过程虽然难度不大，但是也有工作量。在各个项目之间，界面的重复工作也在继续。SOA如何将界面也能重用呢？gigix说他们在项目中将CMS嵌入为一个SOA服务，我始终想不通的是，CMS的界面是如何服从SOA的定义被其他项目调用的呢？
每一个项目都有其不同的业务数据模型和工作流程。对这一部分的抽象并重用简直是不可能的。因此，SOA的应用领域仅限于同一个项目或者一个持续集成并可能业务规则不断变化（利用BPEL进行定义）的项目。