SOCA (2007) 1:51–63DOI 10.1007/s11761-007-0002-3

ORIGINAL PAPER

Web services technology in support of business transactions

Michael P. Papazoglou · Benedikt Kratz

Received: 29 October 2006 / Revised: 9 January 2007 / Accepted: 13 January 2007 / Published online: 1 March 2007© Springer-Verlag London Limited 2007

Abstract Advanced business applications typicallyinvolve well-defined business functions such as paymentprocessing, shipping and tracking, determining newproduct offerings, granting/extending credit, managingmarket risk and so on. These reflect commonly standardbusiness functions that apply to a variety of applicationscenarios. Although such business functions drive trans-actional applications between trading partners they arecompletely external to current Web services transactionmechanisms and are only expressed as part of applica-tion logic. To remedy this situation, this paper proposesa business-aware Web services transaction model andsupport mechanisms, which is driven by common busi-ness functions. The model allows expressing businessfunctions such as payment and credit conditions, deliv-ery conditions, business agreements stipulated in SLAs,liabilities and dispute resolution policies. It allows blend-ing these business functions with QoS criteria such assecurity support to guarantee integrity of information,confidentiality, and non-repudiation.

Keywords Web services transactions · Businesstransactions · Business functions · Business protocols ·

Part of this research reported is funded by the DutchOrganization for Scientific Research (NWO) under the projecteXecution of Transactional Contracted Electronic Services(XTC), project No. 612.063.305.

M. P. Papazoglou · B. Kratz (B)INFOLAB, Tilburg University, Dept. of Information Systems& Management, P.O. Box 90153, 5000 LE Tilburg,The Netherlandse-mail: B.Kratz@uvt.nl

M. P. Papazogloue-mail: mikep@uvt.nl

Business process orchestration · Business processintegration · QoS principles

1 Introduction

When business processes span organization boundariesthey pose a number of significant business and tech-nology challenges. First, trading partners need to agreeupon explicit and unambiguous standards that specifyprecisely the data and common business documents,such as purchase orders and invoices, which the dis-parate systems can exchange. Second, and, more impor-tantly, they require loose coupling on the basis of precisebusiness interaction protocols. Such protocols are bynecessity message-centric: they specify the flow of mes-sages representing business activities among tradingpartners (without requiring any specific implementa-tion mechanism). Collectively, business process proto-cols and associated data format and message exchangestandards provide the means for automated, system-to-system exchange of data and messages between tradingpartners. These requirements are common to all appli-cations that involve business processes which span orga-nizational departments and boundaries.

In environments involving business collaborations,business processes are increasingly complex and inte-grated both within internal corporate business functions(e.g., manufacturing, design engineering, sales and mar-keting, and enterprise services) and across the externalsupply chain. In such environments there is a clear needfor advanced business applications to coordinate multi-ple Web services into a multi-step business transaction.This requires that several Web service operations or pro-cesses attain transactional properties reflecting business

52 SOCA (2007) 1:51–63

semantics, which are to be treated as a single logical(atomic) unit of work that can be performed as part ofa business transaction. For example, consider, a man-ufacturer that develops Web service based solutions toautomate the order and delivery business functions withits suppliers as part of a business transaction. The trans-action between the manufacturer and its suppliers mayonly be considered as successful once all products aredelivered to their final destination, which could be daysor even weeks after the placement of the order, andpayment has ensued.

In contrast to Web service transactions, which aredriven by purely technical requirements such as coordi-nation, data consistency, recovery, and so on, businesstransactions are driven by economic needs and theirobjective is accomplished only when the agreed uponconclusion among trading parties is reached, e.g., pay-ment in exchange for goods or services.

This approach requires distilling from the structure ofa business collaboration the key capabilities that mustnecessarily be present in a business transaction and spec-ifying them accurately and independently of any specificimplementation mechanisms. The business transactionthen becomes the framework for expressing detailedoperational business semantics.

Conventional approaches to business transactions,such as Open EDI, the UN/CFACT Modeling Meth-odology (UMM) and ebXML [1], focus only on thedocuments exchanged between partners, rather thancoupling their application interfaces, which inevitablydiffer. The core idea behind this approach is to define alibrary of standard electronic XML business documentssuch as invoices, purchase orders, and ship notices—possibly described in the Universal Business Language(UBL) [2] — to provide an intuitive framework forspecifying the business logic and computations that takeplace on each end of a document exchange. For example,if a customer sends a purchase order to manufacturer,which the manufacturer can fulfill, it will then respondwith an invoice and a shipping notice. How such docu-ments are produced and what actions result when theyare consumed is strictly up to the business at each endof the document exchange.

The previous approach to business transactionsfocuses only on data objects, i.e., documents exchangedbetween partners, and ignores important constituents ina business transaction such as business operations andtheir behavioral semantics. A more natural approach tobusiness transactions is to make common business oper-ational requirements and operational level relationshipsbetween trading partners first class tenets in a busi-ness transaction. This requires providing a common coreof well-understood business operational principles (or

business transaction functions) such as ordering, trans-port, distribution and payment that can be rationalizedand appropriately combined across any supply chainto create semantically enhanced business transactions.Developers can then build transactional applications byusing, combining, and, possibly specializing, these con-structs in a similar way that abstract data types are usedin programming languages.

This paper focuses on introducing an advanced busi-ness transaction model and on providing operationalbusiness principles for specifying business transactionsalong with their QoS characteristics. The approach takenmimics business operational semantics and does notdepend upon underlying technical protocols and imple-mentations. The paper also presents a Business Trans-action Model Language (BTML) that is used at designtime to specify the elements of a business transaction.Run-time support for this environment is provided byconventional Web services standards such as BPEL, WS-Coordination and WS-Transaction and will be brieflyhighlighted in the context of a reference architecture.Detailed descriptions of the run-time environment aswell as run-time transformations between the BTMLand equivalent constructs supported by Web servicestransaction standards are outside the scope of thispaper.

