1. Choreology Ltd. www.choreology.com Copyright © 2003, Choreology Ltd Confidential information which must not be reproduced or displayed without permission Proposed changes and additions to BPEL for BTM Peter Furniss Tony Fletcher

2. What is needed Business transaction creation Business transaction propagation (aka infection) Processes as business transaction participants, which can handle positive and negative transaction finalization messages Business transaction termination – two-phase ( promise, decision) exchange Selective termination - selection of participants to be prepared, to be cancelled and to be confirmed.

3. How to handle identity of the transaction Have a variable to hold a business transaction context mark scopes and processes as creating and accepting business transaction context – but the context itself is implicit Business transaction manipulation is a conscious act of the business process

4. Variables to hold context <variable name=”receivedContext” type=”wscoor:CoordinationContext” /> <variable name=”flightTransactionCtx” type=”oasisbtp:context” /> <variable name=”trainTransactionCtx” type=”wscaflra:context” /> <variable name=”hotelTransactionCtx” type=”oasiswsbt:Context” />

5. loading a btContext variable from a received message <receive partnerLink=”customer” portType=”SP:purchasingPT” operation=”purchase” variable=”PO” businessTransactionContext=”receivedContext” >... propertyAlias used to define how to extract value from abstract WSDL message WSDL defines where it really is – which header or other part

6. sending a context with an outbound message <invoke partnerLink=”airline” portType=”AL:bookingPT” operation=”book” inputVariable=”flightRequest” inputBusinessTransactionContext=”flightTransaction Ctx”> … propertyAlias, WSDL used as with inbound message

7. sending a context and receiving back an identification <invoke partnerLink=”hotel_sussex” portType=”HTL:reservationPT” operation=”book” inputVariable=”hotelRequest” inputBusinessTransactionContext=”flightTransaction CTX” outputVariable=”hotelResponse” outputBusinessTransactionParticipant=”hotelAtGatwi ckPI”> … participant Id will be needed later input, output follow pattern for the message variables could be the other way round – BT started by invoked service, returns btContext – extracted to variable using outputBusinessTransactionContext

8. Similar for reply and onMessage <reply partnerLink=”customer”portType=”HTL:reservationPT” operation=”book” variable=”bookingDetails” businessTransactionParticipant=”ourParticipantId”> … No need for input.., output.. here

9. the businessTransaction activity All BT manipulations within a process are done by businessTransaction activity what it does is determined by the action attribute a normal executable activity, appearing sequence, flow etc.

10. starting a business transaction to start a business transaction: the variable myContext can now be used in inputBusinessTransactionContext of invoke,etc. having received a btContext, start a subordinate one, whose decision will obey the parent’s: <businessTransaction action=“new” context=“childContext” parentContext=“receivedContext” />

11. termination Just tell everything registered to cancel Ask the BT to confirm everything will only decide to confirm if all participants promise to obey Faults thrown if the BT cannot confirm when asked to (one or more participants insisted on cancellation) any participant disobeys the decision (breaking their promise)

12. Selective termination use the variables holding the btParticipantIds returned from the registered participants to identify which participants are to be confirmed or cancelled: confirm the desired, let the rest fall by the wayside: <businessTransaction action=“confirm” context=“carTransCtx” participants=“sunroofPI leatherPI maindealPI”/> eliminate the undesired, confirm the survivors: <businessTransaction action=“cancel” context=“travelTranCtx” participants=“taxiPI”/>

13. Forcing a promise and checking the status Selection can be on basis of participant refusal, so must force out promises and check what the answer is <businessTransaction action=”prepare” context=”trainTransaction” participants=”taxiInGlasgow”> <businessTransaction action=”query” context=”trainTransaction” status=”glasgowTaxiStatus” participants=”taxiInGlasgow”> Variable glasgowTaxiStatus now holds the status (prepared/cancelled) of the participant whose ParticipantId is in the variable taxiInGlasgow

14. BPEL participant …. <receive... businessTransactionContext=”theContext ” > … <businessTransaction action=”register” registerWith=”theContext” registeredAs=”myIdentity”>... other processing as needed... <reply... businessTransactionParticipant=”myIden tity”> … Process is the unit Is capable of registering as a participant because of confirmHandler and cancelHandler faultHandler triggered if fault before normal completion normal completion leaves work in provisional state which may be identical either the confirmed or the cancelled state, but can transition to either confirmHandler triggered by bt protocol brings to confirmed state; cancelHandler will not be triggered cancelHandler triggered by bt protocol brings to cancelled state; confirmHandler will not be triggered incoming btContext taken from some message registerWith – the BT identified by the btContext in the variable registeredAs – sets the variable with the unique identifier of the participant return the participantId with the reply

15. BPEL process initiates BT, participants are in invoked WS <reply partnerLink=”customer” portType=”hdcmb:consistentCombinationPT” operation=”orderRequest” variable=”combinationOrderRejected” /> messages in the ws offered by this process messages used in the invoked ws for the nuts messages used in the invoked ws for the bolts holder for the business transaction context fault handler to reply to our invoker if things go wrong

