只因为你不懂SOA

你什么地方还不清楚？具体点

楼主可否详细的谈谈。。。

   支持楼主，终于找到知音了，哈哈。 我和楼主的理解是一样的，细节可以详谈，呵呵。
    说几句虚点的总结：SOA是一种架构思想， 轻还是重，复杂还是简单都是一个具体产品的技术问题。 就像 业务Bean思想， 用了EJB就很重，用了Spring POJO就很轻。 只是现在IBM，Oracle 等大厂商为了商业考虑，推出的产品 BPEL，Integration Server，ESB等都比较重，我用过其中一些，很难用； 但 Mule 等就比较轻，易用。

总算不止我一个人挨骂了
EJB是很重,因为它实现的功能也多,这个时候是没法避免的. 事实上,反对EJB,其实不是因为他给了我们很多我们需要的功能,而是他要求我们做很多额外的工作,又因为这些额外的工作,加大了开发时间,调试时间,带来了一系列问题.
可能很多人反对SOA,有一个原因是基于对EJB的反感.

我实在没有看出来哪里有逻辑联系在SOA和EJB之间？反感SOA是反感EJB？
在讨论一件事情之前，我决定对事情的本质有一个了解才是基础。首先我认为从代码级别或者从软件来看待SOA都是降低了SOA的级别。大家请注意SOA中间的两个最重要的字母S和A。
讨论SOA是不是先看看什么叫service？以前有本很流行的书叫《领域驱动设计》，这本书里面提到了在程序设计中的service的概念，大家可以先去了解一下从程序的角度来看待service是怎么回事情。在SOA中service的定义是什么？如果你有看过SOA的白皮书(好像是IBM版本不是很确定)，里面对于SOA中的service的定义是什么？repeatable task.为什么这样子定义才能很好地领悟SOA的本质，你首先要
明白为什么要提出SOA的概念，它的终极目的是什么？是为了快速应对企业级的业务需求变化。怎么理解？你配合repeatable task就不难理解了。在一个大型企业中，为了不断提升自己的竞争力要不断修正自己的商业模式，但是在传统意义下IT系统的变革或者开发速度是远远落后于商业模式的改变的，但是当SOA出现了以后，这个格局却有可能（注意是可能而已，因为技术上的阻碍实在是太多）打破。为什么？在传统的开发模式下,每当得到一个新需求的时候，我们都需要从头到脚构建整个系统，因为这个系统中其实是有很多关联和依赖的，如果我们能够将这些关联和依赖以service的方式分别自治却又整体统一在企业应用的架构下面？那是不是有很高的复用性，在面对新的需求时我们也无需从头构建系统？举个例子，在电信企业中，以前每开通一种新业务，从后台（客户是看不见的）到前台（客户可以通过网站、手机什么的访问）都是全新开发的，但是在SOA的模式下，我们会尽可能地复用已有的service，那么无论从时间和金钱都大大地节省了，难道不是一件被大老板乐于接受的事情吗?这也是为什么SOA会流行的原因。
再说A，如果有专研过程序设计，你就应该知道，我们的系统只是模拟现实世界而已，为了应对现实世界的复杂性和多变性，我们需要分而治之，同时发现越是抽象程度高的东西，发生变化的可能性就越小，那么在目前的情况下，肯定是架构最抽象，所以结合到需要高复用性，我们将S和A结合在一起就是要求我们在做系统设计的时候，时时事事考虑到service，并将其抽象到一种高度以至于架构与具体的程序语言和规范之上。也只有这样才可以不被语言约束，不被技术限制。但是以上都是理论而已，真正在实践的过程中却有太多技术难题。但是web service的出现改变了这种尴尬的局面（上个世纪SOA就被提出了，但是真正推广却是近些年），如果SOAP解放了web service一样，web service解放了SOA的实现上的很多难题。SOA中的description,discovery,policy,communication都在web service中得到了一定程度的解决,XML，WEB,UDDI,SOAP,WSDL这几个最重要的规范走到了一起，那么对应于SOA中以前的只有理论没有实现是一个巨大的进步，但是这也是很多人混淆WEB SERVICE和SOA的一个原因。anyway，web service是大大地开阔了我们的眼界，丰富了我们的技术手段。不是吗?虽然更多的人有着误解，但是如果你真正地参与到SOA的项目中，特别是和以前的开发模式比较，你会发现，上帝为你打开了另外一扇门。

俺明白点了，soa只是一种思想，至于效果，那个设计实现的人的水平有关，对不对！

忽悠吧。。。。

糊涂。。。。。。。。。。。。

忽悠，接着忽悠

JAVA开发路上，太多名词了。
其实都是玩概念，厂商的根本目的就是让大伙觉得Java很高级，适用于企业级应用，然后好骗企业客户的Money。