A Comprehensive Framework for Dynamic Web ... - Google Sites

A Comprehensive Framework for Dynamic Web Services Integration Zhile Zou, Zhenhua Duan, Jianli Wang Institute of Computing Theory & Technology, XiDian University, Xi’An, 710071, P.R. China [email protected],[email protected],[email protected] Abstract The Business Process Execution Language for Web Services (BPEL) offers a new formal specification for integrating loose-coupled web services and building flexible business processes. However, due to the increasing number of the available services, it is becoming a new challenge to dynamically select and integrate the appropriate partner services for internet-scale business processes. In this paper, we provide a comprehensive framework to implement such dynamic selections and integrations. In this framework, the abstract process template (APT) is utilized as the starting point for the dynamic integrations; the domain services and partner requirements are semantically described with SSD and PPC models, respectively. In this way, the qualified services can be selected through the matchmaking between SSD and PPC instances, and the technical information of the selected operations can be merged into APT through APT binding. To this end, the selected partner services can dynamically be integrated.

1. Introduction Web Services are networked applications that are able to interact using standard application-to-application web protocols over well-defined interfaces [1]. To achieve seamless interactions among the services available on the World Wide Web, lots of industry efforts have been devoted to the development of orchestration and process modeling languages like XLANG [28] and WSFL [29]. Finally, the BPEL [2] specification is co-authored by IBM, Microsoft, BEA, SAP and Siebel Systems and becomes the de facto web services integration standard. In parallel with these industry efforts, solutions from the Semantic Web [4] community and research laboratories are also playing great significance. The efforts from the Semantic Web community include RDF [26], RDF Schema [27],

OWL Ontology Language [5] and OWL-S [6], etc. The OWL Ontology Language is a web standard built on top of RDF and aims at making the web content unambiguously interpretable by computer programs; OWL-S is introduced as a common semantic model for representing the semantics of the web services. OWL-S is composed of a service profile that describes what the service does, a process model that describes how the service works and finally a service grounding that describes how the service is used. However, the OWL-S model may lead to a low retrieval precision due to its weak domain awareness and ignorance of the user context [11]; besides, the OWL-S based composition doesn’t closely connect to the industry standards and is currently not well supported by industry for wider adoption. Also, web services integrations can be static or dynamic. The primary distinction between the two kinds of integrations is that the partner services are determined at design time for static integrations, while these are specified at runtime for dynamic integrations. Dynamic integrations also address the runtime assessment of nonfunctional attributes such as QoS [30], which is also not clearly specified by generic models like OWL-S[12]. Hence, it is desirable to provide a comprehensive integration framework which offers an enhanced service semantics description model and closely connects to existing industry standards. The constraint driven approach [15] proposed by LSDIS laboratory is one of such initiatives. In this paper, we introduce a framework for such dynamic integrations with value-added domain awareness and backchaining [16] features incorporated in the Service Semantics Description(SSD) and Process Partner Contract(PPC) models. With SSD models, the functionalities and QoS aspects of web services can semantically be described, and the service descriptions derived from different domain ontologies can be matched through a similarity-based matchmaking approach; with PPC models, the partner requirements can precisely be specified, and the encoded Abstract Process Template (APT) can be associated with the matched partner services at runtime. The success rate of the dynamic

integration is also improved through the backing-chaining attempts when a specific partner requirement cannot be satisfied. To closely connect to the industry standards, WSDLS[23] is used as the service deployment model and BPEL is used for business process modeling. The rest of this paper is organized as follows: In the following section, some open issues for the dynamic integration framework are firstly proposed, then an overview of our framework is given out; Section 3 introduces the SSD model, and delivers detailed descriptions about the similarity-based matchmaking approach and the utilized QoS model; the structures of APT and PPC are introduced in Section 4, the framework roles of the PPC models are also described; Section 5 illustrates how the technical information of the selected service operations can be merged into the abstract process template, the back-chaining scenarios are also investigated; we compare our approach with related work in Section 6; our conclusions and future works are presented in Section 7.

• The merging of the services’ technical information into APT should be as straightforward as possible in order that the integration risks can be reduced. • The dynamic integration framework should embrace the industry standards to make it a more practical approach to be widely adopted.

2.2

Framework Overview

Our framework is composed of three top-level parts: APT, PPC and SSD, as shown in Figure 1.

2 Framework Overview 2.1

Open Issues

