Update distributed applications
Tutorial Details:
Update distributed applications
Update distributed applications
By: By Jonathan Simon
A comparison of auto-updating solutions for thick Java clients
hick and thin clients each have major strengths and weaknesses when compared to each other. Often, the strength of one is the weakness of the other. In general, thick clients are functionally rich but difficult to deploy, while thin clients are less functionally rich but easy to deploy and manage. Each approach attempts to gain the other's strengths without sacrificing its own. Deployment solutions like Sun Microsystems' Java Network Launching Protocol (JNLP) are gaining ground by allowing developers to control deployment and maintenance of thick-client applications running locally on users' desktops. This thick-client approach combines the best of both worlds. This approach, however, requires a fair amount of infrastructure in the form of a deployment solution.
A deployment solution is a complete architecture for installing and maintaining an application for its entire lifecycle. This breaks down into two sections, installation and maintenance. Installation is a package that sets up an application for the first time. Typical installations distribute installation executables via the Web or a CD. Maintaining an application assumes that the application is already installed and is being updated. Maintenance includes pushing new application versions, bug fixes, and resources. Application maintenance can be accomplished by distributing update installs or patches to the previous installation. Maintenance can also be accomplished by integrating a maintenance solution into the application development and deployment process to automatically maintain the application. I will refer to this maintenance as auto-updating from now on.
General auto-deployment architecture
Ideally, developers and administrators should have access to all of their clients' machines and push upgrades of their applications directly to their desktops at will. For various reasons, this is just plain impossible, as well as impractical. As a result, the solutions discussed in this article share a similar architecture to check a server for updates, and download and execute the application locally. First, let's take a high-level look at the general architecture before we dive into any one solution.
Figure 1. A generic architectural overview of auto-updating solutions. Click on thumbnail to view full-size image.
Notice all communication between the client and server occurs between the client and server agents. Also note the application server. All these solutions deploy in application servers, although some only require a Web server with a servlet engine. There is also HTTP/S communication between the client and server agents, making secure Internet distribution possible.
Now, let's discuss each of the main components in detail.
Client agent: The client agent is a small application that resides on a user's machine and manages all communication with the server. This includes functionality for checking updates and downloading new resources. The client agent also processes all data received from the server. The level of client-agent functionality varies between solutions. For example, some solutions may have functionality to prompt the user with several download options, while others may not.
Server agent: The server agent integrates functionality for communication with the client agent and server-updating logic. This updating logic may include functionality like authentication logic to determine if a particular user is authorized to receive a particular update.
Application datastore: The application datastore contains downloadable resources as well as server-agent and client-agent configurations for each application. This can range from a full-blown database to a simple directory on a server.
Server administrator: The server administrator is an editor for the application datastore and server agent. It provides a user interface for registering and editing application resources and settings.
How to compare solutions
The first step towards comparison is to define major functional categories of deployment solutions. Let's define them as follows:
User experience: what the user sees and interacts with relating to the updating process
Client functionality: functionality on the client machine executed behind the scenes
Deployment control: interaction with the server and control over updating processes
Architecture and integration: deployment-solution server integration with other systems
Then we look in-depth at each solution, including the following information:
Historical overview
If not JNLP, relation of the solution to JNLP
Specific architectural overview
Major benefits; something about this solution that makes you think twice about using another one
Showstoppers; something about this solution that might keep you from using it at all
After exploring each solution, you can compare specific points between solutions with the summary tables provided later. Finally, we examine appropriate circumstances for using each solution presented in this article.
JNLP and Java Web Start
JNLP was developed by Sun ( Java Specification Request (JSR) 56 ) with the Java Community Process (JCP) as a quick, easy way to deploy and auto-update thick clients. Auto-updating thick clients helps to overcome many of the problems with applets and thin-browser clients, including Java Runtime Environment (JRE) restrictions and other browser dependencies. JNLP deployment is intended for a wide range of scenarios from applet replacement to intranet enterprise application deployment.
Java Web Start, the Sun JNLP reference implementation, allows one-click application installation and initialization through a browser. Users start by downloading the Java Web Start client, a browser helper application. This is only necessary the first time a Java Web Start application is run. All Java Web Start applications launched later use the same Java Web Start client. When the user clicks on the URL in the browser, the server serves a JNLP file to the client. The JNLP file is an XML file specifying resources and settings for the particular application. The JNLP file also specifies the locations (URLs) of the resources on the server for downloading.
Figure 2. A simple JNLP descriptor file. Click on thumbnail to view full-size image.
Opening the JNLP file initiates the Java Web Start client, which processes the JNLP file. Java Web Start downloads the entire application if the application was not previously downloaded. If the application is currently on the client, but out of sync with the server, only new or changed resources are downloaded. After this update check, Java Web Start automatically launches the application.
According to Stanley Ho, staff engineer at Sun, "In Java Web Start 1.2, we have a new auto-install feature (on Windows only), which allows the launching of a Java application from the Internet/intranet using just a few clicks from the browser. Upon clicking the JNLP file link on the browser, Java Web Start will download/install if needed and launch the Java application automatically. This is another benefit of using Java Web Start?to deploy client-side applications easily."
Now that you know how JNLP works, let's step back and analyze the architecture. The Java Web Start client is the client agent, albeit a very simple one, as it allows only rudimentary user interaction during the update process. There are no server agents, server application caches, or server administrator components defined in the JNLP specification.
By now you're probably wondering why JNLP is described as a deployment solution. A little insight into Sun's intentions with JNLP will help clarify this. JNLP was intended to be a starting point in thick-client deployment. It's a protocol, a foundation, but not a complete deployment solution. Sun intends for IT departments and product vendors to build solutions on top of JNLP and extend it as necessary. In the context of this article, I will compare the possibilities of JNLP implementations to other off-the-shelf solutions.
Major benefits
It's free!
Straightforward architecture. May only require a Web server (without a servlet container) for simple applications.
Solutions can be small and lightweight (and therefore easier to deploy and maintain) since they may not require full databases, client administrators, and server agents.
The solution Web application and the application resources can easily be packaged into one war file, keeping transportation between machines simple.
You can build dynamic Web applications to search for applications at runtime rather than explicitly registering them with a database (see sidebar, " Application Portals ").
JNLP is an open specification. Therefore, you can switch between JNLP-compliant clients at will, or write your own for unsupported platforms.
Since JNLP files are XML files, generating and editing JNLP files is simple with the help of a Java XML parser/generator like Xerces.
The JNLP specification integrates the secure sandbox security model. This is absolutely essential for public Internet distribution.
Show stoppers
As mentioned, the JNLP specification integrates the secure sandbox security model. Therefore, security restrictions include server download and access restrictions and signed resources requirements. The inability to disable security is a major minus for enterprise applications, as it involves serious coding and distribution considerations.
Client-agent support is minimal. The user cannot interact with the client agent in any way during the update process. An example of where this might be a problem is an application that is required to prompt the user to decide whether or not to update the application once a new version is detected.
All resources must distribute in jar files. This also means that your application code needs to change
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: Update distributed applications
View Tutorial: Update distributed applications
Related
Tutorials:
 SQLJ: The 'open
