组件是能够完成某种功能并且向外提供若干个使用这种功能的接口的可重用代码集。表现形式为常见的(库/包),组件将一些类和接口组织起来,对外暴露一个或 多个接口,供外界调用。如开发JDBC时所使用的JAR包,其中就包含了,JDBC的API,我们开发JDBC实际上就是使用这些JAR包里的API,也 就是说,使用了JDBC组件提供的功能,这些功能,能过接口声明体现。
组件是抽象的概念而已,通俗的说是一些符合某种规范的类组合在一起就构成了组件。他可以提供某些特定的功能。
所谓容器就是指符合一定的规范能提供一系列服务的管理器,方便别人使用它来完成一系列的功能
例如tomcat,使用tomcat可以为我们提供servlet.jsp等服务,我们俗称叫servlet服务器,在服务器中会有相关的容器,servlet容器可以调用servlet和jsp动态的为我们生成html。
何谓"容器"?
说穿了没什么特别的地方,而且在我们的世界里面司空见惯。容器就是一组提供一系列服务的管理器,只要你符合容器的服务要求(规范)
容器就可以让你使用范围内的管理服务. 早在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社群,这给我们对这项技术的了解降低了门槛。
PicoContainer
http://www.picocontainer.org/
Avalon Apache Software License
HomePage http://avalon.apache.org/
NanoContainer
http://www.nanocontainer.org/
Peapod
http://www.peapod.org/
Carbon
http://carbon.sourceforge.net/
Excalibur
http://excalibur.apache.org/index.html
Gravity
http://gravity.dev.java.net
以上Pico作为type3(IoC)的创导者和spring IoC容器已经成这里面的佼佼者。IoC容器,给传统的container(as EJB)带来了深远的冲击。
面对技术给我们带来的思想革新,我们必须时刻准备让我们的学习曲线保持在一个定点的高度,才可以处于不败之地。