Architectural Recovery

of JBoss Application Server

Mazeiar Salehie, Shimin Li, Ladan Tahvildari

Electrical and Computer Engineering University of Waterloo

Waterloo, Ontario

Technical Report UW-ECE#2005-02

February 2005

Abstract

This report addresses analysis of the architecture of an object-oriented system written in Java – JBoss Application Server. By selecting this case study, we follow two major objectives. First, we want to use object-oriented entities as building blocks of software architecture. Second, due to success of JBoss as an open source J2EE platform in the market and among developers, and its high modular and scalable design, it is an apt case study for Software Architectural Recovery.

In a nutshell, we aim to make a bridge from object-oriented system hierarchy and its design rules to generic building blocks, relations, and architectural rules in JBoss Application Server. We propose how a subset of object-oriented design rules is able to evaluate architecture of a software system in terms of maintainability and reusability. We also propose a set of hypothesis describing a lightweight methodology to express the architectural flaws of JBoss system based on source code analysis approach.

Table of Contents

Content Page 1- Overview .................................................................................................................... 1 2- Our Approach ........................................................................................................... 2

2-1- Architecture Quality Evaluation ......................................................................... 2 2-2- Tools ................................................................................................................... 4

3- JBoss Application Server ......................................................................................... 5 4- Conceptual Architecture .......................................................................................... 6

4-1- Layered architecture............................................................................................ 6 4-2- MicroKernel Layer.............................................................................................. 8 4-3- Service Layer ...................................................................................................... 8 4-4- Aspect Layer ..................................................................................................... 11 4-5- Architectural styles ........................................................................................... 12

5- Concrete Architecture ............................................................................................ 13 5-1- Clustering.......................................................................................................... 14 5-2- System flow ...................................................................................................... 17 5-3- Comparing conceptual and concrete architecture ............................................. 18

6- Architectural Flaws in JBoss ................................................................................. 18 6-1- Analyzing metrics ............................................................................................. 18 6-2- Auditing design flaws ....................................................................................... 21

7- Conclusion ............................................................................................................... 21 8- Glossary ................................................................................................................... 22 9- References................................................................................................................ 23

Table of Figures

Figure Page Figure 1- hierarchy of a large-scale object-oriented system written by Java ..................... 1 Figure 2-General view of JBoss Application Server .......................................................... 5 Figure 3- Lines of Code of top directories.......................................................................... 6 Figure 4- Top level conceptual architecture of JBoss Application Server ......................... 7 Figure 5- Conceptual architecture of JMX ......................................................................... 8 Figure 6- JBoss JNDI Naming Service module conceptual architecture.......................... 11 Figure 7- JBoss AOP conceptual architecture .................................................................. 12 Figure 8- Interceptor pattern variant implemented in EJB: container architecture .......... 13 Figure 9-A snapshot of relationships between some important subsystems of JBoss...... 13 Figure 10- All top-level projects of JBoss Application server 4.0.0 ................................ 14 Figure 11- Fan-in and Fan-out of top-level projects in Jboss ........................................... 14 Figure 12- The Contour plot of JBoss top-level projects relationship ............................. 15 Figure 13- JBoss Application Server Top-level Concrete Architecture ........................... 16 Figure 14- A typical JBoss service (MBean) life cycle .................................................... 17 Figure 15-Bootstrapping of Jboss ..................................................................................... 17 Figure 16- Depth Of Inheritance Hierarchy (DOIH) ........................................................ 18 Figure 17- Response for Class (RFC)............................................................................... 19 Figure 18- Number Of Child Classes (NOCC)................................................................. 19 Figure 19- Lack of Cohesion Of Methods ........................................................................ 20 Figure 20- Coupling Between Objects (CBO).................................................................. 21 Figure 21- determined design flaws in the JBoss architecture ......................................... 21

1

1- Overview A software architecture is a high-level description of a software system’s design, often a model of the software’s components (e.g., objects, processes, data repositories, etc.), the externally visible properties of those components, and the relationships among them [1]. The concept of software architectures has received considerable attention lately, and developers are starting to document software architectures. However, the living architecture of a software system may drift from the documented architecture if architecture changes are made during software implementation or maintenance and no similar effort is made to maintain the architecture documents. Software architecture recovery can be divided into two phases: a) identification and extraction of source code artifacts, including the architectural elements, and b) analysis of the extracted source artifacts to derive a view of the implemented architecture. The extracted source artifacts form a source model, which comprises a collection of elements (e.g., functions, files, variables, objects, etc.), a set of relations between the elements (e.g., ‘‘function calls function’’, ‘‘object A has an instance’’) and a set of attributes of these elements and relations (e.g., ‘‘function calls function N times’’) represent the system [2]. In this report we try to map object-oriented hierarchy levels with the generic architectural levels such as system, subsystem, sub-subsystem and so on. Figure 1 illustrates a generic hierarchy of an object-oriented system. Because the case study of this report is a system completely written in java, and java is a full object-oriented system, so the depicted hierarchy could be used for analyzing the architecture of JBoss. During this report we use term “module” as a general term which may refer any unit in any level of the depicted tree.

System

Package Package

ClassClass

Methods MethodsAttributes Attributes

Project Project

Figure 1- hierarchy of a large-scale object-oriented system written by Java

The organization of this report is as follows: in section 2 we have a general overview of JBoss application server and why we have chosen it as our case study. Section 3 describes our approach for analyzing the architecture of JBoss and how we want to evaluate its quality. Section 4 and 5 respectively describe conceptual and concrete architecture of the system and details of some major subsystems. Section 7 describes findings in the architecture quality assessment by considering measured metrics and

2

audits. Section 8 concludes the report and finally section 9 is a glossary of terms used during the report.

