JBoss Architecture

中文版:

http://hi.baidu.com/dreamsun2008/blog/item/536b84d5859edd0aa18bb7c3.html 

 http://hi.baidu.com/dreamsun2008/blog/item/6cc7a6edc486392c62d09fde.html

http://www.huihoo.org/jboss/jboss.html

Research Project: An Analysis of JBoss Architecture

   Jenny Liu 
   School of Information Technologies 
   University of Sydney 
   jennyliu@cs.usyd.edu.au 


Chinese 

Abstract

JBoss is a free, open source J2EE implementation. Its architecture is highly modular and plug-in design. JBoss uses the industry standard Java Management eXtentions (JMX) to manage the JBoss components as well as provide services for EJB. Based on our previous research experience, we know there are great difference of performance and scalability among J2EE application servers. We believe the architecture design has an important role in determining the quality attributes such as performance and scalability. Analyzing and extracting architectural model from JBoss will provide us insights of its behavior and help us to build an accurate perdiction model on performance. In this project we analysis JBoss application server architecture especially on four susbsystems, JBoss EJB Container, JBossNS,JBossTX and JBossCMP. A reverse engineering tool is used to extract component/subsystem dependency from source code. Both the conceptual model and concrete model of the three JBoss subsystems are generated and the architectural styles used in JBoss design are discussed.

Table of Content

1. Introduction

   1.1 What is about JBoss

   1.2 Motivation

   1.3 Methodology

   1.4 Organization

2. JBoss Server Architecture Overview

   2.1 JMX - Layered

   2.2 JBoss Major Modules

   2.3 How does it works?

3. Conceptual Architectual Model

   3.1 Container Conceptual Architecture Model - Plug-in

   3.1.1 Major Componemnts and Interfaces

   3.1.2 Dependency

   3. 2 JBoss Naming Service Conceptual Model

   3.2.1 Major JNDI API

   3.2.2 Major Components and Interfaces

   3.2.3 Dependency

   3. 3 JBossCMP Conceptual Model

   3.3.1 Major Components and Interfaces

   3.3.2 Dependency

   3. 4 JBossTx Conceptual Model

   3.4.1 Major Components and Interfaces

   3.4.2 Dependency

4. Concrete Architecture Model

   4.1 Container Concrete Model

   4.1.1 The method to obtain a synthetic concrete model

   4.1.2 Unexpected Components and Dependency

   4.1.3 An example of a EntityBean container and its plugins to performance method invocation

   4.2 JBoss Naming Service Concrete Model

   4.2.1 Unexpected Components and Dependency

   4.2.2 An example of a client to get ejb home object

   4.3 JBossCMP Concrete Model

   4.3.1 Unexpected Components and Dependency

   4.4 JBoss Transaction Management Concrete Model

   4.4.1 Unexpected Components and Dependency

5. Evolvability of JBoss Architecture

6. Conclusion

7. Reference

8. Data Dictionary

9. Appendix

List of figures

1. Figure 1-1 Overall JBoss Conceptual Mode
2. Figure 2-1 JMX Layered Model
3. Figure 3-1 Container Conceptual Architecture Model
4. Figure 3-2 Interceptor Invocation 'Pipe'
5. Figure 3-3 JBoss Naming Services Conceptual Model
6. Figure 3-4 JBoss CMP Services Conceptual Model
7. Figure 3-5 JBossTx Conceptual Architectural Model
8. Figure 4-1 Container Dependecy Diagram
9. Figure 4-2 JBoss Naming Service Concrete Model
10. Figure 4-3 Method Invocation Message diagram
11. Figure 4-4 Entity Container Concrete Architectural Model
12. Figure 4-5 Client and EJB container Interaction Scenario
13. Figure 4-6 JBossCMP Dependency and Inherency Diagram
14. Figure 4-7 JBossCMP Concrete Model
15. Figure 4-8 JBossTx Dependency and Inherency Diagram
16. Figure Appendix-1 StatelessSessionContainer Concrete Architectual Model
17. Figure Appendix-2 StatefulSessionContainer Concrete Architectual Model
18. Figure Appendix-3 A COTS EJB Container Conceptual Architecture Model

---

1. Introduction

1.1 What is about JBoss

JBoss is a free, open source J2EE implementation distributed under the LGPL license. It provides the basic EJB container as well as EJB services such as database access(JDBC), transactions(JTA/JTS), messaging(JTS), naming (JNDI) and management support(JMX).Current release JBoss2.2.4 implements Enterprise JavaBean (EJB )1.1 and parts of 2.0 specification, JMS1.0.1, Servlet2.2, JSP1.1, JMX 1.0, JNDI1.0, JDBC1.2 and 2.0 extensions (Connection Pooling also supported), JavaMail/JAF,JTA1.0 and JAAS1.0. It is 100% pure java and can run on any platform [1][2][3].

1.2 Motivation

This project is motivated by our research work on performance analysis of middleware based systems. Based on our previous research experience,we know there are great difference of performance and scalability among J2EE application servers. We believe the architecture design has an important role in determining the quality attributes such as performance and scalability. We try to understand its architecture design effect on performance and scalability by extracting its architecture. Despite the limitation of conceptual model and concrete model to reflect the run-time behavior of the system, they do provide us a comprehensive architecture view of the entire system and serve as the foundation to construct an analytical model.

