Deploying Client Applications

There are two phases in deploying Java Client applications: deploying the server-side application and deploying the client-side application. If you’re familiar with deploying HTML-based WebObjects applications, you already know everything you need to deploy the server-side application. If you’re unfamiliar with this process, however, you need to read the document WebObjects Deployment Guide Using JavaMonitor.

After you’ve deployed the server-side part of a Java Client application, there are two ways you can deploy the client application. They are described in this chapter, after a section comparing the three options:

Deployment Options

HTML-based WebObjects applications require only a Web browser on the client to run on the user’s computer. The client requirements for Java Client desktop applications, however, are considerably more demanding.

Java Client applications can be deployed as real desktop applications or through Web Start. Each deployment option is feasible, but you should carefully evaluate both options after understanding their respective strengths and weaknesses.

Web Start

The easiest way to deploy the client part of Java Client applications is to use Web Start. Starting with WebObjects 5.2, Web Start is integrated with all Java Client applications, which takes care of these Web Start tasks for you:

In WebObjects 5.2, Java Client projects have two default WOComponent files, Main.wo and JavaClient.wo. Main.wo provides an HTML entry page for the client application that includes an HTML link to the JNLP file of the client application. The JNLP file is generated dynamically when the application starts up so you don’t need to worry about it at all.

Attributes of the JNLP file such as vendor, description, and application name are specified with bindings in the JavaClient component. You probably configured these bindings in the Java Client project assistant, as shown in Figure 10-1.

Figure 10-1  JNLP configuration in new project assistant
JNLP configuration in new project assistant

When a user clicks the link that points to the client application’s JNLP file, that file is downloaded to their computer. If you’ve added the JNLP MIME type to your Web server, the client’s Web browser should automatically invoke the Web Start application to launch the client application.

Deploying the client application with Web Start provides a platform-independent, standards-based deployment solution that is easy for end users to use and that is easy for you to update and maintain. It is perfect for an environment of distributed heterogeneous client systems.

Java Client signs the wojavaclient.jar file (the core Java Client client-side runtime classes) with its own security certificate. However, there is no way you or your clients can verify the authenticity of this certificate, so the wojavaclient.jar appears as signed by an “unknown issuer” and recommend to users that they do not install applications that use it. If this presents a problem for your organization, you’ll need to resign the wojavaclient.jar . If your application includes custom client-side classes (such as nib files and custom controller classes), you may also need to sign the .jar file that contains them with your certificate.

With that said, Java Client applications usually do not need to be run as trusted since they don’t usually need access to the client computer’s file system.

To make accessing your application easier for users, you should instruct them to use the Web Start application to launch the client application after the first use. This frees them from needing to remember the Web address of the client application. Figure 10-2 shows the Web Start application running in Mac OS X.

Figure 10-2  Run the client application from the Web Start application
Run the client application from the Web Start application

The Web Start application also includes a preference to make a platform-specific application executable on the user’s computer so that they can launch the application without needing to use the Web Start application or visit the client application’s Web page. This preference pane is shown in Figure 10-3.

Figure 10-3  Configure Web Start to create a desktop application for the client application
Configure Web Start to create a desktop application for the client application

Desktop Applications

Although Web Start is the default and recommended client deployment mechanism, you can also deploy the client part of Java Client applications as platform-specific desktop applications. You may want to do this to avoid the security contract imposed by Web Start or to achieve optimum performance.

To do this in Mac OS X, follow these steps in Project Builder:

  1. Make a new project of type Java Swing Application.

  2. Add all the .jar files for the frameworks the client application uses. These include at least the following:

    • /System/Library/Frameworks/JavaEOApplication.framework/WebServerResources/JavaEOApplication.jar

    • /System/Library/Frameworks/JavaEOControl.framework/WebServerResources/JavaEOControl.jar

    • /System/Library/Frameworks/JavaEODistribution.framework/WebServerResources/JavaEODistribution.jar

    • /System/Library/Frameworks/JavaFoundation.framework/WebServerResources/JavaFoundation.jar

    • /System/Library/Frameworks/JavaEOGeneration.framework/WebServerResources/JavaEOGeneration.jar

    • /System/Library/Frameworks/JavaEOInterface.framework/WebServerResources/JavaEOInterface.jar

    • /System/Library/Frameworks/JavaEOInterfaceSwing.framework/WebServerResources/JavaEOInterfaceSwing.jar

    • /System/Library/Frameworks/JavaEORuleSystem.framework/WebServerResources/JavaEORuleSystem.jar

  3. Open the project that you want to deploy. Build but don’t run the project.

  4. Open a terminal window and change directory to the project’s .woa file (named ProjectName.woa). By default, the .woa is created in your project’s directory.

  5. Change directory to Contents -> WebServerResources -> Java.

  6. This directory should contain a .jar file that contains the application’s client-side classes. Add the .jar file to the project you created in step 1.

  7. In the project you created in step 1, choose Edit Active Target from the Project menu.

  8. Under Build Phases, select Frameworks & Libraries. Make sure the checkbox next to Merge is selected for each .jar file in the project, as shown in Figure 10-4.

    Figure 10-4  Configure merging of .jar files
    Configure merging of .jar files
  9. Delete all the methods except main from the Java class with the same name as the project you created in step 1. So if you named the project “Launcher,” change the file Launcher.java to look like Listing 10-1.



    Listing 10-1  Launcher class

    public class Launcher extends Object
    {
     
        public static void main(String args[]) {
           com.webobjects.eoapplication.client.EOClientApplicationSupport(new String[]{"",         ""});
        }
     
    }
  10. Under Info.plist Entries, select Expert View.

  11. Add a key to the Java entry called Arguments, of type String and with a value that is the WebObjects application URL of the server application. The form of the value is http://hostName/adaptorName/WebObjects/applicationName.woa/. In development mode, enter the direct connect URL (see the launch console) as shown in Figure 10-5.

  12. Modify the MainClass key in the Java entry to be com.webobjects.eoapplication.client.EOClientApplicationSupport, as shown in Figure 10-5.

    Figure 10-5  Add keys to the Info.plist entry
    Add keys to the Info.plist entry
  13. Build the project. The product is a double-clickable Mac OS X application bundle.

Where To Go Next

Restricting Access to an Application through Building a Login Window contain information on various tasks you’ll perform when adding features to Java Client applications. Some of the chapters contain scenarios listing specific problems and their solutions. You can use those chapters as a reference guide while building applications.

Table 10-1 provides a high-level overview of the task chapters.

Table 10-1  Task chapter overview

Chapter

Difficulty Level

Task Category

Restricting Access to an Application

Intermediate

Access control

Generating Controllers With the Controller Factory

Easy

Programmatic customizations

Adding Custom Menu Items

Intermediate

XML customizations

Adding Custom Actions to Controllers

Intermediate

XML, rule, and programmatic customizations

Common Rules

Easy

Rule customizations

Freezing XML User Interfaces

Intermediate

XML and rule customizations

Mixing Static and Dynamic User Interfaces

Advanced

Nib file and rule customizations

Using Custom Views in Nib Files

Advanced

Nib file customizations

Using and Extending Image Views in Nib Files

Intermediate

Nib file customizations

Using Pop-up Menus in Nib Files

Advanced

Nib file customizations

Localizing Dynamic Components

Advanced

Localization; rule and programmatic customizations

Building Custom List Controllers

Advanced

Programmatic customizations

Using HTML on the Client

Advanced

WebObjects HTML integration

Building a Login Window

Advanced

Access control