243 views

Skip to first unread message

Sep 30, 2008, 9:54:00 PM9/30/08

to Workflow Patterns Group

As an academic in the field of BPM I do not cease to be amazed by the

nonsense that surrounds arguments about (supposed) relationships

between formal theories and languages used for business process

modelling and/or automation. An example of such arguments can be found

in a recent <a href="http://itredux.com/2008/09/28/why-bpel/">blog

post by Ismael Ghalimi</a>

where he responds to a <a href="http://itredux.com/2008/09/26/bpm-20-

mefiez-vous-des-imitations/">blog post by

Sandy Kemsley</a>.

An opportunity to voice some of my gripes ... and to start a

discussion.

As an academic I don't feel qualified to speak about the (supposed)

popularity of a certain standard. I do feel qualified though to speak

about formal methods and their application to the field of BPM. My

comments will therefore focus exclusively on the paragraph that

follows the title "BPEL is built upon the right mathematical model".

Let's dissect the various statements made.

"If they use BPEL, they’re leveraging the Pi-Calculus mathematical

model for supporting the execution of distributed and collaborative

processes."

The way pi-calculus (a beautiful theory btw) has been used as a

marketing tool in the field of BPM has already been pointed out by Wil

van der Aalst a few years ago.

It is a pity to see that this misdirection is still ongoing.

The relationship between BPEL and pi-calculus is tenuous at best.

While it is possible to define a formal semantics of BPEL in terms of

Pi-calculus (and some academics have tried), it is perfectly possible

to write such a semantics in terms of many other formal languages as

well. In order to claim that a certain language benefits from a

certain formal theory their link needs to be made precise and needs to

be made publicly available.

So how *exactly* do users of BPEL "leverage" the theory of pi-

calculus?

Let's drill down a little bit more.

The distinguising feature of pi-calculus compared to other members of

the process algebra family is channel passing. BPEL does not rely on

this feature hence for its formalisation other members of the family

of process algebras (e.g. ACP or CCS) could have been used and the

resulting formalisation would not fundamentally differ from one

realised in pi-calculus.

If anything, the most feature-complete formal semantics of BPEL have

been defined in terms of Petri nets rather than pi-calculus (and one

can see that capturing control links in pi-calculus would not be so

intuitive). In particular, I have been involved in <a href="http://

eprints.qut.edu.au/archive/00014809/"</a>work that mapped BPEL to

Petri nets</a> for the purposes of verification. As can be seen from

the paper, such a mapping involves a significant amount of work and

requires great attention to detail. Here one can leverage the analysis

techniques that are available for Petri nets. So, the link between

language (BPEL) and theory (Petri nets) is defined in a precise

manner, it is publicly available and it is made clear what the

benefits derived are.

Also, it is clear that mapping BPEL to Petri nets does not say much

about BPEL's suitability for process automation. It could have been

mapped to any Turing complete language. So even if a mapping from BPEL

to pi-calculus is provided, what does this really say about BPEL? The

only other option would be to claim that BPEL is some kind of encoding

of the pi-calculus, but this is clearly not the case.

"If they use XPDL, they’re taking advantage of the Petrinet model for

supporting the execution of standalone processes."

A most peculiar claim. What is the relationship between XPDL and Petri

nets? Naturally XPDL can be mapped to Petri nets, but so can BPEL. No-

one (at least I hope so!) would claim that XPDL embodies Petri nets in

one way or another. Basic Petri nets consist of places and

transitions. There is no equivalent of the concept of a place in

XPDL ... So suggesting a link seems a bit of a stretch.

"If they use their own language or execution model, it’s a hack devoid

of any strong mathematical foundation, and it won’t scale over the

long run."

This seems to suggest that BPEL and XPDL are the only languages with a

strong mathematical foundation. This is ironic for two reasons: 1)

neither of these languages actually has a formally defined syntax and

semantics that is accepted by a standards organisation, 2) there are

other approaches that *do* have a proper formal underpinning.

"Petrinets are great for executing standalone processes, but cannot

really be used to model how independent processes can be executed in

parallel while synchronizing each other."

A mystifying argument. Firstly, High Level Petri nets are Turing

complete, so they can express every computable function. Secondly,

they are even eminently suitable to

express communication interactions between various independent

processes

