An Abstract Workflow-Based Framework for Testing ... - IEEE Xplore

8 downloads 2324 Views 175KB Size Report
An Abstract Workflow-Based Framework for Testing Composed Web Services. Marcel Karam*1, Haidar Safa1, Hassan Artail2. 1 Department of Computer ...
An Abstract Workflow-Based Framework for Testing Composed Web Services Marcel Karam*1, Haidar Safa1, Hassan Artail2 1 Department of Computer Science 2 Department of Electrical and Computer Engineering American University of Beirut P.O.Box: 11-0236 Riad El-Solh, Beirut 1107-2020, Lebanon Phone: +961 1 350000, ext. 3520 Fax: +961 1 744461 E-mails: { mk62, hs33, hartail}@aub.edu.lb

WSDL document and tries to bind it using Simple Object Access Protocol (SOAP) messages [32]. SOAP is an XML-based messaging protocol that provides the communication layer to access WSs. An input SOAP message is used by the WS requester to invoke the service, and an output SOAP message is generated by the WS to answer the requester. A common usage scenario for WSs can be modeled as: Publish (by service provider); Find (by service requester); and Bind (service broker). A WS provider publishes the WSDL document to the WS broker using the UDDI registries; A WS requester (person or organization) finds a suitable WS according to a certain specific requirements found in the UDDI registries; A WS broker acts as a matchmaker between the WS provider and requestor; that is, once a WS is found at the UDDI registries, the WS requestor gets its corresponding WSDL document and tries to bind with the WS using SOAP messages. WSs can be either basic or composite. A Basic WS does not rely on any other WSs, whereas a composite or composed WS (CWS) is a business process that usually performs a complex task requiring an interacting number of WSs or activities structured in a workflow-like fashion. For example, a complete (composed) traveling WS comes from the collaboration of the following services: travel agent; airline; hotel; car rental; entertainment; and billing. The Business Process Execution Language for Web Services (BPEL4WS) or BPEL [7] is a formal specification of business processes and interaction protocols that captures, in a platformindependent manner, all behavioral aspects that have cross-enterprise business significance, both at the intraand inter-organization level. BPEL facilitates the definition of WSs in a workflow-like format; however, like most choreography languages, it provides notations to describe the message flow in the collaboration, but lacks some reasoning mechanisms to verify the interaction between WSs. As a result, a predefined

Abstract Testing web services impose many challenges to existing testing methods, techniques, and tools; especially those available to traditional applications. Composed web services increase these challenges by requiring additional validation and verification efforts. Structural-based testing approaches have been thoroughly researched for traditional applications; however, they have not yet been examined, as a methodology, for testing composed web services. In this work, we introduce a formal model for an abstract-based workflow framework that can be used to capture a composed web service under test. We then define a set of applicable structural-based testing criteria to the framework. Finally we outline a promising line of testing criteria that can be applied to this framework.

1. Introduction A Web Service (WS) is an autonomous entity of algorithmic logic that is usually placed into a (WS) server. A Web Services Description Language (WSDL) [10] is then used to describe the technical details of WS’s interface such as: what operations are supported by the WS; what protocols are used; and how the exchanged data should be packaged. The WS provider (organization or person) can then publish the WSDL document using the Universal Description, Discovery and Integration (UDDI) registries [30]. A UDDI registry is a “yellow pages-like” document that provides a standard format that is readable by other Web Services (WSs) for describing organizations, their services, and ultimately their online discovery. The latter can be accomplished using the value of the Uniform Resource Locator (URL) that is stored in the UDDI and points to the WSDL specification of the WS. Once a WS is discovered in the UDDI, the WS requester (service invoker) acquires its corresponding

1-4244-1031-2/07/$25.00©2007 IEEE

901

