Alex Norta, PhD University of Helsinki October 2 nd , 2007

1. Advanced eBusiness-Transactions for Dynamic Inter-Organizational Business Process Collaboration Alex Norta, PhD University of Helsinki October 2nd, 2007

2. Agenda • B2B Collaboration Context • Advanced Transactions before Service-Oriented Computing (SOC) • Characteristics of electronic business transactions (eBT) • Industry Initiatives for eBT • Transaction Frameworks • Conclusion

3. 1. B2B Collaboration Context

4. An eBusiness-Collaboration Concept

5. eSourcing: a Definition • eSourcing is: • matching on an external level • conceptually formulated service consuming and providing processes • that belong to the domains of autonomous organizations • for the formation of an inter-organizationally linked business process • More information online: • http://www.cs.helsinki.fi/u/anorta/research/eSourcing/

6. Tackling Complexity: Three-Level Framework • Conceptual level: • processes are mapped to internal level • Internal level: • legacy systems, WFMS • External level: • stretches across organizational domains • automatic, dynamically forged collaboration • processes projected from conceptual level

7. eSourcing and Control-Flow: an Example Consumer Domain

8. eSourcing and Control-Flow: an Example External Level

9. eSourcing and Control-Flow: an Example Provider Domain

10. Question!!!!! Who still claims that electronic business collaboration can be safeguarded merely with flat ACID transactions?

11. Why care for business transactions? • To ensure the reliability of inter-organizational electronic business collaboration • To facilitate a loose coupling of business processes • To enable highly dynamic establishment of business collaboration • Conclusion • being flatly ACID is not enough • operational business semantics should be reflected • no single conventional transaction model is able to meet all requirements

12. Service-Enabled Electronic Business Collaboration

13. 2. Advanced Transactions before Service-Oriented Computing (SOC) • Two strategies to achieve different structures inside an advanced transaction: • Modularize a complex transaction and nest in hierarchies • e.g., distributed transactions, nested transactions, multilevel transactions, and open nested transactions • Decompose a long-lasting transaction into shorter sub-transactions • e.g., chained transactions, sagas

14. Save points and Check points (1) • Prerequisites of distributed and nested transactions • Save points: • a point in a transaction that can be “rolled back to” • rollback does not affect transaction before rollback • multiple save points may exist within one transaction • Checkpoint: log entry about save point • Complex error recovery in DB applications • error recovery by rolling back to save point • no need to abort entire transaction

15. Distributed and Nested Transactions (1) • Suitable for complex-structured applications • e.g., integration of several DB systems • Distributed transactions integrate geographically bottom-up • global transaction: represented by multi-DB system • local transaction: controlled by local DB management system • Local and global integrity constraints are aligned • If sub-transaction fails, whole transaction is aborted • e.g., two-phase commit protocol (2PC) realized in the X/Open Distributed Transaction Processing (X/Open DTP) software architecture

16. Distributed and Nested Transactions (2) • Nested transactions divide top-down according to functionality • Sub-transactions are composed in hierarchy • each is atomic and may abort independently • only leaves perform DB-operations • Parent-transaction triggers alternative sub-transaction when one fails • Overall transaction may still succeed when sub-transaction fails

17. Distributed and Nested Transactions (3) • Open nested transactions are a variant of nested transactions • also called multilevel transactions • Transaction tree has its levels corresponding to the layers of the underlying system architecture • leaves in different levels are allowed • Pre-commit allows early commit of sub-transaction • semantic undo if root-transaction fails

18. Distributed and Nested Transactions (4)

19. Chained Transactions and Sagas (1) • For decomposing long running transactions • into small sequentially executing sub-transactions • Chained Transaction: • variant of safe-point mechanism • sub-transaction in a chain roughly equals a save-point interval • difference: each sub-transaction is atomic, while each interval is part of atomic transaction • sub-transaction triggers next upon commit • Rollback returns to last committed sub-transaction • atomicity and isolation not guaranteed by whole chain

20. Chained Transactions and Sagas (2) • Saga: based on chain transaction • each sub-transaction has compensating sub-transaction • with exception of last sub-transaction • entire transaction can be undone with compensating sub-transactions • Useful for compensating business processes • semantic rollback of already carried out tasks • applicable for workflow management systems • Also Saga may be interleaved with other transactions • isolation is not guaranteed

21. Chained Transactions and Sagas (3)

