只因为你不懂SOA

不同意，JAVA之所以概念多，看起来复杂是因为JAVA是开放规范的，JAVA的规范由各大厂商共同维护，每个厂商都在表面上遵守规范而暗自增加自己的特性，久而久之，特性就成为规范的扩展或者取代规范成为新的规范了，JAVA概念多是因为参与构建基础平台框架的厂商和组织太多啦。

追寻开发人员思维轨迹：
第一阶段：面向过程
第二阶段：面向对象
第三阶段：面向组件
第四阶段：面向服务
SOA即是在第四阶段上提出的概念，如果说Eric Newcomer没有讨论这个概念，当开发人员进入到第四阶段也应该自然而然想到这个问题，也就是说SOA不应该被当作是一个时尚或者追赶的新技术潮流，因为有些人可能没有经历这些过程阶段而直接跳到讨论面向服务这个问题而无法揭示本质。

面向组件比面向对象进步在于，面向组件要求开发人员用一组对象来实现一系列的功能，这其中除了面向对象问题以外，还要考虑类的生命周期，那些类应该被设置成公有，那些API是self-use的，哪些是应该暴露给用户的，那些类不能继承，继承这个类会不会导致客户使用它时承担过多的责任等等。。。

而面向服务，按Martin Fowler说法就是服务和组件的区别是，组件在本地，服务再远程，当不同组件在网络各处完成一个工作的时候，这个系统就成为一个服务体系，面向服务实际上是希望解决不同厂商的服务在同一系统中运用的透明度问题。
这个问题相对于面向组件过程的“一个组件在不同应用程序中使用的无关性”
也相对于面向对象过程的“对象在不同功能模块中复用问题”

所以对于多应用环境中SOA（或许我们应该忘记这个名词，并不能把它当作一个时尚技术而当成发展到第四阶段而顺理成章要做的事情）应该起到至关重要的作用。

没有看到任何有点意义的东西

纯粹祥林嫂式忽悠

一切都是假的

那么请问在你的定义中，什么是有意义的东西？简单地说使用WEB SERVICE来做一个项目你可以大致了解到一些SOA的思想和实现，现在的web service规范和产品多如牛毛，除了大厂商之外opensource也是非常多的。
前面有很多人都说是在忽悠，不可否则在国内这个概念是最近才流行的，但是你不能否认它在这个世界上已经存在了很多实质。
我觉得我们搞技术的人，不要盲从，人家说是忽悠就是忽悠，人家说是好东西就是好东西，你要有自己的独立判断能力啊。比如你们说忽悠的人，你具体看过几本SOA的书？参与过几个SOA的项目？研究了多少个SOA的规范？测试了多少个SOA的产品？人啊不要做墙头草。
不可否认的是，SOA本身在推广和发展中遇到了很多技术难题，或者即使是现在我也要承认很多产品、实现包括规范都是不完美的，但是你不能否认SOA对IT业界带来冲击和实质性的本质改变和诸多成功的SOA项目上线。
拜托在批评一件事物之前先对他充分了解，就像rod批判EJB的前提是他本身对EJB的master,在作出了SPRING，如果诸位是这种情况下的批判，我举双手双脚来欢迎你们的批判。

很对，SOA是一种架构的思想，并非一个软件或者一段代码。他是帮助我们来更好地架构我们的大型企业应用，从某种程度上说他可以弥补从前的软件、语言的一些缺点。

SOA是神学，基本用途就是忽悠人。觉得这贴水分太大了，SOA的最终目的还是炒概念挣钱，觉得这样做很不好，我们需要实实在在的东西。

请问你有没有看过SCA，有没有看过tuscany？请仔细看过在下结论OK？

前面就说了，你不要不负责任，人云亦云，你凭什么说他不是实实在在的东西呢？我真服了这种看帖子不看前面的人

当然SOA经过各个商业语言和销售语言吹嘘过，是有点让人迷糊。
但，就技术上来说，SOA的技术体系及思想还是很清晰的。
-->SCA规范（组件化）-->服务化（ESB暴露）-->业务服务聚合（BPM）-->
|---------------------管理及治理（Governance）----------------------------|
不过，这需要站在一定高度和层次上才能很好感受和理解。
这个高度就是EA，企业架构的高度
如果你目前只是关注单个业务系统开发，或者你觉得SCA/SDO或Service又和必要？一个java bean+jdbc不就搞定？
但是，如果你是一个企业，里面有上百个业务系统，它们之间需要通信、整合。。。
让你出方案，你会如何处理？
我们成天把企业级开发挂在嘴边，但又有多少人真正理解企业级开发的含义？！