process is likely to behave abnormally. With the increasing number of workflows that are being modeled using BPEL, testing CWSs becomes increasingly necessary to maintain a certain quality assurance about the composition process, and subsequently its execution correctness. Despite this valid observation, we find that only little research has been done in this area. For example, most testing efforts of CWSs focus on: test process automation for WSs using agent-based technologies [30, 34]; automatic generation of test cases for testing WSs [21], and recently BPEL-based unit testing for CWSs [22]. Most of these efforts however, did not address testing of CWSs the context of a structural framework that could capture the separation of concerns: semantic, control; data; security; and exception in a CWS or a process workflow. In the area of process (workflow) views and related notions of a partial workflow, research focused on: constructing a process view from a given workflow [17]; modeling cross organization workflows and workflow schema exchange [8, 9, 25]; derivation of private workflows from interorganizational workflows [32]; and the concept of workflow projection inheritance by means of derivation rules that decides whether a workflow is behaviorally bisimilar to the original workflow [3]. However, none of these workflow efforts examined a workflow’s structural representation of a process (set of activities) to test CWSs; especially in the context of the previously mentioned separated concerns. This work describes our current efforts in providing a structural-based workflow framework (hereafter referred to as SBWF) for testing CWSs. In this direction, we use, in the context of CWSs, current flows “view” of a workflow [17, 23, 25], to support the conceptual development of SBWF and its supporting structural testing strategies (deferring language issues at this time). We investigate the representation of a subset of the above mentioned concerns in SBWF, and provide, in particular, control-flow test adequacy criteria for testing CWSs. The remainder of this paper is organized as follows: In section 2 we explain some terminologies and provide an overview of semantic web, and semantic web services. We then discuss related work in terms of workflow modeling of WSs, as well as the current state of the art in testing techniques for WSs. In section 3, we introduce a case study that we use to show the feasibility of our proposed framework and methodology. In section 4, we introduce, in the context of the case study, a formal approach for constructing SBWF. In Section 5, we introduce a family of control-flow based test adequacy criteria that is applicable CWS under test in SBWF. In section 6, we conclude with some future work and; especially in the direction of testing expansion strategies, as well as regression testing in the context of SBWF.

2. Literature Review and Related Work This section provides an overview of Semantic Web and Semantic Web Services. Then web services workflow modeling approaches, as well as some of the attempts to test WSs will be presented.

2.1 Semantic Web and Semantic Web Services Semantic Web enabling standards are built on: RDF [5]; RDF Schema; and the Web Ontology Language – OWL [19]. These standards build up a rich set of constructs for describing the semantics of online information sources. RDF is an XML-based standard from W3C for describing resources on the Web. RDF introduces a little semantics to XML data by allowing the representation of objects and their relations through properties. The RDF-Schema is a language for expressing semantic metadata. The Web Ontology language – OWL facilitates greater machine interpretability of Web content than RDF and RDF Schema by providing a much richer set of constructs for specifying classes and relations. OWL has evolved from existing ontology languages; specifically DAML + OIL [13]. DAML-S [1, 11, 29] is an RDF-based language that defines ontology for declaring and describing Web Services through a set of basic classes and properties. DAML-S aims to provide the necessary semantics to enable Semantic Web Services. Three main approaches have been driving the development of Semantic Web Service frameworks: IRSII [20], OWL-S [26] and WSMF [12]. IRS-II (Internet Reasoning Service) is a knowledge-based approach to SWS, which evolved from research on reusable knowledge components. OWL-S is an agent-oriented approach to SWS, providing ontology for describing WS capabilities. WSMF (Web Service Modeling Framework) is a business-oriented approach to SWS, focusing on a set of e-commerce requirements for Web Services including trust and security. WSMF consists of four main elements: (a) Ontology that provides the terminology used by other elements; (b) Capability repositories which define the problems that the set of Web Services solve; (c) Web Services descriptions that define various aspects of a Web Service; and (d) Mediators which bypass interoperability problems. The Semantic Web Services, Semantic Web, and Web Services, their standards, and internet-based languages, all provide for the dynamic or automatic composition of WSs. And as such, one interesting investigation could be to provide a testing methodology for dynamically composed WSs. Although this is not within the scope of our current work; however, we intend to investigate our framework‘s structure for the feasibility of such a methodology in our future work.

902

that a CWS can function correctly according to its semantic, activities and data dependencies.

