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