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: Re: [sca-assembly] Issue 183 - discussion and proposal



Ashok,

Yes, those words exist - but not in the Assembly spec.  They are in the Policy spec.

There are 2 points relevant here:

a) Should the Policy spec be specifying anything normative in relation to the binding.sca?

My opinion is "no", since binding.sca is defined normatively in the Assembly spec.

b) As you rightly point out - should binding.sca be different from other bindings?

This IS a question for the Assembly TC and it can be dealt with under Issue 183.

Here are some thoughts:

1) binding.sca can be treated just like any other binding.  This implies that both intents and policySets
can apply to an instance of that binding.  I note that the current XSD for binding.sca does allow this, although
the pseudo-schema in the section describing binding.sca does not include them (I think we must change this)

This requires the removal of the words from the Policy spec.

I suggest adding words into the section of the Assembly spec which defines binding.sca, as shown at the bottom
of this email.


2) should there be any normative requirements placed on binding.sca implementations regarding support of
policy features?  This is where I was trying to head with the normative SHOULD I included in the text for resolving
Issue 143, which was removed.  Perhaps this notion is invalid, but I made the proposal in the interests of greater
portability.

However, to quote from the Web Services binding spec:

"The <bindingType> element associated with this binding MUST include the SOAP.1_1 intent in its @mayProvides or
 @alwaysProvides attributes. [BWS20035] The <bindingType> element associated with this binding SHOULD include
the SOAP.1_2 intent in its @mayProvides attribute. [BWS20036]s."

...which shows that there is some precedent for requiring support for specific intents.

My idea had been to require support for a small set of "core" intents relating to Security, such as confidentiality.
However, I can see the argument that this might be regarded as overly restrictive.


Proposed Updated Version of section 7.5 of the CD03-Rev4 of Assembly specification:
Note that this is a more significant update since I decided that once the pseudo-schema was updated, other things needed
proper explanation and I made this section more of the style of similar sections elsewhere in the Assembly spec.  It also
gained a missing normative statement - i.e. @URI makes no sense for binding.sca on a service.

8.5 SCA Binding

The SCA binding element is defined by the following schema.

<binding.ws name="xs:NCName"?
            requires="list of xs:QName"?
            policySets="list of xs:QName"?
            uri="xs:anyURI"? >
   <wireFormat ... />?
   <operationSelector ... />?
</binding.ws>

Snippet 7-2: binding.sca Pseudo-Schema

A binding.sca element has the attributes:

       uri (0..1) - has the semantic:
–        The @uri attribute can be omitted.
–        If a <binding.sca/> element of a component reference specifies a URI via its @uri attribute, then this provides a wire to a target service provided by another component.
                The form of the URI which points to the service of a component that is in the same composite as the source component is as follows:

                     <component-name>/<service-name>
–        The circumstances under which the @uri attribute can be used are defined in  section "Specifying the Target Service(s) for a Reference."
–        For a binding.sca of a component service, the @uri attribute MUST NOT be present [ASM90005]

       name (0..1) – a name for the binding instance (an NCName), as defined for the base <binding/> element type.

       requires (0..1) - a list of policy intents. See the Policy Framework specification [10] for a description of this attribute.
       policySets (0..1) – a list of policy sets. See the Policy Framework specification [10] for a description of this attribute.

A binding.sca element has the child elements:

       wireFormat (0..1) - a wireFormat to apply to the data flowing using the binding. binding.sca does not define any specific wireFormat elements.
       operationSelector(0..1) - an operationSelector element that is used to match a particular message to a particular operation in the interface.  binding.sca does not define any specific operationSelector elements


The SCA binding can be used for service interactions between references and services contained within the SCA Domain.
The way in which this binding type is implemented is not defined by the SCA specification and it can be implemented in different ways by different SCA runtimes.
The only requirement is that any specified qualities of service are implemented for the SCA binding type. Qualities of service for <binding.sca/> are expressed using intents
and/or policy sets following the rules defined in the SCA Policy specification [SCA-POLICY].

The SCA binding type is not intended to be an interoperable binding type. For interoperability, an interoperable binding type such as the Web service binding is used.

An SCA runtime has to support the binding.sca binding type. See section 13.2.

A service definition with no binding element specified uses the SCA binding (see ASM50005 in section 4.2 on Component Service).
<binding.sca/> only has to be specified explicitly in override cases, or when a set of bindings is specified on a service definition and the SCA binding needs to be one of them.

If a reference does not have a binding subelement specified, then the binding used is one of the bindings specified by the service provider, as long as the intents attached to the reference and the service are all honoured, as described in Section 4.3 on Component Reference.

If the interface of the service or reference is local, then the local variant of the SCA binding will be used. If the interface of the service or reference is remotable, then either the local or remote variant of the SCA binding will be used depending on whether source and target are co-located or not.








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



From: ashok malhotra <ashok.malhotra@oracle.com>
To: OASIS Assembly <sca-assembly@lists.oasis-open.org>
Date: 27/10/2009 23:04
Subject: [sca-assembly] Issue 183





Dave found the words I was looking for during the call ...

Lines 1120-1122 of the Assembly spec (CD04) say:
"An exception is binding.sca which is configured entirely by the intents
listed in its @mayProvide and @alwaysProvides lists. There are no
policySets with appliesTo="binding.sca".

Thus, it seems to me, the central point to be discussed is whether
binding.sca is different from other bindings and
in what way.  If it is not significantly different, then the rules laid
out in the Policy spec for all bindings should apply to it. If it is
different, then that may impact whether policySets can be attached to it
and how attached intents are
satisfied.
--
All the best, Ashok

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php









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]