2 Business collaborations and transaction support

One key requirement in making cross-enterprise busi-ness process automation happen is the ability to describethe collaboration aspects of the business processes, suchas commitments and exchange of monetary resources,in a standard form that can be used by applications andconsumed by tools for business process implementationand monitoring.

Business collaborations are usually expressed withreference to business entities that are affected by a busi-ness collaboration activity, e.g., order, goods transfer,and in terms of events that trigger the state transitionsof business entities and of the business collaboration,e.g., delivery of goods triggers the transition of orderline status from pending to fulfilled. Business collabo-rations need to capture the information and messageexchange requirements between trading partners, iden-tifying amongst other things the timing, sequence andpurpose of each business collaboration and informationexchange. This becomes the responsibility of a businessprotocol that defines the ordering in which a particularpartner sends messages to and expects messages fromits partners based on an actual business context.

SOCA (2007) 1:51–63 53

A business protocol captures all behavioral aspectsthat have cross-enterprise business significance. Eachparticipant can then understand and plan for confor-mance to the business protocol without engaging inthe process of human agreement that adds so much tothe difficulty of establishing cross-enterprise automatedbusiness processes.

A business protocol may exhibit the flowing charac-teristics:

1. It invariably includes data-dependent behavior. Forexample, a supply-chain protocol depends on datasuch as the number of line items in an order, the totalvalue of an order, or a deliver-by deadline. Defin-ing business intent in these cases requires the use ofconditional and time-out constructs.

2. It is able to specify exceptional conditions and con-tingency measures and their consequences includingrecovery sequences.

3. It is able to specify cross-partner coordination ofactivity outcomes (success or failure) at various lev-els of granularity.

A business protocol helps to choreograph the flowamong business interactions. This flow depends on thestates of business entities and/or the business collabo-ration. Business interactions are driven by significantbusiness events and represent an atomic unit of workin a trading arrangement between two or more businesspartners, which is typically associated with the formationof contracts or agreements and expressed in terms of atransactional business process (or business transaction).

A business transaction is defined as an atomic busi-ness process describing a trading interaction betweenpossibly multiple parties that strive to accomplish anexplicitly shared business objective [3]. This shared busi-ness objective extends over a possibly long period oftime and is terminated successfully only upon recogni-tion of the agreed conclusions between the interactingparties. A business transaction is driven by well-definedbusiness tasks and events that directly or indirectly con-tribute to generating economic value, such as processingand paying an insurance claim, and has also an associ-ated number of quality of service (QoS) parameters thatrepresent security and timing requirements. A businesstransaction always either succeeds or fails with respectto the business task (function) that initiated it and gov-erns it throughout its execution. If a business transac-tion completes successfully then each participant willhave made consistent state changes, which, in aggregate,reflect the desired outcome of the multi-party businessinteraction.

A business transaction is made up of a requesting(initiating) business activity performed by an initiat-ing partner (party) and a responding business activityperformed by the responding business partner. The ini-tiating business activity sends a business document toa responding business activity that may return a busi-ness signal (signifying the completion of an activity)and possibly a business document as the last respond-ing message. A transaction is associated with an SLAthat describes the agreed upon QoS requirements andusually outlines what each party can do in the event theintended actions are not carried out (e.g., promised ser-vices not rendered, services rendered but payment notissued).

3 The business transaction model

An important requirement in making cross-enterprisebusiness process automation happen is the ability todescribe the collaboration aspects of the business pro-cesses, such as business commitments, mutual obliga-tions and exchange of monetary resources, in a standardform that can be consumed by tools for business pro-cess implementation and monitoring. This gives raise tothe concept of a business transaction model that encom-passes a set of business transaction functions and sev-eral standard business primitives and conventions thatcan be utilized to develop complex business applicationsinvolving transactional and monetary exchanges.

Central to the business transaction model is the notionof a business transaction (see previous section for a defi-nition). Business transactions cover many domains ofactivity that businesses engage in, such as request forquote, supply chain execution, purchasing, manufactur-ing, and so on. The purpose of a business transactionis to facilitate specifying common business proceduresand practices in the form of business application scenar-ios that allow expressing business operational semanticsand associated message exchanges as well as the rulesthat govern business transactions. Such rules includeoperational business conventions, agreements, andmutual obligations. The combination of all these fac-tors characterizes the nature of business relationshipsamong the parties involved in a business transaction. Itenforces trading parties to achieve a common seman-tic understanding of the business transaction and theimplications of all messages exchanged.

The business transaction is initiated by a single orga-nization and brings about a consistent change in the stateof a business relationship between two or more trad-ing parties. A business relationship is any distributedstate held by the parties, which is subject to contractual

54 SOCA (2007) 1:51–63

BusinessTransaction BusinessFunction

BusinessSpecification+name:string

GeneralTransactionInvariant TransactionInvariant

SectorialTransactionInvariant

InterPartyTransactionInvariant

0..N

1

1..N0..M

Role+name:string

BusinessTransactionRole

BusinessFunctionRoleParty

+name:string

BusinessTransactionParty

BusinessFunctionParty2..N

0..M +0..M

+0..N

BusinessPrimitive

+name:string

1..N1..M

GeneralFunctionInvariantFunctionInvariant

SectorialFunctionInvariant

InterPartyFunctionInvariant

Invariant

+name:string

+0..M

+2..N

+0..M

+2..N

ReferentialPrimitive

DescriptivePrimitive

refencesTo

BusinessOperation

Protocol

1

1EventHandler

+eventTypes:QName[] ErrorHandler+errorTypes:QName[]

