Eliminating Eliminating Sanjiva Weerawarana WSDL WG F2F – Raleigh, NC July 30, 2003

Overview Good & bad of Good & bad of Solution space Solution space Proposal Proposal Retaining RPC capabilities Retaining RPC capabilities Conclusion Conclusion

Advantages of Advantages of Allows clear specification of multiple things to send/receive Allows clear specification of multiple things to send/receive Cleanly supports multiple type systems Cleanly supports multiple type systems Using multiple parts maps naturally to method signature model of traditional IDLs Using multiple parts maps naturally to method signature model of traditional IDLs

Problems with Problems with Lack of flexibility w.r.t. data sent/received Lack of flexibility w.r.t. data sent/received –No optional parts etc. Complexity due Complexity due –Two ways to do anything encourages profiling Inconsistent usage to represent method signatures Inconsistent usage to represent method signatures –Advantage of natural mapping to traditional IDLs is lost, at least partially

Solution Space Fix s problems Fix s problems –Add optionality etc., see next page –Remove one –Force (how?) signatures to be described in one way Replace with something else Replace with something else

Improving Improving (Sanjivas old proposal) (Sanjivas old proposal) Drop it and inline s Drop it and inline s Add cardinality Add cardinality In effect, duplicate functionality of xsd:complexType In effect, duplicate functionality of xsd:complexType

Improving cont. Even if we do this, how do we force people to describe function signatures with multiple s except with a single element? Even if we do this, how do we force people to describe function signatures with multiple s except with a single element? –This is not a religious argument: both these approaches for describing signatures are in use today.

Proposal This is a summary proposal – it does not go through the evolutionary approach of my ed proposal This is a summary proposal – it does not go through the evolutionary approach of my ed proposal –See that if you want to see how to get here

Proposal - Summary Drop Drop Let / / point to a single as the thing to send/receive Let / / point to a single as the thing to send/receive Define rules to allow one to capture signature information in how the schemas are defined Define rules to allow one to capture signature information in how the schemas are defined

Proposed Syntax <input [body=qname] <input [body=qname] [headers=list-of-qnames]/> [headers=list-of-qnames]/> [<output [body=qname] [<output [body=qname] [headers=list-of-qnames]/>] [headers=list-of-qnames]/>] <fault details=qname <fault details=qname [headers=list-of-qnames]/>* [headers=list-of-qnames]/>* </interface> (and similary for other MEPs)

SOAP Binding [<output [body=qname] [<output [body=qname] [headers=list-of-qnames]/>] [headers=list-of-qnames]/>] <fault details=qname <fault details=qname [headers=list-of-qnames]/>* [headers=list-of-qnames]/>* </interface>

Support of SOAP 1.2 Only one element inside Only one element inside –OK because WS-I has decreed so No direct support for SOAP Encoding No direct support for SOAP Encoding –OK because its deprecated to adjuncts –OK because WS-I has decreed so

Java Binding – JAX-Sanjiva-1 interface { public Element (Element input); public Element (Element input);} (or replace element with your favorite Infoset representation, e.g., XMLBeans, SAX, …)

Java Binding – JAX-Sanjiva-2 class InputType { … xsd -> Java mapping of input element … … xsd -> Java mapping of input element …} class OutputType { … xsd -> Java mapping of output element … … xsd -> Java mapping of output element …} interface { public OutputType (InputType input); public OutputType (InputType input);}

Capturing Method Signatures Previous bindings may not be natural enough Previous bindings may not be natural enough –Consider taking int foo (float, person) and round- tripping signature1 -> WSDL -> signature2 signature1 -> WSDL -> signature2 –Signatures 1 & 2 wont look similar right now –Not good enough Whats needed is a way to capture how the signature is used to derive the input/output elements used in operations Whats needed is a way to capture how the signature is used to derive the input/output elements used in operations

Capturing Method Signatures (cont.) How an is mapped to a signature is not our business How an is mapped to a signature is not our business –Language bindings will do that, e.g., JAX- Roberto –However, it would be nice if we provide sufficient information, for one who cares about it, to recover the original signature

Proposal Whats needed is a way to capture how the signature is used to derive the input/output elements used in operations Whats needed is a way to capture how the signature is used to derive the input/output elements used in operations Add an optional hint to allow one to indicate the rules that were followed in defining the schemas Add an optional hint to allow one to indicate the rules that were followed in defining the schemas – – We define one normative We define one normative –

Rules No default value No default value If not given then no information about the "style" of the operation's elements is available If not given then no information about the "style" of the operation's elements is available

@encodingStyle= The input and output elements have been defined according to a pattern indicated by these rules. The input and output elements have been defined according to a pattern indicated by these rules. Input/output elements contain only local element children (i.e., no global elements allowed). (No etc. allowed? Not sure but probably should say so.) Input/output elements contain only local element children (i.e., no global elements allowed). (No etc. allowed? Not sure but probably should say so.) Input element's name's localPart and are the same. Input element's name's localPart and are the Output element's name's localPart is Output element's name's localPart is Input and output elements are both in the same namespace. Input and output elements are both in the same namespace. The child elements of input and output represent input and output parameters of the operation. (" " in WSDL 1.1) The child elements of input and output represent input and output parameters of the operation. (" " in WSDL 1.1) If there exists foo such that there are child elements named foo in both input and output elements, then that represents an in/out parameter. If there exists foo such that there are child elements named foo in both input and output elements, then that represents an in/out parameter. If there does not exist any such foo in both elements then all the parameters are input-only and/or output-only as appropriate (depending on whether they're in the input or output element). If there does not exist any such foo in both elements then all the parameters are input-only and/or output-only as appropriate (depending on whether they're in the input or output element).