分布式对象的使用仅仅在少数应用中才是适合的。因此，快速增加的领域是在异构平台之间的互操作性，而不是j2ee应用服务器之间的远程调用。
随着更多远程协议的发展，ejb容器不可能支持所有的协议，而ejb又没有提供可插入的远程机制。
部署，如果正在编写的是一个web应用，我们可以按照war部署方式来打包我们的对象，同时打包它们所依赖的东西。在任何java应用中，我们总可以使用标准的jar部署单元，这允许我们在manifest文件的classpath中表达对其他jar的依赖关系。
AOP
AOp的一个子集主要涉及拦截（interception），它为我们提供了“在任何对象的方法调用前/后加入自定义行为”的能力，这使得我们可以处理企业应用中的横切（crosscutting）关注点（即：同时作用于多个对象的关注点），并且仍然保持强类型。例如：我们可以在一个应该具有事务的方法调用前开始一个事务，在方法返回时提交或者回滚。使用AOP让我们可以把“与事务管理相关的重复劳动”放进一个框架内。另外一个很适合AOP的场合则是自定义安全检查。
如果我们必须为多个对象和方法应用相同的事务行为，我们需要将各样的代码剪切/粘贴到每一个方法里。AOP让我们可以对这类问题封装到方面（aspect）中，从而更好的实现模块化。AOP定义了点切（pointcut）的概念，让开发者可以从另一个角度来思考程序的结构，从而弥补了oop的某些缺陷：如果需要对一组方法施加横切的行为，就应该拦截这些方法。
EJB容器则使用拦截来提供安全检查、线程管理、声明性事务管理等服务，这与AOP拦截是相同的概念。
AOP的好几种实现方式都可以确保应用服务器之间的可移植性。例如，只要坚持了“针对接口编程，而非针对类编程”的原则，这无论如何是一个最佳实践，我们就可以使用j2se的动态代理来实现AOP。我们还可以使用CGLIB一类的东西来实现动态代码的生成。
Entity bean就是一种糟糕的技术，将它包含在ejb规范中对真正O/R映射造成了很多危害。持久化操作不应该被绑定在ejb容器上，而是应该由专门的解决方案来提供。
spring框架提供的给予aop的声明式事务管理可以通过配置，在支持多个数据库的JTA、或者JDBC、或者其他的特定于资源的事务管理API，而不需要对业务代码做任何修改。
spring也为编程性事务管理提供了很好的解决方案，这是一种合理的做法。在两种极端的情况下，你都会需要编程性的事务管理：如果事务需求极少，则不值得花力气设置声明性事务管理；如果事务需求非常复杂，声明性事务管理也并不合适。如果一个对象中只有一个方法需要复杂的事务行为，也在同一个对象中混合使用编程性事务管理和声明性事务管理。
数据库本身必须支持最大限度的集群伸缩性，否则它很有可能成为系统的性能瓶颈。
线程管理
实现不读、写实例变量的多线程服务对象。这种方法在servlet、struts action之类的对象中工作的非常完美。大多数无状态服务不需要复杂的线程管理。单例在很多场合是有好处的。
使用command模式。在每个请求时为每个服务对象创建一个新的实例，，在对象内部消除并发的问题。
使用一个多线程服务对象，在其中使用普通java语言的同步或并发库以便保护任何读写状态。不能组织集群中的另一台服务器上的同一段代码并发执行。
资源池：在j2ee的缓冲池中，真正有价值的是资源池，而不是业务对象的实例池。例如，讲数据库放入缓冲池中，以避免加载时耗尽连接，只是企业应用的基本策略。
更好的办法是使用AOP来实现声明性自定义安全性：一般的做法是将安全凭证保存在一个ThreadLocal对象（而不是j2ee安全上下文）中，再用一个自定义的安全拦截器包裹在需要安全性管理的业务方法周围。
对于安全需求比较简单的web应用，通常在web层检查用户身份就足够了，例如借助servlet api的声明性（基于web.xml）或者编程性基于角色的安全性。在web层实现声明性安全管理的方法还有：向需要保护的内容周围添加Servlet filter；借助WebWrok2和Spring 之类web框架中的拦截器；或者在web控制器中使用aop拦截器。
spring提供的通用工厂也根据配置来按名字来获得对象实例。
spring提供了控制反转，由轻量级容器负责解决合作的对象上的依赖。
jboss4：一个j2ee应用服务器，通过aop向pojo提供企业服务，不需要使用ejb。
轻量级容器一个重要的出发点就是消除j2ee应用中自制的工厂和Singleton。
借助反射和依赖注入，被bean工厂管理的组件根本就不需要知道Spring的存在。
1057
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