BusinessTransactionEventHandler

BusinessFunctionErrorHandler

BusinessTransactionErrorHandler

BusinessFunctionEventHandler

0..N

1

0..N

1

1

0..N

BusinessObject+name:string+type:QName

Fields+name:string+type:QName+value:Object

0..N

1

1

0..N

definesorreferences

0..N

1

definesorreferences

0..N

1

<<bpel>>Process

1

1

<<bpel>>PartnerLink

<<bpel>>Partner

<<bpel>>Variable

<<bpel>>CorrelationSet

<<bpel>>CompensationHandler

<<bpel>>EventHandler

1

0..N

1

0..N

1

0..N1

0..N

1

0..N

1

0..N<<bpel>>Activity

1

0..N

<<bpel>>FaultHandler

1

0..N

limited to certain

invokedby

affect

Fig. 1 Business transaction meta-model in UML

constraints agreed by those parties. A business transac-tion needs to express features like the parties that areinvolved in the transaction; the entities under transac-tion; the destination of payment and delivery; the trans-action time frame; permissible operations; links to othertransactions; receipts and acknowledgments; and finally,the identification of money transferred outside nationalboundaries.

The previous description of a business transactionhas been derived from (classical) commerce models andserves as a common high-level, non-technical view ofhow business organizations interact with each other. Thedefinition emphasizes the operational business view of atransaction. There are four key components in a businesstransaction model that help differentiate it from (gen-eral) message exchange that business processes involve.These are:

1. commitment exchange;2. the party (or parties) that has the ability to make

commitments;3. business constraints and invariants that apply to the

message exchanged between the interacting parties;and

4. business objects (documents) that are operatedupon by business activities (transactional opera-tions) or by processes.

These terms are introduced and explained below,while Fig. 1 represents them and their inter-relationshipsin UML.

A commitment exchange occurs between two or moreinteracting parties and concerns tasks or functions to becarried out and usually involves formal trading partneragreements that could be expressed in terms of businessprotocols such as RosettaNet PIPs or ebXML BusinessProcess Specification Schema (BPSS) [4]. A commit-ment exchange identifies such things as the overall busi-ness process, the partner roles, the business documentsused, message and document flow, legal aspects, securityaspects, business level acknowledgments and status, andso on. Partners inside a transaction have distinct roles(such as buyer and seller) and the ability to make com-mitments, being held responsible for, having rights andobligations, in the context of the business transactions.One party can act as the initiator of the transaction whilethe others can act as responders.

A business transaction constraint is defined as anexplicitly stated rule that prescribes, limits, or specifiesany aspect of a business transaction that forms part of thecommitment(s) mutually agreed to among the interact-ing parties. Business invariants are constraints externalto constraints agreed by interacting parties in a trans-action and include universal legal requirements, com-mercial and/or international trade and contract terms,

SOCA (2007) 1:51–63 55

public policy (e.g., privacy/data protection, product orservice labeling, consumer protection), laws and reg-ulations that are applicable to parts of a transaction.Invariants ensure the nature of the business transactionand/or the goods or services delivered while guaran-teeing that no regulations are compromised. Businessinvariants are universal (or horizontal) in nature andapply regardless of the type of business or sector withinwhich the business occurs. There are, however, con-straints external to parties that are of a sectorial naturecalled sectorial invariants which can be found in sectorssuch as telecommunications, transportation and deliv-ery, financial/banking, and so on. Universal and secto-rial invariants can be combined with inter-party businessconstraints for building application use scenarios. It isimportant to understand that in such situations invari-ants take precedence over internal constraints in a busi-ness transaction.

Business transactions may be characterized by uni-versally acceptable business operational primitives (orsimply business functions), which represent functionsthat are critical to the conduct of business. A businessfunction is a description of a well-defined and com-monly acceptable critical business principle, e.g., pay-ment or delivery of goods or services, that transformsbusiness values and causes state changes to transactionparticipants, e.g., transforms an unpaid order to paidorder. To achieve this the business function uses con-textually aware polymorphic business operations, e.g.,cancel an order or cancel a payment, constraints anddependencies, (see Sect. 6 for further details). Businesstransactions usually operate on business (document-based) objects. These are traditionally associated withitems such as purchase orders, catalogues (documentsthat describe products and service content to purchas-ing organizations), inventory reports, ship notices, bidsand proposals. Document objects are also associatedwith agreements, contracts or bids. This allows busi-ness transactions to interchange everything from prod-uct information and pricing proposals to financial andlegal statements.

An important characteristic of the business transac-tion model is that it is extendable in nature and can beincorporate and blend together diverse business, e.g.,RosettaNet PIPs, and technical protocols, e.g., securityprotocols.

4 Characteristics of the business transactions

Business transactions in the business transaction modelare defined through two perspectives very much alongthe lines of the Business Operational View and the

Functional Service View in OpenEDI and ebXML.These two perspectives are:

1. Business-related aspects such as critical businessfunctions, business conventions, agreements andrules among organizations. These are limited tothose aspects regarding the making of business deci-sions and commitments among organizations, whichare needed for the description of a business trans-action.

2. Systems-related aspects that are necessary for Webservices transaction systems to support the execu-tion of business transactions using Web servicesstandards.

Important business-related aspects of a transactioninclude the following features:

• which parties are involved in the transaction;• what is being transacted, e.g., what types of goods or

services;• the destination of payment and delivery;• the transaction time frame; e.g., a timeout value that

defines the maximum amount of time during whichthe transaction should be active;

• permissible operations;• links to other transactions;• receipts and acknowledgments;• identification of money transferred outside national

boundaries; and finally,• the ability to specify contractual agreements, liabili-

ties and dispute resolution policies.

