Re: Why workflow is NOT just a Pi-process

Jean-Jacques Dubray wrote:

> Assaf:
>
> I am not the one who originally linked pi calculus to Intalio's 
> designer tool. Looking at some papers recently published which are 
> portraiying Intalio's designer tool as the best pi calculus tool 
> (which I agree, it is the closest that I have ever seen, you guys did 
> really a great job with that respect).
>
> Now, speaking of pi-calculus (as illustrated by examples using 
> Intalio's designer tool), I don't see how you can technically refute 
> that by making everything a process:
>
> A) it requires high levels of compositions (nesting) to be able to 
> support all layers from UI to DB. I content that the numbers of level 
> makes it impractical
>
> B) that pi calculus does not allow you to explicitly specify domains 
> of control that are collaborating with each other (they are at best 
> implicit)
>
> C) as a result, pi-calculus based solutions must implement a single 
> "process virtual machine" which "executes" all the processes that are 
> composed. I think this is Intalio's architecture
>
I do not understand why you imagine that our product is a pi-calculus 
engine equivalent to, say PICT, and not a fully grown BPMS. It is, in 
fact a BPMS. And as such, it fulfills all the requirements of BPMS. I 
don't think our expertise with pi-calculus has clouded our judgment, 
just like I don't believe our expertise with SQL or TCP has prevented us 
from realizing a BPMS.

So to answer your questions:

a) nope. you can have any arbitrary level of nesting that meets your 
needs, and different levels of nesting at the same time.
b) maybe pi-calc doesn't allow that, but our product does. we do quite 
neatly express domains of controls, as you can see in the screenshots.
c) nope. that's not our architecture and we never even considered that 
option.

So again, it's very helpful to ask questions before arriving at 
conclusions, especially if you're expressing an opinion about another 
vendor's product in a public mailing list dedicated to working on a 
vendor-neutral specification.

> I would be really interested in your opinion about choreography versus 
> orchestration. Howard thinks that choreography are necessary. I have 
> heard otherwise from some of the prominent pi-calculus experts.
>
If that was a conceptual question, I would agree with other pi-calculus 
experts. But I do have to take other considerations into account, 
including interchange of definitions, modeling tool, management and 
deployment, etc. What we call real-life requirements. In pi-calculus you 
don't need to label an action. In a process definition language you do 
need to label an action, because it helps the designer and 
administrator, hence the @name attribute. It doesn't exist in pi-c, but 
it's absolutely required in a process definition language. Similarly, 
there are many other additions that are introduced in order to meet 
non-conceptual requirements.

Assaf

