A model and language for business-aware transactions

(1)

Tilburg University

A model and language for business-aware transactions Kratz, B.

Publication date:

2012

Document Version

Publisher's PDF, also known as Version of record

Link to publication in Tilburg University Research Portal

Citation for published version (APA):

Kratz, B. (2012). A model and language for business-aware transactions. CentER, Center for Economic Research.

General rights

Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. • Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain

• You may freely distribute the URL identifying the publication in the public portal

Take down policy

If you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediately and investigate your claim.

(2)

A MODEL AND LANGUAGE

FOR BUSINESS-AWARE

(3)

(4)

A MODEL AND LANGUAGE

FOR BUSINESS-AWARE

TRANSACTIONS

PROEFSCHRIFT

ter verkrijging van de graad van doctor aan Tilburg University, op gezag van de rector magnificus, prof. dr. Ph. Eijlander, in het openbaar te verdedigen ten overstaan van een door het college voor promoties aangewezen commissie in de

aula van de Universiteit op maandag 26 november 2012 om 16:15 uur

door

Benedikt Kratz

(5)

Promotiecommissie

Promotores: prof. dr. M. P. Papazoglou prof. dr. P. W. P. J. Grefen

prof. dr. W. J. A. M. van den Heuvel

Overige commissieleden: prof. dr. W. Lamersdorf prof. dr. C. Nikolaou prof. dr. P. M. A. Ribbers dr. Y. Taher

This research was financially supported by the Netherlands Organisation for Scientific Research (NWO) in the framework of the XTraConServe (eXecution of Transactional Contracted electronic Services) project, № 612.063.305. This has been a joined research project between the European Research Institute in Service Science (ERISS) at Tilburg University and the Information Systems Group at Eindhoven University of Technology.

The research leading to these results has also received funding from the European Community’s Seventh Framework Programme [FP7/2007-2013] under grant agreement № 215483 (S-Cube, the European Network of Excellence in Software Services and Systems).

SIKS Dissertation Series No. 2012-45 CentER Dissertation Series No. 332

The research reported in this thesis has been carried out under the auspices of SIKS, the Dutch Research School for Information and Knowledge Systems and the CentER Graduate School of the Tilburg School of Economics and Management at Tilburg University.

(6)

Hoe ver je gaat, heeft met afstand niets te maken

Hoogstens met de tijd1

Voor iedereen die veel geduld met mij heeft gehad; Anke in het bijzonder

(7)

(8)

List of Figures

1.1 Dissertation Outline 27

2.1 The Extended Service Oriented Architecture 38

3.1 Overview of the actors and their interrelationships in the

automo-tive case study 50

3.2 High-level BPMN view of the automotive case study 51

3.3 A hierarchical representation of the Business-aware Transaction 53

4.1 Relationship between the BTF, BTM and BTL 64

4.2 The Business-aware Transaction Model 80

5.1 Elements of the Business-aware Transaction Language and their

relationships 84

5.2 An activity represented in BPMN 86

5.3 A sequence element represented in BPMN 88

5.4 A parallel element represented in BPMN 88

5.5 An exclusive choice element represented in BPMN 89

5.6 An inclusive choice element represented in BPMN 90

5.7 Activity States 93

5.8 States of a Business Partner 97

5.9 Flat Fragment States 100

5.10 Scope States 102

5.11 Flexible Fragment States 105

5.12 Business-aware Transaction States 106

6.1 Graphical Representation of a Transition 112

6.2 Activity as Automaton 113

6.3 Sequence Structured Activity as Automaton 113

6.4 Parallel Structured Activity as Automaton 115

6.5 Exclusive Choice Structured Activity as Automaton 116

6.6 Inclusive Choice Structured Activity as Automaton 117

6.7 Sequence to Automaton Algorithm 126

6.8 Parallel to Automaton Algorithm Example 129

7.1 Transactional Behavior in Business-aware Transactions 140

7.2 Meta-Model for Transactional Behavior 142

7.3 Relationship between the control flow automaton and activity

states 145

(13)

7.4 Failure Handling 147

7.5 Handling Violations of Contractual Constraints 150

7.6 Relationship between the control flow automaton and business

partner states 154

7.7 Handling Unilateral Decisions by Business Partners 156

7.8 Retry in Automaton 178

7.9 Alternative Activities 180

8.1 _{Relationships between Uppaal templates representing the BTL} 192

8.2 Excerpt of an Activity with Timing Constraint 193

8.3 Hierarchical representation of the auxiliary system with nested

scopes 196

8.4 _{Screenshot of the Automotive Case Study in the Simulator of}

Up-paal 201

8.5 Screenshot of the command line verification of the Automotive

Case Study 203

8.6 _{Screenshot of the Automotive Case Study in the Verifier of Uppaal} 203

C.1 Uppaal Activity Template XXX

C.2 Uppaal Business Partner Template XXXI

C.3 Uppaal Flat Fragment Template XXXII

C.4 Uppaal Scope Template XXXIII

C.5 Uppaal Flexible Fragment Template XXXIV

C.6 Uppaal Business-aware Transaction Template XXXV

C.7 Uppaal Service and Operation Templates XXXVI

C.8 Uppaal Connector Templates for Control Flow; Start,

Select/-Connect, And Split and Join XXXVI

(14)

List of Tables

1.1 Share of enterprises’ turnover on e-commerce [Eurostat, 2012] 9

2.1 Behavioral characteristics of business-aware transactions, cited

(partly) from [Papazoglou et al., 1998] 43

4.1 Coverage of business-aware transaction requirements by BTM

con-cepts 70

4.2 Mapping BTM concepts to BTL elements 82

7.1 Temporal constraints and their applicable relational operators 148

7.2 Overview of Transactional Properties 160

8.1 _{Uppaal Property Types} 197

8.2 Mapping WS-AT States to Business Partner States 206

8.3 Mapping WS-BA States to Business Partner States 207

8.4 Mapping BTL Instructions to Web Services Transactions 209

(15)

(16)

Listings

3.1 Basic Activity Example 54

3.2 Sequence Activity 55

3.3 Parallel Activity 56

3.4 Example of an Exclusive Choice Activity 56

3.5 Example of an Inclusive Choice Activity 57

3.6 Example of an Inclusive Choice Activity 58

3.7 Mixed Flexible Fragment Example with Close Instructions 58

3.8 Timing Constraints with Forward Recovery and Vitality 60

3.9 Operational Constraint 60

