9.7 Best practices

< Day Day Up >

The decision on using RPC style or document style Web services should be based on the nature of underlying business process to be implemented. Since document style involves extra development effort, it should be considered only when RPC style imposes serious restrictions or the benefits of document style justify the extra effort. In order to reach a decision, the following questions might be helpful:

Is the service accessed through an interface based on procedure calls, and unlikely to be affected by future API changes?
Does the service require a request/response architecture?
Does the service exceed organization boundaries?
Is there any state maintenance required?
Is one of the parameters passed to the target application an XML document?
Do the parameters represent complex structures that may benefit from an XML document schema for validation?

Use document style to ease validation and use of documents

In cases where Web services need to pass or return XML documents (for example, a high-level business document) or objects with a complex structure, document style may be more appropriate. Passing the XML document as a string parameter in an RPC call postpones the validation of the XML document to the target application. This may cause valid calls with invalid parameters. Usage of document style allows for publishing an XML document schema and validation against that schema prior to calling the service. In the case of a high-level business document, the document's XML schema may be used to enforce high-level business rules.

When dealing with complex structures, a remote procedure service may have to deal with custom marshaling code while the application is still responsible for meticulously validating each element of the structure. If document messaging is used, then the application programmer can delegate validation to the document designer using an XML schema, and no custom marshaling code is required.

Use document style when maintaining application state

Consider document style Web services when a particular sequence of multiple procedure calls is involved to accomplish a complex business service. If a service consists of multiple procedure calls, then the service normally is not stateless and must maintain application state. Maintaining state between successive Web service requests may be difficult since most client platforms do not generate client stubs that support state information. In order to maintain state information beyond the scope of the request, additional logic has to be implemented in the source and target applications. This erodes the clear separation between Web service requester and Web service provider.

Alternatively, when a document style Web service is used, the contents of an entire transaction may be passed within one XML document. In this case the service is responsible for ensuring the proper sequence of procedure calls. State information only has to be maintained within the scope of this transaction.

It is also important to balance this approach against the need to keep the business objects to a reasonable size.

Use document style when changes to target API are likely

The rules of good design dictate that the method signature of an RPC style Web service interface should never change. In using document style there are less rigid rules concerning enhancements and changes to the XML schema without compromising the calling application. Therefore, document style provides more flexibility if there needs to be future modification to the target application API.

Use document style when late binding is required

RPC style Web services require rigid type specification agreed upon at service implementation. Document style Web services allow for run-time type specification of the object to be passed via the call. This allows for variation of the passed business object type depending on the context of the actual request. Validation of a passed document against an XML schema may be done either before or during the execution of a service request.

Use document style to publish external services

If a service implemented by an enterprise application is being published outside of the organization, the publisher has very little control over who is relying on the service. Since the consequences of any changes to the Web service interface (that means changes to the WSDL file) are not traceable outside of the organization, it may be better to use document style and support a common exchange protocol such as ebXML. See the next section for further details.

< Day Day Up >