RE: New Paper available for PDF download: Workflow is just a Pi process (or WFM is not BPM)

Steve:

This is definitely a useful feature, but I am a bit doubtful about its
applicability of real use cases beyond the trivial ones.

One could argue that if the definition of the choreography is static, you
could find a lot of ways to identify deadlocks. You could also argue that
the fact that a deadlock could be dependent on the content of the message in
a way that is not expressed in the formal model, would greatly reduce the
value of this approach. I would really content that a "SOA debugger" would
have to be smart about a lot of things before that can happen.

I think that we keep jumping from "B" to "W" to "pi" without establishing a
clear and legitimate relationship between them. I don't think anyone is
questioning the validity of pi, but rather its interpretations and its
applicability to solve real business problems. It almost like say that the
value of C# or Java can be derived from  lambda calculus. Well, yes and no,
I am really using Java or C# with respect to lamda calculus based language
because of the libraries that are available to build useful applications. At
the end of the day, I don't care so much if I have a for, foreach, do while,
repeat until, ... I can put up with a lot of shorcomings at this level. This
is the same for "B" or "W" versus "pi". Personally I could not care lest if
petri nets, pi, lambda calculus is the foundation, all I care is that I can
express efficiently what I need to.

If you take the work that is done at the "Business Process" level by Will
van der Aalst, prof. Kumar (with whom I met a couple of weeks ago at Penn
State), or Mike Papazoglou, just to mention a few, you will see that the
major concern in real life scenario is very dynamic situations that might be
able to be decomposed in relatively static parts, but yet, which I think do
not fall under the concept of mobility. Of course I realize that I am hand
waving here, and I apologize, but I have no time to go into the details of
pi theories (I don't see the business case for my job).

We pretty much come to a point where the conclusion is that pi is about
modeling message exchanges and BP or workflow is more than that. As far as I
can tell all the orchestration and choreography standards have failed to
incorporate enough semantics to reach the "B" and "W" levels, and therefore
demonstrate practical applications at this level. It is maybe time that a
massive clarification happens and that the supporters of pi either show what
the "B" and "W" people are missing (like howard has attempted but in a much
grander scale) or show how pi could be efficiently layered below "B" and
"W", or otherwise be done with it.

Cheers,

Jean-Jacques
tel: 425-649-6584
Cell: 508-333-7634

-----Original Message-----
From: Steve Ross-Talbot [mailto:steve@enigmatec.net] 
Sent: Monday, November 17, 2003 9:25 AM
To: Assaf Arkin
Cc: Greg Meredith; Andrew Berry; Howard N Smith; public-ws-chor@w3.org;
W.M.P.v.d.Aalst@tm.tue.nl
Subject: Re: New Paper available for PDF download: Workflow is just a Pi
process (or WFM is not BPM)


Wrt to Greg's "ps" it should be noted that a class of process algebra
(Honda, Yoshida, Kobayashi) lends itself to static analysis which can be
used to show the certain lockfreedom properties. While model checking is
well known and time consuming it may well be the case that using a
behavioural modelling idiom, which process algebra's promote rather well, is
amenable to such checking. What this might give us is the ability to say
that a number of system (i.e. Web services) that conform to some behavioural
contract (i.e. choreography) are free from livelock or deadlock or that they
are not free in some specific way.

This raises an interesting use for those people wishing to embark on a SOA.
They would be able to understand where their systems fail on lock freedom
and take remedial action (timeouts, random time intervals and so on) or
remove the problems.
This in turn would reduce the complexity of testing such systems and
debugging them by orders of magnitude.

I for one have no desire to spend my time finding yet another deadlock or
livelock in my own code, let alone when I connect to other Web Services over
which I have no control. So some form of contractual behavioural description
would be a huge advantage.


Cheers

Steve T


On Monday, November 17, 2003, at 04:52  pm, Assaf Arkin wrote:

>
> Well said.
>
> arkin
>
> Greg Meredith wrote:
>
>> Andrew,
>>
>> You raise important concerns for workflow. i completely agree with 
>> you that a decent account of workflow must address 
>> locality/distribution and partial state. But, i must beg to differ on 
>> your analysis of the pi-calculus with regards to partial state.
>>
>> First, the notion of state must be identified with process in the 
>> pi-calculus. Intuitively, a state is represented by what the process 
>> can do based on what it "knows", i.e. what actions it is willing to 
>> engage in, given what names are in scope. A really good example to 
>> consider is modeling a cell where you can store a value. (See,
>> http://www.lfcs.informatics.ed.ac.uk/reports/91/ECS-LFCS-91-180/ECS-
>> LFCS
>> -91-180.ps, page 35.)
>> Consider a collection, P_i, of processes. Since each process 
>> represents a state, then an aggregate, or partitioned state may be 
>> represented by the parallel composition of the P_i's, P = P_0 | P_1 | 
>> ... | P_N.
>>
>> Notice that in any standard reduction rules for pi-calculus, the rule 
>> for reduction in the parallel composition context will allow these 
>> processes to reduce independently. Thus,
>>
>> P_0 | P_1 | ... | P_N ->* P_0 | ... | P_j' | ... | P_k' | ... | P_N.
>>
>> State change has not happened all at once for all of P. Bit's and 
>> pieces of it have updated, but not the whole thing. You would have to 
>> introduce a protocol, e.g., 2PCPA, amongst the participants of P to 
>> get certain kinds of atomicity and isolation guarantees regarding the 
>> visibility of state change. Fortunately, 2PCPA *is* a protocol and as 
>> such can be well described in pi (see Berger and Honda's paper for a 
>> treatment of this, 
>> ftp://ftp.dcs.qmw.ac.uk/lfp/kohei/express00.ps.gz). Therefore, the 
>> agents providing this protocol can be composed with the agents of P 
>> to give the overall semantics desired.
>> Note that, since this introduces a coding overhead, various 
>> researchers in the process algebra community have added primitives to 
>> the calculus to abstract this coding. This foreshadows a more general 
>> point i want to make that can be illustrated by considering the issue 
>> of modeling locality/distribution.
>>
>> i completely agree that locality and distribution are notions almost 
>> completely lacking in plain vanilla pi-calculus. Unfortunately, i 
>> think that a terrible type/token confusion takes over in these 
>> discussions.
>> It
>> should be plainly obvious that barebones, plain pi-calculus cannot be 
>> used for serious applications like workflow without considerable 
>> enrichment. For example, 1. real workflow applications will describe 
>> message flows branching on numeric computation; the pi-calculus 
>> doesn't have a useable theory of numeric computation; and the 
>> encodings of numbers to be found-- though quite intriguing-- would 
>> simply be too arduous with which to code; 2. real workflow 
>> applications will describe message flows with complex message 
>> structure, e.g. messages with structure like XML documents; neither 
>> monadic nor polyadic pi-calculus is up to this task; 3. real workflow 
>> applications require that there is not a global name manager; plain 
>> vanilla pi-calculus requires that there *is* one; 4. real workflow 
>> applications are probably not going to require a heavy-weight 
>> protocol to ensure-- in a distributed setting-- the summation 
>> semantics the pi-calculus delineates.
>>
>> That said, the pi-calculus provides a *framework* in which to develop 
>> the appropriate formalism. This framework is objectively and 
>> demonstrably different from the other models of computation put 
>> forward.
>> And, it is better suited to the modeling of domains like workflow 
>> than any other model put forward so far. i will return to this point 
>> in a moment.
>>
>> So, as long as we recognize that the pi-calculus is really a stand in 
>> for the class of mobile process algebras, then we are much more 
>> likely to achieve an understanding of how the pi-calculus can 
>> genuinely help model scenarios in the workflow domain. With respect 
>> to distribution and locality, there are several very variations of 
>> the pi-calculus that provide very useful accounts of these notions. 
>> For example, Vasconselos, et al, recently developed lsd-pi which 
>> addresses distribution in a typed setting 
>> (http://www.di.fc.ul.pt/~vv/papers/02-4.pdf). Another approach to 
>> these problems is found in the join-calculus of Fournet 
>> (http://www.cs.unibo.it/~laneve/papers/bisim.ps), et al. Another 
>> approach is found in the work of Wischik, et al, on explicit fusions 
>> (http://www.cs.unibo.it/~laneve/papers/fm-eabs-concur02.ps).
>> Just as you will have to adapt the framework to provide a variant 
>> that deals with complex message structure, you will have to adapt the 
>> framework to provide a variant that deals with distribution. There 
>> are several flavors. Try a few on a few problems and see which one is 
>> better suited. If none are suited, that's wonderful, we have 
>> discovered something!
>>
>> Now, as for the suitability of the framework to this domain, it turns 
>> out that the mobile process algebras are the first model of 
>> computation to simultaneously enjoy four features
>>
>> 1. completeness -- i.e. Turing complete 2. compositionality -- the 
>> model is an algebra, the practical advantage of which is that 
>> large(r) programs are built from small(er) ones 3. concurrency -- the 
>> model has an explicit account of autonomous execution 4. cost -- the 
>> model has an explicit account of resources like time and space
>>
>> Turing machines, for example, fail on features 2 and 3.
>> Lambda calculus fails on 3 and 4.
>> Petri nets fail on 2.
>> CCS, CSP fail on 4.
>>
>> And, of course, each one of these also has the very same issue in 
>> that they are abstractions, frameworks, not ready-made models, and 
>> will have to be adapted to fit the domain. For example, it would be 
>> much too onerous to use Church numerals (ala lambda calculus) to do 
>> the arithmetic calculations on which to make workflow decisions.
>>
>> Noting that the pre-mobile process algebras only lack a notion of 
>> cost, it is most instructive to see how the introduction of mobility 
>> simultaneously provides many important features of both practical and 
>> theoretical import. For example, an account of space consumption of a 
>> program is available in pi (and its variants): count the fresh names 
>> generated by a computation. It is also quite necessary as a practical 
>> feature in workflow. Consider the following scenario.
>>
>> Consumer goes to a well known port of Provider (www.amazon.com) and 
>> emits a message containing a port (consumer@msn.com) at which she 
>> would like to be contacted for further interaction. Provider 
>> processes consumers message, contacts Shipper and emits a messages to 
>> Consumer with, among other things, the port (www.ups.com/tracking) 
>> where Consumer may see the status of her purchase.
>> It is very difficult to model this without mobility. But, this 
>> scenario is all over the place in workflow. It is especially 
>> prevalent in situations involving a broker-- which is one of the most 
>> dominant patterns to be found in the domain.
>>
>> In my brief experience with the domain i have found that the four 
>> features outlined above constitute a bare minimum of requirements of 
>> the computational model necessary to model workflow without imposing 
>> undue labor on the part of the modeler. The mobile process algebras 
>> are objectively, the first models of computation to enjoy these 
>> properties simultaneously.
>> Very likely, now that we have examples of models that enjoy these 
>> properties together we will come up with new and better ones. But, 
>> the only way i know how to do that is to go about the job of modeling 
>> real application scenarios with the best technology available and 
>> seeing where the technology falls short, and then, seeing what it 
>> takes (from minor tweak to paradigm shift) to account for what's 
>> actually happening or needs to happen in the application.
>>
>> Best wishes,
>>
>> L.G. Meredith
>>
>> P.S. There is a coda to this discussion regarding the difference 
>> between modeling workflow and providing *public descriptions* of a 
>> flow. A model may be quite detailed and provide information about 
>> implementation and strategy that a business is not interested in 
>> revealing to its customers or competitors. A public description has 
>> one primary function -- to facilitate search and discovery. Given 
>> this distinction, the language in which public descriptions are 
>> expressed should *not* be complete.
>>
>> Fortunately, in this connection, the mobile process algebras present 
>> another distinguishing characteristic. Over the past decade, a notion 
>> of behavioral typing has emerged and been effected in the mobile 
>> process algebra setting. The languages for these types have exactly 
>> the right properties to be used as the basis for public descriptions 
>> of processes.
>> See my recent paper in the ACM for a more detailed discussion of 
>> these points.
>> (http://portal.acm.org/
>> citation.cfm?id=944217.944236&coll=portal&dl=ACM&
>> idx=J79&part=magazine&WantType=Magazines&title=CACM)
>>
>> -----Original Message-----
>> From: public-ws-chor-request@w3.org
>> [mailto:public-ws-chor-request@w3.org] On Behalf Of Andrew Berry
>> Sent: Monday, November 17, 2003 2:57 AM
>> To: Howard N Smith
>> Cc: public-ws-chor@w3.org; W.M.P.v.d.Aalst@tm.tue.nl
>> Subject: Re: New Paper available for PDF download: Workflow is just a 
>> Pi process (or WFM is not BPM)
>>
>>
>> Howard,
>>
>> You have a fundamental problem with the choice of Pi Calculus: there 
>> is no concept of locality or partial state. In choreography and web 
>> services in general, you can guarantee that participants (processes) 
>> are physically distributed and need to make choices based on a 
>> partial view of state.  To successfully model, program and reason 
>> about these processes, you need to be able to identify and reason 
>> about partial states.
>>
>> Consider your deferred choice semantics.  If the processes identified 
>> as choices are physically distributed, you *cannot* make a choice 
>> without synchronisation of processes because distinct choices can be 
>> made in a truly concurrent fashion.  Pi Calculus has no way of 
>> identifying this issue, let alone reasoning about it.  Explicit 
>> synchronisation processes, while solving the problem for a given 
>> process, require that the programmer reason about distribution and 
>> locality outside the bounds of the Pi Calculus semantics.  I would 
>> therefore argue that a worflow and in particular a choreography is 
>> not a Pi Process.
>>
>> Ciao,
>>
>> AndyB
>>
>>
>> On Wednesday, November 12, 2003, at 03:00  AM, Howard N Smith wrote:
>>
>>
>>> Choreography pioneers,
>>>
>>> Following a short conversation with Steve R-T, he agreed for me to  
>>> send you this paper.
>>> It is intended as a draft for discussion.
>>>
>>> The paper is new information. It shows how, based on BPML, it is  
>>> possible to model all
>>> of the advanced workflow patterns identified by workflow theorists,  
>>> whereas most workflow
>>> engines only support approx 50% of patterns directly and very few of  
>>> the advanced patterns.
>>> In addition, it gives insights into the BPML implementation inherent  
>>> to a BPMS, and how a
>>> BPMS is able to support many process models not supported by  
>>> workflow technology.
>>> Screenshots from Intalio|n3 BPMS are given as examples. Further, the  
>>> workflow engine itself can
>>> be modelled in BPML, as reusable processes for use in end-to-end  
>>> processes. The paper was
>>> written to more fully explain the work of BPMI.org and its direction  
>>> in creating BPMS foundation
>>> technologies.
>>>
>>> Peter Fingar and I have taken great care with this paper, and do  
>>> hope it adds to the
>>> understanding of BPML/BPMI/BPMS direction. While the paper cannot  
>>> present proof of
>>> these claims, you can consider it a report on the work so far.
>>>
>>> The paper can be downloaded from:
>>>
>>> http://www.bpm3.com/picalculus/workflow-is-just-a-pi-process.pdf
>>>
>>> Regards,
>>>
>>> Howard
>>>
>>>
>>> ---
>>>
>>> New Book - Business Process Management: The Third Wave
>>> www.bpm3.com
>>>
>>> Howard Smith/CSC/BPMI.org
>>> cell             +44 7711 594 494 (worldwide)
>>> home office +44 20 8660 1963
>>>
>>>
>
>
>
> 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.