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: [ISSUE 48] Discussion and Proposal for Resolution


This is a follow-up on some debate that has already taken place on Issue 48 at a couple of recent meetings.

The Title of Issue 48 is "Defaulting composite reference targets to internal components"

....and the essence of the idea behind the issue is that for a Composite Reference, it should be possible to
indicate that IF the Composite Reference is NOT wired by a higher level Component that is using the
Composite as its implementation, THEN the composite reference is wired to a service contained within
the composite itself.  That internal service thus becomes a "default target" for the composite reference, that
is used unless the higher level component provides some alternative target.


Before proposing any resolution for Issue 48, it is necessary to discuss and clarify the current functionality
defined in the specification.  It was clear from the debate that took place on one of the calls that there are
differing views on this - which implies that the current text is not clear.

In essence, one side of this debate takes the view that the functionality called for by Issue 48 is ALREADY
SUPPORTED by the current specification.  The other side of the debate is that this is not so.

The debate hinges on the interpretation of sections 5.3.1 and which deal with Specifying Target
Services for a Reference - and more particularly as to the treatment of Promotions of a Component
Reference by a Composite Reference.

Section deals with the multiplicity of a reference - and provides restrictions on the number of
targets allowed for a reference which has one of the 4 allowed multiplicity settings.

Section also deals with Promotion (in fact, this is the only section which deals with it), in the
infamous final paragraph:

"Where a component reference is promoted by a composite reference, the promotion MUST be
treated from a multiplicity perspective as providing 0 or more target services for the component
reference, depending upon the further configuration of the composite reference. These target
services are in addition to any target services identified on the component reference itself, subject
to the rules relating to multiplicity."

I would like to bring everyone's attention to that final sentence. "These target services are IN
ADDITION...".  I don't think that this wording is at all vague. It says that you ADD the target service(s)
identified by the configuration of the composite reference to any target service(s) identified by the
configuration of the component reference.  In no way can this be interpreted as "REPLACE".

From this, I derive the following:

IF there is a component reference with multiplicity 1..1 and the component reference is configured
with a single target service (via its @target attribute) AND the same component reference is also
promoted by a composite reference, which itself is configured with a single target service, THEN
the component reference is configured with 2 target services ("ADD") and this is in violation of the
multiplicity constraint on the component reference - THIS IS AN ERROR.

IF instead, the component reference has multiplicity 1..n, with one target service configured on the
component reference itself and a second target service identified by a composite reference which
promotes the compoennt reference, then the component service is configured with 2 services
("ADD") and this is fine - the component reference is wired to BOTH services, as allowed by the
multiplicity constraint.

For me, nothing can be clearer.  It is what was intended when this section of the spec was created
and it is also the reason why Mike Rowley raised Issue 48 in the first place. ie IF we want to provide
the idea of an "internal default" for a composite reference, then this means adding something to
the current spec.

I would be happy to add the example above to the specification (as a non-normative example) to
help clarify things.  This can be done at the end of section following that infamous paragraph


OK, having got the interpretation of the current specification out of the way, let us look to the way in
which to resolve Issue 48.

There are two basic options:

A) Don't provide the function that Issue 48 calls for.  ie "CLOSE WITH NO ACTION"

B) Provide the function that Issue 48 calls for.  ie Provide an internal default for a Composite Reference

The proposal in the Issue itself is close to what would be needed:

- add an attribute to CompositeReference, called @internalDefault
- internalDefault must contain the URI of a service within the composite ("componentName/serviceName")
- the target service identified by @internalDefault MUST be compatible with the CompositeReference
(ie matching interfaces and matching Intents/Policies)
- the multiplicity of the CompositeReference MUST be either 0..1 or 0..n (there seems no point whatsoever
in allowing 1..1 or 1..n, since those force the using component to wire the reference)

- the semantics of @internalDefault is that IF the using Component does not wire the CompositeReference,
THEN the service identified by the @internalDefault is used to wire all the internal component references
that are promoted by the CompositeReference.  (in essence, from the "inside", the CompositeReference
looks like a 1..1 or 1..n reference - it always provides at least one target service).  IF the using Component
does wire the CompositeReference THEN the target service(s) so identified are used to wire the
internal component references that are promoted by the CompositeReference and the service identified
by @internalDefault is ignored.

Which of these 2 options am I in favour of?  I'm firmly on the fence.  I have not seen much demand for this
capability, although I agree that it is a neat piece of function.  One thing in favour of Close no Action - this
is an additive piece of function and it can always be added to the spec later if it turns out to be really

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]