An Experimentation Framework for Specification and Verification of Web Services

Designing and implementing Web Services constitutes a large and constantly growing part of the information technology market. Web Services have specific scenarios in which distributed processes and network resources are used. This aspect of services requires integration with the model checkers. This article presents the experimentation framework in which services can be specified and then formally analyzed for deadlock-freedom, achievement of process goals, and similar features. Rybu4WS language enriches the basic Rybu language with the ability to use variables in processes, service calls between servers, new structural instructions, and other constructions known to programmers while remaining in line with declarative, mathematical IMDS formalism. Additionally, the development environment allows simulation of a counterexample or a witness - obtained as a result of the model checking - in a similar way to traditional debuggers.


I. INTRODUCTION
RISING number of available Web Services are used for business processes in the modern world. Interactions with other Web Services are key features in creating more complex scenarios and satisfying business needs. An example of interaction between different services might be a travel agency that uses external services to book hotels, flights, and other facilities. Service for booking flights may use another service for processing a payment that communicates with a bank or credit card provider. Such interaction between many services is called Web Service composition [1]. From the computer science point of view, Web Service composition is a distributed system concerned with typical problems like deadlocks or lack of termination..

A
In Warsaw University of Technology, Institute of Computer Science, an experimentation framework for specification and verification of web services composition was developed. It is based on IMDS formalism (Integrated Model of Distributed Systems [2]) and DedAn [3] tool to model asynchronous distributed systems and verify them automatically. The user does not need to have deep knowledge about verification methods such as temporal logic and model checking.
A distributed system under verification in IMDS formalism is defined as a set of actions used to model the behavior. The declarative input of the DedAn environment was designed to structure a set of actions by combining them across servers or agents. While DedAn input language is sufficient to specify simple distributed systems, modeling more complex cases is challenging due to various technical difficulties described later in this paper.
To overcome the problem of modeling complex distributed systems, a higher-level language Rybu was initially developed [4], which simplifies the modeling of the system by some imperative-style elements and data aggregation. To improve the modeling of Web Service composition, Ry-bu4WS language was created, which is the original contribution of this paper. Moreover, Rybu4WS Debugger tool was developed to visualize counterexamples or witnesses caught from DedAn directly on the original Rybu4WS code. The latter feature is unique among model checking tools: they verify the systems but do not allow to interpret the checking results on the source code of the tested system. The projection of the verification result onto the source form of the specification is one of the most significant achievements of the authors. This paper is organized as follows: Section 2 covers related work of web service composition. Architecture of the Experimentation Framework is in section 3. Section 4 gives a brief description of IMDS formalism and DedAn tool. Description of Rybu4WS and its syntax can be found in section 5. General conversion rules of Rybu4WS code to IMDS model are described in section 6. Section 7 contains a description of the Rybu4WS Debugger tool. Conclusions and possible future development of our experimentation framework are covered in section 8.

II.RELATED WORK
Labeled Transition Systems (LTS) are alternative approaches for modeling Web Service compositions [5] where transitions between states can represent Web Service interactions. In the mentioned paper, model-checking and temporal logic properties were used to verify the Web Service composition modeled using this approach.
Existing formalisms like CSP [6] or CCS [7] are well designed to model concurrent systems, but they are hardly suitable for distributed systems. They do not possess asynchronous features needed for modeling true distributed systems. Instead, they rely on synchronous communication in the system, which requires that communicating processes reach given states simultaneously before passing a message. Such a scenario is impossible in Web Services or any other distributed system because components are typically placed on separate machines in different locations. They cannot learn about the other party9s state in other ways than by message exchange. However, there were attempts of formal software verification based on Service Component Architecture (SCA) [8] converted into CSP specification [9].
Bandera [10] tool allows the creation of a finite-state transition model directly from Java source code that can be verified in the external model checker. The main goal of this project was to provide automated model extraction from software systems that allows easy verification without manual software analysis and model creation. While automated creation of a model from the source code could be very convenient, generated abstraction might affect the model precision. As an alternative to verification, automated WS testing is proposed. Combinatorial method is described in [11] and metamorphic in [12]. Fault injection testing is presented in [13]. Simulation is covered in [14].
There are also languages specifically designed for writing distributed programs, like SR language (Synchronized Resources) [15] that provide various mechanisms used for concurrent process interaction. However, it lacks the ability of formal verification and is not suitable for model checking.
Widely used in industry WSDL [16] format describes Web Service interfaces for other services or applications. Since WSDL is designed to specify the pure interface of Web Services, it is not possible to define the internal behavior of Web Service, which is necessary for verification against deadlocks or checking termination.
A significant number of studies were conducted about Web Service composition, for example hybrid approach [14]. Report [15] presents different automatic composition approaches. TripICS [16] is an example of a real-life application that uses automatic WS composition for planning trips and travels around the world. It is based on the PlanICS framework to solve automatic composition problems, which uses a combination of SMT-solver and genetic algorithms [16]. Automated WS composition for Financial Decision Support is presented in [17]. Semantic modeling is covered in [21] [22].

