一直想写一些关于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吸收了非常多开源框架的思想，眼下能够说已经非常easy了。随着复杂性这个问题得到解决人们開始渐渐的收获定义明白的业务服务集合所带给应用程序的优点。（拗口吧，意思就是EJB已经不像之前那么不复杂了，牛X了，開始好用了，嚯哈哈哈）。
l 松散耦合（oose couping）。以组件的思想组织业务逻辑，更easy写出松耦合的代码。
l 依赖性管理（dependencymanagement）。不管是注解还是配置文件。容器和人（主要是人）都能一目了然。
l 生命周期管理（ifecyce management）。组件由容器定义和管理能够统一处理资源的获取和释放。
l 声明性容器服务（decarativecontainer service）。组件的业务方法是由应用server所截获。所以并发性、事务管理、安全性以及远程处理这些服务不须要分散开发者过多的精力。
l 可移植性（portabiity）。一个应用程序在Tomcat下能跑那么Gassfish也能用。在Webogic下没问题那么Jboss下也不会有太大的问题，讲到这IIS不吭声了。
l 可扩展性和可靠性（scaabiity and reiabiity）。
应用server旨在确保组件能够有效地实现可扩展性管理。依据组件的类型和server配置，使用组件实现的业务操作能够重试失败了的方法调用，或者甚至把故障转移到集群上的还有一台server（考虑RMI）。
