240

General Considerations

client from some future changes to the service. These facade classes help a client

developer to not only access the service in a standardized manner, but may also

improve their understanding of the service endpoint so as to develop better clients. 

More extensive HTML documentation of a service covering parameters

required by the service, return values, and exceptions helps developers better

interact with the service. This information should go beyond what is included in

the WSDL document. 

5.4.4 Packaging

To access a service, a stand alone client requires a runtime environment. For J2SE

clients, the runtime must be packaged with the application. J2EE clients rely on the

JAX RPC runtime. 

J2ME clients do not need to package the JAX RPC runtime with the applica 

tions. Although stubs do need to be packaged with an application, the stubs are

portable across JAX RPC runtimes. The portability of stubs is critical because

J2ME clients cannot generate or compile stub implementation code, and thus must

rely on more dynamic provisioning.

This section discusses packaging issues for the different types of clients.

5.4.4.1

J2EE Clients

Web service clients running in a J2EE environment require some basic artifacts, as

follows:

  Service reference A 

service ref

 element in the deployment descriptor

  Mapping file A JAX RPC mapping file

  WSDL document

  Service endpoint interface A stub or dynamic proxy 

  Generated classes

The 

service ref

 element, part of the general J2EE 1.4 schema, contains

information about a service. Web, EJB, and J2EE application client module

deployment descriptors use this element to locate the JAX RPC mapping files as

well as the service's WSDL file. The service reference element maps a service to

a JNDI resource name and also specifies the service endpoint interface for those

clients using stubs and dynamic proxies. (Clients using DII do not need to specify