TxQoS : concepts, scenario, and framework

Citation for published version (APA):Wang, T., Grefen, P. W. P. J., & Vonk, J. (2007). TxQoS : concepts, scenario, and framework. (BETA publicatie :working papers; Vol. 230). Technische Universiteit Eindhoven.

Document status and date:Published: 01/01/2007

Document Version:Publisher’s PDF, also known as Version of Record (includes final page, issue and volume numbers)

Please check the document version of this publication:

• A submitted manuscript is the version of the article upon submission and before peer-review. There can beimportant differences between the submitted version and the official published version of record. Peopleinterested in the research are advised to contact the author for the final version of the publication, or visit theDOI to the publisher's website.• The final author version and the galley proof are versions of the publication after peer review.• The final published version features the final layout of the paper including the volume, issue and pagenumbers.Link to publication

General rightsCopyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright ownersand 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.

If the publication is distributed under the terms of Article 25fa of the Dutch Copyright Act, indicated by the “Taverne” license above, pleasefollow below link for the End User Agreement:www.tue.nl/taverne

Take down policyIf you believe that this document breaches copyright please contact us at:openaccess@tue.nlproviding details and we will investigate your claim.

Download date: 01. Oct. 2020

TxQoS: concept, scenario, andframework ∗

Ting Wang, Paul Grefen, and Jochem Vonk{t.wang, p.w.p.j.grefen, j.vonk}@tue.nl

Department of Technology ManagementEindhoven University of Technology

The Netherlands

∗The research reported in this paper has been conducted as part of the eXecution ofTransactional Contracted electronic services (XTC) project (No. 612.063.305) funded bythe Dutch Organization for Scientific Research (NWO).

1

Abstract

We have proposed the TxQoS (Transactional Quality of Service) ap-

proach to infuse transactional semantics into contracts so that a gap

between business and technical communities with regard to transaction

awareness is filled. In this paper we continue to refine the proposed

TxQoS concepts in SOA (Service Oriented Architecture) context. We

illustrate the complete TxQoS picture by a scenario with three parties

interacting through the four phases of a TxQoS lifecycle. The specifica-

tion of the four TxQoS attributes is discussed in detail to demonstrate

how the TxQoS concepts are operationalized. To support the TxQoS

scenario, we present a framework containing an architecture, a map-

ping and matching model and a monitoring mechanism. With in-depth

investigation of various aspects of the TxQoS framework, we aim to

deliver a proactive approach of transaction management that is feasi-

ble, extensible and effective to enhance process and service reliability.

Keywords: TxQoS; SOA; SLA; Transaction Management

2

Contents

1 Introduction 4

2 Research Background 7

2.1 SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 TxQoS Proposal . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 TxQoS Overview 11

3.1 TxQoS Participants . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 TxQoS Lifecyle . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3 TxQoS Data Model . . . . . . . . . . . . . . . . . . . . . . . . 15

3.4 TxQoS Specification . . . . . . . . . . . . . . . . . . . . . . . 17

4 TxQoS Framework 23

4.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.2 Mapping and Match . . . . . . . . . . . . . . . . . . . . . . . 24

4.3 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5 Related work 28

6 Conclusions and future work 30

References 31

3

1 Introduction

Today’s business processes have become very complex with multiple part-

ners and distributed resources involved which result in long-lasting, cross-

organization cooperation over heterogeneous platforms. Meanwhile, flexible

integration of heterogeneous IT resources to support business agility is nec-

essary to gain a competitive edge. The evolving complexity and flexibility

demands make reliability more and more critical for both technical and busi-

ness communities. From a technical perspective, smooth execution of the

integrated systems across organizational boundaries is a must. Technolo-

gies such as Web services, middleware etc. have emerged to enable a loose

coupling of the distributed applications (published as services). These tech-

nologies greatly facilitate large scale resource reuse and meanwhile provide

certain reliability for the supporting processes. From a business perspective,

processes should be designed as robust as possible to minimize loss from fail-

ures. Besides technical reliability, proper management and legal means also

contribute to process reliability.

Transaction management has been around for nearly three decades as

an effective and widely-adopted technical means to guarantee reliability for

running applications. The original ACID properties are the pivotal features

a short-lived database transaction should conform to free the worry of ap-

plication designers about low-level system errors and exceptions. Later on,

with the emergence of large-scale distributed databases, quite a few trans-

action models were proposed, which relax one or more ACID properties for

long-lived or multi-leveled database transactions. Afterwards, along with

the workflow systems, even more complex models have been created based

on database transactions. Nowadays, with the emerging service technologies,

transaction management still plays an important role.

Contracts are used as a legal means to protect business trustworthiness

by enforcing obligations between partners. E-contracting sets a vision to

automate contract establishment, monitoring and management for greatly

enhanced efficiency and effectiveness. After an e-contracting case analysis

[Wang 07], we discovered that the lack of transaction awareness between

4

business parties and the subsequent inadequacy of transactional agreements

within e-contracts lower the process reliability. The main cause, as we identi-

fied during the analysis, lies in the gap between IT and business communities

with regard to a common interpretation of transaction semantics. Therefore,

to bridge the gap, we need to answer two research questions: how to specify

proper transaction support and how to ensure them.

We have proposed the concept of TxQoS (Transactional Quality of Ser-

vice), which means the transactional performance of services that should be

agreed as well as other performance indicators. Applying the contracting

perspective in a service oriented context, we view Service Level Agreement

(SLA) as a variation of e-contract that carries technical semantics in a busi-

ness vehicle. Thereby, we proposed the TxQoS-SLA-Contract structure to

enclose the transactional agreements in service contracts. To support this

idea, we developed the mapping and matching model to bridge the gap be-

tween IT and business communities. Vertically, the mappings from the low

level IT infrastructure of an organization enable the transforming from tech-

nical transaction terms to business transaction terms. Therefore the horizon-

tal matching of proper TxQoS between organizations in the external busi-

ness level is enabled. A terminology to realize the mapping and matching is

also suggested. With these initial steps towards a TxQoS framework, which

eventually compliments our ATC (Abstract Transaction Construct) based

business transaction framework, we aim to address transaction management

issues by a contractual approach. Thus, the reliability problem in contract-

driven, service-oriented business processes is tackled from both technical and

business aspects.

Based on the result discovered from the case analysis, in this paper we

