OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [sca-bpel] RE: [Issue 38]: Is the 'MUST' in section 2.1.2 needed?



Folks,

The Assembly spec uses the term "target service" rather than "endpoint", and also uses the term "target service address" for the actual location of a target service (this is as close as we get to "endpoint")
so I suppose that might make the wording something like:

"for a service, there must be a fixed target address for the callback"

To cover your 3 cases:

1) Callback address is supplied via configuration of the callback binding
2) Service is promoted and the configuration of the higher level service provides a single Callback address
3) Service is connected only via a single wire that uses the SCA binding so that the source of the wire provides an unambiguous callback address.

I think that the case for a reference is clearer.  All that is needed is that the reference is configured with at least one target service.
I'm unclear as to whether more than 1 reference target is OK.  If it isn't, then that translates into a restriction of the multiplicity of the reference to 1..1.
Otherwise the restriction is to 1..n or 1..1.  But 0..x is not allowed.


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: Michael Rowley <michael.rowley@activevos.com>
To: Mike Edwards/UK/IBM@IBMGB, OASIS BPEL <sca-bpel@lists.oasis-open.org>
Date: 27/04/2009 14:50
Subject: RE: [sca-bpel] RE: [Issue 38]: Is the 'MUST' in section 2.1.2 needed?





 
I'm certainly not wedded to the way I've suggested here.  It is tricky to find a way to state the requirement that is both clear and accurate.
 
You suggested: "for a service, there must be a fixed set for the endpoint of the callback".  This is close.  I don't think it is a fixed set, but more like a fixed single endpoint.  However, I think that begs the question, since I'm not aware of any SCA spec that has a precise definition for "endpoint" and how it might be specified (I might be wrong, of course).  I used the phrase "binding, promotion and wiring" because I can think of a few ways that the clients address might be known by the system:
1) The callback binding specifies an endpoint address
2) The service is promoted and some higher level componenty is configured so that the client address is known (using (1) or (3)).
3) The service callback uses the SCA binding and there is only a single wire to the service _and_ the system uses technology for the SCA binding that allows it to guarantee that no client other than the one wired client will connect to the service.
 
There may be other cases as well, but I suspect that the phrase of "binding, promotion and wiring" is broad enough to cover them.
 
I thought about trying to find a way to state a use case for this restriction as part of the spec text.  The use case is that it should be possible to assign from the partner role of the partner link as soon as the partner link's scope is initialized.  The result of such an assignment should be to move a useful EPR to the target of the assign.  I found it difficult to state the use case, and it is the same use case as for BPEL's @initializePartnerRole attribute even without SCA, so I decided it probably doesn't belong in this spec.
 
Michael
 
 
From: Mike Edwards [mailto:mike_edwards@uk.ibm.com]
Sent:
Monday, April 27, 2009 6:41 AM
To:
OASIS BPEL
Subject:
[sca-bpel] RE: [Issue 38]: Is the 'MUST' in section 2.1.2 needed?

 

Folks,


I am still left feeling that the whole story is not being given from an SCA perspective here.  Perhaps an example is called for.


What I think I am missing is what demands this set of requirements place on the guy assembling a component which uses

a BPEL implementation with this characteristic.


I am having a hard time translating "the partner link's partner role will be initialized as soon as the partner link becomes active"

into something that is meaningful to an assembler.


If it means something like "for a service, there must be a fixed set for the endpoint of the callback" and  "for a reference, the reference

must be wired to a service", then I think that we should say so.  If these words are not the right ones, I'd appreciate it if someone

who understands @initializePartnerRole better could come up with a better set of words.



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: Michael Rowley <michael.rowley@activevos.com>
To: Anish Karmarkar <Anish.Karmarkar@oracle.com>, OASIS BPEL <sca-bpel@lists.oasis-open.org>
Date: 23/04/2009 21:44
Subject: RE: [sca-bpel] [Issue 38]: Is the 'MUST' in section 2.1.2 needed?

 









I took an action to try rewriting this.  Here is a version that separates out the reference side from the servic side.  It has a lot of redundancy this way, so immidiately below it I have a second try that attempts to combine the requirements for services and references.

-----

2.1.2 Handling @initializePartnerRole

If a partner link marked with initializePartnerRole="yes" maps to a reference in the component type, then any component that uses this business process as an implementation MUST configure the corresponding reference using binding, promotion and wiring configuration that guarantees that the partner link's partner role will be initialized as soon as the partner link becomes active.  The component type reference for a partner link that is marked as initializePartnerRole="yes" MUST NOT specify wiredByImpl="true".  

SCA has no concept of multiplicity on services, but partner links that map to services can still be marked with an initializePartnerRole attribute.  [SBPEL2014] If initializePartnerRole="yes" is specified for a partner link and the partner link maps to a service in the component type, then any component that uses this business process as an implementation MUST configure the corresponding service using a callback binding, promotion and wiring that guarantees that the partner link's partner role will be initialized as soon as the partner link becomes active.

------

2.1.2 Handling @initializePartnerRole

If a partner link is marked with initializePartnerRole="yes" then any component that uses this business process as an implementation MUST configure the corresponding service or reference using binding, promotion and wiring configuration that guarantees that the partner link's partner role will be initialized as soon as the partner link becomes active.  If the partner link is mapped to a service, the callback binding would be the relevant binding for this requirement.  The the partner link is mapped to a reference then the component type ype reference MUST NOT specify wiredByImpl="true".  

Michael


-----Original Message-----
From: Anish Karmarkar [
mailto:Anish.Karmarkar@oracle.com]
Sent: Thursday, April 23, 2009 3:24 AM
To: OASIS BPEL
Subject: Re: [sca-bpel] [Issue 38]: Is the 'MUST' in section 2.1.2 needed?

This is now issue 38:
http://osoa.org/jira/browse/BPEL-38

Anish Karmarkar wrote:
> Title: is the 'MUST' in section 2.1.2 needed?
>
> Target: SCA BPEL C&I
>
> Description:
> This issue came up as a result of discussion of test assertion SBL-TA-2012.
> The test assertion, which is based on SBPEL2014, is not really testable.
> OR to be more precises perhaps could be testable for some corner cases,
> which the SCA BPEL TC (very likely) is not going to test.
> The problem is that the requirement states that the binding configured
> must know the identity of the partner as soon as the PL becomes active.
> It is not clear how that would happen for the bindings that we define.
> It seems to assume that the binding and the port associated with the
> binding is visible only to other SCA references. It is not clear why/how
> this would be true.
> A related minor issue is that it talks about the 'identity' of the
> partner. Does it really mean 'identity' or the 'location'? The
> parenthetical statement seems to indicate that it is the location, not
> identity.
>
> Proposal:
> Two possible solutions:
> 1) If this is indeed a corner case which we want to enable but not test,
> we could s/MUST/SHOULD/
> 2) If this is a corner case that we don't intend to test nor do we see
> it serve a useful purpose then we should just get rid of section 2.1.2
>
> -Anish
> --
>
> ---------------------------------------------------------------------
> 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







 

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











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]