|
锁定老帖子 主题：论Spring与EJB的组件架构
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2004-09-20
gigix 写道 raimundox 写道 而且我从来没说过ejb的业务逻辑中说，而是该在外说，在容器里说，在部署里说，也是我为什么说deployer重要的原因，事务scope是他们界定的。
好了，现在我们都同意：组件的业务逻辑不应该涉及“要不要事务管理、要什么事务管理”这样的基础设施。那么我请问你，既然组件的业务逻辑不应该涉及这些，难道把组件模型的技术架构跟这些玩意捆绑在一起就显得很合理了吗？如果可选的话，难道POJO不是更自然的选择吗？ ejb是怎么捆在一起的？deployment description！代码里有吗？没有。pojo呢？xml based context description，有区别吗？有，一个是标注准技术环境，一个你自己定义的。 你大可说自己定义的更灵活，但这不意味pojo更自然，pojo不是组件模型，ejb是。我承认pojo+可订制容器环境形成了轻量的组建模型，但我不认识这就是最好的。因为你可以在你的context里复用你的component，而别人需要复用你的container才能复用你的component。 为什么不有个联盟统一技术语义，给contianer一个标准？这是我对spring认可也是质疑。用spring实现一个ejb3 container，用轻量方法的实现标准的语义，都是我感兴趣的东西。 |
| 返回顶楼 | |
|
发表时间：2004-09-20
raimundox 写道 why transaction?我在电力行业做过一阵信息化软件架构师，在电力这样一个需要处理大量数据的领域里，很少有oo model，而是做完entity分析，交给dba去优化，以数据性能为主，这样的系统里，数据操作的粒度就是transaction，而不是object或是别的。我想这该算是一个大型企业级系统，我看到的是transaction，因此ejb这个把scope定在enterprise级的东西而言，这样的设计还使合理。而且ejb对transaction这部分的处理确实比较完整，cmt，bmt，不同的transaction scope控制的都很好。基于这种认识，我认识transaction script是ejb的标准应用模式，而不是domain model或是别的。
这是对ejb最大的误解的来源，我看过的所有ejb书里，只有o'reilly的一本隐约提到transaction是ejb的中心。其他一律不提，疯狂的鼓吹ejb多好多好ejb多么万能，我想，如果不知道ejb是transaction-oriented的，那么ejb奇怪的对象模型的确不可接受。 EJB是怎么来的吗？它本来就是从TP Monitor和分布式对象管理器发展而来。所以EJB的真正价值本来就是Transaction 和 Distribution。我从来不知道有人会误解EJB不是Transaction based的。所以这一炮等于自己虚构出来一个靶子，然后对它猛烈的开火。 raimundox 写道 由于scope不同，其实比较spring和ejb那个更适合企业开发没什么意义，因为这里面根本就是两个不同的范畴，在scope上指责ejb不如spring，就好像说raimundox，你就不能替老婆把孩子生了，还让她那么痛苦的怀胎十月。其实我也不想，我也想替，可惜我们这功能.....扯远了，ejb也是，没这功能你怎么强求他呢？你要说ejb设计的不好，也不对，人家有专门的领域。因此我说，在scope上比较spring和ejb没意义，根本不是一个级别的
任何技术的使用都是有一定的前提的。就好像批评Hibernate不适合OLAP，批评汇编语言不适合OO一样，脱离了应用的前提，讨论就失去了意义。如果不限定scope，比较Spring和EJB也是没有任何意义的。 我觉得你与其拿着规范泛泛而谈，还不如像你自己所说，限定一个scope，然后再进行比较。例如在XX行业，什么比较好，在XX环境下，什么比较好，诸如此类。 raimundox 写道 Component architecture有一个基本观点，就是component和context的分离，理想情况下，component只负责业务的实现，而container提供context，这个context只技术context，比如事务比如安全的支持。于是，component architecture的基本观点就是business关注点和technique关注点分离，business由component负责，technique由context或者叫container实现。那么很明确了，component architecture里有两种编程，针对component的和针对container的。
好，有了这个理解，我们可以继续了，如果有人有疑意，那么抱歉，这片文章并不适合您，后面全部的论点都是基于这个观点的，如果不认可这个，下面的也不会认可，您也不用浪费时间了 任何框架都是有侵入性的，完全没有侵入性的框架是不存在的。你首先设定一个我们都不认可的前提条件，然后说如果我们不接受这个前提，就不要浪费时间往下看了。这还是等于自己虚构出来一个没有人认可的靶子，然后开火。 raimundox 写道 上面我们已经看到了spring和ejb都是component architecture，那么component能想到的最直接的用处就是复用。那么比较这一点就是比较ejb和spring component architecture的关键。看到这里spring的支持者们该常出一口气了，spring复用一定强于ejb复用，赫赫，但我的结论正好相反，ejb复用优于spring复用！！收起你们的愤怒，收起你们不屑，听我把话说完。
你对复用的理解是不对的。组件的复用有一个前提，是在他的容器内的复用。也就是说你应该比较的是在Spring里面编写的组件，它在Spring环境中的复用程度，和EJB环境里面写的EJB组件他的复用程度。而不是你所说的组件写好以后，我们把容器完全抛开来谈复用。所以你仍然在设定一个虚拟的靶子开火。 引用 在component architecture里，component是业务实现，而不该有技术代码，就算用也要通过容器环境去和容器交互来完成操作，比如ServletContext等东西。那么其实组建结构下复用的关键不是组建而是容器！！
嘿嘿，组件里面完全没有技术代码是不可能的，我们只能做到技术代码比例尽量的低，事实上，反倒是EJB里面混有的技术代码比例远远高于Spring组件，这一点，如果你编写过EJB，不会不清楚。 引用 以前有一个颇有名气的dx(gigix别看了，说你呢)，说"COM和EJB都鼓吹模块化和复用，模块化是真的，复用是骗人的",com我不是很熟，不好下结论，ejb呢？ejb不易复用我承认，但是骗人吗？不骗，后面我给出一种ejb复用的思路大家参考。反正组件一点技术都不作，只有业务逻辑想用就要有相应的容器环境，那么容器环境的复用性才是组件复用的关键。ejb不易复用是因为如果脱离容器，我们就必须给它提供相应的技术context，事务、分布、并发等等一个也不能少，因此容器外复用ejb效率很低。注意，是容器外，组件本来就是跑在容器里的，谁让你非要拿出去用），而容器内呢？因为ejb规范规定ejb容器应该兼容，别说webSphere到bea的移植有多难，其实不难，或者说难度比把spring组件移植到pico复杂一点，当然你用vendor-specified的特性就没办法了，这不再规范内，你违规就别怨人家。因此，ejb的复用是可以的，而且是规范保证的，容器外也有办法，也不是很难，我后面说。
我上面已经说了，复用不能脱离容器来谈。你现在树立的靶子是脱离容器谈复用。 引用 比如有个componentA，在SystemA里需要事务模型A和安全模型A，在SystemB里需要事务模型B和安全模型B，当你从SystemA里复用componentA的时候，你要怎样？重写事务模型B和安全模型B
我还是强调复用不能脱离容器来谈，compomentA他永远只在Spring这个SystemA中，而不会搬到SystemB去。所以你下面那些话又是自己树立了别人都不认可的一个靶子，然后开火开的十分起劲。 引用 对于组件还有一个问题就是部署，这也是ejb为人诟病的地方.的确,ejb的部署够复杂，但在ejb规范里有一个专门的角色来负责部署的，ejb是component architecture，那么比如有一个人来粘合技术和业务，这个人不该是programmer(我刚才说了，ejb的实现者最好是业务专家，实现业务逻辑)，ejb的部署才是很厉害的人，他需要知道什么业务需要什么样的技术支持，该怎样得到性能，因此deployer才是ejb architecture里最牛的，我重来不以为写ejb的是高手，但是一直都敬仰ejb的deployer
EJB需要一个部署的角色，但不是你理解的那种角色。他并不是如你所说的来粘合技术和业务，编写ejb-jar.xml的，这些工作是程序员自己的事情。部署者他的真正角色是应用服务器管理员，他要做的事情是监视应用服务器的性能，对应用服务器进行性能条件。我建议你多接触一些EJB项目，特别是分别做一下这些角色，我还是感觉你缺乏这种经验。 引用 那么spring复用的问题表明了什么呢？其实是缺乏语义的支持，ejb开发可以看作在一个统一的语义环境下来作的，这个语义由ejb规范规定，因此ejb的复用有语义保证，而spring呢？贫语义，一切都要开发者自己来实现。因此，如果ejb的环境语义可扩展并且可配置（比如去掉分布），那么spring毫无优势，标准的一致的完整的组件架构使ejb会大有作为，但是现在并没有，才有了spring的火爆.这是一种畸形的胜利，完备语义的输给了贫语义的，问题是什么，强迫消费...谁让ejb非得强迫客户去买用不到的分布式环境的单？但是统一语义的威力不会因此掩灭，现在有两条路，spring联合os社区，制定lightweight j2ee语义集合，争取成为标准。第二，ejb实现技术语义可配置可扩展。谁会胜利？不好说，但是似乎ejb的脚步快一些！
其实你的意思就是说有统一的标准比较好。现在EJB标准有问题，所以spring流行了，如果EJB标准确实很好很实用了，EJB才是主流，Spring就会像EJB靠拢。 这话完全正确，如果不是EJB2太不实用，Rod干吗要去自己开发Spring呢？如果EJB3真的那么棒，Rod干吗不和EJB3兼容呢？至于说谁会胜利，我不觉得他们是竞争关系，就好像我们过去总喜欢拿Hibernate和CMP当做竞争对手一样，来比较谁的生命周期长一些，现在回头看看，当时那种争论根本就是浪费时间。 整个文章看下来我感觉很吃力，可能是行文的语言表达不太通俗，理解起来比较费力。另外就是文章大多数观点都是先树立一个没有人会反对的论点，然后虚拟出来假想敌，自己批的很高兴，实际上就是自己树靶子，自己打靶子，完全是一个自娱自乐的状态。 我是觉得没有什么可争论的。 |
| 返回顶楼 | |
|
发表时间：2004-09-20
pojo不是组件模型
我不赞同这个观点！ 关于component的定义，我们可以看一下W3C的定义： A component is a software object, meant to interact with other components, encapsulating certain functionality or a set of functionalities. A component has a clearly defined interface and conforms to a prescribed behavior common to all components within an architecture. [CCA T&D]A component is an abstract unit of software instructions and internal state that provides a transformation of data via its interface. 另外，业务组件不应该跟事务处理绑定在一起！ 业务组件是一个POJO更好！当然，这很难做到！ |
| 返回顶楼 | |
|
发表时间：2004-09-20
唔……implements SessionBean，这还不够“捆绑”吗？
我不在乎它是不是组件模型，我也不在乎它是不是标准，我只要方便、灵活、可移植。以后会有更多的标准，譬如EJB3，我也不在乎。我在乎的是，我的程序应该是POJO，应该是最普通的Java Bean，应该允许我做任何的OOD。既然我可以选择POJO，那么即便多一个接口的约束也是多余的。这大概就是我们选择的标准不同吧。 另：你可以找出一百条理由来论证“别人需要复用你的container才能复用你的component”，但一个POJO和一个EJB哪个更可复用，这只是个常识问题。就像potian说的，如果说POJO都不可复用，那么我们就再也不必讨论什么复用性的问题，因为不会再有任何可复用的东西。 |
| 返回顶楼 | |
|
发表时间：2004-09-20
raimundox 写道 其实ejb在容器外完全是可以用的，但是为了最大限度保证能用，bean-managed是推荐（不是cmp，bmp而是cmt,bmt），那么怎么传送一个transaction进去？SessionContext(好像是这名记不清了，都快2：00了，困呀...就是ejb那个context接口)，一个接口嘛，自己mock一下，给一个transaction进去就好了。怎么装配？spring的setter injection。如果用spring，那么cmt也可以实现，拦截啦，不过就看能不能实现ejb transaction model了。entity bean，如果是bmp，就用它好了，cmp，继承一个上hibernate。这些都模拟好了，找一个in memory的jndi，把spring context封进去，这样相当于我们用spring实现了一个lightweight ejb container（其实就是给spring一个ejb api的皮），轻到什么程度？除了注射什么都没有。
然后client就可以构造jndi，然后lookup了 看到这里一定有人说，你吃饱了撑的，这么费劲容器外复用ejb，为什么不直接用spring，这样也不够pojo，每个组件都有ejb的类的继承，好，我告诉你这么做的好处，首先，虽然不够pojo，但是足够bean，因此spring来管理ejb是可以的，证明我的观点容器外使用ejb可以(赫赫，不要说偶rpwt...).其次的，当业务发展了，你的系统需要分布了，把spring去掉，拿出ejb，redeploy，ok了，延展，稳定，分布都有了，这才是复用该有的境界，改一个部署整个环境换掉，去掉lightweight的ejb container，换乘heavyweight的就是重量级。 当然这么实现很难，在ejb3里会容易些，我敢打赌，spring以后一定是lightweight ejb container的供应商，免不免费，os不os要看rod johnson了，不过我觉得希望不大。 jeffrey_he 写道 Spring推荐是这么做的：
将服务接口用普通的Bean实现，在Spring的配置文件中定义。如果需要分布的话，Session Bean调用普通bean实现服务接口，然后修改Spring的配置文件就可以了。详细资料可参考Spring文档中有关EJB的章节。 好处：测试简单，需要分布时，扩展一层EJB而不需要重写业务逻辑。 raimundox 写道 这是两种思路，我是把spring作为lightweight ejb container provider来对待的，那么一旦需要heavyweight，更换容器。而spring强调在spring里用ejb。
你提到可以让EJB脱离容器，也列举了方法，这样就可以使得在非EJB环境下使用EJB了。 我提出的是Spring所推荐的方式，让普通Bean来实现组件，需要分布时再加上一层Session Bean的包装。 不论是否两种思路，我们想要达到的目的就是“希望自己写的组件能够在EJB容器和非EJB容器下都能使用”，这也属于是组件可复用性的一部分。 你认为哪种方式更为简单？简单的方式就是更具效率的方式，更自然的方式，自然也是开发人员的首选。 呵呵，楼主看来今天要忙死了。 
|
| 返回顶楼 | |
|
发表时间：2004-09-20
to:potian,gigix
“可用”和“可复用”是两个概念。 POJO在哪里都可以再次使用，一个简单的对象而已。 但是要能够复用，不是能够把这POJO new出来就算是用起来了。 |
| 返回顶楼 | |
|
发表时间：2004-09-20
庄表伟 写道 to:potian,gigix
“可用”和“可复用”是两个概念。 POJO在哪里都可以再次使用，一个简单的对象而已。 但是要能够复用，不是能够把这POJO new出来就算是用起来了。 无状态的业务组件，确实是可以new出来就可以用的。 呵呵 事务管理，以及其生命周期管理可以选择具体的容器来管理。 我感觉，对于组件的概念，我们更关注的是业务组件，对于业务组件，我更关注的是它能不能够做到无状态，如果可以做到无状态，那我就会给他一些相应的Lifecycle接口，以适用与容器统一管理。 至于，一定要同一容器内才有复用的语义，我比较模糊也是不可理解，部署一个业务组件到容器中，就应该能够组成一个处理业务的核心，至于部署的技术细节，因容器而异1 说道这里，robbin 庄表伟，请解析一下我的困惑。一定要同一容器内才有复用的意义码？难道就不能在不同容器内复用码？ |
| 返回顶楼 | |
|
发表时间：2004-09-20
引用 一定要同一容器内才有复用的意义码？难道就不能在不同容器内复用码？
如果说是Servlet container，当然可以复用了，你不管怎么换Servlet Container都可以复用，但是如果你的组件是依赖特定框架和特定技术的话，你很难做到完全脱离他而存在。这里有一个前提，就是任何框架容器都是有侵入性的，侵入性越高，复用的可能性就越小，复用的时候修改的地方也越多。特别是像Spring，Hibernate，EJB这种框架，你应用了它，就等于接受了他一整套设计理念，要想无痛的切换到其他框架上面，是不可能的。 |
| 返回顶楼 | |
|
发表时间：2004-09-20
robbin 写道 其实你的意思就是说有统一的标准比较好。现在EJB标准有问题，所以spring流行了，如果EJB标准确实很好很实用了，EJB才是主流，Spring就会像EJB靠拢。
这话完全正确，如果不是EJB2太不实用，Rod干吗要去自己开发Spring呢？如果EJB3真的那么棒，Rod干吗不和EJB3兼容呢？至于说谁会胜利，我不觉得他们是竞争关系，就好像我们过去总喜欢拿Hibernate和CMP当做竞争对手一样，来比较谁的生命周期长一些，现在回头看看，当时那种争论根本就是浪费时间。 整个文章看下来我感觉很吃力，可能是行文的语言表达不太通俗，理解起来比较费力。另外就是文章大多数观点都是先树立一个没有人会反对的论点，然后虚拟出来假想敌，自己批的很高兴，实际上就是自己树靶子，自己打靶子，完全是一个自娱自乐的状态。 我是觉得没有什么可争论的。 我也觉得楼主这么多文字所表达的意思只有一个： EJB是有标准的，Spring是没有标准的。 文章中的论点和论据如robbin所说的那样：先树立一个没有人会反对的论点，然后虚拟出来假想敌，自己批的很高兴，实际上就是自己树靶子，自己打靶子。 因为“EJB是有标准的，Spring是没有标准的。”，这是一个现状，没有什么值得争论的。 |
| 返回顶楼 | |
|
发表时间：2004-09-20
我的感觉是，楼主不但想要比较“EJB是有标准的，Spring是没有标准的。”
还想进一步表达，EJB正在简化自己的标准，而Spring需要建立自己的标准。胜负尚在未可预料之间。 |
| 返回顶楼 | |
