[NEW ISSUE] Identifying wire format and operation selection

[Mike Edwards <mike_edwards@uk.ibm.com>]

Raiser:        
                Mike Edwards

Target:        
                SCA Assembly Specification

Description:

We need a way to identify how the business data is translated
into the wire representation of each of the binding types. 
We also need to have a way to identify how incoming data
is inspected and the operation that is desired is deduced from the incoming
request.

The reason that this issue is raised in the Assembly TC
is that it affects sections of the Assembly specification that deal with
<binding/> elements.

This issue has been raised from the Bindings TC who have
considered and approved the proposal outlined below.


Proposal:


 In SCA, the
data wireFormat (ie the format of the data as carried by a particular transport
binding) is defined by 
means of a <sca:wireFormat/> element, which is a child element of
the <binding/> element. 

There is an abstract <wireFormat/> element in the sca schema, which
any specific wireFormat extends by means of a  
substitution group, to give a particular <wireFormat.xxx/> element.
 This proposal does not attempt to define the details of
any of the specific wireFormats.  Specific wireFormats will be defined
through separate issues raised against appropriate
Bindings specifications. 

A specific wireFormat may be unique to one SCA binding or it may apply
to multiple SCA bindings. 

Detailed proposal material follows - unfortunately it requires a set of
changes to the SCA Assembly specification, since the
general description of SCA Binding elements is held there.  The following
material deals with the specifications at these levels:

1) sca-assembly-1.1-spec-cd01-rev1.doc 
2) sca-wsbinding-1.1-spec-WD-03.doc 
3) sca-jmsbinding-1.1-spec-WD-03.doc 

A) Material for the Assembly Specification 

a1) replace the <binding/> element, following each of lines 2646,
2650, 2663, 2667, with the following: 

<binding uri="xs:anyURI"?
name="xs:NCName"?
  
      requires="list
of xs:QName"? policySets="list
of xs:QName"?/>*
 <wireFormat
/>?
 <operationSelector
/>?
</binding>

(this makes the assumption that policy cannot be applied separately to
a wireFormat - policy is inherited from the containing
binding element)

---------------------------------------- 
a2) add, following line 2706 

A binding element has the following child elements:

• wireFormat (0..1) - a wireFormat to apply to the data flowing using the binding.  See the wireFormat section for details.
• operationSelector(0..1) - an operationSelector element that is used to match a particular message to a particular operation in the interface

---------------------------------------------------------
a3) new Subsections, following line 2733 

8.6 WireFormat 

A wireFormat is the form that a data structure takes when
it is transmitted using some communication binding.  Another way to
  
describe this is "the form that the data takes on the wire".
 A wireFormat can be specific to a given communication method, or
it may be general, applying to many different communication methods.  An
example of a general wireFormat is XML text format.

Where a particular SCA binding can accommodate transmitting data in more
than one format, the configuration of the binding MAY
include a definition of the wireFormat to use.  This is done using
an optional <sca:wireFormat/> subelement of the <binding/>
element. 
Where a binding supports more than one wireFormat, the binding defines
one of the wireFormats to be the default wireFormat
which applies if no <wireFormat/> subelement is present.

The base sca:wireFormat element is abstract and it has no attributes and
no child elements.  For a particular wireFormat, an
extension subtype is defined, using substitution groups, for example:

• <sca:wireFormat.xml/>
• A wireFormat that transmits the data as an XML text datastructure
• <sca:wireFormat.jms/>
• The "default JMS wireFormat" as described in the JMS Binding specification

Specific wireFormats can have elements that include either attributes or
subelements or both.   
For details about specific wireFormats, see the related SCA Binding specifications.

8.7 OperationSelector 

An operationSelector is necessary for some types of transport
binding where messages are transmitted across the transport
without any explicit relationship between the message and the interface
operation to which it relates.  SOAP is an example of
a protocol where the messages do contain explicit information that relates
each message to the operation it targets.  However,
other transport bindings have messages where this relationship is not expressed
in the message or in any related headers 
(pure JMS messages, for example).  In cases where the messages arrive
at a service without any explicit information that maps
them to specific operations, it is necessary for the metadata attached
to the service binding to contain the required mapping 
information.  The information is held in an operationSelector element
which is a child element of the binding element. 

The base sca:operationSelector element is abstract and it has no attributes
and no child elements.  For a particular operationSelector, an
extension subtype is defined, using substitution groups, for example:

• <sca:operationSelector.XPath/>
• An operation selector that uses XPath to filter out specific messages and target them to particular named operations.

Specific operationSelectors can have elements that include either attributes
or subelements or both.   
For details about specific operationSelectors, see the related SCA Binding
specifications. 

------------------------------------------------------------------------
a4) Changes/additions to the SCA XML Schemas 

Change the definition of the Binding complex type (line 3820) to:

  <complexType
name="Binding"
abstract="true">
     <sequence>
        <element
name="wireFormat"
ref="sca:WireFormat"
minOccurs="0"
maxOccurs="1"
/>
       
<element name="operationSelector"
ref="sca:OperationSelector"
minOccurs="0"
maxOccurs="1"
/>    
    
        <element
name="operation"
type="sca:Operation"
minOccurs="0"
maxOccurs="unbounded"
/>
     </sequence>
     <attribute
name="uri"
type="anyURI"
use="optional"/>
     <attribute
name="name"
type="NCName"
use="optional"/>
     <attribute
name="requires"
type="sca:listOfQNames"
use="optional"/>
     <attribute
name="policySets"
type="sca:listOfQNames"
use="optional"/>
 </complexType>

add WireFormat and OperationSelector global elements and complex types
after line 3843: 

  <element
name="WireFormat"
type="sca:WireFormatType"/>
  <complexType
name="WireFormatType"
abstract="true">
  
    <sequence>
       <any
namespace="##other"
processContents="lax"
minOccurs="0"
maxOccurs="unbounded"
/>
    </sequence>
    <anyAttribute
namespace="##other"
processContents="lax"/>
  </complexType>

  <element
name="OperationSelector"
type="sca:OperationSelectorType"/>
  <complexType
name="OperationSelectorType"
abstract="true">
  
    <sequence>
       <any
namespace="##other"
processContents="lax"
minOccurs="0"
maxOccurs="unbounded"
/>
    </sequence>
    <anyAttribute
namespace="##other"
processContents="lax"/>
  </complexType>



Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
Email:  mike_edwards@uk.ibm.com

---

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU