Developing Interoperable Business Processes Using Web Services ...

Developing Interoperable Business Processes Using Web Services and Policies Zakaria Maamar1 , Djamal Benslimane2 , Ghita Kouadri Most´efaoui3 , Subramanian Sattanathan4 , and Chirine Ghedira2 1

2

Zayed University, Dubai, U.A.E - [email protected] Claude Bernard Lyon 1 University, Lyon, France - [email protected] 3 University of Montreal, Montreal, Canada - [email protected] 4 Airvana Networks India Private limited, Bangalore, India - ss [email protected]

Abstract. A Web service is an accessible application that other applications and humans can discover and trigger to satisfy various needs. Thus, Web services should continually adapt their behavior according to these needs, and according to the entities they interact with. This paper presents a Web service- and policy-based approach to achieve interoperable business processes. Web services have gained a huge success due to their composition capabilities, which permit developing this type of business processes. In this approach, we propose using policies in order to constraint the behavior of Web services and regulate the interactions of these Web services with peers, users, and computing resources. Four types of policies are developed namely authorization, restriction, dispensation, and obligation. Each policy type responds to the needs of overseeing Web services engaged in achieving interoperable business processes. Keywords. Interoperability, Composition, Policy, Web service.

1 1.1

Introduction Motivations, challenges, and solutions

The principles upon which Web services are created make them very popular in both academia and industry. Web services rely on standards (i.e., XML, SOAP, WSDL, and UDDI) that make them able to function on various platforms and with different applications. This paper discusses a research project that aims at developing interoperable business processes using Web services and policies. The focus is mainly on how policies constitute guidelines for managing the life cycle of a composition process, which leads into developing interoperable business processes. This life cycle comprises multiple steps identified by Web services discovery, selection, engagement, and monitoring. The complexity of the life cycle’s steps of a composition yield insight into the definition of various types of policies, each type geared towards fulfilling the requirements of a specific step. Despite the extensive adoption of Web services, they still lack the capabilities that could enable them to match and eventually surpass the acceptance level of traditional integration middleware (e.g., CORBA, Java RMI). This lack

of capabilities is to a certain extent due to the trigger-response interaction pattern that frames the exchanges of Web services with third parties. Adhering to this interaction pattern means that a Web service only performs the requests it receives without considering its internal execution state, or even questioning if it would be rewarded for performing these requests (e.g., to be favored over a community of similar Web services during selection). There exist, however, several situations that insist on Web services self-management so that scalability, flexibility, and stability requirements are satisfied. By scalability, we mean the capacity of a service to interact with a limited or extended community of Web services without having its expected performance disrupted or reduced. By flexibility, we mean the capacity of a service to adapt its behavior by selecting the appropriate operations that accommodate the situation wherein it participates. Finally, by stability, we mean the capacity of a service to resist unforeseen changes while maintaining operation and recovering to normal levels of operation after disturbances. These three requirements shed the light on a new type of Web services that should be allowed to assess their current capabilities, ongoing commitments, and particularly surrounding environment prior they bind to any new composition. We label these Web services as context-aware [12]. ”... Context is not simply the state of a predefined environment with a fixed set of interaction resources. It is part of a process of interacting with an ever-changing environment composed of reconfigurable, migratory, distributed, and multiscale resources” [5]. In this paper, the proposed Web service- and policy-based approach for developing interoperable business processes calls for the participation of two extra elements. The resource element identifies the computing means on which Web services operate, and the user element identifies the personalization that Web services are subject to [11]. The use of each element is motivated as follows. The dynamic nature of user expectations and requirements sheds the light on the importance of including their preferences during Web services composition. We focus on user preferences of types time and location (i.e.,when and where a Web service has to be executed, and when and where this execution outcome has to be returned). User preferences can also be explicit or implicit. For example, explicit preferences call for a direct participation of users in the adjustment of Web services. Users clearly indicate the information that Web services have to treat or discard. Implicit preferences do not call for any user involvement and can be built upon automatic learning strategies that, for example, return Web services’ outcomes according to user locations. Generally computing resources have to schedule the execution requests that concurrently originate from multiple Web services. Thus, Web services have to be aware of the capabilities and limitations of the resources on which they will operate. Upon resource identification and ”bearing in mind” user preferences, a Web service checks with the resource about its capacity of supporting an extra execution. The resource assesses its current commitments towards other Web services, and either accepts or rejects the execution request of this Web service. A rejection is motivated by the constraints over a resource like potential overload. The rationale use of resources is critical in Web services-based transaction

