Using Business Process Execution Language to Handle Evaluation ...

Using Business Process Execution Language to Handle Evaluation Factors for Web Services Compositions Christos K. Georgiadis1 and Elias Pimenidis2 1

Department of Applied Informatics, University of Macedonia, Thessaloniki, Greece [email protected] 2 School of Computing, Information Technology and Engineering, University of East London, UK [email protected]

Abstract. Web services aim at spontaneously integrating services from different providers in ensuring at offering a user the best possible experience. The interrelationships between the concepts of security, performance and interoperability, while critical to any web service, are the key criteria in evaluating Web Services and their ability in meeting user requirements. This paper aims at exploring whether the use of the Business Process Execution Language (BPEL) in defining Web Services, can contribute towards enhancing the quality of the service delivered and improving the ability of evaluating suitable factors for ensuring secure and interoperable Web Service composition without compromising on performance. Keywords: BPEL, Web Services, Evaluation, WS Composition.

1 Introduction Web services (WS) are the modern response of traders and online service providers to satisfying the increasing needs and demands of the digital communities. Web service formation and operation is based on a software system designed to support interoperable machine-to-machine interaction over a network. Web services integrate applications owned by different organizations (even if they are developed using different programming languages and deployed on different platforms) to provide a loosely coupled architecture for building distributed systems with universal interoperability. As a result, web services have been widely adopted in industry as a standard platform-independent middleware technology. Such cooperative services are capable of intelligent interaction and are able to discover and negotiate with each other, mediate on behalf of their users and compose themselves into more complex services. These exact properties of web services are the ones that present most challenges and comprise those elements that define “quality” of services to final users. This concept of quality is expressed in terms of functional and non-functional requirements, such as performance or security and it is these two particular attributes that attract researchers in their quest for means of evaluating web services. H. Jahankhani, A.G. Hessami, and F. Hsu (Eds.): ICGS3 2009, CCIS 45, pp. 112–121, 2009. © Springer-Verlag Berlin Heidelberg 2009

Using Business Process Execution Language to Handle Evaluation Factors

113

Business processes do not simply depend on information systems: they define the services required. The big challenge of Service-Oriented Architecture (SOA) is therefore to design systems in such a way that accommodating most business process changes only requires rearranging existing business services [1].

2 Business Process Evaluation: Focus on the Underlying Service Composition 2.1 Evaluation Factors WS-based (or business) processes are capable to negotiate transaction bonds at runtime, to support relaxation of isolation levels, and to maintain long period transaction execution. Business transactions might be complicated enough, because service intermediaries have several responsibilities trying to associate providers, consumers and even other intermediaries. The multiple roles that service intermediaries are asked to play provide a useful set of technical and user-oriented criteria for evaluating the efficiency, usability and effectiveness of WS usage for business processes. Generally, the effectiveness of WS-based interactions and transactions is influenced by the major particular characteristics of the service-oriented architecture [2-7]. We put emphasis on the following [8]: o

o

o

Decentralized maintenance process. WS form a distributed environment which is not placed within a single trust area and this complicates the security issues and makes unrealistic to count on a single authority to coordinate all involved parties. Need for interoperability and for ease of integration. WS-based systems wish to support service dynamic substitution by assembling different services developed separately into one working application. Distributed character. Different WS are frequently distributed across distant geographical positions, and this raises all related issues concerning performance.

This paper focuses on all decisive factors related to system behavior, leaving out useroriented issues. The set of design concerns which we have selected (security, interoperability and performance) is obviously not an exhaustive list of evaluation criteria. Still, they are sufficient to cover a broader variety of areas under considerations. Briefly speaking, interoperable and secure services of high-performance are necessary for supporting WS-based business processes. 2.2 The Expressiveness of Business Process Execution Language (BPEL) The Business Process Execution Language (BPEL) specification focuses on supporting the definition of specific WS-based business processes [2], [9]. It is an extensible workflow-based language that aggregates services by orchestrating secure service interactions and transactions. It provides a long-running transaction model that allows increasing consistency and reliability of WS applications. Correlation mechanisms that allow identifying state-full instances of business processes based on business properties are supported. Orchestration and choreography may be applied simultaneously. Orchestration is the ideal composition approach for internal business processes with