2.2 Workflow Modeling In [17] an algorithm for constructing a process view from a given workflow was presented. In [32] an approach to workflow schema exchange in an XML dialect called XRL was introduced but did not include the support for workflow views. In [31] a Petri Nets-based message sequence charts for modeling interorganizational workflows and their communication structures was introduced. In [3] the derivation of private workflows from inter-organizational workflows was introduced using the concept of workflow projection inheritance. In [25] a tightly coupled private workflow and workflow view with state dependencies was proposed, as well as, cross-organizational workflow architecture for view-based cross-organizational workflow execution. Workflow views were also utilized as a beneficial approach to support the interactions of business processes in E-service environment [8, 9]. The notion of how exception handling could be facilitated in process based information integration and was introduced in [14]. However, there have been no comprehensive studies on how the use of workflow for testing purposes and relative test adequacy criteria.

3. Composed Web Services: Issues and Opportunities To illustrate the testing benefit when using SBWF, we use a motivating example to first illustrate the construction of CWSs; and then show the construction SBWF. In composed WSs, we consider two types: Simple CWS or (SCWS); Complex CWS or (CCWS). The SCWS and CCWS are not exclusive to construction domain of CWSs; however, they serve as a very common scenario of CWS usage. In this section, we illustrate, in the context of the motivating example, the construction of CCWSs and SCWSs, and their corresponding graphbased structures.

3.1 Motivating Example Consider an information system that allows a governmental head hunter to access an integrated view of records (e.g., ID, Driving Abstract, Immigration status, Security clearance, and Credit Bureau Report) from multiple governmental and non-governmental WSs to determine a potential employee’s credentials. The records and their associated organizations are as follows: x Personal Record: SIN; Name; Gender; DOB, Phone; and Address - are held by Statistics Canada (SC). x Driving Abstract Record: Driver’s License Number; Violation Code; Violation Description; Violation Date - are held by the Department of Motor Vehicle (DMV). x Credit Bureau Record: SIN; Risk Factor; and Risk Factor description - are held by a Credit Bureau (CB). x Background record: Security Clearance, Criminal History – are held by Canadian Security Intelligent Services (CISS). Work permit record: SIN; and Work Permit Status – are held by Immigration and Neutralization Canada (INC).

2.3 Web Services Testing Testing CWSs is a discipline much in need of further research due mainly to the contiguity and overlap with other emerging testing paradigms; especially component based testing. While most of the work focuses on preregistration testing [27, 28] and subsequently in [15], others focused on providing agent based testing techniques. For example, in [34] a service oriented framework to solve testing of web services was proposed. The approach enables collaborations between various parties involved in the development of WS applications via service request and service providing. It also enables special testing services to be provided as WS to perform testing tasks on behalf of their customers. In [28] agent techniques to software testing in the context of web-based applications were proposed. An ontology encoded in XML was used to represent testing concepts and relationships. Multiple test agents were implemented to perform various testing tasks based on a light-weight agent platform that supports agent communication. In [22] a generic layer-based approach for creating testing frameworks for repeatable white-box BPEL unit testing was presented. Aside from the work in [22], WSs testing in the cited works is used as a means to evaluate the input/output behavior of the WS that is under registration, in our work, we mainly apply testing to CWSs, shifting our interest from assessing whether a Web Service in a composed web service is bug-free, to focusing on verifying, based on a structural-based testing strategies,

Table 1 represents for each service provider (First column from left) the following information: < (Second column): provides for each service provider, the number of its SWSs >; < (Third column): provided the description of each SWS that is related to a service provider >; < (Fourth column): provides the description of the simple composed web services>; and < (Fifth column): provides the simple composed web service number>. To illustrate the construction of a SCWS, consider a governmental head hunter that might require for an applicant: (see Table 1) , and . The composition of these SWSs makes up a SCWS or SCWS1 (Table 1).

Table 2 - This table demonstrates the composition of Complex Composed Web Services SP

(SWSs)

SCW Ss

Service Requester Head Hunter

Complex Composed Web Services (CCWSs) by a Service requester

CCWSs #

SC

(SWS1)

SCW S1

SR2

SCWS1, and SCWS2

CCWS1

SR3

SCWS2, and SWS4

CCWS2

Table 1 – This table demonstrates the composition of Simple Composed Web Services out of Simple Web Services SP