further present the full picture of of the TxQoS framework. As positioned

in the service oriented context, we propose our TxQoS scenario under the

impact of SOA (service oriented architecture). As the basic SOA shows, in

our scenario, there are also three types of parties, provider, user and inter-

mediaries. A provider provides a service with differentiated TxQoS offers

for potential users to choose from. A user takes one offer from the provider,

usually through an advertising intermediary. There can be various interme-

5

diaries involved in the TxQoS scenario. According to different trust and/or

business complexity levels between the TxQoS users and providers, these

intermediaries provide four types of functions: advertising, reputation man-

agement, TxQoS monitoring, and dispute arbitrator. Please note that in

few cases where the trust is high enough between the provider and user (e.g.

they belong to one organization), there may be no intermediaries at all in the

TxQoS scenario. We also identify different phases of the TxQoS lifecycle to

explain how the scenario works and propose the TxQoS specification method

that can be operationalized for later monitoring. Furthermore, in this paper

we refine the TxQoS framework proposed in the case analysis report with an

improved architecture, a deepened mapping and matching mechanism, and

a method to monitor the runtime TxQoS attributes. The architecture shows

the modules needed at each party to enable the TxQoS scenario. The map-

ping and matching model reveals how the TxSLA establishment between a

provider and a user is realized through the mutually understandable TxQoS

terminology. The monitoring method provides the guidelines to collect the

runtime statistics to evaluate the TxQoS performance. With the in-depth

investigation of various aspects, we aim to deliver a TxQoS-aware business

transaction framework that is feasible, extensible and effective.

The rest of the paper is organized as follows. We present the context,

motivation and goal of our research in Section 2, where we discuss SOA

and its impact on and relation with our TxQoS approach. Also we briefly

introduce the basic TxQoS concepts we have developed so far. Next, we

describe the TxQoS scenario and explain in general the complete picture in

Section 3. In Section 4 we explain how our TxQoS approach works in detail,

such as the mapping model and monitoring method. After that we discuss

the related work in Section 5. The paper ends with conclusions and future

work in Section 6.

6

2 Research Background

Driven by the need for a comprehensive and flexible transactional support

to guarantee reliability for complex processes composed of services, we carry

out the XTC project which aims at laying a generic foundation to the trans-

actional support for processes in the contract-driven and service-oriented

environment by means of a Business Transaction Framework (BTF). One

step toward this goal is to abstract the existing transaction models into Ab-

stract Transaction Constructs (ATCs) and hide their implementation details

that may reside in heterogeneous infrastructures [Wang 06]. According to

the service composition, the needed ATCs are selected to compose a transac-

tion scheme, therefore on-demand transaction support is provided. Besides

flexibility and comprehensiveness enabled by ATCs, we also investigate how

to relate transaction management to contractual support for business trust-

worthiness. Towards this direction, we intend to address the QoS part of

transactions in the context of the XTC project.

2.1 SOA

The optimal integration of distributed IT resources to meet agile business

requirements has long been a challenge. Many efforts have been made to-

wards a cost-effective, easy-to-implement solution to address the challenge

along with increasingly complex business processes. One popular solution is

SOA. According to the OASIS definition, SOA is ’a paradigm for organiz-

ing and utilizing distributed capabilities that may be under the control of

different ownership domains. It provides a uniform means to offer, discover,

interact with and use capabilities to produce desired effects consistent with

measurable preconditions and expectations.’ The basic service oriented ar-

chitecture shown in Figure 1 illustrates how parties interact with each other

to enable a service lifecycle from publish until invocation. If implemented

in Web service technology, the distributed capabilities are published as Web

services for users to invoke using standardized Web services protocols such

as SOAP, WSDL and UDDI.

The basic SOA in Figure 1 is limited for more and more complex business

7

ServiceProvider

Publish

FeedbackDeli

ver

Invo

cate

LeverageDisplay

ServiceIntermediary

ServiceUser

Figure 1: Basic service oriented architecture

environment which demands for extensive properties to compose and manage

services such as security, management etc. Therefore a few extended SOAs

have been proposed. One of the most accepted SOA is a pyramid architecture

proposed in [Papa 03], as shown in Figure 2, which illustrates a broader

scenario involving various service roles and their interactions. Besides, it

reveals a layered architecture identifying the topics in each layer. According

to the authors, transaction management is positioned in the middle layer

of the pyramid for a reliable service composition. Although there have been

Figure 2: An extended service oriented architecture [Papa 03]

8

continuous efforts to address reliability concern, transaction management still

remains a grand challenge in service composition [Papa 06]. Also we can see

from the pyramid that SLA is positioned in the top layer, and QoS topic is

outlined in both middle and bottom layters.

In this paper we position the research of a contractual approach for trans-

action management, TxQoS, in the SOA context. In our approach, we inherit

the concepts such as ‘party’, ’SLA’

2.2 TxQoS Proposal

In our previous report, two questions for our TxQoS research have been

identified: 1)How to specify proper transaction support? 2)How to ensure

these transaction requirements? Here we briefly introduce the basic con-

cepts proposed and more details can be found in the report [Wang 07]. To

address transaction management issues in SOA, we have proposed a contrac-

tual approach after a case analysis. Our proposed approach spans service

composition and service management layers of the SOA pyramid in Figure 2.

A unique feature of our approach is the focus on business semantics instead

of technical mechanisms. As shown in Figure 3, the basic idea of our TxQoS

approach is to interpret transactional properties as TxQoS attributes and

ensure them by means of a service contract containing a TxSLA, in which an

Service Contract

Party A Party B

Date.Venue.Signature

Article 1

η 1.1 ...η 1.N ...

η What the provider is promisingη How the provider will deliver on those promisesη Who will measure delivery, and howη What happens if the provider fails promisesη How the SLA will change over timeη ...

Article 2

η 2.1 ...η ...

Article N

η N.1 ...ηη ...

SLA(s)

SLA

η Transactional reliability η TxQoS specificationη Measurementη Agreed penaltyη Appendix

TxSLA

η External-levelη Conceptual-level η Internal-levelη Mappings

TxQoS Specification

Figure 3: TxQoS agreement

9

unambiguous TxQoS specification plays the key role as the communication

bridge.

A mapping and matching model to realize the unambiguous interpreta-

tion and agreement has been developed, which conforms to the three-level

