Re: [sca-bindings] [ISSUE 27] Proposal to Resolve Bindings Issue27 - "Identifying data binding and operation selection"

Hi Mike,

From reading through your proposal, this doesn't seem to resolve issue
27 - the problem still exists for JMS and SCA binding until Assembly
has approved it, and then we have to update our documents to reflect
what they approve.  If, for example, the assembly TC decides that this
is beyond the scope of standardization, then we may still wish to use
the approach you outline below as defined purely by the bindings TC,
perhaps limited to just the JCA specification?

Other than that, the proposal looks like a decent one for the assembly
TC to tackle.

-Eric.

Mike Edwards wrote:

  Folks,
  

  

  The following is a proposed
resolution
of Bindings Issue 27 - "Identifying data binding and operation
selection".
  

  

  Note: This proposal does NOT aim to
solve the question of the form of the data binding in the
implementation
code.
  

  That is a problem for the various
SCA
language bindings TCs to consider and to solve, since those forms of
language
  

  bindings are specific to each
language
(eg in Java, XML on the wire might be represented in the code as JAXB
objects
  

  or as SDOs).
  

  

  Note that we in the Bindings TC can
vote on this resolution, but since it involves changing stuff in the
Assembly
spec, the
  

  main outcome will be an action item
to raise and progress an issue in the Assembly TC  :-(
  

  

  I leave out the question of defining
specific databindings like databinding.xml, databining.jms - I think
that
we should raise
  

  issues separately for each of these.
  

  

  

  Proposal:
  

  

  In SCA, the form of databindings on
the wire (ie the format of the data as carried by a particular
transport
binding) is defined by
  

  means of a <sca:databinding/>
element, which is a child element of the <binding/> element.
  

  

  There is an abstract
<databinding/>
element in the sca schema, which any specific databinding extends by
means
of a 
  

  substitution group, to give a
particular
<databinding.xxx/> element.  This proposal does not attempt
to define the details of
  

  any of the specific databindings.
 Specific
databindings will be defined through separate issues raised against
appropriate
  

  Bindings specifications.
  

  

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

  

  Detailed proposal material follows -
unfortunately it will require 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"?/>*
  

  
       
<databinding
  />?
  

  
</binding>
  

  

  (this makes the assumption that
policy
cannot be applied separately to a databinding - policy is inherited
from
the containing
  

  binding element)
  

  

  ----------------------------------------
  

  a2) add, following line 2706
  

  

  A binding element has the following
child elements:
  

  

  
    
databinding (0..1)
- a
databinding to apply to the data flowing using the binding.  See the
      databinding section for details.

  
  

  

  ---------------------------------------------------------
  

  a3) new Subsection, following line
2733
  

  

  8.6 Databinding
  

  

  A databinding 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 databinding can be specific to
a given communication method, or
  

  it may be general, applying to many
different communication methods.  An example of a general databinding
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
databinding
to use.  This is done using an optional <sca:databinding/>
subelement
of the <binding/> element.
  

  Where a binding supports more than
one
databinding, the binding defines one of the databindings to be the
default
databinding
  

  which applies if no
<databinding/>
subelement is present.
  

  

  The base sca:databinding element is
abstract and it has no attributes and no child elements.  For a
particular
databinding, an
  

  extension subtype is defined, using
substitution groups, for example:
  

  
    
<sca:binding.xml/>

A databinding that transmits the data as an XML text datastructure

  
  
    
<sca:binding.jms/>

The "default JMS databinding" as described in the JMS Binding
specification

  
  

  Specific databindings can have
elements
that include either attributes or subelements or both.  
  

  For details about specific
databindings,
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="databinding"
  type="sca:Databinding"
  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 a Databinding complex type after
line 3843:
  

  

  

  
    <complexType
  name="Databinding"
  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:  

  
  

  

  
  

  

  

  
  
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