论Spring与EJB的组件架构

我所指的行业标准并不是EJB之类的技术标准，我觉得真正能黑箱复用的东西是基于一个工业标准的。例如做银行的国际结算业务，每个银行的做法是不同的，甚至连流程都是不一样的。这个时候如何能做出黑箱复用的组件来？如果有一个工业标准规定国际结算业务就这么这么做，那么黑箱复用的组件就可能产生了。不过这很难，光是一个EJB的技术标准各大厂商就各自弄出一些特性了，更何况是工业标准。这不是软件行业能够指导和控制的，只能跟随工业发展步伐。

现在有可能产生的一些黑箱复用组件是一些通用组件，例如权限管理之类的。至于采用什么技术什么架构去实现，倒显得次要了。

hehe,这里的标准其实也有两层皮。
一个是某个组织制定出来志在推广的标准，比如osi7层模型。ejb也差不多。
另一种是在行业的发展过程中演化出来的标准，最后用的人实在太多，才制定出规范来，这个多了去了。

不知道raimundox反复强调的语义可不可以这么理解？
比如有一个业务对象pojo，它声明了一种事务类型，就像

class BO{
   @transaction("some transaction description");
    public void someaction(...);{
    }
}

因为这个Pojo的正常运行实际上是依赖于它所声明的事务的正确运行的
所以如果这个事务的描述在各个容器中的具体实现是有差别的
（比如某个容器就不理你的这个声明）
那么这个POJO是不能直接复用的
于是我们可以说，虽然这个是一个POJO，可是只有包含了对transaction上下文实现的约束，它才是具有完整语义的
这里这个对"some transaction description"所隐含的上下文的限定是你说的语义的意思么？

我觉得很正常，为什么我不可以把我的业务模块从一个容器的环境下移植到其他容器下呢？

我觉得你还是没明白楼主的意思，他是想说Spring的确可以自己配置，但是它的灵活性带来的是其对于容器复用的复杂，在绑死的环境下也许更能提高服用度，反而反之。而且有一点，选择加载的事物管理复杂度也是很高的，代价上不低阿

这个和我的理解一样，它可能更多时提供framework层面上的东西，至多是个AOP和IoC的容器，而谈不上强规范的容器，我认为容器是强规范的。

既然有规范，原本就应该是无缝移植的。譬如说我写个JSP，难道还需要考虑它是不是在Tomcat底下能跑在JBoss底下就不能跑吗？没错，对于同一个规范也会有不同的实现，所以同一个规范底下也总会有这样那样的不兼容问题，但这是不正常的，而不是生活的常态。仅仅是因为EJB规范本身缺陷太多，所以各家厂商的实现不得不有相当多的不兼容性，所以才有这么个“EJB容器之间的移植”问题。你不妨想想，如果我说我要把几个JSP从Tomcat底下移植到JBoss底下，难道你不觉得可笑吗？如果我夸口说“我的Java Bean既可以在Sun JDK下执行也可以在IBM JDK下执行”，难道你不觉得可笑吗？

这点我承认，各个实现差异太大了！其实我支持这一说法的原因就是在强语义的环境下，尽量减少使用特殊技术，降低对容器的依赖性，是可以在一定层面上实现对组件的服用，这也是Rod上一本书也强调过的一点。

我认为容器移植挺重要，我就做过一个项目，最初在Weblogic 8.1下面作，然后移植到WS上，最后为了提供低成本的版本，全面移植到JBoss，其中这个框架和业务对象一直都没有改变，改得最多的就是deploy配置文件和xdoclet的一些调整项目。不过其间修改真是让人头疼。

我只是一个普通的j2ee程序员。我也说说我的看法。不针对什么。（因为觉得自己水平还是不高）
我以前是个ejb的狂热分子（Rod说的classic j2ee 开发人员）。每次别人说ejb不好的时候，我总是说，ejb不是你认为的这种东西。他是基于分布式，基于事务，...的组件技术。所以你说ejb的看法本身就是错误的。正因为ejb是基于这些的，所以ejb的复杂是必须的，这你都不懂说明你根本不理解ejb。所以你的反驳是错误的。
但我看Rod的第一本书的时候，我开始反思很多事情。我认为Rod对我影响最大的是：是否为了解决ejb要解决的问题就必须且只能使用ejb模型呢？是否同样的解决了ejb能够解决的问题的技术仅仅因为不是ejb就天然比ejb差呢？
我现在也还是基于ejb开发，但我在研究spring，hibernate。
我也许不一定会在项目里面使用这些技术，但我想知道的是ejb是否是唯一的必然的最好的选择。
无论把ejb说成是什么？这并不能成为ejb本身很多缺陷的原因。并不能因为ejb是ejb而必须如此。

Spring贫规范？不是吧。JavaBean规范就是最好的规范，你还要什么？难道像EJB那样硬性规定几个接口才叫富规范？规范越多，对系统的侵入性就越强，也就越意味着“绑定”。

P.S
你在容器外使用EJB以证明EJB复用性好完全毫无意义。要是愿意的话，Servlet也可以拿来在容器外用。JavaBean的好处无可置疑。最近我们的一个项目为业务建模制定了一组JavaBean作为基础VO，打包成个jar作为整个系统的基础组件，从fat client越过web service接口一直穿越到Hibernate持久层。换了Entity bean成吗。谈到Entity  bean我就要鄙视，什么玩意儿！接口做的跟个VO一样，一堆getter/setter，但就是偏偏不能拿来当VO用（我想没人干过把Entity bean用(bean: write)写在JSP上的吧！），实在是蹩脚透顶。