III. ARCHITECTURE OF THE EXPERIMENTATION FRAMEWORK FOR WEB SERVICE COMPOSITION
To provide efficient experimentation with Web Service Composition, a modular but highly integrated system was created. Rybu4WS program is converted to IMDS form and checked by DedAn verifier, then the witness/counterexample is caught by the Rybu4WS Debugger which can simulate the verification output directly on the source Rybu4WS code.
When DedAn is run with user interface, additional analysis facilities become available, like export to Uppaal for checking huge systems, graphical simulation over system components [18], counterexample animation, and detailed analysis of individual components9 behavior.

IV. IMDS AND DEDAN
IMDS [2] formalism is the key element of the experimentation system. Therefore, it will be discussed first. It is a model of a distributed system using that is constructed over a set of actions. The actions are executed in the environment of servers offering services and traveling agents representing distributed computations. The agents use messages for their traveling between servers where partial computations are performed as the execution of actions. A set of messages in given sequential distributed computation forms an agent. The current configuration of a system is defined as a set of states of all servers and a set of current messages of all agents (one message per agent).
Action is a relation between the input pair (message, state) and output pair (new message, new state). The server in a given state accepts the message, which invokes the action. Action execution changes the state of the server and issues a new message. There is a special case on agent termination, which changes only a state without sending a message. The system in IMDS starts from the initial configuration, which consists of initial states for each server and initial messages for each agent.
Formally, the IMDS action is a quadruple of input items and output items ((message, state)þ(next message, next state)) or a triple ((message, state)þ(next state)) (agent terminates).
The IMDS formalism can well represent Web Service composition due to the following essential features: " Locality -there is no global or non-local state in the system, all servers are independent. " Autonomy of decisions -server autonomously determines the order of message acceptance. " Asynchrony of actions 3 always a message waits for an appropriate state or a state waits for matching message. " Asynchrony of communication -messages are sent through a unidirectional asynchronous channel. In most cases, the states of servers and the messages of agents can be treated as atomic, and actions are defined as a relation in (MôS)ô(MôS) which defines input message, input state, output message, and output state of an action. Agent-terminating actions are defined in (MôS)ô(S). The action extracts the input pair (message, state) from the input configuration and inserts the pair (new message, new state) into the output configuration. The execution of actions is assumed to be in interleaving semantics [2].
The IMDS models can be verified using the DedAn environment, which allows to find deadlocks or check possible termination in the modeled system. The input of DedAn was designed to structure a set of actions by combining them across servers or agents. It allows defining server and agent types used to instantiate variables of those types along with linking them using formal and actual parameters.

V. RYBU FOR WEB SERVICES (RYBU4WS)
It should be emphasized that the set of actions of Rybu/ Rubu4WS specification is exactly the same as the set of actions in IMDS specification after conversion. The main role of higher level language is to ease the programming. The instructions in Rybu/Rybu4WS group sets of actions into more readable high level actions, and chain the actions as in imperative language programming.
A Rybu [4] system consists of two kinds of servers: reactive servers and threads (processing servers from which the agents originate). The agent starts its run in a thread and invokes services offered by the servers by means of messages. Invoked service executes an action on the server, changing its state. A server replies from the executed action by sending a message back to the thread, prolonging its execution. The Rybu4WS was developed for modeling Web Service compositions, overcoming the limitations imposed by Rybu. It features more advanced functionality, such as: " server-server communication that allows agents to travel between different servers and execute complex scenarios, " state variables in grouped processes, which enables the communication between different processes without sending actual IMDS messages, " termination at any point of execution, " complex code sequences in reactive server actions instead of trivial state mutation and return value. Like Rybu, the Rybu4WS system consists of reactive servers and processes (in Rybu: thread). The reactive server is a resource that holds a particular state and offers services. Each service can be guarded by a condition over variables and contains a code sequence for further actions. Process consists of a code sequence that the agent executes to invoke services on reactive servers and does not hold any state.
Rybu4WS introduces a third, more advanced feature called group, which is used to group one or more processes. It gives the possibility to declare shared variables, allowing the creation of more sophisticated scenarios where processes use the same variables within a server to cooperate.
The following listing presents example Web Service composition in Rybu4WS. It consists of services necessary to build a simple book shop service 3 warehouse, payment, bank. Processes are used to represent the user9s behavior.

A. Reactive servers
The reactive server in Rybu4WS consists of variables, actions, and dependencies.
Variables form the internal state of the server, which can be used in conditions for action and can be mutated by the actions code.
An action defines the behavior of a service. It includes an optional predicate, a condition over state variables used to determine whether an agent can execute the given action in the current server state or not, and a code sequence for execution. The code sequence might contain service calls to other servers, variable mutations, return statements, process termination, or conditional statements. Each service has a unique name used by other servers or processes for calling the service. In case a server state satisfies the predicate of more than one action in a given service, the action to execute is chosen non-deterministically. The code sequence is a sequence of statements executed when an action is invoked.
The collection of other servers needed by the given server is called dependencies. Only servers defined in the dependency list can be called from the server.
In order to use reactive servers, an actual server instance must be created. Initial state and required dependencies must be defined for each reactive server instance. This allows creation of many servers with the same behavior but with different initial states or dependencies.

