换个角度看SOA

对于楼主提到的全局观，也很赞同。

普元真是很有名啊，可偶不是的。

SOA为啥让人雾里看花，因为这个概念太大，和当初.NET提出来时一样。这不是一个spring release新版本，列出特性表那样直观。对于这种真正的high level的东西，我们技术人员就是很难一下子搞明白。而形成对比的是，一些高管绘声绘色的描述着，说的话还是那么云里雾里，还是那么有政治高度。
包括程序员搞得那几期SOA专题，讲和没讲一个样。没有任何一个人能将SOA具体的实例化。
关于楼主描述的SOA里，有个有讨论必要的地方就是遗留系统的问题。
SOA到今天，已经从大家当初理解的集成方法变成了业务敏捷的架构方法。有没有遗留系统和用不用SOA没有任何关系。我现在用的一个产品号称是SOA产品，可是我还是没看到SOA在哪里，怎么能敏捷的重组业务。导致一直到现在，我还是认为某种service+工作流描述便组成了SOA。

感觉soa还是主要用于集成，比如javabean，webservice,jms等，而访问客户也非常灵活，甚至包含.net客户端。服务之间可以灵活的互访问。
至于服务的概念，粒度可大可小，本质还是基于接口的编程。

在开发新系统的过程中，有多少公司愿意为不可预计多长时间的未来买单呢？

遗留系统不是必要条件，我的文章意思是说，如果有很多有价值的遗留系统，那么用SOA的思想加以重构和集成会比完全新构建系统得到更多的回报。 不管有没有遗留系统，达到业务敏捷都是SOA的一个目标。 我的SOA的理解也是service+流程再加上可靠通信机制（比如可靠的ESB）。

"不管有没有遗留系统，达到业务敏捷都是SOA的一个目标"
确实SOA可以做到，不过用其它的架构或技术也能实现不是吗？而且是经过实践证明的，实施成本也很低，为了“业务敏捷”而采用SOA对技术人员来说有点over，也许sales比较喜欢这种说法。

不理解大家心目中的SOA为什么那么难，我的理解是：当你需要公司已经存在的数据而又和支持那个数据的系统不能用传统方式进行集成时，SQA就来了，而不管你的系统，不管那个数据支撑系统大小。而事实上，我们的确也是这样做了。

即便一个小小的功能都可以做成全公司都能用的service。

随着SOA思想和配套工具的成熟，SOA也会成为经过实践证明的，实施成本更低的技术。

购买SOA的基础设施的成本不会低吧，IBM整了那么多庞大的软件出来，情况会不会又象EJB那样。