Transcript Slide 1

CINCO
Collaborative and interoperable computing
Advanced eBusiness-Transactions for Dynamic
Inter-Organizational Business Process Collaboration
Alex Norta, PhD
University of Helsinki
October 2nd, 2007
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
Tier 1
Tier 2
Tier 3
OEM
engineering, machine
and plant construction
Systems and
modules suppliers
logistics, tooling
Component suppliers
Raw materials, standardized parts
mould making,
IT services
An eBusiness-Collaboration Concept
Inter-organizational
knowledge worker
Inter-organizational
knowledge worker
Transaction
Resource
Data flow
Control flow
Transaction
Service consumer
Resource
Enact
Data flow
Model
Control flow
eSourcing
Model
Enact
Service provider
eSourcing: a Definition

eSourcing is:
o
o
o
o

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

Conceptual level:
o

Internal level:
o

processes are mapped to
internal level
legacy systems, WFMS
External level:
o
o
o
stretches across
organizational domains
automatic, dynamically
forged collaboration
processes projected from
conceptual level
Internal Level
eSourcing and Control-Flow: an Example
truck-production web service
In-house process
Conceptual Level
(ST)
in: motor-pump
out: motor-pump
specification
status
consumer sphere
ics
in
i
(RT)
assemble
motor pump
RT
m
External Level
m
ocs
m
project
in: motor-pump
consumer
contractual sphere
RT
in
out: motor-pump
p
status
specification
iccs
o
out
S
assemble
motor pump
occs
S
out
Consumer Domain
map
eSourcing and Control-Flow: an Example
project
out: motor-pump
in: motor-pump
status
specification
RT
in
m
m
out: motor-pump
External Level
specification
RT
S
m
in: motor-pump
ipcs
out
assemble
motor pump
p
status
provider
contractual sphere
assemble
motor pump
project
opcs
out
S
External Level
iccs
in
occs
consumer
contractual sphere
eSourcing and Control-Flow: an Example
out: motor-pump
specification
status
provider
contractual sphere
External Level
ipcs
RT
in
m
m
assemble
motor pump
project
S
out
p
m
in: motor-pump
out: motor-pump
specification
status
provider sphere
ips
produce
motor
RT
in
produce
pump
assemble
motor pump
map
Internal Level
opcs
motor-pump web service
ops
forward
motor pump
S
out
Provider Domain
Conceptual Level
in: motor-pump
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
e-Business
Transactions
UDDI
WS-Agreement
WS-Security
Service-Enabled
Electronic Business Collaboration
Orchestration, e.g., BPEL, BPMN,
WSFL, RosettaNet, XLANG
WSDL
SOAP
XML
HTTP
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 subtransactions

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 applications
o
error recovery by rolling back to save point
o
no need to abort entire transaction
Distributed and Nested Transactions (1)
Suitable for complex-structured applications

o
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 aborted
o
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 hierarchy



o
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 subtransaction 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-transaction

o
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
o
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

o
atomicity and isolation not guaranteed by whole chain
Chained Transactions and Sagas (2)
Saga: based on chain transaction

o
each sub-transaction has compensating sub-transaction
o
with exception of last sub-transaction
o
entire transaction can be undone with compensating subtransactions
Useful for compensating business processes

o
semantic rollback of already carried out tasks
o
applicable for workflow management systems
Also Saga may be interleaved with other transactions

o
isolation is not guaranteed
Chained Transactions and Sagas (3)
Challenges of
Electronic Business Transactions
ACID properties are too restrictive

o
entire process fails when one task fails
Statically coupled workflows not suitable

o
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
o
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)
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:

payment atomicity
o
•
basic level of atomicity
•
payment-atomic protocols affect fund transfer
goods atomicity
o
•
are payment atomic and affect exact transfer of goods for money
delivery atomicity
o
•
to prove exactly which goods were delivered, are payment and goodsatomic
contract atomicity
o
•
eBT is governed by contracts and update accounts
Characteristics of eBT (3)

Generic characteristics:
o
o
o
o
o

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
o
o
o
links to other transactions
receipts and acknowledgments
identification of money transferred outside national
boundaries
Characteristics of eBT (4)

