Re: Pi-Calculus Metamodel

I wonder why our experiences in the field are so different?

What I see out there is a lot of demand for reusability. Yesterday you 
have one service for your CORBA application and one for your DCOM 
application, and they both did the same thing but you still needed two 
of them. And now you can have one service and use it in any number of 
applications. So the next logical step is to consider how these services 
can be reused in a variety of business scenarios.

Some of these scenarios may be radically different. Contacting a shipper 
may be applicable for purchase orders, but also for transporting office 
supplies when you relocate, or just moving materials from one facility 
to another. Some of these scenarios are simply evolutions. The order 
placement choreography of tommorow may be better than the one I have 
today, but may end up using the shipper in exactly the same way.

So what you want is the ability to reuse pieces of the choreography in 
multiple contexts. Isn't that why loose coupling is so interesting? So 
how do you loosely couple the service from the choreography? In other 
words, how do you define its participation in potentially any number of 
choreographies?

This is no way means you are going to create choreographies left and 
right. One choreography for addressing purchase orders is often enough. 
But over time you may realize that you can do more business by slightly 
extending that one choreography. So now you have two versions. Can you 
reuse pieces of the old version in the new one? And while odering is one 
thing, you may find use for servicse in other contexts that address 
different business problems. So even as you use abstraction to minimize 
the number of different choreographies in support of the same business 
scenario, you still want to benefit from reuse across scenarions.

The second issue has to do with composition. I have my ERP or MRP or CRM 
or whatever system in place and I'm satisfied with using it. Now I want 
to tie it to other applications out there to create a new kind of 
offerring. Can I just reuse what's already given there to create that 
new offering? An act of importing the capabilities of one system into 
the definition of a larger overall system? Or do I need to create two 
separate systems and then work to bridge the gap?

I see a lot of benefit in the ability to reuse and compose. I agree with 
you in that I can't imagine how services "magically" happen to talk to 
each other by sheer luck. I see a guiding hand in defining these 
choreographies and taking a top-down approach. But I think that guiding 
hand would be much more powerful were it able to reuse artifcats of the 
past in the creation of new choreographies. A model that allows the 
top-down approach to leverage existing artifacts is more appealing in my 
mind.

arkin

Jean-Jacques Dubray wrote:

>I have created a tentative metamodel for pi-calculus, i.e. the kind of
>thing you can express with it.
>
>http://www.ebpml.org/metamodel.htm
>
>I don't claim that this work is completed. I derived it from the
>notation that I found in one presentation on the web. If anyone wants to
>comment or point me to a more complete reference, I'll keep updating the
>metamodel.
>
>AFAIK, what people have in mind for ws-chor is what is labeled a
>ProcessComposition in the metamodel.
>
>See also my comments below.
>
>JJ- 
> 
> 
>  
>
>>>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.
>
>
>[JJ] I do not claim that pi-calc is useless (after all I established the
>connection between pi-calc and BPSS in 2000 while the pi-calc camp (BPML
>and BPEL) came to realize the importance of choreographies/collaboration
>in 2002), I am just wondering if by adopting it as a metamodel we are
>not creating many difficulties for the people that will use and consume
>ws-chor, compared to the benefits that a few will gain. After all is
>bi-simulation that necessary for most classes of applications of
>ws-chor? As we talked about it many many times, the scenarios in which
>web services interact with each other and that are designed in complete
>isolation of each other and ultimately are brought to work together look
>pretty rare to me. Now I don't rule out a tool vendor offering
>bi-simulation services to qualify implementation (interoperability), but
>shall we design the whole thing just because of this requirement?
>
>As I said I am a strong believer of metadata driven software (being in
>the enterprise software business, anything else would be surprising).
>But I also know that specifying the right metamodel is key to its
>usability and adoption. I do not claim that BPSS metamodel is the one we
>should adopt. Again one design a metamodel based on requirements, there
>is no absolute metamodel. ebXML has come up with an architecture which
>is different from WS-Arch so I don't expect that WS-chor will be the
>same as BPSS. ebXML scope is narrow (b2b), I believe that ws scope is
>broader.
>
>
>
>  
>


-- 
"Those who can, do; those who can't, make screenshots"

----------------------------------------------------------------------
Assaf Arkin                                          arkin@intalio.com
Intalio Inc.                                           www.intalio.com
The Business Process Management Company                 (650) 577 4700


This message is intended only for the use of the Addressee and
may contain information that is PRIVILEGED and CONFIDENTIAL.
If you are not the intended recipient, dissemination of this
communication is prohibited. If you have received this communication
in error, please erase all copies of the message and its attachments
and notify us immediately.

Received on Wednesday, 16 April 2003 16:38:45 UTC