sca-assembly message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-assembly] Overridable and multiplicity, was Re: [sca-assembly] NEWISSUE: Incorrect usage of MAY Keyword
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: sca-assembly@lists.oasis-open.org
- Date: Fri, 24 Apr 2009 10:37:11 +0100
Folks,
I think Simon has described it well.
Let's go with the proposal outlined
below...
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:
| Simon Nash <oasis@cjnash.com>
|
To:
| sca-assembly@lists.oasis-open.org
|
Date:
| 24/04/2009 10:14
|
Subject:
| Re: [sca-assembly] Overridable and multiplicity,
was Re: [sca-assembly] NEW ISSUE: Incorrect usage of MAY Keyword |
Mike Edwards wrote:
>
> Folks,
>
> A problem with defaulting the @multiplicity attribute value of a
> <composite/> <reference/> to use the
> multiplicity attribute of a promoted <component/> <reference/>
is where
> there are multiple promoted
> references and the promoted references have different @multiplicity
> values - which one do you use?
>
> Imagine a case where the composite reference promotes 4 references
with
> the multiplicities set to:
>
> 0..1
> 1..1
> 0..n
> 1..n
>
> What value does the @multiplicity of the composite reference get?
>
> I think it's 1..1
>
> I think that the general rule is:
>
> The lower bound is 0 if the lower bound of all the promoted references
> is 0, otherwise it is 1
>
> The upper bound is n if the upper bound of all the promoted references
> is n, otherwise it is 1.
>
I agree with all of the above. Based on the principle that promotion
of a reference can restrict multiplicity but not extend it, it makes
sense for the default multiplicity of the composite reference to be
the least restrictive setting that satisfies this constraint.
> The worse thing is that the multiplicity changes depending on the
set of
> promoted references
> which may lead to problems with the higher level composition.
>
Any such change involves making a change to the definition of the
composite reference and it could be argued that this isn't very
different from changing the @multiplicity setting on the composite
reference. However I accept that changing the default multiplicity
if a promoted reference is added or removed could give rise to
subtle unintended errors.
> Which may argue for requiring the multiplicity to be specified at
all
> times, with no default.
>
Most of the time, only a single component reference will be promoted.
For this common case, it is simple and natural to say that the
composite reference multiplicity defaults to the component reference
multiplicity.
I think it would make sense to also do this when promoting multiple
component references that all have the same multiplicity.
The above two cases should acount for well over 95% of all reference
promotions. For the other cases where multiple component references
with different multiplicities are being promoted, there is a good case
for not having a default but requiring the composite reference to
specify @multiplicity explicitly. I think this would be better than
choosing an arbitrary default of 1..1.
> At least having a fixed default avoids this problem and a tool can
> always verify that the
> multiplicities are correctly matched within the composite....
>
A tool could also look at what references are being promoted and
apply the above algorithm to compute the default. I'm more concerned
about whether this algorithm is consumable/understandable by humans
than whether it's implementable by tools.
In summary, for the simple case of promoting a single reference or
multiple references with the same multiplicity, I think the
composite reference multiplicity should default to the component
reference multiplicity. For the complex case of promoting
multiple component references with different multiplicities,
I think the simplest approach is to require @multiplicity to be
present on the composite reference.
Simon
>
> 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:
Simon Nash <oasis@cjnash.com>
> To:
sca-assembly@lists.oasis-open.org
> Date:
23/04/2009 11:44
> Subject:
Re: [sca-assembly] Overridable and multiplicity, was
Re:
> [sca-assembly] NEW ISSUE: Incorrect usage of MAY Keyword
>
>
> ------------------------------------------------------------------------
>
>
>
> Dave,
> Thanks for the review. One response inline below.
>
> Simon
>
> David Booz wrote:
> > my multiplicity induced migraine is back ... inlined below
and shortened
> > to just this topic.
> >
> > Dave Booz
> > STSM, BPM and SCA Architecture
> > Co-Chair OASIS SCA-Policy TC and SCA-J TC
> > "Distributed objects first, then world hunger"
> > Poughkeepsie, NY (845)-435-6093 or 8-295-6093
> > e-mail:booz@us.ibm.com
> >
> > Simon Nash <oasis@cjnash.com> wrote on 04/21/2009
05:23:10 PM:
> >
> > > [image removed]
> > >
> > > Re: [sca-assembly] NEW ISSUE: Incorrect usage
of MAY Keyword
> > >
> > > Simon Nash
> > >
> > > to:
> > >
> > > OASIS SCA Assembly List
> > >
> > > 04/21/2009 05:23 PM
> > >
> > > On today's Assembly call I volunteered to produce
a reworded paragraph
> > > for the first of Eric's items. See inline
below.
> > >
> > > Simon
> > >
> > > Eric Wells wrote:
> > > > All,
> > > > I think that in several places
in the specification the usage
> > of the
> > > > keyword MAY is not consistent with the
definition in RFC2119. To
> quote
> > > > http://www.ietf.org/rfc/rfc2119.txt:
> > > >
> > > > 5. MAY This word, or the adjective
"OPTIONAL", means that an
> item is
> > > > truly optional. One
vendor may choose to include the item
> > because a
> > > > particular marketplace
requires it or because the vendor
> > feels that
> > > > it enhances the product
while another vendor may omit the
> > same item.
> > > >
> > > > In several places MAY is used to indicate
the semantics of an
> > artifact and
> > > > NOT that a behavior is optional. I believe
other usage of MAY (and
> > SHOULD)
> > > > are consistent with the RFC2119 definition.
> > > >
> > > > Note I DO NOT want to delay the CD03 vote,
so it may be more
> > appropriate to
> > > > handle these issues on the public comment
list. However I will
> defer to
> > > > others as to how best to handle these items.
> > > >
> > > > Best Regards,
> > > >
Eric.
> > > >
> > > > Eric Wells.
> > > > Consulting Engineer.
> > > > Hitachi Computer Products (America) Inc.
> > > > San Francisco, CA. USA.
> > > > +1 (415) 656-4346
> > > > eric.wells@hitachisoftware.com
> > > >
> > > >
> > > > Based on the CD03 Word document at:
> > > >
> > > >
> > > >
> >
> http://www.oasis-open.org/committees/download.php/31566/sca-assembly-1.1-spe
> > > > c-cd03.doc
> > > >
> > > > I think that the following normative statements
need corrections:
> > > >
> > > > Unmarked normative statement Lines 836
- 840
> > > > ============================================
> > > > "If the component reference has @nonOverridable==false
and
> > @multiplicity
> > > > 1..1 and the reference has a target, then
any composite
> reference which
> > > > promotes the component reference has @multiplicity
0..1.by default
> > and MAY
> > > > have an explicit @multiplicity of either
0..1 or 1..1."
> > > >
> > > > Although this is not marked as a normative
statement, I think the
> > use of the
> > > > MAY keyword is probably correct and either
value for
> @multiplicity is
> > > > arbitrarily allowed.
> > > >
> > > > PROPOSAL:
> > > > Add a normative reference for the statement.
N.B. If a vendor
> > should NOT be
> > > > allowed to arbitrarily choose the value
for @multiplicity the
> statement
> > > > should be reworded. (Note there is an extra
period in "0..1.by"
> > that should
> > > > be corrected editorially regardless of
this issue).
> > > >
> > > Here is my proposed rewording of this paragraph.
I have added inline
> > > notes as <scn>...</scn> to explain
the changes, with a few additional
> > > comments.
> > >
> > > nonOverridable : boolean (0..1) - a boolean
value, "false" by
> default,
> > > which indicates whether this component
reference can have its
> targets
> > > overridden by a composite reference which
promotes the component
> > reference.
> > > If @nonOverridable==false, the target(s)
of the promoting composite
> > > reference replace all the targets explicitly
declared on the
> component
> > > reference for any value of @multiplicity
on the component reference.
> > > If the component reference has @nonOverridable==false
and
> > @multiplicity 1..1
> > > and the reference has a target, then
any composite reference which
> > promotes
> > > the component reference has @multiplicity
0..1 by default and
> can have
> > > an explicit @multiplicity of either 0..1
or 1..1.
> > > <scn> Changed "MAY"
to "can" because the normative text
> covering this
> > > will be added to ASM60011 (see
below).
> > > </scn>
> >
> > +1
> >
> > > <scn>I find it surprising
that there is no similar special case for
> > > a component reference with multiplicity
1..n and one or more
> targets.
> > > Is this deliberate?
> > > <scn>
> > Not deliberate that I recall. A 0..n or 1..n reference
that is
> overridable
> > would seem to need the same 0..n default on the composite
reference
> with a
> > full target replacement semantic (as opposed to additive
as in the
> case for
> > non-overridable references).
> >
> > > If @nonOverridable==true, and the component
reference has
> @multiplicity
> > > 0..1 or 1..1 and the reference has a
target, promotion implies
> that the
> > > <scn>Changed "also declares
a target" to "has a target" for
> > consistency
> > > with the previous wording four
lines earlier. The difference
> could be
> > > significant if the target is provided
by autowiring.
> > > </scn>
> > > promoting composite reference has @wiredbyImpl==true
and the
> composite
> > > reference cannot supply a target, but
can influence the policy
> attached
> > > to the component reference.
> > > If @nonOverridable==true, and the component
reference
> @multiplicity is
> > > 0..n or 1..n, promotion targeting is
additive.
> > >
> > > In addition to this change, a change needs to
be made to the
> description
> > > of @multiplicity for composite references because
the current wording
> > does
> > > not cover this case. Here's my proposed
update:
> > >
> > > multiplicity : (0..1) - Defines the number
of wires that can
> > connect the
> > > reference to target services. When
present, the multiplicity can
> > have one
> > > of the following values:
> > > o 0..1 – zero or one wire can
have the reference as a source
> > > o 1..1 – one wire can have the
reference as a source
> > > o 0..n - zero or more wires can
have the reference as a source
> > > o 1..n – one or more wires can
have the reference as a source
> > >
> > > The default value for the @multiplicity
attribute is 1..1,
> except where
> > > the promoted component reference has
@nonOverridable==false and
> > > @multiplicity 0..1 or 1..1 and the reference
has a target, in which
> > > case the default value for @multiplicity
is 0..1.
> > > <scn>I find it surprising that
the default is 1..1 rather than the
> > > multiplicity setting of the promoted
component reference. Assuming
> > > this was a deliberate choice and not
a cut-and-paste error, this
> > > additional special case of a 0..1 default
needs to be added.
> > > </scn>
> > >
> >
> > +1 The words for multiplicity default on a component reference
consider
> > componentType multiplicity in ASM50009 and the following
paragraph. The
> > words you've proposed seem appropriate.
> >
> I think the words in the paragraph following ASM50009 are fine, but
> I'm less convinced about the words in the paragraph preceding ASM60011.
>
> This default of 1..1 means that if I promote a component reference
that
> has multiplicity 0..n and don't explicitly specify a multiplicity
in
> the promoting composite reference, the multiplicity of the composite
> reference will be 1..1. Therefore, the reference in the componentType
> of the implementation.composite will be 1..1, and it would not be
> possible to wire the reference to multiple targets in any component
> that uses the implementation.composite.
>
> For example, the following would not work:
>
> <composite name="Foo">
> <component name="Bar">
> <reference name="ref1" multiplicity="0..n"/>
> </component>
> <reference name="refp1" promote="Bar/ref1"/>
> </composite>
>
> <component name="MyComp">
> <implementation.composite name="Foo"/>
> <reference name="refp1" target="Service1
Service2"/>
> </component>
>
> To be able to wire MyComp/refp1 in this way, I would need to write:
>
> <composite name="Foo">
> <component name="Bar">
> <reference name="ref1" multiplicity="0..n"/>
> </component>
> <reference name="refp1" promote="Bar/ref1"
multiplicity="0..n"/>
> </composite>
>
> <component name="MyComp">
> <implementation.composite name="Foo"/>
> <reference name="refp1" target="Service1
Service2"/>
> </component>
>
> This seems inconsistent with other promotion cases where
> attributes of the composite service or reference default to
> the corresponding attributes of the underlying promoted
> component service or reference.
>
> Simon
>
> > > The value specified for the @multiplicity
attribute of a composite
> > reference
> > > MUST be compatible with the multiplicity
specified on each of the
> > promoted
> > > component references, i.e., the multiplicity
has to be equal or
> > > further restrict.
> > > So multiplicity 0..1 can be used where
the promoted component
> > reference has
> > > multiplicity 0..n, multiplicity 1..1
can be used where the promoted
> > > component reference has multiplicity
0..1, 0..n, or 1..n, and
> > > multiplicity 1..n
> > > <scn>I have added 0..1 to
the above list, assuming that its
> omission
> > > was accidental rather than deliberate.
> > > </scn>
> > Seems ok, any multiplicity with an optional aspect could
always be
> > constrained
> > to 1..1.
> >
> > > can be used where the promoted component
reference has multiplicity
> > 0..n.
> > > However, a composite reference of multiplicity
0..n or 1..n
> > cannotbe used to
> > > promote a component reference of multiplicity
0..1 or 1..1
> > respectively.
> > > In addition, if the promoted component
reference has
> > @nonOverridable==false
> > > and @multiplicity 1..1 and the reference
has a target, then the
> > composite
> > > reference can have multiplicity 0..1.
[ASM60011]
> > > <scn>Added additional possibility
that is an exception to the
> normal
> > > rule that promoted references can
only restrict multiplicity.
> > > </scn>
> > Seems ok as you've simply said that once can specify the
default.
> >
> > >
> > >
> > > Simon
> > >
> >
> > <snip>
> >
>
>
>
> ---------------------------------------------------------------------
> 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/
>
>
>
>
>
>
---------------------------------------------------------------------
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]