Systems-related aspects focus on technical consider-ations for automating or improving the internal flowof transaction processing, spanning multiple disparateapplications. An important requirement is to providesolutions for reliable, consistent, and recoverable com-position of back-end services, as inconsistencies andfailures cannot be tolerated. The technical infrastruc-ture for supporting the business related aspects of abusiness transaction requires both short conventionalACID transactions as well as support for long-lived opennested transactions. Important systems-related aspectsof a business transaction include the following features:

• the ability to support of long-running interactions(business conversations) that include multiple, oftennested units of work, each with its own data require-ments;

• the ability to specify exceptional conditions and theirconsequences, including recovery sequences;

56 SOCA (2007) 1:51–63

Fig. 2 Integrated logistics example using RosettaNet PIPs

• the ability to support reversible (compensatible) andrepaired (contingency) transactions;

• use of alternate transactions that can be tried outeither in sequence or in parallel;

• the ability to reconcile and link transactions withother transactions;

• the ability to support secure transactions that guar-antee integrity of information, confidentiality, pri-vacy and non-repudiation;

• the ability for transactions to be monitored, audited/logged and recovered.

In a Web services environment business transactionsare used to capture and define the integration betweenbusiness operational requirements and technical trans-actional requirements. Business transactions are foundonly in the application (business-logic) level and essen-tially trigger transactional Web service interactionsbetween organizations at the systems-level (using Webservices-based business processes and transactionalstandards) in order to accomplish some well-definedshared business objective. A business transaction in itssimplest form could represent an order of some goodsfrom some company. The completion of an order resultsin a consistent change in the state of the affected busi-ness: the back-end order database is updated and a doc-ument copy of the purchase order is filed. More complexbusiness transactions may involve activities such as pay-ment processing, shipping and tracking, determiningnew product offerings, granting/extending credit, andso on.

Transactional facilities such as the previous areprovided by Web Services standards including the

Web Services Transaction (WS-Transaction) [5,6] andthe Web Services Composite Application Framework(WS-CAF) [7] standards.

5 Integrated logistics example

In this section we present a simple integrated logisticsexample based on standard business protocol Rosetta-Net PIPs [8]. We shall enhance the simple integratedlogistics scenario described in the following with trans-actional functions and business operational semantics aswell as QoS features.

RosettaNet PIPs define the specific sequence of stepsrequired to complete a business-to-business process,such as the placement of a purchase order with a sup-plier, and the specific exchange of information and trans-actions triggered by each step in the business process.Specifically, RosettaNet PIPs create standard e-businessdialogues for common business activities like order andinventory management, transportation, sales forecast-ing, etc. The PIPs are organized in functionally logi-cal groupings of segments and clusters. For example,the PIP3A4 Purchase Order Request is found in theQuote and Entry Segment grouping, which belongs tothe Order Management cluster [8].

Figure 2 depicts an integrated logistics scenarioinvolving a customer, suppliers and a logistics serviceprovider. This logistics model consists of forecast noti-fication, forecast acceptance, inventory reporting, ship-ment receipt, request and fulfil demand, consumptionand invoice notification processes. PIP 4A2 (Notify ofEmbedded Release Forecast) supports a process in which

SOCA (2007) 1:51–63 57

Des

crip

tive

pri

mit

ives

Ref

eren

tial

pri

mit

ives

(Co

nte

xtaw

are)

Bu

sin

ess

Op

erat

ion

s

Order Payment Delivery Transport General QoS Security Transactional

Identification Value + Negotiable M Means Accessibility Authentication MeansMethod Means Method Method Accuracy Integrity Operative

Settlement Pick-Up Pick-Up Efficiency Confidentiality articipantsStatus Status Reliability Authorization/Access Control DependenciesRestrictions Restrictions Responsiveness Repudiation

Immediacy Immediacy Immediacy Immediacy

Order OrderPayment Payment Payment Temporal Location RoutingDelivery Transport Time Spatial Point SequentialRepudiation Repudiation Repudiation Repudiation Date Rout allel

Refund Duration UR electiveRespend Interval Spectra ChoiceTransferTraceRetry Retry Retry General BO BO Associations Operations

Change Change Change Change Identification Business Function Reference set/getCancel Cancel Cancel Cancel Properties Other BO Reference change

QoS Operational Principles

Business Objects

Constraints

Operational Business Principlesr Payment Delivery Transport General QoS Security Transactional

Identification eans Means Accessibility Authentication MeansMethod Means Method Method Accuracy Integrity Operative

Settlement Pick-Up Pick-Up Efficiency Confidentialit articipantsStatus Status Reliability Authorization/Access Control DependenciesRestrictions Restrictions Re s Repudiation

Immediacy Immediacy Immediacy Immediacy

Order OrderPayment Payment Payment Temporal LocationDelivery Transport Time Spatial Point SequentialRepudiation Repudiation Repudiation Repudiation Date Route Parallel

Refund Duration UR electiveRespend Interval Spectra ChoiceTransferTraceRetry Retry Retry General BO BO Associations Operations

Change Change Change Change Identification Business Function Reference set/getCancel Cancel Cancel Cancel Properties Other BO Reference change

Business Objects

Constraints

P

Fig. 3 Description of common business functions, QoS principles and constraints

