Automatic Service Process Administration by

Automatic Service Process Administration by Semantic Service Discovery Steffen Bleul — Michael Zapf — Kurt Geihs Universität Kassel Distributed Systems Wilhelmshöher Allee 73 D-34121 Kassel Germany {bleul,zapf,geihs}@vs.uni-kassel.de

ABSTRACT. One of the salient features of Service-Oriented Architectures is that services can be deployed and removed at runtime. Service replacement and management for service processes is a demanding task in complex environments, especially under additional constraints like minimizing downtime. We introduce an approach for automatic service process administration. A service process ontology allows to describe service processes with roles and the functionality of the required roles. Semantic annotations allow to compare services with compatible behavior but different operation, parameter, or task naming. The matching result is specified with our service result ontology. We describe a procedure to automatically modify service execution descriptions, which can be utilized for achieving self-manageability of service processes. KEYWORDS:

service process, web service, management, discovery, web service, ontology

1. Introduction Enterprises increasingly rely on SOAs to implement their business logic and to execute their business workflows. Business processes can be represented by a composition of services, and services may be rearranged when these processes change. Business logic is implemented as services, whereas business workflows are realized as services processes. Service process execution languages like BPEL4WS (Andrews et al., 2003) allow for the specification of execution details, while execution engines take care of the workflow at runtime. This increase in flexibility comes at a cost: Managing SOAs becomes more and more difficult. Services may have separate, distributed runtime environments, and when a service ceases to work or to maintain its quality, a complete service process can become unusable. In that situation the service process must be quickly restored by replacing faulting services. We can identify some basic challenges here: – A replacement for the defect service must be discovered which offers the required functionality. However, common interface descriptions are not sufficient to discover functionally equivalent services. – The bindings within the WSDL document must be modified to point to the replacement service. The identifiers inside the description document must be mapped to the identifiers inside the interface description of the discovered service. – In some situations, the process execution description itself needs modification in order to adapt to the specific properties of a replacement service. Frameworks for dynamic business processes may be appropriate to meet these issues, e.g. based on BPEL4WS, which either allow the specification of service alternatives before runtime, or the configuration of a proxy (Ezenwoye et al., 2006, Baresi et al., 2004, Blow et al., 2004). Both cases rely on manual preselection of service alternatives. Another approach is to assist manual service discovery with machineprocessable semantics, e.g. with OWL-S (Burstein et al., 2004) or the Web Service Modeling Ontology (WSMO) (Roman et al., 2005). A matching algorithm assists the administrator with a preselection of appropriate services (Jaeger et al., 2005). These approaches, however, only realize a semi-automatism. There exists a number of activities in the area of semantic service process management. The METEOR-S project (Patil et al., 2004) demonstrates the configuration and execution of web processes (Verma et al., 2005) and also the semantic description of service processes. While this project employs a parameter-based matching, there is no support for optional and required operations which allows to consider different execution descriptions. Moreover, METEOR-S uses a central configurator which directly accesses and configures service proxies. We envisage a platform-independent approach which focuses on service process execution descriptions. ODE SWS (Gomez-Perez et al., 2004) is a semantic framework for the specification of service processes. Service processes are specified by an ontology. The ODE framework requires to specify the execution of the whole service process. In our

Automatic Service Process Administration

ServiceProcess

Concrete Role

hasConcreteRole

hasRoleRequest

hasAlternative

Role Request

hasExecution

providedBy

Service

describedBy

describedBy

ServiceBrokering Request

mandatory

ServiceProcess Grounding

optional

Operation

Figure 1. Service Process Ontology

work, we restrict the specification to functional aspects without invocations, message exchange and execution constraints. This allows us to avoid cumbersome translations into ontology schemas. Automatic service process administration may greatly enhance self-management properties for these processes, allowing to handle complex processes, as we already showed in (Bleul et al., 2007a). In that article we concentrated on the specific details of our approach for service processes in relationship to BPEL4WS and Web Services. A more detailed description of our matching algorithm and our extensions on the OWL-S ontology can be found in (Bleul et al., 2007b). The paper is structured as follows: Section 2 introduces the process ontology we use to specify services as roles in service processes. Afterwards the discovery process is presented in Section 3. The prototype for adapting BPEL4WS descriptions is described in Section 4, and we finally present our conclusions in Section 5.

2. Ontology-Based Service Process Descriptions The motivation for a service process ontology is to enable automatic semantic service discovery in service processes. The structure of such an ontology is presented in Figure 1. It offers a high-level view on service processes by abstracting from the execution logic, i.e. invocations and statements; instead, it introduces roles and their functionalities. The overall goal is to find appropriate services for all role requests inside a service process. The specification of the functionalities of roles is semantic, which entails a semantic service discovery to find successful service matches for roles. Role descriptions appear as concrete roles and role requests. Invocation sequences may be specified by process execution descriptions, which commonly reference services by URI. We distinguish concrete roles which represent services that are statically

Customer Application

Ordering ServiceProcess

Storehouse Service

