SOA虽好，可是门槛不低吧
SOA的概念大概大多数人都能理解，概括的说就是一个总线上用标准插件的方式去实现业务的脱耦。
道理是这样，实际做起来就没这么简单了，总线的接口如何定义才能满足今后业务功能扩展的需要？用什么样的技术才能在性能和开发效率间获得平衡？ 怎样才是主流的实现方法，.Net的方案获是java的方案？
总之，当SOA这个香饽饽放在大家面前的时候，怎么去吃就有讲究了？ 用刀用叉还是用筷子？
现在虽然已经有了些SOA的成功案例，IBM、MS也在大力推广，但离产生比较通用的最佳实践还有一段路要走。
>>而WebService只是SOA的一种行业标准的实现而已。
recher老师的这个观点我特别赞成,SOA - WebService - SOAP/WSDL - XML 之间是手段(方法)级别的联系.
而SOA抽象成了流程.
>>SOA概念提出，实际是把EJB再搞大，大到跨平台
banq老师的这个观点我也特别赞成, 我也认为SOA概念提出，实际是把EJB再搞大. 或把类似EJB的东西再搞大.
最近公司正在做SOA的POC,论证实施SOA的可行性.也查看了不少网上的资料，这里谈一点到目前为止的体会.
从业务的角度看,我觉得SOA的提出就是为了快速整合现有的服务，以实现新的业务。尤其大公司里存在大量的业务系统，各自间的交互方式主要是点对点，通用性都比较差，而且各个业务系统的技术也不大一样，ejb,corba等，减少重复开发，加快新业务的实现是每个企业都特别关注的。
从技术的层面看，有很多地方可以探讨，首先是SOA这个理念或者说这个方法论究竟是什么(what is SOA?)，它跟面向对象OO有什么异同.
我觉得相对OO而言，SOA更高层次一些，或者说其关注点不一样，SOA集中在服务之间的交互上，而各个服务本身实现上仍可使用OO去分析开发。这里就涉及到一个重要的概念，什么是服务。在不同的应用环境中，我觉得服务定义的粒度是不大一样的，但有几个原则，主要是通用性和扩展性。
而SOA面向服务的架构（服务驱动的架构）带来的最大的挑战，应该是怎样在开发中将这种新的理念应用到的软件开发过程中，如何使这一套新的方法论为开发人员接受。
则于具体的web service等这些具体技术，只是SOA的实现而已，有不少公司也有相应的产品，反而不是企业最关心的。
>而SOA面向服务的架构（服务驱动的架构）带来的最大的挑战，应该是怎样在开发中将这种新的理念应用到的软件开发过程中，如何使这一套新的方法论为开发人员接受。
这是对的，我之前说过SOA是将EJB搞大，事实上，如果你使用EJB架构，你的Session Bean就可能是一种服务，EJB本身就是一种服务驱动的架构。所以以前如果使用了EJB，现在使用SOA整合就很方便。
如果以前不使用EJB，使用普通JavaBeans，那么就要注意使用服务驱动的架构了，这方面后来Spring包括Jdon框架都是一种服务驱动的架构，所以，说白了，你的系统要将来融合到SOA的未来，现在起就必须使用上述两者开发架构开发你的系统。
最新TSS上一篇文章:
JBI - A Standard-based approach for SOA in Java
http://www.theserverside.com/articles/article.tss?l=JBIforSOA
在文忠，作者对Service服务的定义：
服务的实现是自我包容的，不必依赖上下文或其他服务状态，服务交互主要基于文本数据的交换，用基于标志的消息模型定义。这些服务对于运输层（发送和接受两方）是隐瞒的，或者这个层是不知道传送的什么服务。
SOA原理是非常不同于面向对象的，主要区别是在服务之间的交互是用接口定义的，注意这个接口和面向对象的接口概念是不同的，这个接口更多是面向数据（或者说基于数据），而不是象OO接口那样是基于行为（OO中的接口基本都是行为动作，无数据的）。
一个服务是可以被使用面向对象的概念和技术开发实现的，但是，请注意，服务之间的交互就很少使用OO的这些技术了，更多的是基于一种文本数据交换技术。
面向对象技术将行为绑定到数据，而SOA则是将数据从行为中解耦出来。可见在通往解耦的终极目标上，OO只是一条道路，SOA也是一条道路，可以互相补充，克服彼此缺点。
>如果以前不使用EJB，使用普通JavaBeans，那么就要注意使用服务驱动的架构了，这方面后来Spring包括Jdon框架都是一种服务驱动的架构，所以，说白了，你的系统要将来融合到SOA的未来，现在起就必须使用上述两者开发架构开发你的系统。
看来banq大哥还是比较着重实现的层面,实际上我们目前碰到的首要问题是分析原来的系统并定义其服务,怎样把它们整理出清晰的架构出来,并逐步向SOA过渡.毕竟,对于大部分公司,完全从头开发现有的系统是很不现实的,而如何改造,改造到什么程度则需要权衡多个方面.
>从对象/接口的关系静态（体现代码）-->描述的动态的转变？
请教高手们，怎样理解静态关系转变成动态描述的?
>耦合关系发生在runtime动态关系转变？
怎样理解?
谢谢！^_^
>没有耦合，耦合关系发生在runtime动态关系转变
目前我们编码中有类与类之间耦合（对象间的耦合）；还有一个类（对象）中数据和抽象的耦合。
面向对象解决了第一个耦合对象间的耦合，现在大家正从不同方向攻克数据和抽象的耦合，SOA也是这个方面的努力；
在J2EE开发方面也有这种努力：J2EE已经可以清晰地划分为表现层/业务层和持久层，持久层不用说了，元数据是为runtime转变做准备的；业务层的Ioc/AOP也是进行这方面的攻克，Decorator模式结合Ioc模式实现runtime结合；AOP则更干脆；表现层象AJAX这样的客户端界面东东也参与进来，把界面数据从流程中抽象出来。
随便谈谈。
我觉得"SOA"不是用来解决单个系统的架构体系,应该是针对如果有机连接多个系统进行业务整合的体系,属于分布式系统的一种体系.
所以使用具体技术实现的方式来描述是不妥当的.它只是一种分布式的思想.层次高于单个系统的架构思想.
个人理解,请指正!
[该贴被zuozu于2007年03月27日 13:01修改过]
>说句笑话，如果微软赢了，我也不会再搞软件了。已经没有意思了，让他一个人玩去吧。
哈哈，从这话看出一个banq对思想自由的追求阿，ms的开发工具的确禁锢开发人员的思想
路过,学习中!
SOA不由得让我想起了《UNIX编程艺术》中所说的：Unix 哲学是这样的：一个程序只做一件事，并做好。程序要能协作。程序要能处理文本流，因为这是最通用的接口。
那在SOA中也能这样说：SOA 哲学是这样的：一个系统只做一件事，并做好。系统要能协作。系统要能处理XML文本流，因为这是最通用的接口。
现在做SOA的是不是UNIX的FANS呀？!
[该贴被mentat于2008-03-08 12:39修改过]
我的理解:
1, 让沉睡的代码醒过来, 去参加SOA盛会
2, 软件工程解决了人的分工问题, SOA即将解决软件分工的问题-----这才是银弹
3, SOA精髓: 让软件分工并且协作
4, pipeline是对SOA的实现
说那么多没用, 直接搞个例子不就得了.
pipeline 3.1.0 已经发布
查看演示程序: http://code.google.com/p/ether-anima-pipeline/wiki/Demo_3_1_0
有什么建议直接告诉我
msn: isuifengi@hotmail.com
楼主说了半天，我仍没看见SOA架构的实质。楼主该说得具体一点，切实一点，以免我们误解或小看了SOA。