16. BPEL process initiates BT, participants are in invoked WS (2) <receive partnerLink=”customer” portType=”hdcmb:consistentCombinationPT” operation=”orderRequest” variable=”combinationOrderRequest” > <!-- copy values from the received message to the sent messages and the reject message --> <invoke partnerLink=”nutSupplier” p portType=”hdwr:orderingWithTxPT” operation=”order” inputVariable=”nutOrderRequest” inputBusinessTransactionContext=”ourBizTran” outputVariable=”nutOrderReply” > <invoke partnerLink=”boltSupplier” portType=”hdwr:orderingWithTxPT” operation=”order” inputVariable=”boltOrderRequest” inputBusinessTransactionContext=”ourBizTran” outputVariable=”boltOrderReply”> <reply partnerLink=”customer” portType=”hdcmb:consistentCombinationPT” operation=”orderRequest” variable=”combinationOrderAccepted” /> incoming message starts us off forgot to define this one ! start a business transaction details assumed.. propagate the transaction to the BT-aware nut-supplying WS and to the BT-aware bolt-supplying WS request confirmation of the transaction (if it cancels, the faulthandler fires) construct and send our reply

17. Same thing, with marked scopes, not context variables <receive partnerLink=”customer” portType=”hdcmb:consistentCombinationPT” operation=”orderRequest” variable=”combinationOrderRequest” > <!-- copy values from the received message to the sent messages and the reject message --> <invoke partnerLink=”nutSupplier” p portType=”hdwr:orderingWithTxPT” operation=”order” inputVariable=”nutOrderRequest” businessTransactionInfection=“yes” outputVariable=”nutOrderReply” > <invoke partnerLink=”boltSupplier” portType=”hdwr:orderingWithTxPT” operation=”order” inputVariable=”boltOrderRequest” businessTransactionInfection=“yes” outputVariable=”boltOrderReply”> <reply partnerLink=”customer” portType=”hdcmb:consistentCombinationPT” operation=”orderRequest” variable=”combinationOrderAccepted” /> start a business transaction covering this scope propagate the transaction to the BT-aware nut-supplying WS and to the BT-aware bolt-supplying WS (selective termination would need something here) end of marked scope triggers confirmation construct and send our reply

18. BPEL process contains a participant … … copy reservation identification from reservationDetails to reservationConfirmation … <invoke partnerLink=”existingService” … operation=”confirm” inputVariable=”reservationConfirmation” /> process is a BT-aware cover for a BT-naïve WS used as both the incoming message to ourselves as a service, and the outgoing forward work to the underlying service underlying service has app-specific confirm and cancel converts from the general purpose confirm to the application specific

19. BPEL process contains a participant (2) … copy reservation identification from reservationDetails to reservationCancellation … <invoke partnerLink=”existingService” … operation=”cancel” inputVariable=”reservationCancellation” /> <receive partnerLink=”user” portType=”ourSvc:transReservationPT” operation=”makeReservation” variable=”reservationRequest” businessTransactionContext=”transactionContext”> <businessTransaction action=”register” registerWithContext=”transactionContext” registeredAs==”ourParticipant”> <invoke partnerLink=”existingService” operation=”makeReservation” inputVariable=”reservationRequest” outputVariable=”reservationDetails” /> <reply partnerLink=”user” portType=”ourSvc:transReservationPT” operation=”makeReservation” variable=”reservationDetails” businessTransactionParticipantIdentification =” ourParticipant” > convert from general cancel to app-specific the message that starts us off (omitted correlation with initiate=yes) used the received BT identity to register ourselves, enabling the triggering of our confirm and cancel handlers do the non-transactional forward work reply to our user, passing back the answer and our identity as a participant (which it might or might not use)

20. BPEL participant using marked scopes <process name=”transactionalReservation” businessTransactionAware=“yes”… > … … copy reservation identification from reservationDetails to reservationConfirmation … <invoke partnerLink=”existingService” … operation=”confirm” inputVariable=”reservationConfirmation” /> process is declared as BT-aware this could have been simple in the previous case – or perhaps must be compound here

21. BPEL process contains a participant with marked scopes (2) … copy reservation identification from reservationDetails to reservationCancellation … <invoke partnerLink=”existingService” … operation=”cancel” inputVariable=”reservationCancellation” /> <receive partnerLink=”user” portType=”ourSvc:transReservationPT” operation=”makeReservation” variable=”reservationRequest” businessTransaction=”accept”> <invoke partnerLink=”existingService” operation=”makeReservation” inputVariable=”reservationRequest” outputVariable=”reservationDetails” /> <reply partnerLink=”user” portType=”ourSvc:transReservationPT” operation=”makeReservation” variable=”reservationDetails” businessTransactionParticipantIdentification =”ourParticipant” > need to indicate that this message is the one that infects us (commonly or invariably ? will be correlation initiate=“yes” on same receive reply to our user, passing back the answer and our identity as a participant (which it might or might not use) not sure how to set the ParticipantId – implicitly ?