JBOSS.5.AS 原理篇（jboss aop）

JBoss 5 原理

目录

41microcontainer 概论及与其它的几个框架的比较

1.1JBOSS MicroContainer结构分析4

1.2(OSGi.docx)5

1.3Jboss microcontain和PicoContainer6

2microcontainer 及原来的JBoss4 用到的jmx container的比较7

2.1JMX微内核结构7

2.2对象部署7

2.3生命周期控制8

2.4结构图8

2.5ProfileServiceBookstrap9

2.6JMXKernel9

2.7对象部署9

2.7.1部署的改进9

2.7.2部署初始化9

2.7.3MainDeploy10

2.7.4HDScanner10

2.8生命周期控制10

3microcontainer 中的几大原理的解释的理解12

3.1模块化思想12

3.2Classloader12

3.3Vfs12

3.4Injection and ioc12

4microcontainer用到的几个大的技术与服务13

5下个阶段的研究重点15

6其它16

1 microcontainer 概论及与其它的几个框架的比较

1.1 JBOSS MicroContainer结构分析

1)Kernel初始化完成后，注册表中八个核心对象：

KernelConfig：配置对象(配置Kernel自身)

KernelInitializer：初始化器对象，用户初始化

Kernel KernelRegistry：注册表对象，用户存储注册

Bean KernelEventManager:事件管理器对象

KernelBus:总线对象,提供对bean的间接调用

KernelConfigurator:配置器对象,用户配置

Bean KernelController:控制器对象,用户控制Bean的状态

MicroContainer Bean State

JBOSS MicroContainer中Bean的八种状态

NOT_INSTALLED - Metadata describing the bean has been parsed from annotations or a deployment descriptor.注释以及部署描述符中的元素都已经被分析

PRE_INSTALL - the scope of the bean within the microcontainer has been discovered and classloading dependencies have been resolved.微容器已经确定bean的范围并且指定了ClassLoader

DESCRIBED - Any AOP dependencies have been added完成对bean AOP依赖的添加

INSTANTIATED -All dependencies have been resolved to construct the bean. These include; a classloader exists, the class can be found, a constructor or factory method can be found and any parameter injections can be resolved.构造该bean的所有依赖已经确定，包括ClassLoader、class文件、构造方法或者工厂方法、需要注入的全部参数 即实例化该bean

CONFIGURED - All the property injections can be resolved. This includes any injections within collections.完成对实例化的bean所有属性的注入，包括任何集合中的注入

CREATE - All the beans metioned in the @Depends annotation or <depends> element have reached the CREATE state including any parameter injections in the create method.依赖(@Depends annotation或<depends>)全部到达CREATE状态，包括create方法中注入的任何参数

START - All the beans metioned in the @Depends annotation or <depends> element have reached the START state including any parameter injections in the start method.同上(全部依赖到达START状态)

INSTALLED - Any deployment actions have been processed and the bean has been added to the list of items that the controller supplies.全部的部署行为都被处理完成，bean已经被添加到controller的提供项列表中

1.2 (OSGi.docx)

OSGi是什么，OSGi是一种服务运行平台。通过实现能够提供服务的符合OSGi规范的组件，用户可以将其组件发布到OSGi运行平台，供用户和其他组件使用。OSGi组件提供的服务具有两个层面的含义：系统层面，即一个组件为其他组件提供服务，这些服务体现为Java接口的实现；业务层面，即一个组件为外部系统或用户提供某种业务服务实现。

OSGi提供的功能

OSGi能够提供什么功能呢？我们将OSGi运行平台与常用的Web应用服务服务器做一个比较，来看OSGi提供的功能。首先，以tomcat为例，在tomcat容器中可以运行多个Web应用，假设存在两个Web应用A和Web应用B，一般说来，Web应用A和B具有各自的运行空间，两者之间不存在任何关联，A和B具有自己独立的生命周期，如部署、启动、停止和卸载等。