To provide a comprehensive framework for the dynamic web services integrations, we believe the following issues must be taken into account: • Support the semantic descriptions of the process partner requirements and domain services with ontology. This will maximize the similarities between them and provide a more precise matchmaking process. • Support the matchmaking for multi-ontology service descriptions, since it is not practical to assume all the available services are semantically described with the same domain ontology. • The service matchmaking should be domain aware so that services in irrelevant domains can be discarded immediately, and the services in the target domain can efficiently be accessed. • The semantic descriptions of a specific service should be associated with the service’s deployment model in order that the technical information for successful interactions can precisely be extracted. • Additional partner selection attempts should be made when a specific partner requirement cannot be satisfied through the common selection procedure. In this way, the integration success rate can consequently be improved.

Figure 1. Framework Overview APT is the starting point for the dynamic integrations in this framework. Each APT instance is essentially a BPEL abstract process that is defined as a template for the executable process creations. The operational details of some activities in APT can be omitted as placeholders. Each such activity is regarded as a plug-in point where a specific service operation can be later bound. PPC is utilized to describe the expected process partner which is defined as a collection of the APT plug-in points. Each expected process partner corresponds to a partner service matched at runtime. One or more Process Partner Contract Item (PPCI) entries can be aggregated in a PPC instance. Each PPCI entry describes the functionality and/or QoS aspects of a specific plug-in point associated with the partner. From another point of view, each PPCI entry also describes the requirements for the service operation to be bound to the given plug-in point. Each partner service can be regarded as a collection of publicly visible operations, and is described by an SSD instance. The functionality and/or QoS aspects of each service operation are described by a Service Semantics Description Item (SSDI) entry aggregated in SSD. A partner service is matched with a PPC instance only if every PPCI

entry aggregated in the PPC instance can be matched with a certain SSDI entry aggregated in the partner service’s SSD. In a nutshell, APT declares where the service operations can be plugged; PPC describes what features the qualified services should have and how the selected service operations are plugged; SSD describes exactly what features each partner service owns. Further discussions about the framework are presented in the following sections, and a tourism example is provided in details.

this example are both available online1 . A snapshot of the domain ontology is shown in Figure 3.

3 SSD Model In general, a web service can be regarded as a collection of operations, which are published through a specific deployment model as a set of specific functionalities in a specific domain with specific qualities. In SSD, the functionalities of each service operation is semantically annotated in the deployment model; the QoS aspects of each service operation is described with our QoS ontology; the SSDI entries deliver a more compact form of the semantic descriptions about the service operations. The structure of the SSD model is shown in Figure 2, and the SSD related issues are discussed as follows.

Figure 3. Snapshot of Domain Ontology In this example, the bookTicket and cancelTicket operations are declared to provide the ticket booking and ticket canceling businesses, respectively. For each operation in the WSDL-S document, the annotations include: the business it handles, preconditions, effects, the semantics of the message parts in the input/output message definitions, and the semantics of the related XML schema data types. Typically, a concrete SSD instance corresponds to a specific domain service, while each aggregated SSDI entry corresponds to a service operation. Each SSDI entry contains the semantic descriptions of the operation’s functionalities and/or QoS aspects. The corresponding SSDI entries for the bookTicket and cancelTicket operations are specified below.

Figure 2. SSD Model Operation bookTicket

3.1

Deployment Model and SSDI

The WSDL-S [23] specification initially proposed by LSDIS laboratory is used as the deployment model in SSD. WSDL-S offers multiple advantages over OWL-S, such as the combination of the semantics and operation level details in WSDL [25], agnostic ontology representation languages and easier accommodation by existing WSDL tooling [23]. In our framework, OWL ontology is used to semantically annotate the functionalities of the service operations described in WSDL-S documents. Take the tourism domain for example, suppose you are going to visit the Emperor Qin’s Terra-Cotta Warriors and Horses Museum [31] in Xi’An, and the museum offers an online ticket service to handle the ticket booking and canceling. The domain ontology and WSDL-S document of

cancelTicket

Semantic Descriptions in SSDI In: BookTOntology#BookingRequest Out: BookTOntology#BookingConfirmation Pre: BookTOntology#CreditCardValid Eff: BookTOntology#TicketBooked In: BookTOntology#CancelRequest Out: BookTOntology#CancelConfirmation Pre: BookTOntology#BookingIdValid Eff: BookTOntology#TicketCanceled Eff: BookTOntology#TicketFeeReturned

