Simplifying%20Bindings

1
Simplifying Bindings

• Sanjiva Weerawarana
• May 14, 2003

2
Today

• ltdefinitions targetNamespacens1
• xmlnstnsns1gt
• ltinterface namei1gt
• ltoperation nameoi /gt
• lt/interfacegt
• ltbinding nameb1 interfacetnsi1gt
• -- interface-wide bindings --
• ltoperation nametnsoigt
• -- operation-specific bindings --
• ltinputgt .-- input-specific bindings
  -- lt/inputgt
• ltoutputgt .-- input-specific bindings
  -- lt/outputgt
• ltfaultgt .-- input-specific bindings
  -- lt/faultgt
• lt/operationgt
• lt/bindinggt

• ltservice names1 interfacetnsi1gt
• ltport namep1 bindingb1gt
• -- address --
• lt/portgt
• ltport namep2 bindingb2gt
• -- address --
• lt/portgt
• lt/servicegt
• lt/definitionsgt

3
Step 1

• Drop _at_interface from /definitions/binding
• Pros
• Removes redundancy of interface specification
• But remember that with our wonderful new
  overriding rules operation names are really
  global anyway
• Increases reusability of a binding
• Cons
• Once we wake up and do real overloading, we would
  lose the fact that operation specific stuff may
  be within a given interface
• Or can think of it as structural equivalence for
  interfaces

4
After Step 1

• ltdefinitions targetNamespacens1
• xmlnstnsns1gt
• ltinterface namei1gt
• ltoperation nameoi /gt
• lt/interfacegt
• ltbinding nameb1 interfacetnsi1gt
• -- interface-wide bindings --
• ltoperation nametnsoigt
• -- operation-specific stuff --
• ltinputgt .-- input-specific bindings
  -- lt/inputgt
• ltoutputgt .-- input-specific bindings
  -- lt/outputgt
• ltfaultgt .-- input-specific bindings
  -- lt/faultgt
• lt/operationgt
• lt/bindinggt

• ltservice names1 interfacetnsi1gt
• ltport namep1 bindingb1gt
• -- address --
• lt/portgt
• ltport namep2 bindingb2gt
• -- address --
• lt/portgt
• lt/servicegt
• lt/definitionsgt

5
Step 2

• Allow inlining of interface-wide bindings within
  a port make _at_binding optional
• Pros
• Makes the 80/20 case simpler
• Except if you have per-operation soapAction
  values
• Cons
• Have to define what happens if _at_binding is
  present and if you have inlined bindings
• Inlined ones win over the referenced ones is
  reasonable?
• Going from 80/20 case to wanting to define any
  operation specific bindings will be a nasty shock

6
After Step 2

• ltdefinitions targetNamespacens1
• xmlnstnsns1gt
• ltinterface namei1gt
• ltoperation nameoi /gt
• lt/interfacegt
• ltbinding nameb1 interfacetnsi1gt
• -- interface-wide bindings --
• ltoperation nametnsoigt
• -- operation-specific bindings --
• ltinputgt .-- input-specific bindings
  -- lt/inputgt
• ltoutputgt .-- input-specific bindings
  -- lt/outputgt
• ltfaultgt .-- input-specific bindings
  -- lt/faultgt
• lt/operationgt
• lt/bindinggt

• ltservice names1 interfacetnsi1gt
• ltport namep1 bindingb1gt
• -- address --
• -- interface-wide bindings --
• lt/portgt
• ltport namep2 bindingb2gt
• -- address --
• -- interface-wide bindings --
• lt/portgt
• lt/servicegt
• lt/definitionsgt

7
Step 3

• Define a default binding
• Most likely the moral equivalent of current SOAP
  doc/lit
• (To be considered further after the ltmessagegt
  evolution discussion concludes)
• Pros
• Makes the 80-20 case (IMHO) very simple
• Cons
• Makes it appear as if other bindings are 2nd class

8
After Step 3

• ltdefinitions targetNamespacens1
• xmlnstnsns1gt
• ltinterface namei1gt
• ltoperation nameoi /gt
• lt/interfacegt
• ltbinding nameb1 interfacetnsi1gt
• -- interface-wide bindings --
• ltoperation nametnsoigt
• -- operation-specific bindings --
• ltinputgt .-- input-specific bindings
  -- lt/inputgt
• ltoutputgt .-- input-specific bindings
  -- lt/outputgt
• ltfaultgt .-- input-specific bindings
  -- lt/faultgt
• lt/operationgt
• lt/bindinggt

• ltservice names1 interfacetnsi1gt
• ltport namep1 bindingb1gt
• -- address --
• -- interface-wide bindings --
• lt/portgt
• ltport namep2 bindingb2gt
• -- address --
• -- interface-wide bindings --
• lt/portgt
• lt/servicegt
• lt/definitionsgt

9
Step 4 Dealing with operation-specific
SOAPActions

• SOAPAction What if you want operation-specific
  soapAction values?
• Yes its deprecated
• Reality is different
• Define a default for computing SOAPAction
• Pros
• Widen the 80/20 to 89/11?
• Cons
• Encourages use of soapAction contrary to XMLP

10
A WSDL for the fitting case

• ltdefinitions targetNamespacens1
• xmlnstnsns1gt
• ltinterface namei1gt
• ltoperation nameoi /gt
• lt/interfacegt
• ltservice names1 gt
• ltport namep1gt
• -- address --
• lt/portgt
• ltport namep2gt
• -- address --
• lt/portgt
• lt/servicegt
• lt/definitionsgt

11
Summary

• Makes the simple case really simple
• Improves reusability of bindings
• Retains full flexibility of WSDL 1.1 like
  bindings
• No power is lost