那么，是如何做到这一点的呢？很明显，这是通过JVM的类加载机制决定的。当tomcat运行并启动Web应用A和B时，tomcat为Web应用A和B各自构建了一个类空间，也可以看作是一个类域（Class Domain），Web应用A的类域包括JRE中的类，tomcat启动类路径上的类和Web应用A中WEB-INF目录下classes目录下的类和lib中的jar包；同样，Web应用B也有自己独立的类域，其范围除了JRE中的类，tomcat启动类路径上的类之外就是自己内部WEB-INF目录下classes目录下的类和lib中的jar包。现在提出一个问题，如果Web应用A需要使用Web应用B提供的Java类，怎么办？实现方式有多种，一种是将B提供的类打包，放置到应用A的WEB-INF/classes或WEB-INF/lib中；也可以将B提供的类放置到tomcat的类路径上，甚至是JRE的扩展目录下，但这样做在实际使用中或多或少存在一些问题。能不能在运行时Web应用A可以直接使用Web应用B提供的类呢？在运行时Web应用B能不能提供一个接口的实现，即类实例，由Web应用A使用呢？能不能提供一个应用C为应用A和应用B提供服务呢？显然，这些对于Web容器是不行的。

带着上述问题我们回到OSGi运行平台。可以将OSGi看作是Web容器的泛化，是更高级别的抽象。运行在OSGi环境中的类似于Web容器中的Web应用的组件即Bundle，不再仅仅局限于一个业务应用的概念，它的粒度更加精细，即可以看作是一个Jar包，为其他Bundle提供帮助类；也可以是一个HTTP服务组件，为其他Bundle提供http服务；还可以是一个Web容器，为其他Bundle提供Web应用服务。

OSGi中的重要元素就是Bundle

和Service，Bundle提供了一种静态资源边界，类似于Web容器中的Web应用的概念。

每一个Bundle通过一个元数据文件（MANIFEST.MF）描述。OSGi框架（即SystemBundle）通过解析这个元数据文件对该Bundle进行加载和管理。Bundle通过元数据中的"Export-Package"属性将内部的类包发布给OSGi系统中其他Bundle使用，通过"Import-Package"，"Requie-Bundle"属性引用OSGi系统中其他Bundle发布的类包。

每一个Bundle有自己独立的类加载器（Fragment Bundle例外，其资源通过其Host Bundle加载），Bundle内部的资源（类，文件等）通过该类加载器查找和加载。Bundle的类加载器能够控制的类加载边界包括：启动类路径上的类资源，OSGi框架即SystemBundle上的类资源和Bundle内部的类资源。该类资源边界即形成该Bundle的类域。

每一个Bundle在OSGi框架中具有自己的生命周期，其生命周期内的状态包括：INSTALLED、RESOLVED、STARTING、ACTIVE、STOPPING和UNINSTALLED。

INSTALLED状态是Bundle的初始状态，当该Bundle部署到OSGi系统的Bundle Repository中时，Bundle的状态标记为INSTALLED。

Bundle内部的资源在加载之前，首先由OSGi框架对其进行解析（Resolve），解析的过程就是分析Bundle的元数据的过程，详细过程参考OSGi规范。解析后的Bundle进入RESOLVED状态，解析失败时，仍然处于INSTALLED状态。

Bundle内的资源被其它Bundle使用时，该Bundle被启动，也可以通过设定让OSGi框架在加载该Bundle时直接启动。

Bundle内的资源通过BundleContext与其他Bundle进行交互。元数据中的"Bundle-Activator"属性指定了实现BundleActivator接口的实现类，Bundle通过该类得到BundleContext，通过BundleContext可以查找其他的Bundle，查找注册在OSGi中的服务（Service）与OSGi环境进行交互等等。Bundle可以在其提供的BundleActivator实现类中进行初始化的工作，也可以注册服务到OSGi的服务注册表中，供其他Bundle查找使用。

1.3 Jboss microcontain和PicoContainer

JMX微内核的问题就是要求用户应用按Jboss的服务体系结构进行开发，不便于移植。新一代内核Microcontainer是彻底的反转控制(IoC)，依赖注入的轻量容器，允许开发人员通过XML配置POJO，这些POJO有自己的生命周期，能够独立作为服务(Service)使用，更重要是它不在依赖JBoss应用服务器了，可以成为组件嵌入到任何系统。

Microcontainer与PicoContainer的区别 PicoContainer也是一个反转控制，依赖注入的轻量级容器，与Microcontainer最大的区别在生命周期的管理上，Microcontainer的设计目标是新一代Jboss的内核，所以它的生命周期管理是十分完善的，包括instantiate，configure, create, start, register等操作，而PicoContainer只提供了简单的start和stop。

