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] Issue 41: proposal with examples -- version 2



Folks,

A few editorial changes:



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: Anish Karmarkar <Anish.Karmarkar@oracle.com>
To: OASIS BPEL <sca-bpel@lists.oasis-open.org>
Date: 20/08/2009 07:36
Subject: Re: [sca-bpel] Issue 41: proposal with examples -- version 2





Attached.

The changes are based on discussions from last week. Diff between v1 and v2:
1) Added SBPEL2ZZZ in anticipation of issue 52 resolution.
2) made the changes to the example as suggested by Danny.
3) Added the last paragraph in the proposal.

-Anish
--

Anish Karmarkar wrote:
> Danny van der Rijn wrote:
>> Strangely, I like this :-)  Thanks for taking the time, Anish, to
>> flesh this out in spec language.  I like the addition of
>>
>> "
>>
>> o         [SBPEL2YYY] If the sca-bpel:service or sca-bpel:reference
>> attribute is present on the partnerLink, its value MUST NOT be a
>> member of /S/. The value of the attribute is added to /S/ and
>> appropriate SCA service or reference is generated per section 2.1.1.
>>
>> "
>>
>> IMO it would be worth changing the example slightly to include a use
>> of SBPEL2YYY:
>>
>> <process …>
>>
>>   <partnerLinks>
>>
>>     <partnerLink name="shipping" "_shipping_1"
>> sca-bpel:service="shipping" ... />
>>
>>     <partnerLink name="_shipping_2" ... />
>>
>>     <partnerLink name="receiving" ... />
>>
>>     <partnerLink name="_receiving_2" ... />
>>
>>   </partnerLinks>
>>
>>  
>>
>>   ...
>>
>>  
>>
>>   <scope>
>>
>>     <partnerLinks>
>>
>>       <partnerLink name="shipping" ... />
>>
>>       <partnerLink name="receiving" ... />
>>
>>       <partnerLink name="_shipping_1" ... />
>>
>>       <partnerLink name="_receiving_1" ... />
>>
>>     </partnerLinks>
>>
>>  
>>
>>     ...
>>
>>  
>>
>>   </scope>
>>
>>  
>>
>>   ...
>>
>>  
>>
>> </process>
>>
>>
>> with the resulting tables remaining the same.
>>
> +1 to the change
>
> I should also point out that the resolution of issue 52 will alter the
> algorithm as the sca-bpel:multiReference element can now have a name
> attribute.
>>
>>
>> However, the addition of SBPEL2YYY does bring up another edge case.  I
>> think I'm OK with not closing the loophole and just leaving this sharp
>> corner there for the few people in the world who will run up against
>> it, to mix my metaphors.  But I feel the need to point it out, anyway.
>>
>> Consider a modification on the first example:
>>
>> <process …>
>>
>>   <partnerLinks>
>>
>>     <partnerLink name="shipping" ... />
>>
>>     <partnerLink name="_shipping_2" ... />
>>
>>     <partnerLink name="receiving" ... />
>>
>>     <partnerLink name="_receiving_2" ... />
>>
>>   </partnerLinks>
>>
>>  
>>
>>   ...
>>
>>  
>>
>>   <scope>
>>
>>     <partnerLinks>
>>
>>       <partnerLink name="shipping"  sca-bpel:service="shipping" ... />
>>
>>       <partnerLink name="receiving" ... />
>>
>>       <partnerLink name="_shipping_1" ... />
>>
>>       <partnerLink name="_receiving_1" ... />
>>
>>     </partnerLinks>
>>
>>  
>>
>>     ...
>>
>>  
>>
>>   </scope>
>>
>>  
>>
>>   ...
>>
>>  </process>
>>
>>
>>
>> This would be an invalid document under SBPEL2YYY since "shipping"
>> will already have been assigned by the algorithm.
>>
> Indeed. IMHO, it is ok to call such a document non-conformant document.
> The creator specifically used the sca-bpel:service attribute to name the
> ref/service associated with the partnerLink and should have chosen a
> unique name.
>
> But there is another case which is even tricker: when the creator does
> choose a unique name (as far as partner link names are concerned) but it
> still results in an invalid document.
> For example:
>
> <partnerLink name="shipping" .../>
> <scope>
>    <partnerLink name="shipping" .../>
>    <parnerLink name="foobar" sca-bpel:service="_shipping_1 .../>
> </scope>
>
> This is a result of the fact that we have a one-pass algorithm that does
> not do any look-ahead when mangling names. I think it is a trade off.
> I'm fine with the one-pass algorithm, but the useful guideline here for
> values of sca-bpel:service/reference attribute values is:
> don't use underscore as the 1st character of the name, don't use
> integers preceded by underscore as the last characters of the name.
>
> -Anish
> --
>
>>
>> Anish Karmarkar wrote:
>>>
>>> Attached.
>>>
>>> This is based on the proposal that was sent by Danny (which updated the
>>> proposal sent by MichaelR). I have added examples (that were also sent
>>> by Danny in a different email).
>>>
>>> Comments?
>>>
>>> -Anish
>>> --
>>>
[attachment "issue41-ask-v2.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






issue41-ask-v2_mje.doc



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