By comparing the two SSDI entries with the deployment model document, it is obvious that the functionality descriptions in the SSDI entries are exactly extracted from the deployment model, but organized in a more compact form. 1 The domain ontology and WSDL-S file of this example are available at http://zouzhile.googlepages.com/webservices

3.2

c=|OS |,d=|OT |

Multi-Ontology Support

X

T Sout =

c=1,d=1

Industry standards like WSDL and UDDI [24] can only provide syntactic level descriptions of web services, and are not efficient enough for the current heterogeneous scalable environments [11]. As a result, many semantics-based approaches are proposed to achieve more precise discoveries and compositions [3, 10, 11, 16, 18], etc. However, most of these approaches are based on a single shared domain ontology, which is an impractical assumption against the tendency that services are described with the domain ontologies from many different parties. Thus, the descriptions with the same meaning but different representations cannot be matched. One solution to the above problem is the approach introduced in [20]. The matchmaking is based on the similarities between the semantic descriptions of two services’ inputs and outputs, instead of the pure subsumption relationships in the same domain ontology. The Total Similarity is introduced as the overall similarity between two concepts. The calculation of Total Similarity is concerned with the following aspects of the two given concepts: URI, name, synonym, data type, associated properties, and neighborhood concepts. Further, the Degree of Compatibility (DOC) is defined as a measurement to determine how compatible one service is to another in terms of the inputs and outputs similarities. Since the semantic annotations in WSDL-S also include preconditions and effects, we naturally extend DOC with preconditions and effects similarities. Also, preconditions and effects can be utilized as the criteria to determine the domain of a given service operation, since they specify the environmental constraints and changes about its execution with respect to a specific domain. Thus we define the Degree of Domain Compatibility (DODC) as a measurement to determine whether two given service operations handle the businesses in the same domain. In this case, the source and target operations are referred as OPS and OPT , and their inputs, outputs, preconditions and effects are referred as IS /IT , OS /OT , PS /PT and ES /ET , respectively. Then each input iS of IS is compared with each input iT of IT , each output oS of OS is compared with each output oT of OT , each precondition pS of PS is compared with each precondition pT of PT , and each effect eS of ES is compared with each effect eT of ET . Let the Total Similarity of the functionalities (inputs, outputs, preconditions and effects) be T Sin , T Sout , T Spre and T Sef f , then DODC and the extended DOC (DOC + ) can be calculated as follows: a=|IS |,b=|IT |

T Sin =

X

a=1,b=1

T otalSim(iSa , iT b ) |IS |

(1)

m=|PS |,n=|PT |

X

T Spre =

m=1,n=1 u=|ES |,v=|ET |

T Sef f =

X

u=1,v=1

DODC =

T otalSim(oSc , oT d ) |OS |

(2)

T otalSim(pSm , pT n ) |PS |

(3)

T otalSim(eSu , eT v ) |ES |

(4)

T Spre + T Sef f 2

(5)

T Sin + T Sout + T Spre + T Sef f (6) 4 where T otalSim is the function defined in [20] for calculating the Total Similarity between two given concepts. For two matched concepts defined in the same domain ontology, the Total Similarity between them is probably high, since they have the similar URI, synonyms and neighborhood concepts, etc. Thus the similarity-based matchmaking also works well with concepts defined in the same domain ontology. In this way, whether the businesses handled by two service operations belong to the same domain can be determined by comparing the DODC value with a threshold value given by the user, i.e. they belong to the same domain if the DODC value is bigger than the threshold. To this end, we say that the matchmaking is domain aware. During the selection of the process partner services, those services belonging to irrelevant domains are immediately discarded. After that, the DOC + values are calculated and compared. For those functionally qualified services, the selection is further optimized with QoS, which is specified in the following subsection. DOC + =

3.3

Quality of Service

The QoS of web services determines the service usability and utility, and will become an important selling and differentiating point of these services. Often, unresolved QoS issues cause critical transactional applications to suffer from unacceptable levels of performance degradation [30]. Generic QoS metrics are based on availability, accessibility, response time, reliability, cost and security [9, 12, 13], as well as some domain specific aspects. We use ontology to explicate the semantics of these metrics in order that they can be compared at semantic level among different representations. Note that web services are integrated into a BPEL business process at operation level, our QoS model is consequently utilized to describe the service operations instead of the whole service. The QoS model of the service operation is defined below:

QoS =< AV, AC, RT, RE, C, S, DM1 , DM2 , ..., DMN > where Item