framework developed in [Gref 03], where external, conceptual and internal

levels are identified for business collaboration purpose. Mapping exists be-

tween the external level where transactional reliability concern is expressed

by business terminology, and the internal level where transaction manage-

ment mechanisms are expressed in technical terminology. Matching means

the bridge between the external-level transaction requirements and offers. In

this mapping and matching model, a terminology to enable the mutual under-

standing of transactional reliability is essential for the TxQoS specification.

At the conceptual level of a business process, a TxQoS terminology should

avoid technical jargons used to describe the internal level transaction mech-

anisms. At the external level, such terminology should be understandable by

both parties to enable the matching of TxQoS offers and requirements, as

well as the subsequent establishing of TxQoS agreement. Thus, an external-

level transactional reliability using TxQoS terminology could encapsulate the

lower-level transaction properties that are usually too technical-specific for

business-level understanding. We have identified four external-level TxQoS

attributes: Fluency; Alternation; Transparency; Interferability. These at-

tributes can be mapped to the conceptual-level TxQoS attributes where real

transactional properties and mechanisms are concerned, such as ACIDity, re-

covery and compensation. These conceptual-level TxQoS attributes in turn

are mapped to the internal-level transaction protocols (e.g. two phase com-

mit) which take place at databases.

Following the above research direction, in next sections we go further

from two dimensions. First, we present an overview scenario of the TxQoS

approach to illustrate the ingredients in our approach and how it works. We

discuss the details of the TxQoS scenario such as the parties, phases and

data objects involved. Second, we refine the existing TxQoS framework in

all aspects including the architecture, the mapping and matching model, and

the monitoring mechanism.

10

3 TxQoS Overview

As shown in Figure 4, the TxQoS overview scenario also contains three par-

ties, as in the basic SOA in Figure 1. Here we discuss their interactions

following the TxQoS proposal introduced in the previous section, assuming

that the basic responsibilities of the parties (e.g. publish, deliver, lever-

age) have been fulfilled. We notice that, in the SOA pyramid in Figure 2,

there appeared five parties: service provider, service client, service operator,

market-maker and service aggregator. The later three parties do not appear

in our TxQoS scenario, as we category all the auxiliary parties as interme-

diaries. Please note that our scenario describe the non-functional aspects of

services that address the QoS and SLA issues outlined by the SOA pyramid.

In the TxQoS scenario, a provider offers differentiated TxQoS specifica-

tion for its service to match the TxQoS requirements from various service

users. In common cases, a user searches in the TxQoS performance repos-

itory of an advertising intermediary to decide which offer to take. There

Intermediary(s)

AdvertiserReputation

checkerArbitrator

User

Monitoring module

Provider

Monitoring module

Monitoring module

Monitor

TxQoSPerformance

Report

PerformanceRepository

TxQoSTemplate TxQoS

Offer

TxQoSStatistics

Differentiate

Use

TxQoSRequirement

InstantiateRequirements

TemplateRequirements

TemplateRequirements

Template

Feedback

Provide

Match

Customize

UseEvaluate

TxSLA

Figure 4: TxQoS Scenario

11

can be negotiations between a provider and a user when no ready-to-agree

TxQoS specification is suitable. After an agreement on TxQoS (TxSLA) is

reached, monitoring the actual running transaction performance and check-

ing the compliance with the TxSLA take place. The monitoring module

performs the monitoring task and can be a part of service provider, user

and/or intermediary. Different from the optional intermediaries, this mod-

ule is indispensable to fulfill a TxQoS lifecycle and should be provided by

at least one party. In other words, monitoring the established TxSLA is a

compulsory task, but can be performed by any of the involved parties. In

case either a provider or a user is not assured by its partner, a trusted inter-

mediary is delegated to monitor the runtime TxQoS statistics and make use

of the statistics for transactional performance records and analysis. In case

a provider or a user has established its authority, the monitoring task can

be performed by the authorized party and an intermediary is skipped. The

intermediary(s) which provide the other auxiliary functions (i.e. advertising,

reputation checking, arbitrating) can be omitted from the scenario, where

the provider and user are tightly coupled. In such a rare case, the trust

between them has been built up so that the already familiar parties have no

need to call for intermediaries to approve each other.

3.1 TxQoS Participants

As we see from the complete TxQoS scenario, there are three parties: TxQoS

provider, TxQoS user and TxQoS intermediary.

TxQoS provider A TxQoS provider offers differentiated TxQoS specifica-

tions for a particular service it publishes. Take a travel booking service

for example, where the service can be associated with different levels

of transactional reliability ensured by corresponding TxQoS specifica-

tions. One TxQoS specification offers a super fluent service execution

(e.g. always provide compensations for every step and never shut down

as long as the service instance is being open), which is specifically

provided to its registered users. Another TxQoS specification offers

12

standard service execution (e.g. time-out settings that may entail a

new invocation), which is provided for random visitors.

TxQoS user A TxQoS user is a service invoker who intends to discover

a suitable service with an appropriate level of transactional reliabil-

ity according to its transactional requirements. Using the same travel

booking example, a service user with a specific travel plan to implement

within a certain time usually has more requirements towards TxQoS

than a happen-to-visit browser.

TxQoS intermediary A TxQoS intermediary is a third party which mon-

itors the ongoing service to collect and store TxQoS statistics; or an

advertising service provider which publishes TxQoS advertisement for

potential users; or a trusted reputation broker which records the past

transactional performance of a list of services and may predict the fu-

ture performance for users to check; or an arbitrator which settles dis-

pute when the agreed TxQoS is breached. Note that an intermediary

does not provide direct business functions as a service provider does. In

contrast, it serves as an auxiliary role to enable and facilitate TxQoS

agreements. The enabling and facilitating tasks can be advertising,

reputation repository, post-service functions such as sending statistics

and feedbacks of the actual TxQoS performance etc.

3.2 TxQoS Lifecyle

For any particular service, a complete TxQoS lifecycle comprises 4 phases

spanning service design time, service execution time and post-execution time.

1. Design phase, during which a service provider defines the TxQoS tem-

plate of its service and offers one ore more TxQoS specifications based

on the template. The differentiated offers are designed based on the

past TxQoS performance of its service and the analysis of users’ re-

quirements so that various user requirements can be catered. A TxQoS

offer can be pre-fixed with every attribute configured by the provider,

