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"
- From: Simon Holdsworth <simon_holdsworth@uk.ibm.com>
- To: Mike Edwards <mike_edwards@uk.ibm.com>
- Date: Thu, 14 Aug 2008 15:23:06 +0100
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:
- serializedForm
- dataSerialization
- wireFormat
- wireRepresentation
- serializationConfiguation
- serialization
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:
- 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
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]