1.3 Methodology

The architecture of a large software system can be divided into two layers: conceptual architecture and concrete architecture[4],[5]. Conceptual architecture reprents the entire system by a bunch of subsystems and their interaction with each other. Each subsystem has a clear meaningful function and they comprise the entire system with a particular architecture style. Concrete architecture has a lower hierarchy level than conceptual architecture. It represents what exactly happens among the actual programming blocks/modules. It may have many deviations from the ideal conceptual architecture. In this project, we have derived both the conceptual and concrete architecture of JBoss. The ideal conceptual architecture model is derived from the reference [1,2,3,6,7,8],our own experiment to deploy applications and online formus of JBoss. At this stage, we focus on the functionality of each component at the module level and their dependencies on each other. The concrete architecture model is synthesized. We use a reserse engineering tool, Together5.5 [11] to extract the class and sequence diagrams from the source code and synthesize them into one subsystem model . Together5.5 supports application desing, implementation,deployment and reverse engineering on JBoss. It can generate class diagram of java files or classes files. Further, we can select a particular method and generate sequence diagram of it. These two utilities can help us understanding the component behavior. Finally concrete model are compared with conceptual model. The unexpected modules, componments and dependecy in the concrete model are discussed.

1.4 Organization

The organization of this report is as follows: section 2 introduces the overall architecture of JBoss and its major compoments. Section 3 discusses the conceptual model of JBoss subsystems, namely, container framework and its plugins, JBoss naming service, JBoss container managed persistence and JBoss transaction services. Section 4 we dig out the concrete model of JBoss subsystems and the unexcepted dependency between compoments are referred. Section 5, we evaluate the JBoss architecture styles and their effect on the quality attributes such as performance, modifiability and scalability. We dicuss our future work in section 6 and finally conclude our report.

---

2. JBoss Server Architecture Overview

JBoss architecture is special compared to other J2EE application server architecture.The modular architecure of JBoss is on the top of JMX infrastructure. The figure below shows the major JBoss components interating on JMX. 

Figure 1-1 Overall JBoss Conceptual Model

2.1 JMX - Layered

JMX is a reusable framework that can expose the applications to the remote or local management tools[8]. Its architecture is layered. There are instrumentation layer, agent layer and distribution layer. The distribution layer is still waiting for future specification. Briefly, the user provides the instrumentation of a given resource using managed beans,MBeans. The instrumentation layer instruments the resource about its features and exposes it to the JMX compliant application. They agent layer controls and exposes the managed resources that are registered with the agent by MBeanServer. 

Figure 2-1 JMX Layered Model

2.2 JBoss Major Modules

The major JBoss modules are manageable MBeans connected by the MBean server [2].

JBoss EJB container is the core implementation of JBoss server. It has two features. It generates the stub and skeleton class of EJB object at the runtime and it supportshot(re)deployment.

JBossNS is the JBoss naming service to locate the object and resource. It implements JNDI J2EE specification.

JBossTX is a transaction monitor with JTA/JTS support.

Deployment service supports deployments of EJB jars, Web application archives(wars) and enterprise application archives(ears). It watches the URLs for J2EE archives and deploy the archives as they appear or change.

JBossMQ is the implementation of Java Messgaing Specification(JMS).

JBossSX supports both non-JAAS and JAAS based security implementations.

JBossCX implements parts of JCA. JCA specifies how J2EE application components can access connection-based resources.

WebServers supports Web containers and sevelet engines.The 2.4.x version of JBoss Tomcat 4.0.1,Tomcat 3.2.3 service and Jetty 3.x service

2.3 How does it works?

When JBoss starts up, it creates an MBean server instance in one of the first steps. The manageable MBean components are plugged into JBoss by registering with the MBean server. JBoss implements the dynamic classloading M-Let services, which is an agent service. It allows to register the MBeans to the MBean server. The MBeans to be loaded are specified in a text based configuration files.

The JMX MBean server doesnt perform much functionality actually. It works as a microkernel aggregator component which interconnecting the MBeans. The functionality is provided by MBeans instead of JMX MBean server. The overall architecture of JBoss can not be strictly categorized as the architecture styles in Garlan and Shaw's paper[12]. Instead, it is a component plug-in framework. The interface of MBeans is the connector.

In the rest of this report, we will choose the JBoss EJB container, JBossNS, JBossTx and JBossCMP subsystems of JBoss architecture for our study. Although JBossCMP,container management of persistence of entity bean is a part of container architecture, we discussed it seperately, because it has its own architecture. The reason we only cover these parts in this project is they are of major concerns of our work on performance evaluation of JBoss application server. The methodology used in this project enables to include more subsystem into the study if needed.

---

3. Conceptual Architectual Model

3.1 Container Conceptual Architecture Model - Plug-in

JBoss EJB Container is the core implementation of JBoss server. Figure 3-1 shows the conceptual model of EJB container. We can see that the architecture of JBoss container is not a strict layout. Most dependencies are bi-directed and the container depends on much lower level components. In fact, the Container and its Plugins, InstancePool,InstanceCache, Interceptor, EntityPersistenceManager, StatefulSessionPersistenceManager, form a plugin framwork [14] to provide EJB services to a particular EJB. 

