Assaf, I appreciate the sentiment of this message. It can only be a good thing to understand the basis for the markup language one is implementing. Arguably, discussion of pi-calculus may be more pertinent to the definition of BPEL than it is is to the engine itself.
When we set out to implement BPE, we looked at pi-calculus and petri-nets, but in the end, implementing the patterns van der Aalst references was the path we chose for the BPE because it was both pracitcally applied and was mapped to a superset of BPEL. Based on the interface layer conversations, it's probably safe to say that separating out concerns is a clear goal and the discussion about synchronicity in the interface layer and threading will help take us in that direction. --Bill On 4/20/06, Assaf Arkin <[EMAIL PROTECTED]> wrote: > The best approach I find is separation of concerns. You worry about data > extraction (XPath/XQuery) in one place, deal with messaging in another, put > one layer in charge or reliability problems (transactions, persistence, > etc). Similarly, you have one layer dealing with concurrency and state > transition problems, and another one to write the high-level activities, > where you can focus on nothing but their semantics. > > The model I'd pick for simplicity would deal with concurrency, state > transitions and channel passing semantics. That way you can wire a lot of > things around it, you can make parallel flows and event handler, compensate > and interrupt them. You can have composite activities, but also link them > together, and nest states arbitrarily. > > Those are all software decisions, but if you want to understand the model it > can be easier to start with something simpler, dissociated from code. These > models are descriptive, not prescriptive. You don't build anything from > pi-calculus, it wasn't designed as an architecture for building software. > But there's a huge class of applications you can better understand with > pi-calculus. > > If you want to understand why TCP works, how parallel processes execute > without dead-lock, or mathematically model peer-to-peer network, that's one > of the better ways of doing it. It's the equivalent of relational algebra or > lambda-calculus. You don't write relational algebra to query your database, > and it won't get you to do faster I/O or split data across disks. But you > can write better SQL if you understand the cost of queries and updates. > > Assaf > > > On 4/20/06, Bill Flood <[EMAIL PROTECTED]> wrote: > > > > My previous question on the gain vs pain for a specific implementation > > preference was aimed at getting to some concrete advantage. Paul, > > your explanation of the algorithm's ability to solve the Sieve problem > > helps and Assaf's argument about the ease of changing the model is > > interesting as well. > > > > I was just trying to get to the root of the issue about pi-calculus > > and it's advantage to the runtime model once it is deployed. > > > > Not that it has any impact to our discussion or reflects on your > > explanation, but, here's another interesting article. > > > > http://is.tm.tue.nl/staff/wvdaalst/pi-hype.pdf > > > > Bill > > > > On 4/12/06, Paul R Brown < [EMAIL PROTECTED]> wrote: > > > > > > Hi, All -- > > > > > > JaCOb is Maciej's invention, so I'm hoping that he'll jump in here at > > > some point and add a layer of detail. > > > > > > The articles that Matt pointed to can make some interesting reading > > > (I like the Sangiori and Weaver book (ISBN 0521781779) and Gul Agha's > > > thesis (linked from my bookmarks -- > > > http://del.icio.us/prb/actors)<http://del.icio.us/prb/actors%29> > > ). > > > **BUT** PXE is a *PRACTICAL* design, you don't need any of the heavy > > > machinery to appreciate how PXE works. > > > > > > Getting back to the sieve example with JaCOb, here's the basic idea: > > > > > > The Sieve of Erasthones (http://en.wikipedia.org/wiki/ > > > Sieve_of_Eratosthenes) provides a way to enumerate prime numbers. In > > > terms of the example, you have three process terms that work together: > > > > > > 1) You've got a counter term that sends integers one after the other. > > > 2) You've got a head term that works like a factory for primality > > > checkers. > > > 3) You've got a printer. > > > > > > We start off with an arrangement like this: > > > > > > Counter -1-> Head -2-> Print > > > > > > Counter sends 2 to Head on -1->, and Head creates a prime checker and > > > a new Head. The new Head still talks to Print on -2->. The prime > > > checker listens on -1-> and checks for relatively primeness to 2; if > > > it succeeds, it tells the new Head (on -3->). So we have: > > > > > > Counter -1-> P2 -3-> Head -2-> Print > > > > > > Note that the P2 above is really the term PrimeFilter(2,-1->,-3->), > > > Head is really Head(-3->,-2->), and Counter is really Counter(3,-1->). > > > > > > When Counter sends 3, P2 passes it along, and Head again spawns a > > > checker for relatively primeness to 3 and a new Head: > > > > > > Counter -1-> P2 -3-> P3 -4-> Head -2-> Print > > > > > > Counter is really Counter(4,-1->), and this time, PrimeFilter(2,-1- > > > >,-3->) just absorbs it. Counter is now Counter(5,-1->), 5 will > > > flow from P2 to P3 to Head, which spawns a mod 5 checker and a new > > > Head, etc. > > > > > > This is what the Sieve example does, and JaCOb ("[Ja]va [C]oncurrent > > > [Ob]jects") is a relatively thin layer to translate between notation > > > like the above and Java. The translation between process notation > > > like the above and JaCOb notation takes a little getting used to, but > > > this little snippet is relatively close to the underlying notation: > > > > > > Process: > > > ( v x ) > > > JaCOb: > > > NaturalNumberStreamChannel x = newChannel > > > (NaturalNumberStreamChannel.class ); > > > > > > Process: > > > PrimeFilter(n,_in,x) > > > JaCOb: > > > instance(new PrimeFilter(n, _in, x)); > > > > > > Process: > > > Head(x,_primes) > > > JaCOb: > > > instance(new Head(x, _primes)); > > > > > > And this is the "spawning" phenomenon within a Head(...) term. > > > (Parallelism is implicit in JaCOb, so no "|" is needed.) This is > > > covered in the JavaDoc for the instance method on Abstraction -- > > > "instance(new Term(args))" in JaCOb Java notation is equivalent to > > > "Term(args)" in process notation. In the same vein, "self" is a > > > reduction of the represented term. > > > > > > Does this make some sense so far? > > > > > > -- Paul > > > > > > > > > On Apr 6, 2006, at 3:15 PM, Alex Boisvert wrote: > > > > > > > > > > > Yes, the sieve example can be found at: > > > > > > > > $PXE_SVN/jacob/src/java/com/fs/jacob/examples/eratosthenes/Sieve.java > > > > > > > > alex > > > > > > > > > > > > Paul R Brown wrote: > > > > > > > >> > > > >> Hi, Bill -- > > > >> > > > >>> We are trying to understand the PXE contribution. Is this the > > > >>> implementation basis for PXE? > > > >>> http://www.labri.fr/perso/grange/documents/fmppta.pdf > > > >> > > > >> > > > >> Funny -- that's a *different* Jacob but with a few ideas in common. > > > >> (Or at least that's the way it looks after I skimmed the paper.) > > > >> > > > >> Did the prime sieve example make it into the submission? If so, I > > > >> can walk through that as an explanation. > > > >> > > > >> Best, > > > >> > > > >> -- Paul > > > > > > > > > > > > > > > > > > > > -- > CTO, Intalio > http://www.intalio.com >
