- From: Paul Prescod <paul@prescod.net>
- Date: Fri, 18 Oct 2002 20:15:40 -0700
- To: Ricky Ho <riho@cisco.com>, www-ws-arch@w3.org
Ricky Ho wrote: >... > > Think about how we define network protocol (e.g. TCP, SMTP, HTTP ... > etc.) using a finite state machine. Can the public protocol be just an > XML representation of a state machine. Each state constraint what event > can happen (event can be what SOAP message to send or what SOAP message > to receive). Each event defines the next state. Effectively, we are > defining what are the possible message exchange sequence without > describing the internal decision making process. I think it is smart to define it in terms of a well-known mathematical formalism like a state machine. AND I agree that the private stuff has no business being in the public interface. BUT...there will be circumstances where a particular state change can only happen if a certain set of conditions hold. So you are 100% right that WSCI's if/else is not really necessary for a public specification but "There are two states and you can go to X if condition A and Y if condition B" makes sense. One can imagine the conditions being expressed in terms of XPaths[1]...basically Schemeatron. (To avoid confusing the issue I won't mention that DAML is much more powerful than Schematron for this task because it works at a more appropriate semantic level. Schematron gets across the point.) But of course the only state datums that can be incorporated into these XPaths are those that are addressable. And the way to make things addressable on the Web is to use URIs. Now once you have this language, you can actually represent your states with addressable datums and flatten out your "state machine" into JUST conditions. Now I would call this a "business constraint expression" language rather than a "choreography language" but the result is the same. Let me be concrete. Consider the following choreography task. I won't use any REST techniques even though they make sense for this example. Just RPC-style XML messaging. Here is a sample session: Client asks for a shopping cart: <shopping action="cartRequest"></shopping> Server returns one: <shopping><cart cartid="FHEIOFHEOIFHOFHFS"/></shopping> Client asks for a commitment to deliver a particular item: <shopping action="itemRequest"><cart cartid="FHEIOFHEOIFHOFHFS"/> <itemRequest SKU="HFEIOSHFEOSIHF"/> </shopping> Server returns one: <shopping><cart cartid="FHEIOFHEOIFHOFHFS"/> <item SKU="HFEIOSHFEOSIHF" confirmationID="HFHFOIEHFOSIHF"/> </shopping> Client asks to checkout: <shopping action="checkOut"> <cart cartid="FHEIOFHEOIFHOFHFS"/> <item SKU="HFEIOSHFEOSIHF" confirmationID="HFHFOIEHFOSIHF"/> </shopping> Server: <error><noCustomerNumberAndPassword/><error> Client: <shopping action="checkOut"> <customerNumber num="829374932737492374" password="927492ufi"/> <cart cartid="FHEIOFHEOIFHOFHFS"/> <item SKU="HFEIOSHFEOSIHF" confirmationID="HFHFOIEHFOSIHF"/> </shopping> ==== Business rules: 1. In order to request something, a shopping cart must be created. <rule action="itemRequest" context="/shopping" requirement="/cart/@cartid"/> 2. In order to checkout: * Each item must have an associated confirmation ID * I need at least one item * I need a customerNumber and password Schematron-Choreography Rules: <rule action="checkout" context="/shopping/item" requirement="@confirmationID"/> <rule action="checkout" context="/shopping" requirement="item"/> <rule action="checkout" context="/shopping" requirement="customerNumber/@num and customerNumber/@password"/> Come to think of it, you could do this with WXS, but it would just be uglier... Paul Prescod
Received on Friday, 18 October 2002 23:16:30 UTC