Re: [sca-assembly] ISSUE-137: Clarify the use of a binding name in areference target - proposal (d)

[David Booz <booz@us.ibm.com>]

If we make that change then we also need to change the same paragraph under the second bullet.

"If there is no such service, the SCA runtime MUST raise an error. [ASM600xx]

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 07/02/2009 05:20:37 PM:

> [image removed]
>
> Re: [sca-assembly] ISSUE-137: Clarify the use of a binding name in a
> reference target - proposal (d)
>
> Simon Nash
>
> to:
>
> David Booz
>
> 07/02/2009 05:22 PM
>
> Cc:
>
> sca-assembly
>
> Looks good, but... On rereading this, I noticed that the last paragraph
> of the third bullet doesn't cover the error case where there are no
> bindings that match the policy requirements.  I think this should be
> changed to say something like:
>
>   If <binding-name> is not present, the target service MUST choose
>   one and only one of the service's <binding/> subelements that
>   satisfy the mutual policy requirements of the reference and the
>   service, and the SCA runtime MUST use this binding for the wire.
>   If there are no such <binding/> subelements, the SCA runtime
>   MUST raise an error. [ASM600xx]
>
>    Simon
>
> David Booz wrote:
> > Yes. Nice improvement. I updated the proposal with these words and I
> > also reworded the last paragraph of <binding-name> section to read more
> > closely to your last paragraph for the <service-name> section. I also
> > adjusted the words "only one" to "one and only one".
> >
> > /(See attached file: sca-assembly-1.1-spec-cd03+issue137d.doc)/
> >
> > 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
> >
> > Inactive hide details for Simon Nash ---07/02/2009 09:54:19 AM---Dave,
> > If we are going to make these bullets parallel, I think Simon Nash
> > ---07/02/2009 09:54:19 AM---Dave, If we are going to make these bullets
> > parallel, I think we need to
> >
> >
> > From:  
> > Simon Nash <oasis@cjnash.com>
> >
> > To:  
> > David Booz/Poughkeepsie/IBM@IBMUS
> >
> > Cc:  
> > sca-assembly@lists.oasis-open.org
> >
> > Date:  
> > 07/02/2009 09:54 AM
> >
> > Subject:  
> > Re: [sca-assembly] ISSUE-137: Clarify the use of a binding name in a
> > reference target - proposal (c)
> >
> > ------------------------------------------------------------------------
> >
> >
> >
> > Dave,
> > If we are going to make these bullets parallel, I think we need to
> > go a bit further than you are suggesting.  I think the second bullet
> > would become something like the following:
> >
> >  <service-name> is the name of the target service within the component.
> >
> >  If <service-name> is present, the component service with @name
> >  corresponding to <service-name> MUST be used for the wire. [ASM600xx]
> >
> >  If there is no component service with @name corresponding to
> >  <service-name>, the SCA runtime MUST raise an error. [ASM600xx]
> >
> >  If <service-name> is not present, the target component MUST have
> >  only one service with an interface that is a compatible superset of
> >  the wire source’s interface and satisfies the policy requirements
> >  of the wire source, and the SCA runtime MUST use this service
> >  for the wire. [ASM600xx]
> >
> >   Simon
> >
> > David Booz wrote:
> >  > Simon,
> >  >
> >  > Thanks for clarifying your point. I was certainly aware of the impact of
> >  > this change. In the past we didn't have interface compatibility rules on
> >  > which to base this sort of capability, nor did we have the effects of
> >  > policy well understood.
> >  >
> >  > Taking into account the subtle nature of this, I'm now wondering if I
> >  > should change the second bullet (which describes <service-name>) to an
> >  > RFC2119 statement, similar to the last paragraph of the 3rd bullet.
> >  >
> >  > 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
> >  >
> >  > Inactive hide details for Simon Nash ---07/01/2009 04:53:04 PM---Dave,
> >  > I'm sorry that we ran out of time on Tuesday's call befoSimon Nash
> >  > ---07/01/2009 04:53:04 PM---Dave, I'm sorry that we ran out of time on
> >  > Tuesday's call before we could
> >  >
> >  >
> >  > From:
> >  > Simon Nash <oasis@cjnash.com>
> >  >
> >  > To:
> >  > David Booz/Poughkeepsie/IBM@IBMUS
> >  >
> >  > Cc:
> >  > sca-assembly@lists.oasis-open.org
> >  >
> >  > Date:
> >  > 07/01/2009 04:53 PM
> >  >
> >  > Subject:
> >  > Re: [sca-assembly] ISSUE-137: Clarify the use of a binding name in a
> >  > reference target - proposal (c)
> >  >
> >  > ------------------------------------------------------------------------
> >  >
> >  >
> >  >
> >  > Dave,
> >  > I'm sorry that we ran out of time on Tuesday's call before we could
> >  > finish the discussion of policy matching for target URIs.
> >  >
> >  > In an attempt to save time on next week's call, I'll summarize my
> >  > point here.  I hope this clarifies things rather than making the
> >  > discussion even more confused!
> >  >
> >  >  From the spec words before proposal 137c, it was only valid to omit
> >  > the <service-name> if there was exactly one compatible service
> >  > on the component.  So, if a component MyComp has services "Foo"
> >  > and "Bar", and the interfaces of "Foo" and "Bar" are both compatible
> >  > with the reference interface, it would be necessary to specify
> >  > either "MyComp/Foo" or "MyComp/Bar" explicitly in the reference URI
> >  > instead of just "MyComp".  This is irrespective of whether polices
> >  > match or don't match, because policy matching is not part of the
> >  > definition of interface compatibilty.
> >  >
> >  > The wiring rules require interface compatibility, and they also
> >  > require matching policies on reference and service.  So if "Foo" has
> >  > matching policies and "Bar" does not, the target "MyComp/Foo" would
> >  > be OK and the target "MyComp/Bar" would be an error.
> >  >
> >  > The 137c proposal would make one change to this: it would make
> >  > "MyComp" a valid shorthand for "MyComp/Foo" based on the additional
> >  > policy matching rule.  It would leave the other cases as before, with
> >  > "MyComp/Foo" being OK and "MyComp/Bar" being an error.
> >  >
> >  > If you (or others) interpreted the previous words as allowing "MyComp"
> >  > in this case, then the new words are equivalent and clearer.
> >  >
> >  > If anyone interpreted the previous words as not allowing "MyComp" in
> >  > ths case (as I did), then the new words would change this.  However,
> >  > I don't object to making this change.  One point in its favour is that
> >  > the rule stated in the new words is consistent with how autowiring works.
> >  >
> >  >   Simon
> >  >
> >  > Mike Edwards wrote:
> >  >  >
> >  >  > Folks,
> >  >  >
> >  >  > This looks good to me.
> >  >  >
> >  >  > +1
> >  >  >
> >  >  > 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: David Booz <booz@us.ibm.com>
> >  >  > To: sca-assembly@lists.oasis-open.org
> >  >  > Date: 29/06/2009 21:05
> >  >  > Subject: [sca-assembly] ISSUE-137: Clarify the use of a binding
> > name in
> >  >  > a reference target - proposal (c)
> >  >  >
> >  >  >
> >  >  >
> > ------------------------------------------------------------------------
> >  >  >
> >  >  >
> >  >  >
> >  >  > Attached is the updated proposal for ASSEMBLY-137. I believe all
> >  >  > comments from the last telecon are addressed, and in addition I found
> >  >  > several additional places (as I suspected) which also needed a minor
> >  > update.
> >  >  > /
> >  >  > (See attached file: sca-assembly-1.1-spec-cd03+issue137c.doc)/
> >  >  >
> >  >  > [1] _http://www.osoa.org/jira/browse/ASSEMBLY-137_
> >  >  >
> >  >  > 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[attachment
> >  >  > "sca-assembly-1.1-spec-cd03+issue137c.doc" deleted by Mike
> >  >  > Edwards/UK/IBM]
> >  >  > ---------------------------------------------------------------------
> >  >  > 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
> >  >
> >  >
> >  >
> >
> >
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > ---------------------------------------------------------------------
> > 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
>
>
>
> ---------------------------------------------------------------------
> 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
>