120 likes | 242 Vues
This proposal outlines a new syntax for web service operations aimed at simplifying the current complex specifications. It identifies problems in the existing system, where users need to remember pattern URIs and message references, leading to potential errors. The suggested syntactic shortcuts would make input/output definitions optional and utilize direction as a means to imply message reference. By introducing these changes, the proposal seeks to enhance usability and reduce redundancy in designing web service interfaces and bindings, ultimately making development processes more efficient and error-resistant.
E N D
Proposal for Shortcut Syntax for Simple Operations Sanjiva Weerawarana September 21, 2003
Status Quo <interface name=“xs:NCName” extends=“list of xs:QName”? encodingStyleDefault=“xs:anyURI”?> <operation name=“xs:NCName” pattern=“xs:anyURI” encodingStyle=“xs:anyURI”?> <input messageReference=“xs:NCName” body=“xs:QName”? headers=“list of xs:QName”?/>* <output messageReference=“xs:NCName” body=“xs:QName”? headers=“list of xs:QName”?/>* <infault .. not fully defined .. />* <outfault .. not fully defined .. />* </operation> </interface>
Problems with Status Quo • User has to remember pattern URIs • User has to know contents of pattern spec to know proper values for @messageReference • “input” and “output” are redundant as the pattern defines the direction of the message; the user cannot change it and hence its an opportunity for errors • “infault” / “outfault” separation similarly redundant and error-prone
Rationale for Proposal • Requiring users to remember pattern URIs for the commonly used patterns is unacceptable • Requiring users to remember the names chosen by the pattern authors for the messages is unacceptable • It would be better if error-prone redundancies were eliminated • Keep the simple case simple
Syntactic Shortcuts for Supported Patterns • For In-only and In-Out patterns there is at most one message in each direction • Thus, value of message reference is implied by the direction • There may be >= 0 fault messages for In-Out • Since only one set of faults, value of message reference is unnecessary from the client point of view
Rules for Syntactic Shortcuts • Make (input|output)/@messageReference optional and say the direction implies the reference because only one in each direction • Say order of input/output significant (as today) • Make @pattern optional and say its value is computed based on order of input/output and whether both or only one is present
Proposal for Simplified In-only and In-Out Patterned Interactions <interface name=“xs:NCName” extends=“list of xs:QName”? encodingStyleDefault=“xs:anyURI”?> <operation name=“xs:NCName” encodingStyle=“xs:anyURI”?> <input body=“xs:QName”? headers=“list of xs:QName”?/> <output body=“xs:QName”? headers=“list of xs:QName”?/>? <fault details=“xs:QName”/>* </operation> </interface>
User familiarity based on perceived and real similarity to WSDL 1.1 syntax No redundancy This will be defined as a syntactic shortcut ONLY – not a new or special component ?? Simplified OperationsPros & Cons
Status Quo Should be “messageReference” <binding name=“xs:NCName” interface=“QName”?> ... interface-wide bindings ... <operation name=“xs:QName”> ... operation-wide bindings ... <input name=“xs:NCName”> ... input bindings ... </input>* <output name=“xs:NCName”> ... output bindings ... </output>* <infault .. not fully defined .. />* <outfault .. not fully defined .. />* </operation> </binding>
Shortcuts • Once interfaces have shortcuts then those naturally apply in bindings • Make (input,output)/@messageReference optional