Advanced characteristics:
o
o
o
o
o
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 nonrepudiation
the ability for transactions to be monitored logged and
recovered
Managing eBT
EXTERNAL LEVEL - eBC
Post
Transaction
Phase
Main
Transaction
Phase
Pre
Transaction
Phase
time
eBT with phases
coordinate
CONCEPTUAL LEVEL
Pre
Transaction
Phase
Main
Transaction
Phase
CONCEPTUAL LEVEL
Post
Transaction
Phase
eBT with phases
coordinate
Pre
Transaction
Phase
Main
Transaction
Phase
eBT with phases
time
coordinate
time
coordinate
INTERNAL LEVEL
Information Systems
Post
Transaction
Phase
INTERNAL LEVEL
Data
Data
Data
Data
Servers
Service Consumer
Information Systems
Servers
Service Provider
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 internet

o
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 2PC

o
o
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

o
called consensus group
o
business logics to decide whom to commit or to cancel
Business Transaction Protocol (BTP) [3]
BTP specifies two transaction types:

o
o
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

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 at

o
reliable and consistent business transactions
o
with inter-connected web services
WS-Coordination (WS-C) [1]
A generic coordination infrastructure for web services

possible to plug in specific coordination protocols
o
Three services specified for coordination protocol:

activation service
o
•
creates new activity coordinator for specific coordination protocol
registration service
o
o
responsible for the enrolment of new participants and selection of
coordination protocol
coordination service
o
o
o
ensures registered web services are completed with chosen protocol
protocol defines behavior and operations required for activity
completion
WS-Coordination (WS-C) [2]
A generic coordination infrastructure for web services

possible to plug in specific coordination protocols
o
Three services specified for coordination protocol:

activation service
o
•
creates new activity coordinator for specific coordination protocol
registration service
o
o
responsible for the enrolment of new participants and selection of
coordination protocol
coordination service
o
o
o
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)
Focused on existing transaction systems and protocols
with strict ACID requirements

WS-AT is extension to WSDL that allows to

o
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 transactions

o
o
provides mechanisms to reach overall agreement
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 transactions

o
handle systems exceptions transparently
WS-BusinessActivity (WS-BA) [2]
Two coordination protocols

BusinessAgreementWithParticipantCompletion
o
•
all participants driven to same state
BusinessAgreementWithCoordinatorCompletion
o
•
coordinator chooses participant to be committed or compensated
4c. Web Services Composite
Application Framework (WS-CAF)
Purpose of WS-CAF

o
develop an inter-operable, easy to use framework for
composite web services
WS-CAF comprises several specifications

o
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 architecture
o
o
o
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]
Specifies three transaction protocols

o
employs context information and coordination protocols
ACID transaction

o
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 Model

o
integrates different heterogeneous transaction systems
o
one overall business-to-business transaction
o
coordinator is overall business-transaction manager
o
o
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
A need exists for an open standard

o
o
to realize the interoperability both in web services and
business areas
integration of existing transaction concepts with WS-CAF ?
BTP lacks integration ability

o
o
problem of strong coupling requirement between web
services
however, suitable standard candidate when combined with
agent technology
5. Transaction Frameworks

Several transaction frameworks are integrated

Conceptual transaction frameworks
o
ACTA
o
BTF
Technical transaction frameworks

o
CORBA Activity Service Framework
o
J2EE Transaction Framework
5a. ACTA (1)
Unifies existing models to

o
o
reason about the concurrency and recovery properties
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 transactions

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
o
•
if T2 aborts, T1 should also abort
ACTA (3)
Effects of transactions on objects captured by

o
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 delegation
o
ability of delegator transaction to move the objects from its
access set to the delegatee transaction’s access set
Status delegation

o
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

o
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 properties

o
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 ACTA

o
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
o
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]
Three phases exist along the BTF life-cycle

definition phase
o
•
ATCs are abstracted based on a taxonomy of classic transaction
models
composition phase
o
•
constructs of ATC library are used to build a transaction plan for a
complex process within the composition phase
execution phase
o
•
abstract plans resulting from the composition phase are instantiated to
form real business transactions
Business Transaction Framework (BTF) [3]
A
Sales
Select
Select
Hotel
Select
Trans.
Prep.
Docs
Book
Calc.
Send
Docs
B
C
D
Finance
E
F
NC
Select
Car
F
Finance
Invoice
1-a: Booking Process
Payment
A = Saga with Safepoints ( i.e. C)
B = Open Nested with Non Critical
C = Flat (ACID)
D = Flat (ACID)
E = Flat (ACID)
F = X-Transaction (WS based )
G = Saga
H = Saga
G
1-b: Recursive ATC Composition
H
6. Conclusion

Trend of transaction management
o
o

need for more functionalities and better performance in
distributed, heterogeneous collaboration environment
dominated by service-oriented computing
Research needs (among many)
o
o
o
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
CINCO
Collaborative and interoperable computing
Thank you for listening!
Questions, comments?