JavaEE应用程序

一直想写一些关于JavaEE的东西，从刚开始看《Ejb in Action》的时候就想写，总是感觉自己知道的太少了、太不值得一提了、太欠缺了（我太谦虚了）……哈哈哈，到后来工作中一直在使用JavaEE的相关技术，开源的那些流行框架（SSH以及以Spring为核心的Spring家族的东西）丢的也差不多了。工作的时候JavaEE企业级的东西把自己搞的也跟傻子似的，回过头来看看总结一下避免自己真的成了傻子。

先从“组件”（component）说起，不知道从什么时候开始人们希望软件开发就像孩子搭积木似的可以是组装的。随之而来的一个概念就是“组件”，用专业一些的话说就是“组件是一个自包含的、可以重用的软件单元，可以把它集成到应用程序中”。更加直白一些说就是一块积木是可以独立完成一项任务的，而且这个块积木是可以被多个地方使用的（想想螺丝、螺母大一些的话想想发动机、变速器相信能帮助读者理解“组件”这个概念）。在Java中组件的最简单形式是JavaBean，我们通常叫bean。

说到这初学者听到这个词会骂街，猪八戒，猪悟能、猪刚鬣、木母、净坛使者、天蓬元帅一堆名字到头来不就是一头猪么！什么bean，Javabean到头来不就是Java中的类么。骂街归骂街，不同的名称在不同的地方是有意义的。天蓬元帅指这头猪在天庭当官时候的称呼，猪八戒是这头猪跟了唐僧之后的称呼，猪刚鬣是猪在高老庄时期的称呼……好像说远了，总之要说的是不同的名称所包含的意义以及要反应的东西是有区别的千万不要一叶障目。现在JavaBean的这个名字你理解了吧？

在企业范围内，组件更专注于实现业务服务，同时根据组件可执行的业务操作定义组件的协定。Java EE的标准组件模型是EJB模型，它定义了包装、部署以及与自包含业务服务进行交互的方式。EJB的类型决定了需要与之交互的协定。会话bean（Session bean）使用标准的Java接口来定义可以调用的业务方法集合，而消息驱动bean（message-driven bean）的行为取决于bean旨在接受的消息类型和格式。

上面的这段话是非常官方的，总结成接地气的话就是在JavaEE领域不同类型的组件有着其自身的规范，这些组件可以按照其自身的规范来完成业务服务。啊，好抽象……

在我们平时开发当中时候使用组件模型是可选的，一般来说可以用会话bean的容器服务也可用servet。结果导致现在大多数Web应用程序完全避开了EJB，直接从Servet到数据库。这也导致了以Spring为核心的Spring家族以及类Spring家族的开源框架的蓬勃发展。在使用组件的时候我们需要以层的形式组织应用程序，其中业务服务处于组件模型中，且表示服务层位于它之上（你可能在想MVC了，就笔者现在的理解EJB与MVC的关系不是包含也不是并列的关系，他们是……以后再说）。

目前之所以很多Web应用程序不选择EJB是由于历史上EJB的复杂性。相对于EJB2来说EJB3吸收了很多开源框架的思想，目前可以说已经很简单了。随着复杂性这个问题得到解决人们开始渐渐的收获定义明确的业务服务集合所带给应用程序的好处。（拗口吧，意思就是EJB已经不像之前那么不复杂了，牛X了，开始好用了，嚯哈哈哈）。

l  松散耦合（oose couping）。以组件的思想组织业务逻辑，更容易写出松耦合的代码。

l  依赖性管理（dependencymanagement）。无论是注解还是配置文件，容器和人（主要是人）都能一目了然。

l  生命周期管理（ifecyce management）。组件由容器定义和管理可以统一处理资源的获取和释放。

l  声明性容器服务（decarativecontainer service）。组件的业务方法是由应用服务器所截获，所以并发性、事务管理、安全性以及远程处理这些服务不需要分散开发人员过多的精力。

l  可移植性（portabiity）。一个应用程序在Tomcat下能跑那么Gassfish也能用，在Webogic下没问题那么Jboss下也不会有太大的问题，说到这IIS不吭声了。

l  可扩展性和可靠性（scaabiity and reiabiity）。应用服务器旨在确保组件可以有效地实现可扩展性管理。根据组件的类型和服务器配置，使用组件实现的业务操作可以重试失败了的方法调用，或者甚至把故障转移到集群上的另一台服务器（考虑RMI）。