or user-configurable with some attributes customized by the potential

13

user. Also in this phase, a service user may (optionally) design a TxQoS

requirement template for a service according to its own transactional

needs. In this case, usually one requirement template is instantiated

into one requirement document at the user side, in contrast to the

provider side, where one TxQoS template is instantiated into multiple

offers. This is because a user usually has the same requirement ev-

ery time it invokes a service, and one service is usually designed for

multiple users to invoke. In this phase, the mapping between transac-

tion mechanisms at the internal level and TxQoS specification at the

external level is actually taking place.

2. Match phase, during which a TxQoS offer matches a TxQoS require-

ment document. A service user can use an intermediary to look up the

transactional performance of a particular service it has interest in. Or

a user can search in its own history records to directly choose a service

provider with which it has established a business relationship in the

past. After a search, the user then decides which service to invoke,

and which TxQoS offer to take if the service has differentiated TxQoS

offers. Note that the proper interpretation of transactional needs in the

TxQoS requirement document is usually not exactly satisfiable from the

available TxQoS offers. In this case some negotiations are necessary,

however this happens during the next phase.

3. Contract phase, during which a provider and a user establish a TxQoS

agreement (named TxSLA). As 100 percent precise match is not always

possible, negotiations may be involved in this phase. For pre-fixed

TxQoS offers, a user may need to adjust its requirement and take one

that fits the best. The decision making for this adjustment is based

on the weight of different TxQoS attributes (i.e. the least important

requirement can be relaxed the first). For configurable offers, a user

has the power to configure a best fit so that an ideal offer is tailored in

particular to its requirements.

4. Evaluate phase, during which a TxSLA is monitored and managed by

14

both parties, or by a delegated intermediary. This phase encompasses

both the service execution period during which real-time statistics is

generated and recorded, and the post-execution period during which its

transactional performance is evaluated. In the scenario where an inter-

mediary is involved, each TxQoS agreement is monitored in real-time

and multiple monitoring statistics are aggregated into one performance

report, which describes the transactional reliability of the service re-

ferred in the agreement based on its past performances for evaluation

purpose. The performance reports are usually stored in a repository

and updated from time to time. These reports are available for outside

access so that potential users can search a most suitable service offer ac-

cording to their transactional requirements, and meanwhile, providers

can adjust their TxQoS templates and differentiated offers.

3.3 TxQoS Data Model

There are quite a few data objects (e.g. messages, documents, agreements)

flowing between the parties along the TxQoS lifecycle. As a clarification, the

data objects and their relations are depicted in Figure 5.

TxQoS template is a base document maintained by a service provider

to define the TxQoS attributes of its service. Usually the values are not

assigned for future configuration to produce differentiated TxQoS offers.

TxQoS offer is a configured TxQoS template with part or all the values

TxQoS RequirementTxQoS Template

Performance Report

Requirement TemplateTxQoS Offer

Service Contract

TxQoS Spec.

1 *

*1

TxQoS Statistics

1*

TxSLA

**

*1

***

*

**

Figure 5: Class Diagram: TxQoS Data

15

of TxQoS attributes described clearly by a service provider, and published

by an advertising intermediary.

Requirement template is a base document maintained by a service

user according to its TxQoS requirements arise from its process.

TxQoS requirement is a configured requirement template for a service

with desired (range of) values of TxQoS attributes in search for a suitable

offer.

TxQoS specification is a document specifying the TxQoS attributes,

the values of these attributes and the related monitoring and management

issues.

TxSLA is an agreement contained in a service contract specifying TxQoS

performance.

TxQoS statistics describe the runtime performance of TxSLA, collected

and afterwards recorded by a monitor.

TxQoS performance report is the analysis based on the aggregation

of history TxQoS statistics of a service.

As we can see from Figure 5, a TxQoS specification is the key element

for the other data objects. We have developed four TxQoS attributes for

specification and monitoring purposes: fluency, alternation, transparency,

and interfererability. A causal-effect diagram in Figure 6 shows the factors

that affect TxQoS attributes and the dependencies between these attributes.

These causes are identified under three categories: non-system, system and

TxQoS. The ‘non-system’ category contains the factors that belong to the

business domain while the ‘system’ category contains the factors from the

technical domain. The ‘TxQoS’ category reveals the dependencies among

these TxQoS attributes. For example, we can see that the fluency attribute

is dependent to the complexity of the service i.e. the more complex a service,

the lower its fluency can be. Fluency also relates to the system constraints

such as latency time due to network traffic, capacity due to the bandwidth,

and availability due to the hardware reliability. Meanwhile fluency can affect

transparency and interferability, and vice versa.

16

TransparencyTransparency

SystemSystemNon-systemNon-system

TxQoSTxQoS

Compensation

Requirement

Interferability

Duration

InterferabilityInterferability

SystemSystemNon-systemNon-system

TxQoSTxQoS

RecoveryRequirement

TransparencyFluency

AlternationAlternation

SystemSystemNon-systemNon-system

TxQoSTxQoS

Compensation

RecoveryRequirement

Complexity

Interferability

Duration

FluencyFluency

SystemSystemNon-systemNon-system

TxQoSTxQoS

CapacityAvailability

LatencyComplexity

TransparencyInterferability

Figure 6: Categories of TxQoS attributes

3.4 TxQoS Specification

If a TxSLA is agreed by both parties, it should meanwhile specify the metrics

and measurement of the TxQoS specification at both sides. This requires a

clear and precise definition of TxQoS attributes. So far we have defined four

TxQoS attributes. Here we discuss how to specify them in a precise manner

during the ‘design’ phase, so they can be monitored at the ‘evaluate’ phase.

We discuss the specification method to demonstrate the idea of developing

the four TxQoS attributes for contracting purposes are able to be realized

in practice. The detailed specification language and algorism are needed in

implementation stage but left out in this report, as we aim to introduce the

concept, scenario and framework of the TxQoS proposal. Below we present

the reasoning of the specification method for each attribute one by one:

Fluency: When a service is being executed, a monitor detects errors

and failures that break the ongoing execution by counting the number of the

breakdowns and recording their time stamps. After the execution, the flu-

ency indicators (e.g. a function) are recalculated. In this paper a breakdown

is caused by an unexpected exception/error that suspends the service exe-

cution and results in a fix to enable continuing execution. In case a service

execution is canceled by a user, it is counted as an expected failure/error,