(see e.g. <a href="http://is.tm.tue.nl/staff/wvdaalst/BPMcenter/

reports/2006/BPM-06-19.pdf">this report</a>).

"Granted, you can hard-code such integrations and interactions by

hand, which is what workflow vendors have done for the past two

decades, but this is not BPM (at least not BPM 2.0), it’s old-school

EAI."

You can construct proper abstraction mechanisms based on either

formalism (Petri nets and pi-calculus).

While I am happy to see that now, as opposed to the time I was doing

my PhD, there

is a recognition in industry that a proper formal foundation is a

necessity, it is clear that there is still a long way to go in terms

of appreciating and understanding the role of formal methods. It is

not sufficient to just say that a certain language is based on a

certain theory and that therefore this language derives some wonderful

properties from this theory. This needs to be actually demonstrated in

a reproducible (and hence publicly available) way. Till then such

claims should not be made.

Arthur ter Hofstede

nonsense that surrounds arguments about (supposed) relationships

between formal theories and languages used for business process

modelling and/or automation. An example of such arguments can be found

in a recent <a href="http://itredux.com/2008/09/28/why-bpel/">blog

post by Ismael Ghalimi</a>

where he responds to a <a href="http://itredux.com/2008/09/26/bpm-20-

mefiez-vous-des-imitations/">blog post by

Sandy Kemsley</a>.

An opportunity to voice some of my gripes ... and to start a

discussion.

As an academic I don't feel qualified to speak about the (supposed)

popularity of a certain standard. I do feel qualified though to speak

about formal methods and their application to the field of BPM. My

comments will therefore focus exclusively on the paragraph that

follows the title "BPEL is built upon the right mathematical model".

Let's dissect the various statements made.

"If they use BPEL, they’re leveraging the Pi-Calculus mathematical

model for supporting the execution of distributed and collaborative

processes."

The way pi-calculus (a beautiful theory btw) has been used as a

marketing tool in the field of BPM has already been pointed out by Wil

van der Aalst a few years ago.

It is a pity to see that this misdirection is still ongoing.

The relationship between BPEL and pi-calculus is tenuous at best.

While it is possible to define a formal semantics of BPEL in terms of

Pi-calculus (and some academics have tried), it is perfectly possible

to write such a semantics in terms of many other formal languages as

well. In order to claim that a certain language benefits from a

certain formal theory their link needs to be made precise and needs to

be made publicly available.

So how *exactly* do users of BPEL "leverage" the theory of pi-

calculus?

Let's drill down a little bit more.

The distinguising feature of pi-calculus compared to other members of

the process algebra family is channel passing. BPEL does not rely on

this feature hence for its formalisation other members of the family

of process algebras (e.g. ACP or CCS) could have been used and the

resulting formalisation would not fundamentally differ from one

realised in pi-calculus.

If anything, the most feature-complete formal semantics of BPEL have

been defined in terms of Petri nets rather than pi-calculus (and one

can see that capturing control links in pi-calculus would not be so

intuitive). In particular, I have been involved in <a href="http://

eprints.qut.edu.au/archive/00014809/"</a>work that mapped BPEL to

Petri nets</a> for the purposes of verification. As can be seen from

the paper, such a mapping involves a significant amount of work and

requires great attention to detail. Here one can leverage the analysis

techniques that are available for Petri nets. So, the link between

language (BPEL) and theory (Petri nets) is defined in a precise

manner, it is publicly available and it is made clear what the

benefits derived are.

Also, it is clear that mapping BPEL to Petri nets does not say much

about BPEL's suitability for process automation. It could have been

mapped to any Turing complete language. So even if a mapping from BPEL

to pi-calculus is provided, what does this really say about BPEL? The

only other option would be to claim that BPEL is some kind of encoding

of the pi-calculus, but this is clearly not the case.

"If they use XPDL, they’re taking advantage of the Petrinet model for

supporting the execution of standalone processes."

A most peculiar claim. What is the relationship between XPDL and Petri

nets? Naturally XPDL can be mapped to Petri nets, but so can BPEL. No-

one (at least I hope so!) would claim that XPDL embodies Petri nets in

one way or another. Basic Petri nets consist of places and

transitions. There is no equivalent of the concept of a place in

XPDL ... So suggesting a link seems a bit of a stretch.

"If they use their own language or execution model, it’s a hack devoid

of any strong mathematical foundation, and it won’t scale over the

long run."

This seems to suggest that BPEL and XPDL are the only languages with a

strong mathematical foundation. This is ironic for two reasons: 1)

neither of these languages actually has a formally defined syntax and

semantics that is accepted by a standards organisation, 2) there are

other approaches that *do* have a proper formal underpinning.

"Petrinets are great for executing standalone processes, but cannot

really be used to model how independent processes can be executed in

parallel while synchronizing each other."

A mystifying argument. Firstly, High Level Petri nets are Turing

complete, so they can express every computable function. Secondly,

they are even eminently suitable to

express communication interactions between various independent

processes

(see e.g. <a href="http://is.tm.tue.nl/staff/wvdaalst/BPMcenter/

reports/2006/BPM-06-19.pdf">this report</a>).

"Granted, you can hard-code such integrations and interactions by

hand, which is what workflow vendors have done for the past two

decades, but this is not BPM (at least not BPM 2.0), it’s old-school

EAI."

You can construct proper abstraction mechanisms based on either

formalism (Petri nets and pi-calculus).

While I am happy to see that now, as opposed to the time I was doing

my PhD, there

is a recognition in industry that a proper formal foundation is a

necessity, it is clear that there is still a long way to go in terms

of appreciating and understanding the role of formal methods. It is

not sufficient to just say that a certain language is based on a

certain theory and that therefore this language derives some wonderful

properties from this theory. This needs to be actually demonstrated in

a reproducible (and hence publicly available) way. Till then such

claims should not be made.

Arthur ter Hofstede

Oct 1, 2008, 9:35:42 AM10/1/08

to Workflow Patterns Group

Can I quote you on this? :)

The problem is, when things like this are written, there are few

public voices to provide any argument. Many people don't know (or

care) about the details of Pi calculus versus Petri nets, but when

they hear the terms thrown around by a respected voice in the

industry, it creates a certain level of fear over their own product

choices. To the end consumer organizations, I always advocate it

doesn't really matter whether it's BPEL or XPDL or a proprietary

execution language, as long as the model can directly translate to

execution. Your analysis (in a much more elegant and complete way)

says the same thing, and it would be of huge benefit to have a version

of this published that is understandable by people making BPM

purchasing decisions.

I appreciate that your objection is to his misuse of formal theory to

support his viewpoint (and his product), but since I work directly

with BPM implementations, I also have a big objection to his statement

that "If your BPM vendor of choice is advocating that only BPMN

matters, they’re using proprietary ways to make your processes fully

executable, usually requiring a lot of custom code development." To

make the leap from a proprietary (by which he means non-BPEL)

serialization/execution language to "requiring a lot of custom code

development" just isn't true in many of the vendor products that I've

used.

sandy

The problem is, when things like this are written, there are few

public voices to provide any argument. Many people don't know (or

care) about the details of Pi calculus versus Petri nets, but when

they hear the terms thrown around by a respected voice in the

industry, it creates a certain level of fear over their own product

choices. To the end consumer organizations, I always advocate it

doesn't really matter whether it's BPEL or XPDL or a proprietary

execution language, as long as the model can directly translate to

execution. Your analysis (in a much more elegant and complete way)

says the same thing, and it would be of huge benefit to have a version

of this published that is understandable by people making BPM

purchasing decisions.

I appreciate that your objection is to his misuse of formal theory to

support his viewpoint (and his product), but since I work directly

with BPM implementations, I also have a big objection to his statement

that "If your BPM vendor of choice is advocating that only BPMN

matters, they’re using proprietary ways to make your processes fully

executable, usually requiring a lot of custom code development." To

make the leap from a proprietary (by which he means non-BPEL)

serialization/execution language to "requiring a lot of custom code

development" just isn't true in many of the vendor products that I've

used.

sandy

Oct 1, 2008, 10:16:05 AM10/1/08

to Workflow Patterns Group

Brilliant post, Arthur. Agreed. But, as Sandy points out, there are

few dissenting voices. I've been in heated discussions where I've

been trying to make the point that it's the modelling language that

matters, and that the execution is an implementation detail. One

Turing-complete solution is as good as any other -- the key is the

modelling abstraction (and whether it does the job). But, lurking

behind Sandy's point, Arthur, is the following question: how does one

have this discussion with a conversational partner whose eyes roll at