Fruit Storehouse

Order(article,count) RequestOrder(FruitOrder) Order(Order) AffirmOrder(FruitOrder) or Optional: Cancel()

Affirm(Order)

Figure 2. Service invocations in a sample business process

specified inside a process description from role requests which are part of a service brokering request. A role request represents a service functionality that is a generic service functionality inside a process execution description. The functionality of a service is expressed by its operations, together with parameters. In our approach, we allow for operations to be classified as mandatory or optional. This allows to find matches which satisfy at least the mandatory properties, but fail to comply with some or all optional parts. Figure 2 may serve as an illustration of a business process. This one refers to online ordering of fruits from a wholeseller. The Ordering Service Process represents the service process at runtime that delivers the functionality of an ordering process. Its functionality is described by operations, here the operation Order. Additionally the service process requires a Storehouse Service. This (concrete) service may be unknown at the design phase of the service process. The business process is specified using the service process ontology, along with its service brokering request. Figure 3 presents the specification of the OrderingServiceProcess in form of a knowledge graph. Individuals are shown as vertices; properties serve as edge labels. We associate the execution description with the hasExecution property to roles. Extending the scenario of Figure 2, we specify two different roles, the StorehouseServiceWithCancel role and the StorehouseServiceWithoutCancel role. Only the first role offers the optional operation Cancel. Our ontology allows to formalize this fact by declaring this operation as optional. Thus, we may effectively specify two roles which have different execution descriptions by one common service brokering request.

3. Discovery Process In this section we shall provide a brief illustration of the discovery process. The overall goal is to discover services for all roles inside a service process ontology in order to adapt a service process description. Thus, all successfully discovered service roles must either be defined in the ProcessWithoutCancel or the ProcessWithCancel

Automatic Service Process Administration

Figure 3. Description of the Business Process using the Service Process Ontology

ontology. Instead of just verifying that the actual parameters match with respect to data types, we compare the annotations of the parameters. The semantic of the attributes is defined by the ontology. We use the algorithm of (Jaeger et al., 2005) as a base for our algorithm and for the ranking of matching results. The service functionality is expressed by its operations and by the semantic annotations of the operation parameters. Let us demonstrate a simplified example of the matching algorithm related to our scenario. In order to match the individuals of the parameters against each other, we use their semantic relations. Operation

Input

Output

Task

Order Affirm RequestOrder AffirmOrder

&retail;#Order &retail;#Order &retail;#FruitOrder &retail;#FruitOrder

&retail;#Validation &retail;#Validation &retail;#Validation &retail;#Validation

&retail;#CheckAvailability &retail;#ExecuteOrder &retail;#CheckStorehouse &retail;#Deliver

Figure 4. Semantic Annotation of the Operations The table in Figure 4 shows the service brokering request in the first row and the description of an offered service in the second row. The descriptions use semantic annotations for their input and output parameters as well as for the task description. The optional operation Cancel is omitted here. Obviously, the semantic descriptions differ in some positions. It is up to the ontology to create relationships between these annotations. So if we define the retail ontology as follows:

1 2 3 4

< r d f s : s u b C l a s s O f r d f : r e s o u r c e ="# GoodsOrder " / >

5 6 7 8 9



we can successfully match the operations Order and RequestOrder against each other: For both operations, the output parameter is annotated with the individual Validation so both produce an equivalent output. Furthermore, they obviously offer semantically equivalent tasks, as the individuals CheckAvailability and CheckStorehouse are both instances of the class StockhouseQuery. Finally, we can successfully match the input parameters: FruitOrder is a specialization of the individual Order since FruitOrder’s class FruitGoodsOrder is a subclass of the Order’s class GoodsOrder. The operations Affirm and AffirmOrder can be matched analogously. Concluding, the service FruitStorehouse can act as the role StorehouseServicewithoutCancel since it offers the required operations and therefore the requested functionality. As a result, we get an ontology. This result ontology is internally represented by an XML document and formally specifies the result of our semantic reasoning. 1

4. BPEL4WS Grounding BPEL4WS is a language to specify the execution flow of service processes consisting of Web Services. BPEL specifies the interaction with Web Services. In this context, a grounding is a reference from a service offer to a specific Web Service. In the following, we present an example grounding using BPEL4WS. We have built a prototype which is capable of performing an automatic service matching and reconfiguration of service processes. Figure 5 describes the phases of service matching and process adaptation within our prototype. The steps of the adaptation process are referenced in the text and in the figure by the letters A–H. The invocations and statements in BPEL4WS relate to a service contract, defined in a WSDL document (A). Both descriptions are purely syntactic, and we can directly transform WSDL descriptions into an OWL-S schema (B). Now we have a semantic instance of the OWL-S schema, consisting of profiles for each operation and input/output parameters for each message part in WSDL. At this point we work on the semantic level and we manually annotate the operation parameters (C). Additionally we specify the service process ontology which links the service brokering requests to BPEL specifications (D). After providing all the necessary infor1. More details on the structure of the result ontology may be found in (Bleul et al., 2007b).

