Re: Mobility, pi calculus and Web service Choreography

Monica,

My response is not WS-CDL specific, but rather about requirements of all 
such standards offerings. Though i have not verified it for myself, i 
believe that all of the requirements mentioned below are manifest in some 
form in WS-CDL. Consider the following sort of scenario:

1. You walk up to a well-known channel --
www.amazon.com<http://www.amazon.com>-- and interact with the agency
there (via a web-interface tailored to
humans, aka a browser).
2. During the course of the interaction the agent -- who had potentially 
never interacted with you before -- acquires a channel from you, namely 
monika@dmu.ac.uk, at which it may contact you for further interaction.
3. After your purchase, the agency at www.amazon.com
<http://www.amazon.com>selects an appropriate shipping method and then
sends to the port you
provided in step 2 (monika@dmu.ac.uk) an email containing a channel that is 
created just for the interaction -- the url for tracking your package with 
the shipper.

In this scenario we have several different aspects of mobility.

1. Dynamic communication topology -- the agency reachable through 
www.amazon.com <http://www.amazon.com> did not know either the agency or the 
channel monika@dmu.ac.uk prior to the interaction; and, presumably, forgets 
monika@dmu.ac.uk after the interaction.
2. Dynamic name generation -- the url created for tracking the shipment is 
created on the fly for purpose of tracking the shipment and will ultimately 
be garbage collected on the shipper's side after the acknowledged receipt of 
the goods.
3. Dynamic process generation -- the session with the agency reachable 
through www.amazon.com <http://www.amazon.com> is generated as a result of 
the initial request at www.amazon.com <http://www.amazon.com>. Likewise, 
tracking query sessions are generated from requests at the tracking url.

Notice that there is another important aspect of how these standards must 
handle manipulations of channels. In particular, in calculi like the 
\pi-calculus, names, aka channels, are abstract and uninterpreted. In fact, 
in the \pi-calculus names are atomic and the calculus is parameterized in 
the set of names. In applications of these calculi channels are interpreted 
-- or mapped to -- more physical entities, like urls, email addresses, 
tcp/ip ports or what have you. One must find a way to interpret these that 
addresses a number of different possible concerns.

1. The transport protocols may be at wildly different levels in the network 
stack: consider urls and http versus ip addresses and tcp. One must find a 
way to mediate between these. i do not know how or whether WS-CDL addresses 
this explicity, but it's binding to WSDL was at least originally intended to 
address some of these concerns.
2. The transport protocols may impose very different requirements like: 
request/response, ala http, or 'asynchronous' with best effort delivery, ala 
smtp, or exactly-once-in-order (per session), ala tcp. Again, i do not have 
the details of how or whether WS-CDl addresses this issue explicitly, but 
it's binding to WSDL was -- back in the day -- intended to address some 
these issues.

The issues mentioned above raise one of the most serious challenges in the 
meeting between these kinds of real world applications and the mobile 
process calculi. Though there are many proposals regarding treatment of 
distribution -- as it shows up in the example above -- in the mobile process 
calculi none has emerged as particularly compelling. This is the point where 
i come to the moral of the story: virtually all of the features of the 
\pi-calculus show up in these kinds of real world scenarios -- scenarios you 
and i encounter almost everyday on the web -- but proper treatment of these 
scenarios actually demands a just little bit more than the models have 
heretofore been able to convincingly provide. Standards efforts like WS-CDL 
actually give the process algebra community a really rich field of 
applications against which to (im)prove their abstractions.

Best wishes,

--greg

On 8/30/05, kohei@dcs.qmul.ac.uk <kohei@dcs.qmul.ac.uk> wrote:
> 
> 
> Dear Monica,
> 
> Following Steve's message, here are two relevant scenes where
> "mobility helps".
> 
> (1) As Steve wrote, in some business protocols you do pass
> channels dynamically during communication --- a party may
> not know existence of some channel, but later acquire it
> from another party, and interact through that channel. This
> is the first example where channel passing is important.
> 
> (2) Another, and more subtle, usage is a way to combine actions
> in CDL. This has been somewhat implicit so far (but is going
> to be explicit in the final spec I believe). In essence, when
> you write in CDL there are a sequence of interactions, these
> are assumed to belong to a certain logical unit, not to be
> interfered by another instance of the same or different choreo-
> graphy description. This is most easily represented formally
> as interactions using private channels which is initially passed
> from an invoker to the invoked, used throughout the scenario.
> (This is a logical description, not how you should implement.)
> 
> * * *
> 
> I think (1) is fairly obvious, but (2) is somewhat as important,
> since it underlies CDL even if we do not use channel passing
> explicitly.
> 
> Please let me know if you have further inquiries. As Steven wrote,
> pi4tech site would have good examples.
> 
> Best wishes,
> 
> kohei
> 
> >
> > Hello,
> >
> > I am trying to understand in a bit more detail, how the mobility part in
> > Pi calculus helps Web service composition. Please can someone help me
> > here. I have read a lot of papers that talk about establishing
> > behavioural equivalence between pi calculus and XML-Based languagaes,
> > Incidentally none of them highlighted the importance of mobility.
> >
> > Thanks,
> >
> > Monika
> >
> >
> 
> 
> 
> 


-- 
L.G. Meredith
CTO Djinnisys Corporation
505 N 72nd St
Seattle, WA 98103

+1 206.650.3740