JBOSS架构分析.docx

JBOSS架构分析.docx

《JBOSS架构分析.docx》由会员分享，可在线阅读，更多相关《JBOSS架构分析.docx（22页珍藏版）》请在冰豆网上搜索。

JBOSS架构分析

研究项目:

JBoss架构分析

   JennyLiu

   SchoolofInformationTechnologies

   UniversityofSydney

   jennyliu@cs.usyd.edu.au

熙可集团系统分析员:

李剑华翻译

huihoo.orgAllen整理,制作

English

摘要

JBoss是一个免费的开放的J2EE实现。

它的架构是基于高标准的模块化和插入式设计。

JBoss使用工业标准的JMX来管理，JBoss组件和为EJB提供服务。

基于我们以前的开发经验，我们发现了不同的J2EE应用服务器间的存在着巨大的性能和可扩展性差异。

我们相信架构的设计是决定类似于性能和可扩展性等质量指标的重要因素。

分析和展现JBoss架构模型有助于我们了解其内部行为并帮助我们创建一个精确的最终性能模型。

在这个项目中，我们分析JBoss应用服务器架构的四个特殊部分，JBossEJB容器、JBossNS、JBossTX以及JBossCMP，逆转工程工具能使我们通过源代码来分解组件/子系统。

无论是三个JBoss子系统的概念模型或实际模型都将被我们用来讨论JBoss架构模块设计风格。

TableofContent

1.介绍

1.1JBoss是什么

1.2动机

1.3方法

1.4组织

2.JBoss服务器架构一览

2.1JMX-层次

2.2JBoss主要模块

2.3它是如何工作的?

3.架构模型概念

3.1容器的概念性架构模型-插入式

3.1.1主要的组件和接口

3.1.2依赖性

3.2JBoss命名服务概念模型

3.2.1主要JNDIAPI

3.2.2主要组件和接口

3.2.3依赖性

3.3JBossCMP概念模型

3.3.1主要组件和接口

3.3.2依赖性

3.4JBossTx概念模型

3.4.1主要组件和接口

3.4.2依赖性

4.实际架构模型

4.1容器实际模型

4.1.1获得综合实际模型的方法

4.1.2非正规组件和依赖

4.1.3实体Bean容器的示例和它的执行方法调用的插件

4.2JBoss命名服务概念模型

4.2.1特殊组件和相互关系

4.2.2客户端获得EJB本地对象的例子

4.3JBossCMP概念模型

4.3.1特殊组件和联系

4.4JBoss交易管理实体模型

4.4.1特殊组件和关联

5.JBoss架构的可扩展性

6.结论

7.参考

8.数据字典

9.附录

图示列表

1.Figure1-1JBoss总体概念模型

2.Figure2-1JMX层次模型

3.Figure3-1容器概念架构模型

4.Figure3-2拦截器调用'Pipe'

5.Figure3-3JBoss命名服务概念模型ServicesConceptualModel

6.Figure3-4JBossCMP服务概念模型

7.Figure3-5JBossTx概念架构模型

8.Figure4-1容器相互依赖图

9.Figure4-2JBoss命名服务概念模型

10.Figure4-3方法调用消息图

11.Figure4-4实体Bean容器概念架构模型

12.Figure4-5客户端和EJB容器的交互图

13.Figure4-6JBossCMP依赖与继承图andInherencyDiagram

14.Figure4-7JBossCMP概念模型

15.Figure4-8JBossTx依赖与继承图

16.FigureAppendix-1StatelessSessionContainer概念架构模型ConcreteArchitectualModel

17.FigureAppendix-2StatefulSessionContainer概念架构模型ConcreteArchitectualModel

18.FigureAppendix-3ACOTSEJB容器概念架构模型ConceptualArchitectureModel

1.介绍

1.1JBoss是什么?

JBoss是免费的，开放源代码J2EE的实现，它通过LGPL许可证进行发布。

它提供了基本的EJB容器以及EJB（好像应该是J2EE）服务，例如：

数据库访问JDBC、交易（JTA/JTS）、消息机制（JTS）、命名机制（JNDI）和管理支持（JMX）。

