[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" outputV="result"/> <while someCondition> <switch> <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" outputV="result"/> </case> </switch> </while> (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: ~ break; case REJECT: ~ break; case COUNTEROFFER: newOffer = computeNewOffer(result) result = negotiate(newOffer) break; } } } } 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. Cheers, Andrew
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]