2 microcontainer 及原来的JBoss4 用到的jmx container的比较

2.1 JMX微内核结构

JMX内核的目标是让系统能以统一的方式去管理服务对象，所有的服务对象都是一个Mbean，并注册到JMX内核中，通过Mbean的定义，可以方便的调用服务对象的操作。

2.2 对象部署

在Jboss4中，当MainDeployer部署一个单元时，它遍历访问已注册的SubDeployer，SubDeployer通过accept方法来检查是否能接受部署单元，当返回true时，MainDeployer将部署单元交由此SubDeployer进行部署。

下面来看看实际的部署操作，系统启动后，首先部署conf/jboss-service.xml，根据规则定义*-service.xml由SARDeployer部署。

step 1. init 初始化

首先通过findDeployer查找合适的SubDeployer，如果找不到则等待，这里为SARDeployer;

然后调用SARDeployer的init方法进行初始化;

step 2. create 创建

调用SARDeployer的create方法开始服务组件创建;

首先由ServiceController安装服务组件，在jboss-service.xml中定义的每一个mbean节点都对应为一个服务组件;

然后由ServiceController创建服务组件;

step 3. start 启动

调用SARDeployer的start方法启动服务组件;

遍历部署单元内的服务组件，并由ServiceController启动它;

部署完成后，URLDeploymentScanner扫描器开始监视部署目录的变化，当内容发生变化时，如一个服务复制到目录或从目录移除时，扫描器调用MainDeployer对其进行部署或卸载。

2.3 生命周期控制

所有实现Service接口或继承ServiceMBean类并注册到JMX中的对象，都可以通过ServiceController对它的生命周期进行控制。Service接口定义了对象生命周期的四个操作： create，start，stop，destroy。

2.4 结构图

从上图可以看到Jboss5对Microcontainer SPI做了一些扩展处理，用来对Jboss4的MicroKernel进行改造，核心对象是JMXKernel，用来连接Microcontainer和Jboss4系统。

2.5 ProfileServiceBookstrap

ProfileServiceBookstrap是服务启动器，用于启动Kernel，并部署{profileName}/bookstrap-beans.xml中定义的Bean，其中主要的bean定义如下:

1. ProfileService：配置服务对象，记录当前运行的Jboss配置。

2. JMXKernel：JMX核心对象。

3. MainDeployer：主部署器对象，扩展Jboss4中的主部署器。

4. HDScanner：热部署扫描器对象，替换Jboss4中的热部署扫描器对象。

2.6 JMXKernel

JMXKernel继承自ServerImpl对象，并重写了start方法，用于创建和启动MbeanServer，在Jboss5中，除了对象的状态控制交由Microcontroller处理之外，JMX的结构和Mbean的处理并没有太大变化。

2.7 对象部署

2.7.1 部署的改进

Jboss5中对部署做了比较大的更改：

首先是主部署器，Jboss5中新增了一个MainDeployer，Jboss4中MainDeployer的Deploy操作委派给了这个新的MainDeployer来处理；

其次是部署目录的调整，不像Jboss4中使用单一deploy目录，Jboss5中deployers为部署器的部署目录，deploy为应用程序的部署目录； 第三是新增一个部署扫描器（HDScanner）来替换Jboss4中的URLDeploymentScanner。

2.7.2 部署初始化

在Bootstrap-beans.xml中，有五个与部署相关的Bean:

1. MainDeploy：主部署器；

2. VFSBootstrapScanner：用于扫描conf/jboss-service.xml；

3. VFSDeployerScanner：用于扫描deployers目录；

4. VFSDeploymentScanner：用于扫描deploy目录；

5. HDScanner：用于热部署扫描；

在MicroContainer的Kernel启动后，紧接着就部署了conf/bootstrap-benas.xml，以上Bean都将创建并启动，VFSScanner启动后将扫描指定的部署URL，并将解析到的部署上下文（DeploymentContext）添加到ProfileService对应的Profile对象中。

2.7.3 MainDeploy

在Bootstrap-beans.xml中，MainDeployer定义包含两部分内容：

1. structureDeployers，定义了处理相应文件结构对应的布署器，主要用于部署单元文件结构，没有定义的文件结构将不能被部署，默认包括JARStructureDeployer，WARStructureDeployer和FileStructureDeployer。

2. deployers，部署器定义，默认包括AspectDeployer，BeanDeployer，ServiceDeployer等。

