几个常用的概念问题

javabean和一般类的区别：

javabean组件，必须支持jdk1.1版本以上的Serialization模式
还有，它存取property时候必须使用开头为set/get名称的方法。
建立一个javabeans只有这两个限制，并无神奇之处。只要你建立一个类，然后实现java.io.serializable，同时使用get/set方法就可以了。

容器：

类似于IIS，  说白了，Tomcat是一个后台服务进程，其它的servlet（相当于DLL）是在Tomcat容器内运行，    Broswer只与Tomcat通迅; Tomcat接受browser的请求，经过一系列动作（如果是静态网页，那么装载，按http协议形成响应流;如果是动态的如JSP，那就要调用JDK中的servlet.jsp接口，解释形成静态网页，按http协议生成响应流发送回browser）后，形成静态网页，返回响应。其实：Tomcat,IIS...等这些都是应用层上（TCP/IP中的划分）的，应用服务器（或叫http服务器）和ftp服务器同属一层中.

何谓"容器"?

说穿了没什么特别的地方，而且在我们的世界里面司空见惯。容器就是一组提供一系列服务的管理器，只要你符合容器的服务要求(规范)
容器就可以让你使用范围内的管理服务. 早在Web流行的时候，http container就为我们提供解析Html的能力，
让我们的html代码可以通过http协议来发布到internet.随着web应用的推广，动态语言的发展，http容器逐步
可以用指定的接口来解释特殊文件中的特殊片断，如:php,asp等等。那么让我们揭开容器的盖子，看看里面都有什么(服务).

1,生命周期管理
- 既然要管理运行的组件(或程序片断)，至少可以通过某种方法在需要它的时候创建，没用的时候销毁。

2,查询定位
- 通过一定的策略(通常用文件名称)确定需要调用哪个组件或者资源，这可是作为管理器的主要工作。

3,配置器
- 提供静态配置策略。让用户可以控制服务的细节部分。如，资源在哪里等等

4,依赖解析
- 如果组件之间存在关系，或者需要相互通讯。那么至少要保证他们都是"活"的。这就需要分析出之间的依赖关系，动态管理。

5,不同协议层的通讯支持
- 对于程序片断不是自己就可以完成所有的计算的，还需要和不同的系统(平台)进行通讯，如用JDBC和数据存储数据库，用RMI分布组件

6,扩展支持
-扩展服务项不仅是容器需要的，也是任何软体需要的。比如说，增加安全策略。

何谓"轻量级"?
既然是"轻"，那就是比较"重"的而言."重"的典型代表就是EJB,EJB提供了一系列"重量级"企业级服务，并可以让你开发的组件可以很好的
集成EJB容器所提供的企业级服务，如JTA等。那么既然有了"要嘛有嘛"的服务容器，为什么还需要"轻量级"呢?这是一个好问题。
对于全面的EJB容器，虽然给了我们看起来完整的服务策略，但是，EJB不是雷锋，它也给我们带来了许多负面效果。有过EJB经验的人们
深有感触：
1，部署复杂，运行缓慢
2，内在服务多，启动慢
3, 规则特多，空间很小
4，难预测试(调试)
...

EJB容器的服务往往是"买一送三"，不要都不行。我只需要JTA，而真的不需要JMS.
所以，在这个"对我没用的都是垃圾"的世界里，我们就需要"可选择型"的服务容器，让那些对我们没用的服务不要站在这里碍事。
可选择性就是轻量级容器的目标之一。


"轻量级"在哪里?
容器的服务既然可以DIY了，那么确实看上去"轻"了许多。但是，事情并非如此简单。
在开始之前，先来回顾一下几个关键词
1，封装
Java本身在照顾到非java程序员接受程度和配合市场宣传的"running anywhere"，不得不将一些
非面向对象的特性语法加入其中。"是否破坏了封装?"，称为Java十年来争议最多的问题。

2，组件式开发
这个词在软件的圈子里显得技术含量很高，但是，在硬件范围里，哪个硬件不是组件式的呢？你的计算机里就是各式各样的组件，
他们靠各个接口(插槽)集成工作。甚至你正在看得数字电视机顶盒也是一个标准的组件。

3，Running Anywhere
这个词伴随着一杯黑咖啡进入我们的世界，虽然现在已经变成了"Debug Anywhere",但是，这一直是我们的目标。


轻量级容器就是以这几个为目标的解决方案。
面对封装，组件粒度一直是SA的最大问题。根据EJB模型，EJB组件让我们把业务组件封装成粗粒度的业务组件。轻量级容器这可以定义更为细粒度的组件，甚至这个组件只有一个对象.以依赖注入(Dependency Injection,DI)为代表的解耦模式，可以让组件不去依赖容器(运行环境)的API。DI作为容器的管道，承担中间人的角色，让使用者(component)和提供者毫无关联。对于以何种粒度去设计业务组件，这就是业务的具体需求所决定的，任何框架都帮不了你。 而轻量级容器提供技术方面的支持也绝对让你有的放矢。

面对组件，真正的组件就像你手里的U-disk，插到USB上就可以享受其功能。轻量级容器通过反向控制(Inversion of Control,IoC)让容器具有主动权，去管理插进来的组件。只要组件是符合标准的，就可以被
轻量级容器管理。 面对Running Anywhere,轻量级容器让组件以POJO的形式存在，只要你有java.exe就可以运行它。 这样，组件根本就是一个独立的功能集成类，根本不需要容器就可以实现测试行为。

以上三点，给我们带来的好处不仅如此，我们伴随着还将重用，生产力，测试(质量)，移植性等各个方面受益，这里就不多啰嗦了。

轻量级容器的现状

目前，轻量级容器在open source范围已经得到了广泛的认可，而且，作为下一代J2EE构架的基础有着无法比拟的优势。 当前，已存在的轻量级容器框架中，有绝大部分来自open source社群，这给我们对这项技术的了解降低了门槛。