SC

DMV

Simple Web Services (SWSs) number

Simple Web Services (SWSs) and their names

(SWS1)

Validate SIN

(SWS2)

Validate Address Info

(SWS3)

(SWS4) CB

(SWS5)

CISS

(SWS6)

INC

(SWS7)

(SWS8)

Simple Composed Web Services by Service Provider (SCWSs)

SCWSs #

(SWS2) DMV

Pay Violation Outstanding Get Driving Abstract Get Credit Report Get Security Clearance Get Citizenship Status Get Work Permit Status

- Get Driving Abstract (DMV SWS4) - Get Work Permit Status (INC – SWS8)

-Validate Address Info (SC - SWS2) - Get Credit Report (CB SWS5) Get Security Clearance (CISS – SWS6)

(SWS3) (SWS4)

SCWS1 CB CISS

(SWS5) (SWS6)

SCW S3

INC

(SWS7) (SWS8)

SCW S2

Definition 1 – (A simple CWS or SCWS – SP composition): A SPi  SPs combines a number of simple WSs – at the intra-or inter organizational structure of SPi – that are private (not visible to a SR) and or public (visible to a SR) and belonging to any SPj  (SPi could be equal to SPj), into a new CWS that is public to SR. For example, as depicted in Figure 1 and (Table 1), SCWS1 is composed out of the following public WSs = {WS8, WS4}. Private WSs are in general used to compose and expose new public SCWSs that may be accessed by SRs. Definition 2 – (A simple CWS or SCWS – SR composition): A SRi  SRs combines a number of simple public (visible) SWSs belonging to any SPi  SPs, into a new CWS that can be stored as a new SCWS. Definition 3 – (A Complex CWS or CCWS – SP Composition): A SPi  SPs combines, at the intra-or inter organizational structure of SPi, (private and or public to SPi and public to SPj  SPs) the following services: (a) one or more SCWSs and one or more SWSs to form a Complex CWS or CCWS; or (b) one or more SCWSs and one or more SWSs; and (c) a combination of (a) and (b). As an illustration, the case in (b), as depicted in Figure 1, represents building a CCWS2 from SCWS1 and SCWS2. Definition 4 – (A Complex CWS or CCWS – SR Composition): this is similar to Definition 3 except that the CCWs can be stored as a new CCWS for other SRs to be used for composition. As an illustration, the case in (b), as depicted in Figure 1, R2 builds CCWS2 from SCWS1 and SCWS1. These scenarios in Definitions 1, 2, 3, and 4, are not exclusive, but serve to illustrate common usage of CWSs. From a testing perspective, if SR needs to know the status of (SCWS and/or CCWS); especially after a breakdown during normal operation, it would then be particularly useful if the employed testing strategy can investigate the

SCWS2

To illustrate the construction of a CCWS, consider again a governmental head hunter that might require for an different applicant: (see table 2) ; ; ; ; and ; the composition of a CCWS can be done by joining SCWS1, and SCWS2 to produce CCWS1. The composition of WSs can be accomplished either by the Service Provider (SP) or Service Requester (SR). A CWS, for the purpose of this work, can be either SCWS or CCWS. A SCWS is composed out of simple WSs; whereas, a CCWS is composed out of either (a) two or more SWSs; (b) two or more Complex WSs; and (c) a combination of (a) and (b). More formally, given a set of Service Providers SPs = {SP1, SP2, …, SPn}, and Service Requesters SRs = {SR1, SR2, …, SRn}, such that each SPi  SPs is a service provider with a set of WSs, or SP(WSs) = {WS1, WS2, …, WSn}, (each WSi  SP(WSs) is WS  SPi) we say that, there are, from a testing perspective, the following CWSs’s definitions:

904

Service Providers SP1 = SC = {SWS1, SWS2}

SP2 = DMV = {SWS3, SWS4}

WS8

WS4

SP3 = CB = {SWS5}

WS5

Semantic flow 1

WS2

SCWS1

SP4 = CISS = {SWS6}

WS6

SP5 = INC = {SWS7, SWS8}

Semantic flow 1

SCWS2

SOAP

