关于SOA

什么程度的人适合去搞SOA呢?
感觉研究SOA需要很强的技术背景

70年代-80年代，自顶向下分析方法，核心是可以复用的函数，比如C语言的200多个函数库。

80年代-90年代，出现了OO的分析和设计，核心是对象,是可以复用的组件。比如Struts这个框架，我们只需在这个框架上搭载一些自己的Action，就可以体会到真正的MVC模式，而不是每个项目大家都去创造一个自己的FrameWork, 这就是组件复用的好处。

90年代后，OO方法逐渐不能满足用户需求变更加速和老系统集成的需求，所以出现了SOA,SOA的核心是服务。自顶向下分析方法以函数为中心，OO以对象为中心，SOA 以服务为中心。

服务合组件的概念还是不一样的。组件以功能复用为核心，而服务以实际的企业应用为一个单元划分。比如订单管理（OrderManager）可以是一个可以复用的组件，它仅仅提供自己的API,而订单管理服务则是一个完整的企业行为单元，可能包括 采购订单--〉订单审核生效--〉进货 这样一个业务流程。脱离了BPM纯粹从技术上讨论SOA是空洞的。


SOA主要目的是分布式和减少服务和服务之间的耦合。这种耦合性减少和以对象和对象之间关系的耦合性减少是不一样的，对象和对象之间关系的耦合性减少我们用IOC就可以很好的解决了。SOA耦合性的减少是服务和服务之间的耦合性减少。


也就是说，70年代-80年代，我们采用自顶向下分析方法做项目，80年代-90年代，我们用OO的分析和设计做项目，而现在，到了以服务为核心的分析和设计方法作项目。SOA仅仅是OO 思想的一种发展和扩充。

利用SOA思想做概要分析和概要设计，OO思想做详细设计，这就是我对SOA的理解

面向服务的设计思想在方法上的体现就是面向组件的设计方法。再向下才是OO。

因为工作原因，我了解了一些，根据我的观点，IBM和微软都认为SOA甚至ESB都是架构层面的，不仅是一个产品能概括的，而且SOA是企业级的，所以标准化，开放性都很重要，然而目前的现状来说，IBM自己的东西也不完全具有开放性，比如和微软等其它公司的标准，和WS-I标准也不完全符合，最终会不会又做成一个一家之言的EAI呢

做过开发的做集成的人研究这个比较好。
soa 做到及至 应该是集成的事情。。。到那时 现在意义上的开发已经不是问题。。。

您对SOA的理解和我的一样啊！
SOA是方法论层面上的东西，和OOP一样，不能将它和技术缠在一起

那是不是以后就可以软件零件化了？坦白说形式不是很乐观，我目前而言WS的效率实在是太差了。

上次参加IBM的SOA大赛，感觉学了不少东西，我觉的这个东西真的要好好发展下对于我们程序员来说是个解脱呀，一切都是服务，我们只需要调用服务就可以了。
还有一个我认为很好的就是用它能够构建一个成功的以软件组件为中心的商业模式！