项目规模的界定!

》》》我认为确切地说应该是架构的可伸缩性。伸缩性何来？大部分人可能考虑的是系统功能性方面的架构因素，但是这是不够的，往往忽略了非功能性的考虑，诸如质量，维护，技能，人员等。所以好的架构不是鼓吹出来的：什么轻量级的容器，EJB负担之类。是应该来自对问题域的理解，寻求方案而来。
》》》》》

架构的伸缩性能提供保证对需求变化良好的解决手段，但对需求变化的管理和控制是保证需求变化的有序和粒度以及反回来影响需求变化的频度，这是从管理方向来说。但需求的变化跟什么质量，维护，技能，人员有什么关系，解决需求的变化应该说去处理需求的变化跟这些又有什么关系，基本上没有关系。

应该这样说，需求的变化基本是客户提出来的，那你就得做。你要做吧，那你就先要进行需求变更风险评估，结果基本是做的，那做就要要求系统有良好的伸缩性来适应。

并且如果你偏要比较Ejb以及它的容器和其他的轻量级容器就伸缩性来说，那ejb毫无疑问是占上风的。如果什么都不要考虑，就考虑如何去适应客户业务的变化和膨胀，那当然ejb是最佳。
其他管理方向的手段那是另外讨论的问题。

先谢谢各位对帖子的关注!下面是我的几点疑问:
1.首先对于ejb的性能,我觉得应该是有一些影响,我如果使用了ejb,那么我的web服务器首先要进行jndi查找,然后在ejb端与数据库进行交互.但我如果不用ejb,那么我就直接在web服务器上与数据库进行交互了.
2.其次关于ejb的性能问题,我做过一些这方面的项目,但大部分不是太成功,很多人把这归咎于ejb,我不知道这到底是系统设计的问题,还是什么原因,既然banq的系统很成功,能否把一些测试的数据分享一下,让我也有个直观的感受,当然不方便也就算了.
3.就是分布式部署问题,这个问题可能有些弱,就是ejb的弹性表现在哪些方面,我能把系统开发的ejb组件分开部署在不同的ejb服务器上吗?我的web 服务器怎么与这些ejb服务器进行交互.这些概念虽然早熟于耳边,但由于没有参与过这方面的开发,始终没有一个清醒的认识.

"架构的伸缩性能提供保证对需求变化良好的解决手段，但对需求变化的管理和控制是保证需求变化的有序和粒度以及反回来影响需求变化的频度，这是从管理方向来说。但需求的变化跟什么质量，维护，技能，人员有什么关系，解决需求的变化应该说去处理需求的变化跟这些又有什么关系，基本上没有关系。

应该这样说，需求的变化基本是客户提出来的，那你就得做。你要做吧，那你就先要进行需求变更风险评估，结果基本是做的，那做就要要求系统有良好的伸缩性来适应。"

没有哪个架构能很好的保证或满足需求变化，更不能满足系统的膨胀。最贴切地就是刚设计好的架构，再开发后马上就变了型。因为架构是需求下的产物，要一个定型的架构去适应频繁的需求变化是困难的，应该让需求变化来催生架构的改进。因为我们欢迎需求变化！这也是XP/敏捷所提倡的。如果架构去反适应需求的变化，最后只能是不能满足需求。

还有我并没有说质量，维护，技能，人员和需求有什么关系，我只是把他们定为“架构因素”，从而做出某种“架构抉择”。

>>>1.首先对于ejb的性能,我觉得应该是有一些影响,我如果使用了ejb,那么我的web服务器首先要进行jndi查找,然后在ejb端与数据库进行交互.但我如果不用ejb,那么我就直接在web服务器上与数据库进行交互了.

首先你不可以lookUp()一次查找然后缓存起来吗？如：

public static EJBHome getEjbHomeByName(String name, String jndiName) {
EjbNameUtil.setAnyName(name);

String homeName = EjbNameUtil.getHomeName();

if (homeMap.containsKey(homeName)) {
return (EJBHome) homeMap.get(homeName);
}

EJBHome home;

if (jndiName == null) {
home = (EJBHome) lookUpHome(homeName);
}
else {
home = (EJBHome) lookUpHome(homeName, jndiName);
}

homeMap.put(homeName, home);

return home;
}

