Understanding Design Considerations

Web service design elements essentially revolve around the following questions:

• What Web service interface, in terms of its granularity, vocabulary, and payload, would be most appropriate? Also, how many distinct Web services would be appropriate?

  – For packaging and implementation guidance, see Understanding Web Service Package Considerations, p. 1108 and Best Practices, p. 1160 .

  
  

• Should the service mode of interaction be synchronous or asynchronous?

  – For information on service interaction modes, see Web Service Types, p. 1068 .

  
  

• For service operations that return multiple values, will the interface benefit from use of output or inout parameters, that is, Holder classes? Remember that any aggregate result information can always be embodied in a user -defined return type; however, output parameters can provide convenience and elegance to an interface. This is particularly relevant if your client programming language naturally supports output or reference arguments.

• Should you use user-defined type classes in parameters and return values, or use built-in types exclusively? Although user-defined types require a little more work, they can add richer semantics and context to an interface and behavior to parameters or return values.

• What types of J2EE components are most appropriate for your Web service? Table 30.1 provides some guidelines on component selection.

Table 30.1. Suitable J2EE Components and Services for a Web Service

Web Service Characteristic	Recommended Component
Asynchronous	MDB with JMS support
Process oriented	Stateless EJB
Data oriented	JMS and MDB
Scalable and reliable	Stateless EJB
Transactional	Stateless EJB
Simple, not time- or resource- intensive business logic; single-threaded	Java class

– For more information on the types of components you can use with your Web service, see Writing Back-End Components, p. 1126.