3.10 Business Partner Autonomy Example 61

5.1 Activity Syntax 85

5.2 Sequence Element Syntax 87

5.3 Parallel Element Syntax 87

5.4 Choice Element Syntax 89

5.5 Business Partner Syntax 94

5.6 Contractual Primitives Element Syntax 98

5.7 Forward Recovery Elements for Activities Syntax 98

5.8 Vitality Attribute Syntax 99

5.9 Flat Fragment Syntax 99

5.10 Scope Syntax 101

5.11 Flexible Fragment Element Syntax 103

5.12 Instructions Syntax for Flexible Fragments 103

5.13 Business-aware Transaction Syntax 105

8.1 _{Safety Property of the Automobile Case Study in Uppaal} 198

8.2 _{Liveness Property of the Automobile Case Study in Uppaal} 198

8.3 _{Additional Properties for the Automotive Uppaal Model} 199

8.4 _{Additional Properties for the Automotive Uppaal Model} 200

8.5 _{Example of Unconventional Atomicity in Uppaal Model} 200

A.1 Integrated Logistics Business-aware Transaction I

A.2 Integrated Logistics Business-aware Transaction Uppaal Model X

C.1 Parameters for the Activity Template in Figure C.1 XXVII

C.2 Parameters for the Business Partner Template in Figure C.2 XXVII

C.3 Parameters for the Flat Fragment Template in Figure C.3 XXVII

C.4 Parameters for the Scope Template in Figure C.4 XXVII

C.5 Parameters for the Flexible Template in Figure C.5 XXVIII

C.6 Parameters for the Business-aware Transaction Template in Figure

C.6 XXVIII

(17)

C.7 Parameters for the Service Template in Figure C.7 XXVIII

C.8 Parameters for the Operation Template in Figure C.7 XXVIII

C.9 Parameters for the StartFlow Template in Figure C.8 XXIX

C.10 Parameters for the Select Template in Figure C.8 XXIX

C.11 Parameters for the AndSplit Template in Figure C.8 XXIX

C.12 Parameters for the AndJoin Template in Figure C.8 XXIX

(18)

List of Algorithms

6.1 Main BTL Document to Automaton Algorithm 120

6.2 Primary Automaton Algorithm 121

6.3 Sequence Structured Activity to Automaton 124

6.4 Transform an activity into an automaton 125

6.5 Parallel Structured Activity to Automaton 127

6.6 Asynchronous Product of Automata 128

6.7 Exclusive Choice Structured Activity to Automaton 130

6.8 Inclusive Choice Structured Activity to Automaton 132

6.9 Supportive Automata Algorithm 135

7.1 Create a small automaton from an activity 179

(19)

(20)

Preface

Was lange währt, wird endlich gut; German proverb

Nani gigantum humeris insidentes; attributed to Bernard of Chartres

It took some time2_{, but here it finally lies before you.} _{Even though a} disser-tation is a very solitary occupation, I could not have done it without the support of many giants around me and this is the place to express my deepest gratitude to all of you. I am very happy you were there for me!

Working closely together with prof. dr. Ralf Reussner during my Master thesis research in 2002 and early 2003 at Monash University in Melbourne (Australia) had a profound impact on me, for which I am still very grateful to him, as he ignited my interest into academic research. Returning from Australia, prof. dr. Mike Papazoglou and prof. dr. Willem-Jan van den Heuvel then offered me the opportunity to continue my career in academia as a Ph.D. Researcher at Tilburg University. Together with prof. dr. Paul Grefen they initiated the XTraConServe project and supervised my research efforts these past few years. Having three promotors, each with their own background, personality and approach, has not always been easy, but our shared goal lightened the path towards this outcome. I am very grateful for their continues support and want to sincerely thank all three of them for giving me this opportunity. I am very honored to have been supervised by these three highly esteemed researchers and this dissertation would certainly not have been possible without them. I cherish the joint efforts and successes writing papers together with Mike and he keeping me sharp, contemplating my work with Willem-Jan in out-of-office locations and discussing and cooperating with Paul, him always being an excellent host when I visited Eindhoven.

My sincerest gratitude and appreciation also go to the members of my Ph.D. committee. I want to thank prof. dr. Winfried Lamersdorf, prof. dr. Christos Niko-laou, prof. dr. Piet Ribbers and dr. Yéhia Taher for their valuable comments and feedback that greatly contributed to the quality of this dissertation. Having such a large committee has its challenges (like planning), but I am just very honored to have gotten the opportunity of having this unique combination of distinguished researchers in my committee.

I specifically want to mention and thank Yéhia for his invaluable support the past eighteen months. His positive attitude, openness and kindness were a great gift to me. He always (even when on holidays in Lebanon) offered his valuable time to discuss the content of my dissertation with me, pointing me to other sources

2_{This is an understatement; the research, start to finish, (only) took 4011 days.}

(21)

and offering me advice on writing my dissertation. During these past few years, Piet has been an extraordinary and highly esteemed colleague and mentor to me. I closely collaborated with him in lecturing various classes and I have learned a great deal from him. I want to thank him very much for his coaching and ongoing encouragement. I also want to mention dr. Amal Elgammal, who provided me, with breakneck speed, an excellent introduction into the foundations of and other valuable insights in temporal logics and model checking.

During these past few years I have had the opportunity to work together with many enthusiastic, kind and incredibly smart people. I want to thank my former office mates and colleagues at Tilburg University for their company, discussions, collaborations and the many good times we have had these past few years. In no particular order: dr. Bart Oriëns, dr. Kees Leune, dr. Vasilios Andrikopoulos, Patri-cio de Alencar Silva, dr. Bartel van de Walle, Michele ManPatri-cioppi, dr. Hans Weigand, dr. Jeroen Hoppenbrouwers, Frans Laurijssen, dr. Akos Nagy, Jon Pluyter, Sebasti-aan Tesink and dr. Martin Smits. I am indebted to Bart and Kees, in particular, for proofreading this dissertation. A special thanks goes out to our secretaries Mieke Smulders and Alice Kloosterhuis. I want to thank Alice for her help with many small and large issues these past few years and for our pleasant conversations.

I also want to express my appreciation to the members of our joined research project from Eindhoven University of Technology, dr. Ting Wang and Jochem Vonk, for their cooperation and ideas.

