Towards Identifying Representative Characteristics of Web Services Compositions Muhammad F. Kaleem Technical University HamburgHarburg [email protected] Abstract With web services technologies becoming increasingly mature, there is substantial academic research and industrial focus on web services compositions, or composite services. Composite services represent aggregations of individual web services, or other composite services, and can effectively model complex business processes. In this paper we highlight important characteristics that can be deemed representative of composite services, and discuss how these characteristics relate to each other. We also describe a selection of aspects relevant with respect to their application to composite services, and explain how they affect the highlighted characteristics. In this regard, the paper can serve as a reference for web services composition methodologies, by helping to illustrate how a particular methodology affects the characteristics identified in this paper. This, in turn, should help improve architectural patterns and design methodologies for web services composition.

1.

Introduction

Web services compositions represent an aggregation of services, both individual web services, or composite services, to provide enhanced functionality, e.g. a mechanism for supporting business-to-business and intraenterprise application integration [1]. Important is the ability of composite services to implement business collaborations by inter-connecting web services provided by different organizations [2]. In this paper, we take composite services to mean web services compositions orchestrated from individual web services belonging to different, autonomous organizations. Within this context, the focus of this paper is on highlighting important characteristics representative of composite services modeling business processes spanning multiple organizations. Some of these characteristics are the same as those identified in [3] to study interaction issues in B2B e-commerce. Composite services have an important

role to play in this area, therefore the relevance of these characteristics extends to composite services as well. We also discuss the inter-relation of these characteristics. The identification and understanding of these characteristics and their mutual inter-relation can help in analyzing composite service methodologies with respect to how a methodology bears on these characteristics. Furthermore, we discuss a selection of important aspects relevant to composite services, which are applicable at the composition stage, as well as the execution stage of composite services. We also state the affect these aspects may have on the highlighted characteristics. This can further qualify analysis of composite service methodologies in relation to the use of these aspects by a particular methodology. As a result, an improvement in architectural principles and design methodologies for web service composition can be expected. We would also like to point out that in this paper the terms web services compositions and composite services are used interchangeably, as are the terms service and web service. At places we may also mention two roles, a web service provider, and a composite service provider. The former role is easy to perceive, whereas the latter role is an abstract concept, and does not necessarily imply a centralized entity responsible for composing a web service. The term constituent service is used for individual web services making up the composite service. These may also be described by the term participant. However, participant may also refer to the composite service itself, but the difference in meaning should be clear from the context in which the terms are used. It would also be relevant to mention that the term composition methodology used in this paper does not just refer to the process of composition of web services, but covers the eventual execution phase of the composite service as well.

2.

Web services composition

There are different methodologies for composing web services, available in the form of industry standards, (e.g. [4]), or as the subject of numerous research efforts,

Witold Abramowicz (ed.), Business Information Systems, Proceedings of BIS 2004, Poznan, Poland

BUSINESS INFORMATION SYSTEMS – BIS 2004

2 (e.g. [5]). A classification of composition mechanisms based on their approach and applicability is presented in [6]. The classification presented in [6] is at the level of approaches to web services composition. Different composition methodologies, in turn, may conform to different approaches. This paper highlights characteristics that relate to composite services in general, regardless of the approach to composition taken by the underlying methodology. Similarly, the aspects we discuss in this paper are relevant for composition methodologies in general, with respect to their application within composition methodologies. We also discuss how these aspects influence the highlighted characteristics, which should serve as an indication of the way in which a particular methodology, employing the aspect(s), may affect the nature and properties of the composite service.

3.

Characteristics