B. Processes
A process is a code sequence with an accompanying agent. It is used as an entry point for agent execution. Each process is converted into one IMDS server and a single IMDS agent. Ungrouped processes (group will be explained later) can only call instantiated reactive servers in the system and cannot define any variables.

C.Groups
A group is a collection of processes and variables. The group9s primary goal is to enable processes to use shared variables for sophisticated business scenarios where processes can communicate without sending actual IMDS messages. Agents are instantiated like in ungrouped processes, one agent per one process, meaning that many agents can work simultaneously on the same variables.

VI. CONVERSION TO IMDS
Rybu4WS language is used only for modeling distributed systems and cannot be directly verified against deadlocks or terminations. For the purpose of verification in the DedAn environment, Rybu4WS code must be converted into IMDS equivalent using a set of unambiguous translation rules. More detailed description of Rybu4WS language and architecture of the environment is available in [19].
It is important to note, that during conversion, the original code locations of each statement are preserved in IMDS states and messages. In a later stage, they are used to visually present deadlock or termination/non-termination sce-narios directly on the Rybu4WS code after verification in DedAn.
Each Rybu4WS reactive server instance is converted to a state machine. Every state machine represents a single IMDS server.
Server variables are converted to IMDS states exactly like in Rybu -they are defined by a Cartesian product of sets of all possible values of the variables in the server.
The process is converted into a state machine and corresponding agent instance. In comparison to Rybu4WS reactive servers, it does not provide any services that could be externally invoked. The process consists of a single code sequence block that is converted into a state machine and provides a special service used by agent as an entry point.
Group is converted into a single, encompassing state machine by merging state machines created for each process. Additionally, the group can contain variables that are converted as in the reactive servers. Many agents can run concurrently in the same group and share variable values without sending any IMDS message. Each action in the encompassing state machine also includes an agent for which this transition is valid, which means that the agent can travel only within his corresponding code sequence.

VII. RYBU4WS DEBUGGER
The Rybu4WS Debugger [20] is a desktop application that allows Rybu4WS code to be loaded and converted it into a corresponding IMDS representation for the purpose of verification in the DedAn environment. DedAn is invoked automatically (or manually if advanced analysis options are needed) and finds deadlocks/checks termination automatically. It is worth emphasizing that partial deadlocks are identified as well. During verification, a counterexample/witness is elaborated, and visualized in a user-friendly way for the manual analysis. This reverse mapping of the sequence of action onto the source code is achieved because actions in Rybu4WS program are expressed in a more abstract and easily readable form than in IMDS specification. However, the sets of actions in Rybu4WS and IMDS are exactly the same, and the semantics of both specifications is equal.

VIII.CONCLUSIONS
The growing number of designed Web Services requires more and more assistance in the programmer9s activities, including verification of whether the designed services behave safely (free from deadlocks), whether they finish in inevitable success (process termination), or whether there is even a possibility of success. Tools based on temporal logic are used to verify such behavior.
The formalism used to describe services should be wellsuited to distributed systems: support asynchrony, locality of actions, and autonomy of nodes. Ideally, the specification language can be explicitly used for formal verification. Such a modeling method is IMDS, for which the DedAn verification environment has been built. However, the DedAn input language does not fully meet the requirements of program-mers; therefore the Rybu language was created and its successor 3 Rybu4WS. Conveniently for the programmer, it combines the basic IMDS paradigm, adding the possibility of coupling actions in reactive servers. It was achieved using a syntax close to the programmers9 habits, using typical control statements such as conditional branching, loops, and response handlers. Shared variables in process groups allow to easily communicate by mutation of variable values.
The severe limitation of Rybu 3 allowing the server to be called only from a process 3 was solved: now a call chain can be created. Additionally, it is possible to terminate the process without returning it to the home server Communication between servers, declaring shared variables for processes, and termination at any point of execution gives the ability to model Web Service compositions The Rybu4WS Debugger tool provides a user-friendly interface that allows analyzing counterexamples similarly to debuggers in usual programming environments. It is a backward engineering principle, seldom observed in typical verifiers: they produce counterexamples or witnesses that are not easy to analyze in the context of the source code.
Rybu4WS can be used to model a wider variety of concurrent distributed systems than just Web Service themes. The development needs of such systems would require additional programming elements, which could eventually lead to the creation of a Domain Specific Language (DSL) family that might be the subject of further research. It is currently impossible to create a circular dependency between reactive servers, meaning that callbacks or recursive calls are not supported. Also, it is not possible for a single agent to =split= and perform multicast action, i.e., calling multiple services in a parallel manner. That would allow the creation of agents traveling in the distributed system and not returning to the place they originate from.