Re: Why workflow is NOT just a Pi-process

JJ,

I think we are in violent agreement on most things.

Syntactic sugar is certainly very useful. And you are correct in 
suggesting
that syntactic sugar with meaning is just adding semantics. A meta-layer
if you will. I agree. All of which *can* be done using the pi-calculus 
but it
might not be the best approach (see earlier email).

On the observation that we have lost focus on the right things in 
standards land
you are both right and wrong. I think the work that you are doing at 
the higher level
is probably pitched correctly. The work of BPMI, WS-BPEL and WS-CHOR is 
at a
different level (lower in most cases and higher and overlapping in 
others).

Why is this the case? Alas we (the community as a whole) do not have 
the same set
of beliefs and do not have the same set of constraints and do not have 
the same set of
values. They may overlap and much may be common but they are not the 
same.
This is one reason (and probably the most important) as to why we have 
diverse
efforts. It takes time to get such a large community to a point of 
consensus. It certainly
takes vendor support but more importantly it takes user support. Win 
the users and the
vendors will follow.  Easy to say but hard to do.

I hope that you continue the debate and win users over. I certainly 
will continue to do so
and who knows one day we might get to the necessary consensus and 
create the set
of standards that really do meet out vision of distributed systems.

Cheers

Steve T

On 3 Dec 2003, at 10:37, Jean-Jacques Dubray wrote:

> Steve:
>
> I thought I had acknowledged in my email that pi [being turing 
> complete]
> would allow you to model anything, ERP, workflow, ...
>
> However in doing so it assumes that everything is a process, a 
> variable, an
> object, a GUI, a textfield, a user,...
>
> 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.
>
> A much bigger problem of pi is that you cannot efficiently define
> "boundaries" if you start nesting/composing processes like this. If 
> you put
> yourself to the task of modeling a mid-size IT shop. Pi cannot be
> efficiently leveraged to model ERP talking to CRM to SCM, ... It is not
> impossible, rather my point is that pi itself does not provide you 
> with the
> tools to define these boundaries, they are at most a pattern or a 
> discipline
> of using pi. We end up in a rather strange situation, we wanted to use 
> pi,
> because it is a theory that works well for distributed system, but it 
> works
> well as long as you use a single process virtual machine !
>
> 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).
>
> 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.
>
> You might call my approach syntactic sugar, I don't mind, at least I am
> standing on the one that are trying to find a solution to the problem 
> not to
> match a solution to the problem. The syntactic sugar approach does not 
> lead
> to this kind of mistake.
>
> Note that you made a rather ironic lapsus, because precisely pi is 
> syntactic
> and the sugar is semantic.
>
> 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.
>
> 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#10701540100113058
>> 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.

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.

Received on Wednesday, 3 December 2003 06:32:38 UTC