一直想写一些关于JavaEE的东西，从刚开始看《Ejb in Action》的时候就想写，到后来工作中一直在使用JavaEE的技术，开源的流行框架丢的也差不多了。JavaEE企业级的东西把自己搞的也跟傻子似的。回过头来看看避免自己真的成了傻子。
先从“组件”（component）说起，不知道从什么时候开始人们希望软件开发就像孩子搭积木似的可以是组装的。随之而来的一个概念就是“组件”用专业一些的话说就是“组件是一个自包含的、可以重用的软件单元，可以把它集成到应用程序中”更加直白一些说就是一块积木是可以独立完成一项任务的，而且这个块积木是可以被多个地方使用的（想想螺丝螺母、发动机相信能帮助读者理解这个概念）。在Java中组件的最简单形式是JavaBean，我们通常叫bean初学者听到这个词会骂街，猪八戒，猪悟能、猪刚鬣、木母、净坛使者、天蓬元帅一堆名字到头来不就是一头猪么。什么bean，Javabean到头来不都是Java中的类么。骂街归骂街不同的名称在不同的地方是有意义的。天蓬元帅值这头猪在天庭当官时候的称呼，猪八戒是这头猪跟了唐僧之后的称呼，猪刚鬣是猪在高老庄时期的称呼……好像说远了，总之要说的是不同的名称所包含的意义以及要反应的东西是有区别的千万不要一叶障目。
在企业范围内，组件更专注于实现业务服务，同时根据组件可执行的业务操作定义组件的协定。Java EE的标准组件模型是EJB模型，它定义了包装、部署以及与自包含业务服务进行交互的方式。EJB的类型决定了需要与之交互的协定。会话bean（Session bean）使用标准的Java接口来定义可以调用的业务方法集合，而消息驱动bean（message-driven bean）的行为取决于bean旨在接受的消息类型和格式。
在我们平时开发当中时候使用组件模型是可选的，一般来说可用户会话bean的容器服务也可用户servlet。结果导致现在大多数Web应用程序完全避开了EJB，直接从Servlet到数据库。使用组件需要以层的形式组织应用程序，其中业务服务处于组件模型中，且表示服务层位于它之上。
目前之所以很多Web应用程序不选择EJB是由于历史上EJB的复杂性。随着这个问题得到解决人们渐渐的收获定义明确的业务服务集合所带给应用程序的好处。
l 松散耦合（loosecoupling）。使用组件来定义服务鼓励了应用程序的层之间的松散耦合。更改一个组件的实现对客户端或其他依赖与它的组件没有任何影响。
l 依赖性管理（dependency management）。组建的依赖性可以在元数据中声明，并由容器自动解析。
l 声明周期管理（Lifecycle management）。组件的生命周期又应用服务器明确定义和管理。组件实现可以参与声明周期操作来获取和释放资源，或者执行其他的初始化和关闭行为。
l 声明性容器服务（declarative container service）。组件的业务方法是由应用服务器所截获，以应用注入并发性、事务管理、安全性以及远程处理之类的服务。
l 可移植性（portability）。对于遵守JavaEE标准并部署到基于标准的服务器上的组件，额可以更加轻松地把它们从一个兼容服务器移植到另一个服务器。
l 可扩展性和可靠性（scalability and reliability）。应用服务器旨在确保组件可以有效地实现可扩展性管理。根据组件的类型和服务器配置，使用组件实现的业务操作可以重试失败了的方法调用，或者甚至把故障转移到集群上的另一台服务器。