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

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

Michael,

Your proposal includes:
 >The component type reference for a partner link that is marked as
 >initializePartnerRole="yes" MUST NOT specify wiredByImpl="true".

We don't need this, as
1) we do not allow CT side files, and
2) SBPEL2011 in section 2.1.1 already says this will never happen for 
the introspected CT.

-Anish
--

Michael Rowley wrote:
> 
> 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 
>