114

C.K. Georgiadis and E. Pimenidis

strongly coupled internal actors, while choreography is in general preferred for developing cross-organizational business processes between loosely coupled partners [10]. BPEL's place at the top of the WS platform stack allows it to inherit the expressiveness and power of the underlying standards for use in business processes. Underlying standards provide interoperability through standardized interfaces and messaging protocols. Moreover, as additional specifications are proposed for the WS framework, business processes are expected to take advantage of the new capabilities from those future standards by layering on top of the business logic that the business process provides. But more important is that with the modularity of the framework, additional functional aspects to business processes may easily be added.

XRay Authorization Service XRay Authorization process receives a request for an X-ray

Invokes Role Check service and gets a response synchronously

Doctor (user)

Role Check Service Role Check process receives a message with certain security criteria for the response

Synchronously sends back the information about access control rights of the applicant

Invokes Medical Record service (which will respond asynchronously)

Medical Record Service Receives a response from the Medical Record Service

Medical Record process receives a message with certain performance criteria for the response

Qualifies for an X-ray? XML File (interoperable response)

Asynchronously sends back the results from patient’s medical record Invokes XRay Authorization response service

Fig. 1. XRay Authorization Application Scenario

Finally, a challenging aspect in BPEL is its ability to guarantee transactional integrity. Current research [11] examines BPEL approach to fault, compensation and termination handling comparing it to existing formal theories. We have to underline in this point that not all researchers limit their solutions entirely to BPEL standard: recent significant efforts focus on BPEL adaptations and extensions. A characteristic


115

example is that of Koning et al. in [12], in which they propose a language (VxBPEL), an adaptation of the BPEL. The aim is to investigate how variability can be incorporated into service-based systems.

3 Implementing a WS Composition Scenario The following scenario is an XRay Authorization application which starts when a doctor applies for this type of exams for his patient, by sending in a proper XRay request. The application request then goes through two verification steps: o o

verifying the role, that is the security level/credentials of the applicant, verifying whether important information from patient’s medical record can be retrieved in a certain period of time.

Based on the result of these two responses, the X-ray exam request is either approved or denied. The result is written to an external XML file, assuring the interoperable nature of the whole BPEL composition of WS. The whole application development is facilitated by NetBeans platform [13] and its Integrated Development Environment (IDE 6.5), which provides powerful tools for SOA application development.

Fig. 2. Application Schema

Fig. 3. Role Check Service Descriptor

116


3.1 Role Check Service In Fig.2, the schema file (XSD) of our application is depicted. Initially, UserInformation.Role of the AuthorExamInfo part of the schema is examined in order to update the Status field of RoleCheckStatus part of the schema. We will create a synchronous BPEL process, thus the service descriptor WSDL of Role Check service (RoleCheckDefn.wsdl file, Fig.3) needs to define its operation type as “Request-response Operation” and it also has to define the terms (both for input and output) of the contract implemented by this particular service. Then, we have to create a BPEL file that represents the logic of our Role Check service. The left pane of the process diagram (as it is depicted in Fig. 4), shows partner links for services who send data or a request to the process, that is the partners who initiate communication with the process. The right pane represents partners to whom the process sends messages (the process initiates the communication with the partner). The partner link we created (that is the icon in left with the name RoleCheckPartner which represents the service descriptor RoleCheckDefn), is for the partner who will initiate communication. This icon corresponds to the WS-BPEL activity Partner Link. In general, Partner Links represent communication links between the process and external services. In other words, a partnerlink describes communication between the process and it's partner service.

Fig. 4. Role Check Service – BPEL diagram


117

The Receive and Reply activities (see Fig. 4) are the center of the interest of the BPEL process. In BPEL, the Receive-Reply pair is used to implement a requestresponse operation. When a client (partner) sends a message, the message is handled by the Receive activity, and the Reply activity is used to send the response back to the client. We have to create new variables to handle the communication: one variable associated with the Receive activity, that holds the incoming XML message that is sent by the client, and another one variable associated with the Reply activity, that holds the outgoing XML message that will be used as a response to the client. In other words, the message from the client will be received by the Receive activity and the response will be sent to the client by a Reply activity. This behavior represents synchronous message processing. Certainly, we need to do additional processing after receiving the message. We will determine whether the role of the applicant is appropriate using an If activity and the information contained in the variable associated with the Receive activity. Based on that, we will use an Assign activity to populate the variable for the Reply. When the Reply activity is executed the contents of this variable will be used to send back a response to the client.

