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

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

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


Subject: ISSUE 83: Identifying wire format and operation selection



http://www.osoa.org/jira/browse/ASSEMBLY-83

On Sep 9, 2008, at 2:02 AM, Mike Edwards wrote:

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



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