Description

AV

Availability of the operation on invocation

AC

Accessibility of the operation on invocation

RT

Response Time of the invocation

RE

Reliability of the operation on invocation

C

Cost of the invocation

S

Security support of the operation on invocation

DMi

Domain specific metric

And the overall QoS value of a given service operation op is calculated as follows: QoS(op) = w1 AV (op) + w2 AC(op) + w3 RT (op) + w4 RE(op) + w5 C(op) + w6 S(op) + w7 DM1 (op) + w8 DM2 (op) + ... + wN +6 DMN (op) where each wk (1 ≤ k ≤ N + 6) is the weight of a specific metric and is configured by experienced administrators2 . Besides, the advertised metrics in our QoS model may not cover all the aspects of the QoS requirements from the unpredictable clients. For a QoS metric ms in our QoS model (QMS) and a QoS metric mc in the client’s QoS model (QMC), this conflict can be mediated as follows: • For each ms not specified in QMC, it’s weight is set to 0. It is reasonable that the metric should not contribute to the overall QoS value since the client does not care about it at all. • For each mc not specified in QMS, if it is a generic metric, the QoS request is not matched; if it is a domain specific metric, it may reduce the overall QoS value with a weight specified by the client. • If ms and mc are both specified, they are compared. If ms meets the value specified by mc, its weight value is not changed; otherwise, its weight is assigned to the minus value of the original one, i.e. the unqualified metric will decrease the overall QoS value depending on its importance indicated by its weight. At last, the QoS requirement is satisfied if the overall QoS value is bigger than the threshold given by the client.

4 APT and PPC Model By now, the functionalities and QoS aspects of the partner services are semantically described, and the semantics 2 The evaluation of the metrics based on historical records is out of the scope of this paper, readers are referred to [13].

of the service definitions is also annotated in the deployment model. However, it is still not clear where and how the selected service operations can be integrated. Since APT is used as the start point for the executable process creations, the following questions must be answered before such dynamic integrations can be achieved: • What is exactly an abstract process template? how the components in the template are identified? • How are the partner requirements described? And how is the abstract process template associated with the partner services bound at runtime? • How is the technical information of selected service operations merged into the template? For clearer clarifications, the third issue is discussed later in Section V, after the first two issues are solved in the following two subsections.

4.1

Abstract Process Template

An APT instance is essentially a well defined BPEL abstract process. An abstract process is partially specified because it may omit certain operational details mandatory for the executable process. The abstract process is also not intended to be executed. A typical usage of the abstract process is to serve as the starting point for the executable process creations. The process fragment below presents a straightforward APT sample. ...... ...... ...... ...... We say that an abstract process is well defined only if it satisfies the following constraints: It contains all the necessary process components to construct the corresponding executable process; only some operational details of certain APT components can be omitted as placeholders marked with ”?”; and the abstract attribute value of the

element must be set to yes. The required components may include all the core BPEL elements, while the omitted operational details must be available in the partner services’ WSDL-S documents, such as portType, operation, message types, etc. Each given APT will also be encoded in order that each APT component can be identified, positioned and modified. Since the BPEL process (abstract or executable) definition follows the XML syntax, the process can generally be treated as a tree with the following characteristics: The height of tree is finite but varies from one process to another; the number of the direct child nodes for a specific node is finite but varies from one node to another. Note that the tree hight and the maximum number of direct child nodes are usually not very large, thus the encoding function algorithm3 below is efficient enough for handling most of the encoding cases. Function: Encode entire tree built from APT. Input: Tree root node Output: Root node of the encoded tree EncodedNode encodeTree(Node root) 1: EncodedNode eNode=new EncodedNode(root,”0”); 2: return buildTree(root, eNode); Function: Recursively build the encoded tree Input: Original root node, Encoded root node Output: The root node of the encoded tree. EncodedNode buildTree(Node node, EncodedNode eNode) 1: EncodedNode eNode = encodeNode(node); 2: List children = node.getChildren(); 3: while(children.hasNext()) 4: Node child = children.next(); 5: String parentGC= the global code of eNode; 6: String localCode = the local code of child; 7: String gc= append(parentGC, localCode); 8: EncodedNode eChild=new EncodedNode(child, gc); 9: buildTree(child, eChild); 10: return eNode; With this algorithm, an encoded tree can be derived from the original tree corresponding to the given APT. The hierarchical structure of the derived encoded tree is exactly the same with the original tree, except that each tree node is changed to a corresponding encoded node which has a global code and a reference to the original tree node. Despite APT is encoded, the target encoded node still has to be retrieved before the corresponding target APT component can be modified. Since the global code is constructed by appending the parent’s global code with the local code, an encoded node cannot be on the path from root to the target node unless its global code is the prefix 3 The implementation code and flash demo of the algorithms are available at http://zouzhile.googlepages.com/webservices.

