CINCO Collaborative and interoperable computing Alex Norta, PhD University of Helsinki October 2 nd, 2007 Advanced eBusiness-Transactions for Dynamic Inter-Organizational.

CINCOCollaborative and interoperable computing

Alex Norta, PhDUniversity of Helsinki

October 2nd, 2007

Advanced eBusiness-Transactions for Dynamic Inter-Organizational Business Process Collaboration

Agenda

B2B Collaboration Context Advanced Transactions before

Service-Oriented Computing (SOC) Characteristics of electronic business

transactions (eBT) Industry Initiatives for eBT Transaction Frameworks Conclusion

1. B2B Collaboration Context

OEMTier 1

engineering, machine and plant construction

Systems and modules suppliersTier 2

logistics, tooling

Raw materials, standardized parts

Component suppliersTier 3

mould making,IT services

An eBusiness-Collaboration Concept

Con

trol

flow

Dat

a flo

w

Res

ourc

e

Tra

nsac

tion

Service provider

Model

Con

trol

flow

Dat

a flo

w

Res

ourc

e

Tra

nsac

tion

Model

Enact EnactService consumer

Inter-organizational knowledge worker

Inter-organizational knowledge worker

eSourcing

eSourcing: a Definition

eSourcing is:o matching on an external level o conceptually formulated service consuming and

providing processeso that belong to the domains of autonomous

organizationso 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

Conceptual level:o processes are mapped to

internal level

Internal level:o legacy systems, WFMS

External level:o stretches across

organizational domainso automatic, dynamically

forged collaborationo processes projected from

conceptual level

eSourcing and Control-Flow: an Example

Con

cept

ual L

evel

in out

in: motor-pump specification

out: motor-pumpstatus

assemble motor pump

S RTi o

consumer sphere

In-house process(RT)(ST)

ocsics

Inte

rnal

Lev

eltruck-production web service

map

pm

m m

in out

in: motor-pump specification

out: motor-pumpstatus

assemble motor pump

S RT

consumer contractual sphereiccs

occs

project

Ext

erna

l Lev

el

Consum

er Dom

ain

eSourcing and Control-Flow: an ExampleE

xternal LevelE

xter

nal L

evel

in

out

in: motor-pump specification

out: motor-pumpstatus

assemble motor pump

S RT

consumer contractual sphereiccs

occs

project

in

out

in: motor-pump specification

out: motor-pumpstatus

assemble motor pump

S RT

provider contractual sphere

opcsipcs

project

p

m m m

eSourcing and Control-Flow: an ExampleP

rovider Dom

ain

forward motor pump

assemble motor pump

RT

Con

cept

ual L

evel

in out S

producemotor

in: motor-pump specification

out: motor-pumpstatus

producepump

provider sphere

ips

ops

map

Inte

rnal

Lev

el

motor-pump web service

Ext

erna

l Lev

el

in

out

in: motor-pump specification

out: motor-pumpstatus

assemble motor pump

S RT

provider contractual sphere

opcsipcs

project pm

m m

Question!!!!!

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

ACID 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

o being flatly ACID is not enough

o operational business semantics should be reflected

o no single conventional transaction model is able to meet all requirements

Service-Enabled Electronic Business Collaboration

HTTPXML

SOAP

e-Business Transactions

Orchestration, e.g., BPEL, BPMN, WSFL, RosettaNet, XLANG

WSDL

WS

-Agr

eem

ent

WS

-Sec

urity

UD

DI

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

o e.g., distributed transactions, nested transactions, multilevel transactions, and open nested transactions

Decompose a long-lasting transaction into shorter sub-transactions

o e.g., chained transactions, sagas

Save points and Check points (1)

Prerequisites of distributed and nested transactions

Save points:o a point in a transaction that can be “rolled back to”

o rollback does not affect transaction before rollback

o multiple save points may exist within one transaction

Checkpoint: log entry about save point

Complex error recovery in DB applicationso error recovery by rolling back to save point

