Evaluating the JBoss Evaluating the JBoss Application Server Application Server

ArchitectureArchitectureBy

Yichuan Cao

Supervisor:Supervisor:Eleni StrouliaEleni Stroulia

April 22, 2004

Presentation Outline Motivation Related Research Evaluation Process JBoss Overview JBoss3.2.1 Architecture Architectural Approaches Quality Attribute Utility Tree Scenario Analysis Evaluation Result Conclusion

Why Evaluate an Architecture Software architecture is the manifestation

of a system’s earliest design decisions. The success of a software system depends

on good software architectural decisions. Evaluating a software architecture is about

answering the following questions: How well does it fulfill the requirements of the end

users? How well does it affect the software quality? How well does it meet the goals of the development

company?

Current Problems Only a few organizations in the industry

actually perform the evaluation. Often be conducted in an ad hoc way.

We conducted a systematic architecture evaluation on the JBoss application

server by leveraging current software engineering techniques

Related Research

Quality attribute characterization Architectural styles Architectural recovering Architecture Tradeoff Analysis

Method (ATAM)

Evaluation Process

Identify business requirements. Recover the JBoss architecture. Identify the adopted architectural

approaches. Generate quality attribute

scenarios. Analyze the scenarios.

Recovering the JBoss Architecture

Reading related standards, literature, and related framework documentation.

Extracting information from the JBoss build files.

Applying JBuilder8’s UML reverse-engineering feature and debugging features.

Using JProbe’s call graph recording feature.

High-Level Requirements for JBoss

Comply with the J2EE standards. Satisfy the following quality

attributes: Modifiability Usability Scalability Subsetability Performance Manageability Availability

JBoss Overview Full-featured J2EE application server. One of the most popular J2EE application server.

JBoss Application Server

Web Container

EJBContainer

Other System

JCA

Database

Data Flow Component

JavaClient

Keys:

WebClient

JDBC

CORBAClient

Web Service Client

request

request

request

request

request

request

response

response

response

response

response

response

JBoss Context Diagram

JBoss3.2.1 Architecture

Communications Between Top-Level Modules

System Module

Provides a JMX microkernel-based bootstrap service and deployment service

Key classes in the system module

Naming ModuleProvides naming services which allow a user to map a name onto an object.

Core Classes in the Naming Module

Security ModuleProvides supports for both the J2EE declarative role-based security model and the integration of custom security.

Core Classes in JBoss Security

Server ModuleImplements EJB support. EJB specifies a distributed component model simplifying the development of component-based applications

Class Diagram for JBoss EJB Module

Architecture Approaches Microkernel architecture Component-based architecture Component configurator pattern Unified class loader Dynamic proxy Interceptor Invoker Deferral of the binding time of the

variation points

Architecture Approaches (c.)

Collocation of web container and EJB container

Separation of interfaces from implementation

Reuse of 3rd party implementations Reuse of 3rd party frameworks Strategy Pure Java implementation Caching

Quality Attribute Utility Tree Represents overall “goodness” of the

system. Utility is the root node. The desired quality attributes form the

second level nodes. The attribute concerns are the third level

nodes. The leaf nodes are the concrete

scenarios.

Quality Attribute Utility Tree (c.)

Quality Attribute Utility Tree (c.)

Quality Attribute Utility Tree (c.)

Scenario Analysis Elicit the architectural

decisions that impact the analyzed scenario.

Indicate each architectural decision as being a risk, sensitivity point, tradeoff point, and/or non-risk.

An Example of Scenario Analysis

Scenario U1: Deploy a modified library to the JBoss application server within five minutes.

The Results of Analysis of Scenario U1

D1: Using the unified class loaders to facilitate hot redeployment.D2: Using the deployment ScannerThread to periodically check for changes in the deployment directory.D3: The deployment unit is not locked during the deployment.

An Example of Scenario Analysis (c.)

T1: Tradeoff between reusability and the support of multiple versions of components. The unified class loaders support the reuse of the components among different deployment packages at run-time, but they limit the support for the multiple versions of the components .

S1: If the interval for checking is too long, the total deployment time will be longer. If the interval for checking is too short, CPU resources will be wasted.

R1: If the copy takes too long time to complete (large library or remote copy), JBoss may deploy an incomplete library.

R2: If the library is changed during the deployment, JBoss may deploy a library in an inconsistent state.

Evaluation Results This architecture is strong in modifiability. Usability needs to be improved. The dynamic proxy approach and JMX

integration may degrade performance. Lack of a configuration tool may result in

the inconsistency of the configuration, and make it difficulty for users to configure.

Lack of support for internationalization.

Conclusions Architecture evaluation can be done successfully

with limited information and resources. Better documentation. Concrete useful results. No adequate architecture documentation. No original architect participation.

The study of the quality attributes and “general scenarios” greatly helped in generating the specific concrete scenarios to examine the architecture.

Study the attributes of each quality attributes. General scenarios can apply to any system. They have

been collected by researchers.

Conclusions (c.)

Contemporary architecture recovering techniques enable us reconstruct the JBoss architecture.

Using tools to extract useful information. Pattern matching. Study related framework.

Our evaluation process should be able to apply to other evaluations where the domain knowledge of the target system is easy to obtain and the source code of the system is available for analysis.

References

[1] Douglas Schmidt, Michael Stal, Hans Rohnert, and Frank Buschmann. Pattern- Oriented Software, Archetecture Volumn 2: Patterns for Concurrent and Networked Objects. John Wiley & Sons, Ltd, 2000

[2] Paul Clements, Rick Kazman and Mark Klein. Evaluating Software Architectures – Methods and Case Studies. Addison-Wesley, 2002.

[3] Scott Stark, Marc Fleury, and the JBoss Group. JBoss Administration and Development. Sams Publishing, 2002.

[4] Len Bass, Mark Klein, and Gabriel Moreno, “Applicability of General Scenarios to the Architecture Tradeoff Analysis Method,” Technical Report, CMU/SEI-2001-TR-014, Dec. 2001.

[5] J2EE - http://java.sun.com/j2ee.

References (c.)

[6] Kazman, R.; O’Brien, L.; & Verhoef, C. Architecture Reconstruction Guidelines, Second Edition (CMU/SEI-2002-TR-034).

[7] JBoss – http://www.jboss.org.

[8] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. Reading, Massachusetts: Addison-Wesley, 1995.

[9] M. Shaw, D. Garlan, Software Architecture - Perspectives on an Emerging discipline, Prentice Hall, 1996..

Questions & Answers