236

General Considerations

quately store its conversational state during a session interaction with a service. For

a service endpoint to maintain conversational state with its clients, the endpoint

must be designed with this in mind. 

Often, such endpoints are designed to use a unique, nonreplicable token to

identify communication from a specific client, much like browsers use the cookie

mechanism. The service endpoint and the client application pass the token

between them with each call during their conversation. Code Example 5.18 shows

the definition of an order management service endpoint's methods for retrieving

and updating a purchase order. Each method includes a token parameter,

clientToken

, that identifies the specific client. The client application creates a

unique token and passes it to the service endpoint when invoking these methods.

When it receives the method invocation, the service endpoint identifies the client

and persists its state. In this example, notice that the endpoint can identify the pur 

chase order because the same client token is passed when retrieving and updating

the purchase order.

public interface OrderManagementSEI extends Remote {

public void updatePurchaseOrder(PurchaseOrder po, 

String clientToken) throws RemoteException;

public PurchaseOrder getPurchaseOrder(String id, 

String clientToken) throws RemoteException;

}

Code Example 5.18

Service Endpoint Interface Methods with Unique Tokens

When an EJB component is the basis for a service endpoint, the EJB compo 

nent can persist conversational state to a data store during the session. The service

endpoint may still be designed to use tokens, and such tokens may represent the

primary key of an entity bean. In this case, the endpoint designer must be sure to

clean up stale session data from the persistent store. This can be done using a time

stamp on the entity bean holding the conversational state and a timer bean to track

elapsed time. An endpoint that does not properly clean up stale session data might

eventually persist a large amount of data.

A client developer whose application interacts with an endpoint that stores

conversational state needs to have detailed knowledge of the endpoint's token

requirements and the state maintained by the endpoint. In addition, the developer

needs detailed knowledge of the timeout, if one exists. This coordination between