Transaction policies for service-oriented computing - CiteSeerX

Data & Knowledge Engineering 51 (2004) 59–79 www.elsevier.com/locate/datak

Transaction policies for service-oriented computing Stefan Tai a,*, Thomas Mikalsen a, Eric Wohlstadter b, Nirmit Desai c, Isabelle Rouvellou a a

b

IBM T.J. Watson Research Center, 19 Skyline Drive, Hawthorne, NY 10532, USA Department of Computer Science, University of California, Davis, One Shields Ave., Davis, CA 95616, USA c Department of Computer Science, North Carolina State University, 940, Main Campus Drive, Venture-I, Suite 110, Raleigh, NC 27695, USA Accepted 3 March 2003 Available online 9 April 2004

Abstract Service-oriented computing is emerging as a distributed computing model where autonomous services interact with each other using standard Internet technology. In addition to the application-specific functions that services provide (different) services may also support (different) sets of protocols and formats addressing extra-functional concerns such as transaction processing and reliable messaging. This raises the need for services to complement their functional service descriptions with descriptions of extra-functional capabilities, requirements, and/or preferences, which must be matched and enforced for service interactions. In this paper, we address the problem of transactional coordination in service-oriented computing. We argue for the use of declarative policy assertions to advertise and match support for different transaction styles (direct transaction processing, queued transaction processing, and compensation-based transaction processing), and introduce the concept of and system support for transaction coupling modes as the policybased contracts guiding transactional business process execution. We focus on concrete, protocol-specific policies that apply to relevant Web services specifications. Using transaction policies and our middleware system, we are able to support a reliable SOC environment. Ó 2004 Elsevier B.V. All rights reserved. Keywords: Service-oriented computing; Transactional coordination; Declarative policy assertions

*

Corresponding author. E-mail addresses: [email protected] (S. Tai), [email protected] (T. Mikalsen), [email protected] (E. Wohlstadter), [email protected] (N. Desai), [email protected] (I. Rouvellou). 0169-023X/$ - see front matter Ó 2004 Elsevier B.V. All rights reserved. doi:10.1016/j.datak.2003.03.001

60

S. Tai et al. / Data & Knowledge Engineering 51 (2004) 59–79

1. Introduction Service-oriented computing (SOC) is emerging as a new distributed computing model that builds on the notion of an Internet-accessible service to represent applications and business processes for integration. SOC suggests a component and metadata-driven approach to dynamically discover and select services, to execute services in heterogeneous implementation environments, and to interact with services in a client–server or peer-to-peer fashion [20,21,27]. Web services are an effort to define a SOC platform [1]. Initially, the basic specifications SOAP [6], UDDI [4], and WSDL [11] have been developed. More recently, these have been complemented with specifications for Web services coordination (WS-Coordination [9]) and transactions (WS-Transaction [8]), Web services reliable messaging (WS-ReliableMessaging [15]), and business process definition and execution for Web services (BPEL [12]) [13]. Additional important specifications addressing Web services policies (WS-Policy [19]), security, and other aspects have also been proposed [32]. A specific Web service provider (and, Web service client) may or may not support any of these specifications, and may also require or prefer a particular usage according to the specifications. For example, a Web service provider may support the coordination protocols for atomic transactions, but not the coordination protocols for business activities [8]. Or, a Web service client may support reliable messaging according to the WS-ReliableMessaging specification, and prefer a delivery assurance of exactly-once. In order to coordinate and compose Web services, the services’ extra-functional capabilities, requirements, and preferences must be declared and matched. The functional service interfaces defined in WSDL must be complemented with extra-functional specifications, and a middleware is needed to match capabilities and requirements to ensure proper execution according to the declarations. In this paper, we present an approach to transactional Web services coordination. We argue for the use of declarative policy assertions to advertise and match transaction capabilities and requirements of individual service providers and clients, and to define transactional semantics of Web services compositions. We introduce transaction policies and transaction coupling modes. Transaction policies are assertions for transactional coordination that individual service providers and service clients declare. We use and extend the WS-Policy XML syntax for this purpose. A transaction coupling mode is the contract that matches service provider and client transaction policies. We show how policies and coupling modes can be used to support the three transaction styles of direct transaction processing (DTP), queued transaction processing (QTP), and compensationbased transaction processing (CTP) [31]. We further present a middleware prototype for policy matching and transactional business process execution. The paper is structured as follows. In Section 2, we describe the transaction styles of DTP, QTP, and CTP. In Section 3, we introduce concrete transaction policies supporting these styles, and show how the policies can be attached to Web services (WSDL and BPEL) descriptions. In Section 4, we introduce our policy matching algorithm to realize transaction coupling modes guiding transactional business process execution. Our middleware system prototype implementing the ideas presented is described in Section 5. We discuss related work and conclude with a summary in Sections 6 and 7.


61

