W3C home > Mailing lists > Public > public-ws-chor@w3.org > May 2003

Re: Global view requires transactions (RE: Use Cases )

From: Mark Little <mark.little@arjuna.com>
Date: Tue, 20 May 2003 10:28:54 +0100
Message-ID: <018b01c31eb2$3c010e60$850a090a@exhp>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:00:17 GMT