The characteristics we consider in this paper are loosecoupling, autonomy, reliability, consistency and adaptability. These relate to the nature of composite services (loose-coupling), the setting in which composite services will operate, e.g. business-to-business interactions between autonomous organizations (autonomy, consistency), and the general applicability of composite services to real-world scenarios (reliability, adaptability). It should be noted that this informal organization of the characteristics is not exclusive, rather there is competing interaction between the characteristics. In the next sections we discuss the characteristics one by one. Loose-coupling: Loose-coupling is a representative characteristic of web services, whether at the level of individual web services, or at the level of composite services [7]. In the context of composite services, we take loose-coupling to mean the low level of coupling, or dependency, of constituent services on each other. In the scenarios for composite service applications which we are interested in, namely business to business interactions, the constituent services may belong to different organizations. A low level of coupling between the constituent services suits such a scenario very well. This is because web service providers (e.g. different organizations) will typically want to avoid tight-coupling of their services to other services over which they have no control. A low level of coupling between constituent services also maintains a degree of isolation between them, preserving the autonomy of participants, and enhancing the adaptability of the composite service. On the other hand, loose-coupling also creates challenges for the reliability and consistency of the composite service. An example could be the difficulty of appropriate faulthandling (necessary for reliability) for an application spread over different, loosely-coupled participants, as

compared to traditional, tightly-coupled distributed systems (e.g. CORBA [8]). Autonomy: Autonomy of constituent services - which may belong to independent service providers - within a composite service forms an important characteristic of composite services. It also fits in naturally with the loosely-coupled nature of inter-service interaction. As an example of the autonomy of web service providers, we mention that they may, at their own will and timing, update the interface of the web service being provided [9]. Similarly, a web service provider may go out of service, and the web service may no longer be available. The business-to-business interaction scenarios typical of composite services deployment will generally involve long-running business processes [10], therefore constituent service interface change or service unavailability over the period of time are relevant issues for the composite service. Additionally, these issues affect the reliability of the composite service, by disrupting the ability of the composite service to perform the task it is defined for in the expected manner. Autonomy also applies seen from the view of the composite service. For example, a constituent service within a composite service may be swapped (by the composite service provider) for another service offering the same functionality, but at a lower price [7]. In this case autonomy contributes to the adaptability of the composite service, though can affect consistency, as we will discuss later. Reliability: Reliability of composite services may hold different meanings based on the context it is defined in. Reliability is considered the requirement for appropriate handling of all failures and concurrent activities in [11]. In this regard, composite service reliability is normally associated with transactional mechanisms and failure handling [12-14]. On the other hand, reliability is also considered as a QoS parameter [15], which represents a non-functional property [16]. A more comprehensive definition of composite service reliability is given in [17], and is the view we ascribe to. Reliability of composite services is also influenced by the two characteristics discussed previously, and extends to the composition phase through to the execution phase, as discussed in [17]. For example, service unavailability or service interface change poses challenges for the reliability of the composite service execution. However, reliability is not just limited to composite service execution. An example could be a composition process that does not take into account the functional and non-functional properties of the individual web services. Since web service providers can autonomously determine these properties, failing to take these into account in context of the business policies modeled by the composite service will affect reliability at the composition phase, and manifest itself at the execution phase as well. Moreover, newer approaches of web services composition may allow the composition and execution phases to be interleaved [5], and such dynamic

Witold Abramowicz (ed.), Business Information Systems, Proceedings of BIS 2004, Poznan, Poland

TOWARDS IDENTIFYING REPRESENTATIVE CHARACTERISTICS OF WEB SERVICES COMPOSITIONS

composition would put even more demands on the reliability of the composite service. Consistency: Consistency has a well-defined meaning in traditional transactional systems [18]. Carried over to composite services, consistency has relevance both with respect to transactional mechanisms for web services and their ramifications [19], as well as issues related to interactions between web services [20]. Moreover, the non-functional properties of constituent services also play a role in the overall consistency of the composite services. For example, the time period over which a constituent services guarantees availability (a non-functional property, as opposed to the operation(s) that could be invoked on the constituent service, which would represent a functional property) has to be taken into account in the context of the business policies behind a composite service. The consistency characteristic has relevance for the composition, as well as the eventual execution of the composite service. Here we distinguish between inconsistency resolution, and consistency maintenance. Inconsistency resolution takes the form of respecting constraints, both functional and non-functional, placed by individual, autonomous services, and reconciling the constraints to the business policies of the composite service. Respect for constraints may include, for example, taking into account the message formats expected by the constituent services, the transactional protocols supported, or the billing strategy of a web service provider. Consistency maintenance is more relevant for composite service execution stage, and relates to maintenance of respect for constraints during this stage. An example for this could be the proper execution of the designated compensation operation in case of a failure during composite service execution. The propriety of the compensation operation execution would be determined with respect to fulfillment of constraints represented by the business policies driving the composite service. This could mean, for example, that the compensation operation restores the system to a state that does not violate these business policies, as well as the policies of the web service providers. It is easy to deduce that addressing the consistency characteristic requires constraining the loosecoupling and autonomy characteristics, but contributes to the reliability of composite services. Adaptability: Adaptability is related to the ability of the composite service to deal with changes. These changes may be required as a result of some action on the side of constituent web services, e.g. a service not being available anymore, or on the side of the composite service, e.g. a composite service provider swapping a constituent service for another service, as discussed previously. Different methodologies contributing to adaptability in composite services have been proposed. An example is the concept of service communities presented in [21], which are repositories of functionally similar services, any of which could be chosen to service

