[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] Binding name in the service/reference promotion case
Yes, interesting question. This is a bit of a corner case, but we should probably clarify this in the spec. Hopefully we can agree that naming a composite service (since the name is required) is really about forming the componentType of the composite. The composite service is never a wire target, so there's no reference that would need to address that binding on that composite service. Therefore, there's no reason to try to adjust the binding name as promotions occur. Instead, a reference might address the component service of a component which uses this composite as an implementation. Using Raymond's example, the reference target would look like: component_X/Service2/Service1. Adding more levels of promotion changes the first two components of the uri, but not the last one.
In looking at the spec, CD03-rev3 (pdf) lines 2867-2868 (right before ASM90002) could be clarified to indicate that the name comes from the immediate parent service or reference.
Should I open this as an issue against the spec?
The reason I think this is a corner case is because the binding is at the bottom of the implementation hierarchy, instead of at the top. That's really what makes the example ugly.
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 10/01/2009 12:25:26 PM:
> [image removed]
>
> Re: [sca-assembly] Binding name in the service/reference promotion case
>
> Simon Nash
>
> to:
>
> Simon Holdsworth
>
> 10/01/2009 12:25 PM
>
> Cc:
>
> sca-assembly
>
> Simon,
> Your reasoning makes sense to me, and my preference is also for the
> name of the binding not to change on promotion.
>
> Simon
>
> Simon Holdsworth wrote:
> >
> > Raymond,
> >
> > Good question; It seems a bit odd to me to have a binding change its
> > name when its parent service is promoted, however what you would then
> > end up with from an external viewpoint would be promoted service 2
> > having binding with name service 1, which also seems a little odd.
> >
> > having the name change on promotion does introduce the possibility of an
> > unpromotable service:
> >
> > <composite ...>
> > <service name="Service2" promote="Component1/Service1">
> >
> > <component name="Component1">
> > <service name="Service1">
> > <binding.sca/> <!-- it can be
> created
> implicitly if no bindings are present -->
> > <binding.ws name="Service2"/>
> > </service>
> > </component>
> > ...
> > </composite>
> >
> > This would fail because you'd end up with two bindings on Service2 with
> > the same name.
> >
> > For that reason I'd prefer that the binding name defaults to the name of
> > its parent service (or reference) element.
> >
> > Regards, Simon
> >
> > Simon Holdsworth
> > STSM, SCA Bindings Architect; Master Inventor; OASIS SCA Bindings TC Chair
> > MP 211, IBM UK Labs, Hursley Park, Winchester SO21 2JN, UK
> > Tel +44-1962-815059 (Internal 245059) Fax +44-1962-816898
> > Internet - Simon_Holdsworth@uk.ibm.com
> >
> >
> > From: Raymond Feng <rfeng@us.ibm.com>
> > To: sca-assembly@lists.oasis-open.org
> > Date: 30/09/2009 16:54
> > Subject: [sca-assembly] Binding name in the service/reference promotion
> > case
> >
> >
> > ------------------------------------------------------------------------
> >
> >
> >
> > Hi,
> >
> > In a composite as follows:
> >
> > <composite ...>
> > <service name="Service2" promote="Component1/Service1">
> >
> > <component name="Component1">
> > <service name="Service1">
> > <binding.sca/> <!-- it can be
> created
> implicitly if no bindings are present -->
> > </service>
> > </component>
> > ...
> > </composite>
> >
> > The binding.sca will get a name "Service1". When it is inherited by the
> > composite service "Service2", what happens to its name? Should it be
> > "Service1" or "Service2"?
> >
> > Thanks,
> > Raymond
> > ------------------------------------------------------------------------
> > *Raymond Feng*
> > Senior Software Engineer, Apache Tuscany PMC Member & Committer /
> > IBM Bay Area Lab, 1001 E Hillsdale Blvd, Suite 400, Foster City, CA
> > 94404, USA*
> > E-mail*//: //_rfeng@us.ibm.com_/ <mailto:rfeng@us.ibm.com>/, *Notes*//:
> > Raymond Feng/Burlingame/IBM, *Tel*//: 650-645-8117, *T/L*//: 367-8117*
> > Apache Tuscany*//: //_http://tuscany.apache.org_/
> > <http://tuscany.apache.org/>/
> > Co-author of Tuscany In Action: //_http://www.manning.com/laws_// /
> > ------------------------------------------------------------------------
> >
> >
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > /
> > /
> >
> > /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
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]