CCWS1 SOAP

SOAP

CCWS2

Service Requesters SR1

SR2

SR3

Figure 1 – Composed Web Services – simple and complex failure, and give useful feedback. For example, it would be reasonable to test every possible legal invocation sequence of a CCWS or a SCWS. To address some testing strategies for CWSs = {SCWS, CCWS}, we first provide the following layer descriptions of a workflow. The Semantic-flow represents how WSs are choreographed to perform a SR’s request. For example, the Semantic flow in Figure 2 represents a choreographed sequence of activities requested by SR1 (See Table 1), and responded to by SCWS1. For each semantic flow, a different activity sequence is activated in the control-flow layer. Therefore, it would be necessary top have a mapping between the two layers. In particular, some activities for particular requesters have to first obtain a read-access approval from each data custodian and data service provider. The Semantic-flow of SCWS1 thus abstracts the main concepts, and describes their dependence in a more precise way. The semantic configuration of a WS can be extracted from its OWL ontology based on a pre-agreed semantics of the information exchanged with partner organizations. The semantic-flow will be represented with a graph or Semantic Flow Graph (SFG) that will be formally described later. The Control-flow specifies the execution order of activities (based on a specific semantic flow) within a SCWS or CCWS. It therefore represents the process logic in a cross-organizational CWS. The semantic-flow will be represented with a Control-flow Graph (CFG) that will be formally described later. The data-flow defines the flow of specific data or dataset required by a CWS process. Since the control-flow are often inadequate, inflexible, or unclear for expressing the required data exchange sequence, the data-flow comes to fill the gap, and “connects” the referenced data to the activities in the CFG, and the WSs in the SFG.

The interactions and data dependencies among the SFG, CFG, and DFG are, from a testing perspective, of particular interest to us in this work. In general, a workflow process begins with a request and ends once all the control-flows and data-flows are completed successfully. As such, a successful testing session should consider (at least for our current work) all the “elements” that interact in the SFG, CFG, and DFG from start to end. The interaction among SFG, CFG, and DFG is triggered by SOAP messages. For example, in Figure 2, a SOAP service request is sent by SR1. For this particular request, there is a set of: controls or activity sequence ; and models or records {Driving Abstract Record or m1, and Work Permit Record or m2). For our testing purposes, the complexity of interactions among composed web services should merit the necessity to construct abstract structure to capture all the constituents of composed web services, their semantics, control, and data dependencies. This framework should then be supplemented with test adequacy criteria to test these dependencies. We next give a formal definition of our abstract Workflow-based framework.

4. A Structural-based Workflow Framework The construction of the structural-based workflow framework (SBWF), as depicted in Figure 2, (although showing only two SCWSs and two CCWSs) with trivial data (model) bears enough complexity to merit a justification for the construction of SBWF when testing CWSs. We next give the formal definition of the workflow graphs for a SCWS, and a CCWS.

905

Complex; or a combination of the former) can be then = (where the join operator is applicable to the construction of SBWF(CWSUT)). We say that SBWF(CWSUT) can then be used as a reference to the test adequacy criteria and their converges that are applied to a CWSUT. In a BPEL process the following interactions can take place: One-Way; Two-Way Synchronous, and Two-Way Asynchronous. These interactions must cover a number of defined interactions in a CWSUT, to successfully pass a test case. XML-based data and sequences of atomic interactions can be used with a CWSUT for the test data specifications. And as such we can say that, given a specific test data input (interactions/data), a testing criteria, and an expected output, testing can then be applied to SBWF(CWSUT).

Service Providers SP5 = INC = {SWS7, SWS8}

SP2 = DMV = {SWS3, SWS4}

WS8

WS4

Semantic flow

SCWS1 Control flow

a1

E

a3

SOAP

a2

m1

SR1

X

Data flow

5. Applicable Testing Criteria for Composed Web Services

m2

