OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bindings message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



Mike,  

overall that looks good to me, subject to the policy set attachment being straightforward in handling this case.  My main reaction to this is that having "dataBinding" be "the form that the data takes on the wire" seems a misuse of the term to me (not your fault).  Data binding to me refers to the entire process of taking a message in one form and transforming it into another, either from serialized form to that needed by an implementation or vice-versa, or possibly between implementation-required forms.

So perhaps it would be less confusing if we renamed the data binding element to something that more closely matches the definition above, and also omits the over-used "binding".  Possibilities include:

and others I'm sure.

Regards, Simon

Simon Holdsworth
STSM, SCA Bindings Architect; Master Inventor; OASIS SCA Bindings TC Chair
MP 211, IBM UK Labs, Hursley Park, Winchester SO21 2JN, UK
Tel +44-1962-815059 (Internal 245059) Fax +44-1962-816898
Internet - Simon_Holdsworth@uk.ibm.com



Mike Edwards/UK/IBM@IBMGB

14/08/2008 14:58

To
"OASIS Bindings" <sca-bindings@lists.oasis-open.org>
cc
Subject
[sca-bindings] [ISSUE 27] Updated Proposal to Resolve Bindings Issue 27 - "Identifying data binding and operation selection"






Folks,


The following is an updated proposed resolution of Bindings Issue 27 - "Identifying data binding and operation selection",

following comments from Bryan Aupperle and Simon Holdsworth.


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


In answer to Simon Holdsworth's points, this proposal does NOT attempt to address the question of per-operation settings.

The reason for this is that in the Policy TC there is an issue (Issue 15) which is proposing a means of applying external

attachment of policies to any aspect of SCDL - and that does include mechanics for addressing specific operations within

an interface.  I suggest that instead of inventing further operation-level SCDL here, that instead the "external attachment"

mechanism of Policy Issue 15 is used.  This proposal has been updated to add in the <operationSelector/> element that

Simon described.


Note that we in the Bindings TC need to 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.  I also leave out the question of specific forms of operationSelector.



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 />?
   <
operationSelector />?
<
/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:



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

a3) new Subsections, 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:


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

For details about specific databindings, 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:


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="databinding" ref="sca:Databinding" 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 Databinding and OperationSelector global elements and complex types after line 3843:


    <
element name="Databinding" type="sca:DatabindingType"/>
   
<complexType name="DatabindingType" 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




 







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












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








[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]