2- Our Approach In this section we describe our approach for presenting JBoss conceptual architecture, extracting Concrete architecture and how we can evaluate quality of architecture design in terms of the available metrics. At first we start with conceptual architecture which is the system architecture as-designed by designers and presented in datasheets and overviews. We try to use more documents from official website of Jboss [3] although documents of version 4.0 have not been updated yet in the web site. The second phase is extracting concrete architecture of the system. We use extract-abstract-present paradigm which is used in most of reverse engineering approaches (one of the premier work was the Rigi system [4]). We extract facts from source code and then by clustering and with the aid of conceptual information from directory structure, naming criteria and the other system artifacts abstract the system architecture and present it with a presentation tool (we will describe our tools in section 2-2). Our Clustering approach is mainly based on subsystem patterns [5] which in turn use patterns of source code, directory structure and omnipresent modules pattern [6]. We apply the clustering method on the project level of JBoss architecture and then we will compare conceptual (as-designed) and concrete (as-implemented). One of the most important parts of our work is evaluation of JBoss architecture. We selected several metrics (described in section 2-1) from three categories of complexity, coupling and cohesion [7] for this purpose. Metrics in these categories help us to measure respectively distribution of complexity among modules, quality of architecture within class and between classes.

2-1- Architecture Quality Evaluation In this section we deal with quality of Jboss application server architecture. In evaluating we do not take into account how well the architecture fulfill the requirements of the system, but we focus on design decisions which affect on some non-functional requirements such as maintainability, modularity and scalability.For this purpose we measure several metrics (more focused on architectural metrics) and audit the quality regarding some predefined design rules and hypotheses.

Metrics Quality software metrics in literature mostly established for object-oriented structure with a hierarchy consisting of attributes and methods, classes, packages and finally projects. Existing metrics have been categorized in different manners, for instance DatrixTM project [8] has four categories of routine, class, file and Halstead metrics. Borland Together [9] uses 12 categories for object-oriented metrics including some important metrics such as complexity, coupling and cohesion. In this report we more focus on architecture of the system, so metrics dealing with higher levels of the system hierarchy (in terms of figure 1) are taken into account. These metrics include coupling and complexity categories. Selected metrics are shown in the following table (table 1).

3

Table 1- Selected Metrics

Metric Name Category Definition

LCOM Lack of Cohesion Of Methods Cohesion

Measures the dissimilarity of methods in a class by its attributes. m - number of methods in a class a - number of attributes in a class mA - number of methods that access an attribute EmA - sum of mA for each attribute RESULT = 100*(EmA/a-m)/(1-m)

NOC Number Of Classes Complexity NOC counts the number of classes.

NOCC Number of Child classes Complexity NOCC counts the number of classes directly or

indirectly derived from the measured class.

DOIH1 Depth of

Inheritance Hierarchy

Complexity The length of the inheritance chain from the root of the inheritance tree to the measured class.

RFC Response For Class Complexity The size of the response set for a class includes methods in the class’s inheritance hierarchy and methods that can be invoked on other objects.

CBO Coupling between objects Coupling

Represents the number of other classes to which a class is coupled to. Counts the number of reference types that are used in attribute declarations, formal parameters, return types, throws declarations, local variables, and types from which attribute and method selections are made. Primitive types, types from java.lang package and supertypes are not counted.

CF Coupling Factor Coupling

It is calculated as a fraction. The numerator represents the number of non-inheritance couplings. The denominator is the maximum possible number of couplings in a system.

Fan-In Be accessed by Coupling Represents the number of modules which access this module.

Fan-Out Access to Coupling Represents the number of modules which this module access to.

FO Fan Out (in low level) Coupling

FO counts the number of reference types that are used in attribute declarations, formal parameters, return types, throws declarations and local variables.

NOIS Number Of Import Statements Coupling

Counts the number of imported packages/classes. This measure can highlight excessive importing and can also be used as a measure of coupling.

We will use above metrics in various levels of granularity; classes and packages and clusters.

Design flaws We are looking for detecting architectural flaws using object-oriented design heuristics and rules. There is a set of well-known design flaws in object-oriented systems which in this report regarding to our goals of analyzing software architecture, we address a subset of them. The following table (table 2) shows our selected design flaws. We used two criteria for selecting these flaws: 1) how much the definition of design flaw is related to

1 Some researchers call it DIT (Depth of Inheritance) metric (i.e. in [10])

4

the system architecture, and 2) how much refactorings suggested for each flaw are related to the system architecture?

Table 2 – selected object-oriented design flaws

Design Flaw Category Level Definition

Shotgun Surgery Coupling Class level

This is one of the “bad smells” of a design in [11] and it means every time you make a change in a class; you have to make many, tiny changes in lots of different classes.

Feature Envy [11] Cohesion Method

level Often a method that seems more interested in a class other than the one it's actually in.

God Method [11] Complexity Method

level one method is used more extensively than others

God Class [12] Complexity Class level one class is used more extensively than others

Data Class [12]

Data abstraction Class level Classes with fields and getters and setters and nothing else

Refused Bequest [11]

Data abstraction Class level Subclasses don't want or need everything they inherit.

In section 6, we will investigate whether these flaws have been appeared in the architecture of our case study -JBoss application server- or not. We use Together auditing feature for mentioned design flaws. We will also use some more architectural rules for selected metrics.

2-2- Tools There exist many source model extraction tools, such as LSME [13] and ManSART [14] that parse code fragments and extract source model elements, relations and attributes. Tools that use relational algebra to infer new facts from existing facts, such as Grok [15], can be used to manipulate and analyze source model artifacts. Tools for extracting and analyzing software architectures, such as Rigi [16] and SAAMTool [17], provide not only visualization but also manipulation mechanisms to help the user simplify and navigate through the visual system representation. However, each individual tool or system has its limitations and restrictions in terms of the architecture recovery phases it covers, its support for applications developed in different programming languages and its flexibility in supporting customized analysis. Because Jboss application server is completely developed with Java, we used Creole plug-in for Eclipse [18] for visualization extracted facts by FEAT [19]. Creole uses a working set which in turn can be consisted of several projects and packages. Because Jboss source code consists of several projects, we load them in a working set in order to analyze intra-project and intra-package dependencies. We also used Borland TogetherTM for eclipse [9] for quality assurance to measure metrics and audit design flaws in the Jboss architecture. We used Jprobe profilerTM [20] to analyze runtime dependency and flow of the system during operation. Jprobe runs Jboss Application Server and monitors what happened between subsystems and monitors memory consumption and other performance-related issues.

5

3- JBoss Application Server JBoss is an Open Source, standards-compliant, application server implemented in Java and distributed for free under the LGPL license. It is the most downloaded web-app server in the world based on the J2EE specification. JBoss is developed around the world by java middleware professionals organized by the JBoss Group. JBoss was started in 1999 as an open source EJB container. JBoss 2.x was a full J2EE based server. The 3.x series is the production series. JBoss is a full framework for J2EE developers to build their own applications. It is based on a full microkernel (JMX) and service oriented architecture (SOA). The Latest version of JBoss Application Server is version 4.0 which is released on June 2003. Version 4.0 provides an expansive range of services that were previously unavailable in any J2EE application server. The new services are enabled by the Java application server industry’s first implementation of an aspect-oriented programming (AOP) framework. The framework allows developers to interact with the server in a very intuitive manner, making it much easier to design, develop, deploy and maintain enterprise web applications. JBoss 4.0 supports standards: J2EE 1.4, JMS 1.1, JCA 1.5, JACC, and EJB 2.1 [21]. JBoss application server is a part of what we call middle-tier, between the end user-tier and the primary services (see figure 2). This software uses the industry standard Java Management eXtention (JMX) to manage the JBoss components as well as provide services such as identification, authentication, authorization, directories, and security. JBoss’ architecture is highly modular and plug-in design. JMX offers standard interfaces to the management of its components as well as the applications deployed on it. The clients connect to the JMX node through any protocol ports, IIOP, JRMP, WebServices, and all invocations are forwarded to the MBean in the JMX codebase thereby allowing the user to build EJBs that can be accessible through any port.

JBoss Application Server

Web Container

EJB Container

Other System

JCA

Database

Data Flow Component

Java Client

Keys:

Web Client

JDBC

CORBA Client

Web Service Client

request

request

request

request

request

request

response

response

response

response

response

response

Figure 2-General view of JBoss Application Server

We chose JBoss application server as our case study because: 1) JBoss is an open source application server which means that the source code is available for us to take a look at. 2) JBoss is also a very popular application server. 3) The main reason is that we are very

6

interested in how the JBoss group has built a microkernel and then plugged-in modules into this small microkernel to finally get an application server which implements the full J2EE stack. It also provides a very simple mechanism for plugging-in custom services into the server as well as take out unwanted ones. 4) JBoss is huge enough to be an interested case for analyzing the architecture. Table 3 shows size and number of files in the Jboss source code.

Table 3- JBoss source code size

KLOC Number of .Java files Number of classes JBoss Application Server V 4.0 952 6058 4892

Figure 3 illustrates lines of codes metric of top-level directories which are in fact top-level projects2.

Lines of Code

0

10

20

30

40

50

60

70

80

90

100

110

120

aop

aspe

ctsca

che

cluste

r

common

conn

ector

Deploy

mentj2e

ejax

rpc

jms

jmx

jmx-r

emoti

ng

manage

ment

messag

ing

naming

remoti

ng

secu

rity

syste

m

transa

ction

webse

rvice

serve

r

jboss

.net

hiberna

te

tomcat

cons

ole iiop

media varia

Thou

sand

s

Figure 3- Lines of Code of top directories

Due to above reasons we think that JBoss is an appropriate case study for analyzing the architecture and moreover evaluating quality of the architecture design.

4- Conceptual Architecture JBoss Application Server is a standards-based, J2EE platform that is free to use regardless of the size of the application deployment and regardless of whether the application user is an end-user or an independent software vendor. In this section we present the conceptual architecture of Jboss using available documents and release notes.

4-1- Layered architecture By studying the JBoss release note, datasheet, and other documentations in [3], we conclude that the top level conceptual architecture of JBoss Application Server is a layered and it can be divided into four primary layers (see Figure 4):

2 “ThirdParty” directory is not shown here because Jboss uses JAR files of components from Apache, IBM… in this directory

7

Microkernel Layer

JMX

Aspect Layer

ApplicationLayer

Service Layer

User Applications

Aspect-Oriented Programming Model

EJB Container

Web Container & Services

DB Server

Messaging

Naming

Transaction

Security

Cluster

Cache

CORBA Adaptor

Management

Figure 4- Top level conceptual architecture of JBoss Application Server

Microkernel Layer: It is the core of JBoss Application Server. By utilizing Java Management Extensions (JMX), the microkernel delivers a lightweight component model that offers hot deployment and advanced class-loading features and full lifecycle management. Service Layer: On top of the microkernel resides the service layer. The service layer extends and refines the JMX model to address some issues beyond the scope of JMX: service lifecycle, dependencies between services, deployment and redeployment of services, dynamic configuration and reconfiguration of services, and component packaging. It consists of a series of services such as EJB Container, JSP and Servlet container, Database Server, Messaging, etc. Each of these services is neatly packaged and fully hot-deployable. Users can easily add new services or remove unnecessary services from their deployments to reduce the overall footprint and improve performance [22]. Aspect Layer: The aspect layer is based on the Aspect-Oriented Programming (AOP) model that enables JBoss to provide a wide range of services including object persistence, caching, replication, acidity, remoteness, transactions, and security. The AOP framework allows users to write Plain Old Java Objects (POJO) and apply these enterprise-level services later on in the development cycle without having to change a line of Java code. The AOP capabilities in JBoss 4.0 build on the interceptor model (described in section 4-5) popular in previous versions. JBossAOP extends this capability beyond just EJBs to any POJO. Application Layer: This is where users’ applications live. The applications can greatly leverage the vast infrastructure capabilities of JBoss regardless of whether users utilize the container services directly (programmatically) or by using the AOP layer and tag-driven aspects to add behaviors to objects.

