Research Project: An Analysis of JBoss Architecture

   Jenny Liu
   School of Information Technologies
   University of Sydney
   [email protected]

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

1.3 Methodology

1.4 Organization

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.

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.

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 supports hot(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.

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. The Container 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, EntityContainer and 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:

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.

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

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

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

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

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

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

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.

• Dynamic proxy based container design

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

• JRMPContainerInvoker

• EntityContainer and its Interceptors

• Dependency

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 and EntitySynchronizationInterceptor 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

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 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

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 the NamingService 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

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

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

TxManager implements the javax.transaction.TransactionManager and the above two interface. It is managed by the TransactionManagerService. TxManager depends on TransactionImpl to 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 through UserTransactionSession 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 UserTransaction implementation 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.

5. Evolvability of JBoss Architecture

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

[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

Figure Appendix-3 A COTS EJB Container Conceptual Architecture Model

---

Submitted on April 29,2002. This work is done in 15 working days. You are more than welcome to write to the author about this work. Any of your comment is greatly apprieciated.

---

© Copyright Jenny Liu, all rights reserved