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") {
}

For the sake of simplicity, we do not list in the aforementioned policy the full URNs for the XACML DataTypes and FunctionIds, and use rather simple names for the vocabulary items (e.g., CurrentNumberOfParticipations) and simple names for function identifiers (e.g., integer-less-than). The vocabulary items could also be elements in a schema instance that is passed to the policy evaluator, in which case ”AttributeSelector” with an XPath expression would be used rather than <...AttributeDesignator>. Obligation policy specification. An obligation guarantees that a Web service will be part of a composite service, despite negative permission of participation, dispensation from participation, or dispensation from restriction (Fig. 3). Obligations are aimed for the situations that call for an immediate handling of users’ needs. In addition obligations might result in dropping or suspending some of the ongoing compositions due to the maximum number of participations of a Web service in multiple compositions at a time [12]. Because of this maximum number of participation, a Web service might have to suspend or drop some of its ongoing participations due to the obligation of joining another composition. Compensation solutions are to be developed for the compositions that are affected by suspension or dropping decisions of participation. For example, a substitute Web service needs to be found if a Web service decides to cancel its participation in an ongoing participation. Furthermore, a composition needs to be resumed according to a certain time frame if a Web service temporarily suspends its participation. The following illustrates an obligation policy in WSPL. It states that a Web service takes part in a composite service subject to evaluating to true. This latter checks that whether a no-permission of participation exists, a dispensation from participation exists, or a no-dispensation from restriction exists.

Policy (Aspect="Obligation") { "high" }

4

Implementation

We overview the implementation work of the Web service- and policy-based approach for developing interoperable business processes. For compatibility purposes, we use Sun Microsystems’s tools namely J2EE 1.4 to develop Web services and XACML Open Source to develop policies. Fig. 4 illustrates the architecture of the prototype. The architecture emphasizes the separation of concerns that exists between composition and component levels. The architecture comprises 4 types of managers. The specification manager supports designers during the specification of composite services. This calls for identifying the appropriate component Web services. The specification work is conducted through a composition environment, which is a set of integrated tools that assist designers in creating and editing new and existing specifications of composite Web services, respectively. In this environment WSDL and UDDI are used for Web services specification and announcement and discovery, respectively. This environment, also, supports translation of composite service specifications, like the one in Fig. 2, into BPEL. The selection manager is responsible for identifying the component Web services that satisfy user needs. This manager is trigged upon user’s request, who identifies the appropriate composite service specification. In the current prototype, the selection is not only driven by the resulting functionality of the composition the user needs (e.g., to reach a meeting place by taxi or by bus according to weather conditions as detailed in the next section). It also considers

Binding

User

6. Services for invocation

Component level

Specification manager

2. Submission

Approval(yes,no)

Policy Manager

4. Verification

Selection Manager

5. Search

3. Selection

Composition level

1. Request

Repository of Web services

Binding

Context Manager

Binding

Repository of resources

Fig. 4. Architecture of the prototype of the proposed approach

Web services QoS parameters that affect the selection process like response time, performance, and throughput. These constraints are expressed with WSPL policies. Our policy approach allows new QoS parameters such as network delay and communication cost to be seamlessly integrated into the prototype. The policy manager makes Web services bind to appropriate behaviors according to the progress of a composition. Finally, the context manager keeps track of the contexts of users, service contexts, and resource contexts. Contexts’ parameters are of different types and their values change over time. Therefore the context manager is supported with a real-time triggering mechanism that feeds context parameters with fresh values. Details of contexts are structured as XML files. A dedicated XML editor is used to create, validate, and monitor the different XML files. The validation of these files is based on an XML schema (context.xds). Before sending the selected Web services’ addresses to the user for invocation, the policy manager ensures that these Web services comply with the policies reported in Section 3.2. Upon approval of the policy manager, the selection manager initiates the search of the resources on which the Web services will operate.

5

Related work

