- From: Mark Little <mark.little@arjuna.com>
- Date: Tue, 20 May 2003 10:28:54 +0100
- To: "Bob Haugen" <rhaugen@speakeasy.net>, <public-ws-chor@w3.org>, "Ricky Ho" <riho@cisco.com>
> > I think the "shared state" in this context means "shared visibility" > rather > > than "transactional update". In other words, it is OK to have one > role > > just update its state unilaterally and communicate that result to > relevant > > partners. Of course for certain business-specific process, the state > > change may need co-ordination among partners (e.g. how do I know my PO > has > > been accepted). > > Those are exactly the kinds of state changes I have in mind. > A PO is an offer to buy. Acceptance forms a contract. > State changes to a contract need to be agreed upon > by all parties to the contract. Call it what you will: > transaction, coordination, synchronization, agreement... > it's too common and critical to code adhoc every time. > > Shared visibility would be true for a REST model > where all partners could GET a representation > of the current state of all shared resources. > > Otherwise, all you got is messages over the wire > and maybe an agreed state chart. > > The business transaction models I cited arose > from those situations: contracts between partners, > agreed or standardized state chart, state changes effected > by message exchange in a set pattern. > > They're related to but not the same as private > local transactions. > > I'm not advocating a particular solution in this message. > Just raising the issue. Actually, what you need first and foremost is context to correlate messages. What the messages say ("can you fulfill the order") implicitly requires some form of correlation (in this example, with the aforementioned "order"). Coordination, whether it is done by some stand-alone coordinator technology (e.g., WS-C or BTP) or as a more natural part of the business interactions, utilises that correlation information. What I mean by the latter style of interaction is that, with a correlation id I don't need to have a "coordinator" and related "participants" (things that are coordinated) that are outside of the application; I can keep my application and services and structure the interactions to talk in terms of this correlation id. For example, in a "transactional" interaction with a separate coordinator (whether as a separate service or co-located with the user doesn't matter for this discussion), I'd typically get (assuming a two-phase protocol): application coordinator service participant start tx-------------------> <-------------------------get context place order----------------with context---------> enlist-------------> <----------------------------------------enlist some other work commit tx-----------------> prepare--------------------------------> <------------------------------------OK commit--------------------------------> <------------------------------------OK <--------------------------committed order will be fulfilled whereas if I have a correlation id I may use a more lightweight approach in some situations: application service start business relationship place order--------------correlation id---------> <-----------------------------------------------order placed (can be undone later, with some guarantees) do some other work confirm order-----------correlation id----------> <-----------------------------------------------order confirmed order will be fulfilled In this particular case, how "service" agrees to tentatively place the order and under what constraints is a business level decision and may well be exposed to the application through some bind-time metrics. Now this is not to say that coordination as presented previously isn't required. It is (and with transactions). What I'm trying to illustrate is that all business-to-business interactions don't necessitate a coordinator (or transactions). The context is the fundamental issue (correlation above is just a context). Now, if you think coordination is being done in an ad hoc manner, consider context! As an example, both WS-C and BTP have their own notion of context. At least WS-C doesn't tie it to two-phase as BTP does, so there is a little more leeway in what type of coordination protocol you can implement using WS-C. Mark.
Received on Tuesday, 20 May 2003 05:40:06 UTC