5.2. Scenarios for Web Services-Based Client Applications

Developers typically write clients to access preexisting Web services—that is, public or private Web services. At times, the same developers may simultaneously develop both the service and its clients. Regardless of this, client developers should rely on the WSDL service description for their knowledge of the service details. In addition, developers may use a variety of technologies and APIs for developing these clients. They may develop clients using J2EE technologies, often called J2EE clients, or they may use the standard Java (J2SE and J2ME) technologies, or even non-Java technologies.

Before delving into the details of client development, let's examine several Web service client scenarios. Although different, each scenario is based on accessing the same Web service. The scenarios are as follows:

• J2EE component— In this scenario, a J2EE component accesses a Web service. The J2EE component receives results from the service, and it formats these results so that it can be read or displayed by a browser.

• J2SE client— A J2SE client may access the same Web service as the J2EE component. However, the J2SE client provides a more detailed view of the results returned from the service.

• J2ME client— A J2ME client, such as a client application running on a mobile device or PDA, gives a user the freedom to access the same Web service from places other than his or her office. In addition, the user can work offline with the results returned from the service.

• Non-Java client— A non-Java client accesses the same Web service using SOAP over HTTP.

Figure 5.1 shows how these different types of clients might access the same purchase order tracking Web service interface. All clients, regardless of their platform, rely on the Web service's WSDL document, which uses a standard format to describe the service's location and its operations. Clients need to know the information in the WSDL document—such as the URL of the service, types of parameters, and port names—to understand how to communicate with a particular service.

It is important to note that none of the clients communicate directly with a Web service. Each client type relies on a runtime—either a JAX-RPC or SOAP runtime—through which it accesses the service. From the developer's perspective, the client's use of a runtime is kept nearly transparent. However, good design dictates that a developer still modularize the Web service access code, plus consider issues related to remote calls and handling remote exceptions. These points are addressed later. (See “Locating and Accessing a Service” on page 219 and “Handling Exceptions” on page 230.)

Browser-based applications rely on J2EE components, which act as clients of the Web service. These clients, referred to as J2EE clients, are J2EE components that access a Web service, and the JAX-RPC runtime in turn handles the communication with the Web service. The J2EE environment shields the developer from the communication details. J2EE clients run in either an EJB container or a Web container, and these containers manage the client environment.

Stand-alone clients—which may be J2SE clients, J2ME clients, or clients written in a language other than Java—communicate to the Web service through the JAX-RPC runtime or the SOAP runtime. Stand-alone clients are outside the J2EE environment. Because they don't have a J2EE EJB container or Web container to manage the environment, stand-alone clients require more work from the developer.

Although each type of client works well, developers must deal with an increasing level of complexity if they work directly with the JAX-RPC or SOAP runtimes. The advantage of the J2EE environment is that it shields developers from some of the complexity associated with developing Web services, such as the look up of the service and the life-cycle management of objects used to access a service. In the J2EE environment, a developer uses JNDI to look up a service in much the same way as he or she might use other Java APIs, such as JDBC or JMS.

Given that many types of clients can access Web services, how do you determine which type of client is best for your application? To make this determination, you must consider how end users and the application expect to use the service. You should also weigh the pros and cons of each client type, and consider that each type of client has its own unique characteristics that may make it appropriate (or not appropriate) for a specific application task. Thus, you should consider the characteristics of the different client types as well as the communication mechanisms available to each client type when deciding which client type to use to access a Web service. The following general guidelines should help with this decision:

J2EE clients— J2EE clients have good access to Web services. J2EE clients have other advantages provided by the J2EE platform, such as declarative security, transactions, and instance management. J2EE clients may also access Web services from within a workflow architecture, and they may aggregate Web services.

J2SE clients— Generally, J2SE clients are best when you need to provide a rich interface or when you must manipulate large sets of data. J2SE clients may also work in a disconnected mode of operation.

J2ME clients— J2ME clients are best for applications that require remote and immediate access to a Web service. J2ME clients may be restricted to a limited set of interface components. Like J2SE clients, J2ME clients may also work in a disconnected mode of operation.

Now that we have looked at some sample Web service scenarios, let's examine in more detail the different types of clients that use Web services.

5.2.1. Designing J2EE Clients

As already noted, the J2EE 1.4 platform provides an environment that supports client application access to Web services. In a J2EE environment the deployment descriptors declaratively define the client-side Web service configuration information. The deployer may change this configuration information at deployment. In addition, the J2EE platform handles the underlying work for creating and initializing the access to the Web services.

The J2EE platform provides many other technologies in addition to supporting Web services. Developers can obtain a richer set of functionality by using these other services, such as Web and EJB components, in addition to Web services for their client applications.

For example, consider a browser client that accesses an order tracking Web service via a Web component. (See Figure 5.2.) The Web component presents a browser page to the end user, who enters an order identifier to a form displayed in its browser. The browser client passes this order identifier to a Web component, which accesses the order tracking Web service and retrieves the order information. The Web component converts the retrieved information to an HTML page and returns the formatted page to the browser client for presentation to the end user.

In this example, a Web component calls the order tracking service and, when it receives a response from the service, it puts the results in a Java Beans component (OrderDetailsBean) that is within the request scope. The Web component uses a JSP to generate an HTML response, which the container returns to the browser that made the original request.

It is also possible to write J2EE clients using EJB components. (See Figure 5.3.) These EJB components may themselves be Web service endpoints as well as clients of other Web services. Often, EJB components are used in a workflow to provide Web services with the additional support provided by an EJB container—that is, declarative transactional support, declarative security, and life-cycle management.