the first mention of "isomorphic", "HLPN", "pi Calculus" or any other

such thing? ;) You don't even touch on the apples-to-oranges aspect

of this nonsense, since, strictly speaking, XPDL isn't an execution

language at all.

Given the events of the last few days, I'm prompted to make the

following analogy: business / IT purchasers are no more capable of

making these distinctions than your typical member of the US House of

Representatives can tell me what a centralised debt obligation is.

And in the same toxic way, such a climate of ignorance is ripe for

exploitation.

How do we make the truth "understandable"?

few dissenting voices. I've been in heated discussions where I've

been trying to make the point that it's the modelling language that

matters, and that the execution is an implementation detail. One

Turing-complete solution is as good as any other -- the key is the

modelling abstraction (and whether it does the job). But, lurking

behind Sandy's point, Arthur, is the following question: how does one

have this discussion with a conversational partner whose eyes roll at

the first mention of "isomorphic", "HLPN", "pi Calculus" or any other

such thing? ;) You don't even touch on the apples-to-oranges aspect

of this nonsense, since, strictly speaking, XPDL isn't an execution

language at all.

Given the events of the last few days, I'm prompted to make the

following analogy: business / IT purchasers are no more capable of

making these distinctions than your typical member of the US House of

Representatives can tell me what a centralised debt obligation is.

And in the same toxic way, such a climate of ignorance is ripe for

exploitation.

How do we make the truth "understandable"?

Oct 1, 2008, 9:27:37 PM10/1/08

to Workflow Patterns Group

Sandy: yes, you can certainly quote me on this. And if you feel more

is required from my part in order to make these arguments (more)

accessible to a wider audience please let me know.

BTW, I fully agree with your observation that if you are not using

BPEL this does not imply that “a lot of custom code” is required.

Arthur

is required from my part in order to make these arguments (more)

accessible to a wider audience please let me know.

BTW, I fully agree with your observation that if you are not using

BPEL this does not imply that “a lot of custom code” is required.

Arthur

Oct 1, 2008, 9:30:05 PM10/1/08

to Workflow Patterns Group

Mark: Indeed, how do you deal with insufficient understanding of (or

appreciation for) fundamentals in the community at large? As academics

we have an important role to play in educating our students, but how

to really reach the professional community out there?

Arthur

appreciation for) fundamentals in the community at large? As academics

we have an important role to play in educating our students, but how

to really reach the professional community out there?

Arthur

Oct 23, 2008, 11:24:17 AM10/23/08

to Workflow Patterns Group

Arthur,

Thank you for this detailed answer. I would have liked to see it on

the original blog post for all to see, but I'm happy to join this

thread as well. I must say that I am quite mystified by your counter

argument. Implying that two languages are equivalent because they both

are "Turing complete" is utterly misleading. If one is to believe

this, then most programming languages are pretty much equivalent, and

we shall use them interchangeably for anything. A linguist might be

seduced by this universalist view, but a practitioner of enterprise

system development knows better.

In making my arguments, I tried to simplify things as much as

possible, and referred to mathematics only when necessary. I am

arguing that BPEL is closely related to Pi-Calculus, while XPDL is

closer to a Petri-Net model. If you are refuting this argument, you

will have to go in more details. For example, your main point against

my argument seems to be that BPEL does not support channel passing.

Well, I beg to differ. The ability to assign partner links to/from

variables is as close to channel passing as it gets. If you want more

background on this concept, please follow this link:

http://markmail.org/message/ft7icpxbgerzvrdy

And if you have any doubt of the author's qualification for making

such a statement, his name is Assaf Arkin, he is CTO of Intalio,

author of BPML, co-author of BPEL, and here is what Robin Milner,

inventor of Pi-Calculus, had to say about him in this interview:

http://www.informatics.sussex.ac.uk/users/mfb21/interviews/milner/

"It's the philosophy behind the language BPML (Business Process

Management Language), designed and implemented by Assaf Arkin, who

works for a for a small company called Intalio, in association with

BPML.org, a public domain institution which tries to understand

business process modelling. He based it on the Pi-Calculus. Assaf

Arkin knows a lot about the Pi-Calculus. Howard Smith and Peter

Fingar, who wrote the book together, say that as a result they get a

better model of business processes than before. He claims, because of

Arkin's work, that it does take its ideas from the Pi-Calculus, and

that they have been able to do things they could not do before. It

seems very promising."

If my marketing pitch does not convince you, then you'll have to come

back with a stronger mathematical answer.

Cheers!

-Ismael

Thank you for this detailed answer. I would have liked to see it on

the original blog post for all to see, but I'm happy to join this

thread as well. I must say that I am quite mystified by your counter

argument. Implying that two languages are equivalent because they both

are "Turing complete" is utterly misleading. If one is to believe

this, then most programming languages are pretty much equivalent, and

we shall use them interchangeably for anything. A linguist might be

seduced by this universalist view, but a practitioner of enterprise

system development knows better.

In making my arguments, I tried to simplify things as much as

possible, and referred to mathematics only when necessary. I am

arguing that BPEL is closely related to Pi-Calculus, while XPDL is

closer to a Petri-Net model. If you are refuting this argument, you

will have to go in more details. For example, your main point against

my argument seems to be that BPEL does not support channel passing.

Well, I beg to differ. The ability to assign partner links to/from

variables is as close to channel passing as it gets. If you want more

background on this concept, please follow this link:

http://markmail.org/message/ft7icpxbgerzvrdy

And if you have any doubt of the author's qualification for making

such a statement, his name is Assaf Arkin, he is CTO of Intalio,

author of BPML, co-author of BPEL, and here is what Robin Milner,

inventor of Pi-Calculus, had to say about him in this interview:

http://www.informatics.sussex.ac.uk/users/mfb21/interviews/milner/

"It's the philosophy behind the language BPML (Business Process

Management Language), designed and implemented by Assaf Arkin, who

works for a for a small company called Intalio, in association with

BPML.org, a public domain institution which tries to understand

business process modelling. He based it on the Pi-Calculus. Assaf

Arkin knows a lot about the Pi-Calculus. Howard Smith and Peter

Fingar, who wrote the book together, say that as a result they get a

better model of business processes than before. He claims, because of

Arkin's work, that it does take its ideas from the Pi-Calculus, and

that they have been able to do things they could not do before. It

seems very promising."

If my marketing pitch does not convince you, then you'll have to come

back with a stronger mathematical answer.

Cheers!

