Advanced eBusiness-Transactions for Dynamic
1 / 54

Alex Norta, PhD University of Helsinki October 2 nd , 2007 - PowerPoint PPT Presentation

  • Uploaded on

Advanced eBusiness-Transactions for Dynamic Inter-Organizational Business Process Collaboration. Alex Norta, PhD University of Helsinki October 2 nd , 2007. Agenda. B2B Collaboration Context Advanced Transactions before Service-Oriented Computing (SOC)

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Alex Norta, PhD University of Helsinki October 2 nd , 2007' - wynne-keller

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Advanced eBusiness-Transactions for Dynamic

Inter-Organizational Business Process Collaboration

Alex Norta, PhD

University of Helsinki

October 2nd, 2007


  • B2B Collaboration Context

  • Advanced Transactions before Service-Oriented Computing (SOC)

  • Characteristics of electronic business transactions (eBT)

  • Industry Initiatives for eBT

  • Transaction Frameworks

  • Conclusion

Esourcing a definition
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:


Tackling complexity three level framework
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


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

Why care for business transactions
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

Service enabled electronic business collaboration
Service-Enabled Electronic Business Collaboration

2 advanced transactions before service oriented computing soc
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

Save points and check points 1
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

Distributed and nested transactions 1
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

Distributed and nested transactions 2
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

Distributed and nested transactions 3
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

Chained transactions and sagas 1
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

Chained transactions and sagas 2
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

Challenges of electronic business transactions
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

3 characteristics of ebt 1
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

Characteristics of ebt 2
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

Characteristics of ebt 3
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

  • Characteristics of ebt 4
    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 <>, transactions that guarantee integrity of information, confidentiality and non-repudiation

      • the ability for transactions to be monitored logged and recovered

    4 industry initiatives for ebt
    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

    4a business transaction protocol btp 1
    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

    Business transaction protocol btp 2
    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

    Business transaction protocol btp 3
    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

    4b web services transactions
    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

    Ws coordination ws c 1
    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

    Ws coordination ws c 2
    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

    Ws atomictransaction ws at
    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

    Ws businessactivity ws ba 1
    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

    Ws businessactivity ws ba 2
    WS-BusinessActivity (WS-BA) [2]

    • Two coordination protocols

      • BusinessAgreementWithParticipantCompletion

        • all participants driven to same state

      • BusinessAgreementWithCoordinatorCompletion

        • coordinator chooses participant to be committed or compensated

    4c web services composite application framework ws caf
    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

    Web services context ws ctx
    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

    Web services coordination framework ws cf
    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

    Web services transaction management ws txm 1
    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

    Web services transaction management ws txm 2
    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

    Comparison of industry standards
    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

    5 transaction frameworks
    5. Transaction Frameworks

    • Several transaction frameworks are integrated

    • Conceptual transaction frameworks

      • ACTA

      • BTF

    • Technical transaction frameworks

      • CORBA Activity Service Framework

      • J2EE Transaction Framework

    5a acta 1
    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

    Acta 2
    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

    Acta 3
    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

    Acta 4
    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

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

    5b business transaction framework btf 1
    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

    Business transaction framework btf 2
    Business Transaction Framework (BTF) [2]

    • Three phases exist along the BTF life-cycle

      • definition phase

        • ATCs are abstracted based on a taxonomy of classic transaction models

      • composition phase

        • constructs of ATC library are used to build a transaction plan for a complex process within the composition phase

      • execution phase

        • abstract plans resulting from the composition phase are instantiated to form real business transactions

    6 conclusion
    6. Conclusion

    • Trend of transaction management

      • need for more functionalities and better performance in distributed, heterogeneous collaboration environment

      • dominated by service-oriented computing

    • Research needs (among many)

      • exploring the requirements of business transactions in business process

      • semantics of business collaborations must be clarified, e.g., unconventional atomicities, semantic rollback

      • develop an automated composition of several transaction concepts for a heterogeneous system environment

    Thank you for listening!

    Questions, comments?