Fig. 5. If Condition in Role Check Service BPEL Diagram

As shown in Fig. 5 above, we have created a condition which states "if the Role starts with ‘XRay’, then perform the logic in the If branch". A user who has the Role starting with the letters ‘XRay’ will be deemed appropriate. Otherwise, the person will be deemed inappropriate, and the activities in the Else branch will be executed. The string ‘Authorized’ (see Fig. 6 below) in the response (RoleCheckStatus.Status field of application schema) will indicate to the client that the person passes the access control check, while the string ‘Rejected’ will indicate the opposite. 3.2 Medical Record Service In the next step we will create a Medical Record service, using asynchronous business processes and BPEL correlations. First, a service descriptor file (MedicalRecordDefn.wsdl) will be defined as “One-way Operation” type and it will describe the input term of the asynchronous messaging communication. More specifically, ExamDetails of the AuthorExamInfo part of the XSD schema is defined as request part of the whole Medical Record service. Then, an additional service descriptor file

118


(MedicalRecordRespDefn.wsdl) will be defined also as “One-way Operation” type and it will describe the output term of the asynchronous messaging communication. More specifically, the RecordStatus part of the XSD schema is defined as the response part of the service.

Fig. 6. Assign Activity of the If branch in Role Check Service

Medical Record service is actually based on two independent request-only operations, and is a typical example of an asynchronous business process: the client calls the first operation to send the request to the Medical Record service, the service will do the processing and then, the service calls the client back using the other requestonly operation. Subsequently, we create the BPEL file that represents the logic of Medical Record service. The left pane of the process diagram will show the MedicalRecordDefn service descriptor file, as this operation is actually the partner link (MedRecordProvider) who initiates communication with the process. The right pane will show the MedicalRecordRespDefn service descriptor file, as this operation is a partner (MedRecordRespPartner) to whom the process sends messages. As it is depicted in the logical view of the Medical Record Service BPEL diagram (Fig. 7), a Receive activity handles the message that MedRecordProvider partner sends, and thus we create a new variable to hold the incoming XML message that is sent by the client. In the same way, Invoke activity sends an outbound message to MedRecordRespPartner and thus, another one variable is used to hold that message. We will create the condition for the If activity which states "if PerformInSecs field of the ExamDetails part of the schema (which holds all parameters of doctor’s request), can be satisfied from partner’s capability, then perform the logic in the If branch". The performance of Medical Record Service is considered acceptable and the string ‘Approved’ in the Status field of the involved variable will indicate this fact to the client. Moreover, the PatientExam field will hold user’s request regarding relative medical record information. Otherwise, the activity in the Else branch will be executed and the string ‘Declined’ in the Status field will indicate the opposite. We have to underline the importance of PatientSSN field in message variables: the client that sends a request, as we will see in the next paragraph can be also a service, namely the XRay Authorization Service. So, the value of patient’s SSN is used as a token sent to the Medical Record Service. When it calls back the XRay Authorization


119

Service, it sends the same value in the SSN field of its response. There could be many instances of the XRay Authorization Service active simultaneously and waiting for a response from the Medical Record Service, and we need to send a response to the very instance that sent a request. So when a response comes, the XRay Authorization Service uses the value of the SSN to route the message to the correct service instance. The value of SSN is used as a mark to establish correlation for two asynchronous message exchanges.

Fig. 7. Medical Record Service

Fig. 8. Application Process Files