of the target node’s global code. According to this, the target node can be retrieved with the following retrieving algorithm. Function: Retrieve target encoded node. Input: The root node of the encoded tree. The global code of the target node. Output: The target encoded node, return null if not found. EncodedNode getENode(EncodedNode node, String gc) 1: String code = the global code of node; 2: if((code != gc) && node!=null) 3: List children = node.getChildren(); 4: EncodedNode childOnPath = null; 5: while(children.hasNext()) 6: EncodedNode child = children.next(); 7: String childGC = the global code of child 8: if(childGC is prefix of gc) // child on path 9: childOnPath = child; break; 10: if(childOnPath == null) return null; 11: return getENode(childOnPath, gc); 12: else return node; In this way, the APT components can precisely be identified, positioned and modified.

4.2

PPC Model

The PPC model plays two important roles in our dynamic integration framework: one is the partner requirements description model, the other is the bridge between the runtime matched partner services and APT. The structure of PPC is shown in Figure 4.

Figure 4. PPC Model As PPC is utilized to describe the partner requirements, its structure is quite similar to the structure of SSD: Each expected process partner is represented by a PPC instance; the functionality and/or QoS aspects for each associated plug-in point is semantically described by a Process Partner Contract Item (PPCI) entry. However, the structure of PPCI is a little different from the structure of SSDI. Each PPCI entry is composed of three parts: the global code of a specific plug-in point, the functionality and/or QoS descriptions of

the plug-in point, and the reference (URI) of the SSDI entry corresponding to the dynamically selected service operation. After all the partner requirements are specified, the matchmaking is iteratively performed between the PPC and SSD instances, then the qualified partner services are matched. For each selected operation of the matched partner services, the reference (URI) of the SSDI entry is recorded in the corresponding PPCI entry. In this way, a matched partner service is associated with the APT, and each selected service operation is efficiently connected to the target APT component (plug-in point) via global code.

5 APT Binding The dynamic integration can be regarded as a three-step procedure: First, the matchmaking is performed between the process partner contracts (PPC) and the semantic descriptions of the domain services (SSD); then for each selected operation of the matched partner services, the reference (URI) of the SSDI entry is filled in the corresponding PPCI entry; finally, the technical details of each selected operation are extracted from the deployment model with the SSDI entry, and are bound into APT through APT binding. Consequently, the corresponding executable process is also produced. The first two steps have been previously discussed, and the third step will be illustrated in this section. The former tourism example is used to present straightforward understandings.

5.1

General APT Binding

The general APT binding is executed over each selected service operation qualified for a specific plug-in point. For each selected operation, the reference (URI) of the SSDI entry is filled in the corresponding PPCI entry of the plugin point. After all the expected process partners are selected, the general APT binding is iteratively performed with each PPCI entry as follows: • Extract the functionality details contained in the SSDI entry with the filled-in SSDI entry reference. Operation

Functionality Details in SSDI

bookTicket

In: BookTOntology#BookingRequest Out: BookTOntology# BookingConfirmation Pre: BookTOntology# CreditCardValid Eff: BookTOntology#TicketBooked

• Extract the operational details from the deployment model with the functionality details. Item

Operational Detail

operation

bookTicket

portType

impl:BookingTicket

Input Message:

impl:bookTicketRequest

Output Message

impl:bookTicketResponse

• Merge the operational details into the corresponding APT component with the global code specified in PPCI. APT Component

Executable BPEL





However, for a given PPCI entry, a qualified SSDI entry may not be available in some cases. Instead of simply reporting the integration failure, further attempts are made through back-chaining as introduced in the following subsection.

5.2

APT Binding with Back-Chaining

To improve the success rate of the dynamic integration, the back-chaining algorithm is supported. Let op be an operation and Iop , Oop , Pop , Eop be its inputs, outputs, preconditions and effects, then op can be replaced by a series of operations op1 , op2 , ... , opn with the following constraints: • For each opi , (1 ≤ i ≤ n), the inputs, outputs, preconditions and effects are represented by Iopi , Oopi , Popi , Eopi , respectively. • Iop1 matches with Iop , Pop1 matches withPop ; and Oopn matches with Oop , Eopn matches with Eop .

