DST Service Client
From OpenLiberty.org Wiki
Contents |
org.openliberty.services.DSTClient
The ID-WSF Data Services Template ("DST") facilitates data messaging interaction. It defines the communications protocol by which Web Service Consumers ("WSC") communicate with Web Service Providers ("WSP").
Message Status
Message status is reported in two ways via a number of different codes: At the SOAP layer and at the XML element layer. At the SOAP layer, there is an ID-* Fault message. This is used in the following circumstances
- WSP does not recognize any RequestElement in the SOAP body (IDStarMsgNotUnderstood)
- WSC receives an empty or malformed notification (IDStarMsgNotUnderstood)
- WSP notices that the requesting party is not allowed to make requests (ActionNotAuthorized)
- Unexpected error preventing proper handling of the message body (UnexpectedError)
- Uesr-defined ID-* message case(s) (UnexpectedError)
At the XML element layer, there are two levels of status elements:
1. The "top-level" <Status> element must contain one of the following values:
OK Partial Failed
2. The "second-level" <Status> element contains one of over 50 codes, including:
ActionNotAuthorized AggregationNotSupported AllReturned ChangeHistoryNotSupported ...
There can also be timing related errors (e.g., back-end processing hasn't responded fast enough), in which case the WSP should return a second-level status of:
TimeOut
Finally, there may be errors for which no status code exists to identify the error. In this case the WSP should return:
UnspecifiedError
Or, in the case of a completely unexpected case:
UnexpectedError
Interaction Example Diagram
Notes
Message Linking
Message are "linked" (i.e., responses associated with corresponding requests) via IDs:
- At the SOAP level, there are two headers used: <wsa:messageID> and <wsa:RelatesTo>
- Inside a message, XML attributes itemID and itemIDRef are used.
- The xs:ID XML attribute is used to link parts of different messages together with their referenced elements in other messages.
Resources
Resources associated with services are accessed through the following mechanisms:
- Implicitly via PAOS exchange
- From the <TargetIdentity> SOAP header
- Using supplied credentials (to access the Principle's own resource)
- From an endpoint (the service can choose to offer different endpoints for each resource being used)
The WSC:
- Can specify processing rules to indicate whether all message elements must succeed in order for the overall response to have value. If this is true, the WSP will return Failure if any element fails. Otherwise, it will return Partial if some, but not all elements are successful.
- Can time-stamp request messages in order to track response and/or activity timing. If the WSC does time-stamp a RequestElement, the WSP must do the same in the corresponding ResponseElement.
- May request further status information using the Result Query message. If issued, the WSP must return a positive response (i.e., no response is not considered failure) and any fault associated with the supplemental request must be stored in a secondary status code (leaving the original status code unaffected).
The WSP:
- Can indicate to the Discovery Service that it does not support certain requests that would ordinarily be supported based on the definition of the service it is providing. This is done by using the following keywords to exclude the corresponding request types:
urn:libery:dst:noQuery urn:liberty:dst:noCreate urn:liberty:dst:noDelete urn:liberty:dst:noModify
Questions:
- When is the <wsa:messageID> SOAP header used vs. the <wsa:RelatesTo> header?
- Similarly, when is the itemID XML attribute used vs. the itemIDRef attribute?
- How are the processing rules specified to a WSP?