看明白了吗？还有ejb是一个一个的bean,你可以定义在在pool里初始化多少个，将来你获得bean的时候，基本上是jdbc获得resultSet,然后resultSet把值赋给bean的每个属性，这样的话效率基本和你直接jdbc一样，只不过多了一个把resultSet转换道bean的每个属性的过程(但你要对象编程啊，即使你不用EJB也会把resultSet转换到vo或其他的javaBean,所以这部分都一样)，后面就是网络传输的延迟了。但如果定义pool适当，就减少了new的过程。所以基本上少了lookup过程和使用值对象模式，使用EJB的话效率不比hibernate差多少，有人说大量查询EJB就差的不得了，那是你不会用的原因，不要怪EJB。举个简单的例子，如果有一个Abean,基本上如果业务常对它进行大批量查询，你完全可以设定好它的pool的大小，然后设定该查询方法对事务为nosupport,这样的话你的效率应该很不错。其他的如何调优，我想太多了。呵呵，自己认真的想想吧，不要跟着人云亦云的。
其实有多少人真正的懂EJB呢，我很怀疑。

》》》》》2.其次关于ejb的性能问题,我做过一些这方面的项目,但大部分不是太成功,很多人把这归咎于ejb,我不知道这到底是系统设计的问题,还是什么原因,既然banq的系统很成功,能否把一些测试的数据分享一下,让我也有个直观的感受,当然不方便也就算了.

ejb的性能问题要优化有很多策略，在这里我不多讲，但我举一个反例，我看到过有一个项目基本没有调优，使用jbuilder生成就用，我的天啊，有可能傻惯了，所以一直傻，就象某写人说***.studio开发很快，然后就锻出中国这样的程序员水平，jbuilder生成出来的你要进行调整啊，该local的要local，该修改ejb-jar.xml的要修改，支持pool啊，该readonly的啊要设置，该lazyload啊要lazyload，不是每个方法都都要requried的等，该使用模式的要使用模式，该自己做缓存的要做，不能以为一切都是IDE和容器包办，不要那么不思考，那么的懒惰。

》》》》3.就是分布式部署问题,这个问题可能有些弱,就是ejb的弹性表现在哪些方面,我能把系统开发的ejb组件分开部署在不同的ejb服务器上吗?我的web 服务器怎么与这些ejb服务器进行交互.这些概念虽然早熟于耳边,但由于没有参与过这方面的开发,始终没有一个清醒的认识.

你这个问题不是我说你，你也使用过ejb开发吗？ejb组件分开部署当然可以在不同的ejb服务器（最好说容器，不要说服务器），甚至极端一点你可以一个Bean发布在一个ejb容器里，呵呵，他们之间是可以经过远程调用来协作的啊，唉，说真的你对ejb认识还不深，懂rmi吗？你完全可以用它的原理来理解ejb。ok!

“1.首先对于ejb的性能,我觉得应该是有一些影响,我如果使用了ejb,那么我的web服务器首先要进行jndi查找,然后在ejb端与数据库进行交互.但我如果不用ejb,那么我就直接在web服务器上与数据库进行交互了.
2.其次关于ejb的性能问题,我做过一些这方面的项目,但大部分不是太成功,很多人把这归咎于ejb,我不知道这到底是系统设计的问题,还是什么原因,既然banq的系统很成功,能否把一些测试的数据分享一下,让我也有个直观的感受,当然不方便也就算了.
3.就是分布式部署问题,这个问题可能有些弱,就是ejb的弹性表现在哪些方面,我能把系统开发的ejb组件分开部署在不同的ejb服务器上吗?我的web 服务器怎么与这些ejb服务器进行交互.这些概念虽然早熟于耳边,但由于没有参与过这方面的开发,始终没有一个清醒的认识.”

1。项目规模比较大且需要分布式的支持的话（当然不满足这个前提也是可才用的）可以才用分离表示层和领域层（jsp/servlet + ejb）.进一步考虑到系统的伸缩性，在领域层上才用应用层（外观。工作流）是合适的，他保持了ejb的内聚性，提高领域对象的重用性。如果小项目不需要分布式支持，那么一些轻型的解决方案也是可行的，例如比较流行的spring＋hibernate/jdo2

2。如果ejb性能方面是你系统主要关注，确实很苛刻的话，可以做一下性能测试再决定是否使用它。决定一件事不要人云亦云。此外，我很想问你，你自己能完成ejb的对象池嘛？能做到分布式嘛？能分离系统基础的各个方面，做到系统内部的低耦嘛？比如，安全和事务。问题不是出在ejb容器，而是你对全局的考量。

3。呵呵，你有机台服务器....

to
to kidwish:
<<<<<没有哪个架构能很好的保证或满足需求变化，更不能满足系统的膨胀。最贴切地就是刚设计好的架构，再开发后马上就变了型。因为架构是需求下的产物，要一个定型的架构去适应频繁的需求变化是困难的，应该让需求变化来催生架构的改进。因为我们欢迎需求变化！这也是XP/敏捷所提倡的。如果架构去反适应需求的变化，最后只能是不能满足需求。

还有我并没有说质量，维护，技能，人员和需求有什么关系，我只是把他们定为“架构因素”，从而做出某种“架构抉择”。
>>>>>>>>>>>>

