- From: Steve Ross-Talbot <steve@enigmatec.net>
- Date: Fri, 31 Jan 2003 06:54:13 +0000
- To: "Assaf Arkin" <arkin@intalio.com>
- Cc: <bill.flood@sybase.com>, <public-ws-chor@w3.org>, <W.M.P.v.d.Aalst@tm.tue.nl>, <m.dumas@qut.edu.au>, <l.aldred@qut.edu.au>, <a.terhofstede@qut.edu.au>
I have also tracked the use of PetriNets and process algebras. PetriNets tends to be understood on a more intuitive level whereas process algebras are a little more tricky to get a handle on. I think it is pretty important that we level the playing field on formalisms so that people are more comfortable around them (particularly process algebras). I know Assaf has some experience of both pi and join calculus. I could probably get Prof Robin Milner involved so that we can understand more fully the relationship between the requirements that we write down and the expressive power of pi-calculus. I am sure that we would also be able to handle the blend of pi and PetriNets and possibly show that one subsumes the other. On Thursday, January 30, 2003, at 10:42 PM, Assaf Arkin wrote: > > I tend to agree with W.M.P. van der Aalst and the conclusion, though I > would > disagree on the context in which it is presented. > > In our research we have concluded that a modern process language, in > particular one that makes extensive use of messaging, should be based > on > PetriNet and process algebra. While PetriNet is sufficient for modeling > internal activities, it lacks the ability to describe interactions > between > concurrent distributed systems. This is where we see the value of > process > algebra. > > I have used both models to guide me in working on both BPML and WSCI. > That > would answer one of the most commonly asked questions: why does BPML > and > WSCI look different from languages based purely on PertiNets? The > difference > stems from the introduction of process algebra into the underlying > model. > > I would definitely urge the WS Choreography WG to look at models that > combine PetriNet with process algebra and pursue the development of a > specification along these lines. > > arkin > >> -----Original Message----- >> From: public-ws-chor-request@w3.org >> [mailto:public-ws-chor-request@w3.org]On Behalf Of >> bill.flood@sybase.com >> Sent: Tuesday, January 28, 2003 3:54 PM >> To: public-ws-chor@w3.org >> Cc: W.M.P.v.d.Aalst@tm.tue.nl; m.dumas@qut.edu.au; >> l.aldred@qut.edu.au; >> a.terhofstede@qut.edu.au >> Subject: Yet Another Choreography Specification >> >> >> All, >> >> I seriously considered joining this working group but have deferred >> that >> decision to better try to understand the direction that it is taking. >> Examining WSCI, BPEL4WS (XLANG., WSFL), BPML, XPDL, and the host of >> other >> "specifications" or notes does not seem fruitful without some ability >> to >> understand them in context of the entire problem. >> >> What is needed is a neutral justification for defending the >> arrived-upon >> stance. I'm afraid the alternative is that WS-Chor will simply be >> another >> impotent footnote rendered meaningless by the vendors that have their >> favorite specification and the ability to push them forward. After >> all, >> minus a logical argument, why should one vendor endorsed standard >> give way >> for just another unjustified standard? >> >> An excellent article on this subject can be found at: >> >> http://tmitwww.tm.tue.nl/research/patterns/ieeewebflow.pdf >> >> The author is on the CC list and my hat is off to him and his >> colleagues >> for this valuable work. I hope that the vendor community can learn >> from >> their efforts. >> >> This article is really about recognizing the entire range of workflow >> patterns that address more than the subsets presented through vendor >> specific approaches. A markup language has been developed (YAWL) that >> describes these patterns in XML. Researchers have also mapped from >> vendor-specific markups to the patterns. >> >> The WS-Chor, in my belief, will only be successful if it takes the >> high >> road - a defensible position that avoids pitting one vendor approach >> against another (or for that matter one standards organization against >> another). If the WS-Chor can see itself in a position of supporting a >> neutral approach to the choreography issue, the industry as a whole >> will >> benefit and I will be there to support it. >> >> Best Regards, >> >> --Bill Flood, Sybase >> >> Supporting documents in a similar vein can be found at: >> >> http://idevnews.com/CaseStudies.asp?ID=52 >> >> http://www.daimi.au.dk/CPnets/workshop02/cpn/slides/w_aalst.ppt >> >> http://tmitwww.tm.tue.nl/research/patterns/yawl_qut_report_FIT-TR- >> 2002-0 >
Received on Friday, 31 January 2003 01:50:20 UTC