Figure 3-1 Container Conceptual Architecture Model

3.1.1 Major Componemnts and Interfaces

The client doesnt access to the ejb instance direclty rather than interacts with home (EJBHome) and remote ojbect (EJBObject) interfaces provided by the container. TheContainer forward the calls from client to bean instance to perform operations. It is the container's responsibility to interact with plugins, provide information for plugins to perform operations and manage the lifecycle of beans. There are four subclasses of Container, namely, StatlessSessionContainer, StatefulSessionContainer, EntityContainerand MessageDrivenContainer. They are created and initialized at the deployment time by the ContainerFactory according to the bean type.

A ContainerFactory is used to create EJB container and deploy EJB into the container. ContainerFactory is implemented as a MBean. That means its services start as the JBoss server starts. It can be given a URL to an EJB-jar XML file. ContainerFactory use the metadata in EJB-jar XML to instantiate containers and make them available for invocation. During the deployment, the functionality of ContainerFactory includes: 

• Create subclasses of Container depending on the EJB type in the deployment descriptor files
• Set the container attributed based on jboss.xml and standardjboss.html files
• Create and add container interceptors as configured in standardjboss.html files
• Associate the container with the application object

ContainerInvoker is a Java RMI server object. As it name indicate, ContainerInvoker will invoke the container for the method invocation representing of client request. It is interface between client request and container. It utilizes the RMI exporting to make itself available to accept calls from both remote clients living in other JVMs and from other beans of the same EJB application within the same JVM. ContainerInvoker works in the communication layer and it can be associated with a particular protocol. With a new protocol introduced into JBoss server, one just need to provide a ContainerInvoker implementation of that protocol. JBoss communication layer replies on Sun's RMI using JRMP. The RMI of version of ContainerInvoker is JRMContainerInvoker. A ContainerInvoker seperates the communnication protocal with the EJB implementation. This increases the system modifiablity. The protocol used by JBoss EJB container can be specified in the server configuration files.

EJB object instances can be pooled to reduce the overhead at run time to creat them. A pooled instance is not associated with any ejb object. They are managed by InstancePool.

Stateful session bean and entity bean instances can be cached. They have states in their life-cycle. A cached instance is obtained from instance pool and associated with a particular object and has an identity. The states are handled by InstanceCache, such as synchronization of the instance state in cache and in second storage.

EntityPersistenceManager is responsible for the persistence of entity bean.

StatefulSessionPersistenceManager is responsible for the persistence of stateful session bean.

Inteceptor accepts the method invocation forwarded by container. In the container configuration standardjboss.html file, the interceptors that the method invocation must pass through are defined in order. Figure 3-2 shows the logic execution of the method invocation passing through the interceptors: 

Figure 3-2 Method invocation pass through a Interceptor 'pipe'.

This conforms with the 'pipe and filter' architecture defined by David Garlan and Mary Shaw[12], in which a prototypical filter is a component that takes in a stream of data and incrementally computes output such that output appears before the input stream has been completely read in. The interceptors are filters and the invocation method is the connector between sucessive interceptor. Interceptors benefit from this architecture: 

• It enables the understanding the behavior at each stage of the 'pipe'.
• It supports reusability and extensibility through modularity. There is a clear functional distinction between different Interceptors. To add a new Interceptor, one just need to implement the Interceptor interface and specify it in the container configuration files.
• It support concurrency.
• It is fail-quick semantic. If there is error or exception in an interceptor processing, then it fails there.

3.1.2 Dependency

Internally, InstancePool, InstanceCache, EntityPersistenceManager, StatefulSessionPersistenceManager, Interceptor are interfaces for container Plug-in. Container Plug-in is a collection of the implementations of these interfaces. JBoss container doesnt do much significant work other than provide a framework to connect various plugins:

• A Container passes the method invocationt to an Interceptor.
• A Interceptor depends on an InstancePool for access to a session bean instance or an InstanceCache for an entity bean instance.
• A InstanceCache can may need to interact an InstancePool as well for a free bean.
• A InstanceCache depends on EntityPersistenceManager (or StatefulSessionPersistenceManager) to initialize the instance state from data store.
• A Interceptor depends on EntityPersistenceManager (or StatefulSessionPersistenceManager) to synchronize the instance state with data store.

When performing the client request, the container framework has external dependency on other service modulars, naming service, transaction service, security service and resource management. For example, when a client request has a transaction context update the data in database, the container need to contact naming service get the datasource and resource management provide the drive for that datasource. The transaction processing among the container, transaction manager and resource manager is controlled by transaction service.

Unlike traditional distributed system architecture, EJB container has externilized attributes declared in the deployment description files. Alought a container acts corresponding to these metadata information, its external dependency on the deployment service is a little different from other services. That means this information is set to the container at deployment time.

3. 2 JBoss Naming Service Conceptual Model

3.2.1 Major JNDI API

