[ISSUE 48] Discussion and Proposal for Resolution

[Mike Edwards <mike_edwards@uk.ibm.com>]

Folks,

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.

DEBATE ON THE CURRENT FUNCTIONALITY
IMPLIED BY THE SPECIFICATION

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 5.3.1.1 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 5.3.1.1 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 5.3.1.1 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 5.3.1.1 following that infamous paragraph

above....

PROPOSAL FOR RSOLUTION OF ISSUE
48

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
useful.






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