By Greg Cole
R&D Engineer
Inprise Corporation

Table of Contents
Application Deployment in the Enterprise
The DSJ Server
The DSJ Client
Future Directions for DSJ
Conclusion


Application Deployment in the Enterprise

Corporations have adopted Java for two primary reasons: the language and the platform. Java the language provides an elegant, object-oriented language for rapid application development. Java the platforms holds the promise of "Write Once, Run Anywhere"(tm)-creating an application once and being able to run it on the myriad of systems in corporate use today.

Originally, this platform independence was thought of primarily in terms of Applets running in the confines of a Browser. However, for productive business applications, Applets are generally not the answer-no hard disk access, security restrictions, and browser incompatibilities are some of the issues driving corporations to full-fledged Java applications. But with applications, the Applets ease of cross-platform deployment is lost.

To simplify and reduce the cost of application deployment and maintenance, Inprise delivers the Deployment Server for Java, which provides the convenience of applet deployment to full-featured Java applications. Applications are installed once on a server, then are seamlessly accessed by remote clients on any platform. Updates are centrally administered and immediate. Access is secure and may be monitored.

Benefits for the developer include:

• Developed applications are more powerful because they are not subject to the security restrictions imposed on applets, such as the ability to access files, native code, threads, sockets, printing, system properties, platform clipboard, IP multicast, reflection API, etc.
• IS departments have a dramatically simpler network infrastructure to maintain.
• Widens the number of potential target platforms.
• Management can track application usage.
• QA doesn't need to test for differences introduced by browser vagaries caused by version or platform.
• Applications can be deployed to platforms without a Java-enabled browser that supports the version of the JDK used in development.
• May obviate big site licenses for browsers in larger organizations. Not having browsers saves costs for training, maintenance, updates, and loss of productivity.
• Development can target lower-end machines, because target will not require a full-fledged browser.
• Developers are relieved of coordinating deployment issues with other departments.
• Maintains security within the firewall while still allowing access to documents.

Benefits for the developers' customers include:

• Reliable fast access to updated software.
• Fault-tolerant architecture provides service for mission-critical applications.
• Software that executes dramatically faster than applets.
• Software that is more powerful because it is not restricted.
• Being allowed to keep their browser set up as they want it without having to update (or backdate) in order to run a particular applet.

Understanding the DSJ Architecture
The Deployment Server for Java (DSJ) consists of two complementary, platform-independent components written entirely in Java: the DSJ Server and the DSJ Client.

The DSJ Server provides the centralized storage and management of applications, and includes visual administration tools. These tools allow administrators to rapidly register, change, and update applications, define application access lists, group servers, and associate specific Java runtime environments (JREs) with applications. Once this information is defined on the server, applications can be easily run from any system in the organization using the DSJ Client.

The DSJ Client provides the communications layer on client machines, communicating with DSJ Servers to rapidly provide the most up-to-date applications to the end user. The client can be configured to either start up individual applications, or to retrieve the list of available applications on the server. In either case, the end user perception is of starting a local application-they do not need to know anything about the server.

At a high level, the Client seamlessly determines if the current version of the application is cached on the local machine-if it is, the application is started up using the local copy. If the latest resources are not available on the local machine, they will be retrieved from the server, and the application is started. The entire process is completed automatically, without any intervention from the user.


Figure #1 DSJ Architecture

The rest of this paper drills down into the specific technologies employed by the Deployment Server for simplifying the deployment and maintenance of Java applications.

The DSJ Server

The DSJ Server is designed to store the code, resources, and Java Runtime Environments (JREs) that make up a Java application(s). All storage on the server is versioned, allowing multiple versions of the same application to be efficiently maintained in a form available for client access.

One of the primary design goals of DSJ is to ensure that no restrictions are imposed on the Java applications that can be written or deployed.

The Deployment Process
As soon as your Java application is completely debugged, it is ready to be loaded onto a DSJ Server. Using the server's Application Dialog (as shown in Figure #2), the server administrator provides information necessary to describe the application. The only required elements are:

• a name by which the application can be referred to
• the classpath representing the application's code
• the name of the application's entrypoint (its 'main' class)
• a version date

There are additional elements that may be specified in order to more completely describe the application to potential users.

• a description of the functionality provided by the application
• a version name


Figure #2 Application Dialog

For most applications, providing values for these fields is all that is required to install the application to the DSJ Server.

Extra Files
Some applications may require that additional files be present when the application executes on the client. For example, applications may use JNI (the Java Native Interface, which accesses operating system-specific libraries) or read from a property file or load an image from a file. For these applications, the DSJ administrator will need to specify the application's 'Extra Files'. This is done on the Application Dialog's 'General' tab, by pressing the Extra Files button.


Figure #3 Extra Files

At runtime, the DSJ Client will ensure that these files are present before initializing the target application.

JRE Dependencies
Other applications may have a dependency on a specific JRE version. For example, applications that make use of Sun's Swing package require a JRE version greater than 1.1.5. In this case, the DSJ administrator may specify the required JRE version by selecting the Application Dialog's 'Required JRE' radio button and supplying the name of the required JRE. Clients that subsequently attempt access to this application will be checked to ensure that they are running the proper JRE version. If they are not, an attempt will be made to automatically update them (more on this later).

