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


Danny van der Rijn wrote:
4A7B1CE6.2090408@tibco.com" type="cite"> 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.
4A7B1CE6.2090408@tibco.com" type="cite">

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

4A7B1CE6.2090408@tibco.com" type="cite">
Anish Karmarkar wrote:
4A7A3D26.3070103@oracle.com" type="cite"> [sca-bpel] Issue 41: proposal with examples

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



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