2. Transactions Transactions are a common way to address reliability and fault-tolerance in distributed computing, and a variety of transaction models has been proposed [16]. Most of these models are variants of one of the three main transaction processing styles of direct transaction processing (DTP), queued transaction processing (QTP), and compensation-based transaction processing (CTP) [31]. In this section, we describe these transaction styles for background and motivation. 2.1. Direct transaction processing (DTP) The direct transaction processing (DTP) style is illustrated in Fig. 1. A single DTP interaction comprises one client (process A) and one or more servers (service providers, process B). The client sees the invocation of a server as an atomic unit that is protected by transaction Ta. The server sees its processing as an atomic unit protected by transaction Tb. Ta and Tb are coordinated as part of a single global transaction Tg. The invocation of the server is synchronous, with the client blocking while waiting for the server’s response (transactional RPC). The invocation also is reference-based (thus, direct), and requires the server to be available at the time that the invocation takes place. State changes are executed in isolation (are not visible outside the transaction), and can be automatically rolled back by the middleware should the transaction abort. The coordination of client and server(s) is achieved using a distributed two-phase commit (2PC) protocol [16].

Fig. 1. Direct transaction processing (DTP).

62


2.2. Queued transaction processing (QTP) The queued transaction processing (QTP) style is illustrated in Fig. 2. In QTP, the client’s view now spans two transactions Ta1 and Ta2, which cannot be treated as an atomic unit. This is in contrast with DTP, where the client’s action was protected by a single transaction. The separation into two transactions has implications on the recovery of A should there be a failure after executing Ta1 but prior to completing Ta2. The server’s view in QTP is the same as in DTP. The invocation of the server is asynchronous through middleware (queue) mediation, using reliable messaging protocols to ensure guaranteed delivery of request and reply messages. Therefore, the server (respective client) need not be available at the time that the client (respective server) is sending a message, and the client is not blocked waiting for the server’s response. Unlike DTP, no global transaction exists in QTP to coordinate the transactions Ta1, Tb, and Ta2, and state changes performed in each of these transactions, when completed, are visible. It is the application’s responsibility to correlate request and reply messages and to potentially initiate compensation actions to undo any unwanted state changes (see below). 2.3. Compensation-based transaction processing (CTP) Compensation-based transaction processing (CTP) refers to a transaction style that employs compensation as a technique [22]. A compensating action is executed to ‘‘undo’’ the effects of actions that have been successfully completed (and which are, therefore, not isolated); the com-

Fig. 2. Queued transaction processing (QTP).


63

Fig. 3. DTP compensation.

pensation action constructs a new correct state as a means of forward recovery. Actions and compensating actions can be, for example, a single operation, a DTP interaction, a QTP interaction, or an entire business process. A coordination middleware driving a compensation-based coordination protocol is needed. Fig. 3 depicts compensation for a DTP interaction. The primary action is the transaction Tg1 which includes B ’s processing of X . After the completion of Tg1, the client (or possibly another process) may decide to compensate Tg1 (illustrated by the diamond in Fig. 3). If a decision to compensate Tg1 is made, a second transaction Tg2 is executed. The transaction Tg2 processes X 0 to forward recover from the processing of X in Tg1. Compensation of a QTP interaction requires a corresponding set of transactions for the three transactions that were completed. This is illustrated in Fig. 4. As in DTP compensation, a process X 0 must be executed by the server to undo any prior processing of X . 3. Transaction policies DTP, QTP, and CTP are transaction styles relevant to modern enterprise systems. DTP is commonly used whenever a tight coupling between client and server and strong isolation guarantees are desired. QTP allows for loosely-coupled, asynchronous transactions. CTP is often required to support atomicity and consistency of long-running business processes that involve committing actions during the process.

64


Fig. 4. QTP compensation.

Each of the DTP, QTP, and CTP styles can be described from the client’s and the provider’s viewpoint. To declare client and provider transaction support, we correspondingly propose the use of client transaction policies and provider transaction policies. A client transaction policy defines the client’s capabilities, requirements, and preferences to invoke a service provider transactionally, to participate in reliable messaging, and/or to drive compensation. A service provider transaction policy defines the provider’s capabilities and requirements to be transactionally invoked, to engage in reliable messaging, and/or to support compensation. Client and provider policies can be matched for compliance; a matched client–provider policy describes a transaction coupling mode. A transaction coupling mode is the (short-lived or longlived) contract between two partners to engage in transactional interactions. 3.1. Abstract and concrete policies Transaction policies (client and provider policies) and transaction coupling modes can be expressed on different levels of abstraction. Abstract policies allow to describe and to match transaction capabilities and requirements independent of the (lower-level) interoperability formats and protocols that can be used to implement the transaction. The Transaction Attitudes framework and middleware is an example system supporting abstract policies [25].

transactional interaction

backward recoverable

forward recoverable

shared context

separate context

shared context

DTP using 2PC

QTP using RM

CTP

DTP using WS-TAT

QTP using WS-RM

CTP using WS-TBA

65

transaction coupling mode abstraction