3

an invocation. Adaptability may also be necessitated by application of a composite service to achieve business goals different from those for which the composite service may initially have been conceived. This may be categorized as composite service re-use, and an approach is presented in [22]. This approach describes the concept of a service component class that represents a composite service, which may be re-used and specialized as a normal software component. Adaptability is facilitated by loosecoupling and autonomy, and may have ramifications for reliability and consistency of the composite service. Referring back to the previously presented example in which a constituent service is swapped through another, functionally similar service, an inconsistency situation may arise if the non-functional properties of the swapped services are different. Adaptability is constrained by having to take into account the needs for consistency and reliability, and facilitated by loose-coupling.

4.

Important aspects for composite services

In this section we consider some important aspects that are relevant in the context of their application to composite services, both at the composition, as well as the execution stages, and have bearing on the characteristics described in the previous section. We also describe the interplay of these aspects. This list of aspects is not exhaustive, and we expect it to evolve further. We discuss these aspects next. Transactional mechanisms: Transactional mechanisms are generally used as a means to guarantee reliability of composite services, and as such have a prominent effect on the reliability characteristic described previously. Also relevant to state is that according to [17] transactional mechanisms contribute to the reliability of execution phase of a composite service, and are applied for failure management and exception handling scenarios. Transactional requirements of composite services are taken into account in newer industry standards [23, 24]. Such standardization effort will help in adoption and eventual interoperability of transaction management in composite services. On the other hand, transactions management for composite services also represents challenges for the consistency of composite services (e.g. as described in [25]). These challenges stem from the loosely-coupled nature of composite services and the autonomous nature of service providers. In the next sections we will discuss which aspects of composite services may be helpful in this regard. Inconsistency resolution, respect for constraints: We previously described consistency as an important characteristic for composite services, and distinguished between inconsistency resolution and consistency maintenance. In this section we discuss important factors

Witold Abramowicz (ed.), Business Information Systems, Proceedings of BIS 2004, Poznan, Poland

BUSINESS INFORMATION SYSTEMS – BIS 2004

