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


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

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

Subject: RE: [wsbpel] Question on Profile Usage Re: [wsbpel] Issue 82 - resolution]

I am now getting lost.  Why would one want to translate abstract BPEL to a 3GL like C# or Java?  These languages are not designed for expressing long-running interactions.  Which means that only trivial processes can be straightforwardly translated to them.  What is the goal?


From: andrew.francis@mail.mcgill.ca [mailto:andrew.francis@mail.mcgill.ca]
Sent: Sun 1/23/2005 2:48 PM
To: Satish Thatte
Cc: andrew.francis@mail.mcgill.ca; rkhalaf@watson.ibm.com; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Question on Profile Usage Re: [wsbpel] Issue 82 - resolution]

Hello Satish:

> The abstract class analogy you cited is interesting.  We
> have very specific completion rules for each profile
> I can imagine an abstract class variation that forbids
> the addition of new methods, say through an additional
> keyword modifier.  That would be analogous to what we
> need.

Satish, I am not quite sure how well the method
metaphor translates into WS-BPEL. The scenario (or profile)
I imagine is inspired by the "Template Method" mentioned
in the GoF "Design Patterns" book.

As an illustration, if the outline of the WS-BPEL
abstract process for the automated negotiator is:

<opaque name="preCondition" />
<invoke plnk="seller" portType="sellerPort"
        operation="negotiate" inputV="initialOffer"
<while someCondition>
         <case $result/type = ACCEPT> ~ </case>
         <case $result/type = REJECT> ~ </case>
         <case $result/type = COUNTEROFFER>
             <opaque name="computeNewOffer"
                     inputV="newOffer" outputV="result">
             <invoke plnk="seller" portType="sellerPort"
             operation="negotiate" inputV="initialOffer"

(note I am taking liberties with opaque for
illustrative purposes)

this would be similar to the following in an OO
language like Java (excuse my Java :-))

public abstract class AbstractNegotiator
   protected abstract Offer precondition(Offer someOffer);
   protected abstract Offer computeNewOffer(Offer someOffer);
   public final void execute(...)
       initialOffer = preCondition();
       result = negotiate(initialOffer)
       while (someCondition)
           //Why doesn't BPEL's switch work like this....
           switch (result.type)
                case ACCEPT:
                case REJECT:
                case COUNTEROFFER:
                     newOffer = computeNewOffer(result)
                     result = negotiate(newOffer)

If we assume that the abstract BPEL is interested in
provided just enough control flow to produce the
protocol (or proper set of traces - trace specification),
we can omit complex internal details like concurrency
or scope/compensation. Consequently I believe in these
simple cases, one could write a Ratfor style translator
(see Kernighan and Plauger's "Software Tools") that
could walk the DOM (read AST) and pump out a
skeleton in the high level language of one's choice.
Programmers are already familiar with abstract classes
and WSDL generators creating code stubs.

The translator will balk if it sees something too
complex, sees syntax mistakes, or one tries to alter
the sequence in which partnerlinks are called (as per
Satish's observation in a previous post) since in this
scenario (or profile), a primary goal is to make the
trace set an invariant.


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