企业应用架构选型
本文将首先考察企业应用的一般概念和需求；然后讨论两种目前最流行的企业级Java应用架构，分析它们满足企业应用的需求的方式，最后清算一下两种选型的代价和使用范围。
企业应用的概念和需求
笼统地说，一个“企业级应用系统”肯定是一个“服务于商业目的，处理企业业务信息，数据的软件系统”。大概可以总结出以下五方面特征:
1．有复杂的业务逻辑
2．有大量持久化数据
3．与多种外部系统相关联
4．有较高的性能要求
5．在运行时需要随时监控，管理；应该能够实时记录，观察系统运行情况，修改系统配置。
当然，开发人员要设计，实现的并不是整个系统的所有部分。开发人员只负责实现与业务相关的核心应用内容，其余的底层结构部分则是在架构选定之后，由相关的系统软件提供(可能是AppServer或者是专门的框架产品)。开发人员关心的是最终完成的“业务构件”，这些“构件”填入“架构”，形成了整个企业系统。
我们之所以把系统中这些有待开发的关键部分称为“构件”，而不是“组件”或“对象”，是因为后面这两种称呼，恰恰与两种具体的架构选型有关。众所周知，如果我们开发的是一个EJB架构的企业应用系统，那么我们的实际工作是在编写EJB组件；另一方面，如果我们使用Spring框架开发应用，那么我们写出的则主要是些POJO。
但无论采用哪种架构，由于前面提到的企业应用的基本特征，我们编写的“构件”都需要从架构系统软件获得一些关键支持或称为“基础服务”。
1． 事务处理：确保关联操作正常，完整的执行。
2． 持久性：实现数据的存储，关系性数据与业务对象之间的映射。
3． 安全性：保证资源只被授权的客户端访问。
4． 构件的生命周期管理和资源管理：负责构件的创建，销毁，构件之间关系的维护，构件的装池(pooling)和重用，并负责构件要用到的Socket，线程，数据库连接等资源的分配，释放和装池。
5． 并发访问管理：处理多个客户端对特定业务构件的并发访问。
6． 寻址服务：当业务构件需要调用其他对象/组件时，架构系统软件应该提供相应的寻址机制，对调用者隐藏被调用者的实现细节。
以上列出的基础服务，对于绝大多数企业应用都是不可或缺的。另外，考虑到企业级应用扩展，集成，升级的可能性，还有一些需求也应该属于这里：
7． 远程机制：如有业务构件和web构件不在同一物理层中，则往往有必要通过某种远程机制（RMI或web service）暴露业务接口。
8． 集群机制：当企业应用的规模扩展，负载增加时，肯定会考虑添加备份服务器以提高处理效率。
9． 管理机制：可以是一个console界面或其他类型的管理接口，供系统管理员实时掌握运行状态，更改系统配置。
10. 日志机制：记录系统运行信息和异常信息。
在理想情况下，业务构件应该能够“透明的”享受以上大多数的基础服务。一个常见的例子是日志机制，系统所采取的日志记录格式，记录媒质，都应该独立于核心的业务逻辑，业务逻辑只是隐式地使用了日志服务。
EJB架构
EJB架构是一种基于组件模型的系统架构，EJB容器提供了对事务处理，持久性，安全性，组件生命周期管理和资源管理，并发访问管理，寻址服务，远程机制以及集群机制的内置支持。换句话说，这是一座一上来就标榜“全功能”的豪华公寓。
事务处理：EJB容器负责实现底层事务服务，并通过JTA提供访问。
持久性：通常由Entity Bean实现。有BMP(通常DAO模式封装)和CMP两种。
安全性：EJB容器提供了声明式安全性机制，可以通过配置实现基于role的访问限制。
组件的生命周期和资源管理：AppServer负责这些核心机制(pooling/callback)。
寻址服务：JNDI。
远程机制：RMI/IIOP(EJB2.0技术规范)。SOAP(web service形式EJB2.1技术规范)。
集群机制：EJB架构同时支持纵向扩展和横向扩展。
通过以上介绍我们发现，EJB架构提供了企业级应用的所有基础服务(EJB开发范式诞生的初衷)，但其中一些服务的实现存在缺陷，在应对特定业务场景的时候往往捉襟见肘；另一方面，所有这些服务都必须一篮子提供，即使只使用到了其中的少数几个服务，我们也必须付出运行所有服务的代价。
另外，EJB采取的组件模型具有很强的“侵略性”，为了享用上述服务，业务构件必须具有EJB的接口声明。
轻量级容器架构
很长一段时间以来，EJB架构一直被认为是完整的J2EE方案中不可或缺的核心成分。但随着AOP，Ioc等技术的逐渐发展成熟，一些开发者干脆放弃了EJB容器，转而采取了一种全新的J2EE方案。
在EJB容器之外提供各种企业级基础服务——轻量级容器架构不仅做到了这一点，而且让开发者感到了可贵的自由。针对EJB架构的两大弊病a.一揽子提供所有服务 b.组件接口的强侵略性，轻量级容器架构做出了彻底的变革：a.实现透明的“照单点菜”服务提供，使用者可以按需配置当前运行的服务；b.放弃组件开发范式，采用POJO，基本上消除了EJB架构强加给业务构件的侵略性接口。
以下考察轻量级容器框架怎样通过AOP，Ioc技术实现各项企业级服务的。
事务处理：
底层服务由专门的事务处理框架完成，业务对象可以采用编程方式实现事务(如事务模版)；但更好的方案是通过声明实现(xml配置或者在源代码中给出meta data注释)。Spring框架在底层通过interception，为POJO业务对象添加事务功能。
持久性
Spring框架通过DAO模式实现对象持久性，并针对各种常见数据访问机制(如JDBC，JDO，Hibernate，iBatis，SQL Map)设计了专门的处理模版。
安全性
可以通过AOP拦截，实现基于声明的安全机制，这通常比EJB安全机制更符合复杂的业务需求。
对象的生命周期管理和资源管理
生命周期管理由容器实现。对象无需具有特定接口，回调方法在配置声明，以供容器到时自动完成回调。资源寻址由容器完成，资源管理由容器调用底层服务实现。
并发访问管理
容器负责自动处理并发请求；开发者可以把业务对象视为单线程模型。
寻址服务
借助IoC架构，寻址服务由容器透明地实现，无需进行显示代码，只需在配置文件中声明对象之间的依赖关系即可。
远程机制
Spring内置了对RMI, web services(JAX-RPC)的支持，另外还支持两种轻量级的远程机制：Hessian(一种二进制协议)/Burlap(一种XML协议)。
集群机制
通常采用横向集群方案，也就是添加整个应用系统的备份。
评价：与EJB容器相比，轻量级容器在事务处理，持久性，寻址以及构件生命周期管理/
资源管理机制方面具有较大优势。在安全性，并发访问，远程机制方面与EJB容器相差无几，也许在集群机制（本文没有详述消息处理机制，因为缺乏MDB的代替方案）方面与EJB容器有明显差距。
选择与代价
我们首先从系统开发的角度，通过三个方面考虑两种架构的差异。
1． 组件编程 vs. 对象编程
首先，组件的粒度大于对象，一个组件可以由多个对象构成。其次，组件不能脱离相关框架独立存在，组件的生命周期完全由框架管理，并且在接口和实现中都显示地依赖于框架中基础设施，而在理想情况下，对象则可以单独使用。最后，组件往往要求接口和实现之间的分离，用户在使用组件时，只要知道接口定义即可；而一个对象则不一定具有这样严格定义的接口特征。
EJB开发体现了组件编程范式的典型特征，EJB不能须臾离开容器存在。用EJB实现的业务组件无法摆脱对专门的接口和异常的依赖——这正暴露了EJB的“侵略性”。
基于轻量级容器的开发则是传统Component编程和POJO编程的一种混合体。由于它广范采用了IoC地注入，回调机制，所以业务对象代码中几乎不存在对容器和相关服务的依赖；业务对象不需要容器特有的接口声明，所以这些对象完全可以独立于容器使用，测试。另一方面，业务对象一旦进入容器，也仍然区别于传统，单纯的Java对象，它在整个生命周期中受到容器的全程管理，事实上，用户对它的调用也会经过容器多次拦截/代理。最后，即使是在轻量级容器架构中，通常也会鼓励接口与实现之间的分离。
总上所叙，轻量级容器架构的自由隐含着巨大的收益。另外从面向对象原则，测试调试，开发效率等等角度来说，对于大多数企业应用系统，轻量级架构都优于EJB架构。
2． 正交性
EJB架构和轻量级容器架构，从“正交性”视角出发，它们的部分初衷都是区分，隔离与业务逻辑“正交”的各项系统功能，并改由容器提供相关服务，而不是手动编码实现。
如前文所述，EJB架构已经抽象出了各种关键的企业服务，并且提供了声明性的配置策略；而且在EJB容器本身的底层实现中，我们也已经能看到对interception的大量应用。
但只有在明确地引入了AOP技术的轻量级架构中，我们才能看到更为彻底的功能正交划分；interception能让开发者能够以更灵活，更符合业务需求的形式定制基础服务。
但应当注意的是，AOP也并非解决正交问题的万应药：“基础服务”的很多细节，不可避免的要与“业务逻辑”混杂在一起——事实上，在很多时候它们就是“业务逻辑”的一部分。在一些特别繁复的应用场景中，与其为正交而正交，勉强隔离各项功能，不如考虑怎样让它们体面地共存。
因此，从正交性角度考虑，对于业务需求极为简单或极为复杂的场景，采用EJB架构也许还有优势，对于较复杂的场景，轻量级架构则可能更为适用。
3．“设计”vs.“补丁”
轻量级容器架构易于配置，易于即插即用地添加新功能，与EJB架构相比，这显然隐含着一种更灵活，更能随机应变的开发范式。
通过AOP增强业务对象，加入原先的设计中不包含的功能，这固然能够一时应付全新的需求，但是采用了这种范式，开发者确实倾向于“懒得”从一开头就把事情想清楚，倾向于怀疑理性预测未来的能力。如果啊AOP的兴起只是助长了这种编码风格，那么我们面临的就不仅是两种容器架构的分歧，而且还是“设计”与“补丁”这样两种精神取向的区别。
从这个角度考虑，也许应该首先预估系统业务需求变更地可能性，当需求相对固定时，EJB架构不乏可取之处；如果需求变化频繁，那么也许应该考虑轻量级架构——但即使如此也应牢记，AOP的本意并不是“打补丁”。
