Integrating rich clients with J2EE |
 |
By Coach Wei, CTO, NexaWeb, special to SearchWebServices.com
15 Sep 2004 | SearchWebServices.com |
|
|
J2EE has been a widely adopted middleware platform for powering HTML Web applications. However, many customers run into the inherent limitations of HTML applications when they start to use the Web for mission critical enterprise computing: HTML applications need to be connected all the time. A lot of enterprise applications require a much more scalable usage model than page "click and refresh". A lot of them require real-time data updates via server push. Rich client technologies solve these problems. By adopting the right rich client technology, customers can get the best of both worlds: the universal deployment advantages of the Web and the richness of local desktop computing.
How does rich client integrate with J2EE server infrastructure? In general, there are two different approaches:
1. Remote method invocation
2. Loosely coupled messaging
In approach 1, the application exposes certain server side objects to the client side. The client side invokes these objects via some form of remote method invocation. This is the default approach if the application is deployed onto a J2EE Client Container. The developer still needs to create standard Enterprise Java Beans (EJBs) on the server side and expose some of these objects to the client container via some object registry. The J2EE Client Container obtains a remote proxy to these EJBs and the client code calls these proxy objects to perform the server side business function. This approach works well from the perspective of integration with J2EE server infrastructure.
The problem of approach 1 is that the client and server are tightly coupled and the architecture is inflexible. On the other side, deploying the client application together with the J2EE client container (typically multi-megabytes) is a big challenge. This approach is suited for Intranet applications where multi-megabyte installation per desktop is not a problem.
In approach 2, the developer creates server side code using the standard J2EE practice, writes code to send/process messages from the client and invokes appropriate business functions. The client code sends and receives messages as well. This message-based architecture is much more flexible.
There are various techniques to perform messaging, such as using Java Messaging Service (JMS) or HTTP messaging. Using JMS requires putting a JMS server on the J2EE server and configuring network infrastructure to accommodate JMS, such as opening a special port on the server firewall beyond the normal Web server port.
In comparison, HTTP messaging is interesting because it makes message handling even easier. Using HTTP messaging, the client is sending standard HTTP messages to the server. This type of HTTP message can be handled by a normal Java server page or Servlet (this is exactly how normal HTML Web applications are written!). The JSP or Servlet processes the HTTP request and returns data back to the client as an HTTP response. The data can be arranged into an XML format and further transformed and processed on the client side. At this point, the developer can use all familiar skill sets, the existing security infrastructure, and no change is required for server side network infrastructure.
In summary, Rich Client technologies solve many of the problems associated with HTML Web applications. By integrating Rich Clients with J2EE servers via the messaging based approach described above, developers can overcome many Web development hurdles (especially by enabling standard J2EE coding on the server and not requiring changes to the network/firewall infrastructure), while experiencing architectural flexibility and numerous deployment advantages.
About the Author:
Coach Wei currently serves as CTO for NexaWeb , which develops the leading technology software platform for building and deploying Enterprise Internet Applications. Previously, he played a key role at EMC Corporation in the development of a new generation of storage network management software. Coach is a graduate from MIT, holds several patents, and is an industry advocate for the proliferation of open standards.
|
|
|
|