8

In the following sections we describe above aforementioned layers in more details.

4-2- MicroKernel Layer The JMX has a layered architecture (see Figure 5). It consists of three layers: the instrumentation layer, the agent layer, and the distributed services layer [23].

Agent Layer

Distribution Service Layer

MBean Server

Connector (as MBean)

Protocol Adaptor

(as MBean)

Agent Service

(as MBean)

Agent Service

(as MBean)

Instrumentation Layer Managed

Resource (as MBean)

Managed Resource

(as MBean)

Figure 5- Conceptual architecture of JMX

Instrumentation layer: It defines how to instrument resources so that they can be monitored and manipulated by (possibly remote) management applications. The instrumentation of a given resource is provided by one or more managed beans (MBeans), Java objects that conform to certain conventions and expose a management interface to their clients. Agent layer: It defines an agent that manages the set of instrumented resources within a Java virtual machine, in behalf of (possibly remote) management applications. The JMX agent consists of an in-process server, the MBean server, plus a standardized set of agent services: dynamic class loading, monitoring, timer service, and relation service. Agent services are implemented as MBeans; this makes them manageable through the MBean server, like user resources. Distributed services layer: It specifies how management applications interact with remote JMX agents and how agent-to-agent communication takes place. It consists of connectors and protocol adaptors, implemented as MBeans.

4-3- Service Layer In this section we briefly review service layer subsystems which in turn are projects in the system hierarchy.

9

Management JBossMGT project makes JBoss Server and its components manageable in a JSR-88 compliant fashion (see glossary for more details) and also creates a JSR-88 compliant management client allowing the administrators to manage any JSR-88 enabled application servers.

WebSys (Web Container and Services) This subsystem encompasses web container for servlets and JSP pages, and supports web services. The following list describes the main modules.

TomCat: Tomcat is the servlet container that is used in the official Reference Implementation for the Java Servlet and JavaServer Pages technologies.

JAX-RPC: Java API for XML-based RPC (JAX-RPC). It enables Java technology developers to develop SOAP based interoperable and portable web services.

Webservice: There are two implementations of webservices in JBoss 4.0 Application server: JbossWS (in project webservice in the directory structure) and Jboss.Net. They cannot be used simultaneously and a developer must remove one of them to install the other one. The following description is adopted directly from released source code of Jboss 4.0.

• JBossWS: This is the J2EE-1.4 compatible web service implementation in JBoss. It is installed in the all and default configuration. This implementation will be developed further and eventually replace JBoss.NET

• JBoss.NET: This is an early jboss web service project which is really integrated Axis and jUDDI projects from Apache group. It is now a default project in Jboss 4.0.

Remoting The JBoss Remoting (JBR) framework is a core JBoss component that provides a light-weight building block API for constructing network aware services. The JBR package namespace is org.jboss.remoting and part of the jboss-remoting CVS module. The JBR framework provides no particular remoting service alone; however, it does provide a set of interfaces and classes for easily building network aware services. For example, the JMX component uses JBR to provide JMX Remoting services, making MBeans accessible and transportable within a JBoss networked environment.

Cluster JBossClustering is the final piece of the puzzle that makes JBoss a true Enterprise-Class Application Server. With its fail-over, load-balancing, and distributed deployment features, JBossClustering provides the means to develop large scalable robust applications.

Cache JBoss Cache (called JbossCache) is a replicated and transactional cache that allows you to cache data from Enterprise Applications in order to dramatically improve performance.

10

The caching data is replicated automatically allowing you to easily cluster data across a grid of JBoss servers. JBossCache can run as an MBean service within JBoss Application Server or other J2EE containers. JBossCache consists of two modules: 1) Tree Cache: a replicated transactional tree-structured cache. 2) Tree Cache AOP: an "object-oriented" cache using AOP to dynamically manage Plain Old Java Objects (POJOs).

CORBA-Adaptor CORBA-Adapter supports CORBA/IIOP access to enterprise beans deployed in a JBoss server, as defined by the EJB 2.0 specification. It makes enterprise bean methods available to both 1) RMI/IIOP clients written in Java and 2) CORBA clients written in Java, C++, or other languages.

Security Security subsystem (called JBossSX) Implements standard J2EE Authentication and Authorization (JAAS) but also supports extended security models to provide support for context-sensitive authorization (e.g. trades cannot be executed after 4:30pm EST). Support for Pluggable Authentication Modules (PAMs) allow you to integrate with existing authentication frameworks in your enterprise.

Connector Connector (called JCA) is a clean room implementation of the J2EE Connector API part of the J2EE specification. JCA handles the deployment of resource adapters. These include DataSources and ConnectionFactorys and MessageListeners to and from databases, legacy systems or JMS Servers.

Transaction Transaction subsystem implements Java Transaction API (JTA) from J2EE. JTA specifies standard Java interfaces between a transaction manager and the parties involved in a distributed transaction system: the resource manager, the application server, and the transactional applications.

Database server JBoss database server (Hibernate) is a powerful, high performance object/relational persistence and query service for Java. The Hibernate Query Language, designed as a "minimal" object-oriented extension to SQL, provides an elegant bridge between the object and relational worlds.

Naming The JBoss JNDI naming service is a Java socket/RMI based implementation of the javax.naming.Context and javax.naming.Name interfaces. It is a client/server implementation that can be accessed remotely. The implementation is optimized so that access from within the same VM in which the JBossNS server is running does not involve sockets. Same VM access occurs through an object reference available as a global singleton. Figure 6 illustrates the conceptual architecture of JBoss JNDI naming service module.