a forecast owner sends forecast data to a forecast recip-ient. The embedded release forecast contains productdemand information (planning demand) and/or prod-uct release information. PIP 4A5 (Notify of ForecastReply) provides visibility of available forecasted prod-uct quantity between two trading partners. PIP 4C1 (Dis-tribute Inventory Report) supports a process in which aninventory information provider reports the status of theinventory to an inventory user. The inventory report caninclude any product, active or inactive, held in inventory.PIP 3B2 (Notify of Advance Shipment) allows a shipperto notify a receiver that a shipment has been assigned.This notification is often a part of the shipment pro-cess. PIP 4B2 (Notify of Shipment Receipt) supports aprocess used by a consignee to report the status of areceived shipment to another interested party, such asanother consignee, a transport service provider, a third-party logistics firm, or a shipper. Receipt of a shipmentis reported after it has been delivered by a carrier andinspected by receiving personnel. The customer thenissues an Invoice Notification (PIP 4B3) to communi-cate material consumption to the supplier, allowing thesupplier to trigger invoicing for the consumed material.PIP 3C3 (Notify of Invoice) enables a provider to invoiceanother party, such as a buyer, for goods or services per-formed. Finally, PIP 3C6 (Notify of Remittance Advice)enables a payer to send remittance advice to a payee (inthis case the supplier) which indicates which payablesare scheduled for payment.

6 Business operational principles and QoS functions

In the previous we argued for the identification of func-tional capabilities necessary to support business trans-actions and introduced the concept of critical business

functions, which divide business applications along com-mon functional lines. Figure 3 describes the constituentelements of the business functions in the business trans-action model, which is described schematically in Fig. 3.In particular, this figure illustrates that the businesstransaction model divides trade into four broad func-tional lines — ordering, paying, delivery and transpor-tation, which are referred to as business operationalprinciples (or business functions) in this figure. Theseareas represent common business functions that aregeneric, industry neutral and re-usable and can be usedto develop business transactions in a multiplicity of busi-ness scenarios. In this way we remove excess complexityfrom the business transaction, allowing common busi-ness functions such as ordering, distribution and pay-ment to be expressed in a form analogous to abstractdata types and rationalizing them across an integratedsupply chain. The basic structure of these business func-tions (which could be also appropriately extended andcustomized) provides a standard definition for buildingbusiness solutions.

Figure 3 shows that each business function uses anumber of descriptive primitives (or attributes) thatdescribe a certain business function, e.g., the meansof payment. There are also referential primitives thatrefer to other business functions, e.g., payment refersto an associated order. Finally, the context aware busi-ness operations introduce a set of polymorphic businessoperations that collectively transform business valuesand cause state changes to the business transaction par-ticipants, e.g., cancel and order or cancel a shipment.

Business functions not only help streamline and ratio-nalize common business practices across an integratedsupply chain, they also help enforce participant com-mitments. They introduce a mandatory set of four busi-ness level atomicity criteria that reflect the operational

58 SOCA (2007) 1:51–63

Fig. 4 Describing thedelivery business functionattributes

semantics the four standard business functions (order-ing, payment, delivery and transportation). For instance,payment atomicity affects the transfer of funds from oneparty to another in the transaction. This means that thetransaction would fail if payment is not made within apre-specified time period that was agreed between a sup-plier and a customer. Delivery atomicity, on the otherhand, implies that the right goods will be delivered to acustomer at the time that has been agreed.

Each atomicity criterion is treated as a single indivisi-ble logical unit of work, which determines a set of viableoutcomes for a business transaction. The outcomes of abusiness transaction may involve non-critical partial fail-ures, or selection among contending service offerings,rather than the strict all-or-nothing assumption of con-ventional ACID transactions, and govern the durationand character of participation in a transaction. They alsoallow provisional results to be revealed deliberately toallow such business activities as probabilistic inventorymanagement. Atomicity criteria can be characterized asvital or non-vital. If a business level atomicity criterionis characterized as vital and fails then the transactionaborts at the system-level. If, however, the atomicity cri-terion is characterized as non-vital then a contingencyactivity may be issued in case that a given atomicity crite-rion, e.g., if goods transportation fails then another ship-per could be chosen and a new shipment is scheduled.The above characteristics give the ability to a businesstransaction to explicitly describe business operationalsemantics, specify the proper behavior of common busi-ness functions and their implications in case of successor failure.

The business transaction model not only expressesthe purpose of each business collaboration interactionbut is also capable of capturing the message and com-mitment exchange requirements between any tradingpartners, identifying the timing and sequence of mes-sage exchanges. The message exchanges in the modelcan be specified in such a way so as to define the order-ing in which a particular partner sends messages to and

expects messages from its trading partners. The modelhas some fixed sequencing semantics which require thatordering occurs first and is followed by transport anddelivery. Payment can happen either before or after thedelivery function. For instance, in the integrated logisticsscenario described in the previous section, there mightbe an implicit or explicit agreement that the deliveryof goods must take place before the payment and thatpayment always follows the confirmation of an order.This situation is depicted by the following code snip-pet that uses a business transaction specification lan-guage (called Business Transaction Mark Up Languageor BTML) that we are currently developing for businesstransactions employing Web services.

<BTx><name>LogisticsScenario</name> ...<sequence><BF> <name>Order</name> </BF><BF> <name>Delivery</name> </BF><BF> <name>Payment</name> </BF> ...

</sequence></BTx>

By using these constructs, each participant can under-stand and plan for conformance to the business protocolbeing employed.

Figure 4 shows two of the attributes of the deliverybusiness function. These are means and method whichdescribe the means and method of delivery, respectively.The delivery business function, as seen from Fig. 3, alsouses referential primitives to refer to other functionssuch as payment and transport. It also uses context awarepolymorphic business operations, such as retry to retry afailed delivery, change to change a delivery and cancel tocancel a delivery. All attributes and operations in Fig. 3have been defined and formalized and are available onrequest.

Finally, an important element of the business model isthe quality of service required from the functional capa-bilities for the business transactions. For instance, oneof the referential primitives used in business functions

SOCA (2007) 1:51–63 59

