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)

They are different precisely the manner I outlined (though perhaps didn't
give enough text): the latter case does not require a separate coordinator
as its functionality may very well already be built into the business logic.
We are working with companies that do not need a separate coordinator (or
transaction) service whether that is based on BTP or WS-T: they have spent
many years on developing in-house management systems that do this for them
and do it very well (and in the presence of failures).

>
> 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.

I think it is very short-sighted to believe that existing implementations of
workflow systems (as an example) will be changed to use some separate
coordination service, whatever its basis/history. Obviously newly created
applications may very well not want to reinvent the wheel if that wheel is
already out there and works (but it may not be).

The starting point is the context, that is the core. Everything else builds
upon this.

> Actually, I'm especially intrigued that Mark doesn't count that as being
> "two-phase".

You are correct and wrong: firstly this is a two-phase approach; secondly I
did not say it wasn't two-phase in my original email!

> 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.

Again, correct. However, in this case it's two-phase, but there are
situations where it isn't and BTP (since I'm assuming you're pushing that)
isn't appropriate.

Mark.

>
>
> 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 09:12:00 UTC