架构说跟我常合作的ejb,ejb是叫做业务组件，别理解错它了，它不只是域模型，什么是业务组件，就是具有相对独立的业务逻辑封装的实体，具体一点我可以把一个订单业务用一个sessionBean来表达，外面客户端经过service 接口来调用我这个业务，如果订单业务改变了（业务逻辑变化，是需求变化的一种），我的主人可以只要修改我这个sessionBean就可以了，客户端不要做任何改动，如果有新的业务要增加，我的主人就给我添加一个sessionBean兄弟好了(需求增加)，如果有一个新的业务兄弟A需要在我的订单业务逻辑过程中进行
先处理，如果A也是我的EJB兄弟的话，只要在我的逻辑中对他进行调用就可以了（业务逻辑变化，需求增加），如果有其他兄弟应用系统在它自己的服务器中需要改变在它某件事情时需要订单业务数据参与处理，那它从它的应用中调用我好了（业务逻辑变化，需求增加）。呵呵，你说这是不是从技术方面提供了一个很好的适应需求变化的手段呢，你不要告诉我你说的那些EJB能做的我用其他的都能做哦，那当然了，但i服了you，如果你也去写另外一套的ejb的话，自己学rmi啊，自己来处理事务啊等等，天啊。

所以需求变化是要业务组件来适应的，而不同的业务组件有着不同的适应能力，就是所谓系统的伸缩能力，如果你用一般的java
class做为业务组件的话，你适着想上面问题的解决，你头会大的，明白吗？呵呵，好了，我觉得我们老是离题好象，架构提供的是什么，是适应适应你的需求变化的组件。需求变化需要业务组件的变化来适应，架构只是埔助业务组件完成业务组件所需要的服务。

呵呵,首先我知道web container访问ejb container需要进行rmi操作,我的意思是服务器之间的交互怎么进行,比如我用一个Tomcat,然后启了5个Jboss,这些jboss里有我开发的ejb组件,tomcat怎么通过jnp来访问jboss呢?

不管是 web container访问ejb container还是ejb container之间互相访问，都是经过rmi调用，协议当然可能是jrmi或者iiop,这个要看ejb container的实现。

to neksai

我觉得你的说法有些偏执一个"完美"的方案或设计.ejb固然好,但是你能保证他不被淘汰嘛(我只是假设...)

你所有的问题都从技术的角度去看,是无法看清全局的...

我想你理解错了，我何来偏执，从那些信息得出？我也没有表达所有问题技术角度解决就可以了，我是说就技术的角度，因为大家在这里说的更多的是到底是with Ejb还是without eej,是技术问题引申出来的到底需求难于界定的时候采用何种技术，是讨论从技术方面解决需求变化的问题，那么我也推荐就主要而言采用ejb技术是比较好的，我也举了例子来说明从技术角度来提供一种手段。不否认，管理上的管理和控制来的更有效，你可以看其他帖上关于我对需求变化从管理方向的一些建议和理解。
在说我从来就不是ejb的传播者，也不是其他方案的支持者，我就是要按自己对事务本质的理解来选择自己认为合理的技术方案，听清楚了是技术方案，这里我说的技术，我也说了技术只是一个风险中的小部分，不要看了就瞎说我什么从技术来看全局，技术的方案是等你看完全局后才做决定的，当然要权衡，如果就什么都不考虑，为了满足伸缩性，当然是EJB了，我是这么说的。

置于ejb要淘汰的话，我只能告诉你那一定有另外一种能满足现在EJB所有的好处以上的EJB出现（这句话好好好想想，为什么这么说），而不是因为现在有什么hibernate或者有spring框架，这些都不能作为ejb要淘汰的依据，因为他们没有EJBde 优点。当然如果某个人定义出了更好的一种ejb规范，那也是现在的ejb淘汰之时。君不见的ejb1.X的时候,you有新的一种ejb2.0来替代，而不是什么OJB，千万不要认为ejb1.X和ejb2.0不都是EJB吗，它们只是名字有点像和定义他们的都是同一个父亲SUN,但他们是有很多不一样的，那马上要到来的EJB3.0要出来了，当然它跟EJB2.0又有很多不一样，说到此，不管是不是把EJB2.0和EJB3.0的名字改不改为nekesai还是Kidwish，这都不是本质的东西，本质的东西就是他们都跟EJB1.0一样支持分布式计算，事务容器自管理，安全和服务容器能提供等好处，不管谁代替谁都要有这些东西。

