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

Related Topics: Weblogic

Weblogic: Article

RMI Interoperability - In a clasloader of its own

RMI Interoperability - In a clasloader of its own

If you've had the pleasure of working with BEA WebLogic Server for several years, you may know that RMI/T3 calls between different releases of the server used to be disallowed ­ to be buzzword -compliant, the releases were not "wire compatible."

For example, you couldn't call an EJB deployed on WebLogic Server 4.5.1 from a WebLogic Server 5.1 application. This often meant that groups of applications had to be migrated together to new versions of WebLogic Server.

The lack of wire compatibility became more of a problem as users began to put increasingly sophisticated WebLogic Server configurations into production. Engineering stepped up to the mark and WebLogic Server 6.1 became the RMI/T3 "interoperability baseline" ­ interoperability between 6.1 and a number of future releases is designed into the product. New features such as Web services and enhanced RMI/IIOP also provide creative alternatives.

Not everyone has the luxury of green field sites using the latest WebLogic Server releases. In this article, I describe a scheme for sending JMS messages to both a WebLogic Server 5.1 application and a WebLogic Server 6.1 application from a single client. The approach I take is to use a special class loader that allows both versions of the RMI stack to be loaded into a single Java Virtual Machine (JVM).

A warning: you might need your propeller-head hats for some of this. I hope you come out the other side with an enhanced understanding of how class loaders work and how to use them to your advantage. The technique is not limited to addressing WebLogic Server interoperability problems; it can be applied wherever you want to load more than one version of a particular code base in a single JVM.

The full source code for this article can be found on the WLDJ Web site at www.sys-con.com/weblogic/sourcec.cfm.

So What's The Problem?
For a client to engage in RMI communication with a particular version of WebLogic Server, it must have the appropriate classes available. Usually, this means adding the WebLogic classes directory (for 5.1) or weblogic.jar (for 6.1) to the client's system classpath. The client uses these classes to communicate with the server and RMI stubs for application types are then retrieved from the server at runtime. Unfortunately, RMI classes and stubs from WebLogic Server 5.1 are not compatible with those from WebLogic Server 6.1; they can't be loaded together.

Java uses class loaders to control how classes are located and loaded into the virtual machine. Each class used by a program belongs to a class loader and, by default, a method uses its caller's class loader to load other classes. Class loaders are arranged in a hierarchy, with the Java boot, extension, and system class loaders at the top of the hierarchy. By convention, class loaders defer to their parents, meaning that when asked to load a particular class they give their parent class loader the option to load it instead. This is usually sensible; it minimizes the number of instances of a class that are loaded and allows parts of an application that use different class loaders to communicate through a set of common classes loaded by a parent class loader.

It's quite possible for a class with the same name to be loaded independently in two different class loaders and in this case the two instances are treated as distinct. By creating appropriate class loaders, you can partition parts of your application into separate "sandboxes" and ensure that classes one application component loads do not affect other components. This is what WebLogic Server 6.1 does to ensure that Web applications and enterprise applications are kept separate from one another. Refer to http://edocs.bea.com/wls/docs61/ programming/packaging.html#1048725 for details. The WebLogic Server class loader also supports dynamic loading and unloading (hot deployment) of Web applications and enterprise applications. An interesting article on writing dynamic class loaders can be found at www.javageeks.com/Papers/ClassForName/index.html.

By now, I think you can see where this is going. We should be able to load the two versions of the WebLogic Server RMI classes in separate class loaders. Our client needs to access both JNDI and JMS services from the two servers. The services are implemented differently in the two server versions, and we'll need to load two sets of the classes and stubs. We can't load everything in isolation though; the JNDI and JMS interfaces must be loaded in a single class loader so we can compose a useful program that calls both servers. Figure 1 shows the class loader hierarchy we will use.

An alternative strategy would be to load one version of the RMI classes and stubs in the same class loader as the controlling code (the main method in our example). This would be the case if you were using the technique to call out from a servlet running in one version of WebLogic Server to an Enterprise JavaBean running in another. I chose to use a distinct class loader for each version of the RMI classes because the symmetry makes the code simpler to understand. However, the class loader implementation I provide allows you to take either approach.

The Isolating Class Loader
If you've been paying attention, you might be wondering about the previous paragraph. How would a WebLogic Server 6.1 class loader work if the WebLogic Server 5.1 RMI classes were loaded in the system classpath? When asked to load a particular class, wouldn't the WebLogic Server 6.1 class loader first call the system class loader (its parent), which would erroneously load a WebLogic Server 5.1 version of the class?

This would certainly be the case for a conventional class loader, which would always defer to its parent first, but I've created an unconventional class loader, IsolatingClassloader. Each IsolatingClassloader is constructed with a list of packages and classes that it should load, and a class path that specifies where to load them from. This method is called to load a class and is shown in Listing 1.

IsolatingClassLoader first determines whether the class name is one that should be loaded in isolation, and if so, attempts to discover and load the class and make it available to the JVM. The class loader asks its parent to load the class only if the class is one that shouldn't be isolated or an implementation cannot be found.

Putting It To Work, The JMS Client
The supplied example client has four command-line parameters, the classpath and JNDI provider URL for each of the servers. Listing 2 is an example of the client running against the two servers. Note that I added the WebLogic Server 5.1 weblogicaux.jar file to the system classpath. This contains the JNDI and JMS interface classes.

To call a particular version of the server, we first construct an instance of IsolatingClassLoader that will isolate the WebLogic implementation classes (package names beginning with weblogic and COM.rsa) and set an appropriate classpath. We can then use the code in Listing 3 to call either version of the server. All that changes from server to server is the isolating class loader instance and the JNDI provider URL.