11

Server

Interface

Main (as MBean)

NamingContextFactory Naming

NamingContext

NamingServer (as MBean)

Figure 6- JBoss JNDI Naming Service module conceptual architecture

Main: It is implemented as an MBean and performs the following tasks: instantiates a NamingService instance and sets this as the local VM server instance; exports the NamingServer instance's Naming RMI interface; creates a socket that listens on the interface given by Naming; and spawns a thread to accept connections on the socket. NamingServer: It is an MBean that delegates its functionality to Main MBean. The reason for the duplicate MBeans is because JBossNS is started out as a stand-alone JNDI implementation, and can still be run as such. The NamingService MBean embeds the Main instance into the JBoss server so that usage of JNDI with the same VM as the JBoss server does not incur any socket overhead. NamingContext: It is the interface for clients to interact with a naming service. NamingContext implements the Context interface and delegates all operations to the Naming instance associated with it. NamingContextFactory: It is responsible for creating a NamingContext object with the environment properties of a naming service established with whom the client wants to communicate. Naming: it is the implementation of Java Naming and Directory Interface (JNDI) API.

4-4- Aspect Layer The JBoss 4.0 AOP framework is the generalization of the JBoss Container with the Interceptors providing the aspect of a method call. It allows developers to quickly and easily apply services such as transactions, persistence, remoteness and cache replication without creating EJBs. They simply code or reuse plain Java objects, classes or dynamic proxies and can subsequently apply higher level services. A management console allows users to view classes that have been loaded by the AOP framework, as well as their interceptor chains, introductions, pointcuts and associated metadata. Figure 7 illustrates the conceptual architecture of JBoss AOP.

12

Console

Class Manager

Unified Class Loader

(as MBean)

Aspects Weaver

Interceptor Stack

POJO

Figure 7- JBoss AOP conceptual architecture

POJO: it is a kind of Plain Old Java Objects which has not been written for J2EE. Aspects Weaver: It is responsible for automatically combining the separate descriptions, which are used to express each of a system’s aspects of concern, into a final executable form. Interceptor Stack: It is a stack of stateless components in which every call proceeds through the stack from first to last, until finally the target is called. After the target is finished with its method, the call will unwind through the stack in reverse order. Hence, it can be viewed as a pattern for intercepting calls. Console: It allows users to view classes that have been loaded by the AOP framework, as well as their interceptor chains, introductions, point-cuts and associated metadata. Class Manager: It manages the classes that have been loaded by the AOP framework and provides an interface for Console to view the class information. Unified Class Loader: It is an MBean as well as used as the MBean Classloader and is responsible for deploying multiple applications.

4-5- Architectural styles As we discussed earlier in section 4-5 this system designed in a layered model. In this section we discuss on the other architectural patterns of JBoss application server. Plug-in centric architecture: Each service module sitting in the service layer of JBoss application server can be viewed as a plug-in of the JMX Microkernel. This architecture style and the interceptor architecture implemented in EJB container form the base of JBoss hot deployment. Interceptor: Inceptor is an architectural pattern that allows services to be added transparently to a framework and triggered automatically when certain events occurs [24] (see figure 8). In particular, this pattern was applied in developing Enterprise Java Bean servers such as JBoss. Application developers can focus on application-specific business

13

logic. Besides, the pattern also makes services to be added transparently to the server. Flexibility and extensibility of the server increased.

Figure 8- Interceptor pattern variant implemented in EJB: container architecture. [24]

5- Concrete Architecture In this section we deal with concrete architecture of JBoss as-implemented. Due to the huge size of JBoss, we incrementally added subsystems to Creole to extract facts and visualize subsystems and relationships among them. Figure 9 shows the snapshot of some major subsystems visualized by Creole.

Figure 9-A snapshot of relationships between some important subsystems of JBoss

Figure 10 depicts all of the top-level projects. Unfortunately Creole couldn’t handle this diagram and crashed after more than 24 hours processing. This figure is too messy especially around JMX, J2EE, System, Server and common modules.

14

Figure 10- All top-level projects of JBoss Application server 4.0.0

The above two figures are only the raw picture of the concrete architecture. For better analysis we should cluster architecture entities to better understand hierarchy of the system.

5-1- Clustering We want to cluster the JBoss top-level projects by the approach we mentioned in section 2. First we analyze relation between top-level projects. We measured fan-in and fan-out of the major top-level projects in JBoss, and as you can see in figure 11, server has the highest number of fan-out and so is more dependent to other top-level projects.

Fan-in and Fan-out

0

200

400

600

800

1000

1200

Naming

Securi

tyAOP

common

System

JMS

J2EE

Trans.

JMX

Cache

Cluster

Server

Aspec

ts

Deploy

.

Remoti

ng

Messa

ging

Manage

ment

Fan In

Fan Out

Figure 11- Fan-in and Fan-out of top-level projects in Jboss

Figure 12 illustrates the relationship matrix of most of the top-level projects in JBoss using a contour plot. This plot shows the number of access from modules on the horizontal axis to modules on the vertical axis. As the figure depicts, many modules use

15

“common” module and regarding to patterns in [5] (Omnipresent pattern), common is kind of a library.

Nam

ing

Secu

rity

AOP

com

mon

Syst

em JMS

J2EE

Tran

s.

JMX

Cac

he

Clu

ster

Serv

er

Aspe

cts

Dep

loy.

Rem

otin

g

Mes

sagi

ng

Man

agem

ent

Naming

Security

Aop

Common

System

JMS

J2EE

Transaction

JMX

Cache

Cluster

Server

Aspects

Deployment

Remoting

Messaging

Management

2-3

1-2

0-1

Figure 12- The Contour plot of JBoss top-level projects relationship (in logarithmic scale)

In order to extract top-level subsystems of JBoss concrete architecture, we cluster the JBoss source code packages into 17 subsystems. Figure 13 illustrates the result of clustering applied on JBoss top-level projects.

16

Figure 13- JBoss Application Server Top-level Concrete Architecture

Directories of Jboss Application server v. 4.0 are different Java projects most of them have the name of major subsystem aforementioned in the conceptual architecture. So, first we apply the directory structure pattern to cluster each of packages whose functionality is a complete JBoss application server service into an individual subsystem, For instance, naming, transaction, and security subsystems. Then we group the related packages into a single subsystem according to support library pattern and central dispatcher pattern, for instance, microKernel, library, and webSys subsystems. Table 4 shows the members of each cluster shown in figure 13.

Table 4- shows the packages in each of these subsystems.

Subsystems JBoss source code packages microKernel jmx, system library common, tools, thirdparty, media, varia deployment deployment databaseSys hibernate CORBA-Adaptor iiop security security naming naming cache cache ejbContainer server, j2ee transaction transaction webSys webservice, jboss.net, jaxrpc, tomcat remotingSys remoting, jmx-remoting management console, management messageSys jms, messaging connector connector cluster cluster aopSys aop, aspects

17

5-2- System flow JBoss application server is a complex system and analyzing its system flow takes too much time and needs lots of figures and descriptions. So, here we suffice to discuss about a typical JBoss service (MBean). JBoss 4.0 enables hot deployment of services and applications. Components, EJBs, applications, database connections, AOP constructs, and even plain JAR files can be deployed, undeployed and redeployed at runtime. This enables a quick development cycle because the application server does not need to be restarted, and provides 24/7 availability because new application versions can be cycled at runtime. Figure 14 illustrates the lifecycle of JBoss services. When applications are going to be deployed, the JBoss deployment scanner examines what kind of services are needed and the JMX Microkernel automatically deploys the needed services according the deployment flow showed in figure 14. If the deployed application is updated, it can be redeployed without restarting the application server. In this case, newly needed JBoss services are deployed, and such services that the updated application does not need any more are undeployed automatically.

D e p lo y

C re a te /R e g is te rM B e a n

s e tA ttr ib u te s

c re a te () s ta r t () s to p () d e s tro y ()

u n re g is te rM B e a n

U n d e p lo y

L o o p

Figure 14- A typical JBoss service (MBean) life cycle

It is interesting to know that JBoss major modules also load like a hot-deploy service. Analyzing call graphs in JProbe shows that “system” provides a JMX microkernel-based bootstrap service and deployment service (see figure 15). After that all the other modules such as security, cluster, cache, etc will be loaded.

Access to “System”

“Deployment”

Figure 15-Bootstrapping of Jboss

Due to variety of services in JBoss, extracting a comprehensive data flow of the system by JProbe takes a considerable time. We think that extracting concrete architecture of a system relay needs monitoring the dynamic behavior and call graph when it operates in its environment.

18

5-3- Comparing conceptual and concrete architecture Both conceptual architecture and concrete architecture of JBoss 4.0 application server show that it has a layer top-level architecture. We find some unexpected dependencies between the AOP layer and the Micro-Kernel layer in the concrete architecture. There are many additional dependencies among the service modules at the service layer in the extracted as well.

6- Architectural Flaws in JBoss In this section we analyze quality of the JBoss architecture in terms of metrics and design rules described in section 2-1.

6-1- Analyzing metrics Basili et al. [10] drew up six hypotheses (one for each metric) that represent the expected connection between the metrics and the fault-proneness of the code. They tested these hypotheses and found that some of the metrics were very good predictors, while others were not. Ferenc et al. [25] used these hypotheses for analyzing architectural design changes during evolution of Mozilla. We use these hypotheses for evaluating architecture quality of Jboss. DOIH hypothesis: “A class located deeper in a class inheritance lattice is supposed to be more fault-prone because the class inherits a large number of definitions from its ancestors.” The DOIH was found to be very significant in [10], which means that the larger the DOIH, the larger the probability of fault-proneness. TogetherTM puts a threshold value 5 for this metric and as you can see in figure 16, DOIH values for cache, common, JaxRPC, JMX and webservice modules are beyond 5. So due to the complexity of these modules, they are more fault prone.

Figure 16- Depth Of Inheritance Hierarchy (DOIH)

Depth Of Inheritance Hierarchy

0

1

2

3

4

5

6

7

8

aop

aspectscach

ecluster

common

connector

Deployment

j2eejaxrp

c jms

jmx

jmx-r

emoting

management

messag ing

naming

remoting

security

system

transacti

on

webservice

19

RFC hypothesis: “Classes with larger response sets implement more complex functionalities and are, therefore, more fault-prone.” The RFC was shown to be very significant in [10] and the larger the RFC, the larger the probability of fault-proneness. It can be justified because a class, which provides a larger response set, is considered to be more complex and require more effort in testing than one with a smaller overall design complexity. TogetherTM puts a threshold value 50 for this metric and as figure 17 shows majority of top-level project have an RFC value more than 50.

Res pons e For C las s

0

100

200

300

400

500

600

700

800

900

1 000

aop

aspe

cts

cach

e

clus

ter

com

mon

conn

ecto

r

Dep

loym

ent

j2ee

jaxr

pc jms

jmx

jmx-

rem

otin

g

man

agem

ent

mes

sagi

ng

nam

ing

rem

otin

g

secu

rity

syst

em

trans

actio

n

web

serv

ice

serv

er

jbos

s.ne

t

hibe

rnat

e

tom

cat

cons

ole

iiop

med

ia

varia

Figure 17- Response for Class (RFC)

NOCC hypothesis: “We expect classes with large number of children to be more fault-prone.” The NOCC appeared to be very significant but the observed trend is contrary to what was stated by the hypothesis. The larger the NOCC the lower the probability of fault-proneness [10]. Measured values for this metric in TogetherTM has been depicted in figure 18.

Number Of Child Classes

0

10

20

30

40

50

60

70

80

90

aop

aspe

cts

cach

e

clus

ter

com

mon

conn

ecto

r

Dep

loym

ent

j2ee

jaxr

pc jms

jmx

jmx-

rem

otin

g

man

agem

ent

mes

sagi

ng

nam

ing

rem

otin

g

secu

rity

syst

em

trans

actio

n

web

serv

ice

serv

er

jbos

s.ne

t

hibe

rnat

e

tom

cat

cons

ole

iiop

med

ia

varia

Figure 18- Number Of Child Classes (NOCC)

20

LCOM 3 hypothesis: “Classes with low cohesion among its methods suggests an inappropriate design which is likely to be more fault-prone.” The LCOM was stated to be insignificant in [10], but a low value of LCOM can indicate good class subdivision, implying simplicity and high reusability. A high lacking of cohesion increases complexity, thereby increasing the likelihood of errors during the development process. According to the hypothesis we can see in figure 19 that J2EE and deployment subsystems are rather poorly designed regarding to this metric.

Lack of Cohesion Of Methods

75

80

85

90

95

100

105

aop

aspe

ctsca

che

cluste

r

common

conn

ector

Deploy

mentj2ee

jaxrpc

jms

jmx

jmx-r

emoti

ng

manage

ment

messa

ging

naming

remoti

ng

secu

rity

syste

m

trans

actio

n

webse

rvice

LCOM3

Figure 19- Lack of Cohesion Of Methods

CBO hypothesis: “Highly coupled classes are more fault-prone than weakly coupled classes.” The CBO was said to be significant in [10]. Excessive coupling between objects is detrimental to modular design and prevents reuse. In order to improve modularity and promote encapsulation, inter-object class coupling should be kept to a minimum. The larger the number of coupling, the higher the sensitivity to changes in other parts of the design, and therefore maintenance is more difficult. A measure of coupling is useful to determine how complex the testing of various parts of a design is likely to be. The higher the inter-object class coupling, the more rigorous the testing needs to be. According to figure 20 modules Aop, cache, connector, jaxRPC, JMX, messaging, naming, Security, system and webservice projects violate the threshold value 30 determined by TogetherTM. By regarding this point that CBO has been measured inside each of these projects not among projects, we can say the aforementioned projects especially aop, jaxRPC and JMX are fault-prone.

3 TogetherTM calculates 3 types of LCOM, and here we use LCOM3 with the definition given in table 1.

21

Figure 20- Coupling Between Objects (CBO)

6-2- Auditing design flaws In this section, we determine which design flaws can be determined in the JBoss architecture regarding to selected flaws in section 2-1. We used Borland Together for Eclipse to audit design flaws of JBoss top-level projects. Figure 21 illustrates number of flaws detected in a major set of JBoss application server.

JBoss Architecture design flaws

0

20

40

60

80

100

120

140

AOP

Aspec

ts

Cache

Cluster

Connec

torJ2

EE

JaxR

PCJM

SJM

X

Manag

emen

t

Shotgun SurgeryFeature EnvyGod MethodGod ClassData ClassRefused Bequest

Figure 21- determined design flaws in the JBoss architecture

Modules JaxRPC, AOP and JMX show remarkable values for the selected design flaws. It can be natural for AOP, because it has been added in version 4.0, but the other two modules are not new. High number of Shotgun surgery flaw in a module can increase architecture maintainability cost, because few changes need lots of changes in lots of different classes.

7- Conclusion In this report, we discussed conceptual and concrete architecture of the JBoss 4.0 application server. We presented the conceptual architecture by studying JBoss release

Coupling Between Objects (CBO)

0

10

20

30

40

50

60

70

80

90

aop

aspe

ctsca

che

cluste

r

common

conn

ector

Deploy

mentj2ee

jaxrpc

jms

jmx

jmx-r

emoti

ng

manage

ment

messa

ging

naming

remoti

ng

secu

rity

syste

m

trans

actio

n

webse

rvice

22

note, datasheet, and other documentations related to its application, evolution, and evaluation. We extracted the concrete architecture using a set of reverse engineering tools. We found that concrete architecture is slightly different from the conceptual architecture. We evaluated JBoss architecture using a set of metrics and auditing it to find a defined collection of design flaws. Results of theses assessments showed us some modules should be refactored to increase maintainability of the system. For instance “shotgun surgery” flaw is considerable in two modules (AOP and JaxRPC) which could increase cost of system evolution and maintainability. In this report we tried to find out whether JBoss is really designed for change and how much tough its evolution is.

8- Glossary AOP - Aspect-Oriented Programming AXIS - Apache Axis is an implementation of the SOAP ("Simple Object Access Protocol") EJB - Enterprise Java Beans. Reusable and portable software components that model business objects and processes. EJBs can run on any EJB enterprise server. The server takes care of issues such as object persistence, security and transaction management. The EJB 2.0 specification defines three different types of Enterprise Java Beans: entity beans, session beans and message driven beans. IIOP - Internet Inter-ORB Protocol: the standard protocol that specifies how web-objects communicate across TCP/IP networks. Internet Inter-ORB Protocol. An object-oriented protocol that allows distributed programs written in different programming languages to communicate over the Internet. IIOP is a critical part of CORBA. Using CORBA IIOP and related protocols, a company can write programs that can communicate with other programs wherever located and without having to understand anything about the other programs except their services and names. JAXRPC- Java API for XML-based RPC (JAX-RPC). It enables Java technology developers to develop SOAP based interoperable and portable web services. JCA – J2EE Connector Architecture JMS - Java Message Service: An interface implemented by most J2EE containers to provide point-to-point queueing and topic (publish/subscribe) behavior. JMS is frequently used by EJB's that need to start another process asynchronously. For example, instead of sending an email directly from an Enterprise JavaBean, the bean may choose to put the message onto a JMS queue to be handled by a Message-Driven Bean (another type of EJB) or another system in the enterprise. This technique allows the EJB to return to handling requests immediately instead of waiting for a potentially lengthy process to complete. The J2EE sample application included in Out-of-the-Box Enterprise Edition implements precisely this scenario. JBoss-4.x supports the JMS1.1 version of the spec.

