220

Developing Client Applications to Use a Web Service

ports for a service, the container, based on its configuration, can choose the best

available protocol binding and port for the service call. (See Code Example 5.2.)

Context ic = new InitialContext();

Service service = (Service)ic.lookup(

 java:comp/env/service/OpcPurchaseOrderService );

PurchaseOrderIntf port = (PurchaseOrderIntf)service.getPort(

PurchaseOrderIntf.class);

Code Example 5.2

Looking Up a Port Using a Stub or Dynamic Proxy

Code Example 5.2 illustrates how a J2EE client might use the 

Service

 inter 

face 

getPort

 method. Rather than cast the JNDI reference to the service imple 

mentation class, the code casts the JNDI reference to a 

javax.xml.rpc.Service

interface. Using the 

Service

 interface in this manner reduces the dependency on

generated stub classes. The client developer, by invoking the 

getPort

 method,

uses the client side representation of the service endpoint interface to look up the

port. After obtaining the port, the client may make any calls desired by the appli 

cation on the port. 

E

When using stubs or dynamic proxies, the recommended strategy to reduce the 

dependency on generated classes is to use the 

java.xml.rpc.Service

 interface 

and the 

getPort

 method as a proxy for the service implementation class. 

E

A client developer should not circumvent the J2EE platform's management of 

a service. A client should not create or destroy a Web service port. Instead, a 

client should use the standard J2EE mechanisms, such as those shown in Code 

Example 5.2.

E

A client developer should not assume that the same port instance for the service 

is used for all calls to the service. Port instances are stateless, and the J2EE 

platform is not required to return a previously used port instance to a client.

An application in a non J2EE environment uses a stub to make a Web services

call in a different manner. The client application accesses a stub for a service using

the method 

getOrderTrackingIntfPort

 on the generated implementation class,

OpcOrderTrackingService_Impl

, which is specific to each JAX RPC runtime.

J2SE or J2ME clients use these generated 

_Impl

 files because they do not have