Figure 5.3 demonstrates a workflow scenario: a Web service endpoint used in combination with a message-driven bean component to provide a workflow operation that runs asynchronously once the initial service starts. The Web service endpoint synchronously puts the purchase order in a JMS message queue and returns an orderId to the calling application. The message-driven bean listens for messages delivered from the JMS queue. When one arrives, the bean retrieves the message and initiates the purchase order processing workflow. The purchase order is processed asynchronously while the Web service receives other purchase orders.

In this example, the workflow consists of three additional stages performed by separate Web services: a credit card charging service, a shipping service, and a service that sends an order confirmation. The message-driven bean aggregates the three workflow stages. Other systems within an organization may provide these services and they may be shared by many applications.

5.2.2. Designing J2SE Clients

Unlike the J2EE environment, developers of non-J2EE clients are responsible for much of the underlying work to look up a service and to create and maintain instances of classes that access the service. Since they cannot rely on a container, these developers must create and manage their own services and ensure the availability of all runtime environments needed to access the Web services.

J2SE clients, such as desktop applications developed using the Swing API, have the capability to do more processing and state management than other clients. This type of application client can provide a rich GUI application development environment that includes document editing and graphical manipulation. However, there are some points that should be kept in mind when considering J2SE clients:

• Long-running applications— Using J2SE is particularly good for Web service clients that run for extended periods of time. Because these applications run for long periods, developers must consider that both the client and the Web service may need to maintain the state of at least some of the data. It is possible to embed conversational state within each method invocation, if required by the service's use case.

• Using a rich graphical user interface (GUI) for complex data— J2SE clients can provide users with a rich view of data. Such a rich interface might permit a user to navigate and modify offline a large set of data returned by a service. The client can later update the Web service with any changes to the data.

• Requiring only intermittent network access— J2SE client can use Web services without needing to maintain continuous network access, relieving some of the burden on a network. Care must be taken to ensure data consistency between the service and the client.

• Requiring complex computations on the client— J2SE clients are well-suited for performing complex mathematical calculations, as well as operations that update data, and then submitting the results to a service. For example, these clients have better resources for image manipulation, and they can relieve the server of this burden. Thus, J2SE clients can provide a better environment than a service for a user's interaction with data sets.

For example, a J2SE application may contain a rich GUI used to update catalog information. The user can manipulate attributes as well as graphical data using the application's GUI screens. When the user finishes, the application submits new or updated catalog data to the catalog service.

J2SE applications may be deployed using Java Web Start technology. Java Web Start simplifies deployment in large enterprise environments by ensuring that clients have available the proper versions of the Java Runtime Environment and all necessary libraries.

Whenever possible, use Java Web Start to provide a standardized means of deployment for J2SE clients.

When designing a Web service client, try to keep Web service access code separate from GUI code.

Since J2SE clients may operate in either a connected or disconnected mode, when developing these clients keep in mind issues related to maintenance of state and client and service synchronization.

5.2.3. J2ME Clients

Java 2 Platform, Micro Edition (J2ME) clients may interact remotely with a Web service. However, since J2ME clients have limited GUI capabilities compared to J2SE clients, consider using J2ME clients when mobility and remote access are requirements. Also consider using this type of client when immediacy of access is important.

For example, Figure 5.4 shows a J2ME client running on a cell phone and accessing an order tracking service. The client does not need an elaborate GUI or set of widgets to interact with the Web service.

J2ME clients may access Web services using a subset of the JAX-RPC API. When accessing Web services, J2ME clients should consider network connection and bandwidth issues, offline versus connected operation, and GUI and processing limitations.

Networks supporting J2ME devices may not always provide consistent connectivity. Applications using such networks must consider connection failure, or sporadic connectivity, and be designed so that recovery is possible.

Additionally, the bandwidths for many networks supporting J2ME devices limit the rate at which data can be exchanged. Applications need to be designed to limit their data exchange rate to that allowed by the network and to consider the cost that these limitations imply. Care must also be taken to deal with network latency to keep the user experience acceptable. Since Web services do not specify a level of service for message delivery, the client application must take this into account and provide support for message delivery failures.

Keep in mind that J2ME network providers may charge for network usage by the kilobyte. J2ME-targeted applications may be expensive for the user unless care is taken to limit the data transferred.

Applications for J2ME devices may work in an offline, or disconnected, mode as well as an online, or connected, mode. When working in an offline mode, applications should collect data and batch it into requests to the Web service, as well as obtain data from the service in batches. Consideration should be given to the amount of data that is passed between the Web service and the client.

Applications for J2ME devices have a standard, uniform set of GUI widgets available for manipulating data, such as the liquid crystal display UI that is part of MIDP 1.0 and MIDP 2.0. Plus, each device type may have its own set of widgets. Such widgets have different abilities for validating data prior to accessing a service.

J2ME devices, while capable of small computations and data validation, have limited processing capabilities and memory constraints. Client applications need to consider the types of data exchanged and any pre- and post-processing required. For example, J2ME devices have limited support for XML document processing and are not required to perform XML document validation.

In summary, keep the following considerations in mind when designing J2ME clients.

Connectivity and bandwidth limitations— J2ME clients may have limited bandwidth, intermittent disconnects, and fees for connection usage.

Processing power— The processing capabilities of a Web service client should be considered in its design.

State maintenance— J2ME clients may operate in a connected or disconnected mode, requiring the maintenance of state and synchronization between client and service.