Fig. 5. Transaction coupling mode abstractions.

Concrete policies, on the other hand, refer to specific formats and protocols used to implement the transaction, such as the two-phase-commit protocol of the WS-Transaction specification [8] or the reliable messaging protocol defined in the WS-ReliableMessaging specification [15]. Concrete policies are needed to ensure service compatibility and proper execution of service interactions according to specifications like WS-Transaction and WS-ReliableMessaging. Abstract policies result in correspondingly abstract transaction coupling modes; concrete policies result in protocol-specific contracts. Fig. 5 illustrates different levels of abstraction for transaction coupling modes. An abstract coupling mode, for example, describes that services engage in a backward recoverable interaction. A concrete coupling mode describes that services engage in a DTP-style interaction using the WS-Transaction atomic transaction (WS-T AT) protocols, or a CTP-style interaction using the WS-Transaction business activity (WS-T BA) protocols. In the remainder of this paper, we focus on concrete policies to support transaction processing that is compliant to published Web services specifications. We exemplify concrete policies for the Web services specifications WS-Coordination, WS-Transaction, and WS-ReliableMessaging, which were proposed by IBM, Microsoft, and BEA. The overall framework of client and provider policies and transaction coupling modes is illustrated in Fig. 6. The figure shows one client and three service providers. The client’s policy declares support for WS-T AT and WS-RM interactions. The three providers each declare a different (concrete) transaction policy: Provider A supports WS-T AT interactions, Provider B supports WS-T AT and WS-RM interactions, and Provider C supports WS-RM interactions. The client executes two transactional processes, one of which follows the DTP-style using two WS-AT transaction coupling modes, the other one following the QTP-style using a single WS-RM transaction coupling mode. 3.2. DTP, QTP, and CTP policies We define concrete DTP, QTP and CTP policy assertions that apply to the three Web services specifications WS-Coordination, WS-Transaction, and WS-ReliableMessaging. WS-Coordination [9] defines a framework of common mechanisms (including support for coordination context propagation and participant registration) that can be used to implement different coordination

66


Fig. 6. Transaction policy framework.

types. A coordination type is a set of coordination protocols, where a coordination protocol is the set of well-defined messages that are exchanged between the services that are to be coordinated. WS-Transaction [8] leverages the WS-Coordination specification in that it defines the two coordination types of atomic transactions and business activities, which support short-running transactions and long-running transactions, respectively. WS-ReliableMessaging [15] defines a protocol that allows messages to be delivered reliably in the presence of software or system failures. The policies that apply to these specifications are expressed using the WS-Policy [19] language. WS-Policy is a general-purpose, extensible grammar to describe a broad range of requirements, preferences, and capabilities in an XML Web services-based system. The policies can be attached to various elements of a Web service definition [18]. We propose transaction policy attachments to WSDL definitions and to BPEL [12] processes to describe transactional service providers and transactional processes, respectively. Transaction policy attachments and their semantics are described below in Section 3.3. 3.2.1. DTP policies DTP-style interactions are supported by the WS-Transaction atomic transaction (AT) coordination type. In order to define DTP policies that apply to WS-Coordination and WS-Transaction, we define the element (see Appendix A). assertions are made in terms of WS-Coordination coordination types and protocols. The following example shows a DTP policy named ‘‘ATPolicy’’ defining optional support for the WS-Transaction AT coordination type and the WS-Transaction two-phase commit protocol.


67

The element identifies a WS-Policy coordination assertion and, as such, a statement that is part of the policy definition container (the element). A coordination type is associated with each assertion, and protocol elements identifying the coordination protocols (of the coordination type) that the policy subject participates in can be defined. Different policy processing semantics (such as whether a protocol usage is required or optional) can be expressed through the usage attributes as defined in the WS-Policy language (, , , , ) [19].

3.2.2. QTP policies The QTP style requires the transaction participants to support a reliable messaging protocol. More specifically, request messages and reply messages are required to be delivered with an exactly-once delivery semantics. The WS-ReliableMessaging protocol defines WS-Policy assertions for reliable messaging, an example of which is given below. The policy describes a requirement for a specific protocol version (using the assertion of the WS-PolicyAssertions [26] specification), and indicates that messages should be delivered exactly-once. Unlike in DTP, no global transaction (and shared transaction context and distributed participant registration) exists in QTP. The QTP participants are loosely-coupled, and their coordination is achieved by the applications, which rely only on reliable messaging but no other coordination middleware. Therefore, the basic WS-ReliableMessaging policy assertions can be considered sufficient for a service to declare its support to engage in a QTP interaction. For advanced QTP models, however, which may include additional coordination middleware support, a WS-Coordination compliant coordination type can be defined. For example, a coordinator may be used to create and propagate a QTP context to help correlate request and reply messages. A corresponding QTP policy could then be expressed using a assertion, referencing the WS-ReliableMessaging protocol as a coordination protocol of the QTP coordination type.

68