o no need to abort entire transaction

Distributed and Nested Transactions (1)

Suitable for complex-structured applicationso e.g., integration of several DB systems

Distributed transactions integrate geographically bottom-up

o global transaction: represented by multi-DB system

o local transaction: controlled by local DB management system

Local and global integrity constraints are aligned

If sub-transaction fails, whole transaction is abortedo 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)

Nested transactions divide top-down according to functionality

Sub-transactions are composed in hierarchyo each is atomic and may abort independently

o 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)

Open nested transactions are a variant of nested transactions

o also called multilevel transactions Transaction tree has its levels corresponding to

the layers of the underlying system architecture

o leaves in different levels are allowed

Pre-commit allows early commit of sub-transactiono semantic undo if root-transaction fails

Distributed and Nested Transactions (4)

Chained Transactions and Sagas (1)

For decomposing long running transactions o into small sequentially executing sub-transactions

Chained Transaction:o variant of safe-point mechanism

o sub-transaction in a chain roughly equals a save-point interval

o difference: each sub-transaction is atomic, while each interval is part of atomic transaction

o sub-transaction triggers next upon commit

Rollback returns to last committed sub-transactiono atomicity and isolation not guaranteed by whole chain

Chained Transactions and Sagas (2)

Saga: based on chain transactiono each sub-transaction has compensating sub-transaction

o with exception of last sub-transaction

o entire transaction can be undone with compensating sub-transactions

Useful for compensating business processeso semantic rollback of already carried out tasks

o applicable for workflow management systems

Also Saga may be interleaved with other transactionso isolation is not guaranteed

Chained Transactions and Sagas (3)

Challenges of Electronic Business Transactions

ACID properties are too restrictiveo entire process fails when one task fails

Statically coupled workflows not suitableo instead flexible, dynamic, loose coupling of systems

Solution is combining several web services in a business process

o requires special business-transaction concept

Reasons:o data in the back end of web services can’t be locked over

long time

o multiple transaction concepts in one business collaboration

3. Characteristics of eBT (1)

eBT: o is automated, complex, long running, with multiple parties

o requires commitments that must be negotiated

o supports contracts, shipping and logistics, varied payment instruments, exception handling

eBT combines conventional transactions with unconventional features

o reflect semantics and behavior of business tasks

Characteristics of eBT (2)

eBT has unconventional atomicities: o payment atomicity

• basic level of atomicity

• payment-atomic protocols affect fund transfer

o goods atomicity• are payment atomic and affect exact transfer of goods for money

o delivery atomicity• to prove exactly which goods were delivered, are payment and goods-

atomic

o contract atomicity• eBT is governed by contracts and update accounts

Characteristics of eBT (3)

Generic characteristics:o who is involved in the transactiono what is being transactedo the destination of payment and deliveryo the transaction time frameo permissible operations

Special purpose characteristicso links to other transactionso receipts and acknowledgmentso identification of money transferred outside national

boundaries

Characteristics of eBT (4)

Advanced characteristics:o the ability to support reversible (compensatible) and

repaired (contingency) transactionso the ability to reconcile and link transactions with other

transactionso the ability to specify contractual agreements, liabilities

and dispute resolution policieso the ability to support secure EDI, e.g., SET

<www.setcom.org>, transactions that guarantee integrity of information, confidentiality and non-repudiation

o the ability for transactions to be monitored logged and recovered

Managing eBT

Pre Transaction

Phase

Main Transaction

Phase

Post Transaction

Phase

timeeBT with phases

EXTERNAL LEVEL - eBC

Pre Transaction

Phase

Main Transaction

Phase

Post Transaction

Phase

time

CONCEPTUAL LEVEL

eBT with phases

Pre Transaction

Phase

Main Transaction

Phase

Post Transaction

Phase

time

CONCEPTUAL LEVEL

eBT with phases

Service Consumer

coordinate coordinate

Service Provider

ServersInformation Systems

Data

INTERNAL LEVEL

Data

coordinate

