sca-bindings message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: [sca-bindings] [ISSUE 27] Updated Proposal to Resolve Bindings Issue 27 - "Identifyingdata binding and operation selection"
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: "OASIS Bindings" <sca-bindings@lists.oasis-open.org>
- Date: Thu, 14 Aug 2008 14:58:14 +0100
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:
- databinding (0..1) - a
databinding to apply to the data flowing using the binding. See the
databinding 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 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.
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="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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]