• For operations opi , opj (1 ≤ i < j ≤ n, j = i + 1), Oopi matches withIopj , Eopi matches with Popj . With the above constraints, the operations op1 , op2 , ... , opn are chained together, as shown in Figure 5:

Figure 5. Back-Chaining The back-chaining starts from selecting an operation opn which matches with the outputs and effects of the operation op, then a series of opn−1 , opn−2 , ... , op1 are recursively selected with the above constraints satisfied. According to [25], there are four transmission primitives (operation types) can be supported by an endpoint: one-way, request-response, solicit-response and notification. From the BPEL process perspective, these primitives correspond to the following activities, respectively: • one-way: A one-way primitive corresponds to an Invoke activity without the outputVariable attribute specified. • request-response: A request-response primitive corresponds to an Invoke activity with both inputVariable and outputVariable specified. • solicit-response: A solicit-response primitive corresponds to a Receive-Reply pair in the process. • notification: A notification primitive corresponds to a Receive activity. The back-chaining is intended to be performed among the partner services outside the process, thus the solicitresponse and notification primitives cannot be supported since the receive message of the process cannot be splited. The back-chaining for the request-response primitive is exactly the same with the one shown in Figure 5. As to the one-way primitive, the back-chaining is even simpler with the constraint ”Oopn matches with Oop ” omitted, as shown in Figure 6:

Figure 6. Back-Chaining for One-Way Hence, the implementation of back-chaining in APT Binding will be discussed over the request-response primitive, a similar implementation can easily be derived for the one-way primitive.

For the request-response primitive op, it is noted that each of the back-chained operations op1 , op2 , ... , opn is also a request-response primitive. And for the operations opi and opj (1 ≤ i < j ≤ n, j = i + 1), the outputs Oopi are equivalent to the inputs Iopj . Thus, each of the back-chained operations corresponds to an Invoke activity, and the chain segment between opi and opj corresponds to an Assign activity that assigns Oopi to Iopj . As a result, the original Invoke activity is replaced by a sequence of interlaced Invoke and Assign activities, as shown in Figure 7.

Figure 7. APT Binding with Back-Chaining Note that two XML schema types may be specified semantically equivalent but defined differently in syntax, thus the assignment may involve some human interventions. Finally, each of the interlaced Invoke and Assign activities is bound using the general APT binding approach specified in the previous subsection, and the corresponding executable BPEL process is produced.

6 Related Work Semantics-based service selections and integrations have attracted lots of attention in recent years. The ability to dynamically select and integrate partner services is regarded as a key to the success of Service-Oriented Architecture (SOA). Academic approaches like OWL-S use ontology to semantically describe the functionalities and capabilities of web services, and try to achieve such dynamic selections through explicated service semantics. However, some important nonfunctional aspects like QoS are not clearly specified in such generic models. Then, some QoS models are proposed separately to incorporate QoS in the service descriptions, selections and compositions [9, 12, 13]. Some other enhanced description models are also proposed to achieve more precise service discoveries, such as the PILLAR conceptual model introduced in [11]. Also, WSDL-S annotates the functionality semantics in the WSDL file and aims at being widely supported by industry for wider adoption. In this paper, the SSD model provides a combination of the functionality and QoS descriptions at operation level, and the aggregated SSDI entries offer a compact form of such descriptions for the service operations. The matchmaking of the semantically described services is crucial to the dynamic service selection. Earlier approaches are based on the inputs and outputs matchmaking

between advertisements and requests [3]. Then the preconditions and effects of the service operations are also taken into account, such as the behavioural constraints based approach introduced in [10]. However, such approaches are usually based on a single domain ontology, and are not powerful enough for the matchmaking in heterogeneous and multi-domain environments. The similarity-based approach introduced in [20] supports the matchmaking in multiontology environment, and it is extended by our SSD model to support the precondition/effect matchmaking among the operations described with different ontologies. Our integration framework has several concepts similar to the constraint driven approach [15] proposed by LSDIS laboratory, such as abstract process template, functionality semantics and abstract process template binding. However, our approach is different from the constraint driven approach in a number of ways, such as: • The matchmaking of the partner services is domain aware. Whether two services belong to the same domain can be determined by the similarity-based matchmaking; while the constraint driven approach depends on the keywords specified by certain categorization schemes, such as the NAICS taxonomy. • The multi-ontology matchmaking is supported. • The QoS metrics are associated with weights, thus the importance of different metrics are effectively reflected, and consequently the overall QoS can be better evaluated. • The abstract process template is encoded in order that the selected service operations can precisely be connected to the target APT components. • The APT binding is enhanced with back-chaining support. For one-way and request-response primitives, the integration success rate can be improved. A Bottem-Up approach is also introduced in [16] to adapt BPEL for the semantic web. At the heart of this approach is the Semantic Discovery Service (SDS) and the semantic translation of the well-defined data types in terms of their relationships to another via implicit or explicit translational axioms. The SDS receives invocations from BPEL processes, and then dynamically select and invoke the qualified partner services. However, SDS is stateless, thus it cannot handle some complex BPEL issues appropriately, such as correlated invocations; and the matchmaking takes place every time an arbitrary invocation is dispatched from BPEL process, even two invocations are exactly the same. This may cause a corresponding runtime performance degradation. While our approach provides a comprehensive framework for dynamically generating executable processes, and the complexity of BPEL is fully covered.

Some other OWL-S based composition approaches are also proposed. In [18], each partner service is encoded into a nondeterministic state transition system, and all state transition systems are combined into a planning domain. Then based on the given composition goal, a plan is generated and can be translated into process languages like BPEL. Another approach is introduced in [19] to define a theoretical framework for automated process-level compositions. For each of the above approaches, OWL-S process model is applied to describe the partner services and serves as the starting point for automated service compositions. However, we provide a different dynamic integration solution which closely combines the efforts of Semantic Web community with industry standards like BPEL and WSDL for wider adoptions and implementations.

7 Conclusion In this paper, we provide a comprehensive framework to dynamically integrate web services. The functionality and QoS aspects of process partner requirements and partner services are semantically described by SSD and PPC models, respectively; the dynamically selected service operations are associated with the target APT components through PPCI entries; the operational details are extracted from WSDL-S documents with the SSDI entries, and are merged into APT through APT binding. In this way, the partner services can precisely be selected and integrated at runtime, and the corresponding executable BPEL process is also produced. The contributions of our approach are specified as follows: • The similarity-based approach introduced in [20] is extended to perform the matchmaking of the service functionalities in the multi-ontology environments. And the domain awareness feature incorporated in SSD improves the matchmaking efficiency by discarding the irrelevant services immediately. • We provide a QoS model to precisely capture the QoS aspects of the service opertions. • An APT encoding algorithm is introduced to facilitate the runtime partner association. With the encoded APT, the matched service operations can efficiently be connected to the corresponding APT components through PPCI entries. • The back-chaining algorithm is implemented in APT binding, and the integration success rate is considerably improved for one-way and request-response primitives. • The entire integration framework appropriately combines the efforts from industry, Semantic Web commu-

nity and research laboratories, and provides a practical solution for dynamic web services integrations. We believe our approach has brought flexibility and utility to the dynamic web services integrations. Further investigations will be taken to appropriately handle the full complexity covered in the APT binding procedure. Such complexity is mostly caused by the different syntactic extensions for the abstract process and executable process. The APT encoding algorithm will also be optimized to present more efficient and precise APT binding procedures.

Acknowledgment This research is supported by the NSFC (National Natural Science Foundation of China) Grant No. 60373103 and 60433010, the SRFDP (Specialized Research Fund for the Doctoral Program of Higher Education) Grant 20030701015.