4 relevant for consistency of composite services. Inconsistency may result due to the constraints expected by constituent services not being respected in the context of the composite service. These constraints may be at the level of functional or non-functional properties. For example, a constituent service may expect a particular order of invocation of its operations. Such a requirement is not easily expressed using existing web service description mechanisms, e.g. WSDL (http://www.w3.org/TR/wsdl). In the same way, different service providers expected to participate in a composite service may have different transactional policies, or may place constraints on compensation mechanisms. Identification of consistency conditions, and respect for constraints represented by them, leads towards inconsistency resolution for the overall composite service. It is important to address the requirements of the constituent services in the context of the requirements of the composite service. Here we may refer to an example presented in [10]. This example describes how the overall system represented by a composite service may be in an inconsistent state even after the successful cancellation of a transaction. This can result because one participant expected a cancellation fee, a constraint which was not taken into account in the context of the composite service. Inconsistency resolution holds even if the composition and execution of the composite service were interleaved, since inconsistency resolution could take place incrementally. In the next section, we discuss what mechanisms may be helpful with inconsistency resolution. Important in this regard is that any mechanisms for inconsistency resolution should not infringe upon the loose-coupling and autonomy characteristics of the composite service. Enhanced service description: For a simple web service that is expected to be used in isolation, the WSDL description of the web service may suffice for a client of the web service. However, the composition of autonomous web services into a composite service requires more information about the functional and nonfunctional properties of the services than are available in WSDL descriptions. We have described in the last section how this can affect consistency in case of a transactional scenario. Similarly, QoS parameters [15] of a constituent web service are also important for a composite service provider so that it may thoroughly evaluate the suitability of the service for composition. The functional and nonfunctional properties of constituent services, not expressible in WSDL, but required for consistency and reliability of the composite service, can be expressed using enhanced service descriptions. Different methodologies are available for enhanced service descriptions. These range from industry proposals, (e.g. WS-Policy Framework, available at http://www106.ibm.com/developerworks/library/ws-polfram/), to research projects [26]. A research project (available at

http://www.research.ibm.com/AEM/xmt.html) uses the previously referenced industry proposal for coordinated execution and recovery of composite services. This is done by proper specification of transactional requirements and semantics, as well as middleware capabilities. A methodology for resolution of conflict of interest in a particular scenario using enhanced service descriptions is described in [27]. However, enhanced service descriptions can be effective in so far as they are adhered to. For this, agreements, or contracts between the participants can be helpful. These form the subject of the next section. Agreements/contracts: We differentiate between agreements and contracts. Agreements represent informal arrangement between participants, and are more conducive to the loosely-coupled nature of composite services. They also suit the autonomous nature of the web services. An agreement might mean a recognition of the functional and non-functional properties of constituent services, and the composition and eventual execution of the composite service on the premise that these properties will be adhered to by the participants. This, however, places more burden on the composite service provider and the web service provider. For example, if a service has specified provision of service availability for a certain period of time, but becomes unavailable, the burden is on the composite service provider to deal with the consequences. Similarly, a web service provider has to deal with consequences if the composite service provider does not signal it an activity termination, leaving the constituent service data in an inconsistent state. Compared to agreements, contracts (or service-level agreements [28]) represent a binding arrangement, which, however, goes more in the direction of tight-coupling between participants. Additionally, contracts would need a monitoring mechanism as well to check adherence to the contract by the participants. On the other hand, contractual agreements add to the reliability of the composite service, in that there is less room for inconsistencies to creep up, as well as less chance for unnecessary exceptional situations. Also relevant to this aspect is the process of negotiation that may precede an agreement or a contract. A negotiation process can also be necessitated due to the autonomous nature of the participants, who would like to enter agreements or contracts at favorable terms. A negotiation methodology for business processes based on web services is described in [29]. Since negotiations represent interactive two-way communications, conversations between participants can represent a natural choice for acting as a vehicle for negotiations. Conversations are the subject of the next section. Conversations: Conversations can play a role in composite services at two levels. One level is the process of web service composition, and the other the execution of the composite service. In this respect we ascribe to the view presented in [5], which distinguishes between

Witold Abramowicz (ed.), Business Information Systems, Proceedings of BIS 2004, Poznan, Poland

TOWARDS IDENTIFYING REPRESENTATIVE CHARACTERISTICS OF WEB SERVICES COMPOSITIONS

composition-driven conversations and execution-driven conversations. Conversations at the level of the composition are important because they can help in inconsistency resolution, and reaching an agreement, potentially a contractual agreement also. For example, through a conversation-based composition process a composite service provider and a web service provider can agree on a functional property, e.g. the transaction protocol mutually supported by both types of providers, or a non-functional property, e.g. the price of a web service operation invocation. A conversation model, such as that described in [30], can prove useful in capturing the properties, functional as well as non-functional, of a composite service. Conversations at the level of the composite service execution deal mainly with the structuring and management of complex interactions between web services. In this regard a methodology for conversations is described in [31], which defines a conversation infrastructure on top of the composite service layer. The methodology described in [31] can also deal with the issues previously discussed, namely a service interface change, and different formats used for message exchanges between participants. However, conversations, while they may contribute to the consistency and reliability characteristics of the composite service, do represent a tightly-coupled interaction. This can be explained by the requirement imposed on participants involved in a conversation to be aware of the context and format of the conversation, e.g. in what format is a reply to be sent in correlation to which particular request.

5.

Conclusion

In this paper we dealt with web services compositions, and presented characteristics representative of composite services. In doing so, we also mentioned how these characteristics relate to each other. We also discussed important aspects relevant to composite services, and described how these aspects relate to each other, as well as to the previously highlighted characteristics. We also described the relevance of these aspects to web service composition methodologies. We did not consider interoperability as a representative characteristic of composite services, since interoperability is considered inherent to web services based solutions. Practical problems with interoperability in the realm of web services are being addressed through standardization and good design practices. Important to stress is that interoperability should not come at a cost to the representative characteristics of composite services, which we have described in this paper. This holds not just for interoperability mechanisms, but is important for all web service composition methodologies in general, regardless of the approach they are based on and the

5

composite service characteristic they address. Herein lies a contribution of this paper, that it can be used as a scale against which to ascertain the effect of web service composition methodologies on the representative characteristics. This is important for improvement of architectural principles and design methodologies for composite services. For example, a composite service design that provides a high degree of reliability but compromises loose-coupling cannot be considered representative of a successful architecture. In the same way, preservation of autonomy of web service providers at the cost of composite service consistency is also not acceptable. A sound architecture and a corresponding good design model for composite services needs to strike a balance between the characteristics presented in this paper. As work on web service composition methodologies moves forward and consolidates, awareness of the points raised in this paper should lead to better understanding of the issues that need to be kept in view during architectural and design decisions.

6.

References

[1] Francisco Curbera, Rania Khalaf, et al., The Next Step in Web Services. Communications of the ACM, 2003. 46(10): pp. 29-34. [2] P. Wohed, W.M.P. van der Aalst, et al., Pattern-Based Analysis of BPEL4WS. Technical Report. FIT-TR-2002-04. Queensland University of Technology. 2002. [3] Brahim Medjahed, Boualem Benatallah, et al., Business-tobusiness interactions: issues and enabling technologies. The VLDB Journal, 2003. 12: pp. 59-85. [4] Tony Andrews, Francisco Curbera, et al. Business Process Execution Language for Web Services, version 1.1. Accessed at: http://dev2dev.bea.com/technologies/webservices/BPEL4WS.js p [5] Zakaria Maamar, Boualem Benatallah, et al. Service Chart Diagrams Description & Application. In Proc. WWW2003. Budapest, Hungary. 2003. [6] Rania Khalaf and Frank Leymann. On Web Services Aggregation. In Proc. TES 2003. LNCS 2819, pp: 1-13. 2003. [7] Mike P. Papazoglou and Jian Yang. Design Methodology for Web Services and Business Processes. In Proc. TES 2002. LNCS 2444, pp: 54-64. 2002. [8] OMG's CORBA Website. Accessed at: http://www.omg.org/corba/ [9] Bahman Kalali, Paulo Alencar, et al. NSPF: Designing a Notification Service Provider Framework for Web Services. In Proc. NODe 2002, Web- and Database-Related Workshops. Erfurt, Germany. LNCS 2593, pp: 73-90. 2002. [10] Alan Fekete, Paul Greenfield, et al. Transactions in Loosely Coupled Distributed Systems. In Proc. The Fourteenth Australasian Database Conference. Adelaide, Australia. 2003. [11] Dean Kuo, Alan Fekete, et al. Just What Could Possibly Go Wrong In B2B Integration? In Proc. 27th Annual International Computer Software and Applications Conference. Dallas, USA. 2003. [12] Thomas Mikalsen, Stefan Tai, et al. Transactional Attitudes:Reliable Composition of Autonomous Web Services. In

Witold Abramowicz (ed.), Business Information Systems, Proceedings of BIS 2004, Poznan, Poland

BUSINESS INFORMATION SYSTEMS – BIS 2004

6 Proc. International Conference on Dependable Systems and Networks (DSN 2002). 2002. [13] Paulo F. Pires, Marta Mattoso, et al. Building Reliable Web Services Compositions. In Proc. NET.Object Days Conference (WS-RDS'02). Erfurt, Germany. 2002. [14] Werner Vogels and Chris Re. WS-MEMBERSHIP Failure Management in a Web-Services World. In Proc. The Twelfth International World Wide Web Conference. Budapest, Hungary. 2003. [15] Liangzhao Zeng, Boualem Benatallah, et al. Quality Driven Web Services Composition. In Proc. WWW2003. Budapest, Hungary. pp: 411-421. 2003. [16] Justin O’Sullivan, David Edmond, et al., What's in a Service? Towards Accurate Description of Non-Functional Service Properties. Distributed and Parallel Databases, 2002. 12: pp. 117-133. [17] Muhammad F. Kaleem. A Classification Framework for Approaches and Methodologies to make Web Services Compositions Reliable. In Proc. First European Workshop on Object Orientation and Web Service. Darmstadt, Germany IBM. IBM Research Report Series-RA 220, pp: 35-42. 2003. [18] Philip A. Bernstein and Eric Newcomer, Principles of Transaction Processing. 1-55860-415-4. Morgan Kaufmann Publishers, Inc. 1997. [19] Paul Greenfield, Alan Fekete, et al. What are the consistency requirements for B2B systems? (Position paper). In Proc. High Performance Transactions Systems Workshop. California, USA. 2003. [20] Giacomo Piccinelli, Anthony Finkelstein, et al. Web Services Need Consistency. In Proc. OOPSLA 2002 Workshop on Object-Oriented Web Services. 2002. [21] B. Benatallah, M. Dumas, et al. Declarative Composition and Peer-to-Peer Provisioning of Dynamic Web Services. In Proc. 18th IEEE International Conference on Data Engineering (ICDE). San Jose CA, USA IEEE Press. 2002. [22] Jian Yang, Web Service Componentization. Communications of the ACM, 2003. 46(10): pp. 35-40.

[23] Luis Felipe Cabrera, George Copeland, et al. Web Services Atomic Transaction (WS-AtomicTransaction). Accessed on: 2210-2003 at: http://msdn.microsoft.com/webservices/understanding/specs/def ault.aspx [24] Arjuna, Fijitsu, et al. Web Services Composite Application Framework (WS-CAF). Accessed on: 24-10-2003 at: http://www.arjuna.com/standards/ws-caf/index.html [25] Paul Greenfield, Alan Fekete, et al. Compensation is Not Enough. In Proc. 7th IEEE International Enterprise Distributed Object Computing Conference. Brisbance, Australia. 2003. [26] Vladimir Tosic, Bernard Pagurek, et al., WSOL – A Language for the Formal Specification of Various Constraints and Classes of Service for Web Services. Technical Report. OCIECE-02-06. Department of Systems and Computer Engineering, Carleton University. November 2002. [27] Patrick C. K. Hung and Guang-Sha Qiu, Specifying Conflict of Interest Assertions in WS-Policy with Chinese Wall Security Policy. ACM SIGecom Exchange, 2003. Vol. 4: pp. 1119. [28] Alexander Keller and Heiko Ludwig, The WSLA Framework: Specifying and Monitoring Service Level Agreements for Web Services. Journal of Network and Systems Management, Special Issue on "E-Business Management", March 2003. 11(1). [29] Jin Baek Kim, Arie Segev, et al. Web Services and BPEL4WS for Dynamic eBusiness Negotiation Processes. In Proc. First International Conference on Web Services (ICWS). Las Vegas, Nevada. 2003. [30] Boualem Benatallah, Fabio Casasti, et al. Conceptual Modeling of Web Service Conversations. In Proc. CAiSE '03. 2003. [31] Santhosh Kumaran and Prabir Nandi. Conversation Support for Web Services. Accessed at: http://www106.ibm.com/developerworks/webservices/library/ws-conver/

Witold Abramowicz (ed.), Business Information Systems, Proceedings of BIS 2004, Poznan, Poland