3.2.3. CTP policies Both WS-Transaction and BPEL define mechanisms that can be used to support CTP-style interactions. The WS-Transaction business activity (BA) coordination type provides a mechanism for distributed, interoperable compensation-based transaction processing. In this context, a business activity is a distributed unit of work. It is possible that a successfully completed business activity needs to be undone, in which case ‘‘compensate’’ messages are sent to all participants; otherwise, the activity is eventually closed, and ‘‘close’’ messages are sent to all participants. A Web service participating in a business activity must maintain sufficient context in order to semantically reverse its part of the completed activity, until such time as the activity is closed. We define a CTP policy for WS-Transaction BA enabled Web services using the policy as follows: BPEL provides a mechanism for centralized, internal compensation processing. Compensation handlers are defined as part of the process model and specify the activities needed to undo previously completed activities. When a ‘‘normal’’ activity completes successfully, any associated compensating activities are recorded. If a scope (or the process as a whole) needs to be undone, the recorded compensating activities are invoked. When the process completes successfully, the compensating activities are forgotten. Any partner invoked as part of a compensating activity is accessed according to its application-level interface; no special coordination protocol is used. Since BPEL compensation processing is internal, there is generally no need for explicit CTPpolicies. There are, however, two important cases to consider for which CTP-policies make sense. In the case that a BPEL process instance is distributed over multiple nodes in a network, a coordination protocol is needed to drive completion and compensation across these nodes. While the BPEL specification shows how the WS-Transaction BA protocol might be used, it limits its


69

usage to the case of localized execution [12]. For distributed execution according to the WSTransaction BA coordination type, each node could have a CTP-policy advertising its ability to participate in distributed compensation. In the case of BPEL instance-level compensation, enabled by the enableInstanceCompensation ¼ 0yes0 process attribute, successfully completed process instances can be compensated using platform specific mechanisms. If the supported mechanisms include external coordination according to the WS-Transaction BA coordination type, then the BPEL service provider could advertise a CTP-policy. 3.3. Policy attachments The above DTP, QTP and CTP policies can be meaningfully attached to various elements of a Web service definition, following the flexible model of WS-PolicyAttachments [18]. In this section, we describe a recommended use of attaching transaction policies to WSDL definitions and BPEL processes. 3.3.1. Provider policies In order to define a provider transaction policy, the assertion (and/ or a reliable messaging protocol assertion) is attached to a Web service port binding. This describes the concrete coordination (transaction) capabilities of a deployed Web service that can be invoked. Consider as an example a banking Web service that provides operations to transactionally debit and credit customer accounts using the WS-Transaction atomic transaction coordination type. A assertion can be attached with a WSDL port binding definition of the service using the element of the WS-Policy specification and the ‘‘ATPolicy’’ defined previously. 3.3.2. Client policies In order to define client transaction policies, the DTP, QTP and/or CTP policies are attached to BPEL [12] processes. BPEL (Business Process Execution Language for Web Services) is a language for specifying business processes, where the processes created can be abstract processes or executable processes. A WSDL description can be derived from the process definition; therefore, every BPEL process is a Web service, and the process can be regarded as the specification of an implementation of the Web service as a composition of other services. The services that are being composed through a BPEL process are referred to as partners of the process. In order to define transactional requirements on partners, transaction policies are attached to the BPEL construct. Since the definition of a BPEL process identifies only

70


the portTypes supported by the process partners, and not actually deployed ports, the attachment of a transaction policy to a element has an interpretation similar to the attachment of a policy to a WSDL type definition [18]: as a policy that must be satisfied by every deployed service that may be chosen to provide the corresponding partner functionality. In our case, it describes the concrete coordination (transaction) requirements of the client on a provider that participates in a coordinated activity. Furthermore, a transaction policy is attached to the BPEL or element. A BPEL process/scope with a transaction policy attachment represents the transaction (the client performing multiple transactional invocations). As in the previous case, since the BPEL definition does not correspond to a specific deployment of the process, the attachment of the policy to a process/scope implies the requirement that every deployment of the process is executed according to the policy. We refer to a BPEL process that has attached transaction policies as a T-BPEL (transactional BPEL) process. A (simplified) T-BPEL process example of an atomic funds transfer transaction is given below. The WS-Transaction AT policy defined above is attached to two partners. This declares that any Web service bound to the partners must support that transaction coordination type. The same policy is also attached to the process to declare the required coordination type. Note that a BPEL process may comprise multiple scopes for which different transactional partners and coordination types can be declared. It should also be noted that the T-BPEL policy attachments presented here represent concrete deployment choices that may or may not be explicit in the authored BPEL text. For example, a platform that supports recoverable BPEL instances could implicitly attach appropriate T-BPEL assertions at deployment time, requiring that each partner invocation be reliable by some means supported by the targeted environment. T-BPEL annotations might also be derived from more abstract BPEL language extensions for transactions and reliable execution. It may also be the case that the entire (T-)BPEL text is generated from a higher-level language specification that includes transaction constructs.