management [8]. Locking resources for long periods of time is by far not acceptable as the number of Web services that are announced to potential users continues to grow, so the use of resources is becoming intensive. Other research works have to date focussed on various issues related to Web services such as discovery, conversation, composition, just to cite a few. In this paper we look into the seamless combination of policies, Web services, and context-aware computing in order to develop interoperable business processes. Fig. 1 illustrates our Web service- and policy-based approach for interoperable business processes. On top exists the policy layer, which relies on the information that context caters over the lower layers namely user, Web service, and resource (to keep the paper self-contained, a context content is not detailed). Context oversees the three layers so the policy layer is kept informed on a regular basis, for example, about the changes in user preferences, the execution state of a service, and the recent commitments of a resource.

Policy layer Context to oversee the three layers User layer Web service layer Resource layer Environment

Fig. 1. Web services and policies for interoperable business processes

1.2

Using policies to leverage Web services

Policies are defined by some as information which can be used to modify the behavior of a system [9]. Two reasons motivate boosting the role of Web services in developing interoperable business process with policies. First, policies permit managing Web services at a higher level where guidelines to conduct composition are separated from guidelines to specify the behavior of Web services. On the one hand, guidelines for composition concern among others how to identify and integrate user preferences into Web services, and how to guarantee the satisfaction of these preferences subject to resource availability? On the other hand, guidelines for Web services concern among others how to exchange comprehensible information between Web services, how to deal with a Web service unreliability, and how to substitute a Web service with an equivalent one? The second reason is that policies support adapting Web services by taking advantage of the up-to-date information that context caters over users, Web services, and resources. Context supports loading the policies for triggering, which means the possibility of changing the progress of a composition scenario.

1.3

Paper organization

Section 1 presents the research project discussed in this paper in terms of motivations, challenges, solutions, and rationale of using policies. Section 2 presents the We service- and policy-based approach for interoperable business process with a focus on the four layers of this approach. Section 3 discusses the specification and management of the behavior of Web services. The implementation of a proof-of-concept prototype is reported in Section 4. Related work is given in Section 5. Finally, we draw our conclusions and highlight some future research avenues in Section 6.

2

The proposed approach

Fig. 1 presents the four layers upon which our Web service- and policy-based approach for interoperable business processes is built. Context is inserted between the policy layer and the rest of layers. In the following, we explain the contributions of each layer towards the approach by taking on a bottom-up description. Resource layer. It represents the computing means on which Web services operate. The scheduling of execution requests of Web services is prioritized when enough resources are not available to satisfy them all at once. To support this scheduling, a resource could be associated with multiple arguments like previous periods of time/services, current period of time/services, and current location/services. These arguments primarily describe a resource from time and location perspectives. The time perspective is about the periods of time that have featured/are featuring/will feature the execution of Web services over a resource. The location perspective is about the locations that have simultaneously featured/are simultaneously featuring/will simultaneously feature both the presence of users in certain locations and the execution of Web services over a resource. Web service layer. It represents the Web services that are advertised with a registry (e.g., UDDI) so users can trigger in order to satisfy their needs (e.g., book ordering). This satisfaction is subject to resource availability as shown in the resource layer. A Web service could be associated with multiple arguments like state per participation, previous services per participation, and start time per participation. These arguments describe a Web service according to specific execution chronologies in terms of pre- and post-services, time and location parameters that will trigger the execution of the service, and corrective measures in case of execution failures. User layer. It represents users who look for Web services with respect to their needs that vary from travel planning to book ordering. Users may require some assistance in locating, selecting, and composing the appropriate Web service. This could be done using for example software agents [4], but this is outside this paper’s scope. The complexity of some user needs requires the composition of Web services as Berardi et al. report in [3]. Composition addresses the situation of a user request that cannot be satisfied by any available Web service,

whereas a composite service obtained by combining available Web services might be used. Fig. 2 is a sample of a specification of a composite service [10]. The component Web services of this composite service are: sightseeing (SI), weather (WE), shopping (SH), and transportation (TR).

yes

SCD-SI (SIghtseeing) (SCD: Service Chart Diagram)

SCD-WE (WEather)

[confirmed (hot weather)] no

SCD-SH (SHopping)

SCD-TR (TRansportation)

Fig. 2. Sample of a composite service specification

