Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Eliminating Eliminating Sanjiva Weerawarana WSDL WG F2F – Raleigh, NC July 30, 2003."— Presentation transcript:

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

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

3 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

4 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 to @element vs. @type Complexity due to @element vs. @type –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

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

6 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

7 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.

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

9 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

10 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)

11 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>

12 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

13 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, …)

14 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);}

15 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

16 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

17 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 value @encodingStyle We define one normative value @encodingStyle –http://www.w3.org/2003/ws/desc/rpc

18 Rules for @encodingStyle 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

19 @encodingStyle= http://www.w3.org/2003/ws/desc/rpc 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 operation/@name are the same. Input element's name's localPart and operation/@name are the same.operation/@name Output element's name's localPart is concat(operation/@name,"Response") Output element's name's localPart is concat(operation/@name,"Response")operation/@name,"Response 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).


Download ppt "Eliminating Eliminating Sanjiva Weerawarana WSDL WG F2F – Raleigh, NC July 30, 2003."

Similar presentations


Ads by Google