ServersInformation Systems

Data

INTERNAL LEVEL

Data

coordinate

4. Industry Initiatives for eBT

Three possible standard candidates:

1. Business Transaction Protocol

2. Web Services Transaction• WS-Coordination

• WS-AtomicTransaction

• WS-BusinessActivity

3. Web Services Composite Application Framework• Web Services Context

• Web Services Coordination Framework

• Web Services Transaction Management

4a. Business Transaction Protocol (BTP) [1]

BTP for managing B2B transactions over the interneto XML-based but not exclusively for web services

o complex, long running, multi-step

Direct communication between transaction manager and backend system

o contradicts web-service philosophy of autonomy

o leads to security problems

Business Transaction Protocol (BTP) [2]

BTP similar to 2PCo first phase: tentative state changes called provisional effect

o second phase: either confirmation called final effect or cancellation that is called counter effect

For participants in BTP

o called consensus groupo business logics to decide whom to commit or to cancel

Business Transaction Protocol (BTP) [3]

BTP specifies two transaction types:o atom: either all participants of a consensus group confirm or

all are cancelled

o cohesion: relaxed atomicity; business rules decide which participant is confirmed or cancelled

Cohesions are long running transaction

o participants commit results in confirm sets

o confirm sets are atoms

4b. Web-Services Transactions

Consists of:o WS-Coordination (WS-C)

o WS-AtomicTransaction (WS-AT)

o WS-BusinessActivity (WS-BA)

Differently to BTP, disjoint coordination and transactional framework

Three specifications aim ato reliable and consistent business transactions

o with inter-connected web services

WS-Coordination (WS-C) [1]

A generic coordination infrastructure for web services o possible to plug in specific coordination protocols

Three services specified for coordination protocol:o activation service

• creates new activity coordinator for specific coordination protocol

o registration serviceo responsible for the enrolment of new participants and selection of

coordination protocol

o coordination serviceo ensures registered web services are completed with chosen protocol

o protocol defines behavior and operations required for activity completion

WS-Coordination (WS-C) [2]

A generic coordination infrastructure for web services o possible to plug in specific coordination protocols

Three services specified for coordination protocol:o activation service

• creates new activity coordinator for specific coordination protocol

o registration serviceo responsible for the enrolment of new participants and selection of

coordination protocol

o coordination serviceo ensures registered web services are completed with chosen protocol

o protocol defines behavior and operations required for activity completion, currently WS-AT, WS-BA

WS-AtomicTransaction (WS-AT)

Focused on existing transaction systems and protocols with strict ACID requirements

WS-AT is extension to WSDL that allows too offer application as web services

o specify the ACID properties

Requirements for WS-AT participants (2PC)o updates are isolated until committed

o single all or nothing decision for participants

o any participant can abort the entire system

Problem: high trust required between participants

WS-BusinessActivity (WS-BA) [1]

Supports long-running business transactionso provides mechanisms to reach overall agreement

o atomic transactions to preserve the autonomy of participating organizations

High-level transaction o drives transaction that spans multiple atomic transactions

o handles business transactions

Atomic transactionso handle systems exceptions transparently

WS-BusinessActivity (WS-BA) [2]

Two coordination protocolso BusinessAgreementWithParticipantCompletion

• all participants driven to same state

o BusinessAgreementWithCoordinatorCompletion• coordinator chooses participant to be committed or compensated

4c. Web Services Composite Application Framework (WS-CAF)

Purpose of WS-CAFo develop an inter-operable, easy to use framework for

composite web services

WS-CAF comprises several specificationso WS Context (WS-CTX): first level

o WS Coordination Framework (WS-CF): second level

o WS Transaction Management (WS-TXM): third level

Web Services Context (WS-CTX)

Defines a generic context management mechanism for sharing common system data (i.e., context) across multiple web services

o different to BTP and WS-Tx

WS-coordination combines context and coordination

BTP combines context, coordination, transaction management

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 architectureo coordinator: participant register to receive context and

outcome of an activity

