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

Mark Little's message distinguished a "two-phase coordination protocol"
case from a "lightweight correlation" case. I don't believe these are
genuinely different - in implementation, they are just alternative
partitionings of the same work and, in message exchange/protocol terms,
OASIS BTP was specifically designed to do both. (WS-T isn't currently
quite as flexible)

Taking the "correlation" pattern:

> 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

That's exactly the pattern of the BTP "one-shot", where the prepared
signal is piggy-backed on the order placed message. Using a coordination
protocol avoids having to re-invent in the application protocol the
collision, recovery and error cases and allows the implementations on
each side to take advantage of features of the coordination
implementations. Of course, you *can* do it for yourself, (if you're on
this list), you'll probably get it right. But you will find you are
re-specifying and reimplementing something that already exists.

Actually, I'm especially intrigued that Mark doesn't count that as being
"two-phase". There's obviously a double exchange, and it's clear the
service passes through a "doubt phase", where it's waiting on the
leftside to confirm (or presumably, cancel) the order. To me, that's
two-phase - there's a request for work to be performed contingent on a
later yes/no, then the yes/no. Whether there's an explicit prepare
signal, or whether the coordinator could be separated (or, as here, is
integrated on the left-side) are particulars that don't affect the
principal.


Peter

------------------------------------------
Peter Furniss
Chief Scientist, Choreology Ltd

   Cohesions 1.0 (TM)
   Business transaction management software for application coordination

web: http://www.choreology.com
email:  peter.furniss@choreology.com
phone:  +44 20 7670 1679
direct: +44 20 7670 1783
mobile: +44 7951 536168
13 Austin Friars, London EC2N 2JX

> -----Original Message-----
> From: Mark Little [mailto:mark.little@arjuna.com] 
> Sent: 20 May 2003 10:29
> To: Bob Haugen; public-ws-chor@w3.org; Ricky Ho
> Subject: Re: Global view requires transactions (RE: Use Cases )
> 
> 
> 
> > > 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 Thursday, 22 May 2003 08:57:07 UTC