sesame' of Java database applications
SQLJ: The 'open
sesame' of Java database applications
|
Make room for JavaSpaces, Part 3 - JavaWorld March
2000
Make room for JavaSpaces, Part 3 - JavaWorld March
2000
|
The smart approach to distributed performance monitoring with Java - JavaWorld September
2000
The smart approach to distributed performance monitoring with Java - JavaWorld September
2000
|
Make room for JavaSpaces, Part 6 - JavaWorld October 2000
Make room for JavaSpaces, Part 6 - JavaWorld October 2000
|
Add the power of asynchronous processing to your JSPs - JavaWorld February 2001
Create custom JSP tags to use with JMS ost JavaServer Pages (JSP) developers that
|
Superior app management with JMX - JavaWorld June
Integrate JMX, a reusable configuration framework, with your JSPs
|
Optimistic
Locking pattern for EJBs - JavaWorld July
2001
Optimistic
Locking pattern for EJBs - JavaWorld July
2001
|
Cache SOAP services on
the client side
Cache SOAP services on
the client side
|
Good
introduction to JDO
Good
introduction to JDO
|
Update distributed applications
Update distributed applications
|
Comparing The Performance of J2EE Servers
Performance ReportThe standardization of the application server, thanks to Sun\'s J2EE specifications, has spawned a wealth of implementations. There are offerings from big players such as Sun, IBM, BEA and Oracle as well as numerous offerings from low-co
|
Sun releases J2SE SDK 1.4.2_05
Release Notes
JavaTM 2 SDK, Standard Edition
Version 1.4.2_06 (Microsoft Windows, Linux, and Solaris Operating Environment)
|
Welcome to the Tonic Look & Feel.
Welcome to the Tonic Look & Feel. This pluggable look and feel is a free substitute for the default native look and feel of Swing, 'Metal', distributed under the GNU Lesser General Public License.
|
PrEd
PrEd is a Java based graphical utility to find and edit Java property files in JAR, WAR, EAR and other kind of ZIP archives. It is the perfect tool for customizing Java applications, which use XML and Property files for their configuration.
|
Develop aspect-oriented Java applications with Eclipse and AJDT
AspectJ is an aspect-oriented extension of the Javaâ„¢ language that enables a modular implementation of crosscutting concerns. This crosscutting behavior, which can be static or dynamic, presents an extra challenge to tools that support AspectJ. The AJDT
|
SLAMD Distributed Load Generation Engine
SLAMD Distributed Load Generation Engine
The SLAMD Distributed Load Generation Engine (SLAMD) is a Java-based application designed for stress testing and performance analysis of network-based applications. It was originally developed by Sun Microsystems,
|
Distributed Enterprise Messaging with MantaRay
A very important communication standard in Java is Java Messaging Service (JMS). JMS is a set of Java interfaces and associated semantics that define a way for a Java-based client to access a messaging system. JMS provides a rich, yet simple, set of messa
|
Distributed Objects & Components: JavaBeans
What is JavaBeans ? (from the FAQ)
|
Introduction To Enterprise Java Bean(EJB). WebLogic 6.0 Tutorial.
Introduction To Enterprise Java Bean(EJB). WebLogic 6.0 Tutorial.
Welcome to EJB Section
(Learn to Develop World Class Applications with Enterprise Java Beans)
(Online WebLogic 6.0 Tutorial)
Introduction To Enterprise Java Bean(EJB)
Enterprise
|
We are providing Knoppix 3.7 Live Linux CD's
We are providing Knoppix 3.7 Live Linux CD's
Knoppix Linux CD's
Now Available Linux Knoppix 3.7 CD's
What is KNOPPIX?
KNOPPIX is a bootable Linux CD with a collection of various GNU/Linux software. It auto-detects hardware and supports many
|
|
|
|