17

not a breakdown, and therefore belongs to the attribute of interferability.

Theoretically, if we assume that breakdowns happen stochastically and

meet the following two conditions: (1) No simultaneous breakdowns can

happen at any time; (2) the causes of the past breakdowns are fixed and do

not affect future execution, then we can view the service execution a Non-

Homogeneous Poisson Process (NHPP). A NHPP is a generalization of a

Homogeneous Poisson Process where events occur randomly over time at an

average rate of λ events per unit time. The rate λ varies with time as deter-

mined by the intensity function λ(t), which is an integrable function of time

interval (0, t]. The cumulative intensity function Λ(t), which is interpreted

as the expected number of events from starting time 0 by time t, is defined

by [Cinl 75]

Λ(t) =∫ t

0λ(τ)d(τ), t > 0 (1)

The exact events occurring in the interval (a, b] is given by

Λ(a, b] =∫ b

aλ(t)d(t), b > a > 0 (2)

Therefore, according to (2), the probability of exact n events occurring

in the interval (a, b] is given by

P (n) =

[∫ ba λ(t)d(t)

]n

e−∫ b

aλ(t)d(t)

n!, for n = 0, 1, . . . (3)

If we view each breakdown as an event, and use the past statistics to

determine the intensity function λ(t), (breakdown happening rate), then in

theory a prediction of the fluency attribute in the next execution can be com-

puted. Depending on the service characteristics, the breakdown happening

rates can vary. For example, a few extensive NHHP models using different

λ(t) computation techniques have been proposed using different intensity

18

function in the area of software reliability, such as GO NHPP [Goel 79], De-

layed S-shaped NHPP [Yama 83], Inflection S-shaped NHPP [Ohba 84]. It

is up to the provider to choose the most appropriate one that interprets the

real testing data and can be adjusted according the runtime statistics.

For example, suppose a service that should be executed within time

T (T = max(t)), any execution not committed after T is viewed as a fail-

ure and is excluded in the fluency statistics. During the test, it shows the

breakdown rate λ(t) is a constant so that the GO NHPP model is adopted.

The mean value function of λ(t) is given by

λ(t) = m(1− e−rt), (4)

where λ(0) = 0, and m is the number of breakdowns that will be eventu-

ally detected and r is the breakdown detection rate. If we define the fluency

function f(n) as the probability of having no more than n breakdowns during

execution (i.e. within the time interval (0, T ]), according to (3), f(n) can be

calculated as

f(n) =∑

P (n) =∑

[∫ T0 m(1− e−rt)d(t)

]n

e−∫ T

0m(1−e−rt)d(t)

n!(5)

According to (4), we replace the λ(t) by m(1− e−rt) to calculate function

f(n) with variables m and r:

f(n) =∑

[m(T + e−rT−1

r)]n

e−m(T+ e−rT−1r

)

n!(6)

This way f(n) can be calculated based on the testing statistics. For

instance, f(0) means the probability of having no breakdowns during service

execution and can be used to specify the maximum fluency. Similarly, f(1)

means the possibility to have at most 1 breakdown during service execution.

19

Usually in TxQoS offers, the provider can provide various fluency guarantees

by means of fluency function values (i.e. f(n)). For example, if computation

result shows that f(0) = 0.8146, f(1) = 0.9235, f(2) = 0.9992, then an offer

can be specified as ‘we guarantee no more than 2 breakdowns during the

execution’, while another can be specified as ‘we guarantee no breakdowns

during the execution at the cost x ’.

Alternation: The alternation attribute describes the choices that are

pre-defined in case of breakdowns during the service/process execution. Dur-

ing the design phase, the attribute of alternation is defined as a set of allowed

execution graphs. At runtime, if a breakdown occurs which deviates the orig-

inal execution path to an alternative path, a monitor detects the current path

and compares with the predefined set of graphs. Every pre-defined alterna-

tive path can be specified using a graph. For example, imagine there is a

service s consisting of activities A,B,C,D,E with the order of execution as

A C

D

EB

We define ‘N = {nodes} ⊆ X’ as the domain of activities, and ‘E =

{edges} = {〈nodem, noden〉 ∈ X × X}’ as the domain of edges, then ‘G =

〈N, E〉’ is the execution graph of the activities in the domain X. Correspond-

ingly, the above execution graph Gsis specified as

Gs = 〈{A,B,C, D,E}, {〈A,B〉, 〈B,C〉, 〈B, D〉, 〈C,E〉, 〈D, E〉}〉

Here, ‘{A,B, C, D, E}’ defines five nodes in the graph that represents the

activities in this service that need to be executed, and ‘〈node1, node2〉(nodex ∈{A,B,C, D,E})’ defines an edge of the graph that represents the execution

path from ‘node1’ to ‘node2’. In case a breakdown happens during the exe-

cution of the activity C or D, it is expected that an alternative activity P

or Q is executed to cover the loss. Therefore, the alternative paths Ga can

20

be specified as

Ga1 = 〈{A,B, P, D, E}, {〈A,B〉, 〈B, P 〉, 〈B, D〉, 〈P,E〉, 〈D, E〉}〉Ga2 = 〈{A,B, C,Q, E}, {〈A,B〉, 〈B, C〉, 〈B,Q〉, 〈C, E〉, 〈Q, E〉}〉Ga3 = 〈{A,B, P, Q, E}, {〈A,B〉, 〈B, P 〉, 〈B,Q〉, 〈P, E〉, 〈Q, E〉}〉

The above example indicates that three situations might occur: Ga1 is

chosen if C can not be committed, so that P is adopted as an alternative

node; Ga2 is chosen if D can not be committed, so that Q is adopted as

an alternative node; Ga3 is chosen if both C and D can not be committed,

so that P and Q are adopted respectively as the alternative nodes. This

way, the predefined graphs representing the agreed execution path and al-

ternative paths can be precisely specified, which enables the later automatic

monitoring of alternation attribute. If the monitor detects during runtime

that the on-going path graph contains an unspecified edge ‘〈C,D〉’, a message

is generated to notice such an error.

Transparency: The transparency attribute describes the visibility of a

service/process. The specification of transparency can be the set of the activ-

ities that are visible during execution. Using the above example where a ser-

vice has five activities and two optional compensating activities, if activities

‘C, D, P , Q’ are allowed to be visible, then we can specify the transparency