呵呵，所以我觉得那些问“你能保证ejb不被淘汰吗？“的问题，是一个很傻的问题，不值的问，为什么，因为我基本就不管它是不是EJB，我只管它有没有ejb的好处就行，哪怕它来个变脸说我EJB3.0要变成NEKESAI1.0了哦，你用不用，用的话我告诉你ejb已经淘汰了哦，哈哈，这是傻瓜，NEKESAI1.0不是一样做做着ejb那些勾当，换汤不换药。但如果你把药都换了就如hibernate，是不能代替EJB的。为什么，自己想想，想些本质的东西，不要瞎掰。

至今是w/ ejb还是sans ejb还没有令人信服的理由。众说纷纭，莫衷一是。这其中有politics的目的，有舆论的导向。我没有真正使用过ejb开发大型系统，也没有发言权。不过事物存在就是合理的。正于辩论java好还是.net好一样，如果你有一个虔诚的religious mind，就用你喜欢的技术好了，谁也没法阻拦你。呵呵。

to nekasai

我觉得在这里争论ejb或without ejb没有多少意义，每个人站的立场不一样...

ejb是有很多pros，但是也是有很多cons的。究竟应该怎么样，应该由决定采用他的人来决定。回到最初的80/20，就是那么回事。他根本不用什么鼓吹。你“觉得”好用，够用，OK！就是他了！

是啊，是立场不一样，其实立场是一个挡箭牌而言。首先，我先表明我的态度，我不是ejb的pros,是我老觉得业界有些人在瞎掰，做着让客户买两个一好多万的weblogic,然后自己干起使用它的JDBC勾当，这就不对了。立场，什么是立场，符合自己的利益的就是立场，我明白，这里也不是讨论这样问题的是非，是纯技术的讨论。我老觉的有些人在捣浆糊，在大放一些自己都不能圆说的阙词，搞的好像自己很辨证似的。
不知道各位是否认真了看了帖子了没有，否则就必要瞎说。

我说了我的结论的前提是：如果只考虑系统的伸缩性(不考虑其他的，如你老板说招一个做EJB的要好多MONEY啊),意思就是说你现在已经知道客户将来的业务要快速增长了，应该出于客户的需求变化的需要最好选择EJB技术，我只是在JAVA范围内比较哦，本人不懂.net。

呵呵，偏偏有些人是叫着客户买着weblogic,然后自己只使用它的datasource.这些人想的立场就是这个。当然用着自己熟悉的技术没有什么无可厚非，但欺上瞒下就不对的，还有基本有很多人都没有用过EJB，甚至有些人不懂什么是EJB，然后看了国外的一些论坛或说法以及国内有人先点火就跟着瞎掰，这些人大有人在。^_^，可悲的是这在在我们的IT界里。

一种技术你衡量着用吧，有些人从来没有过ejb, 它说我用的过程中自己也写了一个EJB哦。如他一开始固执的不用选用EJB,然后发现了jdbc不能管理global事务了，他去找啊找，终于发现了tryx或jtom，然后呵呵自己来使用里面提供的xaconnection,费了九牛二虎之力终于解决了跨数据的问题，哈哈，后来发觉系统运行效率太慢，然后有找啊找，找了了一些pool库，或者自己写一个，自己又弄啊弄，哦总于也累的半死的总算吧运行效率改善了点，啊，然后发现引入这些东西，或者自己写的这些东西稳定性很差啊，甚至又内存溢出，唉，又弄啊弄，弄捣最后自己累倒了，然后某一天他看对我的帖了，他说，唉早来这里就好了，这些问题ejb容器都又哦，干吗不使用EJB呢，唉真傻，相见恨晚啊，EJB.

当然，如果客户提的需求就这样，按他的业务将来也不会增加多少，变更也不大多，呵呵，没有问题strtut+dao+vo，dao里直接jdbc都可以搞定。^_^，但不要跟客户说你去买一个weblogci哦，那他妈的又是自己的立场了，受不了。

>>>>
不管是 web container访问ejb container还是ejb container之间互相访问，都是经过rmi调用，协议当然可能是jrmi或者iiop,这个要看ejb container的实现。
-----------
可能我的表述还不是很确切,举个例子换个角度来说吧,假使我开始的系统部署在一个tomcat和一个jboss下,我有一个jndi.properties来记录jndi的主机和协议等信息,现在我要对它进行分布式部署把它的ejb组件分别部署在五个jboss上,那么我的web container端就需要配置5个jndi.properties,然后我要修改我的客户端
代码让他们可以访问它们将要访问的的ejb container,如果我这些ejb container之间有相互的远程调用,那么我还需要修改他们通过jndi访问地代码,不知我地
叙述是否正确,如果不正确请给出正确地流程,如果正确,那么ejb提供地分布式部署地弹性还确实是有一定地限度地,呵呵!

to nekasai

你言论就像是牢骚,不要再说这种无意义的话,浪费版面!