大家都是怎么理解SOA的
对这个概念俺还有点模糊，先抛砖引玉一下照俺的理解，SOA就是一种面向业务的软件架构和设计理念，先把业务模块化，然后用WSDL SOAP UDDI 等等等等XML技术去包装它们。
企业本身可能运用的乱七八糟一堆软件应用，应该是。NET或者JAVA乃至PHP的都有，把它们用SOA的WSDL来定义成标准的接口。然后用UDDI注册了，再通过任何一种软件应用手段或者干脆用WEB浏览器去访问这些标准接口，然后交换XML数据。
俺个人感觉就像把一团乱草用一个个的小抽屉分类装好，然后按需求分别取出。只是被那些所谓的高手们给吹的神化了。 首先我不是高手$害羞$
lz理解得不错，$握手$ soa是跨平台整合方案，是概念是理念。web service只到目前用得比较多的实现方法，这个方法比较廉价，即通过定制公共接口,加bpel来实现多组件的整合。在java里我比较倾向用message driven ESB,因为这样整合比较细节化$ok$。
我对所谓一些海吹得高手也非常的反感，特别是国内的些技术论坛和blog,现在整天SCA,SDO，技术细节不讨论，整天为一些老外弄出来的花样吵来吵去，真丢脸！
真正有本事的是那些多做事少废话的程序员。$怒吼$ LZ理解的不能说错，但是不够。
理解SOA得从历史的角度看。
以前一个流程是由很多模块组成，现在是由Service组成。
模块与Service的最大差别在于,模块是面向内部的，Service是面向外部的，当Service面向全局的时候就变成了 Web Service。Service具有封装API的功效，但是以前的类库是静止的，只是函数的集合，Service是功能的集合。
Service的好处在于，它不仅是一个技术的概念，同时也是一个业务的概念。当然，这也就成了它的难点，也就是Service的切割与划分。它要有业务上的完整含义。
这个东西不是一两句话就能说明白的，嫩可以找一段前几年写的程序，然后按照Service的方式再重新分析，设计和编写一遍，然后就能感受在技术上的差异。业务上的差异，必须得嫩有业务经验才好。不过嫩可以简单设计和分析一个销售流程来感受一下。
唉，还真不能用文字一下子写出来啊！ 楼上说的俺有点不太明白，虽然模块是面向内部的，就不能按照业务service把一个功能写成一个模块么 楼上说的是SOAP的概念，只是SOA里面会用到的一种协议。
RMI就是JAVA语言对RPC的具体实现，JAVA对分布式系统的通信方式。 原帖由 大镖客 于 2007-10-13 22:41 发表 http://www.dolc.de/forum/images/common/back.gif
楼上说的俺有点不太明白，虽然模块是面向内部的，就不能按照业务service把一个功能写成一个模块么
Service的目标是外部使用，具有单独的业务意义，但是模块通常都大于一个Service，可以把一个完整的销售流程做成一个模块，但是下单的子过程可能就是一个Service，是不是一个Service取决于业务的分析。所以对于Service最重要的是标准，因为Service提出的原始初衷里有一条是为了满足互换性的需要才提出的，让一个具有多个Services的销售过程部分采用SAP的，部分采用ORACLE的，部分采用MS的，最后达到企业认可的最优的销售流程。
页:
[1]