Since I started working at Deloitte Consulting part-time in 2007, a whole new world opened up to me, especially concerning my personal development. I am glad that I took the step from academia to a professional services firm with the pos-sibility to work in both worlds at the same time, letting me apply cutting-edge developments from academia to business challenges. The dynamic environment, the many exceptional professionals and the interesting assignments all make it very worthwhile. I want to foremost thank my direct manager René Theunissen for his support, giving me the opportunity to finish my dissertation by letting me make a final leap during a sabbatical. My counselor George Kollmann has been guiding me ever since I started at Deloitte. I greatly appreciate his straight-forward manner and the way in which he lets me discover my own path whilst at the same time offering me excellent advice. I feel very privileged to work together with so many fine colleagues and to be in a position to also pay my knowledge forward as well, both at Deloitte and in academia. I have met, and still meet every day, many special people at Deloitte and the list of them here would be sheer endless, but I want to mention Laudy Konings, Jeroen Bok, Ron IJmker, Tom Schepers, Yvonne Maas, Marloes van de Braak, Edward van Meeuwen, Ronald Kruidhof, Kirsten Hulken-berg, Régine Terwisscha van Scheltinga and Hans van Beek in particular. One person, from outside Deloitte, I want to mention is Arno Ramakers. Arno has come along my path very frequently the past few years and I am very glad for that to have happened. Some insights about oneself are not always easy, and he, in his way of coaching, sometimes confrontational but always respectful, provided me an environment for critical contemplation and offered me invaluable advice.

During my Ph.D., especially in the last phase, I have not always been around for my friends and family during birthdays, births and other occasions. I am blessed with having these friends and relatives and their sheer amount of understanding and

(22)

support for me. Sander, Martijn, Marco, Marcel, Dennis & Maaike and Kevin & Lizzy, my HvB running-mates and friends in Australia: thanks for being there!

Without my parents Barbara and Helmut I would not have been the person I am today. Having their unconditional support, faith and love always kept me going forward. No words can express my gratitude towards them. I want to thank my brother Fabian not only for his help in reviewing my dissertation, but also for his clear and analytical opinions and occasional jests about my progress, which always triggered my ambition to complete the work. Unimpressed by his own busy schedule, he is always there for me; I am very proud of him and his accomplishments.

Anke has been my support and anchor these past ten years. Putting so

much effort into this dissertation has not always been easy for our relationship, but I am very glad that my soul-mate stuck around and that we achieved this great milestone together. Without her and her encouragement, I know for sure that this dissertation would not have been finished. I hope we can and will en-joy more time together, not only here but also in many other places around the globe. Benedikt Kratz

Lisse, October 1st, 2012

(23)

(24)

Chapter 1 Introduction

This dissertation is about transactions, business-aware transactions to be precise, and in this chapter we present an introduction to our research. Our definition of what we mean by business-aware transactions will follow from the overview of the scientific and real-world context of this research as presented in Section 1.1. In Section 1.2, we argue why there is a strong case for business-aware transactions in e-business environments. Since there are currently no available mechanisms to support business-aware transactions, Section 1.3 explicitly states our research goal to develop a model and language as part of a framework that is capable of supporting business-aware transactions. After we introduced the goal of our research we define the scope in Section 1.4. Within this scope we list in Section 1.5 the questions that need to be answered in order to achieve our research goal. The development of our framework during our research followed a scientific methodology, which will be explained in Section 1.6. Section 1.7 provides an overview of the contribution of this completed research. In Section 1.8, we give an overview of limitations and assumptions concerning our research. The final section of this chapter, Section 1.9, gives an overview of the structure and the other chapters of this dissertation.

1.1 Research Context

The term transaction is overloaded with semantics. The goal of this section is therefore (a) to provide a common ground on what we mean by the term and its various derivations, as used in both the business domain and information technology

domain, (b) to present the elements of both domains that are relevant for our research

and (c) to give an insight into the focal point where both domains meet and intersect, as that is the point where this research is positioned.

Transactions: business and information technology perspective

(25)

2 Chapter 1. Introduction

business partners. We will use the term business transaction1 _{in this dissertation to} refer to this type of transactions.

A business transaction is a contractually agreed-upon commercial reciprocal exchange of assets between two or more parties.

Definition - Business Transaction

The objective of a business transaction is accomplished only when the agreed-upon conclusion among trading business partners has been reached. This can be, for example, a payment that is received on time by one business partner in exchange for the delivery of goods to a certain location of another business partner. Transacting tangible and intangible items is the basic element on which our economy thrives.

A business transaction is reflected by a consistent change in the state of an organization and is commonly driven by a business function (e.g., sales, operations or logistics) [Papazoglou, 2002]. Each participant in a business transaction holds its own state in relation to other business partners participating in that business transaction. During the course of a business transaction, this state may change [Little and Freund, 2003].

A key characteristic of business transactions is their complexity. This complexity arises from the fact that they (a) can have a long duration, (b) involve multiple busi-ness partners and (c) are contract-driven. Busibusi-ness transactions must be recorded by an organization, as part of financial accounting and reporting, due to governmen-tal rules and regulations. At the same time, these records can be used to support internal management accounting.

Keeping record of business transactions was originally done by hand in ledgers. With the large scale emergence of Information Technology (IT) from the 1960s on-wards, the automation of existing paper based procedures became one of the first areas that organizations addressed to reduce their costs [Pearlson and Saunders, 2009]. Record keeping could be easily automated and databases proved to be a viable technological means of keeping a persistent record of the data of the busi-ness transaction in computer memory. Since a busibusi-ness transaction is reciprocal, the recording of data involves two or more consistent changes to the state of the database, just as in traditional (manual) double-entry accounting systems.

Consider for example the sale of car-seats by an automotive supplier to a car manufacturer: a sale of seats has at least two implications. The sale increases the amount outstanding to the car manufacturer (the debtor) and decreases the monetary value of the seat inventory of the supplier. All changes to the data inside the database must be permanently recorded and be faithfully. This means that the data in the database must be a true representation of the actual transaction and conform to legal requirements. As the actual business transaction is reflected by changes in the state of the database and the values of the stored data managed by the database, a set of such related database state changes is therefore referred to as a database transaction2.

1_{A business transaction may consist of one or more commercial reciprocal exchanges.}

2_{A database transaction, in the technical sense, is in fact the execution of a program, in which}

(26)

1.1 Research Context 3

Transactions in databases