Kagal et al. claim that policies should be part of the representation of Web services, and in particular of semantic Web services [7]. Policies provide the specification of who can use a service under what conditions, how information should be provided to the service, and how the provided information will be used later. In this paper, we adopted a different strategy by using policies to represent how Web services of composite services behave according to specific situations, rather than how to interact with Web services.

Desai et al. have recognized the importance of separation of concerns from a software engineering perspective [6]. Indeed, they split a business process into two parts: protocol and policy. The protocol part is a modular, public specification of an interaction among different roles that collaborate towards achieving a desired goal. The policy part is a private description of a participant’s business logic that controls how this participant takes part in a protocol. The mapping of Desai et al.’s work onto our work is straight. A composite service specification illustrates a protocol in which Web services participates according to various policies. The commitments of Web services towards composite services have been highlighted with rewards/sanctions that promote/demote Web services. In [2], Baresi et al. propose a policy-based approach to monitor Web services’ functional (e.g., constraints on exchanged data) and non-functional (e.g., security, reliability) requirements. In this approach Baresi et al. report on the different types of policies that can be defined along the life cycle of a Web service [13]. These types are service policies, server policies, supported policies, and requested policies. Combining requested and supported policies results in effective policies.

6

Conclusion

In this paper, we discussed a Web service- and policy-based approach for developing interoperable business processes. We mainly focussed on how policies constraint the behavior of Web services engaged in this development. The approach depicted four layers referred to as resource, Web service, user, and policy, respectively. Interesting to highlight the role of the policy layer, which, for instance, enabled the separation of concerns between the requirements of a composite Web service and the requirements of a component Web service. This separation of concerns was backed by the information that context provides over preferences of users, execution states of Web services, and commitments of resources towards Web services. Furthermore, we promoted the importance of Web services adaptability by allowing them to expose distinct behaviors according to the situations wherein they evolve. A behavior was organized along four interconnected attributes referred to as authorization, obligation, restriction, and dispensation. As part of our future work, we investigate the use of policies to secure policies. We discussed how policies direct a Web service towards the behavior that is suitable for the execution progress of a composition. To guarantee that this behavior binding happens as expected, we deem appropriate protecting the policies from unwanted alterations or misuses from unauthorized parties. We deal with policies as resources that can be subject to attacks like any other resource offered to external parties. For instance, a Web service could get engaged in composition despite the restriction policy that prevents the engagement from happening. However this policy did not trigger due to unpermitted changes in its content. Our strategy to secure policies for behaviors of Web services will be built upon a set of security policies, which are different from these policies.

Acknowledgements The authors would like to thank Anne H. Anderson from Sun Microsystems Laboratories in Burlington, MA for the fruitful discussions on Web services policy standards.

