只因为你不懂SOA

研究过它的openapi,甚至过于简单,没有SOA的印迹. 你指的是它内部架构吧?

如果有机会,我多研究研究再发表评论.
前面的话,是我这几年的感觉,没有深入去做过,整体感觉比较虚.

SOA呀？

我们全村人都在用SOA，用了SOA再也不用脑白金了,腰不酸了,背不疼了腿也不抽筋了,BUG改起来也有劲儿.SOA真是IT建设,必备良药！

你这种想法是很有代表性的,却也是我发出这个标题的本意————提出这篇贴子,我想引出的是: 不能因为某某技术引用了先前的某些技术,就对这个技术予以否定.



如果你以这点认为我就被忽悠,那也太小看我了.Spring没出现前,Proxy,cglib不也用得好好的么?那是不是说Spring也是个炒概念的呢?我知道,现在的人不会这么看Spring,但在04年的最初阶段,我的确认为Spring是旧瓶装新酒(当然,这是当时理解的局限).
.
任何技术都会有先前的影子,都是逐步发展起来的.SCA没提及DI,但为了实现它的架构,可以借助DI这个技术去.事实上,在开源实现上Tuscany就是以Spring作为基础,ServiceMix也是.

是的, 正如我开篇所说,SOA在你的眼中就是DI

但问题是,他可以有DI,但它不是DI.甚至DI都在SCA的规范中未曾提及.
另外, 如果我没看低你, 我还是说句费话:
PoJoAddServiceImpl,EjbAddServiceImpl,SoapAddServiceImpl是一个虚拟的东西, 容器会自动提供相关功能. 另外这个容器也不是说一定是SOA容器才可以.

因为,我帮你强调一下的原因是,按各种回贴情况看, 我怀疑很多人会认为是要自已手工实现这些东西, 很多人还会认为一定要一个什么JMock之类,或者像StrutsTestCase之类的mock一样.

好的，我知道了有容器支持。这是个实物，是可以拿来评述的。比如Tuscany。
对于容器，我很反感。它一方面提供了相应的功能，另一方面又是人为建立的壁垒，用来绑定客户，绑定该公司其它产品。
-- 尽管容器这个概念在理论上是符合标准的，是独立于厂商的。
其实，这些东西完全可以更轻量级，然而这样不符合厂商利益和销售策略。

从Tuscany的介绍来看，它就是我前面说的“通用协议适配器”，同时也提供了服务调用拦截器：
http://dev.yesky.com/56/7644056.shtml
这是filter chain机制，联想到楼主在另一篇贴子提出 接口被AOP替代 的观点。

这个东西是可以评述的，我认为它是有价值的。那么，从技术层面，还有什么？

是的，阿里软件开始对比过OSGI和SCA，不过后来还是选择了SCA
SCA这种东西对于大规模软件开发还是很有好处的，就像weblogic10平台版，现在安装文件1个多G，软件规模越来越大，我们如何来有效控制那？这个不是能够依靠tdd,源代码共享等等就能掌握的了
说白了SCA的本质还是组件开发，但是这个组件和以前的组件技术还是有很大不同的，它可以做到接口和实现分离（这里的实现是可以是跨平台的，跨技术的，比如你用c++实现，你用spring实现，你用osgi实现），实现和协议也是分离的（你可以用ws，也可以用rmi，更可以用jms等等）
就是因为以前SOA的虚，所以才诞生了SCA SDO的实

接口和实现的分离，你可以认为是DI，但是你认为现在除了SCA容器，还能有那个DI容器能给你提供如此强大的功能吗？

是的，就我目前对SCA、SDO的了解，这俩算比较实在的。
归根到底是异构整合和组件开发 -- 突破技术障碍后会解放思想。
SOA的虚正是让人觉得无所不包，对于开发者来说，实惠太少。

SCA的绑定除了能够绑定协议外，还能绑定数据格式，比如支持SDO，XMLbeans等等
举个例子，现在有两个组件，需要相互调用，采用目前的技术就需要明确定义这两个组件之间的调用技术细节，比如你需要分别部署在两台机器上，那么还需要选择协议，比如考虑到异构系统，OK，选择webservice吧，这时候就需要你和webservice的具体技术细节打交道了，引擎是选择axis2还是cxf等等一系列问题，可以反过来那，使用SCA的话，你根本不需要考虑这些问题，你就认为这两个组件之间就像正常同一个jvm的调用一样，SCA容器会将你的调用自动转换，从java调用转换到ws调用，包括数据格式，从java对象到soap对象，然后再反过来把结果返回给你，看一切都是如此简单

SOA--抽象概念
SCA--技术框架规范
Tuscany--具体实现的产品。

能不能说具体点啊，看过之后更迷茫了！