-Ismael

Oct 24, 2008, 12:51:10 AM10/24/08

to workflow...@googlegroups.com

Hi all,

This is exactly what Arthur was pointing out: given vagueness of the relationships between BPEL, BPML and their formal precursors, that this is about as useful as the statement that they are mapped to a language that's Turing Complete. A roll of toilet paper and a stone is also legendarily Turing complete... but it does not help in doing formal analysis of computations. I suggest you read it again:

2008/10/24 Ghalimi <gha...@gmail.com>

Thank you for this detailed answer. I would have liked to see it on

the original blog post for all to see, but I'm happy to join this

thread as well. I must say that I am quite mystified by your counter

argument. Implying that two languages are equivalent because they both

are "Turing complete" is utterly misleading.

This is exactly what Arthur was pointing out: given vagueness of the relationships between BPEL, BPML and their formal precursors, that this is about as useful as the statement that they are mapped to a language that's Turing Complete. A roll of toilet paper and a stone is also legendarily Turing complete... but it does not help in doing formal analysis of computations. I suggest you read it again:

Oct 24, 2008, 5:39:59 AM10/24/08

to workflow...@googlegroups.com

On Fri, Oct 24, 2008 at 12:24 AM, Ghalimi <gha...@gmail.com> wrote:

>

> In making my arguments, I tried to simplify things as much as

> possible, and referred to mathematics only when necessary. I am

> arguing that BPEL is closely related to Pi-Calculus, while XPDL is

> closer to a Petri-Net model.

>

> In making my arguments, I tried to simplify things as much as

> possible, and referred to mathematics only when necessary. I am

> arguing that BPEL is closely related to Pi-Calculus, while XPDL is

> closer to a Petri-Net model.

Hi Ismael,

your pedigree proof for BPML is extremely convincing. The interview

piece is perfect and easy to understand for the Average Joe I'm.

But then, where did you get the link from XPDL to the Petri-Nets ? The

wikipedia page for XPDL (as of today), doesn't state anything about

Petri-Nets. Arthur already discarded as well that link you suggest.

Ismael wrote in http://itredux.com/2008/09/28/why-bpel/ :

>

> If they use XPDL, they're taking advantage of the Petrinet model for supporting the execution of standalone processes.

> If they use their own language or execution model, it's a hack devoid of any strong mathematical foundation,

> and it won't scale over the long run.