In this section we introduce formal notations that are related to test cases, test suites and applicable structural test adequacy criteria for composed web services in our framework. Definition 7 - (A test suite T for a CWSUT): We define a test case t for a CWSUT as an access interaction with a CWS’s service requester represented as the tuple (i, z, ov/i, n), where: i is the test case number; z is a set of input values for t; ov/i is t’s output valid/invalid results (passed to a human for verification, based on excepted results), and n is the set of exercised nodes (WSs) in SBWF(CWSUT) that is obtained as the result of executing t on CWSUT. We say that t is valid or t = (i, z, ov, n) if the actual output for an execution of CWSUT with t is the same as the expected output for t; otherwise, t is invalid or t = (i, z, oi,, n). Having defined what a test case is, a test suite T can then be defined as the tuple (I, Z, I, CN), where: I = {i1, i2,..., ik} is the set of test case numbers; Z = {z1, z2,..., zk} is the set of all inputs in T, OV/I (ov/i  OV/I) is CWSUT’s valid/invalid set of results of executing CWSUT with T; and N is the set of covered nodes (WSs in SBWFG(CWSUT) ) that is obtained as the result of executing CWSUT with T. Definition 8 - (all-States criterion for CWSUT): formally, given a SBWFG(CWSUT), a test t exercises a (state) node n or an activity in a (work-flow)  SBWF(CWSUT) if t causes the evaluation of CWSUT, and causes a transition to be fired which in turn causes the traversal of a path through SBWF(CWSUT) that includes n. A test suite T is state-adequate for CWSUT and for each dynamically executable activity (node n) in SBWF(CWSUT) if there is at least one t  T that exercises n. Definition 9 - (all-Transitions criterion for CWSUT): formally, given a SBWF(CWSUT), a test t exercises an

Service Requesters

