J2EE without EJB

看到这本书有第15章：
15、Performance and Scalability —— 曹晓钢

又看到了这样一篇文章：
http://www.jdon.com/artichect/scalable.htm
以及这样的一些讨论
http://www.jdon.com/jive/thread.jsp?forum=91&thread=15634

不知道书里是如何回答的。

简单说，获得scalability的方式有两种：对象分布和应用集群。EJB独特的优势在于对象分布，然而对象分布不仅带来scalability，也带来复杂度的上升和performance的下降。所以Rod Johnson更推荐应用集群，就像chinaren那样的做法。

Rod Johnson 那本《expert one to one。。。》非常不错的一本书。他对j2ee每一层都有涉及。我看了英文版的前几章就去买了中文的，可惜翻译的有点水。

什么时候需要业务对象分布的应用?一般情况,web应用jsp和商业对象会部署在一台机器上,一般在web层实现集群就可以了,对于胖客户端,如果采用spring的http远程对象或soap,在web层实现集群也就可以了,业务对象分布的应用仅适用于rmi方式的胖客户端,不知我的理解对不对?

今天又看了J2EE without EJB,得出rmi式的胖客户端其实也不是必须使用ejb才完美,使用spring可以得到更透明的解决方案,那么到底什么时候才能需要分布式对象呢,J2EE without EJB中最经典的一句:Remember the First Law of Distributed Computing: Don’t Distribute Your Objects.宣告分布式对象几乎无用武之地

对于胖客户端来说，RMI肯定不是一个好的选择，因为RMI通常不是从HTTP上走，这样一旦有防火墙它就麻烦。现在做胖客户端，web service基本上已经是定规，只不过是具体采用哪个协议的问题。另外，分布式计算的第一法则最初是Martin Fowler提起的，而且我估计他也是从别人那听来的。这些玩意都是“古而有之”，没有哪一样是所谓“EJB的思想”。

to gigix 现在做胖客户端，web service基本上已经是定规?
我认为,用web service开发胖客户端是不合适的,首先胖客户端往往和服务器端是同一开发小组,使用web service有过渡设计之嫌,就拿axis为例,每一个接口客户端都要生成大量的stub类,管理起来是比较繁琐的,所以我认为spring的Lightweight Remoting: Hessian and Burlap才是胖客户端的首选.

我说的web service，就是包括了Hessian和Burlap这一类的，不光是指SOAP协议的web service。另外，你可能用axis的方法有点问题。我的经验，axis用起来和Hessian/Burlap的复杂度基本上是完全一样，连开发的步骤都一样。

服务器端开发是一样的,而客户端开发有区别,Hessian只需要从厂中得到对象转换为相应接口即可,而axis要生成接口,xxService,xxServiceLocator,xxSoapBindingStub,感觉管理起来比较繁琐,土土的问一下,是否axis也有类似Hessian的访问方式,只需要接口类,其他类全用动态代理自动产生的机制?

呵呵，忘记了，其实我没用axis做过client，都是用的什么XUL啦FLASH啦这些，它们本来就封装了SOAP RPC的。SOAP对对象的支持不好，axis用了一个自己的方案，能不能成为标准还很难说，还是burlap比较实用。