such as ordering, payment, transport and delivery, isthe issue of non-repudiation using digital signatures, seeFig. 3. Non-repudiation is a security service that supportsthe proof-of-origin and the proof-of-receipt services thatprovide proof of message origin to the recipient andproof of message receipt to the sender. In this way busi-ness transactions can also become QoS-aware and QoSprinciples can be blended with constraints and businessrequirements enforced by the business functions. OtherQoS primitives that can be attached to a business trans-action and govern its behavior may include general QoSprimitives such as desired performance rates, mean timeto respond, accessibility periods, time-to-repair a servicethat has failed, desirable security protocols and tokens,and so on. These are also depicted in Fig. 3.

QoS criteria can be registered in a Service LevelAgreement, which specifies the agreements and commit-ments of trading partners involved in a business trans-action and which is used to specify the conditions thatinitiate and drive a business transaction. More specifi-cally, they form part of the agreed service-level objec-tives, which define the levels of service that both theservice customers and the service providers agree on,and usually include a set of service level indicators, likeavailability, performance and reliability.

7 Business transaction reference architecture

Apart from providing a basis for describing partnerengagements, interaction sequences and the technicalservices for implementing business practices in a sup-ply chain, the business transaction model can also serveanother equally important purpose. It can also serveto introduce a framework for the development of e-Business solutions needed to rationalize and simplifybusiness transactional exchanges and applications in anintegrated supply chain. The effective inter-relationshipbetween the two perspectives of business transactionspresented in Sect. 4 is a critical factor of the architec-tural model.

The reference architecture that supports the businesstransaction model is depicted in Fig. 5. Application sce-narios are built using the business related aspects of themodel, e.g., business principles constraints, QoS crite-ria, and soforth. Both the business ad technical aspectsof the model must interact with each other to executethe corresponding business transaction. Each businesslevel aspect is appropriately mapped to a correspondinginfrastructure primitive that that employs Web servicesstandards, such as BPEL, WS-Coordination [9], WS-Atomic Transaction [5,10] and WS-Business Activity [6,10]. Currently, this trio of Web services standards is used

WS-Sec WS-C/T WS-CAF BPEL WS-AG WS-Pol

Business Applications

QoSPrinciples

BusinessPrinciples

Constraints

Transformation

Infrastructure Primitives(cancel, commit, compensate, sign, etc)

SLA

Business

Protocols

TechnicalP

rotocols

WS-Sec WS-C/T WS-CAF BPEL WS-AG WS-Pol

Business Applications

QoSPrinciples

BusinessPrinciples

Constraints

Transformation

Infrastructure Primitives(cancel, commit, compensate, sign, etc)

SLA

Business

Protocols

TechnicalP

rotocols

Fig. 5 Business transaction reference architecture

