ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Flood" <bill.f.fl...@gmail.com>
Subject Re: PXE implementation basis
Date Fri, 21 Apr 2006 19:25:03 GMT
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 <arkin@intalio.com> 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 <bill.f.flood@gmail.com> 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 < paulrbrown@gmail.com> 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
>

Mime
View raw message