> Cheers,
>
> Jean-Jacques
> tel: 425-649-6584
> Cell: 508-333-7634
>
> -----Original Message-----
> From: Assaf Arkin [mailto:arkin@intalio.com]
> Sent: Wednesday, December 03, 2003 11:07 AM
> To: Jean-Jacques Dubray
> Cc: Steve Ross-Talbot; public-ws-chor@w3.org
> Subject: Re: Why workflow is NOT just a Pi-process
>
> Jean-Jacques Dubray wrote:
>
> > If you wanted to model an ERP, I contend that the level of nesting
> > (i.e. all the composed processes from user to DB would be impractical
> > to manage). Except for Intalio which took a very pure approach to
> > implementing pi, everyone is using pi with one or two levels of
> > composition (nesting). Which I think is the wise approach.
> >
> Is that a technical argument regarding Intalio's architecture and 
> product capabilities, or an attempt to portray Intalio in a negative 
> light?
>
> I'm happy to dispute that statement on a technical basis and even 
> demonstrate its fallacy. But in the meanwhile, I do cordially request 
> that if you have a personal agenda against Intalio please, for the 
> sake of all other members, consider taking it off the public mailing list.
>
> > Hence other efforts to carve these boundaries, such as BPELa or
> > ws-cdl, and the comment that choreographies are complementary. I go
> > even further in my last email, there is a duality between choreography
> > and orchestration, as proven by the fact that BPML 0.4 (an
> > orchestration specification) was repurposed with little change in a
> > choreography specification (WSCI).
>
> I've said that two years ago and used an early version of BPML (0.4) 
> to illustrate that point by example. At that time my argument was 
> rejected.
>
> I am glad to learn that we finally see eye to eye on this. Perhaps, 
> moving forward we could see eye to eye on more subjects. It will 
> definitely help advance the level of this discussion.
>
> > Steve, you might understand a bit my fustration, after 5 years, of
> > attempting to contribute to defining a business process models at
> > BPSS, BPML and WS-CHOR, I very sadly see that we are going pretty much
> > nowhere, completely ignoring the basics of what we are doing. I was at
> > a meeting in Paris last week, where one strong BPMI player was
> > responding to my comment that I could not understand why after 4 years
> > of efforts we still did not have a business process standard that had
> > the concept of a "user" and "organization" like WfMC had in 1995. His
> > response was "errare humanum est" and that was being fixed. How is it
> > possible that someone designing a "Business Process" specification
> > forgets about the "user" like BPML and now BPEL? Well it is possible,
> > once you take an approach like Howard is taking. Sadly, it is only a
> > few individuals that decide what approach to take, in one of the most
> > undemocratic way.
> >
> Since we don't experience any difficulties representing users or 
> allowing the human element to be introduced, and actually take pride 
> in our human interface capabilities, I would say that we present solid 
> evidence that this statement is not entirely accurate.
>
> > So I reiterate my request: why are we spending all this time to create
> > specifications that are vastly incomplete and overlapping. Why can't
> > we all come to a point of discussion where we finally tackle this
> > problem, creating a solid infrastructure foundation (BPEL,ws-cdl,...)
> > on which the "business" semantics (i.e. the sugar) (BPML, ebBP...) can
> > be built? I think answering this question would prove very fruitful.
> >
> This change in strategy is more then welcome, I personally believe and 
> have expressed my clear interest in unification of these specifications.
>
> But we have to acknowlege that considerable time was spent due to the 
> need, which I fail to understand, to reject various ideas and 
> specifications. Once we root out the NIH thinking, I believe we will 
> find it much easier to get our work done in a collaborative fashion.
>
> arkin
>
>
> > Ciao,
> >
> > Jean-Jacques
> > tel: 425-649-6584
> > Cell: 508-333-7634
> >
> > -----Original Message-----
> > From: Steve Ross-Talbot [mailto:steve@enigmatec.net]
> > Sent: Wednesday, December 03, 2003 1:33 AM
> > To: Jean-Jacques Dubray
> > Cc: Greg Meredith; public-ws-chor@w3.org; 'Haugen Robert'
> > Subject: Re: Why workflow is NOT just a Pi-process
> >
> >
> > I really don't think that this debate is going anywhere.
> >
> > I could say that everything can be represented as assembler but does
> > that help me in any way?
> > I could say that everything can be modeled in logic but does that help?
> >
> > Alas saying that workflow is just a pi-process is not helpful.
> >
> > The pi-calculus (and higher order forms of process algebra) can be
> > used to model many things, including workflow. After all the
> > pi-calculus is turing complete and has (as Greg Meredith has oft
> >
> > stated) a number of interesting properties that allow us to reason
> > effectively about pi-calculus models.
> >
> > I understand Howard's attraction to a simple unifying model of
> > computation, of which the pi-calculus is a candidate. So Howard is
> > correct in asserting that workflow is a pi-process but it's just not a
> > useful thing to say for most people.
> >
> > On the other hand JJ suggests that you cannot represent workflow as a
> > pi-process because it lacks the higher level semantics (roles etc).
> > Just because it doesn't support them as syntactic sugar doesn't mean
> > that you cannot do so.
> >
> > The fact that the pi-calculus unifies the notion of data and process
> > is not a bad thing. It is a good thing. It has a use in that you can
> > model interaction with data and with classical notions of process
> > using the same underlying model. This in turn allows you to reason
> > about the systems that you model more fully.
> >
> > JJ also suggests that the pi-calculus works well for low levels of
> > nesting. I'm not quite sure I understand what is meant by "levels of
> > nesting". But if this is to include or be equivalent to recursive
> > composition then the pi-calculus is scale invariant with respect to
> > composition. It doesn't change and so is well suited to as many levels
> > as you want to go to. So, unless I misunderstand, the assertion is
> > incorrect.
> >
> > On the other hand JJ's point does beg the question "is it useful to
> > model workflow using the pi-calculus?.
> > To answer this (and I don't intend to at this point) we have to ask
> > another question, namely "what is it we want to know about a workflow
> > that we can only understand by leveraging the pi-calculus?".
> >
> > If the answer is nothing then it is not useful to say "workflow is
> > just a pi-process". If there is something then clearly it is useful to
> > say "workflow is just a pi-process".
> >
> > If it turns out that it is useful then we will be able to understand
> > in what context a workflow should be modeled in this way (is it just
> > the execution platform or the language that described the workflow?).
> >
> > Perhaps better minds that mine could provide a single paragraph on why
> > the pi-calculus is useful in this regard.
> >
> > Cheers
> >
> > Steve T
> >
> >
> >
> > On 3 Dec 2003, at 02:16, Jean-Jacques Dubray wrote:
> >
> > > We may also want to keep Phil Wainewright in the loop, he is keeping
> > > track of the debate and already wrote a very good summary:
> > >
> > > http://www.looselycoupled.com/blog/2003_11_23_lc.htm#107015401001130
> > > 58
> > > 8
> > >
> > > This article could also be titled: "why pi does not matter..."
> > >
> > >
> > > 2. I think what we meant to imply by using the title "Workflow is
> > > just a Pi process" is that there is something foundational about the
> > > Pi concepts that allow us to model higher level processes, including
> > > workflow-like processes.
> > > We could have equally written papers with the following
> > > titles:
> > >
> > > ERP is just a Pi process
> > > SCM is just a Pi process
> > > B2B is just a Pi process
> > > Adding Up is just a Pi process
> > > Managing A List is just a Pi process EAI is just a Pi process Data
> > > is just a Pi process etc
> > >
> > > <JJ>I think we should define what "models" means. If it means
> > > express all the semantics of the things listed above as a
> > > pi-process, Intalio's N3 designer tool might be falling a bit short.
> > >
> > > For instance, I understand that a PO business object can be modeled
> > > as a process, actually it will require that all instance variable of
> > > this object be a pi-process itself, not to mention the database in
> > > which it is stored, and so on...
> > >
> > > I am wondering why SAP and PeopleSoft have not yet released a
> > > pi-version of their ERP system?
> > >
> > > </JJ>
> > >
> > > Just to clarify. If you look at some of the swimlane diagrams in the
> > > paper, each swimlane is a BPML process in its own right (the XML
> > > form and notational form being just alternate notations).
> > > <JJ>I think you just touched the fundamental issue I have with pi,
> > > BPML/BPEL and Intalio's product
> > >
> > > As I understand it, Pi and Intalio's product do not allow for role
> > > separation (since a role IS A process). Since everything is a
> > > process, there is no way to introduce the notion of domain of
> > > control or independent role, everything is capable of exchanging
> > > messaging with everything at all levels (that looks pretty evil to
> > > me, though Howard seems to argue that this is great in the
> > > paragraphs below),
> > >
> > > I can easily conceive that choreography is not not needed as long as
> > > you have process composition, but what choreography buys you is
> > > precisely this notion of domain of control that does not seem to
> > > exist in what I have seen so far. Pi works wonders in a wireless
> > > system where the levels of nesting of pi-processes are relatively 
> low.
> > > However, I cannot imagine the disaster for an ERP system or a
> > > workflow where the level of nesting could reach infinity (in 
> computers terms).
> > >
> > > This is precisely because this notion of domain of control does not
> > > exist that BPEL/BPML are going through excruciating pain to create
> > > the concept of an abstract process, to precisely define the
> > > boundaries that do no exist in the theory. As a matter of fact, pi
> > > just by itself, cannot cross company boundaries. I think that this
> > > is what howards says in the next two paragraphs.
> > >
> > > Maybe there is a business opportunity to run Intalio's Process
> > > Virtual Machine in an ASP model, running all pi-processes in the
> > > world. Then the problem will be solved.
> > >
> > > </JJ>
> > >
> > >
> > > The process virtual machine within the BPMS creates end to end
> > > processes out of piecemeal processes at all levels. This is where
> > > the Pi concepts come in, since the interaction between swimlanes is
> > > of course mobile behavior as defined by Milner. We chose email as an
> > > example as it is a recusive process with this characteristic. We
> > > have found similar characteristics with change management processes,
> > > record keeping processes etc. We see no correspondence between these
> > > and typical workflow processes as WFMS have been typically applied
> > > in business.
> > > It feels very different to me in practice.
> > >
> > > I believe that the significance of choreography lies at the heart of
> > > this, which is kind of why a subset of BPMI.org members submitted
> > > WSCI, based on BPML, to this group, as a first step towards
> > > unification. After all, it is WSCI-territory that allows multiple
> > > technologies from existing players (even if they have no intention
> > > to build a BPMS) to be used in conjunction with each other.
> > >
> > > Howard
> >
> > This email is confidential and may be protected by legal privilege. If
> > you are not the intended recipient,  please do not copy or disclose
> > its content but  delete the email and contact the sender immediately.
> > Whilst we run antivirus software on all internet emails we are not
> > liable for any loss or damage. The recipient is advised to run their
> > own antivirus software.
> >
>
>
> -- 
> "Those who can, do; those who can't, make screenshots"
>
> ----------------------------------------------------------------------
> Assaf Arkin                                          arkin@intalio.com
> Intalio Inc.                                           www.intalio.com
> The Business Process Management Company                 (650) 577 4700
>
>
> This message is intended only for the use of the Addressee and
> may contain information that is PRIVILEGED and CONFIDENTIAL.
> If you are not the intended recipient, dissemination of this
> communication is prohibited. If you have received this communication
> in error, please erase all copies of the message and its attachments
> and notify us immediately.
>
>


-- 
"Those who can, do; those who can't, make screenshots"

----------------------------------------------------------------------
Assaf Arkin                                          arkin@intalio.com
Intalio Inc.                                           www.intalio.com
The Business Process Management Company                 (650) 577 4700


This message is intended only for the use of the Addressee and
may contain information that is PRIVILEGED and CONFIDENTIAL.
If you are not the intended recipient, dissemination of this
communication is prohibited. If you have received this communication
in error, please erase all copies of the message and its attachments
and notify us immediately.

Received on Wednesday, 3 December 2003 15:25:03 UTC