Advanced eBusiness-Transactions for Dynamic
Download
1 / 54

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


  • 64 Views
  • 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)

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
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


Agenda
Agenda

  • 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:

    • http://www.cs.helsinki.fi/u/anorta/research/eSourcing/


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





Question
Question!!!!!

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 <www.setcom.org>, 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?


    ad