JNDI provides varities of naming services. The major JNDI API are javax.naming.Name, javax.naming.Context, javax.namingInitialContext. Basically a naming system is a colletion of object and each object has unique Name. Context is the interface for client to interact with a naming service. InitalContext implements Context. JBoss naming service is the JBoss JNDI provider. The source code is in the org.jnp package. As we have mentioned in section 2, JBoss naming service is implemented as MBean. Figure 3-2 shows the conceptual model of JBoss naming services. 

Figure 3-3 JBoss Naming Services Conceptual Model

3.2.2 Major Components and Interfaces

The org.jnp.server package contains the MBean of naming service, Main. Main wraps NamingServer and expose it. NamingServer does the job of name-object pair query.

The org.inp.interface package extends/implements javax.naming.* interfaces. The interface can be access remotely from client. It is interconnected with Main to access naming service in NamingServer. NamingContext is a implementation of javax.naming.Context and it is the interface between client and JBoss naming service.

3.2.3 Dependency

No external dependency found for JBossNS.

3.3 JBossCMP Conceptual Model

3.3.1 Major Components and Interfaces

BossCMP extends the JAWS to support the mapping between java object in memory and the relational data base storage. JBossCMP consists of the components to support EJB 1.1 Container Managed Persistence (CMP) model. In entity bean model of CMP, the persistence of the EJB instance state is performanced by the container. The container accesses the Database on behalf of the entity bean. Figure 3-4 shows the JBoss CMP services conceptual model 

Figure 3-4 JBoss CMP Services Conceptual Model

EntityContainer depends on EntityPersistenceManager interface for the persistence management of entity bean.

CMPPersistenceManager implements EntityPersistenceManager interface. As we mentioned before, the container manages the instance states. The semantics of EJB1.1 CMP callback methods, ejbLoad, ejbStore, ejbActivate, ejbPassivate, ejbRemove provides the container point of view of the instance state. Actually it is the CMPPersistenceManager that does the synchronization of cached instance states with underlying database. For example, when the bean cached data is loaded, CMPPersistenceManager will invoke container's callback method ejbLoad on the bean instance. When the cahced data needs to update the database, ejbStore method is invoked to prepare cached data and then CMPPersistenceManager will take care to update the dabase.

EntityPersistenceStore interface implementation takes care of the details of a particular physical store. CMPPersistenceManager delegates the actual storage of the entity persistent fields to EntityPersistenceStore. Notice that EntityPersistenceStore is an interface and this leaves space for persistence storage of customization, e.g. file based storage or database storage.

3.3.2 Dependency

JBossCMP is not implemented as a MBean service like JBossNS. In fact, it is included in the EJB container package org.jboss.ejb and interacts with container and its plugins.

Externally, JBossCMP may depends on JBossNS to get a reference of datasource to save the persistence data for bean instance.

3. 4 JBossTx Conceptual Model

3.4.1 Major Components and Interfaces

JBossTx architecture can use any transaction manager that implements JTA. The major participants in a distributed transaction include:

Transaction manager: It provides the services and management functions required to support transaction demarcation, transactional resource management, synchronization, and transaction context propagation. The javax.transaction.TransactionManager interface exposes the transaction manager over RMI. Application server: An application server (or TP monitor) provides the infrastructure required to support the application run-time environment which includes transaction state management. An example of such application server is a EJB server/container. Resource manager: A resource manager provides the application access to resources. An example of such a resource manager is a relational database server. Transaction Context: A transaction context identifies a particular transaction. Transactional Client: A transactional client can invoke operations on one or more transactional objects in a single transaction. Transactional Object: A transactional object is an object whose behavior is affecte by operations within a transactional context. Most ejb beans are transactional objects.

Figure 3-5 JBossTx conceptual architectural model

3.4.2 Dependency

JBossTx architecture is designed to use any transaction manager that implements JTA javax.transaction.TransactionManager interface. JBoss transaction manager is managed as an MBean and exports itself as a services over RMI.

The primary requirements of the transaction manager services is to bind its implementation to the JNDI naming directory when it is started by the service management of JBoss server. Therefore JBossTx externally depends on the JBossNS.

---

4. Concrete Architecture Model

The concrete architecture model is basically derived from the JBoss source code with the help of a reverse engineering tool. We choose Together5.5 from TogheterSoft. Togehther5.5 is CASE IDE and it can derive the class diagram directly from source code or from the class jar files. It also support method invocation trace by generating sequence diagram. Users have options to for visualization . There is a snapshot of how it works.

Since the developers tends to group files with similar functionality into package, we found that the hierarchy of the source code package is closed to the conceptual model. We rearrange the source codes by grouping the source codes in different packages with some expected dependency based on our conceptual model and put them into the together5.5.

The concrete architectural model is substantially different from our expection and knowledge of the conceptual model. Some components and dependency appear unexpected and some disappear. This is because the concrete model is from the implementation point of view which is closer to the run-time behavior than the conceptual model. In this section, we discuss the concrete model of container, naming service, container managed persistence service and transaction service.

4.1 Container Concrete Model

4.1.1 The method to obtain a synthetic concrete model