目前的JBoss发布版2.2.4实现了EJB1.1和部分EJB2.0的标准、JMS1.0.1、Servlet2.2、JSP1.1、JMX1.0、JNDI1.0、JDBC1.2和2.0扩充（支持连接池（ConnectionPolling））、JavaMail/JAF、JTA1.0和JAAS1.0标准，JBoss是100%纯Java实现能运行于任何平台。

1.2动机

这个项目的动机是我们想分析一下中间件基础系统的性能。

基于我们以前的开发经验，我们知道不同J2EE应用服务器在性能和可扩展性方面有着极大的差异，并且相信架构的设计是决定类似于性能和可扩展性等质量指标的重要因素，我们想通过分析这个系统来了解架构设计究竟对于性能和可扩展性具有着怎样的影响。

无论概念性模型的局限性或实际模型中对于系统运行期行为的Reflect（反射机制）应用，他们还是能提供给我们一个对于整个系统的全面架构的了解的视点和符合基本境况的分析模型的构建的前提。

1.3方法论

大型软件系统的架构分析可以分为两个层面：

概念性架构和实际架构。

概念性架构通过将子系统的"捆绑式"分析和子系统间的分析描述了这个系统的架构。

每一个子系统具有清晰的有意义的方法和他们包含了整个系统的特殊的架构风格。

实际架构和概念性架构比起来具有较少的层次关系。

它表述了实际的编程规划/模型的实际体现，它和想象的概念性架构有很多不同。

在这个项目中，我们将JBoss的概念性架构和实际架构进行了分割。

想象的概念性架构模型通过参考资料来分割和获得，我们自己的经验来自配置应用系统和JBoss的在线论坛。

眼下，我们先关心一下每个组件在模块层面上的功能性，他们彼此不相关。

实际架构模型是综合的。

我们使用逆转工程工具Together5.5以便于将源代码翻转成为类（class）图和序列（sequence）图并使他们在一个子系统模型中综合。

Together5.5支持应用设计，实施，配置和JBoss的逆转工程。

它可以通过Java文件和class文件来获得类图。

更深一层，我们通过使用Together选择相应的特殊的方法来获得序列图。

有两个工具可以帮助我们来了解组件行为，最终实际模型和概念性模型的比较。

在实际模型中以外的模块、组件和其它部分也将被讨论。

1.4组织

这份报告将按照以下次序进行组织：

第二部分将介绍JBoss架构的整体设计和主要的组件。

第三部分讨论JBoss子系统的概念性模型，即：

容器框架和它的插件。

JBoss命名服务（JNDI），JBoss容器持久性管理（CMP）和JBoss交易服务。

第四部分，我们将挖掘JBoss子系统的实际模型和被提及的组件间的相应稳固的关系。

第五部分，我们来评价一下JBoss的架构风格和在性能、可更改性、可扩展性等一系列质量指标上的表现。

在第六部分我们将讨论我们将来的工作和提出我们报告的最终结论。

2.2.JBoss服务器架构概述

JBoss的构架和其他J2EE应用服务器的构架有着巨大的不同。

JBoss的模块架构是建立在JMX底层上的，下图展现了JBoss主要组件和JMX的联系。

Figure1-1OverallJBossConceptualModel

2.1JMX-层次

JMX是一个可复用框架，它为远程（Remote）和本地（Local）管理工具扩展了应用。

它的架构是层式架构。

他们是实现层（instrumentationlayer）、代理层（agentlayer）和发布层（distributionlayer）。

其中，发布层还在等待未来的标准化。

简要的表述是，用户使用管理Bean，MBean来提供获得相应资源的实现方法。

实现层实现相关的特性资源并将它发布于JMX相关应用中，它的代理层控制和发布相应的注册在MBeanServer代理上的管理资源。

.

Figure2-1JMX层次模型

2.2JBoss主要模块

主要的JBoss模块是在MeanServer上的可管理MBean。

[2].1.JBossEJB容器是JBoss服务器的核心实现。

它有两个特性，第一是在运行期产生EJB对象的Stub和Skeleton类，第二是支持热部署。

2.JBossNS是JBoss命名服务用来定位对象和资源。

它实现了JNDIJ2EE规范.

3.JBossTX是由JTA/JTS支持的交易管理控制.