References 1. A. H. Anderson. An Introduction to The Web Services Policy Language (WSPL). In Proceedings of The 5th IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY’2004), New-York, USA, 2004. 2. L. Baresi, S. Guinea, and P. Plebani. WS-Policy for Service Monitoring. In Proceedings of The 6th Workshop on Technologies for E-Services (TES’2005) held in conjunction with The 31st International Conference on Very Large Data Bases (VLDB’2005), Throndeim, Norway, 2005. 3. D. Berardi, D. Calvanese, G. De Giacomo, M. Lenzerini, and M. Mecella. A Foundational Vision for e-Services. In Proceedings of Ubiquitous Mobile Information and Collaboration Systems Workshop (UMICS’2003) held in conjunction with The 15th International Conference On Advanced Information Systems Engineering (CAiSE’2003), Klagenfurt/Velden, Austria, 2003. 4. N. Boudriga and M. S. Obaidat. Intelligent Agents on the Web: A Review. Computing in Science Engineering, 6(4), July-August 2004. 5. J. Coutaz, J. L. Crowley, S. Dobson, and D. Garlan. Context is Key. Communications of the ACM, 48(3), March 2005. 6. N. Desai, A. U. Mallya, A. K. Chopra, and M. P. Singh. Processes = Protocols + Policies: A Methodology for Business Process Development. In Proceedings of The Fourteen International World Wide Web Conference (WWW’2005), Chiba, Japan, 2005. 7. L. Kagal, M. Paolucci, N. Srinivasan, G. Denker, and K. Finin, T. Sycara. Authorization and Privacy for Semantic Web Services. IEEE Intelligent Systems, 19(4), July/August 2004. 8. B. Limthanmaphon and Y. Zhang. Web Service Composition Transaction Management. In Proceedings of The Fourtheenth Australasian Database Conference (ADC’2004), Dunedin, New Zealand, 2004. 9. E. Lupu and M. Sloman. Conflicts in Policy-Based Distributed Systems Management. IEEE Transactions on Software Engineering, 25(6), November/December 1999. 10. Z. Maamar, B. Benatallah, and W. Mansoor. Service Chart Diagrams - Description & Application. In Proceedings of The Alternate Tracks of The Twelfth International World Wide Web Conference (WWW’2003), Budapest, Hungary, 2003. 11. Z. Maamar, S. Kouadri Most´efaoui, and Q. H. Mahmoud. On Personalizing Web Services Using Context. International Journal of E-Business Research, Special Issue on E-Services, The Idea Group Inc., 1(3), July-September 2005. 12. Z. Maamar, S. Kouadri Most´efaoui, and H. Yahyaoui. Towards an Agent-based and Context-oriented Approach for Web Services Composition. IEEE Transactions on Knowledge and Data Engineering, 17(5), May 2005. 13. N. Mukhi, P. Plebani, I. Silva-Lepe, and T. Mikalsen. Supporting Policy-Driven Behaviors in Web Services: Experiences and Issues. In Proceedings of The 2nd International Conference on Service Oriented Computing (ICSOC’2004), New York City, NY, USA, 2004.

Developing Interoperable Business Processes Using Web Services ...

Abstract. A Web service is an accessible application that other appli- cations and humans can discover and trigger to satisfy various needs. Thus, Web services ...

135KB Sizes 1 Downloads 144 Views

Recommend Documents

Developing Java Web Services by Ramesh Nagappan.pdf ...
Page 3 of 784. Developing Java Web Services by Ramesh Nagappan.pdf. Developing Java Web Services by Ramesh Nagappan.pdf. Open. Extract. Open with.

Describing Processes- Games - Using English
An administrative system (e.g. finding school places for first year primary students). Applying for something ... Driving or riding something. Entering a competition.

Toward the Web of Functions: Interoperable Higher-Order ... - GitHub
enabling a generation of Web APIs for sparql that we call Web of Func- tions. The paper ... Functions with a Remote Procedure Call (RPC) approach, that is, users can call ...... tional World Wide Web Conference, WWW (Companion Volume).

Authoring intelligent tutoring system using Web services
application architecture (see Fig. 1). Web .... use cases designates xTEx-Sys Web services (see Fig. 4). .... passes all elements of domain knowledge using XML.

Towards Behavioral Web Services Using Policies
ditional integration middleware (e.g., CORBA, Java RMI) [4]. This lack of ...... [15] F. Curbera, M. Duftler, R. Khalaf, W. Nagy, N. Mukhi, and S. Weerawarana.

Web Services using Tomcat and Eclipse - Recluze - WordPress.com
Create a new java file called BasicMath.java with the following code: ... Start apache server using Apache Monitor from the program menu. ... EchoSoapBindingStub srv = new EchoSoapBindingStub( new URL("http://localhost:8080/SOATest/services/Echo"), n

Catalog
18: Studio Visit: SEO. 17: Terry Haggerty: Angle of Response / Kuttner Siebert Gallery, Berlin. 14: Interview with Dan Perjovschi at Fumetto Festival Lucerne.

The Mobile Web in Developing Countries - World Wide Web Consortium
1. The Mobile Web in Developing Countries. Ravi Jain [email protected] ... The explosive growth of mobile phones and mobile voice services in developing countries has led .... competition, regulation and the attributes of the fixed network.