← Prev in month ← Prev in thread

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

From
David Booz <>
Date
2009-07-02T15:03:20+00:00
ID
Thread
Re: [sca-assembly] ISSUE-137: Clarify the use of a binding name in areference target - proposal (d)
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:

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

To:

David Booz/Poughkeepsie/IBM@IBMUS

Cc:



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:

> 

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

> 

> To:		 

> David Booz/Poughkeepsie/IBM@IBMUS

> 

> Cc:		 

> 

> 

> 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:  

>  >

>  >

>  > From: David Booz <>

>  > To: 

>  > 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:[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 

> 

> 

> 

sca-assembly-1.1-spec-cd03+issue137d.doc
← Prev in month ← Prev in thread