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

• Figure 1
• Source Code