4. Transaction coupling modes Clients bind to providers at various times such as BPEL deployment time or dynamically through endpoint references [5]. Whenever binding occurs, policies on both the client and provider side must be evaluated to validate that the policies do not conflict with one another and to resolve


71

any alternatives or preferences expressed in either policy. The resolution of policies into a coupling mode, and, as introduced here, of transaction policies into transaction coupling modes, can be established transparently by a policy matching algorithm using a policy middleware. In this section we describe the resolution phase for both deployment time and run-time matching and provide a sketch of our matching algorithm. 4.1. Policy verification and deployment Our T-BPEL language includes policies attached at both the business process scope level and on individual abstract partner declarations. Matching policies for T-BPEL is carried out in two stages. First, static verification of the BPEL process flow takes place to ensure that partners are only used in scopes where the partner declaration supports at least the policies needed by that scope. Here we briefly describe the algorithm for static verification. Verification is implemented as a depth first walk of the BPEL process tree. At each node declaring a scope, policies are pushed onto a policy stack. When a BPEL construct is encountered that makes use of an abstract partner (such as an invoke statement), the policy attached to the abstract partner is checked to make sure it satisfies all the policies on the stack. As the depth first walk exits scope nodes, their attached policies are popped off the stack. Static verification ensures a correct BPEL process flow before instantiating the abstract partners. The second stage of matching occurs when abstract partners are instantiated. The endpoints of abstract partners may be instantiated at either deployment time or at run-time. When instantiation occurs, policies are resolved into a coupling mode between the BPEL process and the partner. Deployment time instantiation involves feeding the WSDL of concrete partners to a T-BPEL compiler (see Section 5 below), where the WSDL of each partner is annotated with transaction policies, as described earlier. From the WSDL annotations we can create an effective policy for the partner to be matched against the policy attached to the abstract partner declaration. This creates a coupling mode which is then passed onto the policy middleware component (shown as Policy Info in Fig. 7) to be used at run-time for guiding execution of transactional and reliable messaging components. Some partners may be instantiated at run-time through the use of endpoint references. This is achieved in BPEL through the use of the assign activity. The T-BPEL compiler generates code for each assign statement to retrieve WSDL for the endpoint reference. Matching follows as described above to create a coupling mode for the dynamically assigned partner. The construction of these coupling modes from client (BPEL process) and provider (partner) policies is achieved through our policy matching algorithm. 4.2. Policy matching The WS-Policy language provides operators for composition of policies from concrete policy assertions. Assertions are domain specific and their semantics are described in specifications such as WS-Coordination, WS-Transaction, and WS-ReliableMessaging. In addition, preferences [19] may be attached to policies in the case where choices are available. The purpose of our policy matching algorithm is to find a set of assertions that is acceptable to both client and provider policies and maximizes the preferences of both.

72

S. Tai et al. / Data & Knowledge Engineering 51 (2004) 59–79 T-BPEL + WSDL

Partner WSDL

T-BPEL

H T M L

Parse/Process

Java Impl

Deployer

Deploy Desc.

Policy Info

T-BPEL Service Policy Middleware

WSTPM SOAP Engine (Axis) Application Server (Tomcat) Fig. 7. Prototype architecture.

Policy assertions are composed from the , , and operators [19]. This corresponds to a logic where assertions are Boolean variables and the operators map to n-ary AND, OR, and XOR. We have not included the concept of a NOT operator in our interpretation of WS-Policy. Assertions are implicitly false by excluding them from the policy. The following example illustrates a policy composing different concrete policies using the and operators. The example also illustrates the use of the attribute.


73

The first step of the algorithm is to enumerate the acceptable assertion sets of both client and provider policies. An acceptable assertion set consists of a list of assertions that when set to true reduce the entire policy to true. For each set, all assertions that are not on the list are set to false. The preferences of assertions are summed over each list to yield a total preference for each set. Next, the acceptable policy sets of both client and provider are compared to find matching sets that contain exactly the same list of assertions. This may yield any number of matching sets. The set with the largest total preference sum for client and provider sets realizes the transaction coupling mode for interaction. This set of assertions is interpreted by the middleware to drive transactional and reliability mechanisms. If no matching sets are found then the client and provider are incompatible. A deployment time mismatch may be resolved by a BPEL client by changing the policy or choosing another partner provider. At runtime, mismatches result in runtime exceptions that must be handled by the application appropriately. More details on our policy matching approach can be found in [33].

