202

Scenarios for Web Services Based Client Applications

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 access 

ing 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 re 

sults 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 re 

sults 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 plat 

form, 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 infor 

mation in the WSDL document such as the URL of the service, types of param 

eters, 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 perspec 

tive, 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 con 

sider 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.)