I guess you're wondering what those setContextClassLoader calls are doing? These calls set a "context class loader," which is associated with the current thread. The Java JNDI and RMI interface classes use the context class loader to determine how to load the implementation classes.

I encourage you to download the source code to see just how elegant the class loader solution is. With the exception of the IsolatingClassLoader setup and the calls to setContextClassLoader, the application code uses the standard J2EE API's.

Bridging Interface Differences
By now you can appreciate the appropriate emerging pattern when using IsolatingClassLoader to call several different versions of an implementation. Interface code is loaded in a common class loader; implementation code that needs to be isolated is loaded in its own IsolatingClassLoader. But what if the interfaces themselves vary?

In fact, this is the case for our JMS example. WebLogic Server 5.1 uses JMS 1.0.1, whereas WebLogic Server 6.1 uses JMS 1.0.2b. There are minor API differences in the handling of TopicConnections between the two versions of the JMS specification. Even if you don't create a TopicConnection, you'll run into this problem when you attempt to employ the IsolatingClassLoader technique to make WebLogic Server 5.1 JMS calls from a WebLogic Server 6.1 application. WebLogic Server 5.1 RMI performs strict type- checking that uses the stub interface and throws a ClassCastException if the local interface type does not exactly match the remote interface type. The mirror image of the scheme, with a WebLogic Server 6.1 IsolatingClassLoader embedded in a WebLogic Server 5.1 server, works fine because WebLogic Server 6.1 RMI uses dynamic proxies and is more relaxed about the API differences.

All is not lost. I've successfully extended the IsolatingClassLoader pattern to address this problem. I don't have room to cover the full solution here, but I will briefly describe it. I used a proxy object, residing in the common WebLogic Server 6.1 class loader, which maps JMS 1.0.2b calls to a neutral interface (a subset of the JMS 1.0.1 and 1.0.2b interfaces). A second proxy object, which is loaded by the WebLogic Server 5.1 IsolatingClassLoader, maps calls from the neutral interface to the JMS 1.0.1 interface. I managed to hide this implementation from application code by binding the entry points of the interfaces (connection factories) into the WebLogic Server 6.1 JNDI tree. Look out for this trick in the JMS Bridge that comes with the next release of WebLogic Server.

That's all for this month. I hope I've given you a different perspective on Java class loaders, and that you'll find it useful when wiring WebLogic Server applications together. Till the next time…

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
The deluge of IoT sensor data collected from connected devices and the powerful AI required to make that data actionable are giving rise to a hybrid ecosystem in which cloud, on-prem and edge processes become interweaved. Attendees will learn how emerging composable infrastructure solutions deliver the adaptive architecture needed to manage this new data reality. Machine learning algorithms can better anticipate data storms and automate resources to support surges, including fully scalable GPU-c...
Machine learning has taken residence at our cities' cores and now we can finally have "smart cities." Cities are a collection of buildings made to provide the structure and safety necessary for people to function, create and survive. Buildings are a pool of ever-changing performance data from large automated systems such as heating and cooling to the people that live and work within them. Through machine learning, buildings can optimize performance, reduce costs, and improve occupant comfort by ...
The explosion of new web/cloud/IoT-based applications and the data they generate are transforming our world right before our eyes. In this rush to adopt these new technologies, organizations are often ignoring fundamental questions concerning who owns the data and failing to ask for permission to conduct invasive surveillance of their customers. Organizations that are not transparent about how their systems gather data telemetry without offering shared data ownership risk product rejection, regu...
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...
Poor data quality and analytics drive down business value. In fact, Gartner estimated that the average financial impact of poor data quality on organizations is $9.7 million per year. But bad data is much more than a cost center. By eroding trust in information, analytics and the business decisions based on these, it is a serious impediment to digital transformation.
Digital Transformation: Preparing Cloud & IoT Security for the Age of Artificial Intelligence. As automation and artificial intelligence (AI) power solution development and delivery, many businesses need to build backend cloud capabilities. Well-poised organizations, marketing smart devices with AI and BlockChain capabilities prepare to refine compliance and regulatory capabilities in 2018. Volumes of health, financial, technical and privacy data, along with tightening compliance requirements by...
Predicting the future has never been more challenging - not because of the lack of data but because of the flood of ungoverned and risk laden information. Microsoft states that 2.5 exabytes of data are created every day. Expectations and reliance on data are being pushed to the limits, as demands around hybrid options continue to grow.
Digital Transformation and Disruption, Amazon Style - What You Can Learn. Chris Kocher is a co-founder of Grey Heron, a management and strategic marketing consulting firm. He has 25+ years in both strategic and hands-on operating experience helping executives and investors build revenues and shareholder value. He has consulted with over 130 companies on innovating with new business models, product strategies and monetization. Chris has held management positions at HP and Symantec in addition to ...
Enterprises have taken advantage of IoT to achieve important revenue and cost advantages. What is less apparent is how incumbent enterprises operating at scale have, following success with IoT, built analytic, operations management and software development capabilities - ranging from autonomous vehicles to manageable robotics installations. They have embraced these capabilities as if they were Silicon Valley startups.
As IoT continues to increase momentum, so does the associated risk. Secure Device Lifecycle Management (DLM) is ranked as one of the most important technology areas of IoT. Driving this trend is the realization that secure support for IoT devices provides companies the ability to deliver high-quality, reliable, secure offerings faster, create new revenue streams, and reduce support costs, all while building a competitive advantage in their markets. In this session, we will use customer use cases...