Cobbler, stick to thy last
Arthur
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
Sandy Kemsley
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
mastermark
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"?
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
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
Ghalimi
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
Keith Duddy
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:
John Mettraux
>
> 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
Ghalimi
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:
>
> > 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.
>
>
>
>
> > 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
John Mettraux
>
> 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,
Ghalimi
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:
Matthieu Riou
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>
John Mettraux
>
> 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,
Ghalimi
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:
Ghalimi
My point remains the same though. The most fundamental element of BPEL
is almost completely overlooked.
-Ismael
John Mettraux
>
> 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,
Ghalimi
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:
Arthur
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.
Ghalimi
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