23

JMX - Java Management eXtension. It allows developer to expose a management interface of their Java classes as well as clients to manage these Java classes through the management interface. The management interface is called MBean and does not necessary have to be part of the Java class it is defined for. But the real power behind JMX is that it enables developers to create dynamic applications because the references to a MBean called ObjectName is resolved every time a call is made. Therefore when a MBean instance is replaced at runtime the client will immediately call the new MBean instead of the old one. In JBoss we talk about the Communication Bus between modules using JMX. JNDI – Java Naming and Directory Interface JRMP – Java Remote Method Protocol JSR-88 - The JSR-88 specification defines a management information model called the J2EE Management Model for the J2EE platform. The J2EE Management Model is a specification of the attributes, operations, and architecture of the managed objects required by compliant J2EE platform implementations. This model is inter-operable with a variety of industry standard management systems and protocols. It also provides standard mappings of the model to the Management Information Base (J2EE MIB) and to a Java API as a server resident EJB component. JTA – Java Transaction API jUDDI - (pronounced "Judy") is an open source Java implementation of the Universal Description, Discovery, and Integration (UDDI) specification for Web Services. POJO - Plain Old Java Objects Tomcat - Tomcat is the servlet container that is used in the official Reference Implementation for the Java Servlet and JavaServer Pages technologies. The Java Servlet and JavaServer Pages specifications are developed by Sun under the Java Community Process. Tomcat is developed in an open and participatory environment and released under the Apache Software License.

9- References [1] Bass L., Clements P., Kazman R., Software Architecture in Practice, Addison-Wesley, 1998 [2] Kazman, R., Carrière, S. J., View Extraction and View Fusion in Architectural Understanding, Fifth

International Conference on Software Reuse, pp. 290-299, 1998 [3] Jboss project official site, www.jboss.org [4] H. A. M¨uller, D. Notkin, and K. Sullivan, “Rigi – a system for programming in-the-large,” in Proc.

International Conference on Software Engineering (ICSE), Raffles City, Singapore, pp. 80–86, Apr. 1988,.

[5] V. Tzerpos and R. C. Holt, “ACDC: An algorithm for comprehension driven clustering,” In Proceedings of the Working Conference in Reverse Engineering (WCRE’00), 2000.

[6] Hausi A. Muller, Mehmet A. Orgun, Scott R. Tilley and James S. Uhl., “A reverse engineering approach to subsystem structure identification,” Journal of Software Maintenance Research and Practice, 5:181-204, December 1993

24

[7] Ladan Tahvildari, Ajit Singh, "Categorization of Object-Oriented Software Metrics", In Proceedings of the IEEE Canadian Conference on Electrical and Computer Engineering, Halifax, Canada, pages 235-239, May 2000.

[8] Datrix metric reference manual, version 4, Bell Canada, 1999 [9] Borland together for eclipse, version 6.3, 2004, www.borland.com [10] V. R. Basili, L. C. Briand, and W. L. Melo, “A Validation of Object-Oriented Design Metrics as

Quality Indicators,” In IEEE Transactions on Software Engineering, volume 22, pages 751–761, Oct. 1996.

[11] M. Fowler, K. Beck, J. Brant, W. Opdyke, and D. Roberts., Refactoring: Improving the Design of Existing Code, Addison-Wesley, 1999.

[12] A.J. Riel, Object-Oriented Design Heuristics, Addison-Wesley, 1996. [13] Murphy, G., Notkin, D., “Lightweight Lexical Source Model Extraction,” ACM Transactions on

Software Engineering and Methodology, 5(3), 262-292, 1996 [14] Yeh, A., Harris, D., Chase, M., “Manipulating Recovered Software Architecture Views,” Proceedings

of ICSE 19, 184-194, ACM Press, 2004 [15] R. Holt, “Structural Manipulations of Software Architecture using Tarski Relational Algebra,” WCRE

'98, Honolulu, Oct 1998. [16] Wong K., Tilley S., Muller H., Storey M., “Programmable Reverse Engineering,” International Journal

of Software Engineering and Knowledge Engineering, 4(4), 501- 520, 1994 [17] Kazman, R., “Tool Support for Architecture Analysis and Design,” Joint Proceedings of the SIGSOFT

‘96 Workshops (ISAW-2), 94-97, ACM, 1996 [18] Chisel HCI lab, university of Victoria, http://www.thechiselgroup.org/ [19] Fact Exploration and Analysis Tool, SPL lab, University of British Columbia, http://www.cs.ubc.ca/labs/spl/projects/feat/ [20] Jprobe profiler, http://www.quest.com/jprobe/profiler.asp [21] JBoss-4.0.0RC1 Release Notes, 2003 http://sourceforge.net/docman/display_doc.php?docid=23870&group_id=22866 [22] JBoss Application Server 4.0 Datasheet, http://www.jboss.org/pdf/JBoss_AS_4.0_Datasheet.pdf, 2004 [23] Fleury, M. and F. Reverbel. “The JBoss extensible server,” published in ACM/IFIP/USENIX

International Middleware Conference, Rio de Janeiro, Brazil: Springer-Verlag, 2003 [24] Douglas Schmidt, et al., Pattern-oriented software architecture: Patterns for concurrent and

networked objects, Chichester, New York, N.Y.: John Wiley & Sons, 2000 [25] Ferenc R., Siket I., Gyimothy t., “Extracting Facts From Open Source Software,” in Proc. of ICSM’04,

pp: 60-69