Automatic Service Process Administration

ServiceOffer WSDL

ServiceOffer OWL-S

(B) + (C)

(E)

Result Reference

BPEL4WS Specification (A)

PartnerService WSDL

Syntactic Level

(H)

Mapper

Result Ontology

(G)

Adaption Process (B) + (C)

(F)

(E)

Result Reference

PartnerService OWL-S

Matcher

(D)

ServiceProcess Ontology

Semantic Level

Figure 5. BPEL4WS Semantic Service Discovery and Adaptation Process

mations on the semantic level, we use the logical entity Matcher for semantic service discovery (E), returning a result when a match is found (F). The result ontology provides detailed information about the match of offered operations to requested operations and offered parameters to requested parameters. Using the WSDL identifiers inside the grounding ontology, we can directly link offered WSDL operations and message parts on WSDL operations and message parts referenced in the BPEL description. This is used by the Mapper (G) to adapt the BPEL description to be able to use the discovered services (H). Summing up: For each role, the Mapper – changes the BPEL references on WSDL files of a service brokering request to the WSDL file of the discovered service (BPEL Imports). – changes the BPEL references on WSDL operations of a service brokering request to WSDL operations of the discovered service (WSDL PortTypes). – changes the BPEL references on WSDL message parts of a service brokering request to WSDL message parts of the discovered service (WSDL MessageParts).

5. Conclusions Ontologies may be utilized to enhance semantic service discovery in a serviceoriented architecture and to automatically find and replace services within business processes. In our approach, we use roles which represent functional requirements instead of comparing invocation and statement sequences – thus abstracting from concrete realizations. This allows a much more flexible brokering process, delivering a service which actually works as requested.

Processes may be automatically adapted when services fail or other functionally equivalent variants of services are found. This will be helpful to introduce selfproperties in SOAs like self-healing (Bleul et al., 2007a).

6. References Andrews T., Curbera F., Dholakia H., Goland Y., Klein J., Leymann F., Liu K., Roller D., Smith D., Thatte S., Trickovic I., Weerawarana S., BPEL4WS, Business Process Execution Language for Web Services Version 1.1, IBM. 2003. Baresi L., Ghezzi C., Guinea S., « Smart Monitors for Composed Services », ICSOC ’04: Proceedings of the 2nd International Conference On Service Oriented Computing, ACM Press, New York, NY, USA, p. 193-202, 2004. Bleul S., Zapf M., « Ontology-Based Self-Organization in Service-Oriented Architectures », Proceedings of the Workshop SAKS 2007, VDE, Bern, Swiss, March, 2007a. Bleul S., Zapf M., Geihs K., « Flexible Automatic Service Brokering for SOAs », Proceedings on 10 th IFIP / IEEE Symposium on Integrated Management (IM 2007), Munich, Germany, May, 2007b. Blow M., Goland Y., Kloppmann M., Leymann F., Pfau G., Roller D., Rowley M., « BPELJ: BPEL for Java. », BEA and IBM, March, 2004. Burstein M., Hobbs J., Lassila O., Mcdermott D., Mcilraith S., Narayanan S., Paolucci M., Parsia B., Payne T., Sirin E., Srinivasan N., Sycara K., « OWL-S: Semantic Markup for Web Services », Website, November, 2004. Ezenwoye O., Sadjadi S. M., RobustBPEL-2: Transparent Autonomization in Aggregate Web Services Using Dynamic Proxies, Technical Report n˚ FIU-SCIS-2006-06-01, School of Computing and Information Sciences, Florida International University, 11200 SW 8th St., Miami, FL 33199, June, 2006. Gomez-Perez A., Gonzales-Cabero R., Lama M., « ODE SWS: A Framework for Designing and Composing Semantic Web Services », , vol. 19, n˚ 4, p. 24-31, July, August, 2004. Jaeger M. C., Rojec-Goldmann G., Liebetruth C., Mühl G., Geihs K., « Ranked Matching for Service Descriptions using OWL-S », Kommunikation in verteilten Systemen (KiVS 2005), Informatik Aktuell, Springer Press, Kaiserslautern, Germany, p. 91-102, February, 2005. Patil A., Oundhakar S., Sheth A., Verma K., « METEOR-S Web Service Annotation Framework », Proceedings of the Thirteenth International World Wide Web Conference (WWW2004), LSDIS Lab, University of Georgia, New York, USA, May, 2004. Roman D., Keller U., Lausen H., de Bruijn J., Lara R., Stollberg M., Polleres A., Feier C., Bussler C., Fensel D., « WSMO - Web Service Modeling Ontology », DERI Working Draft 14, vol. 1, Digital Enterprise Research Institute (DERI), IOS Press, BG Amsterdam, p. 77106, 2005. Verma K., Gomadam K., Sheth A. P., Miller J. A., Wu Z., The METEOR-S Approach for Configuring and Executing Dynamic Web Processes, Technical report, University of Georgia, Athens, June, 2005.