优点和缺点是从《without EJB》第一章概括出来的，希望我没有曲解作者的意思：
优点：
1.仍是最好的的业务对象分布式架构。无状态session bean还是不错的。
2.消息Bean也不错。尤其是对金融系统来说
缺点：EJB乃至整个J2EE规范的缺点，可以用一句话来概括：花了80%的时间去处理那些20%的问题，得不偿失。典型的例子就是开发人员凭空想出一些不切实际的需求来捆住自己：
1.系统除了支持web客户端，还要支持swing
2.系统所用的数据库产品和应用服务器可能会改变
3.系统可能使用两个数据库
4.系统可能不用关系数据库作持久化，有可能用XML作数据源
我个人对Rod Johnson的以下看法持保留意见：
1.他说，在远程调用方面，web services是比EJB更好的选择。按我的经验，web services的配置复杂性非常吓人。
2.他还说，分布式对象方案 破还了OO原则，因为出于性能考虑，需要为远程方法定义比本地接口要粗糙的远程接口。这破坏了透明性。但我觉得，这种透明性本来就没要去追求。
a.进行分布式交互的两个对象，未必就应该是业务对象，完全可以是一些控制指令。这些控制信息专用于远程交互，不会和本地业务对象实现同一个接口
b.分布式对象之间交互时，本来就不会涉及多大的数据量，否则就会用文件来传递数据了
c.再考虑不使用分布式对象的机会成本。不用这种东西，就要用socket、web service或者其他中间件。后果是：
I.配置文件多了
II.与配置文件的配套的设计文档、安装文档也多了
III.最头疼的是，要专门一个协议。比如定义一个报文，这个报文的这个字段代表什么，字段是什么类型，长度有多少等等。
A.这个工作量不小
B.以后如果增加了新的交互功能，要尽力保证新的报文会使所有报文集在解析时不会出现二义性（如维持上下文无关文法），比起可随意取名的、可随意重载、可随意覆盖的 对象方法 要麻烦多了