3.3 XRay Authorization Service In the final step, we will create the XRay Authorization Service so that it could communicate with the Role Check and Medical Record services. Figure 8 presents a detailed view of all the process files in our application. As it is depicted in Fig. 1, a client (doctor) sends an XRay Authorization request to the XRay Authorization Service. This service receives the message and sends a request to the Role Check Service to determine the reliability/suitability of the applicant. The Role Check Service processes the request and returns an approval or denial. Then, the XRay Authorization Service sends an asynchronous request to the Medical Record Service. When the status received are ‘Authorized’ and ‘Approved’ from these two services respectively (Fig. 9), the XRay Authorization Service sends a message to the XRay Status partner to inform the doctor’s decision (based on patient’s medical

120


Fig. 9. If Condition in XRay Authorization Service BPEL Diagram

Fig. 10. XRay Authorization Service BPEL Diagram

record) about the X-ray exam. Fig. 10 presents the BPEL diagram of the XRay Authorization Service. There, the XRAy Status partner represents an XML file, capable of interoperable communication with other non homogeneous systems.

4 Conclusion In developing WS interoperability, security and performance are identified as the key critical success factors that form the main criteria for evaluating the success of an


121

implementation and can define the business success and longevity of the service itself. From the above examples and the discussion of the different BPEL diagrams one can safely conclude that BPEL has the capabilities of defining the requirements for web services that would meet the expectations of the operator for specific levels of security, interoperability and desired performance. The degree of how successfully this can be implemented can be assessed at design level and hence the effectiveness of the application can be evaluated before launch, allowing for realistic expectations from its performance.

References 1. Brown, P.C.: Succeeding with SOA – Realizing Business Value Through Total Architecture. Addison Wesley, Boston (2007) 2. Weerawarana, S., Curbera, F., Leymann, F., Storey, T., Ferguson, D.: Web Services Platform Architecture, NJ. Prentice Hall, Upper Saddle River (2006) 3. Teo, H.M., Kadir, W.M.N.W.: A Comparative Study of Interface Design Approaches for Service-Oriented Software. In: XIII Asia Pacific Software Engineering Conference, APSEC 2006, pp. 147–156. IEEE CS, Washington (2006) 4. Marquezan, C.C., dos Santos, C.R.P., Salvador, E.M., Almeida, M.J.B., Cechin, S.L., Granville, L.Z.: Performance Evaluation of Notifications in a Web Services and P2PBased Network Management Overlay. In: IEEE 31st Annual Intern. Computer Software and Applications Conference, COMPSAC 2007, Beijing, pp. 241–250 (2007) 5. Casola, V., Fasolino, A.R., Mazzocca, N., Tramontana, P.: A policy-based evaluation framework for Quality and Security in Service Oriented Architectures. In: IEEE Intern. Conf. on Web Services, ICWS 2007, Salt Lake City, pp. 1181–1190 (2007) 6. Chen, S., Zic, J., Tang, K., Levy, D.: Performance Evaluation and Modeling of Web Services Security. In: IEEE Intern. Conf. on Web Services, ICWS 2007, Salt Lake City, pp. 431–438 (2007) 7. Han, T., Guo, H., Li, D., Gao, Y.: An Evaluation Model for Web Service. In: IEEE First Intern. Multi-Symposiums on Computer and Computational Sciences, IMSCCS 2006, pp. 698–701. Hanzhou, Zhejiang (2006) 8. Georgiadis, C.K., Pimenidis, E.: Service-Enabled Business Processes: Constructing Enterprise Applications - An Evaluation Framework. In: Sobh, T.M. (ed.) Advances in Computer and Information Sciences and Engineering, pp. 125–130. Springer, Netherlands (2008) 9. OASIS WSBPEL Technical Committee: Web Services Business Process Execution Language Version 2.0, OASIS standard (2007), http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html 10. Papazoglou, M.P., van den Heuvel, W.: Business Process Development Life Cycle Methodology. Communications of the ACM 50(10), 79–85 (2007) 11. Eisentraut, C., Spieler, D.: Fault, Compensation and Termination in WS-BPEL 2.0 – A Comparative Analysis. In: Bruni, R., Wolf, K. (eds.) WS-FM 2008. LNCS, vol. 5387, pp. 107–126. Springer, Heidelberg (2009) 12. Koninga, M., Sunb, C., Sinnemaa, M., Avgeriou, P.: VxBPEL: Supporting variability for Web services in BPEL. Information and Software Technology 51(2), 258–269 (2009) 13. Sun Microsystems, Netbeans IDE 6.5 – SOA Applications (2008), http://www.netbeans.org