set Nt as

Nt = {C,D, P, Q} ⊆ X X = {A,B,C,D,E, P,Q}

This is the only one of the four TxQoS attributes that only need to be

specified without runtime monitoring. We assume that the monitor keeps a

log of each instance execution status and parameters. If a user complains

that an activity specified in the TxSLA as transparent was not visible, then

the log is needed to settle the dispute.

Interferability: The interferability attribute describes the control pos-

sibility of the activities by service users. The specification of interferability

can be the set of commands from the user to intervene the service execution,

together with the timings of these commands that are allowed. Note that a

21

user only has interferability to the activities that are specified as transparent.

These commands are actually a set of operations on a transparent activity

that can be specified as functions with the parameters time and activity:

C = {operation(time, activity)}, activity ∈ Nt time ∈ {Rules}

Timing rules can be specified in two ways. One adopts absolute machine

times such as ‘before 10:00 ’, another adopts relative times which invoke tim-

ing functions to indicate the semantics such as ‘after the execution of activity

N, but before the execution of the activity M ’. Again we use the service s as

an example, where ‘C,D, P, Q’ are transparent activities. Suppose D is the

activity that allows user intervention to cancel after it has started and the

next node E starts. This interferability attribute can be specified as:

C = {cancel(getProgress(D) = 0.5 ∩ getProgress(E) = 0, D)}

In the above specification, the function getProgress(N) invokes the sys-

tem function to detect the execution status of the node N ∈ X. The re-

turn parameter can be set for example like ‘0=not started, 1=commited,

0.5=started but not committed ’. The above example shows a specified inter-

ferability attribute as a rule ‘the user has the right to cancel the activity D

at any time during its execution’. During runtime, when the monitor detects

a cancel command from the user at the time when activity E has started, it

judges the command as an invalid one and generates a warning. This way,

the monitor can filter every user command and pass it to the underlying

system when it conforms with the TxSLA and block the invalid commands.

22

4 TxQoS Framework

4.1 Architecture

To support the scenario in Figure 4, we propose the architecture in Figure 7.

This architecture includes all the basic functional components of a TxQoS

manager, which is built on top of a business process engine. The design may

be further decomposed and refined as a guideline for the implementation.

The monitor is compulsory in the scenario but optional for each of the

three parties. Therefore, we depict it as a dashed box and make it an op-

tional component at each side. A monitor is a module for runtime compliance

checking of the TxQoS specification cording to agreed TxSLA. Within the

TxQoS manager at both provider and user sides, there are tools for TxQoS

template definition, TxQoS configuration and contracting. The intermedi-

ary(s) support TxQoS advertising, reputation checking, arbitrating, and/or

monitoring functions as a trusted third party. An advertising intermediary

publishes all TxQoS offers for users to choose a particular service; a repu-

tation intermediary keeps a repository to provide transactional performance

analysis of different services from various providers so that potential users

can approve a provider. An arbitrating intermediary is used when there is

any dispute between the providers and users.

Business Process Engine

ArbitratorReputation

RegistryAdvertiser

TxQoS Manager

Configuration Tool

Definition Tool

Contracting Tool

Provider

Monitor

Monitor

Intermediary(s)

Business Process Engine

TxQoS Manager

Configuration Tool

Definition Tool

Contracting Tool

Monitor

User

Figure 7: TxQoS architecture

23

4.2 Mapping and Match

An ideal situation to reach a mutually satisfied agreement on transactional

reliability is realized in three steps. First, the provider maps the transac-

tional mechanisms of its internal level to the conceptual-level transactional

properties, and then interpreted into a TxQoS template which can be con-

figured into multiple offers to cater for various needs at the external level.

Second, the user figures out its TxQoS requirement document instantiated

from its requirement template. This requirement template is based on the

process reliability analyzed from the process specification at its internal level.

Third, the user discovers a suitable service by matching its transactional re-

quirement document to a provider’s TxQoS offer, usually facilitated through

an advertising intermediary. Note that the first step and the second step are

independent and can take place at the same time. The third step happens

after the first two steps are finished.

We propose the mapping and matching model shown in Figure 8. From

the provider side, it offers at the external level multiple TxQoS offers of its

service. Or there can exist different providers at a time to choose from.

This way a service user can choose a service provider with the most suitable

TxQoS offer based on its TxQoS requirement. There are mappings at each

side between the internal level and the conceptual level, and between the

conceptual level and the external level. With the mappings, the transac-

External Level

Conceptual Level

Internal Level

Provider User

TxQoSrequirement

TxQoS offers

Matching

TxSLA

Process reliability

Transaction properties

mappingmapping

Transaction mechanisms

Process specification

Figure 8: TxQoS mapping and matching

24

tion properties (e.g. ACIDity) are translated into the external-level TxQoS

terminology. At the external level, there is a match of the TxQoS which

results in an agreed TxSLA between the provider and the consumer. In the

contract-driven service-oriented processes, the agreed TxSLA is included into

a service contract and ensured by the contracting systems.

Our proposed TxQoS mapping (vertically) between process levels and

matching (horizontally) between the service user and provider are the first

step towards identifying and interpreting transactional requirements and of-

fers. To achieve a successful mapping, we need to investigate the relation-

ships between transactional properties in technical terms (e.g. ACIDity) and

TxQoS in business terms (e.g. fluency). For instance, if the execution time of

an service is very short, this service may be assigned ACIDity. While in the

case that the intermediate result of an service is visible and allows for inter-

ference from outside, ACIDity is not appropriate anymore. An ACID service

is supposed to have high fluency. After a mapping, the essential step leading

to the establishment of a service contract is the match of a user’s require-

ment with the most suitable offer from a provider’s multiple TxQoS offers at

the external level. Here we assume that the e-contracting system supports

the automation of contract fulfillment. Because of these TxQoS enabled e-

contracts, a user can have better understanding of how much transaction

reliability a service guarantees.

4.3 Monitoring

As the architecture implies, a monitor monitoring the agreed TxSLA at run-

time is indispensable for a complete TxQoS framework. For conceptual-

level TxQoS (e.g. ACIDity, compensation etc.), it is possible to monitor

with various available transaction monitoring technologies and tools such as

[Bern 90, Zaik 99]. However, such monitoring is missing for the external-

level TxQoS attributes(e.g. Fluency, Visibility etc.). According to Figure 4,