Figure 4-1 shows the dependency digram of container and its plugins. The concrete architecture model we got from Together5.5 is substantially different from our knowledge of conceptual model. It is now layered architecture model with the plugins implementation components in the top layer, container in the middle layer and the plugin interfaces in the bottom layer. The dependecy between interceptor and persistence manager disappear, which counters intuition based on the JBoss documentation. We found this is due to the pitfall of Together5.5 visualization of the relationship. The dependency of components in the same layer, for example the one between entity instance interceptor and entity instance, is omitted. To solve this problem, we use a method of following steps: 

1. Rearrange the source codes of container and its plugin interface, implementations according to the bean type. Feed them into Together5.5 project.
2. Extract both the dependecy and inherence relationship of components.
3. Choose key methods from key components and generate message diagrams to trace the method invocation.
4. Repeat 1,2,3 to synthesize the concrete model of container architecture

Figure 4-1 container dependecy diagram

Figure 4-2 container inherence diagram

Figure 4-3 method invocation message diagram

4.1.2 Unexpected Components and Dependency

Here we only discuss the entity container architectual model. StatelessSessionContainer and StatefulSessionContainer concrete architecutual model are shown in appendix. 

Figure 4-4 Entity Container Concrete Architectural Model

• Dynamic proxy based container design

In EJB specification, EJBHome implements the bean home interface and EJBObject implements bean remote interface. EJBObject interace presents a client's view of EJB. It is the responsibility of container provider to generate the javax.ejb.EJBHome and javax.ejb.EJBObject. In the design of JBoss EJB container, there is NO EJBHome and EJBObject object implementation at all. It is the dynamic proxies that take the role of EJBHome and EJBObject. A dynamic proxy is an object that can implement a list of specified inferfaces at the run time when it is created using java reflection.

At the deployment time the ContainerFactory creates and initializes containers.The home object is generated as a dynamic proxy by JRMPContainerIvoker, whick we will discuss it later. The InvocationHandler is replaced by HomeProxy class.Then it is bound to JNDI naming tree with a specified JNDI name in the deployment descriptor file.

The proxy is serializible and it can be sent to the remote client across network. When a client looks up the EJBHome from JNDI and the home proxy instance is serialized. At the client side, the home proxy instance is unserialized. Becasue the proxy implements the bean's home interface, it can be cast and used as the home interface.

When a client requests a EJBObject using home object reference. The EJBObject dynamic proxy is generated by the code shown above. The InvocationHandler is replaced by the one of the EJB object proxies, namely, StatefulSessionProxy, StatelessSessionProxy and EntityProxy based on the bean type. The same as home proxy, EJB object proxy can also be serialized and sent to the remote client across network.

Fianlly the client gets the handle of EJB object and can use it to invoke business method implemented in server side beans. The home and object dynamic proxies forward the calls from client to InvocationHandler.

• EJB Proxy

StatefulSessionProxy, StatelessSessionProxy and EntityProxy are implementations of InvocationHandler interface. As their names indicate, they work as a proxy for the container. They first attempt to handle the method on the client side. If the method invocation is for a remote method implemented in the server side. The call is converted into RemoteMethodInvocation object and then wrapped as MarsharlledObject and forwarded to JRMPContainerInvoker through RMI.

• JRMPContainerInvoker

Recall from Section 3.1.1 that ContainerInvoker is a container transport handler. JRMPContainerInvoker implements the RMI/JRMP transport protocol. It exports itself to accept remote method invocation by implements ContainerRemote interface which in turn extends java.rmi.Remote. JRMPContainerInvoker has optimization for handling the method invocation by providing two version of invoke() and invokeHome() method. One uses MarshalledObject parameter (call-by-value) and the other uses method reflection style parameters (call-by-reference). If the caller is from the same VM as the container, the caller can choose call-by-reference to omit the MarshalledObject serialization. Otherwise, the method invocation information is unpacked from MarshalledObject with all the attributes of the original EJB method invocation as well as security and transaction contexts. Then it is converted to MethodInvocation and passed to the container.

• EntityContainer and its Interceptors

The container type is specified as the bean type at deployment time. The ContainerFactory create and initialize it. Besides, for each bean type the standarjboss.xml specifies the interceptors used for this container and their order of invocation. The interceptors are also created and initialized. Each container maintain a list of interceptors. It forwards the method invocation to the first interceptor in the list by invoke() method. The interceptor handles the invocation first and triggers the next interceptor by calling its invoke() method. The last interceptor is the ContainerInterceptor, whose task is to delegate the method invocation to the bean instance.

• Dependency

We arranged the concrete architecture model so that it can be easily compared to the conceptual model. As we discussed in section 3.1.1, InstancePool, InstanceCache,Interceptor and PersistenceMangerare interfaces which extend ContainerPlugin. In the concrete model, the container plugins layer is replaced by the concrete implementation components. These components implement the plugin interfaces. Therefore the control flows from the EntityContainer to the plugin interfaces are now delegated to the concrete implementation components as shown as blue dash lines with arrow. The dependency in between the plugin interface, such as the InstanceCahce and InstancePool is now the control flow between the concrete implementation components, EntityInstanceCache and EnityInstancePool.

The persistence management of entity bean has two type, bean managed persistence(BMP) and container managed persistence(CMP). With BMP the programmer has to take care of the synchronization of bean cached state with underlying database while with CMP, the container generates the codes and free the programmer of such effort. Their effect on performance is beyond the scope on this report. We will discuss the JBossCMP architecture later.