5. Middleware prototype Our approach of transaction policies for service-oriented computing has been implemented in terms of a research middleware prototype. The client programming model is T-BPEL as introduced above. Service providers declare and attach transaction policies in their respective WSDL. Fig. 7 depicts the architecture of our prototype implementation. The T-BPEL compiler deploys the T-BPEL business process flow as a service from the provided definitions. The policy middleware matches client policies with provider policies and enforces them at run-time. The WSTPM (Web Services Transaction Processing Monitor) component handles transaction management and coordination; this component is an implementation of the WS-Transaction coordination types. At the lowest level, the middleware depends on the interfaces provided by the Tomcat application server [3] and the Axis SOAP engine [2]. The T-BPEL compiler takes as input 1. A BPEL business process description annotated with transaction policies, and its corresponding abstract service description in WSDL. 2. WSDL descriptions for each of the invoked partners potentially having transactional policies attached to their service bindings. These definitions are parsed and processed to generate a Java implementation equivalent to the business process flow, a deployment descriptor for deploying it on the Axis SOAP engine, and an XML document containing information for the policy middleware. During the process, the compiler also consults the policy middleware to match the client and provider policies while generating the Java implementation. As described in Section 4, a matching set must be found or exceptions will be raised. The implementation of a partner interaction reflects the coupling mode for that partner derived from the policy matching step. The Deployer component installs the generated code as a SOAP based service having parameters given by the deployment descriptor. The generated service interfaces with the WSTPM

74


component for executing and coordinating the transaction. It also interfaces with the policy middleware to enforce the contract with the partners at run-time. Our approach for deploying a BPEL business process flow is unique in the sense that no runtime component is required to manage and orchestrate the BPEL flow itself. Instead, the flow definition is transformed into a standard SOAP based service. By transparently configuring middleware mechanisms based on both client and provider policies we are able to support a reliable SOC environment where business processes are carried out by autonomous hosts. 6. Related work The work presented in this paper combines policy-based management and transaction processing for service-oriented computing. Related work exists in the areas of policies and transactions. Related policy work includes research on policy-based network management (see, for example [28,29]), which provides techniques for the definition and deployment of Quality-of-Service policies (for example, to determine applications or users which are allowed to have a preferential access to network resources). In the context of service-oriented computing, electronic contracts [17] define agreed-upon characteristics of (Web) services and a model for measuring, evaluating, and managing the compliance of these characteristics. Their representation involves assertions comparable to our policies, and algorithms for assertion match-making and negotiation have been developed. However, contracts such as those described using Web service-level agreements (WSLA) [24] focus on locally (non-distributed) measurable phenomena as seen by the client only. For example, a service provider’s performance offerings can be measured and matched with a client’s performance expectations as specified in a contract. While contract adherence or violation can be determined, a policy-driven configuration of client and server middleware to ensure (transactional) interoperability is not addressed. With our system, a transaction is only executed if a compatible policy composition has been determined. Our previous work on Transactional attitudes (TxA) [25] described a framework and middleware based on abstract, pattern-based transaction policies. The work presented in this paper focuses on concrete policies that apply to relevant Web services specifications. Provider transaction policies relate to declarative transaction attributes as known from component models like Enterprise JavaBeans [30]. While EJB transaction attributes are used to communicate transaction requirements from a service developer to the deployment environment, our provider policies are used to communicate the transaction capabilities of a deployed service to its potential clients. In this sense, combinations of EJB transaction attributes and transaction policies are possible: for example, an Entity EJB with transaction attribute ‘‘Mandatory’’ could be deployed as a Web service with a DTP provider policy; a Message Driven Bean (MDB) with transaction attribute ‘‘Required’’ could be deployed as a Web service with a QTP provider policy. Furthermore, our transaction policies are not a single attribute but assertions defined using an expressive policy description language. Unlike EJB transaction attributes, which do not represent the client, our approach also allows transactional clients to explicitly state their expectations on transactional services, and allows the middleware to detect mismatches between client requirements and service capabilities.


75

The notion of a coupling mode has also been used in active database systems [14] and middleware-mediated transactions [23], which both encompass diverse policies to specify the transaction relationship of (database) events, condition evaluation, and action execution. Unlike these coupling modes, the transaction coupling modes as introduced here are run-time contracts between independent services that are based on matched transaction policies. Transaction specifications for SOC other than WS-Coordination and WS-Transaction, including the WS-CAF [7] and BTP [10], have been proposed. While we focused on concrete transaction policies and coupling modes that apply to specific Web services specifications, we believe that the concepts presented are not restricted to these specifications, but can be applied to transactional Web services in general. 7. Summary Transaction policies for service-oriented computing are declarative assertions of capabilities, requirements, and preferences for reliable service interactions. In this paper, we presented a new approach to policy-based transactional coordination of services, introducing concrete DTP, QTP, and CTP policies that apply to the Web services specifications WS-Coordination, WS-Transaction, and WS-ReliableMessaging and which can be attached to WSDL and BPEL definitions. We described the policy verification and matching algorithm implemented to realize transaction coupling modes as the run-time contracts between deployed services and processes, and presented a middleware prototype supporting the concepts proposed. Transaction policies and coupling modes advance SOC towards reliable service interactions according to Web services technology and standards.

Appendix A This appendix defines the element to assert a requirement or ability for a service to participate in a coordinated activity. Such assertions are made in terms of coordination types and coordination protocols as defined in the WS-Coordination [ ] specification. The element is an extension to the element of the WSPolicy [ ] specification. Preference and usage attributes of the WS-Policy language apply. * * *