to implement business transactions. This infrastructureis based on open an source implementation frameworkprovided by JBoss Transactions (http://www.jboss.org)which supports the latest Web services transactions stan-dards, providing all of the components necessary to buildinteroperable, reliable, multi-party, Web services-basedapplications quickly and easily.

Figure 5 also shows how QoS criteria can be regis-tered in an SLA. An SLA contains several entries thatare related to a business transaction. These include thescope of the agreement (the services covered in theagreement), penalties (sanctions should apply in casethe service provider under-performs and is unable tomeet the objectives specified in the SLA), optional ser-vices (any services that are not normally required bythe user, but might be required in case of an exception)and exclusion terms (specify what is not covered in theSLA).

QoS criteria in the context of a business transactionare expressed as assertions by an assertion sub-languageof BTML. This assertion language is an extension ofthe WS-Policy assertion language thereby reusing exist-ing functionality like normal form, referential and com-bined policies. BTML’s assertion language also containscontext specific assertion definitions for a business trans-action. This part of the BTML can then be incorporatedas guarantee terms into agreements templates specifiedby WS-Agreement to enable the specification, negoti-ation and acceptance of SLAs that are used to drivebusiness transactions.

Finally, the reference architecture supports the use ofbusiness and technical protocols in the context of thebusiness transaction model. Currently, the architecturesupports one business protocol namely, RosettaNet, andone technical protocol, the Secure Electronic Transac-tion (SET) [11]. SET (already obsolete) is a technicalprotocol that ensures the security of financial transac-tions on the Internet. With SET, a user is given a digitalcertificate and a transaction is conducted and verifiedusing a combination of digital certificates and digitalsignatures among the purchaser, a merchant, and the

60 SOCA (2007) 1:51–63

Fig. 6 Listings of BTML snippets

purchaser’s bank in a way that ensures privacy and con-fidentiality. SET makes use of the Secure Sockets Layerand uses several aspects of a Public Key Infrastructure.

In the following we concentrate on illustrating howto semantically enhance the RosettaNet business pro-tocol, which lacks the notion of a business transactionas defined in Sect. 2, by injecting into it business func-tions, explicit sequencing of interactions, partner com-mitments and constraints.

8 Emulating business and technical protocols

In this section we will illustrate how we can supplanttransactional primitives into the integrated logistics sce-nario in Fig. 2 to semantically enhance the operationalcharacteristics of the interacting RosettaNet processes.

This procedure is performed according to the follow-ing steps. We start first by grouping the individual PIPsinto related sets that realize a specific common businessfunction. We observe that PIPs 4A2, 4A5 and 4C1 areall part of the order business function. PIP 3B2 is part ofthe transport function and PIPs 4B2 and 4B3 are part ofthe delivery function. The payment function is coveredby PIPs 3C3 and 3C6.

Following this we need to capture the message andcommitment exchange requirements between any trad-ing partners, identifying the timing and sequence ofmessage exchanges. We assume that the trading part-ners have agreed on a business protocol (developedon the basis of RosettaNet) which requires that pay-ment follows transport and delivery. This is specified inBTML. Subsequently, we can specify the business func-tions using BTML. We assume that in the integrated

logistics example the customer and the supplier haveagreed on an all or nothing express delivery method,which specifies that if the goods are ready for transportthe delivery should not take more than two days (whichrequires delivery by air). The specification in BTML canbe found in Listing 1 of Fig 6.

The above code snippet also specifies that the deliv-ery location is changeable at most twice at a cost of 150$ per time and that the fees will be added to the originalinvoice.

Figure 7 illustrates a simple payment protocol agreedbetween a supplier and a customer. In this figure thepayment protocol is seen from the vantage point of thesupplier. The second code snippet (found in Listing 2 ofFig. 6) specifies in BTML (part of) the simple paymentprotocol illustrated in Fig. 7.

As a last step we may wish to add QoS propertiesto the elements of the business transaction. In partic-ular, we may wish to indicate that the InvoiceNotifica-tion process (PIP 3C in Fig. 2) requires that the time toacknowledge an Invoice Notification message send fromthe Send Invoice activity of the Supplier to the ReceiveInvoice activity of the Customer is no longer then 2 h.This property can be specified using the Responsivenessprimitive in the General QoS field in Fig. 3. The QoSResponsiveness primitive has an operator called setAc-knowledgeable that specifies whether a particular mes-sage should or should not be acknowledgeable and alsothe time frame for this to happen. This can be specifiedin BTML as seen in Listing 3 of Fig. 6.

We may also wish to add other QoS constraints onmessages or message parts. For example we may wish tospecify further security primitives indicating whether ornot a message or message part should be non-reputable

SOCA (2007) 1:51–63 61

Fig. 7 Simple paymentprotocol agreed between asupplier and a customer

ConsumerSupplier

CreateInvoice

SendInvoice

ReceiveInvoice

ProcessInvoice

AcceptInvoice

CreateRemitt Adv

SendRemitt Adv

ReceiveRemitt Adv

ProcessRemitt Adv

DeclineInvoice

DeclineRemitt Adv

or signed with a particular hash and encryption function.This can be specified in BTML as seen in Fig. 8.

The listing expresses two alternatives in a policy spec-ified using WS-Policy notation. This is indicated by theExactlyOne policy operator, which specifies that onlyone of its direct elements must be applicable. Each ofthese alternatives is shown to be wrapped in an Alloperator. The All operator means that all the asser-tions enclosed within this operator must be applicable.This means that if the first alternative is chosen, a Kerb-eros token type and AES encryption algorithm must beemployed. If conversely the second alternative is chosen,an X509 certificate and the 3DES encryption algorithmmust be employed.

To implement the above business scenarios Rosetta-Net types, messages, such the ones expressed in Fig. 2,are mapped to equivalent message definitions in WSDL.The actions in a RosettaNet PIP are mapped to oper-ations in WSDL. Partner roles are mapped to Partnersin BPEL. Choreography from the RosettaNet PIPs areimplemented in the choreography of the abstract andexecutable business process in BPEL. Finally, exceptionmessages from RosettaNet RNIF are mapped to theexception handling mechanisms of BPEL. Transactionalimplementations for the above scenarios are currentlybeing mapped to WS-Coordination and WS-Transac-tion constructs. Concepts that have no direct mappingseither in BPEL, WS-Coordination, and WS-Transactionrequire specific workaround implementations.

Another important aspect of the business referencearchitecture is that it can blend business with technicalprotocols. For instance, the business application that wesketched in the previous does not have any concreteway to handle the actual payment so that it can transferfunds using a financial service provider. This situationalso holds for the RosettaNet PIPs.

To remedy this situation we can extend the paymentpart of the business transaction described in the pre-vious with a technical protocol that guarantees securepayments. This could be, for instance, accomplished bymeans of the Secure Electronic Transaction protocol.SET itself is focused on messages, their content, security

Fig. 8 Adding QoS constraints to messages

aspects and authorization and it is not integrated withother business functions and business protocols and hasno notion of system transactions. An implementationexists that shows how to create an executable transac-tional business process of the enriched SET protocolusing BPEL and WS-Transaction and how to associ-ate the payment protocol with business transaction con-structs.

9 Related work

Automated business transactions are a new category ofresearch, wider than historical data-centric local, dis-tributed of federated transactions. This third genera-tion of transaction management builds out from coretransactional technology, particularly the concept of aopen nested transactions and multi-phase distributedoutcomes (two-phase commit in conventional database/messaging transactions).

62 SOCA (2007) 1:51–63

Research in this paper was inspired by the work foundin [12], which motivates the need for using transactionsthat mimic real business exchanges and presents an over-view of several technologies and protocols that may sup-port a business transaction framework.

Research in the business transactions area is alsorelated to the creation of meta-models for Web servicetransaction models as for example reported in [13,14].In [13] the authors propose to combine multiple trans-action models as WS-C coordination types into BPELspecifications that can support transactional workflows.In [14] a meta-modeling approach to transaction man-agement is proposed, however, this approach focuses onthe modeling and representation of transaction mod-els driven purely from database technology perspec-tive without taking into account business and workflowrequirements.

The work reported in this paper can benefit fromother ongoing research in the Web services domain. Ofparticular interest is the work on SLAs reported in [15].Here, the authors define a template-based approach thatenables automated service provisioning. This provision-ing can be guided by the WS-Agreement [16] protocol.Finally, the work reported in [17] is quite relevant as itdescribes many non-functional properties applicable forWeb services that can also benefit business transactions.

10 Summary

In the previous we have described a business transactionmodel and associated reference architecture. Key char-acteristics of this model is that is sharply distinguishesbetween a business related and a systems related viewof transactions. On the business-level transactions areweaved around commonly standard business functionsthat apply to a variety of application scenarios. Althoughsuch business functions drive transactional applicationsbetween trading partners they are completely externalto current Web services transaction mechanisms and areonly expressed as part of the application logic and are ofcourse difficult to reuse and specialize. At the businesslevel, the model can also represent business exchangesand the sequencing and timing, business agreementsstipulated in SLAs, liabilities and dispute resolution pol-icies, and blends these with QoS criteria. At thesystems-level the business transaction model providessupport for conventional ACID split-second durationtransactions but also long-running transactions, whichmay endure for periods that exceed the anticipated ser-vice cycles of participant systems. Business transactionsin the systems-level retain the driving ambition of con-sistency. Implementation of the systems-level services is

currently provided by a trio of Web services standardsBPEL, WS-Coordination, and WS-Transaction.

Business transactions are more flexible and sophisti-cated in their means reflecting real business functionalityand operational semantics and also the imperfect deter-minism of real business processes (which are necessarilydesigned to cope with innumerable variations and withincremental and partial successes). This approach resultsin a modular, scalable, flexible integration architectureand support environment, providing a high level lan-guage to coordinate the commitment exchangesbetween parties and ensuing flow of messages amongdifferent business processes that require transactionalsupport.

The potential benefits of this approach arise largelyfrom its ability to standardize common business func-tions, better align business processes with business objec-tives and provide information to enable monitoring andtroubleshooting of problems and delays. Business deci-sions can be made at every step of the transaction toalign it with business objectives and to alleviate unde-sirable conditions. For example, in case of a purchaseorder cancellation due to a faulty part, an order trans-action can automatically reserve a suitable replacementproduct and notify the billing and inventory processes ofthe changes. When all interactions between the variousbusiness processes have been completed and the newadjusted schedule is available, the purchase order Webservice notifies the customer sending her an updatedinvoice.

Work is currently underway regarding the formaliza-tion and verification of the business transaction model.

References

1. Webber D (2000) Understanding ebxml, uddi and xml/edihttp://www.touchbriefings.com/pdf/967/59.pdf

2. Meadows B, Seaburg L (2004) Universal Business Language1.0. http://www.docs.oasis-open.org/ubl/cd-UBL-1.0/

3. Papazoglou M, Kratz B (2006) A business-aware web servicestransaction model. In Dan A, Lamersdorf W (eds) Pro-ceedings of the 4th international conference on service ori-ented Computing (ICSOC 2006), Chicago December 4–7,2006. Lecture Notes in Computer Science, vol 4294 Springer,Berlin, pp 352–364

4. Business Process Project Team: ebxml business process spec-ification schema version 1.01 (2001) http://www.ebxml.org/specs/ebBPSS.pdf.

5. Cabrera LF, Copeland G, Feingold M, Freund RW, Freund T,Johnson J, Joyce S, Kaler C, Klein J, Langworthy D, Little M,Nadalin A, Newcomer E, Orchard D, Robinson I, Storey T,Thatte S (2005) Web services atomic transaction (WS-Atom-icTransaction). 1.0 edn

6. Cabrera LF, Copeland G, Feingold M, Freund RW, Freund T,Joyce S, Klein J, Langworthy D, Little M, Leymann F, New-comer E, Orchard D, Robinson I, Storey T, Thatte S (2003)

SOCA (2007) 1:51–63 63

Web services Business activity framework (WS-BusinessAc-tivity). 1.0 edn

7. Bunting D, Chapman M, Hurley O, Little M, MischkinskyJ, Newcomer E, Webber J, Swenson K (2003) Web servicescomposite application framework (WS-CAF). 1.0 edn

8. RosettaNet: (2001) standards required to support xml-based b2b integration http://xml.coverpages.org/rosettanet-StandardsForIntegration.pdf

9. Cabrera LF, Copeland G, Feingold M, Freund RW, Freund T,Johnson J, Joyce S, Kaler C, Klein J, Langworthy D, Little M,Nadalin A, Newcomer E, Orchard D, Robinson I, ShewchukJ, Storey T (2005) Web Services Coordination (WS-Coordi-nation). 1.0 edn

10. Cabrera LF, Copeland G, Johnson J, Langworthy D (2004)Coordinating web services activities with ws-coordination,ws-atomictransaction, and ws-businessactivity http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebsrv/html/wsacoord.asp

11. Merkow MS, Breithaupt J, Wheeler KL (1998) Building SETapplications for secure transactions. Wiley, New York

12. Papazoglou M (2003) Web services and business transactions.World Wilde Web: Internet Web Inf Syst 6(1):49–91

13. Tai S, Mikalsen T, Wohlstadter E, Desai N, Rouvellou I(2004) Transaction policies for service-oriented computing.Data Knowl Eng 51:59–79

14. Hrastnik P, Winiwarter W (2005) Using advanced transac-tion meta-models for creating transaction-aware web serviceenvironments. Int J Web Inf Syst 1(2):89–99

15. Ludwig H, Gimpel H, Dan A, Kearney B (2005) Templatebased automated service provisioning supporting the agree-ment driven service life-cycle. In: Benatallah B, Casati F, Trav-erso P (eds) Service-oriented computing - ICSOC 2005, 3rdProceeding of international conference, Amsterdam, Decem-ber 12–15, 2005, Lecture Notes in Computer Science, vol.3826. Springer, Berlin pp 283–295

16. Andrieux A, Czajkowski K, Dan A, Keahey K, LudwigH, Nakata T, Pruyne J, Rofrano J, Tuecke S, Xu M (2005)Web services agreement specification (ws-agreement). Tech-nical report, Grid Resource Allocation Agreement Protocol(GRAAP) WG

17. O’Sullivan J, Edmond D, ter Hofstede AHM (2005)Formal description of non-functional service descriptions.Technical report, Queensland University of Technologyhttp://www.bpm.fit.qut.edu.au/about/docs/non-functional.jsp