轻量级服务器端组件体系实现
【摘 要】 用组件构成新的系统，将体系结构和设计分解成组件，两者都是现在企业应用系统开发的最有希望也是最具挑战性的工作。N层体系结构已经成为很多这种应用的最佳实践，针对具体应用的复杂度通常集中在应用服务器层。这导致了服务器端组件体系结构的成熟。
然而本文并不局限于讨论了服务器组件体系，现有的组件体系如EJB、CCM和COM+已经很成熟。一个优秀的组件体系无疑也是一个优秀的OOD系统，通过实现一个定制的容器去把握和了解容器内部结构，不仅对于开发组件部署新的应用，同时对于学习面向对象设计都有巨大的促进作用。
【关键词】 组件体系 AOP IoC
A approach of Light-Height Sever-side Component System
【Abstract】Building a new system with component, resolve system structure into component to design, the two now enterprise application system development is most challenging work. N layers of system structure become a lot of the best practice of application already , That using the app server layer to concentrate to the concrete complexity is usually now. This has caused maturity of the server-side component system.
But this text doesn't discuss the server-side component system only, the existing component system such as EJB, CCM and COM + are already very much ripe system. One outstanding component system is also undoubtedly one outstanding OOD system, through realize one customized container it hold and find out about container structure to go, not merely for developing components to deploy a new application, but also having enormous facilitation to studying Object-Oriented design at the same time.
【Keyword】 Component AOP IoC
目 录
一、 引言. 5
二、 系统架构. 5
2.1 面向对象与框架. 5
2.2 系统架构的发展. 5
2.3 支持层——服务器端组件体系设计. 7
2.3.0 服务器端组件体系设计的考虑. 7
2.3.1 IoC容器. 8
2.3.2 AOP容器. 14
三、 软件工程实践. 19
四、 总结. 20
五、 致谢语. 20
参 考 文 献. 21
一、 引言
组件——当前一个很重要也很“热门”的软件工程主题。书架上此类书籍比比皆是。在主流企业开发应用上，大量应用了此类技术，我们已经很习惯的在WebSphere或者WebLogic上开发新的企业应用。然而即时如此，在CCM、COM+和EJB组件平台的传统领域，定制容器的趋势也已出现。
无论是传统领域还是定制趋势，容器的技术体系作为一个优秀的OOD系统无疑带有相当的“神秘”色彩。为什么容器被设计成这个样子，它如何工作。学习其内部结构和工作方式无疑对开发组件以及对于学习面向对象技术都有巨大的帮助。
二、 系统架构
在正式论述主题之前，我不得不先介绍一下一些基本概念，它们虽然没有显式的体现在主题论文中，然而它们确实贯穿了主题的全部。
2.1 面向对象与框架
总体而言，系统的开发方式有三种，如下：
1. 结构化设计（自顶向下）——没有提供适当的方法解决并发性问题。
2. 数据驱动设计——广泛应用于信息管理系统，它关注系统的输入输出。
3. 面向对象设计——适应复杂开发并具有良好复用性。
面向对象作为当前程序设计的主流技术，其本质：抽象、封装、多态、继承。第一要着是抽象，而抽象具有是不确定的，具有不同的粗粒度（根据不同的粗粒度可以排列成为一种层次）。在此之上面向对象设计，则是一种工程学方法，在Robert Martin于1995年出版的那本著名的Designing Object-Oriented C++ Application,在回答“什么是面向对象设计”时，Uncle Bob这样写道：面向对象设计的目的是管理程序中各部分之间的依赖关系。最终开发目标就是降低耦合度，实现复用。
软件复用的发展方式——框架：程序主体反主为客，并让辅助组件反客为主，即控制反转。如果一个程序库负担了整个应用程序运行的主干算法，并实现了主动的事件循环、事件处理机制、控制流程，则为框架。
2.2 系统架构的发展
无论是何种开发方式，在技术层面上，建立一个系统从宏观层面来看第一要著是使系统结构化，结构化的途径有三个：分层、管道和过虑、黑板。
1. 分层模式是一种解决大系统的良好的方法。本质上讲分层是抽象的排列。因为大系统复杂性较高，它的抽象层面也相应较多。
2. 管道和过虑通过用来解决数据流的较好方式。
3. 黑板则是用来解决不确定性问题的首要途径。当一个问题解决方法缺乏一定模式，而现有的方法集中的每个方法都只能解决问题的一个部分，并各自不相交。黑板可以成为较好的抽象机制。
如上所述，现有企业应用解决方案都是采用分层模式，无论是J2EE还是.Net都应用这种技术。整个系统框架一般的可以分为5层：表示层，用来显示数据，而不做任何的逻辑操作；控制层，负责控制页面间的跳转；逻辑层，逻辑控制；数据层，负责数据访问、更新；支持层，服务器端组件体系。大体的分层如下图：
各个层次间关联如下：
正如我们看到的，在分层系统任一层次，都面临的两种问题——业务领域问题和系统功能（如事务管理、协调、安全性和命名服务等），很明显这是两种不同的问题。基于“问题分离原理”——即把“技术问题和业务问题分离”，而其内在本质是抽象，把一个系统抽象为技术和业务，以达到技术的复用。开发人员并不想“不重新发明轮子”。随着开发中复用的演进，系统功能的实现渐渐发展成容器，而业务领域问题的实习则成为组件。
2.3 支持层——服务器端组件体系设计
2.3.0 服务器端组件体系设计的考虑
应用“问题分离”原则的主要理由是为了允许系统演化并促进重用。
组件体系作为一个OOP系统——基于抽象和封装技术，作为业务组件的必然会相互依赖。这里就有两个重要的概念：耦合和内聚。依据DIP原则：抽象不应该依赖于细节，细节应该依赖于抽象。同时顶层也不依赖于底层的实现，顶层抽象的运行机制不依赖底层的实现细节。组件应该是高内聚的，而与其他组件是松散耦合的。组件之间只能通过组件接口交互访问。
同时系统应该保持内核独立于用户接口。因此组件本身不再与其他组件建立直接的依赖关系，依赖关系将在组件之外的地方建立。组件内部关联将被接口隔离。
事实上，团队开发以及迭代的开发模式也不允许开发人员在组件内部建立依赖关系。例如：在开发业务逻辑时，开发人员将不会依赖与数据访问层的工作，必须有一个手段来提供假数据——实际上业务层并不关心数据的来源，它惟一关系的对数据的业务操作的正确性，然而当确实需要从数据库时，开发团队应该可以无缝的替换假数据。
注意到如下事实：组件是被动的实体，它等待客户端（可能是真正的远程客户或者其他组件）的调用，执行被调用的操作，然后再次转向被动模式。这对容器实现方法有重要的影响：容器可以安全的假设如果没有对特定实例的方法调用，实例将永远不会执行任何代码——这样在下次调用到来前从内存中删除实例。这里我们用到了虚实例（Virtual Proxy）模式和生命周期回调（Lifecycle Callback），我们在后面将详细讲述。
对于系统，OOP已经表明了它处理一般行为的能力，但是，OOP不能很好的处理横越多个——经常是不相关的——模块的行为，相比之下，AOP填补了这个空白。正如本文开需求一章中所表明的，系统需求分类为功能性（核心模块级）需求和技术（系统级）需求。很多系统级需求一般来说是相互独立的，但它们一般都会横切许多核心模块。对于任何应用都包含许多横切关注点，如验证，日志，资源池，系统管理，性能、事务处理及存储管理等，每一个关注点都牵涉到几个子系统。如存储管理关注点会影响到所有的有状态业务对象，而事务管理关注事务处理，它是一个系统级的需求，我们并不希望每个业务实体在需要的事务处理里都每次自己处理，因为“重复代码是错误之源”。
因此，支持层采用了IoC容器和AOP两种当前主流技术。而其底层技术是反射和代理技术，这也是当前主流框架采用的基本技术。
2.3.1 IoC容器
1. IoC就是Inversion of Control——控制反转
在开发中，IoC意味着将你设计好的类交给系统去控制，而不是在你的类内部控制。这称为控制反转。
Ioc模式（Dependency Injection模式）有三种：
第一种类型
从JNDI或ServiceManager等获得被调用者，这里类似ServiceLocator模式。
1. EJB/J2EE
2. Avalon
第二种类型
使用JavaBeans的setter方法
1. Spring Framework
2. WebWork/XWork
第三种类型
在构造方法中实现依赖
1. PicoContainer,
2. HiveMind
使用Ioc模式，可以不管将来具体实现，完全在一个抽象层次进行描述和技术架构，因此，Ioc模式可以为容器、框架之类的软件实现提供了具体的实现手段，属于架构技术中一种重要的模式应用。
2. IoC组件容器实现：
市场上已经提供很多优秀的容器。如EJB， COM+， CCM等，但由于大部分是“重量级”，在开发中代来大量的资源消耗和不便——因为它们是以资源换性能。为了开发的便利，本系统实现了一个简单的容器。本系统容器不是取代这些容器，相反，目标是使系统本身易于移植。
2.1 IoC容器的工作方式：
容器作为框架的基础技术，又被称作元框架。容器规定了组件必须遵循的规范（即组件的元数据），复杂以适当的技术创建、组装、管理组件的生命周期（可能是Singleton、缓存或者Pooling的方式），并将其交给使用者。
基本的技术可以为两个部分，如下：
A. 载入组件配置信息 ：
载入XML配置文件并映射到组件信息对象。
B. 管理组件的行为和生命周期 ：
实际上，容器要做的工作很多。容器在一个地址空间里运行好几个组件的实例，它处理了许多技术需求。为了确定这一切可以正常运作，容器要能对组件的行为作出假设。
容器载入组件并根据组件信息对象的提供的信息组装组件，并可能在销毁前反初始化。这个就是众所周知的生命周期管理。而且容器使用里高级的资源管理技术，如池调度和钝化技术。
典型的，在EJB的体系中回调接口如下 ：
public void ejbCreate();
组件初始化工作。
public void ejbRemove();
组件反初始化工作。
public void ejbActivate();
组件从池化状态激活。
public void ejbPassivate();
组件钝化工作。
客户、组件和容器的协作关系如下图：
客户感觉每个实例始终是活跃的，然而在某个时刻内存中的真正实例总数可能大大低于逻辑活跃实例的数量。因而容器的工作负荷将大大减少。容器通常使用实例池调度和钝化来实现虚实例。这个结构对于组件开发者来说是不可见的。
总体而言，容器综合采用了cache、pool和virtual proxy三种关键技术来提高容器的工作性能。
C. 为组件提供上下文环境：
虽然我们一直强调松散耦合关系，然而组件还是不可避免的和其他组件或者资源（如数据库连接池）发生相互关系。由于组件本身不知道这些资源的位置，因而容器必须向组件提供一个上下文环境，使组件可以通过一个统一的入口访问到这些资源而无需关系这些资源的位置。
一个完整的容器架构看起来如下：
另：
我的blog： http://www.cnblogs.com/yimlin
写的不多，请多指教。
本文地址：http://com.8s8s.com/it/it16387.htm