Re: Terminology - What is a process? Was: Internal processes an d/or external choreographies (was RE: Ev ents and States ...

>
>
>  
> What the PI CALCULUS approach has going for it is a sound theoretical 
> base. What it does not have is an easily visible message flow in the 
> definition, which is at the heart of choreography design. Instead you 
> have to infer the message flow by matching up the sends and receives 
> over the same channels.
>
> What the EVENT DRIVEN approach has going for it, is that it mirrors 
> what you actually do since just about everything, sending a message, 
> processing a message, handling timeouts can be described as an event. 
> What it hasn't got (I believe) is a sound theoretical base that would 
> allow one to prove tha correctness and completeness of a design.
>
> What the MESSAGE FLOW/STATE TRANSITION approach has going for it is 
> that it is much closer to the message/work flow models that business 
> analysts use to define a choreography. I don't believe that many 
> business analysts tend to think in a co-operating process stytle that 
> is required for PI Calculus. On the other, hand, there could be issues 
> around how you compose one message flow out of another with this approach.
>
Here is the interesting things. All of these definitions can be analyzed 
using pi-calculus. If you decided to use pi-calculus as the formal model 
for analysis that these definitions are all equal in the sense that you 
can reduce them to the formal model and use that formal model to analyze 
them.

You can start with a collaboration definition given in say BPSS. That 
can easily be represented using pi-calculus. JJ says that he cannot see 
the collaboration in P = Q | R, but pi-calculus can definitely see the 
concurrent interacting processes in a BPSS definition by transforming it 
into the P = Q | R notation. You can then use pi-calculus and other 
works in that area to draw interesting things about your BPSS definition.

The lesson to be learned from pi-calculus is not that you need one 
particular language to use it. It is that you can subject more things to 
that type of formalism. You can subject BPSS to that type of formalism, 
just as well as you can subject WSCI to that type of formalism. You can 
also do that with DAML-S.

The issue I have experience with BPSS is that it places a lot of 
unnatural restrictions on what you can do as it attempts to make 
validation easy. I can see that value in that if people were hand-coding 
XML definitions. Pi-calculus says this is absolutely not necessary. 
There are more interesting things that you can define and more complex 
definitiosn you can create, and if you doubt that they can be validated 
to work, then pi-calculus gives you the right framework to do that.

The language can remain fairly simple, yet gain more semantic and 
expressive power. A lot of the "how do I make this work?" issues that 
may lead you to devise a simpler language go away. You can have the cake 
and eat it too. WSCI is an example for one language that tries to 
capture that richness of semantics and expressive power because we know 
it can be formally analyzed. It simply tries to leverage the model in an 
effort to offer more possibilities to the user.

The message flow/state transition approach is a good one. It has one 
overwhelming advantage: it allows people with less understanding to look 
at a definition and try to understand it in much the same way that 
pi-calculus would do it mathematically. I personally don't believe 
people want to do that - my opinion is that they would rather let the 
software take care of the gory details. If you let the software take 
care of business you don't have to lose capabilities in an effort to 
simplify the language.

The event driven approach is also a good one. It gives you some 
framework for writing definitions that in many cases does not require a 
separate step to validate them. It's kind of obvious it will work. But 
it sacrifices the ability to reuse. If a particular service type can 
take part in multiple choreographies, the nature of this model is that 
you have to define that service type multiple times in each and every 
choreography it is used. You cannot define it's interface once and then 
incorporate it into multiple choreographies (reuse), which means that 
you cannot use that service as the building block for future versions of 
your choreography.

So the questions I would like to raise and then answer are:

1. When it comes time to validate, monitor and otherwise manage the 
choreography, are we expecting that to be done by humans or machine? If 
the answer is humanes, then we have to seriously consider sacrificing 
capabilities in order to simplify the language. We want it to be as 
simple as elementary school arithmetics, or it will neve be used. If the 
answer is machine, then I don't see need to make such a sacrifice.

2. Is reuse important? In some approaches you create a definition and 
then decompose it (e.g. event driven). In other approaches you create 
definitions and then compose them. The ability to compose instead of 
de-compose lends to more reuse and better change management.

WSCI takes a particular stance on depicting choreography - one that is 
not easy to see at first - because it tries to address reuse and maximum 
capabilities. We had the same issue in the early days of OO: it was not 
evident how you could write a COBOL program using OO because OO did not 
have the concept of program start or static records. They added some 
level of complexity in order to increase reuse and allow various forms 
of composition. But eventually we all found that it's not a "big deal". 
We spent some time struggling with OO concepts to understand them, 
learned by trying, but I doubt if at this point we'll want to go back.

> NET, NET ...
> I guess that **my** ideal approach (i.e. it's just my opinion) would 
> be one that combined the theoretical rigor of PI Calculus with the 
> graphical representations you can more easily see with Message Flow - 
> I think that this is what JJ was getting at. Who knows, it might even 
> be possible to map between a PI Calculus and a Message Flow approaches 
> and back ... I don't know.
>
My ideal approach would be a combination of the following:

- A formal model which you can depdent on to give you proof of correctness
- A language that maximizes capabilities and provides solutions to 
interesting problems yet is minimal in its construct - the language does 
not have to be easy
- A graphical representation that is easy to work with, and maybe even 
multiple graphical representations, all of which can be supported by the 
language

I don't think the language should be designed to support one graphical 
model, and I don't think the languages we are talking about limit you in 
the choice of graphical models you can use. If the problem at hand is 
very simple you can use a simple graphical model and express it using 
the language. If the problem at hand is a bit more complex you can find 
ways for the tool to make the graphical model approachable without 
forcing the language to sacrifice any capabilities. And you can always 
use the langauge as a starting point to explore new and more interesting 
graphical models.

I can definitely see people looking at an XML document and saying "I 
just can't see that". I've seen people looking at XML documents and 
failing to see the information in all the clutter of elements and 
attributes. What does ns:shoe="....." has to do with how many shoes I 
want to buy? And why are the line items in the form of a list and not a 
table like the PO print-out? But with a simple XSLT transformation I can 
formulate that information into tables, charts and text that they can 
easily comprehend.

I would not base my a purchase order on a tabular form because it's 
easier to read the XML. I would based the purchase order on a list of 
line items, and then use XSLT to depict it in tabular form. The some 
rational holds here. I would not base the language on a graph of boxes 
and arrows because it's easier to see. I would base it on a model that 
makes sense to capture all the requirements, and then use XSLT (or some 
other mechanism) to represent it to particular people in specific ways 
that make sense for them.

arkin

>  
> What do other folks think?
>
> David
>

Received on Wednesday, 16 April 2003 15:07:34 UTC