Using an Implementation Model to Identify Packaging Issues

Aug. 23, 2002 12:00 AM

At Rosewood Software Services, we use Rational's Unified Process (RUP) and help many clients tailor it for their use. RUP specifies a number of models, including the Implementation Model, which is used to structure the physical artifacts (or files) within a project. For example, in a Java project the Implementation Model is used to define the project's Java package structure and the files used within the project, including class and JAR files as well as JSPs.

Most texts leave the Implementation Model at this point, using it as a simple model of file dependencies. The Implementation Model can be used to identify and design out additional issues, such as:

J2EE packaging
Identification of concurrent development opportunities
Identification of COTS dependencies
Application framework dependencies
Testing strategies

This article explains how to use the Implementation Model to identify WebLogic Server (WLS) packaging issues.

Packaging Issues
The classloader architecture changed with WLS 6. This facilitated a number of new features, including support for EAR files and a much cleaner deployment model that supports hot deployment and hot redeployment.

Classloader Background
A classloader allows a Java application to load new classes at runtime. Within a Java application, there is a hierarchy of classloaders.

The bootstrap classloader is the first in a sequence - the ancestor of all other classloaders. It's responsible for loading all of the JVM's internal classes as well as the classes in the java.* package. The extensions classloader loads all the JARs in the JDK's ext directory. The system classloader (often called the classpath classloader) loads all the classes in the classpath environment variable or those specified using the -classpath command-line switch. The extensions classloader is a child of the bootstrap classloader and the system classloader is a child of the extensions classloader. Any classloaders created by an application (such as WLS) will be children of the system classloader.

How is a class loaded? The classloader first checks to see if the class is already resident in memory. If the class isn't loaded, the classloader asks its parent to load the class. If the parent can't do this, the classloader attempts to load it itself. Since the classloader's parent is also a classloader, when it receives a request from a child to load a class it first asks its parent to load the class. This leads to requests being propagated up the classloader hierarchy to the bootstrap classloader. The bootstrap classloader then tries to load the file; if it can't, the request is passed down to the child that made the request. The request goes back down the hierarchy until a classloader is found that can load the class (see Figure 1). If the class can't be loaded by any classloader, a ClassNotFoundException is thrown.

To load and unload classes at runtime, WLS creates a new classloader for the application. In the context of WLS, an application is usually an EAR file, but it could also be a WAR or an EJB JAR file. When WLS creates a classloader for an application, it provides an effective separation of the applications - they can't access each other's classes due to the classloader delegation strategies.

In WLS, the application classloader loads all the classes explicitly associated with the EAR file and the classes in the EJB JAR files. WLS creates new classloaders for the Web applications. In turn, these are responsible for loading any classes and libraries associated with the Web application. If a class is uniquely defined in a WAR file, it isn't accessible to other classloaders.

Using the Implementation Model to Identify Packaging Dependencies
In RUP, the Implementation Model is concerned with the structure of the physical directories and files that make up the application (or implementation subsystem - a collection of components). This is an important part of any development process; it's crucial to have a cohesive, decoupled Java package structure. Using the Implementation Model purely as a mechanism to identify the Java package structure means losing a vast number of modeling benefits. It can be used to identify additional issues, such as concurrent development opportunities and dependencies. For example, the Implementation Model can be used to help identify the packaging of EJBs.

If we can use the Implementation Model to identify packaging issues, can we use it to identify classloader issues? Indeed we can. Rational Rose helps with the automatic tracing of dependencies. If we take an example EJB, the EJB component may be in the Java package hierarchy com.rssl.syscon.implmod.sampleEJb. If the bean were dependent on another Java class, com.rssl.syscon.implmod.util.ClassloaderDemo, we'd expect to see a UML dependency (see Figure 2). This shows that the UML package SampleEJB is dependent on (requires access to) the utils package. In UML, a Java package is represented by a UML package.

Given the dependency shown in Figure 2, we can produce an EJB packaging diagram that reflects the new dependency (see Figure 3). Now a design decision should be resolved during the modeling activities: Where does the ClassloaderDemo.class file reside? If there are no other dependents on this class, the class can be packaged with the EJB in its JAR file. If there are other dependents, where should it be located? The implementation-focused modeling activities should investigate these dependencies.

