Co-ordination protocol and BPEL

Mark,  I think there are two parts ...

1) A mechanism to pass context around participants so that they know the 
piece of work is just part of a bigger transaction.
2) A mechanism to terminate this bigger transaction so that each 
participant will know its final outcome.

My understanding is that WS-C covers the first and WS-Tx covers the second.

However, I don't see how this fits naturally into the current BPEL model.

BPEL integration with WS-C
=====================
How do I associate a "scope" with the "context" of the message that I just 
receive ? (especially when the <receive> is in the middle of the BPEL process).

I'd like to see something like the following in BPEL

<process>
     ....
     <sequence>
         .....
         <receive newScope="true" ....>
             <scope>
                 <TerminationHandler> ... </TerminationHandler>
             </scope>
         </receive>
         .....
     </sequence>
</process>


BPEL integration with WS-Tx
======================
I'd like to see something like the following in BPEL

<process>
     ....
     <sequence>
         .....
         <receive newScope="true" ....>
             <scope>
                 <PrepareHandler> ... </PrepareHandler>
                 <CancelHandler> ... </CancelHandler>
                 <CommitHandler> ... </CommitHandler>
                 <CompensationHandler> ... </CompensationHandler>
            </scope>
         </receive>
         .....
     </sequence>
</process>

Thoughts ??

Best regards,
Ricky

At 10:28 AM 5/20/2003 +0100, Mark Little wrote:
> > > 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.