References [1] W3C:Web Services, http://www.w3.org/2002/ws/ [2] BEA Systems, IBM, Microsoft: Business Process Execution Language for Web Services, Version 1.1. IBM developerWorks (2003). Available from http://www128.ibm.com/developerworks/library/specification/ws-bpel/ [3] Massimo Paolucci, Takahiro Kawamura, Terry R.Payne, and Katia Sycara: Semantic Matching of Web Services Capabilities. International Semantic Web Conference 2002: 333-347. [4] W3C: Semantic Web, http://www.w3.org/2001/sw/ [5] W3C: OWL Ontology Language Reference, http://www.w3.org/TR/owl-ref/ [6] OWL-S, http://www.daml.org/services/owl-s/ [7] Haiyan Sun, Xiaodong Wang, Bin Zhou, and Peng Zou: Research and Implementation of Dynamic Web Services Composition. Advanced Parallel Processing Technologies 2003: 457-466. [8] Fabio Casati, Ski Ilnicki, LiJie Jin, Vasudev Krishnamoorthy, Ming-Chien Shan: Adaptive and Dynamic Service Composition in eFlow, in Proceedings of the 12th International Conference on Advanced Information Systems Engineering:13 31 [9] San-Yih Hwang, Haojun Wang, Jaideep Srivastava and Raymond A. Paul: A Probabilistic QoS Model and Computation Framework for Web Services-Based Workflows. Conceptual Modeling - ER 2004: 23rd International Conference on Conceptual Modeling: 596-609. [10] Natenapa Sriharee and Twittie Senivongse: Discovering Web Services Using Behavioural Constraints and Ontology. Distributed Applications and Interoperable Systems: 4th IFIP WG6.1 International Conference, DAIS 2003: 248 - 259. [11] Islam Elgedawy: A Conceptual Framework for Web Services Semantic Discovery. On The Move to Meaningful Internet Systems 2003: OTM 2003 Workshops: 1004 - 1016

[12] V. Deora, J. Shao, G. Shercliff, P.J. Stockreisser, W.A. Gray and N.J. Fiddian: Incorporating QoS Specifications in Service Discovery. Web Information Systems - WISE 2004 Workshops: 252-263. [13] Derong Shen, Ge Yu, Tiezheng Nie, Rui Li1 and Xiaochun Yang: Modeling QoS for Semantic Equivalent Web Services. Advances inWeb-Age Information Management: 5th International Conference,WAIM 2004: 478 - 488. [14] Hongen Lu: Semantic Discovery of Web Services. Knowledge-Based & Intelligent Information & Engineering Systems: KES 2005: 915-921 [15] Rohit Aggarwal, Kunal Verma, John Miller, William Milnor: Constraint Driven Web Service Composition in METEOR-S. Proceedings of the 2004 IEEE International Conference on Service Computing (SCC’04) [16] Daniel J. Mandell and Sheila A.McIlraith: Adapting BPEL4WS for the Semantic Web: The Bottom-Up Approach to Web Services Interoperation. International Semantic Web Conference 2003: 227- 241 [17] Boualem Benatallah, Mohand-Said Hacid, Alain Leger, Christophe Rey, Farouk Toumani: On automating Web Services discovery. The VLDB Journal The International Journal on Very Large Data Bases(2004)/Digital Object Identifier(DOI) 10.1007/s007/20078-003-0117-x: 84 - 96 [18] Paolo Traverso and Marco Pistore: Automated Composition of Semantic Web Services into Executable Processes. The Semantic Web CISWC 2004: Third International Semantic Web Conference. [19] Marco Pistore, Pierluigi Roberti and Paolo Traverso: Process-Level Composition of Executable Web Services: ”On-the-fly” Versus ”Once-for-all” Composition. The Semantic Web: Research and Applications: Second European Semantic Web Conference, ESWC. [20] Sasiporn Usanavasin, Shingo Takada, and Norihisa Doi: Semantic Web Services Discovery in Multi-ontology Environment. On the Move to Meaningful Internet Systems(OTM)2005. [21] E. Michael Maximilien, Munindar P. Singh:A Framework and Ontology for Dynamic Web Services Selection. IEEE Internet Computing 8(5):84-93, September-October 2004 [22] Naveen Srinivasan, Massimo Paolucci, Katia Sycara: An Efficient Algorithem for OWL-S based Semantic Search in UDDI. Semantic Web Services and Web Process Composition: First International Workshop, SWSWPC 2004. [23] WSDL-S, http://www.w3.org/Submission/WSDL-S/ [24] UDDI, http://www.uddi.org/ [25] WSDL, http://www.w3.org/TR/wsdl [26] W3C: RDF, http://www.w3.org/RDF/ [27] W3C: RDF Schema, http://www.w3.org/TR/rdf-schema/ [28] Satish Thatte: XLANG, http://www.gotdotnet.com/team/xml wsspecs/ xlang-c/default.htm [29] Frank Leymann: WSFL, http://www306.ibm.com/software/solutions/ webservices/pdf/WSFL.pdf [30] IBM developerWorks: Understanding quality of service for Web services , http://www128.ibm.com/developerworks/library/ws-quality.html [31] Emperor Qin’s Terra-Cotta Warriors and Horses Museum, http://www.bmy.com.cn/index eng.htm