With respect to databases and their management, there exists a plethora of available research and commercial and open-source products that have accumulated ever since the introduction of the database concept in the 1960s. Research into the reliability of databases has since then been an important area of investigation. To provide reli-ability whilst recording data, database capabilities include facilities to enforce data integrity, allow conflict-free concurrent access and automated exception handling and fault recovery in case of errors. A database transaction is a mechanism to guar-antee the aforementioned facilities, allowing the access and manipulation of data in a sound way. To that end, a database transaction holds the following properties, referred to as ACID properties [Bernstein and Newcomer, 1997]:

Atomicity A transaction executes completely or not at all.

Consistency A transaction preserves the internal consistency of the database. Isolation A transaction executes as it were running alone, with no other

transac-tions.

Durability The results of a transaction will not be lost in a case of a failure.

Applying these properties to the before mentioned example of the car-seat sup-plier implies the following. When changing multiple data values in the database as part of the registration of a business transaction, the database transaction as such, with all of its changes to the data, will either succeed or fail. If it succeeds, the state of the database after the transaction reflects the business transaction in its data completely. If it fails, the state of the database after the transaction will be the same as if the business transaction has never happened. In database terms, the transaction either commits or aborts. It is thereby prevented that either solely the inventory value has decreased without an increase of the amount outstanding or only the amount outstanding has increased without a decrease of the inventory value.

The increasing use of IT, due to the ongoing automation of manual actions and procedures within business functions, unlocked new opportunities and challenges for businesses. Management realized that the available data, residing in computer systems now distributed throughout the organization, could be an important source for management information that allowed for better planning, controlling, steering and changing of an organization [Laudon and Laudon, 2000].

(27)

The focus on business processes and the rise of e-business

IT became an important asset for better internal coordination across previously rather disconnected business functions. The need for better integration, especially from the 1990s onwards, was not only fueled by internal demands, but also by exter-nal pressures. Customer and competitive forces required businesses to take a holistic, customer-oriented view of their firm, focusing on value delivery to customers through business processes that span multiple business functions of a company [Davenport, 1993] and are supported by IT. The consistent management and execution of busi-ness processes together with the registration of occurring busibusi-ness transactions are thereby of utmost importance for organizations, as these activities determine an organization’s profitability.

Business processes are commonly decomposed into several activities, which either occur consecutively, in parallel or are optional. To facilitate the consistent model-ing, management and execution of business processes, workflow systems can be used to connect the activities that take place at the different business functions as part of a business process [Grefen, 2000, van der Aalst and van Hee, 2002]. To support business processes, workflow systems had to be able to execute these processes in a reliable way such that no invalided process state can be reached or invalid informa-tion is exchanged. Therefore similar approaches, reusing the concepts and noinforma-tions as already existent in database transactions, were now being applied, in the form of workflow transactions or transactional workflows, on process level to guarantee robustness and the reliable execution of business processes [Grefen and Vonk, 2006]. For example, the application of ACID properties to a business process implies that if one activity of the business process fails, the whole business process will fail and possibly needs to be redone.

Due to new and faster data-communication technologies and the advent of the Internet, organizations could also connect their support and information systems to the ones of their business partners. End-to-end linking of business processes and integrating and coordinating the automatic flow of information among organizations and their business support and information systems is also referred to as e-business [Papazoglou and Ribbers, 2006]. E-Business is nowadays an important, but certainly not sufficient, imperative for organizations seeking to create or maintain sustained market advantages.

(28)

Interlude: Loosely-coupled e-business integration with services

Loose coupling of information systems is a requirement for e-business integration. Notice that the concepts and notions from database and workflow transactions are necessary, but not sufficient features to support business transactions in e-business environments, since both databases and workflows require a tight coupling between the participating organizations3_{, something which is not desirable in highly} dy-namic e-business collaborations. Organizations nowadays operate in highly dynam-ical settings and must respond in a flexible way to changing regulations or market conditions. This requires an inter-organizational coordination based on standard infrastructures that allow for flexible reconfiguration.

Tightly coupled information systems between organizations imply that a great deal of details on agreement and shared context across information systems must be established upfront. Such approach leads to a sensitivity to change, which in turn has the potential to inhibit the capacity for flexible reconfiguration. On-the-fly and on-demand establishment of business relations are the key to e-business integration. To achieve e-business integration, loose coupling is the mechanism of choice as it allows systems to connect and interact more freely across the Internet.

Service-Oriented Computing (SOC) is a new generation distributed computing platform [Papazoglou and Georgakopoulos, 2003,Erl, 2007] to realize loosely-coupled applications that support highly dynamic establishment of business relationships. A key element of SOC is the service concept, which has emerged as a suitable abstrac-tion mechanism, to realize dynamic, self-adaptive Service-Bases Applicaabstrac-tions (SBAs) by flexibly composing individual services [Di Nitto et al., 2008]. Strongly related to SOC are the Service-Oriented Architecture (SOA), as its underlying implementation-agnostic architecture model and Service-Orientation (SO), as its design paradigm and design principles.

To realize a SOA, a technology platform like web services is required. Web services are [Webber and Parastatidis, 2003]:

• self-describing, logical manifestations of heterogeneous physical or software resources4 _{such as databases, applications, devices or humans,}

• grouped as a process, that is, composed into a set of actions that an organi-zation is prepared to execute and

• exposed to the internal network of an organization or to the Internet.

