72

Designing a Service's Interaction Layer

Code Example 3.1 combines logically related data into one large message for

a more efficient client interaction with the service. This is preferable to receiving

the data with individual method calls, as shown in Code Example 3.2.

public interface AirlineTicketsIntf extends Remote {

public String submitFlightInformation(FlightDetails fltInfo)

throws RemoteException;

public String submitPreferredDates(Date depart, Date arrive)

throws RemoteException;

// other similar methods 

}

Code Example 3.2

Retrieving Data with Separate Method Calls (Not Recommended)

However, it might not be a good idea to combine in a single service invoca 

tion the same reservation with an inquiry method call.

Along with optimal granularity, you should consider data caching issues.

Coarse grained services involve transferring large amounts of data. If you opt for

more coarse grained service operations, it is more efficient to cache data on the

client side to reduce the number of round trips between the client and the server. 

3.4.1.3

Parameter Types for Web Service Operations

A Web service interface exposes a set of method calls to clients. When invoking a

service interface method, a client may have to set values for the parameters associ 

ated with the call. When you design an interface's methods, choose carefully the

types of these parameters. Keep in mind that a method call and its parameters are

sent as a SOAP message between the client and the service. To be part of a SOAP

message, parameters must be mapped to XML. When received at the client or

service end, the same parameters must be mapped from XML to their proper types

or objects. This section describes some guidelines to keep in mind when defining

method call parameters and return values. 

Note:

 Since each call potentially may return a value, the discussion in this

section about parameter values applies equally to return values.