How do we identify classloader packaging problems? The issues presented by the classloader architecture are manifestations of dependency resolution. For example, if an EJB is dependent on class X and a Web application is also dependent on class X, there will be an issue if the class is physically different. A problem with models is that the pertinent information is dependent on the view the modeler takes during a particular activity. This often hides the information that may help identify packaging issues. It's helpful to promote the activity of "component dependency resolution," which generates a Packaging view within the Implementation Model (see Figure 4).

Component Dependency Resolution
RUP is architecture-centric. It uses the 4+1 view of architecture, which has the Implementation view to focus on the architecturally significant structuring of the physical artifacts in the system. The Packaging view is a subset of the Implementation view and is architecturally significant in the J2EE environment due to the component-packaging dependencies that may impact how components can be distributed. To produce the view we have an activity that resolves the component dependencies, allowing us to correctly package the components.

The Component Dependency Resolution activity used in our development process (a customized version of RUP) focuses on resolving the dependencies in packaging and deploying components. We introduce a view in our Implementation Model that focuses on identifying the packaging our "build" will have and to provide a focus for the modeling investigation, although care should be taken in introducing unnecessary views as replacements for diagrams. This view is where we create the JAR/WAR/EAR components.

We use Rational Rose to produce most of our models. Rose produces Java code in the Java package structure; in other words, it generates a UML package for each Java package. This package generation starts under the Component view (a high-level structure), under which we introduce the Implementation Model. This UML package is used to group all the views that relate to the implementation. Strictly speaking, it would be academically pure to have the top-level Java package under our Implementation Model package; unfortunately, this breaks the Rose code-generation facilities, which require that the top-level Java package be an immediate child of the Component view package.

Within our Implementation Model we introduce the Packaging Dependencies view, a stereotyped UML package. Here we investigate the dependencies between components and produce any relevant diagrams. The investigation starts with the creation of packages for each currently identified application or EAR file. This provides the top-level structure for the classloaders. From this we can partition the components between applications. In the example shown in Figure 4, our simple demo application has a single application classloader package. In large-scale applications where there may be multiple applications in the build, we would stereotype this package as <<Application Classloader>>. Within this package we produce diagrams to illustrate the contents the classloader should be responsible for loading.

Within our application loader package we identify other significant packages, such as the Web applications that will be packaged into our application.

Where will there be conflict in the classloader dependency structures? If WebApplication1 has a dependency on the classes shown in Figure 5, there's a conflict with the dependents of SampleEJB. SampleEJB also requires access to the class file ClassloaderDemo. How will the classloader architecture resolve this? If the packaging remains and both the EJB and the Web application contain a copy of this class, the EJB class definition will be precedent. At this point we may want to investigate whether there's a flaw in the application architecture, or we may want to resolve the dependency.

Resolving component dependencies is usually a simple activity, and it's a vital design step. A rule of thumb: ensure that the class is loaded only once. Therefore, the dependency can be resolved by ensuring that a single classloader is responsible for loading it. This is achieved by putting the class at the highest common level - in this case, the demo application. If the class needs to span multiple applications (EARs), it must be located at the system level. At this point, questions should be asked of the architecture, and the issue of component versioning may appear.

An application is a discrete set of components. There shouldn't be dependencies between applications on class definitions. If there are, the class definitions have to reside at the system level. This implies that all applications within the application server will share the same version of the class. This may be the intent at the outset; however, when an application upgrade is required of a common class and this class is declared at the system scope, all applications must be recompiled and tested. In some organizations this may be difficult, if not impossible. A far better approach is to ensure that the application is cohesive and that corporate infrastructure, such as any corporate logging framework, is packaged along with the application. This way, modifications to other deployed applications won't have side effects. Should the Packaging view indicate a requirement to have classes at the system scope, it will be excellent documentation for that dependency.

Summary
We've reviewed some of the issues and benefits of the classloader architecture in WebLogic Server. It's important to understand this architecture when architecting a WLS-based solution. The Implementation Model is an excellent artifact for investigating the architectural packaging dependencies that may be introduced during design but it shouldn't be generated just before cutting code - it should be used early in the development process. The Implementation Model may have significant impact on the application architecture you've chosen, and various techniques can be used within it to help identify the packaging dependencies.

Reference

Kruchten, P. (1995). "The 4 + 1 View Model of Architecture." IEEE Software. IEEE. Vol. 12, issue 6.

Related Links

About Andy Winskill
Andy Winskill is principal consultant at Rosewood Software Services Ltd., UK. He specializes in BEa and Rational softwre, and has more than 10 years of experience in designing and constructing EAI and B2B applications. Rosewood Software Services are BEA and Rational partners.