76


The following describes the attributes and tags listed in the schema outlined above: /CoordinatedService This identifies a coordinated service assertion. /CoordinatedService/@CoordinationType This mandatory attribute is the URI of the coordination type associated with the assertion. The range of coordination types is extensible (as defined in the WS-Coordination specification), with each coordination type defined in a published or proprietary specification (such as those defined in the WS-Transaction specification). The only requirement is that coordination types are unique (i.e., represented as URIs) and that all parties processing the policy assertion understand the semantics of that coordination type. /CoordinatdService/@wsp:Preference This optional attribute contains the preference of the coordination assertion; the type and semantics of this attribute are defined in the WS-Policy specification. /CoordinatedService/@wsp:Usage This mandatory attribute contains the usage of the assertion; the type and semantics of this attribute are defined in the WS-Policy specification. /CoordinatedService/@{any} Optional extensibility attributes used to express additional information about the subject application’s asserted coordination capabilities/requirements. /CoordinatedService/Protocol A Coordinated Service assertion includes zero or more protocol elements identifying the coordination protocols (of the asserted coordination type) that the subject application may participate in. In general, the role that the subject application plays in the protocol is defined by where the policy assertion is attached. In cases where this is not sufficient, protocol-specific extensions (attributes and/or elements) should be used to disambiguate the subject application’s role in the protocols. /CoordinatedService/Protocol/@ProtocolIdentifier This mandatory attribute identifies a protocol, belonging to the asserted coordination type, that the subject application participates in. /CoordinatedService/Protocol/@{any} Optional extensibility attributes used to express additional information about the subject application’s participation in the protocol. /CoordinatedService/Protocol/{any} Optional extensibility elements used to express additional information about the subject application’s participation in the protocol.


77

/CoordinatedService/{any} Optional extensibility attributes used to express additional information about the subject application’s asserted coordination capabilities/requirements.

References [1] G. Alonso, F. Casati, H. Kuno, V. Machiraju, Web Services: Concepts, Architectures and Applications, SpringerVerlag, Berlin, 2004. [2] Apache Axis. Available from . [3] Apache Jakarta Project. Available from . [4] T. Bellwood, L. Clement, D. Ehnebuske, A. Hately, M. Hondo, Y.L. Husband, K. Januszewski, S. Lee, B. McKee, J. Munter, C. von Riegen, The Universal Description, Discovery and Integration (UDDI) Protocol, 2002. Available from . [5] D. Box, F. Curbera (Eds.), Web Services Addressing (WS-Addressing), IBM, BEA, and Microsoft, 2003. Available from . [6] D. Box, D. Ehnebuske, G. Kakivaya, A. Layman, N. Mendelsohn, H. Nielsen, S. Thatte, D. Winer, Simple Object Access Protocol (SOAP) 1.1., W3C, 2000. Available from . [7] D. Bunting, M. Chapman, O. Hurley, M. Little, J. Mischkinsky, E. Newcomer, J. Webber, K. Swenson, Web Services Composite Application Framework (WS-CAF), Arjuna, Fujitsu, IONA, Oracle, and Sun, 2003. Available from . [8] F. Cabrera, G. Copeland, B. Cox, T. Freund, J. Klein, T. Storey, S. Thatte, Web Services Transactions (WSTransaction) 1.0., IBM, BEA, and Microsoft, 2002. Available from . [9] F. Cabrera, G. Copeland, T. Freund, J. Klein, D. Langworthy, D. Orchard, J. Shewchuk, T. Storey, Web Services Coordination (WS-Coordination), IBM, BEA, and Microsoft, 2002. Available from . [10] A. Ceponkus, S. Dalal, T. Fletcher, P. Furniss, A. Green, B. Pope, Business Transaction Protocol, 2003. Available from . [11] E. Christensen, F. Curbera, G. Meredith, S. Weerawarana, Web Services Description Language (WSDL) 1.1., W3C, 2001. Available from . [12] F. Curbera, Y. Goland, J. Klein, F. Leymann, D. Roller, S. Thatte, S. Weerawarana, Business Process Execution Language for Web Services (BPEL4WS), IBM, BEA, and Microsoft, 2002. Available from . [13] F. Curbera, R. Khalaf, N. Mukhi, S. Tai, S. Weerawarana, The next step in Web services, Communications of the ACM: Service Oriented Computing 46 (10) (2003) 29–34. [14] U. Dayal, A. Buchmann, S. Chakravarthy, The HiPAC Project, in: J. Widom, S. Ceri (Eds.), Active Database Systems: Triggers and Rules for Advanced Database Processing, Morgan Kaufmann Publishers, San Francisco, CA, 1996. [15] C. Ferris, D. Langworthy (Eds.), Web Services Reliable Messaging Protocol (WS-ReliableMessaging), IBM, Microsoft, BEA, and TIBCO, 2003. Available from . [16] J. Gray, A. Reuter, Transaction Processing: Concepts and Techniques, Morgan Kaufmann Publishers, San Francisco, CA, 1993. [17] P. Grefen, K. Aberer, H. Ludwig, Y. Hoffner, Crossflow: Cross-organizational workflow management for service outsourcing in dynamic virtual enterprises, IEEE Data Engineering Bulletin 24 (1) (2001). [18] M. Hondo, C. Kaler (Eds.), Web Services Policy Attachment (WS-PolicyAttachment), IBM, BEA, Microsoft, and SAP, 2002. Available from . [19] M. Hondo, C. Kaler (Eds.), Web Services Policy Framework (WS-Policy), IBM, BEA, and Microsoft, 2002. Available from .