we assume that for any service, the TxQoS attributes have been specified

unambiguously in the TxQoS offers. This means the agreed values of the

TxQoS attributes in the TxSLA should always be valid from the time a ser-

25

TxQoS performance

report

TxQoSOffer

TxQoSStatistics

TxQoS Template

TxSLA

Design phaseMatch&contract

phases Evaluate phase

Figure 9: TxQoS monitoring

vice provider publishes a service until the end of the service lifecycle (i.e. the

time a provider updates or closes the service). Figure 9 shows the monitoring

mechanism of the TxQoS framework throughout the lifecycle. The objects

monitored are the running instances of a particular service. A monitor is

delegated to detect if there are any inconformities with the agreed TxSLAs

during runtime. Note that, before publishing the service, the provider usually

estimates the future possible performance of the TxQoS attributes accord-

ing to its testing and possibility computation. After publishing, the design

template of the TxQoS offers at the provider side can be adjusted based on

the TxQoS performance report aggregated by the runtime statistics of all

monitored service instances during the past (or between any certain time

intervals). On one hand, monitoring mechanism enables the provider to offer

TxQoS guarantees more confidently. On the other hand, a user can compare

different service offers with objective references from an authorized monitor

for a best match and protect their rights by means of a TxSLA agreed before

service execution. If any dispute arises during or after the service execution,

the monitor can provide the relevant statistics for a fair settlement.

The accumulated runtime monitoring data of the TxQoS attributes for

multiple service instances are aggregated and recorded into a TxQoS per-

formance report, and all the TxQoS performance reports are stored in a

repository, which can be accessed by the provider and the users, and/or

26

other intermediary(s). A TxQoS performance report can be updated upon

the execution of one or multiple service instances. We have discussed the

TxQoS lifecycle that consists of 4 phases in Section 3.2. Here we summarize

the monitoring related steps throughout the lifecycle (e.g. predict, specify,

monitor, evaluate) with regard to the TxQoS attributes agreed in a TxSLA:

Design phase A provider designs a service and run some tests before pub-

lishing it. Based on the testing data, a TxQoS offer template is de-

signed. The information on fluency, such as the maximum, the mini-

mum, the average fluency value, and the way to compute the function

f(p) etc., is used to predict the future performance. For the other at-

tributes, the testing data can also be used to instantiate various offers

that are well under the control (i.e. safe for the provider).

Match and Contract phase A service user chooses one of the TxQoS of-

fers based on its requirement document. A TxSLA is then agreed and

enclosed in a service contract. Negotiation may take place if no exact

match exists, especially for the attributes of ‘transparency’ and ‘inter-

ferability’ which define the control a user has for a service.

Evaluate phase The service starts to run and a monitor authorized by both

parties monitors the ongoing TxQoS statistics and compares them with

the TxSLA. After execution of this service instance, runtime statistics is

recorded and meanwhile the performance report is updated as the latest

evaluation. The updated report is then stored in a repository for future

discovery. The service provider may accesses the report repository to

adjust its TxQoS offer template and offers. The user may also like to

retrieve the up-to-date TxQoS performance report from the repository

for decision-making. If there is any dispute, the runtime statistics in

the report are used by intermediary(s) as authorized evidence to check

its conformance with the agreed TxSLA.

27

5 Related work

Our research addressing the contractual part of a business transaction frame-

work in SOA (Service-Oriented Architecture) is a novel approach that relates

transaction management to QoS, SLA and e-contracting areas. Past research

in the transaction management area usually presents a transaction model or

framework that is suitable for some specific application domain [Wang 05]

and few of them can be understood by the business community. QoS and

SLA are originally proposed to enhance network-level reliability with regard

to traffic management, message routing etc. As reliability is attracting more

and more attention, together with transaction management, QoS issues be-

come increasingly critical in the upper layers of SOA (e.g. service composi-

tion and management). However, people separately view the reliability guar-

anteed by transaction management from the reliability guaranteed by QoS

management. Therefore, we bridge the gap with a QoS-aware transactional

mechanism.

The concept of TxQoS first appeared in [Mani 02], in which the authors

discuss the overall QoS support for Web services. These QoS properties that

are needed for implementation of Web service applications include availabil-

ity, accessibility, integrity, performance, reliability, regulatory and security.

However they only mentioned the TxQoS term briefly without a further ex-

planation of how it should be defined and used. Another research effort

with a similar direction but in a different application domain is the QoS-

aware transaction processing framework for mobile transactions proposed in

[Xie 03]. The authors propose to assign the transaction service in multiple

modes depending on the situation of network traffic, computing and power

resources. While our approach of using TxQoS specification is not limited to

any particular type of transactions.

It is pointed out in [Simo 06] that formal XML descriptions in the Web

services area is not directly useful to business. The notion of a service meta-

data document is invented which contains both business aspects and techni-

cal artifacts so that the two communities work collaboratively on a common

framework. The authors propose a service contract template for their purpose

28

of bridging the gap of the two communities. Following this thought, we have

defined the service contract concept as a group of contracts which combine

business clauses and SLAs in the last report. As our work concerns SLAs, it

has some similarities with the WSLA (Web Service Level Agreement) frame-

work [IBM 04], which addresses SLA issues in a Web Services environment

on SLA specification, creation and monitoring. The WSLA project is aimed

at unambiguous and clear specification of SLAs that can be monitored via a

distributed monitoring framework, and an XML schema to represent WSLAs.

The monitoring framework allows provider components and third party ser-

vices to perform the measurement and supervision activities. However, our

particular interest for SLAs is focused on transactional aspect and the con-

text of using SLAs is not limited to Web services environment. For instance,

the WSLA language may well define normal Web services QoS but seems

too limited for the expression of transactional semantics. With regard to

the specification language for our proposed service contracts, we consider

leveraging or extending existing e-contracting languages. For example, there

are some e-contracting languages proposed in [Ange 06, Berr 05], but none

is widely adopted to our best knowledge.

Another standardization effort that may be used and extended is WS-

Policy [IBM 06], a general framework to specify and communicate policies

for Web services which allows for expressing the capabilities, requirements

and characteristics of a web service as policies through a set of extensible

constructs. WS-Policy provides a model and syntax to define a policy as a set

of policy alternatives and each alternative contains a set of policy assertions.