Still other applications may have a preference for the version of the JRE on which they will run. In the case where multiple JREs exist on the client and a preference for one is specified by the application's install, DSJ will ensure that the preferred JRE is in use but will not enforce this nor attempt to automatically configure the client. This is the purpose of the Application Dialog's "Preferred" JRE radio button. DSJ allows the server administrator to specify two preferences, a primary and an alternate.


Figure # 4 Specifying JRE

Failover
For service of critical applications, DSJ allows specification of 'alternate servers'. The alternates are other DSJ servers to which this application has been installed. This list is communicated to the client during the initial handshake for the client for it to use in the case that the current server connection is lost. It is worth noting that the first entry in this list is typically "this" server. Having the current server not be a part of the server list is a means by which the server administrator could use a centralized DSJ server to implement a 'brokering' service with other DSJ servers.

In order to specify the collection of alternate servers, the system administrator may enter individual servers and their ports, the names of server groups, or both. Server groups are composed of named servers and/or other server groups. This allows the system administrator to construct named server hierarchies and assign or administer them collectively.


Figure #5 server hierarchy

Access Control
It may be desirable to limit access to some applications stored on the DSJ Server. For example, it would be inappropriate for an application that provides access to a company's financial database to be made widely available. In order to address this concern, DSJ allows applications to be restricted. A restricted DSJ application is one for which any accessors have been defined.

In the simplest of DSJ applications, no accessors are specified. This results in an unrestricted application available to any client that accesses the server. As soon as the system administrator provides an accessor, the application becomes a restricted application.

DSJ allows the system administrator to specify several types of application accessors. Access may be restricted by (authenticated) username, by IP address, by IP address range, or by accessor group. An Accessor group functions the same as a server group-i.e., named access to hierarchically nested groups. Accessor groups provide additional capability in that they allow accessors to be combined such that access can be limited to a named user from a particular IP address (or range).

Runtime Control
There may be a need for the system administrator to centrally control the command line arguments passed to the managed application. DSJ allows the system administrator to specify these arguments when the application is loaded into the server.

Another DSJ application option is available to determine a particular application's state. The 'enabled' option allows an individual application to be taken off-line or restored in a convenient fashion.

Further, the DSJ server allows the system administrator a measure of control over connection management. The system administrator may limit the number of simultaneous client connections that the server will allow. A related option allows the number of connections to an individual application to be constrained. If desired, the server may be configured to drop idle connections after a specified period of client inactivity. Using DSJ client's fault-tolerant architecture, the client will be seamlessly reconnected as (or if) necessary. These options provide the system administrator a very fine grain level of control over the DSJ server's connection pool.

A system administrator interested in tuning the performance of a number of applications stored in a group of DSJ servers for access by a large number of DSJ clients can use a combination of connection limiting, idle dropping, and extenders (described next) to fine-tune the system.

Platform Extenders
The value of any of the aforementioned application configuration options may be automatically tailored by the server for a particular client's locale, operating system, or combination of locale and operating system.

One use of extenders would be to customize the application's name, description, and version for presentation to the end user. This would ensure that they show up in French for clients based in France while showing up in German for those clients from Germany.

Another use of extenders would be for when your application relies on native code. When an MS Windows-based client contacts the server, you want to move the relevant .DLL file to the client; if the client is running under Solaris, you'll want to move the appropriate .SO file instead. One alternative would be to deliver both files to all clients, but it is more efficient to send only what is necessary. What the system administrator could do is to specify neither library in the base application and instead to define platform extensions for both Windows and Solaris.

Extenders could be used to customize the collection of alternate servers. This would allow the collection of alternate servers to be based on (implied) geographical locations. Extenders can also be used to provide an additional means for controlling access.

Storing Java Runtime Environments
As previously mentioned, DSJ provides a means to require that a particular application is executed by a specific version of a JRE. In the case where an application has been so configured, and a particular client does not have the specified JRE currently installed, it would be nice if the DSJ server could install the relevant JRE on the client. It can. All that is required is for the system administrator to install the JRE to the DSJ server.

Installation of a JRE to a DSJ server requires that the system administrator provide a description of a JRE, the JRE itself, and the JRE's destination directory on the client. The JRE's description is made up of the following information: operating system platform, Java name, Java version, Java vendor, specification name, specification version, and specification vendor. Its destination is simply the name of a directory on the client (either relative or absolute). Specifying the JRE's contents can be done in one of two ways. If the JRE is installed to the server itself, DSJ can create a compressed representation of it, which it stores in standard Java archive ('jar') format to a file called jre.zip. Alternatively, this jar may be created (or copied from another DSJ server) by the system administrator in some other way.

Once the DSJ Server has the JRE's description and contents, the JRE may be delivered on demand and installed in a fashion that is transparent to a client that requires it.


Figure #6 JRE Entry

The DSJ Client