Each XXXInterceptor is a implementation of Interceptor interface and they are container plugins. With entity bean, the EntityInstanceInterceptor, EntityLockInterceptor andEntitySynchronizationInterceptor use BeanLockManager for concurrency control on the bean instance.

Each ContainerPlugin implementation has depencency on the EntityContainer and it knows which container it is working for by setContainer() and getContainer().

There is such a need that ContainerInvokers may communicate with the Container, for example when a session bean invokes a method of entity bean. ContaineInvokerContainer is an interface for Containers that uses ContainerInvokers. JRMPContainerInvoker has a dependency on ContainerInvokerContainer, which is actually EntityContainer.

MethodInvocation is passed through all the components across the network. All the components have a dependency on it. MethodInvocation depends on EnterpriseContext, which is associated with the bean instance for the lifetime of the instance. In entity bean model, an entity bean is a java object representing the underlying database. CacheKey is an encapsulation of the PrimaryKey. EntityEnterpriseContext depends on CacheKey to get entity object and EntityProxy passes CacheKey as a parameter to the entity container. The entity container use CacheKey as an identity to locate the ejb object and delegate the calls to its instance.

• Summary

Compared with the conceptual model, the unexpected components and their relationships show how special the JBoss EJB container is. The dynamic proxy design is substantially different from the pre-complile container design, which is used by most COTS EJB container implementation. Appendix-3 shows a conceptual architecture model of a COTS EJB container. Declared in the JBoss documentation, dynamic proxy based container simplifies the container design. Its impact on quality attributes, such as performance can not be seen directly from concrete model. It must be measured quatitativily. This remains our futher work.

The plugin framework of EJB container make it flexible and evolvable. One just need to write a new implementation of a particular interface if changes are needed.

4.1.3 An example of a EntityBean container and its plugins to performance method invocation

Figure 4-5 shows the scenario of client and EJB container/server communication. Our analysis of EJB container concrete model can help us the understand the container behavours. 
Figure 4-5 Client and EJB container interaction scenario

1. At the deployment time, the home object is bound to the JNDI tree of JBoss naming service given a JNDI name.
2. The client first interacts the JNDI naming service to get the EJB home object.
3. The client requests a EJB object by using the EJB home object reference.
4. EJB home object create (or find ) a EJB object and return the reference to the client.
5. The client gets the EJBObject reference and invoke method in the remote interface.
6. The container intercepts the method invocation and delegate it to the bean instance. It finally returns the value to client by remote interface.
7. The call is logged by LogInterceptor
8. TxInterceptor decides how to manage transactions for this call based on the XML deployment discriptor
9. SecuirtyInterceptor checkes if the caller is allowed to perform this call based on XML deployment discriptor
10. The container must have an instance before it invokes the business method of bean.  EntityInstanceInterceptor calls the InstanceCache with the given primary key to acquire an instance of enity bean.
11. If the cache does not have an instance associatedwith the given primary key, it first calls the InstancePool to get a free instance associated with the primary key.
12. InstanceCache then calls the PersistenceManager to activate the instance by calling ejbActivate().
13. EntitySynchronizationInterceptor is invoked by EntityInstanceInterceptor  to deal with the instance synchronization with the database. There are several options and the interceptor is configured with one option. loadEntity() will be invoked on the EntityPersistanceManager.
14. ContainerInterceptor is the last Interceptor in the linkedlist added by the container itself instead of the container factory. Bussiness method invocation now is delegated to the EJB instance.
15. The instance performs some work and returns the results. The inteceptor chain is now followed reversely. Each interceptor returns from the invoke operation.
16. EntitySynchronizationInterceptor choose to store the current instance state into the database. The PersistenceManager's storeEntity()  will be called.
17. The instance is returned to the cache. If the transaction does not end with this call, the instance will be locked to this transaction so that no other transaction can use it for the duration of this transaction.
18. TxInteceptor  handles the method according to the transaction settings and choose to commit or rollback the current transaction.
19. The container invoke returns the result to the client.

4.2 JBoss Naming Service Concrete Model

4.2.1 Unexpected Components and Dependency

Figure 4-2 is the concrete architectual model of JBoss naming services. As the container concrete model, there are unexpected components and dependencies between componets, such as NamingService MBean and its relationship with org.jnp subsystem. In the following section, we will give detailed description. 

Figure 4-2 JBoss Naming Service Concrete Model

org.jboss.naming.NamingService is implemented as a MBean. It provides the JNDI naming services. It is the NamingService that create Main MBean and manage its state. When theNamingService starts, it initializes and start Main MBean. NamingService delegates the functionality to Main Mean. This duplication of MBeans volialate our conceptual model, however, the reason behind the screen is that JNDI naming service in JBoss is implemented as a stand-alone application. The NamingService MBean embeds Main by creating a new instance. The benefit of this architecture is if the JNDI VM is the same as JBoss server VM, the JNDI operation will pass socket connect and reduce the overhead.

4.2.2 An example of a client to get ejb home object