4.部署服务支持EJB（jar）、Web应用文档（war）和企业级应用文档（ears）的部署。

它会时刻关心J2EE应用的URL情况，一旦它们被改变或出现的时候将自动部署。

5.JBossMQ使Java消息规范（JMS）的实现。

6.JBossSX支持基于JAAS的或不支持JAAS机制的安全实现。

7.JBossCX实现了部分JCA的功能。

JCA制订了J2EE应用组件如何访问基于连接的资源。

8.Web服务器支持Web容器和Servlet引擎。

JBoss2.4.x版本支持Tomcat4.0.1，Tomcat3.23和Jetty3.x服务.

2.3他们是如何工作的?

当JBoss被启动，它的第一步是创建一个MBean服务器的实例。

一个基于管理机制的MBean组件通过在MeanServer中的注册而被插入JBoss中。

JBoss实现了动态类装载M-Let服务，它是代理服务，M-let允许MBean被注册到MBean服务器上。

通过基于文本文件的配置文件中的配置，相应MBean将被装载。

JMXMBean服务器实际上本身并没有实现很多功能。

它的工作类似于一个MBean中联系的微核聚合组件，通过Mbeans取代JMXMBean服务起来提供相应的功能，换而言之，真正起作用的是MBean。

JBoss的整体架构并不是依循Garlan和Shaw文件中的架构风格严格分类的，代替它的是一个组件插入式的框架。

MBean的接口是一个连接器。

在这封报告的余下部分，我们选择了JBoss架构中的JBossEJB容器、JBossNS、JBossTX和JBossCMP子系统来加以学习。

虽然JBossCMP，实体Bean的容器管理持久层是容器架构的一部分，但我们还是将它分开讨论，因为他们有自己的构架。

我们只在这个项目中介绍三个部分是因为它们是我们关心的JBoss应用服务器的性能问题的关键点。

在这个项目中我们使用的方法学可以扩展到更多有用的子系统的学习中去。

3.概念架构模型

3.1容器的概念性架构模型-插入式

JBossEJB容器是JBoss服务器的核心实现。

图3-1展示了EJB容器的概念性模型。

我们发现JBoss容器的架构并不是一个严格意义上的层，决大多数的独立件是双向管理，容器依赖于更多的低层次组件。

实际上，容器和它的插件、实例池（instancepool）、实例缓存（instancecache）、拦截器、实体持久管理、有状态会话持久管理，都是基于插入式框架来为特定的EJB提供相应的EJB服务。

Figure3-1ContainerConceptualArchitectureModel

3.1.1主要的组件和接口

客户端不可以直接访问EJB实例而是要通过Home（EJBHome）和容器提供的远程对象（EJBObject）接口。

Container类是依循客户端的调用来提供Bean实例并实现操作。

Container类的责任来实现插件的交互，为插件提供信息来实现操作并管理Bean的生命周期。

Container类有四个子类（四种Bean的类型），分别是：

StatelessSessionContainer、StatefulSessionContrainer、EntityContainer和MessageDrivenContainer。

它们是由ContainerFactory通过相应的Bean类型在部署期中被创建和初始化的。

ContainerFactory被用来创建EJB容器和在容器中部署相应的EJB。

ContainerFactory被作为一个MBean实现。

这意味着JBoss服务器启动的时候其相应的服务也被启动。

它会对EJB-jar的XML定义文件获得相应的URL。

ContainerFactory使用EJB-jarXML中的元数据产生一个容器实例并使他们处于可被调用状态，在部署期中，ContainerFactory的功能包括：

∙通过在部署描述文件中的EJB类型来创建Container类的子类，即四个子类中的一个。

∙通过jboss.xml和standardjboss.html文件创建容器属性。

∙通过定义在standardjboss.html文件中的内容创建和添加容器拦截器。

∙使用应用对象来联系相应的容器。

ContainerInvoker是一个JavaRMI服务器对象。

正如他名字所表述的，ContainerInvoker通过客户端的请求（request）方法来调用相应的容器。

可以看作客户端请求和容器间的接口，它利用RMI来获得自身的有效调用，无论这个调用来自其他JVM上的远程客户或是来自同一JVM上同一EJB应用的其他Bean。

