参加4月4日Ben Wang的JBoss讲座纪实

呵呵，我SHOW什么呀？老实说这些技术我都没有玩过，只是看了一些文章凭空想象而已，但我现在确实需要考虑这样一个J2EE的方案，就是发现有这么多名词，头痛啊！

我确实不知道JBOSS居然可以和TOMCAT运行在一起，现在好象做WEB的也要做APP，做APP的也要做WEB，就连做数据库的也要做WEB和APP，都想统一天下，以后都分不清谁是谁了，对不对呀？:)

关于APP与WEB分开部署的问题，我前面已经说过了，如果我希望对第三方提供接口，而且希望APP与WEB隔离开来，那就有分开部署的需求啊。

如果不分开的话，那就没有WEB与APP的通讯层，再加上可以直接利用WEB SERVER的SESSION复制机制，那就更不需要EJB了，我也不会有烦恼了。可是现在我必须分开这两层，考虑到对层间通讯的负载分担和可靠性，以及SFSB的同步，看起来还有使用EJB的必要。

WEBLOGIC我也没有用过，但我知道我一定不能用它，因为需要钱，而我的目标是寻找一个完全FREE的方案，呵呵，是不是太苛刻了？可是现在开源资源越来越丰富，没有可能吗？

首先明确一点，集群，分布式以及负载均衡均是不同的概念，它们之间存在共同点，但是有很大的不同，这个说起来的话很复杂，大家可以看看相关的文档。
从kingkii所表述的意思来看，按照kingkii所选择的架构需要采用J2EE集群，应该说集群不是一个好的选择，不管是bea的技术支持还是从各方面的了解来说，集群所带来的性能提升和也许不到30%，它的好处在于高可用性(Hign Availability)，包括Failover和理论上的零当机，当然还有其它的方面。但是，J2EE集群所带给我们的缺点却是非常明显的，不但技术不是很成熟（至少从我了解的情况来看），从而带来的从编码、技术支持、产品维护等一系列问题；以及集群所耗费的资源开销和产品成本的上升，使我们不得不另觅它法。

一种变相的解决方案：负载均衡器 + N个app/web server + DB Server，负载均衡器做一个proxy的作用，比如采用apache做负载均衡，所有静态页面放到apache上，jsp请求通过apache按照proxy定义的规则分发到不同的app/web server 上，多个app/web server 之间没有横向的联系；唯一要做的就是实现分布式（cluster）cache（OSCache，SwarmCache，以及Tangosol.Coherence，SpiritCache都有实现）。这样的话，在一定程度上分解app/web server的压力，达到负载均衡的目的。

不知大家有没有别的好思路。

这样的话有一个问题，如果我期望将某些业务逻辑对第三方开放，而不仅仅是WEB，那还是需要将逻辑转移到APP上来，那一个APP SERVER肯定不行。
还有一点如果各个WEB SERVER之间无横向联系，怎么支持FAILOVER啊？

有几个问题需要明确一下：
你的要求：
1、业务逻辑做成组件
1、failover以及HA的支持

我想，其实问题集中的焦点还是在于failover以及HA是不是必须的（简单点说就是分布式是否是必要的），这个需求的确定不单单是程序实现上的考虑，还有从成本，资源以及技术支持的可能性上综合评价。

如果你能够确定bottleneck都集中在app/web server层面，可不可以通过app/web server的压力分担来解决问题，总之，一旦选择了多个app server，那么必然要考虑集群的实现问题，如果不考虑业务逻辑之间的共享（也就是跨jvm调用），那么只需要考虑分布式的cache。SwarmCache、OSCache等等都是支持cluster的，做得比较好的是Tangosol.Coherence（收费）。

这样的功能实现起来也不难,可就是没有什么人去做呢?
不就是根据Method动态生成一个Proxy/Stub吗?
我看过一篇文章说COM+就是用了非常多的Interceptor Pattern来时间Transaction等等功能的.
这点不值得Java Community考虑的问题呢?

关于server affinity的问题,有没有什么free的东西?
windows 2003, Websphere都有方案可是问题在于太platform specific了?

首先非常羡慕robbin、dlee、曹晓钢等有这么好的机会，能够与ben有亲密接触的机会，唉，我是想都不敢想。生活在大城市就是好啊！
    虽然没有听这次讲座，不过从各位的表述中已经明显感觉到了hibernate的优秀作用和无量前途。在我这个项目的下次迭代中，100％要加入它了（幸好我的架构与具体框架无关）。我也非常希望hibernate能成为事实的标准或者融入标准，这样有更广泛的代表性了。J2EE规范中Entity Bean的确是太差了，早就该改进了。
    不过余下来的讨论，我就支持joachimz了，对于femto和dlee，我个人觉得是偏激了些啊！EJB真正强大的是在于分布式，它最初设计的目的也就是为了解决分布式的问题，便于快速地进行分布式的开发（所以在1.0、1.1中，没有Local的概念）。也许正因为如此，它庞大了些。其实也正因为如此，才会有Spring等轻量级框架的诞生。可以说，他们不是太冲突的，双方的应用范围和特点都有独特性（EJB想追求全面，这是个失误）。各位没有用到分布式的EJB，没有用到集群（不仅仅是负载均衡），没有用到分布式计算，没有用到分布式事务和分布式的安全体系，而盲目地去表述EJB体系（非实体bean,）我觉得有些欠妥啊。也许一般的项目真用不到，但是大型的应用软件体系并不少的。
    最后，我是希望好东东都能够相互融合，相互促进（各位不要随意一棒子贬低太多技术），至少我们不像SUN、IBM那样的公司，有太多的“政治”考虑的。

agree, 如果真的需要HA和分布式，我想目前来说EJB是唯一的选择，但是有多少应用的机会呢？集群。。。我们真的很少这种环境的。

我不知道负载均衡、cluster和分布式这些术语之间有什么关联和区别。据我的理解是，
如果业务和数据是是分散在各个地方的，才真正叫分布式，这时使用ejb会比较合适，而对于业务和数据集中管理的场合，使用app的负载均衡我想就应该可以提高性能和可靠性了。例如我们以前做的一个香港项目，app 和db server全部放在香港机房，而澳门、珠海和泰国分公司通过browser来访问（因为使用者香港居多，其他每个地方只有几个人才会用到）。这种场合，其实不一定要用到ejb，利用他的几台服务器做个负载均衡就ok了。另外一些诸如OA、MIS系统，多数都是集中管理。
对于一个业务分布较广的企业，例如银行之类，他的数据中心是分布的，广东分行有自己的server，上海分行也有自己的server，这时两行之间的数据和业务交流可能就会用到ejb、corba或者甚至是web service等等。
另外，ejb提供了一种组件的统一访问方式，可以使用基于java的各种客户端程序来访问。

如果认为EJB的最大好处在于分布的话，那可以用的技术多了，比如CORBA、RMI、SOAP或XML-RPC，甚至于古老的ROSE，还有电信中常用的SNMP、CMIP都可以实现分布啊，为什么一定要选择EJB？我倒是觉得如果没有其他特性的话，我不会选择EJB，我最看中的特性是集群，主要包括以下特征：
1）Session状态自动复制（这个现在好象不提倡用）
2）内存数据库，也就是CMP具有cache功能，尤其是需要在集群的机器之间以及和数据库之间保持同步功能，我不知道现有的产品在这方面做得如何。现在随着Hibernate的兴起，CMP也用不上了，但是Hibernate能满足我说的要求吗？
3）其他的特征我倒觉得可有可无，如容器管理的事物，安全等，而且这部分也正在被Spring替代。
这样看来，谁能告诉我还有什么必要使用EJB吗？