Welcome!

Weblogic Authors: Yeshim Deniz, Elizabeth White, Michael Meiner, Michael Bushong, Avi Rosenthal

Related Topics: Weblogic

Weblogic: Article

Using an Implementation Model to Identify Packaging Issues

Using an Implementation Model to Identify Packaging Issues

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.
  • More Stories By 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.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


    IoT & Smart Cities Stories
    DXWorldEXPO LLC announced today that ICC-USA, a computer systems integrator and server manufacturing company focused on developing products and product appliances, will exhibit at the 22nd International CloudEXPO | DXWorldEXPO. DXWordEXPO New York 2018, colocated with CloudEXPO New York 2018 will be held November 11-13, 2018, in New York City. ICC is a computer systems integrator and server manufacturing company focused on developing products and product appliances to meet a wide range of ...
    René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
    DXWorldEXPO | CloudEXPO are the world's most influential, independent events where Cloud Computing was coined and where technology buyers and vendors meet to experience and discuss the big picture of Digital Transformation and all of the strategies, tactics, and tools they need to realize their goals. Sponsors of DXWorldEXPO | CloudEXPO benefit from unmatched branding, profile building and lead generation opportunities.
    Founded in 2000, Chetu Inc. is a global provider of customized software development solutions and IT staff augmentation services for software technology providers. By providing clients with unparalleled niche technology expertise and industry experience, Chetu has become the premiere long-term, back-end software development partner for start-ups, SMBs, and Fortune 500 companies. Chetu is headquartered in Plantation, Florida, with thirteen offices throughout the U.S. and abroad.
    SYS-CON Events announced today that DatacenterDynamics has been named “Media Sponsor” of SYS-CON's 18th International Cloud Expo, which will take place on June 7–9, 2016, at the Javits Center in New York City, NY. DatacenterDynamics is a brand of DCD Group, a global B2B media and publishing company that develops products to help senior professionals in the world's most ICT dependent organizations make risk-based infrastructure and capacity decisions.
    CloudEXPO New York 2018, colocated with DXWorldEXPO New York 2018 will be held November 11-13, 2018, in New York City and will bring together Cloud Computing, FinTech and Blockchain, Digital Transformation, Big Data, Internet of Things, DevOps, AI, Machine Learning and WebRTC to one location.
    @DevOpsSummit at Cloud Expo, taking place November 12-13 in New York City, NY, is co-located with 22nd international CloudEXPO | first international DXWorldEXPO and will feature technical sessions from a rock star conference faculty and the leading industry players in the world. The widespread success of cloud computing is driving the DevOps revolution in enterprise IT. Now as never before, development teams must communicate and collaborate in a dynamic, 24/7/365 environment. There is no time t...
    DXWordEXPO New York 2018, colocated with CloudEXPO New York 2018 will be held November 11-13, 2018, in New York City and will bring together Cloud Computing, FinTech and Blockchain, Digital Transformation, Big Data, Internet of Things, DevOps, AI, Machine Learning and WebRTC to one location.
    Cloud-enabled transformation has evolved from cost saving measure to business innovation strategy -- one that combines the cloud with cognitive capabilities to drive market disruption. Learn how you can achieve the insight and agility you need to gain a competitive advantage. Industry-acclaimed CTO and cloud expert, Shankar Kalyana presents. Only the most exceptional IBMers are appointed with the rare distinction of IBM Fellow, the highest technical honor in the company. Shankar has also receive...
    A valuable conference experience generates new contacts, sales leads, potential strategic partners and potential investors; helps gather competitive intelligence and even provides inspiration for new products and services. Conference Guru works with conference organizers to pass great deals to great conferences, helping you discover new conferences and increase your return on investment.