Each policy assertion describes an individual requirement, capability or QoS

characteristics. However, it does not concern the attachment to a service and

the discovery of certain policies. While in our work, we consider to assert the

TxQoS characteristics in templates that can be differentiated into multiple

offers and these offers are published through some intermediary for discovery.

29

6 Conclusions and future work

Positioned in the SOA context, we present the overview of the TxQoS sce-

nario. According to different trust and/or business complexity levels be-

tween the TxQoS users and providers, the intermediaries provide four types

of functions: advertising; reputation management; TxQoS monitoring; dis-

pute arbitrator. We also identify four phases of the TxQoS lifecycle and

the data objects flow through the four phases to further explain the TxQoS

scenario and how it works. The specification of the TxQoS attributes is dis-

cussed in detail which enables the later monitoring. To support the complete

TxQoS picture, we propose a framework with an architecture, a refined map-

ping and matching mechanism, and method to monitor the runtime TxQoS

attributes. The architecture shows the modules needed at each party to en-

able the TxQoS scenario. The mapping and matching model reveals how

the TxSLA establishment between a provider and a user is realized through

the mutually understandable TxQoS terminology. The monitoring approach

provides the guidelines to evaluate the runtime TxQoS performance.

The TxQoS concept was proposed from a real-life case study with our ex-

tensive knowledge in the related areas. In this report, we further explore and

complete the initial proposal to enhance transactional reliability by facilitat-

ing communication efficacy between the business and technical communities,

as well as between service providers and service users. The TxQoS scenario

is illustrated with a detailed explanation of various aspects evolving around

the concept. The methods are developed to make the TxQoS approach op-

erational. We believe that the TxQoS approach opens a new and meaningful

direction for today and future’s research in contract-driven service-oriented

business processes.

Our future work falls in two categories. First, we are going to develop a

specification language for the TxQoS attributes. The key to this direction is

a precise metric definition and an expressive XML-based language. Second,

we need to relate the TxQoS approach to our previous Business Transac-

tion Framework, so that eventually a QoS-aware transaction framework for

contract-driven service-oriented business processes is achieved.

30

References

[Ange 06] S. Angelov. Foundations of B2B Electronic Contracting. PhDthesis, Eindhoven University of Technology, 2006.

[Bern 90] P. A. Bernstein. “Transaction Processing Monitors”. Commun.ACM, Vol. 33, No. 11, pp. 75–86, 1990.

[Berr 05] A. Berry and Z. Milosevic. “Extending Choreography with Busi-ness Contract Constraints”. Int. J. Cooperative Inf. Syst., Vol. 14,No. 2-3, pp. 131–179, 2005.

[Cinl 75] E. Cinlar. Introduction to Stochastic Processes. Prentice Hall,Englewood Cliffs, NJ, 1975.

[Goel 79] A. Goel and K. Okumoto. “Time-Dependent Error-DetectionRate Model for Software Reliability and Other Performance Mea-sures”. IEEE Trans. Reliability, Vol. R-28, No. 3, pp. 206–211,1979.

[Gref 03] P. Grefen, H. Ludwig, and S. Angelov. “A Three-Level Frame-work for Process and Data Management of Complex E-Services”.Cooperative Information Systems, Vol. 12, No. 4, pp. 487–531,2003.

[IBM 04] IBM Corp. “Web Service Level Agreements (WSLA) project”.http://www.research.ibm.com/wsla/, 2004.

[IBM 06] IBM Corp. “Web Services Policy Framework”.http://www.ibm.com/developerworks/library/specification/ws-polfram/, 2006.

[Mani 02] A. Mani and A. Nagarajan. “Understanding Quality of Ser-vice for Web Services”. Tech. Rep., IBM DeveloperWorks,2002. http://www-128.ibm.com/developerworks/library/ws-quality.html.

[Ohba 84] M. Ohba. “Software Reliability Analysis Models”. IBM Journalof Research and Development, Vol. 28, No. 4, pp. 428–443, 1984.

[Papa 03] M. Papazoglou and D. Georgakopoulos. “Service-Oriented Com-puting”. Comunications of the ACM, Vol. 46, No. 10, pp. 25–28,2003.

31

[Papa 06] M. P. Papazoglou, P. Traverso, S. Dustdar, F. Leymann, and B. J.Kramer. “Service-Oriented Computing: A Research Roadmap”.In: F. Cubera, B. J. Kramer, and M. P. Papazoglou, Eds.,Service Oriented Computing (SOC), Internationales Begegnungs-und Forschungszentrum fuer Informatik (IBFI), Schloss Dagstuhl,Germany, Dagstuhl, Germany, 2006.

[Simo 06] A. Simon and T. Rischbeck. “Service Contract Template”. In:Procs. of IEEE International Conference on Service Computing(SCC’06), pp. 574–581, IEEE Computer Society, Washington,DC, USA, 2006.

[Wang 05] T. Wang and P. Grefen. “A Historic Survey of Transaction Man-agement from Flat to Grid Transactions”. Tech. Rep., EindhovenUniversity of Technology, 2005. BETA Working Papers 138.

[Wang 06] T. Wang, P. Grefen, and J. Vonk. “Abstract Transaction Con-struct: Building a Transaction Framework for Contract-Driven,Service-Oriented Business Processes.”. In: Proceeding of the 4thInternational Conference on Service Oriented Computing (IC-SOC’06), pp. 434–439, Springer Verlag, 2006.

[Wang 07] T. Wang, P. Grefen, and J. Vonk. “TxQoS: A Case Analysis”.Tech. Rep., Eindhoven University of Technology, 2007. BETAWorking Papers 210.

[Xie 03] W. Xie, S. B. Navathe, and S. Prasad. “Supporting QoS-AwareTransactions in a System on Mobile Devices (SyD)”. In: Proceed-ings of 23rd International Conference on Distributed ComputingSystems Workshops, pp. 498– 502, IEEE Computer Society, 2003.

[Yama 83] S. Yamada, M. Ohba, and S. Osaki. “TS-Shaped ReliabilityGrowth Modeling for Software Error Detection”. IEEE Trans.Reliability, Vol. 32, No. 5, pp. 475–478, 1983.

[Zaik 99] K. A. Zaiken, G. Dehond, and D. Boggs. “Method and Systemfor Defining Transactions from a Database Log”. United StatesPatent 5,907,848, May 1999.

32