RE: Yet Another Choreography Specification

> Hi,
>
> there is another question altogether. 'Plain' web services
> distinguish the interface (WSDL) from implementation (your
> favorite programming language).
>
> Complex web services have the same issue: distinguishing the
> external behavior from the implementation that enforces the
> external behavior.

We're definitely in agreement here.

> The question is if you need a 'full' workflow/process/etc.
> language for the external behavior definition if this distinction
> is made. So I suggest this discussion, too, at least
> concurrently, if not upfront.

From my experience the real issue is scoping of external behavior. Because
external behavior could be very complicated, and some people would argue
that the more you *could* know the better, while others will argue the least
you know the better.

A choreography language as a concept takes a neutral position. He who
defines the choreography decides how much information they want to give, and
how they want to describe it.

Concepts are nice, but we also want deliverable, so the choreography group
has to decide on scope: whether to allow more complex behaviors to be
described subject to the discretion of the choreography author, or to limit
the language to simpler behaviors catering for more the more common use
cases we see today.

That's definitely going to be a loaded issue.

What is not going to help is the fact that we don't all agree on what
external behavior is. What one persons thinks is external behavior, another
person argues is implementation details.


Let me illustrate by an example from a different domain, simplified just to
make the distinction clear.

You can go to your favorite electonics shop and get any number of different
car radios. You can get analog ones, digital ones, with or without DSP, with
tape, CD even DVD, 40W or 200W, radios made by big brands, radios made by
small brands, etc. A lot of implementation options.

Let's agree for a second that the external behavior is common to all of
them, or at least we can find a common external behavior to describe all of
them. We can still argue at length what falls within the scope of external
behavior.

One could say that on/off button, volume control and station selector is all
you need to know. Can even argue that WSDL already does that.

Someone else would point out that you need to turn the radio on before you
could change volume or select a station, so some sequencing rules would
actually capture the external behavior better.

Someone else would point out that you can only select a station if you are
listening to the radio, you can only select a CD if you are listening to a
CD, and you can only play a tape when you are listenting to the tape. So you
also need relation between operations and states to really explain the
external behavior. Which you could also argue is an implementation detail.

Someone else would point out that a radio would not work if there's no
electricity, you will be silent until you connect the speakers, and it will
tend to fall off if you forgot to attach it in place. So you also want to
know the external behavior that interfaces the radio to the car.

I'm sure someone would point out that this is a problem for the installer
and the external behavior doesn't have to cover that. Then someone else
would step in and say, "I select radios based on their mount (not all radios
fit all cars), cross over connectors, antennas (RF or XM) and whether the CD
changer goes in the trunk or fits in the glove compartment".

That's pretty much how I see the "I want to know more" vs "I could care
less" and I think both opinions have their merits, getting to a concensus
might be a touchy issue.

If you want to fully describe the external behavior of a radio as a black
box (allowing multiple implementation), you would need more than just
driver-radio/set-of-dials interface. Whether you care to describe more than
driver-radio interface, or expand on the set-of-dials interface, that's an
open issue.

arkin

>
> Thanks,
>
> Christoph
>
> In a message dated 1/30/2003 5:42:18 PM Eastern Standard Time,
> "Assaf Arkin" <arkin@intalio.com> writes:
>
> >
> >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
> >
> >
>
>
> --
> ------------------------------------------------------
> Christoph Bussler
> ChBussler@aol.com
> hometown.aol.com/ChBussler/
> www.google.com/search?q=bussler
> www.google.com/search?hl=en&q=bussler&btnI=I%27m+Feeling+Lucky
> ------------------------------------------------------

Received on Thursday, 30 January 2003 21:28:51 UTC