78


[20] ICSOC 2003. The First International Conference on Service-Oriented Computing, Trento, Italy, 2003. Available from . [21] R. Khalaf, F. Curbera, W. Nagy, S. Tai, N. Mukhi, M. Duftler, Understanding Web services, in: M.P. Singh (Ed.), Practical Handbook of Internet Computing, CRC Press, 2004. [22] F. Leymann, D. Roller, Production Workflow: Concepts and Techniques, Prentice-Hall, Upper Saddle River, NJ, 2000. [23] C. Liebig, S. Tai, Middleware-Mediated Transactions, in: Proc. 3rd International Symposium on Distributed Objects and Applications, IEEE, 2001. [24] H. Ludwig, A. Keller, A. Dan, R.P. King, R. Franck, A service level agreement language for dynamic electronic services, Journal of Electronic Commerce Research 3 (1 & 2) (2003). [25] T. Mikalsen, S. Tai, I. Rouvellou, Transactional attitudes: reliable composition of autonomous Web services, in: Proc. Workshop on Dependable Middleware-based Systems at the International Conference on Dependable Systems and Networks, IEEE, 2002. [26] A. Nadalin (Ed.), Web Services Policy Assertions (WSPolicyAssertions), IBM, BEA, Microsoft, and SAP, 2002. Available from . [27] M. Papazoglou, D. Georgakopoulos, Service-oriented computing, Communications of the ACM: Service-Oriented Computing 46 (10) (2003) 25–28. [28] R. Rajan, D. Verma, S. Kamat, E. Felstaine, S. Herzog, A policy framework for integrated and differentiated services in the Internet, IEEE Network 13 (5) (1999) 36–41. [29] M. Sloman, Policy driven management for distributed systems, Journal of Network and Systems Management 2 (4) (1994) 333–360. [30] Sun Microsystems, Enterprise JavaBeanse Specification, v1.1, 2000. Available from . [31] S. Tai, T. Mikalsen, I. Rouvellou, Transaction middleware, in: Q. Mahmoud (Ed.), Middleware for Communications, John Wiley & Sons, 2004. [32] Web Services specifications. Available from . [33] E. Wohlstadter, S. Tai, T. Mikalsen, I. Rouvellou, GlueQoS: Middleware to Sweeten Quality-of-Service Policy Interactions, submitted to International Conference of Software Engineering, 2004. Stefan Tai is a Research Staff Member at the IBM T.J. Watson Research Center in Hawthorne, NY, USA. Stefan does research on reliable middleware systems and middleware-based software architectures. Since joining IBM Research in 1999, he has been working on transaction, messaging, and Web services projects. Stefan holds a Ph.D. degree in Computer Science from Berlin University of Technology, Germany.

Thomas Mikalsen is an Advisory Software Engineer at the IBM T.J. Watson Research Center in Hawthorne, New York, USA. Since joining IBM in 1997, Thomas has been designing and developing transactional middleware solutions, and is currently working on middleware for reliable (Web) service-oriented computing. He holds a M.S. in Computer Science from Polytechnic University in New York and a B.S. in Computer Science from Rochester Institute of Technology.


79

Eric Wohlstadter is a Ph.D. candidate at the University of California, Davis. His interests include software reuse and domain-specific middleware. He has worked on several NSF funded projects including the CalAggie Wrap-o-Matic and DADO. Recently, Eric has focused on providing middleware support for dynamic Service-Oriented composition.

Nirmit Desai is a doctoral student and a research assistant at the Department of Computer Science, North Carolina State University, USA. He received an M.S. degree in Computer Science from North Carolina State University in 2003. He was an intern at IBM Research during the summer of 2003. His research interests lie in the area of distributed systems middleware and service-oriented solutions for developing business processes.

Isabelle Rouvellou is a Research Staff Member and manager of the Advanced Enterprise Middleware Department at the IBM’s T.J. Watson Research Center, USA, working on the design and implementation of middleware enabling the next generation of distributed applications. Isabelle holds a number of IBM awards for the contributions she made to IBM’s Websphere family of products. She is also a co-author of several papers and patents in the field of distributed object technology, messaging, and software engineering. She received a Ph.D. from Columbia University, USA.