Figure 2 - Composed Web Services. Definition 5 – (WFG(SCWS)) – Each SCWS is represented with a three interconnected workflow graphs or WFG(SCWS) = < SFG, CFG, DFG>. The SFG = graph (W, S)  WG(SCWS), where W is the set of SWSs, and S is the set of semantics, represented as edges between each w  W. The CFG  WG(SCWS) = graph (A, T) where A = {E, a1, a2, ..., an, X} is the set of Activities in a SCWS (E and X are the entry, and exit nodes of CFG, respectively), and T is the set of edges that represent the transitions between activities in A. The CFG contains a valid execution sequence of activities with regards to a CWS, starting at E, and ending with X; The DFG  WG(SCWS) = graph (M, D) where M = {m1, m2, ..., mn} is the set of models or data records, and D is the set of edges that represent the dependencies between a SWs, an activity ai and its model or data record. So formally speaking, WFG(SCWS) = V V >. Definition 6 – (WFG(CCWS)) – Each CCWS is represented with 2 or more interconnected WFG(SCWS) = < SFG, CFG, DFG>. The definition here is recursive, as one WS in the Semantic flow of (WFG(CCWS)) could represent also a WFG(SCWS). So formally speaking, WFG(CCWS) = V V > such that a w  W can also be WFG(SCWS) . According to Definitions 5 and 6, a CWS under test (CWSUT) (Simple; Simple and complex; Complex and

906

transition (edge) e = (ni, nj)  CWSG(CWSUT) if it causes the execution of CWSUT, and that execution traverses a path through CWSG(CWSUT) that includes e. A test suite T is edge-adequate for CWSUT if, for each dynamically executable edge e in CWSG(CWSUT), there is at least one t  in T that exercises e. Automatic test suites extraction and generation are not considered in this work. We also don’t discuss test case organization; however, we anticipate that, an approach like the one in [23] where t is created separately from the WS’s specification, albeit in the same file will be applicable. A test suite T can then be an XML-based document containing all necessary information to execute, based on one of the above testing criterion, T on CWSUT. Using our SBWF(CWSUT), and the family of applicable testing criteria, our testing strategy distinguishes itself from other approaches in that it maintains structural reference that can be consulted before and after a test case or test suite is applied, to evaluate the coverage obtained by a specific t or T on SBWF(CWSUT).

and Advanced Applications (EUROMICROSEAA’05). [3] Basten, T. and W.M.P. van der Aalst, “Inheritance of behavior. Journal of Logic and Algebraic Programming,” vol. 47, pp. 47–145, 2001. [4] Biron, P. V., Malhotra, A. (eds.): XML Schema Part 2: Datatypes, W3C Recommendation, 2 May 2001. http://www.w3.org/TR/xmlschema-2/. (2001) [5] Brickley D., Guha R.V. (eds.): RDF Vocabulary Description Language 1.0: RDF Schema, W3C Proposed Recommendation (work in progress). http://www.w3.org/TR/rdf-schema/. (2003) [6] Bechhofer, S., Dean, M., Van Harmelen, F., Hendler, J., Horrocks, I., McGuinness, D., Patel-Schneider, P., Schreiber, G., Stein, L.: OWL Web Ontology Language Reference, W3C Proposed Recommendation (work in progress). http://www.w3.org/TR/owl-ref/. (2003) [7] BPEL4WS Consortium. Business Process Execution Language for Web Services. http://www.ibm.com/developerworks/library/wsbpel. (2006) [8] Chiu, D.K.W., Karlapalem, K. Q. Li., Kafeza, E. “Workflow View Based E-Contracts in a CrossOrganizational E-Services Environment,” Distributed and Parallel Databases, vol. 12, pp. 193- 216, 2002. [9] Chiu, D.K.W., Cheung, S.C., Till, S., Karlapalem, K., Li, Q., and Kafeza, E. “Workflow View Driven Cross-Organizational Interoperability in a Web Service Environment,” Information Technology and Management, vol. 5, no. 3/4, pp. 221-250, 2004. [10] Christensen, E. Curbera, F., Meredith, G., Weerawarana, S. Web Services Description Language (WSDL), W3C Note 15. http://www.w3.org/TR/wsdl. (2001) [11] DAML-S Coalition: DAML-S 0.9 Draft Release. http://www.daml.org/services/damls/ 0.9/. (2003) [12] Fensel, D., Bussler, C. The Web Service Modeling Framework WSMF. Electronic Commerce: Research and Applications. Vol. 1. (2002). 113-137 [13] Joint US/EU ad hoc Committee. Reference Description of the DAML-OIL Ontology Markup Language. http://www.daml.org/2001/03/reference. (2001) [14] Hung, P.C.K., Chiu, D.K.W. “Developing Workflow-based Information Integration (WII) with Exception Support in a Web Services Environment,” Proc. IEEE HICSS37, CDROM, 10 pages, Jan 2004. [15] Heckel, R., Mariani, L. Automatic conformance testing of web services. In Proc. FASE, Edinburgh, Scotland, Apr., 2-10 2005. [16] Klyne, G., D., Carroll, J.J. (eds.): Resource Description Framework (RDF): Concepts and Abstract Syntax. W3C Proposed Recommendation

6. Conclusion In this paper we have propose an approach to build a practical structural framework to support testing for composed web services. We have showed the construction purpose and merits of our framework. The framework supports the representation of composed web services and their complex relationships; in particular those that are related to the semantic, control, and data that interact in a composed web service. Our framework captures these relationships at a granularity level that allows many structural based testing techniques to be applied. As for future work, we see a promising line of research approaches that we intend to investigate. For example, we intend to consider Exceptions, and Security flows in a composed web service under test. We also intend to extend our family of test adequacy criteria to include Exceptions handling, and security flows, Dataflows, and regression testing.

7. References [1] Ankolekar A., et al. DAML-S:Web Service Description for the Semantic Web. Proc. 1st Int’l Semantic Web Conf. (ISWC 2002), LNCS 2342, Springer-Verlag, 2002, pp. 348–363. [2] Antonia Bertolino and Andrea Polini. The Audition Framework for Testing Web Services Interoperability. Proceedings of the 2005 31st EUROMICRO Conference on Software Engineering

907

(work in progress). http://www.w3.org/TR/rdfconcepts/. (2003) [17] Liu, D.-R., Shen, M.. “Modeling Workflows with a Process-View Approach,” Proc. 7th International Conference on Database Systems for Advanced Applications (DASFAA 2001), pp. 260-267, April 2001. [18] Mandell, D., McIlraith, S. Grounding the Semantic Web: A Bottom-up Approach to Automating Web Service Discovery, Customization and Semantic Translation. In Workshop on E-Services and the Semantic Web (ESSW03) in conjunction with WWW03. [19] McGuinness, D.L., and Van Harmelen F. OWL Web Ontology Language Overview,” World Wide Web Consortium (W3C) recommendation, 10 Feb. 2004; www.w3c.org/TR/ owl-features. [20] Motta, E., Domingue, J., Cabral, L., Gaspari, M.: IRS-II: A Framework and Infrastructure for Semantic Web Services. In: Fensel, D., Sycara, K., Mylopoulos, J. (volume eds.): The Semantic Web ISWC 2003. Lecture Notes in Computer Science,Vol. 2870. Springer-Verlag, Heidelberg (2003) 306–318. [21] Offutt , J., Wuzhi, X Generating Test Cases for Web Services Using Data Perturbation. TAV-WEB Proceedings/ACM SIGSOFT SEN, September 2004 Volume 29 Number 5. [22] Philip Mayer, Daniel Lübke. Towards a BPEL unit testing framework. TAV-WEB’06, July 17, 2006, Portland, Maine, USA. [23] Qing Li, Patrick C.K. Hung, Dickson K.W. Chiu, S.C. Cheung. Flows and Views for Scalable Scientific Process Integration. INFOSCALE ' 06. Proceedings of the First International Conference on Scalable Information Systems. May 29-June 1 2006, Hong Kong [24] Tsai, W. T., Ray, P., Song, W., and Zhibiz, C. Coyote: An XML-Based Framework for Web Services Testing. Proceedings of the 7th IEEE International Symposium on High Assurance Systems Engineering (HASE’02). [25] Schulz, K.A., Orlowska, M.E. “Facilitating crossorganizational workflows with a workflow view approach,” Data & Knowledge Engineering, vol. 51, no. 1, pp. 109–147, 2004. [26] Shen, J., Yang, Y., Zhu, C., and Wan, C. From BPEL4WS to OWL-S: Integrating E-Business

908

Process Descriptions. Proceedings of the 2005 IEEE International Conference on Services Computing (SCC’05). [27] Tsai W., et al. Verification of web services using an enhanced UDDI server. In Proc. of WORDS 2003, pages 131–138, Jan., 15-17 2003. Guadalajara, Mexico. [28] Tsai, W. T. Et. al. Scenario-based web service testing with distributed agents. IEICE Transaction on Information and System, E86-D(10):2130–2144, 2003. [29] Wu, D., Parsia, B., et al. Automating DAML-S Web Services Composition Using SHOP2. In: Fensel, D., Sycara, K., Mylopoulos, J. (volume eds.): The Semantic Web ISWC 2003. Lecture Notes in Computer Science, Vol. 2870. Springer-Verlag, Heidelberg (2003) 195-210 [30] UDDI Consortium. UDDI Specification. http://www.uddi.org/specification.html (2000) [31] Van der Aalst W.M.P., “Interorganizational workflows: An approach based on message sequence charts and petri nets,” Systems Analysis - Modeling Simulation, vol. 34, no. 3, pp. 335–367, 1999. [32] W3C. SOAP 1.2, W3C Recommendation. http://www.w3.org/TR/soap12-part0/ (2003) [33] W.M.P. van der Aalst and A. Kumar, “XML based schema definition for support of inter-organizational workflow,” Proc. 21st International Conference on Application and Theory of Petri Nets (ICATPN 2000), 2000. [34] Xiaoying, B., Guilan, D., Dezheng X., and Wei-Tek T. A Multi-Agent Based Framework for Collaborative Testing on Web Services. Proceedings of the Fourth IEEE Workshop on Software Technologies for Future Embedded and Ubiquitous Systems and Second International Workshop on Collaborative Computing, Integration, and Assurance (SEUS-WCCIA’06). [35] Zhang, Lu., Hong, M. A Framework for Testing Web Services and Its Supporting Tool. Proceedings of the 2005 IEEE International Workshop on ServiceOriented System Engineering (SOSE’05). [36] Zhu Hong. A Framework for Service-Oriented Testing of Web Services. 30th Annual International Computer Software and Applications Conference (COMPSAC' 06) pp. 145-150.

Suggest Documents