22. Challenges of Electronic Business Transactions • ACID properties are too restrictive • entire process fails when one task fails • Statically coupled workflows not suitable • instead flexible, dynamic, loose coupling of systems • Solution is combining several web services in a business process • requires special business-transaction concept • Reasons: • data in the back end of web services can’t be locked over long time • multiple transaction concepts in one business collaboration

23. 3. Characteristics of eBT (1) • eBT: • is automated, complex, long running, with multiple parties • requires commitments that must be negotiated • supports contracts, shipping and logistics, varied payment instruments, exception handling • eBT combines conventional transactions with unconventional features • reflect semantics and behavior of business tasks

24. Characteristics of eBT (2) • eBT has unconventional atomicities: • payment atomicity • basic level of atomicity • payment-atomic protocols affect fund transfer • goods atomicity • are payment atomic and affect exact transfer of goods for money • delivery atomicity • to prove exactly which goods were delivered, are payment and goods-atomic • contract atomicity • eBT is governed by contracts and update accounts

25. Characteristics of eBT (3) • Generic characteristics: • who is involved in the transaction • what is being transacted • the destination of payment and delivery • the transaction time frame • permissible operations • Special purpose characteristics • links to other transactions • receipts and acknowledgments • identification of money transferred outside national boundaries

26. Characteristics of eBT (4) • Advanced characteristics: • the ability to support reversible (compensatible) and repaired (contingency) transactions • the ability to reconcile and link transactions with other transactions • the ability to specify contractual agreements, liabilities and dispute resolution policies • the ability to support secure EDI, e.g., SET <www.setcom.org>, transactions that guarantee integrity of information, confidentiality and non-repudiation • the ability for transactions to be monitored logged and recovered

27. Managing eBT

28. 4. Industry Initiatives for eBT • Three possible standard candidates: • Business Transaction Protocol • Web Services Transaction • WS-Coordination • WS-AtomicTransaction • WS-BusinessActivity • Web Services Composite Application Framework • Web Services Context • Web Services Coordination Framework • Web Services Transaction Management

29. 4a. Business Transaction Protocol (BTP) [1] • BTP for managing B2B transactions over the internet • XML-based but not exclusively for web services • complex, long running, multi-step • Direct communication between transaction manager and backend system • contradicts web-service philosophy of autonomy • leads to security problems

30. Business Transaction Protocol (BTP) [2] • BTP similar to 2PC • first phase: tentative state changes called provisional effect • second phase: either confirmation called final effect or cancellation that is called counter effect • For participants in BTP • called consensus group • business logics to decide whom to commit or to cancel

31. Business Transaction Protocol (BTP) [3] • BTP specifies two transaction types: • atom: either all participants of a consensus group confirm or all are cancelled • cohesion: relaxed atomicity; business rules decide which participant is confirmed or cancelled • Cohesions are long running transaction • participants commit results in confirm sets • confirm sets are atoms

32. 4b. Web-Services Transactions • Consists of: • WS-Coordination (WS-C) • WS-AtomicTransaction (WS-AT) • WS-BusinessActivity (WS-BA) • Differently to BTP, disjoint coordination and transactional framework • Three specifications aim at • reliable and consistent business transactions • with inter-connected web services

33. WS-Coordination (WS-C) [1] • A generic coordination infrastructure for web services • possible to plug in specific coordination protocols • Three services specified for coordination protocol: • activation service • creates new activity coordinator for specific coordination protocol • registration service • responsible for the enrolment of new participants and selection of coordination protocol • coordination service • ensures registered web services are completed with chosen protocol • protocol defines behavior and operations required for activity completion

34. WS-Coordination (WS-C) [2] • A generic coordination infrastructure for web services • possible to plug in specific coordination protocols • Three services specified for coordination protocol: • activation service • creates new activity coordinator for specific coordination protocol • registration service • responsible for the enrolment of new participants and selection of coordination protocol • coordination service • ensures registered web services are completed with chosen protocol • protocol defines behavior and operations required for activity completion, currently WS-AT, WS-BA

35. WS-AtomicTransaction (WS-AT) • Focused on existing transaction systems and protocols with strict ACID requirements • WS-AT is extension to WSDL that allows to • offer application as web services • specify the ACID properties • Requirements for WS-AT participants (2PC) • updates are isolated until committed • single all or nothing decision for participants • any participant can abort the entire system • Problem: high trust required between participants