Web services are based on platform5 _{independent standards and are identified} by a Uniform Resource Identifier (URI). Standards exist for the description (Web Services Description Language (WSDL) [Chinnici et al., 2007]), discovery (Universal Description Discovery and Integration (UDDI) [Bellwood et al., 2003] and commu-nication between (Simple Object Access Protocol (SOA) [Gudgin et al., 2003]) web services on top of network and transport protocols (e.g., Hypertext Transfer Pro-tocol (HTTP) or Simple Mail Transfer ProPro-tocol (SMTP)). A web service defines a

3_{This, however, might still be an option if organizations have stable long-term relationships}

between them.

(29)

set of messages in standardized eXtensible Markup Language (XML) [Bray et al., 2008] that can be exchanged and couples actions (e.g., querying back-end databases) to the receipt of messages, and (potentially) with the return of appropriate reply messages. This set of standards is called the web services stack. They form the foundational set of standards to realize SBAs that span multiple systems between different business functions and organizations.

By using and combining multiple web services, referred to as service

composi-tion, an organization can leverage the benefits of web services to gain advantages in

e-business integration and perform interactions with web services offered by other or-ganizations with minimal programming effort, even on an ad hoc basis. This enables dynamic execution of business tasks within such integrated business processes [Pa-pazoglou, 2003]. Using web services provided by different organizations results in business process interactions between those organizations that involve orchestrations of service invocations to complete a multi-step business interaction.

Since SOC is the current predominant architectural style used in e-business to seamlessly integrate distributed information- and support-systems of collaborating business partners in a highly dynamic fashion and on-demand basis, our research is positioned within that field of computing.

Transactions in Service-Oriented Computing The foundational set of web service specifications did not cover any guidance on composition or Quality of Ser-vice (QoS) related aspects (such as security, reliable messaging or transactional ca-pabilities and coordination of web services), new standards for these topics emerged. The Web Services Business Process Execution Language (WS-BPEL) [Alves et al., 2007] specification is an OASIS standard, on top of the previously mentioned

foun-dation of standards. WS-BPEL is an orchestration language that supports the

composition of web services into processes [Leymann and Güntzel, 2003]. Impor-tant standards in the area of transaction support for web services are Web Services Coordination (WS-C) [Feingold and Jeyaraman, 2009], Web Services Atomic Trans-action (WS-AT) [Little and Wilkinson, 2009] and Web Services Business Activity (WS-BA) [Freund and Little, 2009]. Transaction support for web services is fore-most concerned with pure technical requirements such as the coordination, through predefined protocols, of participants of a web service transaction. As such, SOC currently only provides very rudimentary support for the creation and coordination of meaningful and reliable business transactions in e-business environments.

Business-aware Transactions

Before we introduce the motivation for our research into business-aware transactions in the next section (Section 1.2), we will first define what we consider to be

business-aware transactions and describe their position in the current transaction landscape.

(30)

generated failures (e.g., non-recurring disk or network errors). As important and necessary it is to provide system-level reliability, even when conducting e-business, it is not sufficient when considering the challenges that organizations face when operating in the new world of e-business.

A key element of e-business is the need to support the reliable, consistent and recoverable execution of cross-organizational business processes as part of automated business collaborations amongst multiple business partners. These collaborations are driven by shared objectives, are governed by contractual constraints and are only considered successful if all business partners terminated in an acceptable state once the business transaction has finished. As these collaborations, in essence, can consist of one or more business transactions, there is a clear need to at least provide reliability and integrity features similar to the ones provided by distributed database transactions and workflow transactions to coordinate the participating systems at business partners. If the aforementioned features are not present, inconsistencies and failures will become quickly visible to the business partners throughout the value chain and business network. Manually locating and repairing these problems can lead to unnecessary costs resulting in financial consequences with direct impact on the bottom-line.

In addition, a business in such a situation may not be able to fulfill its promises to and satisfy the expectations of its business partners. As a result an organization may suffer a loss of business due to a decline in trust. Assuring that promises are kept in a predictable, correct and consistent fashion and at an acceptable service quality level is commonly referred to as reliability [Papazoglou and Ribbers, 2006, Papadopoulou et al., 2001]. This makes reliability, as part of the business domain, a crucial factor

when conducting e-business [Urban et al., 2000]. For example, assuring that a

delivery reaches its destination on time is more important than the actual speed of the particular delivery.

E-business interactions create critical interdependencies that require additional reliability features on top of the currently offered features of transactions in the infor-mation technology domain. Business-to-business collaborations in service-oriented environments involve choreographies of service invocations between businesses to complete a multi-step business interaction that relies on numerous document ex-changes, and requires multi-party, long-running transaction support with a clear specification of business agreements based upon contracts. Since current IT trans-actions cannot adequately support these features, there is a need to merge business aspects with existing transaction concepts found in the information technology do-main in order to support the requirements imposed by e-business interaction.

(31)

businesses, and (d) is terminated successfully only upon recognition of the agreed conclusions between the interacting business partners. Our definition of business-aware transactions takes this into account and positions itself at the intersection of business transactions and transactions from the information technology domain. The definition is as follows6_:

A business-aware transaction is a contract-driven IT transaction in service-oriented computing environments that facilitates the failure-resilient and consistent coordination of a possibly long-running, multi-party business transaction.

Definition - Business-aware Transaction

With the above definition we want to position our particular work on transactions at the center of gravity of the two forces that constantly need to be aligned by organization as a prerequisite of being successful with e-business [Grefen, 2010]. These two forces are:

1. the technology push, represented in this dissertation by the technical capabili-ties of existing transaction solutions from the information technology domain and

2. the requirements pull, represented in this dissertation by the need to include business aspects that are currently not available on top of IT transactions to allow for an integral and reliable end-to-end management and execution of multi-party business transactions.

1.2 Motivation

E-business, in particular the Business-to-Business (B2B) part, is undeniably be-coming increasingly important for organizations. Statistics show that in 2007 there has been about $900 billion sales in e-business of which about $400 billion can be attributed to B2B sales (compared to only $20 billion for Business-to-Consumer

(B2C)) [Sandhusen, 2008]. Table 1.1 indicates that in Europe (EU-27),

enter-prises’ receipts from sales through electronic networks as percentage from their total turnover increased between 2004 to 2011 from 9% to 14%7_.

To be successful in B2B e-business, several requirements need to be fulfilled by an organization [Papazoglou and Ribbers, 2006]. One of the challenges for orga-nizations is to create alignment between its operating model and IT architecture

to be able to implement and leverage e-business (integration) technology. In a

2001 report, the Giga Information Group (now Forrester Research, Inc.) announced

6_{Our definition is an elaboration of the previously published definition in [Papazoglou and}

Kratz, 2006, Papazoglou and Kratz, 2007]

(32)

1.2 Motivation 9 Year % Year % 2004 9 2008 12 2005 10 2009 12 2006 11 2010 14 2007 11 2011 14

Table 1.1: Share of enterprises’ turnover on e-commerce [Eurostat, 2012]

that early adopters implementing and mastering e-business (integration) technol-ogy8 _{were benefiting from reduced lead times, lower inventory levels and improved} customer loyalty, resulting in a positive impact on an organization’s bottom line [For-rester Research, Inc., 2001b]. Key business and technical challenges mentioned in the report are still relevant and are the topic of this dissertation. One relevant business challenge is coordination. Coordination is an essential element to manage the complexity of business-aware transactions with multiple key partners involved. Two relevant technical challenges are process management and transaction

recov-ery. Process management is concerned with the end-to-end management of the

value chain, which also encompasses the adaptation of processes in a flexible man-ner if changes are required. Transaction recovery ensures consistent failure-handling among multiple trading partners involved in a business transaction.

A Gartner report from 2010 about market trends in the infrastructure market acknowledges the positive and bottom- and top-line influence of what they call

multienterprise/B2B deployments9 _{(Source: [Gartner, 2010]}10_{). The Gartner report} also indicates that the challenges for organizations engaging in e-business, as stated by the Giga Information Group in 2001, are still applicable as can be seen from the quote from Gartner that can be found on page 10.

To face the presented challenges organizations are required to take an outside-in approach, away from a siloed, enterprise-out design patterns to new architectures that are designed to anticipate service and people dependencies from the outside as Deloitte postulates in its 2012 Tech Trends [Deloitte, 2012]. This development is supported by technological advances, particularly in the area of SOC, which allow end-to-end business services, referred to as capabilities by Deloitte, to be orches-trated across multiple business partners. Deloitte also identifies important tech-nology implications that are particularly relevant and applicable for this research. These implications include the inapplicability of atomic transaction processing and

8_{Giga Information Group actually uses the term Business Process Integration (BPI). BPI}

cov-ers a subset of the more general group of e-business integration technologies. Electronic Data Interchange (EDI) (a batch-oriented document exchange technology over Value Added Networks) can be considered as a different subset of e-business integration technologies [Forrester Research, Inc., 2001a], but is not in scope of this dissertation. BPI is defined as the automated exchange of business process information (over the Internet) between trading partners that is designed to streamline operations, reduce costs and improve customer service [Forrester Research, Inc., 2001b]. This definition is however very similar to the one we use in dissertation for business-aware trans-actions.

9_{The definition of Gartner for multienterprise/B2B is in line with our definition of e-business.} 10_{Please be informed that this citation indicates a historical viewpoint of Gartner from 2010}

(33)

the importance of time sensitivity11_{. Both atomic transaction processing and time} sensitivity must be addressed when realizing an outside-in architecture in order to successfully conduct e-business as an organization. In the remainder of this section we will cover these topics as they provide the motivation for our research.

Be aware that multi-enterprise/B2B infrastructure projects will increasingly involve a variety of technologies as the dumb network evolves to become a

smart network that incorporates diverse integration and collaboration

func-tionality, including communications, translation, Business Process Manage-ment (BPM) and collaborative tools, increasingly impleManage-mented using an SOA. Successful companies will leverage traditional and process integra-tion, as well as SOA, to solve diverse application integration and interoper-ability requirements. Internal IT infrastructure will include adapters; data transformation engines and Extract, Transform, Load (ETL) tools; inte-gration brokers and business process managers to orchestrate message flow, web services choreography and event management and alerting facilities for Business Activity Monitoring (BAM).

Source: [Gartner, 2010]10

We can categorize the above challenges into three topics that illustrate the cur-rent gap between the available functionality offered by existing reliability technology both from industry and academia on the one side and the functionality needed by the business domain to successfully engage and expand in e-business initiatives that support the aforementioned complexity of business-aware transactions (see Section 1.1) on the other side.

Duration, isolation and atomicity A business transaction can take an extended

amount of time between start and finish. This time-frame must be supported appropriately. To guarantee reliability by means of isolation and atomicity, traditional strict-ACID transactions lock resources. These ACID transactions are usually used between trusted systems over short periods of time and are therefore extremely reliable.

This, however, is impractical during a long-running business transaction as locked resources can potentially be blocked for long periods of time and are therefore not available for other business partners willing to participate in the business transaction. This is something that is not appropriate for e-business. In the loosely-coupled world of e-business with autonomous trading partners, autonomy, security and inventory control issues prevent hard locking of local resources [Green, 2001, Papazoglou, 2002].

Advanced transaction models [Wang et al., 2008] from the IT domain, such

as open nested transactions [Weikum and Schek, 1992], relax isolation and

11_{Time sensitivity relates to the IT support for long-running transactions to reflect the very}

(34)

1.2 Motivation 11

atomicity and support long-running interactions. There are however two com-plications. The first and lesser complication stems from the fact that a partic-ular type of transaction is usually limited to a particpartic-ular IT domain such as databases or workflows; something that is generally resolved by inventing new transaction types with similar properties as existing types of transactions for new domains. The second complication is the fact that within a particular do-main it is difficult to combine various transaction types into a comprehensive whole. Composition is necessary because of different reliability requirements that may exist within long-running business transactions. Some parts of a business transaction may require strict enforcement of atomicity (e.g, for the payment part of a business transaction) whereas other parts of the same busi-ness transaction can suffice with a more relaxed atomicity (e.g., ordering). Looking ahead to the results of our literature review, we can already note here that business-aware transactions require transactional support beyond capabilities currently offered by classical ACID and extended transactions.

Contracting As business transactions are regulated by contracts, as in legally

bind-ing agreements, their execution is also governed by these contracts. Contracts provide the constraints within which business transactions must operate. If these constraints exceed their agreed-upon thresholds, contracts are violated. Violations impact business transactions as they may cause a need to undo already performed activities, do additional clean-up work or do alternative ac-tivities. Note that not every contract violation has a legal implication as these can be accepted to occur upfront and agreed to by the business partners. Con-sider for example the following situation: if a preferred supplier cannot fulfill an order then a violation may occur that does impact the business transaction, since a second supplier might be asked to fulfill the same order. Typical con-tractual constraints types are temporal, spatial, security and QoS. It must also be possible to allow the definition of acceptable violations. If, for example an order acknowledgment is expected, but an out of order message is received12_, then this should not, if deemed acceptable, lead to a complete undo of the business transaction.

To bridge the gap between business and IT transactions, contractual con-straints appear to be a suitable candidate to be included as a foundational part of business-aware transactions, clearly representing the business seman-tics currently not present in IT transactions.

Failure-resilient coordination In order to complete a business transaction with

an agreed-upon outcome in which business partners reach their shared objec-tive, business partners participating in a business transaction must coordinate with one another. Such coordination must respect the loose coupling and the autonomy of involved business partners and must be imposed by a coordina-tion protocol for business-aware transaccoordina-tions. Business partners synchronize their public, agreed-upon interactions through this coordination protocol. Without a failure-resilient coordination protocol, failures cannot be handled

(35)

effectively as the interactions between business partners become cluttered with multiple out-of-band messages necessary for error recovery [Green, 2001]. Fail-ures must be addressed not by automated roll-back, something that is often not even possible in a business environment. A roll-back after an order has been delivered, for example, makes no sense. Compensations, which either semantically undo (a part of) what has occurred up to the point of the failure or repair the issue that is halting execution and continue the business trans-action, are much more suitable to handle failures in business transactions. Compensation, or as we will use throughout this dissertation, reversion, is an approach to restore a semantically equivalent state that reflects the actual state before a failure occurred. Additionally, it is desirable in a long-running business transaction to cancel parts of a running business transactions without affecting other parts of the same business transaction.

Current IT transactions are predominantly failure-resilient with respect to system failures and failures that occur during the execution of their coordi-nation protocol. Contractual violations on business level however need to be handled in application logic and require hard-coding of business rules. Such hard-coded business rules are inefficient, especially in the context of highly-dynamic e-business. To increase flexibility, business failures, as in failures related to deviations from the agreed-upon contract, must be a first class and easily changeable (or configurable) element in a business-aware transaction. A business-aware transaction must also allow the evaluation of the current transaction state and have the ability to make forward progress depending on the current business context.

The current gaps within each of the three discussed topics, in the light of the rising e-business importance, provide an interesting opportunity and sufficient reason to conduct further research into how to close these gaps. This motivated us to further research the possibility of combining business and IT transactions into business-aware transactions. We investigate in the literature study of Chapter 2 how current transactional approaches and their characteristics cover these topics.

A note on failures

In industry and academia, the terms failure, fault, error and exception are also somewhat overloaded with semantics, often just distinguished by very subtle differences. For simplicity’s sake we consider them in this dissertation as one and we acknowledge that there may exist a semantic difference between the terms. For example, in the Java programming language, exceptions can be handled and recovered from whereas errors are unrecoverable [Gosling et al., 2000]. In this dissertation however we will use the term failure.

(36)

1.3 Research Goal 13

the specified contractual constraints (e.g., payment within 6 days, but no payment received). Such a failure is foreseen if, and only if, these contrac-tual constraints have been explicitly specified as part of the business-aware transaction. This particular type of foreseen failures is referred to in this dis-sertation more applicable as a violation of contractual constraints. If such a failure happens, an alternative activity can be executed instead, if specified. If not, the failure will cause the part of business-aware transaction it is part of to start recovery. This type of failure is said to be recoverable. In addition, business partners may, during the execution of a business-aware transaction, take a unilateral decision related to the business-ware transaction (e.g., exit) that was not agreed-upon beforehand. Since we limit the set of these decisions and the fact that these decisions are binary, we consider these decisions, if not specified, to be not allowed and these are therefore also part of the foreseeable failures that cause recovery to commence.

An unforeseen failure occurs if something happens that was not foreseen and thus is also not specified beforehand. If such an unforeseen failure oc-curs, then, if specified as part of the business-aware transaction, contingency actions are taken. Typical contingency actions are retries or executing

al-ternative activities. If these contingency actions fail, the failure is said to

be unrecoverable. Such a failure will cause the business-aware transaction to move to a state that needs manual intervention and repair before it can be continue. This final comment also applies if business partners signal a failure.

1.3 Research Goal

The need for business-aware transactions to streamline e-business in service-oriented environments, as motivated by the previous discussion, framed the research as pre-sented in this dissertation. Our research has been part of the XTraConServe project. The overall goal of this joined research project was to develop a Business-aware Transaction Framework (BTF): a set of concepts, support mechanisms and infras-tructure facilities for advanced transactional behavior of complex business processes in contract-driven cross-organizational, service-oriented environments. The BTF facilitates the specification, orchestration and monitoring of choreographed loosely-coupled services into a single, automated, high-level and contract-driven business-aware transaction guaranteeing coordinated, predictable outcomes to the business partners of a long-running business transaction in an e-business context.

(37)

Abstract Transactional Constructs (ATC)13 _{to accommodate the required}

transac-tion support.

The focus of our work will not be on the inclusion of transactional semantics in contractual agreements, but on the actual business-aware transaction concept and support mechanisms as required for the BTF. Business-awareness will be realized by infusing contractual constraints into our transaction concept. The support mecha-nisms must contribute to the improvement of the operational reliability of the type of business transactions that are to be facilitated by the BTF. To assure reliability during the execution of business-aware transactions, the mechanisms must be able to: (1) handle failures, (2) keep track of timeliness of events according to agreements made, (3) manage allowed and disallowed participant behavior and (4) coordinate business partners. This will contribute to the streamlining of business operations resulting in faster throughput times, less manual intervention and therefor less trans-action costs14_{. Taking the previous discussion into account, we define the goal of} our research as follows:

To design a model for the business-aware transaction concept together with its required support mechanisms and to develop and validate a formal-ized specification language with exact behavioral semantics based on this model that will allow the failure-resilient coordination of explicitly speci-fied business-aware transactions as part of the Business-aware Transaction Framework (BTF).

Notice that failure-resilience on system-level supports reliability, as discussed in Section 1.1, on business-level. Being reliable plays a pivotal role for businesses in an e-business context and since this reliability is, at least for some part, dependent on the underlying technology platform that is used, our hypotheses are:

1. Reliability support on system-level is a necessary, but not sufficient precondi-tion for successful e-business.

2. The combination of business concepts with existing IT reliability mechanisms from system-level transactions, will allow businesses to better support the failure-resilient execution of cross-organizational business processes, resulting in a better conformance to the reliability expectations on business-level of business partners in an e-business context.

If we analyze our research goal, it is evident that to achieve the research goal the main objectives of this research are related to the creation of two distinct, but related, artifacts that constitute the building blocks of the BTF and are therefore the key focus of this research: (1) a Business-aware Transaction Model (BTM) and (2) a Business-aware Transaction Language (BTL). The BTM will capture the key model constructs that are required to support the specification and failure-resilient

13_{ATC represent abstractions of common transaction models and their generic qualities.} 14_{We do not provide a business-case in this research to quantify the financial impact of our}

(38)

1.4 Research Scope 15

coordination of business-aware transactions. It will relate business and IT concepts and transactional mechanisms to the language structures and operational behavior of the BTL. The language elements of the BTL will allow the specification of business-aware transaction that can then be executed at run-time. The key research problem is then as follows:

What are the essential concepts and support mechanisms for business-aware transactions and how can these be operationalized so that these aid organi-zations in improving their operational effectiveness by contributing to the reliability of business transactions in e-business environments?

In the next chapters we will investigate and analyze the BTM and BTL building blocks of our BTF. Both building blocks should be based on a robust formal foun-dation, thereby validating the rigor of the research presented in this dissertation.

1.4 Research Scope

As we have seen in Section 1.1, transactions can be characterized from a business or technology perspective. In this research, the technology perspective on transactions prevails above the business perspective, since our goal is to design a new transaction language as part of the IT domain that will be extended with business notions to make it business-aware. There are several other dimensions that can be used to characterize and analyze transactions, some of which can be found in [Gebauer and Scharl, 1999, Papazoglou, 2003]. In this section we will discuss some common perspectives and position our research on business-aware transactions in relation to these perspectives, in order to define the scope of our research.

Transaction Participants This perspective covers the different roles of

partici-pants of a business transaction. Typical roles of participartici-pants in such transac-tions are buyers, sellers and intermediaries [Gebauer and Scharl, 1999]. When we discuss business-aware transactions in this research we limit our scope to transactions where these roles are performed by businesses, commonly referred to as B2B. Our research might also be applicable to transactions between busi-nesses and (semi-) governmental institutions, that is, Business-to-Government (B2G), but we did not investigate this. Transactions between businesses and consumers, referred to as B2C, are not in scope of this dissertation.

With business-aware transaction we take a holistic view on transaction pro-cesses and present one view that captures the activities of all participating business partners like buyers, suppliers, manufacturers, distributors, and in-termediaries, etc., as part of one choreography.

E-Business Relationships [Papazoglou and Ribbers, 2006] present three

(39)

times or high inventory levels. On this level there is no up-front exchange of information between business partners. When businesses want (e.g., as part of changes to their business model) or are forced (e.g., by competition) to develop longer term relationships, they move to tactical-level relationships in which collaborative planning is used to reduce the uncertainty. Planning on strategic-level, finally, results in close cooperation and joined product devel-opment, in conjunction with planning on operational- and tactical-level. The model and language for business-aware transactions we are developing in this research facilitate businesses engaged in tactical-level e-business plan-ning. A specified business-aware transaction can be regarded as an encoded agreement for some period that will realize more stable relationships in terms of clearer expectations, reduced uncertainty and more reliability. The actual content (i.e., that what is being transacted) and execution of a business-aware transaction can be considered part of the operational-level and will improve the operational execution capabilities of businesses. This dissertation will fo-cus on this last part, that is, the operational reliability that is to be improved by business-aware transactions.

Transaction Phases A business transaction can be decomposed into several

dis-tinct phases. [Gebauer and Scharl, 1999] present an overview of models from literature and on that basis provide their own four-phase model to assess pro-cess infrastructures. These phases are the information, negotiation, settlement and after-sales phases. Other work, like [Yang et al., 2006], present similar phases but bundles the settlement and after-sales phases into a contract ful-fillment phase and add an additional collaboration phase. [Papazoglou, 2003] distinguished between pre-transaction, main transaction and post-transaction phases. The pre-transaction phase overlaps the information and negotiations phases of other models. The main transaction phase can be roughly com-pared to the settlement phase and the post-transaction phase is similar to the after-sales phase of [Gebauer and Scharl, 1999].

From the previous discussion, it appears that the model presented in [Gebauer and Scharl, 1999] is the most complete approach and we will use that to po-sition this research. Typical activities during the information gathering phase are concerned with the search of information (e.g., prices, delivery conditions, etc.) and the identification of possible business partners. During negotiation, the agreement terms will be negotiated and stipulated in a contract15_{. During} the contract fulfillment phase, the objects of the contract will be exchanged and all activities related to this exchange will be executed (e.g., ordering, transporting, paying). In addition, monitoring of the contract is also part of this phase and, as we have seen, after-sales activities are sometimes also attributed to this phase. After-sales activities are typically concerned with providing maintenance facilities or business partner performance assessments. Finally, the collaboration phase establishes future cooperation and can be used to stipulate future behavior that may result in strategic-level collaborations.

15_{This phase may be skipped if the business transaction is taking place under an existing contract,}

(40)

1.5 Research Questions 17

Business-aware transactions are specified as an outcome of the negotiation phase and are in fact operationalizations of contracts. The scope of our dis-sertation, however, is not on the translation of contracts into business-aware transactions, but on providing a language that can be used during the contract fulfillment phase. The language supports the set-up and utilization, that is, the execution of the contractually agreed-upon business transactions, on day to day basis.

E-Business Type In this dissertation, we limit the scope of our research to a

par-ticular type of e-business; a type that is mainly concerned with information exchanges related to buying and selling processes. This type is referred to as

e-commerce [Papazoglou and Ribbers, 2006]. This is also reflected by our focus

on the settlement phase and by the case study which we will use throughout this dissertation. This case study is a typical ordering process with purchas-ing, payment and delivery activities. E-business is defined broader and also encompasses activities associated to the collaboration phase of business trans-actions.

Transaction Life Cycle The life cycle of business-aware transactions roughly

fol-lows the common phases of the SOA life cycle as defined in [Brown et al., 2006, Erl, 2007] and which encompasses (a) design-time, sometimes split into modeling and composition (or assembly), (b) run-time (deployment) and (c) management. We limit the scope of our research to the design-time of the life cycle. We provide the BTL as a design-time construct that allows the specification of business-aware transactions. We will not provide an execution environment as part of this research. We, however, will provide operational, as in dynamic or execution, semantics as part of the language, that define how the language will behave at run-time.

1.5 Research Questions

To guide our research towards the realization of the two artifacts, BTM and BTL we define a set of research questions that are to be investigated in this research:

1. What is the state of the art with respect to transactions, in particular related to the modeling, specification and execution of transactions, in relevant research fields, both from an information technology and business perspective?

2. What are the essential business and IT concepts that significantly pertain to a business-aware transaction and should therefore be included in the BTM? 3. How can the concepts of the BTM be encoded in a uniform manner as part of

the BTL, how are they related and how can the behavioral semantics of the BTL be specified formally?

A model and language for business-aware transactions

A MODEL AND LANGUAGE

FOR BUSINESS-AWARE

A MODEL AND LANGUAGE

FOR BUSINESS-AWARE

TRANSACTIONS

PROEFSCHRIFT

Benedikt Kratz

Contents

List of Figures

List of Tables

Listings

List of Algorithms

Preface

Chapter 1

Introduction

1.1

Research Context

1.2

Motivation

1.3

Research Goal

1.4

Research Scope

1.5

Research Questions