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:  

From:
ashok malhotra <>

To:
OASIS Assembly <>

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