Newsletter sign-up

View all newsletters

Sign up for our Enterprise Java Newsletter

Enterprise Java

Java Tip 103: Send HTTP requests for serialized objects

Implement Web object tunneling to transport Java objects through firewalls

By Johann Vazquez, JavaWorld.com, 09/29/00

My Web Object Tunneling utility evolved when I needed to develop an applet that would display dynamic server-side data stored as JavaBeans. I needed to consider how to detect their modifications, and how to download the beans.

I decided to design a transport layer that would allow the applet to request the JavaBeans directly from the server in a serialized form. Moreover, since the applet would be used outside the corporate firewall, I decided to use HTTP to build the layer.

A standard RMI solution would have incurred extra delays when run with proxy servers, making the applet appear slower. Additionally, I would have had to modify my existing servlets into remotable objects, then deal with an RMI registry. Other common problems with the RMI solution include:

• Although all Netscape browsers, since 4.03 with JDK 1.1, patch support RMI, they have a limited capacity for implementing applet-to-server communication. For example, some security managers disallow the creation of ServerSockets. Instead, RMI multiplexes on the established socket, so communication remains (virtually) bidirectional, but slows down because of the additional layer that manages the protocol.
• Microsoft claims to have "Java support in MSIE," but despite being part of 1.1 specifications, RMI is not supported by Microsoft's browsers (Internet Explorer 4.0 and 5.0) by default. Users must install an RMI patch (from Microsoft or IBM, for example) to run RMI applets on their MS browsers. For more details, see Resources.

Basically, the straight RMI solution was too slow and required too much additional coding.

With my custom Web Object Tunneling, I only had to modify my existing servlets to extend a new base class and override a single method.

Model overview

Web Object Tunneling is implemented inside a set of classes, which enables the creation of Java object channels between clients and servlets. The client party originally creates the channel, since the implementation is based on HTTP (request/response protocol). (See Figure 1.)

Figure 1
Click on thumbnail to view full image (15 KB)

The client-side objects involved are:

• HttpObjectChannel, the client-side channel -- the entry point for any communication with server-side channels. It makes it possible to initiate HTTP requests (HttpObjectRequest) to any given Web server URL (HttpObjectChannelServlet).
• HttpObjectRequest, which represents an HTTP request. It handles the HTTP communication exchanges with the Web server. It sends POST requests (along with any desired argument) to the Web server and waits for Java objects to be returned.
• HttpObjectVarg, a variable arguments container. Any argument required in a request (HttpObjectRequest) should be SET inside this object.

The server-side objects involved are:

• HttpObjectChannelServlet, the server-side channel. You can extend this class to construct a servlet that can respond to HTTP requests with serialized Java objects.
• HttpObject: This interface can be implemented by any (serializable) object that should be "freed" right after HttpObjectChannelServlet sends it to the client. That is, if you want to help the garbage collector clean the object, implement HttpObject with a customized free() method (for example, to close sockets or break circular references).

How do you use it?

This example makes an HTTP request to a servlet, sends it some variables (var1, var2, and var3), waits for an object to be returned, and prints the returned object.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.