In order to understand the JBoss naming service architecture better, we give an example and trace the call processing. For example, when a client tends to invoke a bean method, it has to locate the bean home first, which is the handle to create a bean object for the client request. The JNDI name of the home object is specified in deployment discriptor file at development time. A client can get object at the run time by contact the naming service with its JNDI name.

1. When the JBoss server starts, NamingService MBean is registered and available for request.
2. NamingService initializes the Main MBean and now naming service is ready to accept request by listening to the socket.
3. A client provides naming service enviroment properties 
   
4. A client creates a new IntialContext. This will trigger the NamingContextFactory to create a new NamingContext 
   
5. A client lookups the home object from the JNDI naming service by a give JNDI name. NamingContext connects to Naming server and forword the lookup to it. 
   

4.3 JBossCMP Concrete Model

Figure 4-6 shows the JBossCMP dependency and inherency diagram we got from Together5.5.The JBoss CMP concrete model is very closed to our conceptual model. The unexpected subsystem is jwas.

Figure 4-6 JBossCMP dependency and inherency diagram

4.3.1 Unexpected Components and Dependency

org.jboss.ejb.plugin.jwas package contains the default implementation of object-to-relational mapping tool for CMP entity bean in JBoss. It uses JDBC database as its persistent store. The default implementation of EntityPersistenceStore is JAWSPersistenceManager. The customization of CMP entity bean persistence storage is to implements the interface method of EntityPersistenceStore. JAWSPersistenceManager does this by invoking the execute() method of its subclass, for example, JDBCActivateEntityCommand through its interface method of JMPActivateEntityCommand. JAWSPersistenceManager is based on database storage. If other storage is introduce, one just needs to provide a package of implementation of JMPXXXCommand interface. 


Figure 4-7 JBossCMP Concrete Model

Table 4-1 shows the interface method of EntityPersistenceStore, the interfaces in org.jboss.ejb.plugin.jwas package used by JAWSPersistenceManager to implementEntityPersistenceStore and the lowest level implementation of those interfaces. 

Table 4-1 JWAS implementation mapping with EntityPersistenceStore

Method in  EntityPersistenceStore	Interface name	Implemenation name	Function
createEntity	JMPCreateEntityCommand	JDBCCreateEntityCommand	called when an entity is to be created
findEntity	JMPFindEntityCommand	JDBCFindEntityCommand	called when a single entity is to be found
findEntities	JMPFindEntitiesCommand	JDBCFindEntitiesCommand	called when a collection of entities is to be found
activateEntity	JMPActivateEntityCommand	JDBCActivateEntityCommand	called when an entity should be activated
loadEntity	JMPLoadEntityCommand	JDBCLaodEntityCommand	called when an entity needs to be loaded from the underlying storage
loadEntities	JMPLoadEntitesCommand	JDBCLoadEntitesCommand	called when a set of entities should be preloaded from the underlying storage
storeEntity	JMPStoreEntityCommand	JDBCStoreEntityCommand	called when an entity needs to be written to the underlying store
passivateEntity	JMPPassivateEntityCommand	JDBCPassivateEntityCommand	called when an entity is to be passivated
removeEntity	JMPRemoveEntityCommand	JDBCRemoveEntityCommand	called when an entity should be removed from the underlying storage

4.4 JBoss Transaction Management Concrete Model

Figure 4-8 shows the JBossTx dependency and inherency diagram we got from Together5.5. By far, it is not so surprised to see the unexpected components and depencency from the UML diagram. Again we arraged the relationship and highlights the key componments and relationship between them to sythesize the concrete model.

Figure 4-8 JBossTx dependency and inherency diagram

4.4.1 Unexpected Components and Dependency

As we mentioned in JBossTx conceptual model, JBossTx is implemented as a MBean and exposed over RMI. The propagation of transaction context over RMI/JRMP is designed into two interface, TransactionPropagationContextImpoter interface, whose implementations are used for importing a transaction propagation context into the transaction manager andTransactionPropagationContextFactory interface, whose implementation is used for getting a transaction propagation context at the client-side. When the transaction manager is started, its primary task is to bind TransactionManager, TransactionPropagationContextImpoter, TransactionPropagationContextFactory into the well-known JNDI location.

TxManager implements the javax.transaction.TransactionManager and the above two interface. It is managed by the TransactionManagerService. TxManager depends on TransactionImplto perform the transactional operations such as decarerating the transaction with begin, commit, rollback method. Interestingly, TransactionImpl is just a lightweigh frontend of TxCapsule. The operation in TxCapsule is controlled based on the method invoked in TransactionImpl. TxCapsule holds all the information relevant to a transaction. Callbacks and synchronizations are done in this class. It depneds on XidImpl to identify transactions.

Recall the conceptual model with bean mamaged JTA transaction in session bean. In this model, javax.transaction.UserTransaction is needed. JBossTx has a subsystem to implements UserTransaction interface in package org.jboss.tm.usertx. Usertx is divided into two subsystems, client and server and they interact through interface. It is a pure layered architecture. ClientUserTransaction is the client-side UserTransaction implementation. It will delegate all UserTransaction calls to the server throughUserTransactionSession interface. UserTransactionSessionImpl implements UserTransactionSession in the server side. It is for the remote client whose VM is not at the same location as the transaction mananger. With the clients which operates in the same VM as the server, ServerVMClientUserTransaction is the client-side UserTransactionimplementation that delegates all UserTransaction calls to the TransactionManager of the server. Like almost every service in JBoss, UserTransaction implementation is managed as a MBean. It is bound to the JNDI location with JNDI name UserTransaction. 