IIRC (or if I've googled correctly), YAWL

(http://www.yawl-system.com/) is the only workflow management system

based [directly] on Petri-Nets. In the context of your blog, only BPEL

based systems and YAWL have a strong mathematical foundation. So be

it, discarding "weak" sytems still leaves a lot of options (for the

open source world, I can think of jBPM, Ode and Orchestra for BPEL and

then the lone YAWL).

I'm glad you qualify Petri-Nets as a "strong mathematical foundation",

but it's a bit scary to see them leveraged as a useful adversary on

other occasions :

http://www.garyrgilbert.com/blog/index.cfm/2008/5/29/First-Impressions-Intalio-BPMS

(kudos for the excellent rating you got from Gary there)

I guess that other commercial vendors used "Petri-Nets vs Pi-Calculus"

against you, so you feel entitled to use the reverse technique, but I

think it's your responsibility as the "2.0" leader you are to play a

positive game.

Thanks to you and Arthur for the energy, vision and strength you bring

to the field.

Best regards,

--

John Mettraux - http://jmettraux.wordpress.com

Oct 24, 2008, 9:04:25 AM10/24/08

to Workflow Patterns Group

John,

I'm all for playing the positive game, as long as everybody plays

along.

If I am to be attacked on technical/mathematical grounds, please make

sure to provide a more solid argument. As far as I can tell, Arthur's

main point was that BPEL did not support channel passing, and this is

all plain wrong, as was confirmed by Assaf Arkin again yesterday:

http://itredux.com/2008/10/23/bpel-and-pi-calculus/

Please read my latest blog post, and show me that XPDL can support the

scenario we presented.

http://itredux.com/2008/10/23/bpel-and-pi-calculus/

Come on guys, teach me something I don't already know.

-Ismael

On Oct 24, 2:39 am, "John Mettraux" <jmettr...@gmail.com> wrote:

I'm all for playing the positive game, as long as everybody plays

along.

If I am to be attacked on technical/mathematical grounds, please make

sure to provide a more solid argument. As far as I can tell, Arthur's

main point was that BPEL did not support channel passing, and this is

all plain wrong, as was confirmed by Assaf Arkin again yesterday:

http://itredux.com/2008/10/23/bpel-and-pi-calculus/

Please read my latest blog post, and show me that XPDL can support the

scenario we presented.

http://itredux.com/2008/10/23/bpel-and-pi-calculus/

Come on guys, teach me something I don't already know.

-Ismael

On Oct 24, 2:39 am, "John Mettraux" <jmettr...@gmail.com> wrote:

> On Fri, Oct 24, 2008 at 12:24 AM, Ghalimi <ghal...@gmail.com> wrote:

>

> > In making my arguments, I tried to simplify things as much as

> > possible, and referred to mathematics only when necessary. I am

> > arguing that BPEL is closely related to Pi-Calculus, while XPDL is

> > closer to a Petri-Net model.

>

> Hi Ismael,

>

> your pedigree proof for BPML is extremely convincing. The interview

> piece is perfect and easy to understand for the Average Joe I'm.

>

> But then, where did you get the link from XPDL to the Petri-Nets ? The

> wikipedia page for XPDL (as of today), doesn't state anything about

> Petri-Nets. Arthur already discarded as well that link you suggest.

>

>

> > In making my arguments, I tried to simplify things as much as

> > possible, and referred to mathematics only when necessary. I am

> > arguing that BPEL is closely related to Pi-Calculus, while XPDL is

> > closer to a Petri-Net model.

>

> Hi Ismael,

>

> your pedigree proof for BPML is extremely convincing. The interview

> piece is perfect and easy to understand for the Average Joe I'm.

>

> But then, where did you get the link from XPDL to the Petri-Nets ? The

> wikipedia page for XPDL (as of today), doesn't state anything about

> Petri-Nets. Arthur already discarded as well that link you suggest.

>

> Ismael wrote inhttp://itredux.com/2008/09/28/why-bpel/:

>

>

>

> > If they use XPDL, they're taking advantage of the Petrinet model for supporting the execution of standalone processes.

> > If they use their own language or execution model, it's a hack devoid of any strong mathematical foundation,

> > and it won't scale over the long run.

>

> IIRC (or if I've googled correctly), YAWL

> (http://www.yawl-system.com/) is the only workflow management system

> based [directly] on Petri-Nets. In the context of your blog, only BPEL

> based systems and YAWL have a strong mathematical foundation. So be

> it, discarding "weak" sytems still leaves a lot of options (for the

> open source world, I can think of jBPM, Ode and Orchestra for BPEL and

> then the lone YAWL).

>

> I'm glad you qualify Petri-Nets as a "strong mathematical foundation",

> but it's a bit scary to see them leveraged as a useful adversary on

> other occasions :http://www.garyrgilbert.com/blog/index.cfm/2008/5/29/First-Impression...
>

>

>

> > If they use XPDL, they're taking advantage of the Petrinet model for supporting the execution of standalone processes.

> > If they use their own language or execution model, it's a hack devoid of any strong mathematical foundation,

> > and it won't scale over the long run.

>

> IIRC (or if I've googled correctly), YAWL

> (http://www.yawl-system.com/) is the only workflow management system

> based [directly] on Petri-Nets. In the context of your blog, only BPEL

> based systems and YAWL have a strong mathematical foundation. So be

> it, discarding "weak" sytems still leaves a lot of options (for the

> open source world, I can think of jBPM, Ode and Orchestra for BPEL and

> then the lone YAWL).

>

> I'm glad you qualify Petri-Nets as a "strong mathematical foundation",

> but it's a bit scary to see them leveraged as a useful adversary on

Oct 24, 2008, 11:09:27 AM10/24/08

to workflow...@googlegroups.com

On Fri, Oct 24, 2008 at 10:04 PM, Ghalimi <gha...@gmail.com> wrote:

>

> Please read my latest blog post, and show me that XPDL can support the

> scenario we presented.

>

> http://itredux.com/2008/10/23/bpel-and-pi-calculus/

>

> Come on guys, teach me something I don't already know.

>

> Please read my latest blog post, and show me that XPDL can support the

> scenario we presented.

>

> http://itredux.com/2008/10/23/bpel-and-pi-calculus/

>

> Come on guys, teach me something I don't already know.

I have nothing to teach you, but here is an implementation of your

scenario, in Ruby :

---8<---

$p0 = Thread.new do

puts("P0 (User)")

$p1 = Thread.new do

puts("P1")

$p2 = Thread.new do

puts("P2")

end

puts "something is happening here"

$p2.join

end

$p1.join

end

$p0.join

--->8---

You can call me lazy, I didn't go all the stack up to XPDL. At least I

know it will run on your mac.

Kind regards, +1 to Keith and Turing,

Oct 24, 2008, 11:39:48 AM10/24/08

to Workflow Patterns Group

John,

Very funny.

I'll send you my version of this process using carrier pigeons in a

separate post.

Joke aside, did you take a look at SimPEL? What do you think?

-Ismael

On Oct 24, 8:09 am, "John Mettraux" <jmettr...@gmail.com> wrote:

Very funny.

I'll send you my version of this process using carrier pigeons in a

separate post.

Joke aside, did you take a look at SimPEL? What do you think?

-Ismael

On Oct 24, 8:09 am, "John Mettraux" <jmettr...@gmail.com> wrote:

Oct 24, 2008, 2:17:44 PM10/24/08

to Workflow Patterns Group

Keith,

The formal relationship between BPEL, BPML and their formal precursors

isn't provable with the current available theory. I don't think Ismael

claimed having such a formal analysis, it would, by itself, be a

significant breakthrough in the field of computation. I don't think we

even know whether it's provable at all, so trying to either validate

or invalidate this relationship formally is just foolish. And

injecting some academic self-righteousness in the discussion doesn't

help.

I tend to find annoying when one postulates that an argument needs to

be proven (as in mathematical proof) to be set forth. If we look at

what's been proven so far in computation, we won't talk a lot. The

inspiration that business process languages get from formal theory is

just good engineering practices and is therefore subjective. Having a

good engineering discussion is always interesting, isn't it?

Cheers,

Matthieu

On Oct 23, 9:51 pm, "Keith Duddy" <keith.du...@gmail.com> wrote:

> Hi all,

>

> 2008/10/24 Ghalimi <ghal...@gmail.com>

The formal relationship between BPEL, BPML and their formal precursors

isn't provable with the current available theory. I don't think Ismael

claimed having such a formal analysis, it would, by itself, be a

significant breakthrough in the field of computation. I don't think we

even know whether it's provable at all, so trying to either validate

or invalidate this relationship formally is just foolish. And

injecting some academic self-righteousness in the discussion doesn't

help.

I tend to find annoying when one postulates that an argument needs to

be proven (as in mathematical proof) to be set forth. If we look at

what's been proven so far in computation, we won't talk a lot. The

inspiration that business process languages get from formal theory is

just good engineering practices and is therefore subjective. Having a

good engineering discussion is always interesting, isn't it?

Cheers,

Matthieu

On Oct 23, 9:51 pm, "Keith Duddy" <keith.du...@gmail.com> wrote:

> Hi all,

>

> 2008/10/24 Ghalimi <ghal...@gmail.com>

Oct 24, 2008, 10:11:32 PM10/24/08

to workflow...@googlegroups.com

On Sat, Oct 25, 2008 at 12:39 AM, Ghalimi <gha...@gmail.com> wrote:

>

> Very funny.

>

> I'll send you my version of this process using carrier pigeons in a

> separate post.

>

> Very funny.

>

> I'll send you my version of this process using carrier pigeons in a

> separate post.

This version of yours would still be a valid implementation of the

BPMN diagram. But you're one step ahead of me, doing "green computing"

;)

My script is funny but then you realize its cousins are actually out

there, automating business processes, but it's not funny when the

script is planted as a workaround to a BPMS. Don't overlook the funny

scripts.

It would be good to see a diagram that illustrates the 'channel

passing' feature BPEL inherited from Pi-Calculus.

> Joke aside, did you take a look at SimPEL? What do you think?

Yes, I've been following it. The developer is a smart one.

> I'm all for playing the positive game, as long as everybody plays along.

I would find it positive for the image of your company if you stopped

making an abusive usage of Petri-Nets in your communication and in

your user training. There are other ways of using them, for example :

http://eprints.qut.edu.au/archive/00014809/

I reproduce the abstract here so that it won't get overlooked as it

was when Arthur first linked to it :

| Web service composition refers to the creation of new (Web) services by

| combining functionalities provided by existing ones. A number of

| domain-specific languages for service composition have been proposed, with

| consensus being formed around a process-oriented language known as WS-BPEL

| (or BPEL). The kernel of BPEL consists of simple communication primitives

| that may be combined using control-flow constructs expressing sequence,

| branching, parallelism, synchronization, etc. We present a comprehensive and

| rigorously defined mapping of BPEL constructs onto Petri net structures, and

| use this for the analysis of various dynamic properties related to

| unreachable activities, conflicting messages, garbage collection, conformance

| checking, and deadlocks and lifelocks in interaction processes. We use a

| mapping onto Petri nets because this allows us to use existing theoretical

| results and analysis tools. Unlike approaches based on finite state machines,

| we do not need to construct the state space, and can use structural analysis

| (e.g., transition invariants) instead. We have implemented a tool that

| translates BPEL processes into Petri nets and then applies Petri-net-based

| analysis techniques. This tool has been tested on different examples, and has

| been used to answer a variety of questions.

See ? No opposition. A "pi-calculus vs petri-nets" polarization is

easier to frame for your consumers, but please don't go on this "easy

way". Seems like your latest it|redux posts take a more positive

stance, focusing on the benefits brought by the pi-calculus, that's

great.

Thank you, kind regards,

Oct 25, 2008, 1:11:05 PM10/25/08

to Workflow Patterns Group

John,

Here is how channel passing is supported, per Assaf's comment on IT|

Redux:

"Channels are referenced as partner links, communicated in messages

using the service-ref element, and you can copy from inbound channel

(my role) to service-ref and from service-ref to outbound channel

(partner role). There’s no lack of semantics here, and you can find

all that information from a quick read of the spec."

Happy to give you a discount for our next Intalio training in Japan if

you want to learn more about it.

Regarding Petri-Nets, please be assured that I have nothing against

them. The article you referenced is great at explaining how BPEL can

be mapped onto Petri-Nets, and a similar piece of work could be done

for XPDL. What most people are missing though is that BPEL, through

its support for channel passing, goes much beyond what the Petri-Nets

model supports, and this is the whole point of my argument. But

somehow, many people do not seem to like this idea, and I really do

not understand why. Nevertheless, I'll keep pushing this over-

simplified Pi-Calculus vs Petri-Nets polarization, for it's the best

embodiment I found of a very important idea. End-to-end processes are

inherently distributed, and Pi-Calculus (or ambient calculus) are

better ways to describe them, through higher-level languages such as

BPEL and SimPEL, themselves supported by higher-level notations such

as BPMN (when using its multi-swimlane support).

And guess what? The paper you're referencing only shows one BPEL

process at a time. There is not one diagram that shows how multiple

BPEL processes can be orchestrated together. Don't you find that a

little bit weird? In other words, if you don't look for it, you won't

find it, but it's sitting right in front of you...

The same was true for the BPMN 1.0 specification. If you were to read

it cursively, you'd never guess that it would offer support for

multiple swimlanes, hence multiple processes.

-Ismael

On Oct 24, 7:11 pm, "John Mettraux" <jmettr...@gmail.com> wrote:

Here is how channel passing is supported, per Assaf's comment on IT|

Redux:

"Channels are referenced as partner links, communicated in messages

using the service-ref element, and you can copy from inbound channel

(my role) to service-ref and from service-ref to outbound channel

(partner role). There’s no lack of semantics here, and you can find

all that information from a quick read of the spec."

Happy to give you a discount for our next Intalio training in Japan if

you want to learn more about it.

Regarding Petri-Nets, please be assured that I have nothing against

them. The article you referenced is great at explaining how BPEL can

be mapped onto Petri-Nets, and a similar piece of work could be done

for XPDL. What most people are missing though is that BPEL, through

its support for channel passing, goes much beyond what the Petri-Nets

model supports, and this is the whole point of my argument. But

somehow, many people do not seem to like this idea, and I really do

not understand why. Nevertheless, I'll keep pushing this over-

simplified Pi-Calculus vs Petri-Nets polarization, for it's the best

embodiment I found of a very important idea. End-to-end processes are

inherently distributed, and Pi-Calculus (or ambient calculus) are

better ways to describe them, through higher-level languages such as

BPEL and SimPEL, themselves supported by higher-level notations such

as BPMN (when using its multi-swimlane support).

And guess what? The paper you're referencing only shows one BPEL

process at a time. There is not one diagram that shows how multiple

BPEL processes can be orchestrated together. Don't you find that a

little bit weird? In other words, if you don't look for it, you won't

find it, but it's sitting right in front of you...

The same was true for the BPMN 1.0 specification. If you were to read

it cursively, you'd never guess that it would offer support for

multiple swimlanes, hence multiple processes.

-Ismael

On Oct 24, 7:11 pm, "John Mettraux" <jmettr...@gmail.com> wrote:

Oct 25, 2008, 1:13:32 PM10/25/08

to Workflow Patterns Group

Quick correction: there is one, on section 3.7.

My point remains the same though. The most fundamental element of BPEL

is almost completely overlooked.

-Ismael

My point remains the same though. The most fundamental element of BPEL

is almost completely overlooked.

-Ismael

Oct 26, 2008, 4:28:37 AM10/26/08

to workflow...@googlegroups.com

On Sun, Oct 26, 2008 at 2:11 AM, Ghalimi <gha...@gmail.com> wrote:

>

> Here is how channel passing is supported, per Assaf's comment on IT|

> Redux:

>

> "Channels are referenced as partner links, communicated in messages

> using the service-ref element, and you can copy from inbound channel

> (my role) to service-ref and from service-ref to outbound channel

> (partner role). There's no lack of semantics here, and you can find

> all that information from a quick read of the spec."

>

> Happy to give you a discount for our next Intalio training in Japan if

> you want to learn more about it.

>

> Here is how channel passing is supported, per Assaf's comment on IT|

> Redux:

>

> "Channels are referenced as partner links, communicated in messages

> using the service-ref element, and you can copy from inbound channel

> (my role) to service-ref and from service-ref to outbound channel

> (partner role). There's no lack of semantics here, and you can find

> all that information from a quick read of the spec."

>

> Happy to give you a discount for our next Intalio training in Japan if

> you want to learn more about it.

I'll try to find a sponsor and to attend, I'll be glad to learn more

about your suite. But please allow me to step out of the classroom

during the "pi-calculus vs petri-nets" slides of the Intalio training,

for IMHO they contain - to use your words - "bogus pseudo-scientific

statements".

> Regarding Petri-Nets, please be assured that I have nothing against

> them. The article you referenced is great at explaining how BPEL can

> be mapped onto Petri-Nets, and a similar piece of work could be done

> for XPDL. What most people are missing though is that BPEL, through

> its support for channel passing, goes much beyond what the Petri-Nets

> model supports, and this is the whole point of my argument.

> But somehow, many people do not seem to like this idea, and I really do

> not understand why. Nevertheless, I'll keep pushing this over-

> simplified Pi-Calculus vs Petri-Nets polarization, for it's the best

> embodiment I found of a very important idea. End-to-end processes are

> inherently distributed, and Pi-Calculus (or ambient calculus) are

> better ways to describe them, through higher-level languages such as

> BPEL and SimPEL, themselves supported by higher-level notations such

> as BPMN (when using its multi-swimlane support).

OK, I'll be glad to teach myself about how to draw a BPMN diagram that

generates a BPEL document that leverages channel passing, during the

Intalio training.

> And guess what? The paper you're referencing only shows one BPEL

> process at a time. There is not one diagram that shows how multiple

> BPEL processes can be orchestrated together. Don't you find that a

> little bit weird? In other words, if you don't look for it, you won't

> find it, but it's sitting right in front of you...

I guess that you mean "how multiple BPEL processes can be

choreographed together".

> The same was true for the BPMN 1.0 specification. If you were to read

> it cursively, you'd never guess that it would offer support for

> multiple swimlanes, hence multiple processes.

On Sun, Oct 26, 2008 at 2:13 AM, Ghalimi <gha...@gmail.com> wrote:

>

> Quick correction: there is one, on section 3.7.

>

> My point remains the same though. The most fundamental element of BPEL

> is almost completely overlooked.

OK, I guess this element of BPEL is "channel passing", inherited from

Pi-Calculus. In BPEL-speak, that means passing the coordinates of a

process (service-ref) to another process over a message flow. Process

P0 receives a message from process P1 containing, in particular the

coordinates (potentially previously unknown) of process P2, thus

allowing process P0 to send a message to process P2.

I couldn't imagine living without that, even when prefixing "process"

with "sub-".

On the question of whether or not Petri-Nets support multiple

processes or are better at describing them, I would have pointed to

"hierarchical Petri-nets", but the section 3.7 that you mention seems

not to use them, it models the channel a request/response pair of

places labelled "communication medium", maybe that could embody the

message flow / channel of BPEL, respectively Pi-Calculus.

So I have to say that I don't know how to represent this "channel

passing" concept via Petri-Nets (nor do I know how to do it via BPMN

and its multi-pools), but, since you qualified this conversation here

as a "silly discussion", the greatest part of this "silly" label is

for me to bear and that lets me escape with my ignorance.

Kind regards,

Oct 26, 2008, 10:15:23 AM10/26/08

to Workflow Patterns Group

John,

You got it! Here lies one of the fundamental differences between Pi-

Calculus and Petri-Nets, and one of the fundamental differences

between BPEL (or BPML) for that matter, and any other languages that

were mentioned in this discussion.

-Ismael

On Oct 26, 1:28 am, "John Mettraux" <jmettr...@gmail.com> wrote:

You got it! Here lies one of the fundamental differences between Pi-

Calculus and Petri-Nets, and one of the fundamental differences

between BPEL (or BPML) for that matter, and any other languages that

were mentioned in this discussion.

-Ismael

On Oct 26, 1:28 am, "John Mettraux" <jmettr...@gmail.com> wrote:

Oct 26, 2008, 11:07:47 AM10/26/08

to Workflow Patterns Group

It is great to see that there has been some more discussion. Let me

address some of the issues raised.

First, let me say something about the issue of channel passing. I did

not say that channel passing can not be encoded in BPEL. In addition,

channel passing was not the main point of my post. It is essentially

just one communication pattern out of many (let alone control-flow,

data, resource and exception handling patterns). I believe the focus

on this single pattern is not very helpful for the field. Yes of

course you can encode channel passing in BPEL, or in Java for that

matter. Just write a Java Web service that passes a service endpoint

to another one, then the latter uses it to reply back to the former.

Channel passing is not really a part of the control-flow in BPEL, you

have to resort to the data flow to encode it. This is quite a

different matter in the pi-calculus: channel passing is an integral

part of pi-calculus and plays a central role in its underlying

reduction rules. In pi-calculus, channel passing is used to reason

about a system. In BPEL, it is simply used to pass endpoint

references.

This brings me to the difference between expressiveness and

suitability. Expressiveness, in the sense of Turing-computable, is not

a very interesting notion in this area. Any programming language is

Turing complete. Suitability on the other hand is of great interest.

This is a fuzzier notion, but as the workflow patterns initiative has

shown it is possible to get a handle on this. It is all about the

alignment between concepts in the language and concepts that occur in

the problem domain. The fact that BPEL (as any Turing-complete

language) can be used to encode channel passing is a statement of

limited value. There are just so many other capabilities that a BPM

engine needs to support, e.g. resource allocation. To focus the entire

claim of the supposed superiority of a language on this single

capability baffles me.

Also, is this all there is to the claim that BPEL is based on the pi-

calculus: that it is possible to encode (!) channel-passing in BPEL??

Let me quote Assaf Arkin here: "You have to remember that the

relationship between BPML and pi-calculus is the same as the

relationship between Java and lambda-calculus." (source:

http://markmail.org/message/3fa6w4od2bia7t4c). I could not agree more

with this statement as the lambda calculus and Java can live happily

without each other (it would have been different if he had mentioned a

functional language such as Haskell obviously). Imagine if SUN had

promoted Java using the argument that it is based on the lambda-

calculus!

As a side note, it is intriguing to observe how effortlessly, from a

marketing perspective, the switch between BPML and BPEL has been made

in the past few years. Once there was a battle between the two camps,

but apparently from a pi-calculus point of view, we have come to learn

that there are no substantial differences.

@Ismael: I feel I have now addressed the issue of channel passing and

my position on expressiveness vs suitability. Many of the other points

I have raised you have not addressed. E.g. what is the relationship

between XPDL and Petri nets? Here I fear the onus is on you; I've

observed in my original post that 50% of the concepts of Petri nets

have no equivalent in XPDL. Also, why are you claiming that BPEL and

XPDL are the only formally defined languages? Why do you think Petri

nets cannot suitably deal with inter-process communication (noting

that I provided a reference proving the opposite)? I think you're

quite selective about the points you choose to reply to.

@Mathieu. When you deal with the transition of informal approaches

(e.g. BPEL) to formal theories you will always have to deal with

ambiguities in the informal approach. No amount of new theory is going

to help you there. I also feel your comments are beside the point.

When it is claimed that a certain new (informal) approach derives some

great properties from a certain formal theory, then you have to show

this by (a) providing a complete mapping; and (b) demonstrating that

this mapping provides you with certain benefits (e.g. it enables

verification). This has been done successfully on many occasions btw.

The original statements that I objected to, and still do, are

incorrect and do not help the recognition of the benefits of more

formal approaches in industry. In fact, I fear that these statements

(by Ismael) may lead to a backlash against formal methods in BPM. Once

people conclude that the emperor does not have any clothes (in the

case of BPEL and the pi-calculus) they may conclude that there isn't

any benefit at all in the use of formal theory.

Finally, in case it wasn't clear enough, this is not a pi-calculus vs

Petri net debate per se, it is more about how these formalisms are

pitted against each other in an uninformed manner and about how links

are claimed with other formalisms where no meaningful links exist. The

abuse that the pi-calculus has endured at the hands of some, could

also have happened to Petri nets. I feel it is time to recognise once

and for all that the pi-calculus has been abused by some for marketing

purposes in the field of BPM. A great shame as it is a beautiful

theory.

address some of the issues raised.

First, let me say something about the issue of channel passing. I did

not say that channel passing can not be encoded in BPEL. In addition,

channel passing was not the main point of my post. It is essentially

just one communication pattern out of many (let alone control-flow,

data, resource and exception handling patterns). I believe the focus

on this single pattern is not very helpful for the field. Yes of

course you can encode channel passing in BPEL, or in Java for that

matter. Just write a Java Web service that passes a service endpoint

to another one, then the latter uses it to reply back to the former.

Channel passing is not really a part of the control-flow in BPEL, you

have to resort to the data flow to encode it. This is quite a

different matter in the pi-calculus: channel passing is an integral

part of pi-calculus and plays a central role in its underlying

reduction rules. In pi-calculus, channel passing is used to reason

about a system. In BPEL, it is simply used to pass endpoint

references.

This brings me to the difference between expressiveness and

suitability. Expressiveness, in the sense of Turing-computable, is not

a very interesting notion in this area. Any programming language is

Turing complete. Suitability on the other hand is of great interest.

This is a fuzzier notion, but as the workflow patterns initiative has

shown it is possible to get a handle on this. It is all about the

alignment between concepts in the language and concepts that occur in

the problem domain. The fact that BPEL (as any Turing-complete

language) can be used to encode channel passing is a statement of

limited value. There are just so many other capabilities that a BPM

engine needs to support, e.g. resource allocation. To focus the entire

claim of the supposed superiority of a language on this single

capability baffles me.

Also, is this all there is to the claim that BPEL is based on the pi-

calculus: that it is possible to encode (!) channel-passing in BPEL??

Let me quote Assaf Arkin here: "You have to remember that the

relationship between BPML and pi-calculus is the same as the

relationship between Java and lambda-calculus." (source:

http://markmail.org/message/3fa6w4od2bia7t4c). I could not agree more

with this statement as the lambda calculus and Java can live happily

without each other (it would have been different if he had mentioned a

functional language such as Haskell obviously). Imagine if SUN had

promoted Java using the argument that it is based on the lambda-

calculus!

As a side note, it is intriguing to observe how effortlessly, from a

marketing perspective, the switch between BPML and BPEL has been made

in the past few years. Once there was a battle between the two camps,

but apparently from a pi-calculus point of view, we have come to learn

that there are no substantial differences.

@Ismael: I feel I have now addressed the issue of channel passing and

my position on expressiveness vs suitability. Many of the other points

I have raised you have not addressed. E.g. what is the relationship

between XPDL and Petri nets? Here I fear the onus is on you; I've

observed in my original post that 50% of the concepts of Petri nets

have no equivalent in XPDL. Also, why are you claiming that BPEL and

XPDL are the only formally defined languages? Why do you think Petri

nets cannot suitably deal with inter-process communication (noting

that I provided a reference proving the opposite)? I think you're

quite selective about the points you choose to reply to.

@Mathieu. When you deal with the transition of informal approaches

(e.g. BPEL) to formal theories you will always have to deal with

ambiguities in the informal approach. No amount of new theory is going

to help you there. I also feel your comments are beside the point.

When it is claimed that a certain new (informal) approach derives some

great properties from a certain formal theory, then you have to show

this by (a) providing a complete mapping; and (b) demonstrating that

this mapping provides you with certain benefits (e.g. it enables

verification). This has been done successfully on many occasions btw.

The original statements that I objected to, and still do, are

incorrect and do not help the recognition of the benefits of more

formal approaches in industry. In fact, I fear that these statements

(by Ismael) may lead to a backlash against formal methods in BPM. Once

people conclude that the emperor does not have any clothes (in the

case of BPEL and the pi-calculus) they may conclude that there isn't

any benefit at all in the use of formal theory.

Finally, in case it wasn't clear enough, this is not a pi-calculus vs

Petri net debate per se, it is more about how these formalisms are

pitted against each other in an uninformed manner and about how links

are claimed with other formalisms where no meaningful links exist. The

abuse that the pi-calculus has endured at the hands of some, could

also have happened to Petri nets. I feel it is time to recognise once

and for all that the pi-calculus has been abused by some for marketing

purposes in the field of BPM. A great shame as it is a beautiful

theory.

Oct 26, 2008, 12:12:07 PM10/26/08

to Workflow Patterns Group

Arthur,

Fair enough. Please take a look at this article:

http://itredux.com/2008/10/26/bpmiorg-redux/

If you join us in this effort, I promise never to use the words Petri-

Nets and Pi-Calculus in the same sentence.

How does that sound?

Best regards

-Ismael

Fair enough. Please take a look at this article:

http://itredux.com/2008/10/26/bpmiorg-redux/

If you join us in this effort, I promise never to use the words Petri-

Nets and Pi-Calculus in the same sentence.

How does that sound?

Best regards

-Ismael

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu