Transaction support is a key ingredient for reliable interorganizational business transactions between distributed, loosely coupled, heterogenous systems. In this paper we present the outline and basic concepts of the Business Transaction Framework research project. In this project we want to develop a exible and integrated framework that supports the structured application of abstract transactional constructs on business transactions. The ultimate goal of the project is the creation of reliable business transactions in the context of service oriented environments.
events that pertain to transactions adhering to that model [
In comparison with the above transactions, business transactions that occur in a business process are quite di erent. Business transactions are complex and multi-level, span many organizations, involve multiple parties with heterogenous systems, usually have a long duration and optional parts and are automatically executed. When developing transaction support for business transactions, these characteristics need to be addressed to ensure a consistent execution of business transactions. Therefore, the business driven business transactions and technology driven data and application level transactions and supporting transaction models must be aligned.
In this paper, we outline the Business Transaction Framework (BTF), which is the core element of our research project. The goal of our research project is the development of concepts, constructs and mechanisms as well as infrastructure to enable exible transactions in the context of e-business. To achieve our research goal we focus on the following points: { Speci cation of the BTF, in particular the required concepts and supporting architecture. { Representation of business semantics in transaction support for business transactions. { Emulation of other existing similar transaction frameworks within the BTF. { Formalization of the above points.
Our focus here is solely on transaction support, we do not for example focus on security aspects as these are out of the scope of the research project.
The interest into business transactions has recently gained momentum as the Service Oriented Computing (SOC) paradigm recognizes the need for business transactions and emphasizes their importance in loosely coupled and dynamic service oriented environments. The BTF is connected to the SOC paradigm in two ways. First, as SOC is the enabler of interoperability between heterogenous systems accompanied with loose coupling and highly dynamic establishment of business relations, we leverage the SOC philosophy to implement the BTF with Web Service technology. Secondly, the BTF extends SOC transaction models to address business driven requirements (intra- and inter-organizational) on automated long running business transactions. Therefore we abstract from concepts (e.g., context), also allowing the integration of related concepts from elds like databases and work ows to achieve an integrated approach in heterogeneous environments.
To present our research project, the remainder of this paper is organized as follows. In Sect. 2, we present the motivation for this research together with an exploration of related work. We point out several issues that are not addressed by current research. In Sect. 3, we present a short overview of the BTF concepts together with a short illustration. The paper ends in Sect. 4 with a summary and an outlook of future work.
In the area of business transaction automation there are a variety of issues, both from a technical and a business perspective, that need to be addressed and that need to be aligned before an automated execution of business transactions and processes with web service technology becomes feasible.
Starting with the technical perspective, it is obvious that a business process with long running business transactions requires a broad support of applicable transaction models to allow a consistent execution. First of all, the (sub) process structure (e.g., nesting, routing, etc) limits the suitable transaction models as transaction models usually support only a particular structure (e.g., the open nested transaction model supports nesting). Also the participants of a business process require particular transaction models as these participants can be heterogenous (e.g., databases, work ow engines or web services) in nature.
Current approaches (e.g., [2{5]) to address these above technical issues
however only use one or a limited combination of transaction models, applicable only
in particular environments (e.g., databases, work ows, web services) in an ad hoc
manner. The focus of these transaction models (e.g., sagas, open nested, etc.) is
on application level transactions and not on business level transactions. Other
research into transaction support for work ows, e.g., [
Several approaches to integrate advanced transaction models exist. The
ACTA framework [
Apart from the incomplete satisfaction of technical issues, business issues are
not addressed by current transaction models and only very limited by current
research. When looking at a business process from a business perspective,
transaction support is required for the complete business protocol that de nes the
public, agreed business interactions between business parties. The interactions
involve negotiations, commitments, contracts, shipping and logistics, tracking,
varied payment instruments and exception handling. In addition to these
concepts, the phase a business process is in as well as the current level of the
business process determine the required transaction support. In [
There is also a need for a more well-founded and formal approach towards the
use of traditional transaction processing concerns of e-business. In [
The BTF currently provides an initial conceptual model that will be brie y presented in this section. Currently, the focus of the framework is on the abstraction and composition of transaction models to address the technical issues as mentioned in Sect. 2. At present, we focus on the transaction support of business transactions from one participants viewpoint (i.e., orchestration oriented), and related to that, their business processes that contain these business transactions.
The conceptual model of the BTF describes and relates the concepts used in the framework. The framework's main concepts are distributed across three distinct phases (i.e., de nition, composition and execution) to address the logical work ow of adding transaction support to business transactions. The need for a broad range of transaction models in a business conversation makes it necessary to de ne a transaction plan. The transaction plan connects di erent transaction models with each other to reliably execute the business process. The transaction models are the building blocks of a transaction plan, which in fact is a composition of transaction models. The de nition of the building blocks is situated in the rst phase of the framework. The second phase is concerned with the composition of transaction models from the rst phase into the transaction plans. To be able to compose transaction models, existing transaction models with their properties and behavior must be analyzed and then it must be investigated what and how transaction models can be connected together and what the semantics of such a connection is. These rst two phases are design-time phases. The compositions of transaction models can then be executed during the nal, run-time (i.e., execution) phase of the framework.
The concept used in the rst phase are the atomic building blocks of the
framework called Abstract Transaction Constructs (ATC). An ATC is an
abstract representation of a transaction model with its speci c properties and
functionality comparable to a transaction model class in object orientation. ATCs
are (if allowed by the particular transaction model) composable horizontally,
allowing to create a choreographed ordering of ATCs, and vertically, allowing to
nest ATCs. The behavior of an ATC is parameterizable through its structural
(i.e., the process structure) and behavioral (i.e., the behavior during run-time)
interfaces. To investigate and achieve interoperability between and reusability of
transaction models we propose a taxonomy of transaction models in which we
initially group existing transaction models by using the abstraction relation into
three categories, i.e., at (e.g., WS-AT [
Injecting transactional capabilities on business processes requires as inputs the business process speci cation, the collection of ATCs, ATC composition rules and contracts constraining the other inputs. When composing the ATCs together by instantiating their structural interface, Abstract Composite Business Transactions (ACBT) are created. An ACBT is a structural transaction speci cation for a business process comparable to a work ow speci cation.
If a business process is started, the accompanying ACBT is instantiated by parameterizing the behaviorial interface of the ATCs connected in the ACBT. The result will be a Composite Business Transaction (CBT) with fully parameterized ATCs called Transactional Constructs (TC). TCs are the concrete transactions executed at some point during the business process.
Booking Issue WS-LRA
WS-AT
Book Pay WS-BA
WS-AT
Fig. 1. ACBT example
In Fig. 1, a small example of an ACBT is presented. This ACBT is based on a simple (part of a) business process in which a travel can be arranged. The travel arrangement process contains one activity (Booking) with two subprocess steps and thereafter one further activity. Within the Booking activity, the subtasks of the Book subprocess (booking a hotel and a ight, both business transactions with other organizations; not shown) can be performed in parallel, after which the selected travel package is invoiced and the payment is registered and the tickets are electronically issued. Based on some process requirements for transaction support, ATCs can be composed into the presented ACBT. The WS-CAF LRA ATC is based on the SAGA transaction model and can be used to split the long-running Booking activity into smaller, shorter-running process steps, using compensation steps in case (part of) the process needs to rollback. A nested ATC (i.e., WS-BA) would suit the Book subprocess. A at transaction model ATC (WS-AT) is used for the payment and issuing of the tickets. If the last activity (Issue) fails, it should be redone until it succeeds (forward recovery). Failing this activity should have no further impact on the rest of the already completed activities. Also, the payment task can be supported by a at transaction model as its compensation is taken care of by the (higher level) WS-LRA.
We explored the requirements for a business aware transaction framework (BTF) in service oriented environments. We introduced the concepts of the BTF to remedy current limitations of transaction support for business processes with business transactions that require an automated and consistent execution with clear semantics (in case of errors) in service oriented environments. Current approaches are not able to provide a platform-independent way of integrating required transaction models accommodating the various activities and their resources (databases, work ows, web services) throughout the business process into a cohesive whole. Representing transaction models by Abstract Transactional Constructs and composing these into Abstract Composite Business Transactions allows the exible creation of reusable transaction plans to support business processes. The execution behavior of ACBTs is parameterizable at run-time in order to create Composite Business Transactions.
Future work for the BTF from a technical viewpoint will concentrate on the precise de nition of the semantics of interactions between the transaction models. This will result in a set of composition rules for ATCs. Formal analysis is required to de ne the correctness criteria of resulting compositions. To support the BTF we are also currently developing a dynamic and exible three-phased and threelevel architecture. Once the technical requirements for the BTF are ful lled, the business requirements will be addressed by incorporating unconventional atomicity criteria into ATCs. Next to the incorporation of existing standardization e orts from the business process arena (e.g., RosettaNet, EbXML), the BTF will make a shift from an orchestration oriented approach to a choreographed approach. We also plan to develop a proof of concept prototype.