Figure 4-9 JBossTx Concrete Model

---

5. Evolvability of JBoss Architecture

From above discussion of JBoss architecture, we can see that JBoss has two significant features on its architecture design. One is use JMX as the software bus to vehicle all the services. It is easy to extend the existing services by hooking the new service components compliant to the JMX specification. Plugable framework is widely used in each of the service implementation. Developers can tailor their only needs of the services by writing their desired the implementation and letting the JBoss server know this in the deployment description files. The other one is the container is designed with dynamic proxy mechanism. This can simplify the container implementation and developer's effor to precompile the jar files to generate the stub and skeleton codes. However it is a potential problem for performance and scalability, because we know java reflection is a litte costive. Optimization method is included in JBoss and further research need to find out when and how the optimization method works.

---

6. Conclusion

In this report, we discussed JBoss conceputal architectual model and concrete architectural model. We built a method to synthesize the concrete model by using reverse egineering tool and tracing the source code manually. We found that concrete model is substantially different from the conceptual model based on the documentation. This is because the concrete model is in the implementation level and it is more closed to the real story. It is the concrete model that release the special and ad-hoc design of JBoss application server. We tried to apply this method to COTS J2EE product. Unfortuantely, the source code is not available and reverse engineering result is not so complete thus misleading. Only the conceptual model can be compared with JBoss architectual model we got.

Although it is quite exciting to extract and analysis the JBoss architecture in the way we present in this report, this approach has its limitation. we still cannot get any conclusion of its effect on quality attributes, such as performance. This is because there is a great diversity of components and subsystem involved during the run time from the concrete model we got from static analysis. One possible solution is to instrument the source code to trace the componements involved during the run-time and measure their performance. In this way, the conceptual architectual model can be mapped to software exectution model, with the nodes representing the functional components of the software and the arcs represent control flow. The concrete architectual model can be mapped to system execution model, which represents the key computer resources as a network of queues[13]. Therefore it is feasible to evaluate the JBoss performance based on its architecture analysis. Our work on extracting JBoss architecture help us to understand the system greatly. The next step is to derive an analytical model of JBoss application based on this analysis, instrument codes to get measurements and evaluate its performance.

---

7. Reference

[1]  JBoss Home Page http://www.jboss.org/ 
[2] JBoss Documentation http://www.jboss.org/doco.jsp 
[3] JBoss Quick Techincal Overview  http://www.ejbean.com/resources/free-open/jboss.html 
[4] Prof. Richard C. Holt's Home Page http://plg.uwaterloo.ca/~holt/ 
[5] Ivan T. Bowman, Richard C. Holt and Neil V. Brewster, Linux as a Case Study: Its Extracted Software Architecture, ICSE 99, Los Angeles, May 99. 
[6] How do I deploy Enterprise JavaBean to JBoss http://otn.oracle.com/products/jdev/howtos/appservers/deploy_to_jboss.html 
[7] The art of EJB deployment   http://www.javaworld.com/javaworld/jw-08-2001/jw-0803-ejb_p.html 
[8] Superior app management with JMX  http://www.javaworld.com/javaworld/jw-06-2001/jw-0608-jmx_p.html 
[9] DynaServer: System Support for Dynamic Content Web Servers http://www.cs.rice.edu/CS/Systems/DynaServer/ 
[10] MTE Project  http://www.cmis.csiro.au/adsat/mte.htm 
[11] TogetherSoft Home Page http://www.togethersoft.de/downloads/down_index.html 
[12] David Garlan and Mary Shaw, An Introduction to Software Architecture, CMU Software Engineering Institute Technical Report, 1994 
[13] Loyd G. Williams, Connie U. Smith, Performance Evaluation of Software Architecture, WOSP 98, Santa Fe.N.M 
[14] Felix Bachman, Len Bass, Charles Buhman, Santiago Comella-Dorda, Fred Long, John Robert, Robert Seacord, Kurt Wallnau,Technical Concepts of Component-based Software Engineering, Technical Report, CMU/SEI-2000-TR-008 ESC-TR-2000-007

---

8. Data Dictionary

[J2EE]   Java 2 Enterprise Edition from Sun MicroSystem. It is a web operationg system 

[JMX]    the Java Management eXtension (TM) to offer standard interfaces to the management of its components as well as the applications deployed on it. 

[JAWS]   Just Another Web Storage 

[JCA]    The J2EE Connector Architecture 

[JNDI]   Java Naming and Directory Interface 

[RMI]   Remote Method Invocation. It is Sun's object request broker(ORB). 

[JRMP]   Java Remote Method Protocal. 

[JTA]   Java Transaction API.

---

Appendix-1

Figure Appendix-1 StatelessSessionContainer Concrete Architectual Model

Appendix-2

Figure Appendix-2 StatefulSessionContainer Concrete Architectual Model

Appendix-3