- From: Assaf Arkin <arkin@intalio.com>
- Date: Tue, 22 Apr 2003 20:27:34 -0700
- To: "Cummins, Fred A" <fred.cummins@eds.com>
- CC: "Monica J. Martin" <monica.martin@sun.com>, public-ws-chor@w3.org
> > >>I picked this interesting definition from, or all places, pi-calculus: >> >>A process is generally nothing more than a set of commitments. >> >> > >[fac] This seems a bit too simplistic. One could infer that a process >does'nt actually accomplish anything > It's not a full definition, only some sentence that popped out of nowhere. This mention is buried casually in some other topic of discussion, but when I bumped into it accidentally I found it very interesting to mention. We have requirements from the B2B space that talk about legal commitements and fulfilling these commitements, and I just found it very interesting that a very low-level model such as pi-calculus actually acknowledges the same fact. >Some state transitions are better defined as graphs depicting the >possible transitions between a finite set of states. For example from >submitted to approved to pending to shipped. Other state >transitions are >not easily modeled as graphs like that. For example, if I >have a price >for the order and I need to add shipping & handling based on the >destination and weight, the transition is from some number N to some >other number N. Do I write a graph with all possible state >transition s >or are there some transitions not modeled as a graph? Can we identify >more generically these two types of states and transitions? > > > >[fac] I wonder if we couldn't leave this discussion to the definition >of state transition. > Yes. We may at the end decide to talk only about these specific states that you can model as a graph of state transitions, >>WSDL interface defines some of the expected behavior of a >>service type >>and WS-Chor defines other part of that behavior. WSDL can >>also define an >>interface beloning to that type by associating it with the interface. >>However, somewhere along the actual concept of service type >>managed to >>escape and I think we need to introduce it in more generic terms than >>the particular type of WSDL definition used to capture its behavior. >> >> > >[fac] Is your intent to attach some additional semantics to a service >type? If not, what will distinguish one service type from another if not >the WSDL and choreography? > > If you think about it, WSDL is just a type definition language for services. It defines generic types (interfaces) and actual instances of these types (services). I can say that some choreography can use any service that implements interface X, or simply that it can use any service of that type. So service type is just a more generic term and a WSDL interface is just part of the definition of that type. The only need to generalize this concept a bit is by allow different defintions of the service type to exist without naming this particular definitions. arkin
Received on Tuesday, 22 April 2003 23:29:11 UTC