o participant: offers operations that are executed during coordination sequence processing

o coordination service: defines the behaviour for a specific coordination model

Web Services Transaction Management (WS-TXM) [1]

Specifies three transaction protocols o employs context information and coordination protocols

ACID transactiono enabling tightly-coupled network-based transactions

o for intra-organizational interoperability between systems

Long Running Action (LRA)o one phase protocol (differently to ACID transaction)

o Saga-similar compensation of business interactions

o supports nesting and recovery mechanisms, e.g., checkpointing

Web Services Transaction Management (WS-TXM) [2]

Business Process Transaction Modelo integrates different heterogeneous transaction systems

o one overall business-to-business transaction

o coordinator is overall business-transaction manager

o interposition: coordinator used for hiding each domain with own transaction system and protocol

o root coordinator: the business transaction manager has subordinate coordinators

Comparison of industry standards

A need exists for an open standardo to realize the interoperability both in web services and

business areas

o integration of existing transaction concepts with WS-CAF ?

BTP lacks integration ability

o problem of strong coupling requirement between web services

o however, suitable standard candidate when combined with agent technology

5. Transaction Frameworks

Several transaction frameworks are integrated

Conceptual transaction frameworkso ACTA

o BTF

Technical transaction frameworks

o CORBA Activity Service Framework

o J2EE Transaction Framework

5a. ACTA (1)

Unifies existing models to o reason about the concurrency and recovery properties

o capture the semantics of complex transactions

Interactions among transactions are expressed in terms of effects of transactions

o on other transactions

o on objects they access

ACTA (2)

Effects of transactions on other transactionso commit dependency describes the relationship of one

transaction T1 to another transaction T2

o dependency rule regulates that T1 cannot commit until T2 either commits or aborts

o abort-dependency describes the relationship of T1 to T2 • if T2 aborts, T1 should also abort

ACTA (3)

Effects of transactions on objects captured byo two object sets

o concept of delegation

Every transaction is associated with several other objects

o contained in a view set or access set

ACTA (4)

Changes to the objects through three forms of delegation

State delegationo ability of delegator transaction to move the objects from its

access set to the delegatee transaction’s access set

Status delegationo ability of the delegator to undo the changes on the objects

before those objects are moved to the access set of the delegatee

Limited delegationo 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)

Specification of transaction recovery propertieso delegation mechanism combined with commit and abort

dependencies

ACTA allows for o specification of the structure and behaviour of transactions

o reasoning about their concurrency and recovery properties

ASSET transaction model based on ACTAo uses primitives at a programming language level

o ’history’, ’delegation’, ’dependency’, ’conflict set’ etc.

5b. Business Transaction Framework (BTF) [1]

Support for contract-driven, inter-organizational business processes

Basic idea of the BTF:o extract and group existing transaction models into an

Abstract Transaction Construct (ATC) library

o select the required ATCs to compose a transaction hierarchy on demand

Business Transaction Framework (BTF) [2]

Three phases exist along the BTF life-cycle o definition phase

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

o composition phase • constructs of ATC library are used to build a transaction plan for a

complex process within the composition phase

o execution phase

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

Business Transaction Framework (BTF) [3]

Sales Book

Finance

Prep.Docs

SendDocs

SelectCar

Select

SelectHotel

Select Trans.

PaymentInvoice

Calc. Finance

A = Saga with Safepoints ( i.e. C)B = Open Nested with Non CriticalC = Flat (ACID)D = Flat (ACID)E = Flat (ACID)F = X-Transaction (WS based )G = SagaH = Saga

F

A

B

NC

C D E

F

G H

1-a: Booking Process 1-b: Recursive ATC Composition

6. Conclusion

Trend of transaction managemento need for more functionalities and better performance in

distributed, heterogeneous collaboration environment

o dominated by service-oriented computing

Research needs (among many)o exploring the requirements of business transactions in

business process

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

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

CINCOCollaborative and interoperable computing

Thank you for listening!

Questions, comments?