Re: Convergence of Standards - Fun - Phase 2 Was: Why workflow is NOT just a Pi-process

Howard,

A good unifying post.  Thanks for that.  Just one immediate followup:

> Again, I recommend we focus on BPML and the evolution of BPEL towards 
> BPML, rather than
> this Pi C debate. I have certainly encountered no problems using BPMS 
> that arise from these comments
> about Pi C.

I agree with the focus on defining processes at an appropriate level of 
abstraction.  We must be careful, however, not to build-in the 
assumption that processes are executed or controlled by a central 
broker.  In terms of execution/operational semantics, this is the big 
jump that must be made when moving from a single-organisation 
process/workflow management environment (where a central broker is 
practical and appropriate) to an environment for processes than span 
autonomous and physically distributed organisations (where a central 
broker is often neither practical nor appropriate).  The issues we're 
raising with respect to Pi calculus semantics are related to the latter 
type of process when there is no central broker.  I would be interested 
to know if you have attempted to implement/use BPMS without a central 
broker.

Ciao,

AndyB

On 03/12/2003, at 10:56 PM, Howard N Smith wrote:

>
> Guys,
>
> I would like to respond to the thread of messages that my 
> "workflow/pi" paper
> has created at wschor. It's difficult to respond, because most of 
> reaction is to the title
> of the paper, and not the substance. Along the way, I'd like to say 
> some things
> about Phase 2 of BPMI.org.
>
> Let's get some things straight:
>
> 1. The paper was written to get the attention of the workflow 
> community.
> It succeeded. For months and months we had been discussing joint work
> between the BPMI and WFMC and getting nowhere. In addition, and before
> that, WFMC had said BPML could not model workflow. So, I found Wil's
> pattern work and asked BPMI members to show how to model it. We did
> that first on pieces of paper, then asked Wil to do some, and when that
> went wrong, we did it ourselves, using a practical BPML tool, and even
> built executable versions of the patterns, and elements of a workflow 
> engine
> implemented only in BPML.  It was to update people on this work that
> we wrote the paper. The work exists, whether people like it or not.
> We believe BPML can do the same for many other types of processes.
> Indeed, CSC is delivering operational systems based on this technology,
> today.
>
> 2. The title of the paper was intended to get a reaction. Papers are 
> not
> read unless they are moderately controversial.
>
> 3. Pi Calculus was an inspiration for the development of BPML.
> The focus of the work to model workflow patterns in the paper was
> on BPML, not Pi-C.
>
> JJ said:
>
>> 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)
>
> It is possible to approximate to domains of control in BPML dependent 
> on how the model
> is modelled. However, there is no doubt that more work is required on 
> domains of control,
> and I suspect this will be part of BPMI Phase 2 activities. At 
> present, CSC has not encountered
> serious barriers from this point in practical projects however. 
> BPMI.org is a very practical
> group, not developing standards in isolation, but implementations in 
> parallel. While we are
> not unique in that, we are focussed upon it. Thus, untill clear 
> requirements emerge from
> project work we wont put effort into standards on that basis.
>
> JJ said:
>> 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.
>
> I'm not sure what you are implying here JJ. Choregraphy is inherent to 
> BPMS, at every boundary
> of every swimlane.
>
> AB said:
>> The key problem with pi calculus is that its operational semantics 
>> assumes a global namespace
>> and arbitrary synchronisation on names shared by processes. While you 
>> can create a modelling
>> layer above this that uses conventions to provide partitioned 
>> namespaces (e.g. ensuring that names
>> are not shared by distributed processes), any semantic analysis of 
>> such models you make based
>> on the pi operational semantics is potentially invalid.
>
> Again, I recommend we focus on BPML and the evolution of BPEL towards 
> BPML, rather than
> this Pi C debate. I have certainly encountered no problems using BPMS 
> that arise from these comments
> about Pi C.
>
> SRT said:
>> 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.
>
> I think the point is Steve that BPMS requires a formality. The one I 
> am using has a formality, inspired
> by the Pi C. I think the BPMS vendors need to keep focussed on 
> formality because otherwise they
> are dragged into arbitrary schema/tag debates. But really, I dont talk 
> to customers much about Pi C.
> I just demonstrate the power of a BPMS to solve their problems.
>
> SRT said:
>> On the other hand JJ's point does beg the question "is it useful to 
>> model workflow using the pi-calculus?.
>
> Of course it is not useful. But it is useful to use a single process 
> language, BPML or BPEL, to build
> a run time capable of executing models of various things, including 
> workflow, ERP etc, and for those
> to be choregraphy together to create end to end processes, even to 
> include email-like collaborations
> as part of end to end transactional processes. Its what BPMS is for.
>
> JJ said:
>
>> 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.
>
> I want you to take this seriously JJ. I think you have an immense 
> grasp on this subject and have made
> a great contribution. But I'm not sure why you are frustrated. 
> Firstly, in your own slide set you acknowledge
> BPML is your preferred standard, and indeed, made a contribution to 
> the BPML 0.4 effort. And BPML
> products exist, and are being used, in practice, for real things, 
> really ....
>
> As to concepts like user and organisation, we don't have high level 
> "business" semantics in BPML
> because they are not needed. They are just processes, and are defined 
> in the model approach
> taken by different organisations. I can assure you that the systems 
> CSC is building using BPMS
> does not forget the user. And I am sure vendors like Intalio ares 
> looking at the enterprise modeling
> tools like Popkin, ARIS, Case, MEGA and developing a meta level of 
> support that leverages an
> enterprise architecture model (Zackman) so that the user and 
> organisational model can be leveraged
> to create skeletal swimlane models, accelerating development. And CSC 
> are also integrating
> process repository environment like Popkin etc to our BPMS-based 
> architecture.
>
> As for being undemocratic, I am no more in charge of BPML, or BPEL, 
> than you are.
> But I am focussed on using what works, and BPMS is working for me. 
> Much more can
> be done, and all voices are heard (that's the point of OASIS as well) 
> but only those
> vendors that actually implement stuff can have the final say .... and 
> what is not CSC I can assure
> you. I think you have over-stated this democracy thing in the past JJ 
> and I think the time has
> come to drop it. OASIS is presumably taking all views into account. As 
> for BPMI.org, its a
> small core group that is thinking through Phase 2, but you are more 
> than willing to help.
>
> JJ said:
>> 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.
>
> Well, in respect of OASIS, there is no intention to intervene across 
> TCs as I understand it.
> OASIS TCs are able to pursue overlapping, or even conflicting work. 
> That is a matter for OASIS
> leadership team to decide. As for W3C, I think there is a real effort 
> to create coherence across
> the work. As for BPMI.org, we are only focussed on one things, a 
> complete stack of BPM standards
> for BPMS, from wherever useful pieces can be found. As for across the 
> groups, well, there could
> be more coordination. But coordination requires purpose, and your 
> purpose may be different to
> ours, and different to others. For example, not everyone doing BPEL 
> will ever build a BPMS.
> Many BPEL implementations will be extensions to existing products, and 
> quite different from each
> other. We faced this too, at BPMI.org. So, let's just accept an 
> imperfect world and do what we
> can to build a better one. Frankly, BPMI.org has moved on from this 
> execution stuff. Something
> will turn out ok, and BPMS vendors are turning to the next hurdle, 
> which appears to be in the
> area of managing the process data itself.
>
> Standards tend to go from theory, to innovation, to standardisation 
> process. Once in the
> standardisation process, OASIS, a lot of fun is lost. Fun is in 
> innovation. You have innovated,
> I have innovated. Let the standards thing play out, and let's move on 
> to the next fun. BUT ...
> let's keep customers along the way, so that the fun helps them. This 
> is BPMI.org philosphy
> and you'll probably see that formalised for Phase 2 if we can get our 
> act together. I hope
> you, and others, will join us for the Phase 2 fun.
>
> Best,
>
> Howard
>

Received on Wednesday, 3 December 2003 09:31:19 UTC