Source Scenario: S003 Request/Response
The Request/Response scenario is one of the more common uses of Web services. It is sometimes confused with S004 (RPC), since the effect is very similar. In Request/Response, the sender sends (zero or more) documents to the receiver and the receiver returns zero or more documents as a result. The key emphasis here is on document exchange--in RPC, the underlying service's parameter list is passed in order to invoke functionality directly. With document processing, the link to underlying business logic is much more hidden.
An example of this scenario would be sending a purchase order and receiving a purchase order acknowledgement (a receipt essentially).
The key point of this scenario as written is the use of "correlation ids" to identify specific messages in the SOAP Header. Some form of unique message ID is inserted into the originating message and the receiver stores this and returns the same ID in the specific response. It also generates a new unique ID for the response (so that the execution chain can continue to grow).
There are no specific internationalization concerns in the text of this scenario as written.
Request/Response has several general internationalization considerations that implementers should consider.
First, the use of correlation IDs is very similar to the concept of a "session" in human-interactive systems. There may or may not be some sort of "state" maintained by either the receiver or the sender. In any case, in this pattern there is a way to maintain specific settings associated with the processing for the sender.
If the process represented by the receiver is locale-affected or allows language or locale negotiation (see Framework), the specific settings applied to the processing should be persisted, either in the state mechanism in the receiver or by continuing to exchange the additional headers necessary to maintain the state. If possible, there should be some sort of relationship between a specific correlation ID and the locale or language preference.
The possibilities for this include:
Note that there may be several documents included in a single request or response. These documents may have seperate international preferences associated with them: the documents must in that case be designed to convey the specific requirements.
For example, if the sender aggregates purchase orders from several regions before sending them in a batch to a supplier (the receiver), each purchase order might need to include a separate "preferred language" for human readable messages in the response. A PO Acknowledgement might include a human readable status message (which is not a SOAP Fault or error, but part of the business logic), such as "unrecognized customer ID" or "account not activated". If the sender sent three purchase orders-- one from Japan, one from Mexico and one from Belgium--the acknowledgements might need to include human readable messages in three or four different languages, with separate preferences for each acknowledgement.
A SOAP Fault returned to the sender, by contrast, might need to match the language preference of that system's administrator (and not the language preference of the purchase orders involved). This suggests that the implementation include a language preference in the request header which indicates the preferences of the sender and that the application handle language preferences internally via some other mechanism (such as user profiles).
Addison Phillips (aphillips@webmethods.com)
$Id: ws-request-response-pattern-scenario.html,v 1.01 2003/06/19 20:27:21
aphillip Exp $