ContainerInvoker工作在通讯层面上，通过特殊协议进行通讯。

如果想在JBoss服务器上实现新的协议，第一是需要提供一个该协议的ContainerInvoker实现。

JBoss通讯层回复是通过SunRMI的JRMP，ContainerInvoker的RMI版本是JRMContainerInvoker。

一个ContainerInvoker在EJB中实现分割相应的通讯协议，这种设计增加了系统的可更改性。

JBossEJB容器中所使用的协议可以在相应的服务器配置文件中定义。

EJB对象实例被放入InstancePool中以减少在运行期中创建它们的开销。

在InstancePool中的实例不能和其他的EJB对象交流，它们由InstancePool来管理。

有状态会话Bean和实体Bean实例将被缓存化，在生命周期中它们拥有相应的状态。

一个缓存实例通过实例池获得，他们和特殊的对象相关联并具有相应的标示。

其状态由InstanceCache控制，例如在缓存中的实例状态和第二方存储介质中的对象的同步。

EntityPersistenceManager对于实体Bean的持久性起作用。

StatefulSessionPersistenceManager对于有状态会话Bean的持久性起作用。

拦截器通过容器获得相应的方法调用。

在容器配置文件standardjboss.html中，被方法调用的拦截器必须被依次定义在其中。

图3-2展示了通过拦截器的方法调用的逻辑执行顺序。

图3-2通过拦截器管道的方法调用

这个设计遵循了DavidGarlan和MaryShaw的"管道和过滤"（"pipeandfilter"）架构定义，在此定义的过滤原型是一个组件，其包括了数据流和类似于输出总是发生在输入流被完全读取之后等方面的计算输出的增强，拦截器是过滤器而方法调用是连续拦截器中的连接器。

拦截器是整个构架中的优势部分：

∙它能够知道每一个阶段管道的行为。

∙它通过模块来支持重用和扩展，不同拦截器之间具有明显的一个功能性区别。

添加一个新的拦截器，第一是需要实现拦截器的接口并将他定义到相应的容器配置文件中

∙支持同步.

∙具有快速的容错语义表述.如果在拦截器处理中产生错误或违例,就会出现相应表述。

3.1.2依赖性

本质上,InstancePool,InstanceCache,EntityPersistenceManager,StatefulSessionPersistenceManager,都是容器插件的接口。

容器的插件是这些接口的实现对象的集合。

JBoss容器并不做太多的复杂的工作，它只是提供了一个联系不同插件的框架。

∙容器向拦截器发出方法调用信息。

∙拦截器依赖于InstancePool来访问会话Bean实例，或是依赖于InstanceCahce访问实体Bean实例

∙最好还是为了一个自由Bean时，InstanceCache会和InstancePool进行互动

∙InstanceCache依赖于EntityPersistenceManager（或StatefulSessionPersistenceManager）通过数据源进行实例状态初始化。

.

∙拦截器依赖于EntityPersistenceManager（或StatefulSessionPersistenceManager）通过数据源进行实例状态的同步。

当执行客户端请求时，容器的框架依赖于外部的其他的服务功能块、命名服务、交易服务、安全服务和资源管理。

举个例子，当客户端请求一个交易信息将更新数据库内容，容器会通过命名服务获得相应的数据源和资源管理提供的相应的数据源驱动。

整个交易过程在容器内进行，交易管理器和资源管理器由交易服务进行控制。

不象传统的分布式系统构架，EJB容器在部署描述文件中声明了外部属性。

虽然容器担当的是和元数据信息的通讯作用，它在部署服务中显示出的外在独立性和其他的服务还是有点不同的。

这意味着它的信息在部署期时就被放入容器中了。

3.2JBoss命名服务的概念性模型

3.2.1主要的JNDIAPI

JNDI提供了为数众多的命名服务。

主要的JNDIAPI是javax.naming.Name，javax.naming.Context以及javax.namingInitialContext。

根本上命名系统是一个对象的集合并且每个对象都有独立的名字。

Context是用户端访问命名服务的接口。

InitalContext实现了Context。

JBoss命名系统是JBossJNDI的提供者。

源代码在org.jnp包中，就像我们在第二部分中提到的一样，JBoss命名系统被实现成为MBean。