2.7.4 HDScanner

HDScanner通过一个定时器启动扫描线程，通过当前激活的Profile对象来获得有变动的URL，然后调用MainDeployer重新部署。

2.8 生命周期控制

与Jboss5中，生命周期的状态由Microcontainer进行控制，ServiceController只做了一些简单的封装，下面来看看create的流程。

ServiceController的处理部分：

1. 取得ServiceControllerContext，如为null则注册服务；

ServiceControllerContext context = installed.get(serviceName);

2. 取得MicroContainer的KernelController；

KernelController controller = kernel.getController();

3. 更改状态；

doChange(controller, context, ControllerState.CREATE, "create");

controller.change(context, requiredState);

KernelController的处理部分：

在前面Microcontainer的生命周期控制中提到了，状态的控制最后将由ControllerContext来处理，Jboss5中使用ServiceControllerContext实现了ControllerContext，并定义了与生命周期对应的Action，如下：

CreateDestroyLifecycleAction：对应create，destroy；

StartStopLifecycleAction：对应start，stop；

在LifecycleAction中，都是先获得ServiceProxy，然后再通过JMX微内核进行目标调用。

另外两个相关的Action：

InstantiateAction：对应register，注册并实例化服务对象；

ConfigureAction：对应configure，配置服务对象，主要是针对xmbean；

3 microcontainer 中的几个特征的解释and理解

3.1 模型

(JBoss原理-x.doc)

3.2 Classloader

3.3 Vfs

3.4 Injection and ioc

4 microcontainer用到的几个大的技术与服务

wiki上的FAQ 5

Ioc:

AOP:

annotation :

服务概念

所谓服务，必须满足下面的条件：

1. 实现某种功能，以便多个客户可以使用

2. 具有名称，以便客户可以在运行时通过某种命名机制通过名称来访问该服务

3. 服务内部的变化不影响外部客户对其的使用

所以普通的POJO并不能称之为服务，因此需要JBoss Microcontainer这样的服务容器来构建基于POJO的服务。

JBoss Microcontainer如何让POJO变为服务呢？我们有部署文件：<?xml version="1.0" encoding="UTF-8"?>

<deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="urn:jboss:bean-deployer:2.0 bean-deployer_2_0.xsd"

xmlns="urn:jboss:bean-deployer:2.0">

<bean name="HRService" class="org.jboss.example.service.HRManager"/>

</deployment>

HRService就是org.jboss.example.service.HRManager类的名称，我们通过这个名称来访问这个类实现的服务。

JBoss Microcontainer将使用XML部署器在运行时解析执行相应的部署，实例化该服务。

单一的POJO实际上做不了太多的事情，大部分的业务逻辑都是多个POJO相互交互完成的，也就是说我们需要装配POJO或者服务：

<?xml version="1.0" encoding="UTF-8"?>

<deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="urn:jboss:bean-deployer:2.0 bean-deployer_2_0.xsd"

xmlns="urn:jboss:bean-deployer:2.0&Prime;>

<bean name="HRService" class="org.jboss.example.service.HRManager">

<property name="salaryStrategy"><inject bean="AgeBasedSalary"/></property>

</bean>

<bean name="AgeBasedSalary"

class="org.jboss.example.service.util.AgeBasedSalaryStrategy"/> </deployment>

在这个配置文件中，我们添加了一个Bean，然后在先前的Bean中配置一个属性，再使用<inject>元素

将第二个Bean注入到先前的Bean中。看到没有：依赖注入！

上述配置相当于：

HRManager hrService = new HRManager();

AgeBasedSalaryStrategy ageBasedSalary = new AgeBasedSalaryStrategy();

hrService.setSalaryStrategy(ageBasedSalary);

5 下个阶段的研究重点

(JBoss5 研究计划)

1、JBM 在JBoss 5下的配置、监控、调优等；

2、JBoss 5 HA JNDI特性的原理，EJB 动态负载均衡的原理和实现等；

3、JBOSS 5 下的性能监控，特别结合我们UF中的诊断系统；

4、JBoss AOP的特性和使用等；

5、集群的深入研究，如何切换，如何进行负载均衡的，结合各种服务；

6、JBoss 5中有JDK5 适用的和JDK6适用的，确认其区别和原因；

7、MicroContainer的进一步应用等；

6 其它