36. WS-BusinessActivity (WS-BA) [1] • Supports long-running business transactions • provides mechanisms to reach overall agreement • atomic transactions to preserve the autonomy of participating organizations • High-level transaction • drives transaction that spans multiple atomic transactions • handles business transactions • Atomic transactions • handle systems exceptions transparently

37. WS-BusinessActivity (WS-BA) [2] • Two coordination protocols • BusinessAgreementWithParticipantCompletion • all participants driven to same state • BusinessAgreementWithCoordinatorCompletion • coordinator chooses participant to be committed or compensated

38. 4c. Web Services Composite Application Framework (WS-CAF) • Purpose of WS-CAF • develop an inter-operable, easy to use framework for composite web services • WS-CAF comprises several specifications • WS Context (WS-CTX): first level • WS Coordination Framework (WS-CF): second level • WS Transaction Management (WS-TXM): third level

39. Web Services Context (WS-CTX) • Defines a generic context management mechanism for sharing common system data (i.e., context) across multiple web services • different to BTP and WS-Tx • WS-coordination combines context and coordination • BTP combines context, coordination, transaction management

40. Web Services Coordination Framework (WS-CF) • Manages and coordinates multiple web services that are grouped together in one or more activities to perform some task together • WS-CF is more thorough than WS-Coordination • Three main components of WS-CF architecture • coordinator: participant register to receive context and outcome of an activity • participant: offers operations that are executed during coordination sequence processing • coordination service: defines the behaviour for a specific coordination model

41. Web Services Transaction Management (WS-TXM) [1] • Specifies three transaction protocols • employs context information and coordination protocols • ACID transaction • enabling tightly-coupled network-based transactions • for intra-organizational interoperability between systems • Long Running Action (LRA) • one phase protocol (differently to ACID transaction) • Saga-similar compensation of business interactions • supports nesting and recovery mechanisms, e.g., checkpointing

42. Web Services Transaction Management (WS-TXM) [2] • Business Process Transaction Model • integrates different heterogeneous transaction systems • one overall business-to-business transaction • coordinator is overall business-transaction manager • interposition: coordinator used for hiding each domain with own transaction system and protocol • root coordinator: the business transaction manager has subordinate coordinators

43. Comparison of industry standards • A need exists for an open standard • to realize the interoperability both in web services and business areas • integration of existing transaction concepts with WS-CAF ? • BTP lacks integration ability • problem of strong coupling requirement between web services • however, suitable standard candidate when combined with agent technology

44. 5. Transaction Frameworks • Several transaction frameworks are integrated • Conceptual transaction frameworks • ACTA • BTF • Technical transaction frameworks • CORBA Activity Service Framework • J2EE Transaction Framework

45. 5a. ACTA (1) • Unifies existing models to • reason about the concurrency and recovery properties • capture the semantics of complex transactions • Interactions among transactions are expressed in terms of effects of transactions • on other transactions • on objects they access

46. ACTA (2) • Effects of transactions on other transactions • commit dependency describes the relationship of one transaction T1 to another transaction T2 • dependency rule regulates that T1 cannot commit until T2 either commits or aborts • abort-dependency describes the relationship of T1 to T2 • if T2 aborts, T1 should also abort

47. ACTA (3) • Effects of transactions on objects captured by • two object sets • concept of delegation • Every transaction is associated with several other objects • contained in a view set or access set

48. ACTA (4) • Changes to the objects through three forms of delegation • State delegation • ability of delegator transactionto move the objects from its access set to the delegatee transaction’s access set • Status delegation • ability of the delegator to undo the changes on the objects before those objects are moved to the access set of the delegatee • Limited delegation • ability to make the changes to the objects persistent in the view set before adding them to the access set of the delegatee

49. ACTA (5) • Specification of transaction recovery properties • delegation mechanism combined with commit and abort dependencies • ACTA allows for • specification of the structure and behaviour of transactions • reasoning about their concurrency and recovery properties • ASSET transaction model based on ACTA • uses primitives at a programming language level • ’history’, ’delegation’, ’dependency’, ’conflict set’ etc.

50. 5b. Business Transaction Framework (BTF) [1] • Support for contract-driven, inter-organizational business processes • Basic idea of the BTF: • extract and group existing transaction models into an Abstract Transaction Construct (ATC) library • select the required ATCs to compose a transaction hierarchy on demand