Developing lightweight J2EE client applications that interoperate with multiple application servers can be difficult to do. Having to include an application server-specific JAR file along with a thin client application can significantly increase the size of the deployed application and make it too big to be practical.
In addition, client-side execution is tightly coupled using proprietary app-server extensions. This is especially true when mixing and matching multiple J2EE vendors together (such as a Tomcat servlet container communicating with a WebLogic EJB tier). Standard protocols, such as RMI/IIOP, are supposed to alleviate this problem. However, there is still no standard API or library that can be used across application servers without sacrificing native features, such as:
High-Level Overview
One of the greatest features of the Java platform is the ability to dynamically download and execute Java code from a set of URLs to a Java Virtual Machine (JVM). The result is that a remote system can run a program, for example, a thin J2EE client, which has never been installed on its disk. Using the java.net.URLClassLoader and reflection APIs, any JVM can download any Java resource, including RMI stubs, which enables the execution of method calls on a remote server using the server system's resources.
How It Works
The ThinClient.java program does not contain any imports other than the core J2SE APIs. It uses a URLClassLoader to load its Java resources (see Figure 1). The URL is a servlet (see Listing 2) that's deployed on an application server as part of an .ear file.
1. The application server binds the HelloWorld EJB into JNDI. The ClassLoader servlet and Web application (see Listing 2) is deployed on the server and includes the HelloWorld_ejb.jar as part of the classpath. When resources are accessed from this servlet, it will serve classes from its .war, EJB classes, .ear, and System classpath. (Listings 2-5 can be downloaded from www.sys-con.com/java/sourcec.cfm.)
2. The thin J2EE client application uses the URL ClassLoader to load Java resources. The particular example in Listing 1 loads all classes using this classloader.
// set the context class loader to a URL ClassLoader
ClassLoader classLoader;
Thread.currentThread().setContextClassLoader(
classLoader = new URLClassLoader(
new URL[] {
new
URL("http://localhost:7001/classloader/ClassLoaderServlet/")
}
)
);
3. The thin J2EE client application uses reflection to instantiate a hashtable to set up the InitialContext and performs a JNDI lookup operation reflectively. The URLClassLoader is used to download the application server's required classes for the lookup operation. The HelloWorld stubs are returned and executed on the thin client (see Listing 3).
4. The thin J2EE client performs method calls via reflection to the server (see Listing 4).
Listing 2 contains the servlet code that loads the Java resources. In this particular example, the servlet is colocated with the application in the same J2EE container.
Java resources are accessed using the following syntax:
http://<servername>:<port>/classloader/ClassLoaderServlet/test/Example.class
The extra path information:
/test/Example.class
is a hypothetical class called test.Example in the system classpath or part of the .war or .ear files.
Alternative Technologies
A client can access an application service several ways. For example, a client may use a proprietary protocol, RMI/IIOP, JMS, or Web services. Several advantages and disadvantages exist with each of these communication technologies, and choosing the most "optimal" client application design can be challenging.
Interoperability is one factor that comes to mind when choosing a communication mechanism. Both thin J2EE clients and Web services fit well in this model. Web services give clients the ability to interoperate with almost any type of system and application, regardless of the platform on which the system or application runs. The thin J2EE client approach is limited to Java, but allows conversational state, asynchrony, transactions, security, and high-availability performance.
Web services use HTTP as the transport protocol, enabling clients to operate with systems through firewalls. The service's WSDL document enables clients and services that use very different technologies to map and convert their respective data objects. For services and clients that are based on JAX-RPC, the JAX-RPC runtime handles this mapping transparently.
Listing 5 illustrates how to create a dynamic Web service using WSDL. Notice that there are only J2EE imports. It's very similar to the ThinClient.java example, in that the operation and service definitions are dynamically obtained.
The thin J2EE client approach is faster than Web services, since it uses native communication protocols while making remote calls over the network. However, it's better suited for clients operating in intranet environments where there is a greater degree of control over the client's deployment and the J2EE server. A downside for this environment is passing through firewalls. Furthermore, this approach provides clients with secure access to the application business logic while at the same time taking care of the details of the client and server communication and marshalling and unmarshalling parameters.
Java Message Service (JMS) is another means for thin J2EE clients to communicate with server applications. It provides a means for asynchronous communication. Applications using JMS are better suited to a setting that is behind a firewall, since messaging systems generally don't work well on the Internet (often, messaging systems are not even exposed on the Internet).
Using Thin Clients with the WebLogic Server
Check your J2EE application server documentation to see if it comes with a resource to serve objects to the client. For example, the WebLogic server contains a built-in servlet, called ClasspathServlet, to serve Java resources in a distributed manner. The servlet code in Listing 2 is not required, since this feature comes out-of-the-box in WebLogic. The URL syntax is as follows:
http://<servername>:<port>/bea_wls_internal/classes
The bea_wls_internal is a default Web application that is enabled by default. The /classes part of the URL is registered to the internal weblogic.servlet.ClasspathServlet.
If the URL is set to /bea_wls_internal/classes, the classes required by the thin J2EE client should be available in the system classpath of the server.
If the URL is set to /bea_wls_internal/classes/DefaultWebApp@DefaultWeb-App, the classes required by the thin J2EE client should be in the applications/DefaultWebApp/WEB-INF/classes directory or in the system classpath.
Versions prior to WebLogic 7 must register the ClasspathServlet and it's accessed via the /classes URL.
For this to operate successfully, you must add the following parameter to the WebLogic start script:
-Dweblogic.servlet.ClasspathServlet.disableStrictCheck=true
This relaxes the restriction of the downloadable file type. Hence, any Java resource can be served from this servlet.
Java Web Start
Java Web Start (JSR 000056) is a built-in J2SE software-distribution mechanism that downloads and executes Java software from a HTTP server. Typically, it's used from a browser and works well with the Java plug-in. The Java Network Language Protocol (JNLP) is the underlying communication mechanism used by Java Web Start. Alternatively, Java Web Start can be invoked from the command line using the javaws utility.
The techniques presented in this article are not meant as a replacement for Java Web Start. They simply demonstrate how to create lightweight clients in your own programs when you need to selectively download and execute application code.
Summary
As service-oriented architectures reemerge, it becomes crucial to have a decoupled and extensible client layer that can accommodate change and dynamic behavior. Constant API changes and backward compatibility problems can occur during concurrent development cycles. For an architecture that consists of all Java components (both client and server), Web services may not be the best choice, since it can cause performance degradation (overhead of XML parsing), deployment problems (load balancing/failover), and security issues.
Utilizing the native application server features, such as clustering, transactions, and security, with a loosely coupled implementation, architectures can focus on integration versus environmental problems. Constant API changes and backward compatibility problems can occur during concurrent development cycles. Building a very thin client layer can facilitate dynamic code changes and provide an adaptable and extensible architecture.
Resources