图3-2展示了JBoss命名系统的概念性模型。

图3-3JBoss命名服务概念性模型

3.2.2主要的组件和接口

Org.jnp.server包包含了命名服务的MBean，Main包装了MainNamingServer并发布它。

NamingServer的工作是进行"命名-对象"一对对的序列编排。

Org.inp.interface包继承/实现了javax.naming.*接口，这是个J2EE规范。

这个接口可以通过客户端远程访问。

它使得Main可以在NamingServer中和命名服务进行交互，NamingContext实现了javax.naming.Context接口，它是客户端和JBoss命名服务之间的接口。

3.2.3依赖

JBossNS没有更多的外部依赖.

3.3JBossCMP概念性模型

3.3.1主要组件和接口

JBossCMP通过扩展JAWS来支持内存中Java对象和关系型数据库基本储存之间的映射（是一个O/RMapping的概念）。

JBossCMP包含了支持EJB1.1容器持久性管理（CMP）模型的组件。

在CMP的实体Bean模型中，EJB实体的持久性状态的性能是由容器决定的。

容器访问数据库是实体Bean的行为。

图3-4展示了JBossCMP服务的概念性模型。

Figure3-4JBossCMPServicesConceptualModel

EntityContainer依赖EntityPersistenceManager接口为持久性管理的实体Bean。

CMPPersistenceManage实现了EntityPersistenceManager接口。

就像我们前面提到的，容器管理了实例的状态。

EJB1.1CMP的语义有回调方法、ejbLoad、ejbStore、ejbActivate、ejbPassivate、ejbRemove提供了实例状态观点的容器表述。

实际上，正是CMPPesistenceManager在做一项工作：

底层的数据库和缓存实例状态的同步。

举个例子：

当一个Bean的缓存数据被装载，CMPPersistenceManager将会在Bean实例中调用容器的回叫方法ejLoad。

当缓存数据需要更新数据库，ejbStore方法将被调用来准备相应的缓存数据，这样CMPPersistenceManager将关注于更新数据库。

EntityPersistenceStore接口的实现关注的是具体的物理储存细节。

CMPPersistenceManager授权于EntityPersistenceStore进行实体持久性内容的实际储存。

注意EntityPersistenceStore是一个接口，它留着持久层储存实现的客户化空间，e.g。

基于文件的储存或数据库存储。

3.3.2依赖性

JBossCMP并不是和JBossNS一样被实现成为MBean服务。

实际上，它被包含在EJB容器包org.jboss.ejb中通过容器和其他的插件进行交互。

表面上，JBossCMP是依赖于JbossNS来获得相应的数据源调用并在Bean实例中存放持久性数据。

3.4JBossTX概念性模型

3.4.1主要组件和接口

JBossTX构架可以使用的是任何实现了JTA规范的交易管理。

在分布式交易中主要的参与者包括：

:

1.交易管理器：

它提供了相应的服务和管理方法来支持交易划分、交易资源管理、同步和交易内容传播等功能。

使用javax.transaction.TransactionManager接口以便于可以通过RMI来输出交易管理。

2.应用服务器：

一个应用服务器（或TP监视器）提供了基础结构来支持运行期环境的交易状态管理应用。

应用服务器的例子是:

EJB服务器/容器。

3.资源管理器：

资源管理器提供进入其他资源的功能。

资源管理器的例子是：

关系型数据库服务器。

4.交易内容：

交易内容确定一个特定的交易。

5.交易客户端：

交易客户端在单个交易中可以调用一个或多个交易对象。

6.交易对象：

交易对象的行为是由交易内容中的运作来决定的.绝大多数的EJBBean是交易对象。

Figure3-5JBossTX概念性架构模型

3.4.2依赖

JBossTX架构被设计成为可以使用任何的实现了JTAjavax.transaction.TransactionManager接口的交易管理，JBoss交易管理将被看作为一个MBean，并可通过RMI当作一个服务输出其自身。

交易管理服务的基本需求是在JBoss服务器服务管理启动的时候通过JNDI命名目录绑定它的实现。

因此，JBossTX看上去是依赖于JBossNS的。

4.4.实际架构模型

实际架构模型是通过工程逆转工具通过JBos