Similar to resources and Web services, user could be associated with multiple arguments like previous periods of time/services and next periods of time/services. These arguments describe user from time and location perspectives. The time perspective is about the periods of time that have featured/are featuring/will feature the execution of Web services as per user’s request. The location perspective is about the locations that have featured/are featuring/will feature the execution of Web services because of the specific location of user. Policy layer. It represents the policies that define how a Web service should act and react based on the progress of a composition. This progress is subject to the interactions a Web service is having with users and resources. Interactions between users and Web services concern the integration of user preferences into the operation of Web services and the validation of the personalized Web services. Users could have conflicting preferences (e.g., user committed to be in separate locations but at the same time), that negatively affect the integrity of Web services. Interactions between Web services and resources concern the mechanisms of supporting the execution of personalized Web services subject to the constraints on these resources. In Fig. 1, the policy layer and context are connected. Context oversees the three layers by returning various details on users (e.g., current location), Web services (e.g., execution order), and resources (e.g., next period of unavailability). These details affect the loading and firing of the appropriate policies so Web services bind to the right behavior.

3 3.1

Policy-driven Web services behaviors Types of behaviors

In the approach of Fig. 1, policies gear the behavior of Web services towards the satisfaction of the requirements of the progress of a composition. We recall that composition results in developing interoperable business processes. We expose this behavior using the following four attributes: permission, restriction,

dispensation, and obligation. Prior to posting Web services on a registry, their owners specify the policies per type of behavior (Section 3.2). In the following, we describe each behavior and then, discuss how a Web service binds to a behavior. - Permission: a Web service accepts the invitation of participation in a composite service upon validation of its current engagements in other composite services. - Restriction: a Web service cannot get connected to other peers of a composite service due to non-compliance of some peers with this Web service’s requirements. - Dispensation: a Web service breaks some policies that concern permission or restriction. In the case of permission, the Web service will not participate in a composition despite the positive permission of participation. In the case of restriction, the Web service will be connected to some peers despite the existence of restrictions. - Obligation: it is a strong permission for a Web service to participate in a composite service despite the negative permission of participation or the existence of restrictions from participation. In addition, obligations override the dispensations associated with permission or restriction. Fig. 3 illustrates the way the different behaviors of a Web service are related to each other based on the execution outcome of policies. In this figure, behaviors are represented with ellipses and connection links between these ellipses are labeled with yes and no. In the same figure, dispensationP and dispensationR stand for dispensation related to permission and related to restriction, respectively. In addition, (+) and (-) stand for positive and negative participation in composition, respectively. Initially, a Web service is invited to take part in a composite service. The decision of taking part is made based on the outcome of executing the relevant policy. When a participation permission is granted (i.e., yes in Fig. 3), the next step consists of checking if there is any dispensation that could invalidate this permission. In case a dispensation exists (i.e., no in Fig. 3), this may result in cancelling the positive permission of participation in the composite service. Prior to finalizing the cancellation, the obligation of participation is first checked. We recall that obligations override any decision of no permission of participation and any decision of dispensation from participation. If there is no dispensation from permission, the next step consists of checking restrictions. If there are no restrictions, the participation of the Web service in a composite service is finally confirmed. Otherwise, dispensations related to restrictions and obligations as well are checked as discussed in the previous paragraphs. Fig. 3 also shows the different paths that result in a Web service participation in a composite Web service. For instance, a path combines a negative permission (no) and a positive obligation (yes). Another path combines a positive permission (yes), a negative dispensation of type permission (no), and a negative restriction (no).

Permission no

yes

DispensationP yes

no

Restriction yes

no

DispensationR

Participation(+)

no

yes

Obligation

Participation(+)

no

yes

Participation(-)

Participation(+)

Fig. 3. Attributes exposing the behavior of a Web service

3.2

Policy specification

We define examples of policies that expose the behavior of a Web service as discussed in Section 3.1. To this purpose, a policy definition language is required. In this paper, we use WSPL. Anderson argues that a Web service has various aspects and features that can be controlled using policy rules [1]. Some of these aspects include authentication, quality-of-service, and privacy. Anderson suggests WSPL to express policies and achieve the interoperability of Web services. The syntax of WSPL is strictly based on the OASIS eXtensible Access Control Markup Language (XACML) standard1 . For illustration purposes, we only present permission and obligation policies. Permission policy specification. A permission consists of authorizing a Web service to be part of a composite service. The following illustrates a permission policy in WSPL. It states that a Web service participates in a composition subject to evaluating to true. This latter refers to some arguments like the number of current active participations of the Web service in compositions and the next possibility of participation of the Web service in additional compositions. Both arguments can be part of the context of a Web service and tracked according to the Web services instantiation principle [12]. These arguments are known as vocabulary items in WSPL. In the policy, shows the permission of participation, whereas shows the contrary.

1

http://www.oasis-open.org/committees/download.php/2406/oasis-xacml-1.0.pdf.

Policy (Aspect="Permission") {