The DSJ Client software is installed on each client machine. The client software can be updated remotely by the DSJ server whenever future versions become available, so the installation and configuration only has to be done once. The client is configured to look for a primary DSJ server. The connection is made with a custom long-term TCP/IP connection protocol. When the connection is made, the DSJ client can request a list of applications that are available, or request a specific application up front.

The DSJ Client employs a custom Java class loader. To run an application, it looks for its classes "over the wire" from the DSJ server, instead of relying on classes being physically installed on the client machine. Because the connection protocol is specifically designed to send classes, it is faster than an applet, and you get full-fledged Java applications, not restricted applets. By default, the DSJ client also caches the classes on the client machine, so the next time the application is run, it comes up immediately; unless there is an updated version of the application; in which case it will automatically download and use the new version. All this is transparent to the user.

The DSJ Client progresses through three stages during execution of a target application. In the startup stage where options are processed, the target application is determined and a list of servers for that application is acquired. During the second stage, client and server exchange information about versions, platforms, and dependencies resulting in the establishment of a long-term connection. Finally, after the long-term connection is active, classes are pulled to the client on an 'as-needed' basis and (optionally) cached locally for use the next time the application is run.

Startup
Normally when you run a Java application, you run the JAVA or JRE executable, passing your main class's name as an argument. When using DSJ, you pass DSJ's main class and your application's "name" as an argument. Based on the value of a configuration option, the DSJ client may display a username/password dialog at this point in order to ensure that access to applications is secure.

Assuming that the specified DSJ server is accessible, the DSJ Client establishes a short term TCP/IP connection with it.

You can specify an application to run, either on the command line, or in a properties file. For a given application, you can specify the version to run. If you don't designate a specific version, the latest version of the named application is executed. If you don't specify an application, DSJ client will display a list of applications that are available to you. This list is dynamically created based on the access criteria for each application. Access criteria are determined by the connected DSJ Server based on your authenticated user name, the IP address of the DSJ client machine, or a combination of both.

Once a specific application is chosen, the primary DSJ server you have been talking to transmits a list of all DSJ servers it knows that serve that application; this list often includes itself. This is the "available servers" list.

Initial Handshake
The DSJ client uses the available servers list to find a server that is able to provide the desired application.

Once contact with the server is established, the client transmits the version of the JRE that it is currently running, and the versions of other JREs installed on the client machine. Some applications will require a particular JRE; if that JRE version is on neither the client nor the server, the server will refuse the connection request. If the desired version of the JRE is already installed on the client, then the server will instruct the client to restart with that version. If the client does not have the desired version, but that version is installed on the server for downloading, the client will download the JRE from the server, and restart using that version of the JRE.

If, after checking all entries in the available servers list, an appropriate server cannot be located, an error dialog box is displayed and the attempt to run that application is terminated.

If the client finds a server that provides the desired application, the DSJ client transmits its version number to the server. If they don't match, the server instructs the client to download the matching version of the client software from the server, and to restart itself with the corrected version.

Long-term Connection
When the client is running the right version of the right software under the right JRE, it commences a long-term connection. The server transmits a list of alternate servers for the client to try if the current connection is lost. Any external files that are needed by the application are sent to the client. These may include native libraries (such as DLLs), image files, resource files, or any other arbitrary data files. Then the process of serving the Java class files begins.

Class Download
The client can be configured to either download all the classes that are used by the application before starting, or to download the classes as needed. Once the required classes are received, the application starts.

If the client loses its connection to the server while the application is running, it attempts to contact the alternate servers that are supposed to provide the application. This happens transparently, although the user may experience a minor delay as the client attempts to contact the other servers. If the client fails to complete the handshake with another server, an error occurs.

Caching
During idle time, the recently downloaded classes of the application are written to a cache file in the designated cache directory. The next time the application is executed, the class files will be run from the cache, which is much faster than downloading. If the application is updated and you are not requesting a specific version of the application, the cached classes will be discarded in favor of the newer class files from the server.

Each application is cached separately. If two applications use the same class file, you will cache two copies of that class, one in each application's cache file.

Future Directions for DSJ

Future versions of DSJ will make it even easier for system administrators to incorporate DSJ into their infrastructures. Remote administration and the notion of self-synchronizing server pools will make the management of large, geographically distributed infrastructures more convenient.

For the developer, the individual components that make up DSJ will become available separately, thereby allowing portions of the DSJ technology to be embedded within specific applications.

Conclusion

The purpose of software development is to provide a timely solution to an end user's need. Because DSJ is written in 100% Java, it is portable to any machine for which a Java-compliant virtual machine exists and thereby takes advantage of Sun Microsystems's "write once, run anywhere" strategy. Because DSJ imposes absolutely no restrictions on the Java applications that can be deployed, existing applications may be incorporated into a centrally administered system while paving the way for seamless client updates.

As software developers, it is our mission to provide our customers with a competitive edge that allows them to outperform their adversaries. By providing a means to simplify, streamline and automate the delivery of the most current, the most powerful, the best software available directly to the end user's desktop, DSJ makes the customer more productive.