Web Applications Development by Formal Refinement ... - SERSC

International Journal of Software Engineering and Its Applications Vol. 9, No. 12 (2015), pp. 73-98 http://dx.doi.org/10.14257/ijseia.2015.9.12.07

Web Applications Development by Formal Refinement Approach Meftah Mohammed Charaf Eddine and Kazar Okba University of Mohamed Khider, BISKRA, Algeria, University of Mohamed Khider, BISKRA, Algeria [email protected], [email protected] Abstract This paper proposes a formal approach for development of safe web applications. This approach involves the generation of a web application on both sides (users’ side (Ajax) and the web service side (Composition)) from formal specifications. First, we describe the application using symbolic notations then an automatic process is applied in order to translate them into formal specifications B. Using the B refinement process, a set of refinement rules, operating on data and operations. These phases of refinement are intended to make the final specifications close to the implementation language chosen so that the last coding phase becomes intuitive and natural. In general, the process of refinement is a manual task, relatively expensive; with character generic of these refinement rules, an assisted refinement tool can be achieved, enabling reduction the cost of the refining process. Finally, in the case study, we have developed a complete application (Travel Agency) in order to show the benefits of our approach. Keywords: Web application, Formal approach, B Model, refinement, SOA, AJAX

1. Introduction The web technologies can be divided into two sides: first, user side where the users can generate and distribute content, often with freedom to share and re-use. Web 2 sites often feature a rich, user-friendly interface based on Ajax. Two, that the web services (Server side); the Web 2 can be conceptualized as a global SOA; as in Figure 1:

Figure 1. The Web 2 Architecture

ISSN: 1738-9984 IJSEIA Copyright ⓒ 2015 SERSC

International Journal of Software Engineering and Its Applications Vol. 9, No. 12 (2015)

1.1. AJAX (Asynchronous JavaScript and XML) Ajax is a scripting technique to develop interactive and fast web applications with enhanced functionality. The most commendable feature of AJAX is its ability of partial exchange of data with the server, enabling the changes to appear on the browser without reloading the complete page. Ajax is not a single technology, but a group of technologies. HTML and CSS can be used in combination to mark up and style information. The DOM is accessed with JavaScript to dynamically display, and allow the user to interact with, the information presented. JavaScript and the XMLHttpRequest object provide a method for exchanging data asynchronously between browser and server to avoid full page reloads. Ajax approach combines indeed two web publication standards appeared in the late 1990s but now universally recognized: JavaScript and XML (eXtensible Markup Language). XML is not required for data interchange and therefore XSLT is not required for the manipulation of data. JavaScript Object Notation (JSON) is often used as an alternative format for data interchange [1]. 1.2. Convergence of Web 2.0 and SOA The W3C defines a Web Service as "a software system designed to support interoperable machine-to-machine interaction over a network". There are at least two significant connection points which relate Web 2.0 and SOA. One is that Web 2.0 can be conceptualized as a global SOA. Two, that many traditional brickand-mortar business that are currently using SOA as their architectural model will want to connect their Web/Web 2.0 faces up to their SOA. This makes Web 2.0 not just being the Global SOA but makes meeting smaller SOAs everywhere. Another concept closely related to SOA is the notion of Software as a Service (or SaaS). Simply put, SaaS can be defined as "software deployed as a hosted service and accessed over the Internet" .Note that the respected industry analysis firm, Gartner, recently said that by 2008 that 80% of all software development will be based on SOA. This means Web 2.0 and SOA will meet each other both coming and going, and begin to become each other as well [21]. The composition of web services (WSC for short) is one of the key features advanced by the technology. It consists of combining existing services to provide a richer new composite service to meet some user requirements.

Web Service 02

Web Servic e 01 Web Service 04

New Web Service 05

Composition

Web Service 03

Figure 2. The Web Services Composition The composition techniques can be classified into two categories, namely: static service composition and dynamic service composition. Static composition allows the requestor to create an abstract model that should be respected during the execution of the

74

Copyright ⓒ 2015 SERSC


composed Web service. While the dynamic composition enables selecting the atomic Web services automatically and combines them to create an unlimited number of new Web ser-vices. There is yet a third classification, which is based on how the composition is specified, either by orchestration or by choreography [2]. Orchestration: consists of combining available services by adding a central coordinator (the orchestrator) that is responsible for invoking and combining the single sub-activities, as illustrated in Figure 3.

Figure 3. Web Services Orchestration and Choreography Choreography: however, defines complex tasks via the definition of the conversation that should be undertaken by each participant, as in Figure 3. Such composition requires methods and languages for basic Web services integration, such as: XML, XLANG, BPML, WSFL, WSCL, WSCI, BPEL4WS and WS-CDL. Among the composition languages, we chose BPEL (or BPEL4WS) because it is an XML-based language and describes the business process interactions based on web services, within and between enterprises. A BPEL process specifies the exact order in which participating Web services should be invoked. This can be done sequentially or in parallel. With BPEL, we can express conditional behavior; for example, a Web service invocation can depend on the value of a previous invocation. We can also construct loops, declare variables, copy and assign values, define fault handlers, and so on. By com-bining all these constructs, we can define complex business processes in an algorithmic manner [3].

2. Related Work Several studies and approaches have been proposed in this context, are devoted to the formalization of orchestrations of Web services and allow some verification of their behavior. In this section we briefly explore the advantages and limitations of current practice and research work. 2.1. The Transition Systems LTSA-WS This model [4-7] based to verifying compositions of web service implementations. This model supports verification of properties created from design specifications and implementation models to confirm expected results from the viewpoints of both the designer and implementer. Scenarios are modeled in UML, in the form of Message Sequence Charts (MSCs), and then compiled into the Finite State Process (FSP) process algebra to concisely model the required behavior. BPEL4WS implementations are mechanically translated to FSP to allow an equivalence trace verification process to be


75


performed. By providing early design verification and validation, the implementation, testing and deployment of web service compositions can be eased through the understanding of the behavior exhibited by the composition. The advantage of this works, is that uses standard (sequence diagrams, BPEL4WS) available that hide the complexity of FSP ; but UML is semi-formal and BPEL4WS with no formal semantics, it is impossible to prove that the generated FSP is exactly what is described. Then the comparisons and checks can only be partial. Moreover it provides a visual means (via the LTSA tool) compare the design model and the implementation model while checking the absence of violation of general properties; but in case of no consistency of traces, the implementation is completely resumed: the verification phase is then very / too late. 2.2. Process Algebras (ASDL) ADSL (Abstract Service Design Language) [8-10] is a language based on ITL (Interval Temporal Logic) a process algebra for reasoning about time constraints, indeed ASDL is wide spectrum language for: -

Behavioral specification of a service.

-

Specification of service composition.

-

Design of interaction protocols for service.

ASDL focuses on providing a minimalistic syntax with specification oriented semantics for describing services and their compositions ASDL provides a model for the verification of properties of services. ASDL provides capabilities of modeling oriented systems and specification of their desired properties, while remaining within a unified logical and semantic framework of ITL. ASDL has a clearly semantic it is based on a process algebra semantics. It allows the reasoning process; however ASDL has a complex syntax, far from the standards in the field of Web services. Otherwise ASDL has a high degree of abstraction allows him to describe an orchestration at different levels (services, orchestration, protocols), wherefore he requires another language (lowest level) to execute an orchestration described with ASDL, example BPEL4WS. 2.3. Temporal Theories In this approach, [11-12] propose to verify web services composition using an Event Calculus approach. He assumes web services that are coordinated by a composition process expressed in WSBPEL and he uses Event Calculus to specify the properties and requirements to be monitored. The Event Calculus [13] is a temporal formalism designed to model and reason about scenarios characterized by a set of events, whose occurrences have the elect of starting or terminating the validity of determined properties. This approach allows the verification of functional and non-functional properties. But the description of the properties requires some expertise, far from the standard in the field of Web services; and it allows the verification of a BPEL4WS orchestration to a static level (prior to execution) and throughout the execution of an orchestration. The translation phase between BPEL4WS and the formalization of this language remains as in other approaches, which leads to the same restrictions, the potential loss of semantic. On the other side (Ajax and Java) many studies have proposed formalization, but they generally treat a subset of language; for example [14] propose a bottom-up approach for the formal validation of HCI, uses B-event language. These approaches take into account the "semi-formal" notations for describing interaction scenarios supported by the HCI (Human Machine Interface).

76



3. The Proposed Approach An important concept in the design of the behavioral aspects of the Web 2 applications is the task. These tasks describe the various interactions betwe en web services (orchestration side and ergonomics side) to achieve a particular goal.

Figure 4. Task Model Used: CTT Notation and B Method 3.1. Models Used We considered the task model described by the CTT [15] notation in-form expressions of process algebra. We represent the decomposition into sub-tasks used by CTT using Event-B refinement. 3.1.1. CTT (Concur Task Trees) Model: We chose the syntax of CTT language for the following reasons: - CTT is a notation defined for specifying task models. - CTT is a task model based on decomposition by a top-down approach; - CTT Allows the task description by combining tasks using temporal

operators.

- CTT Model is hierarchical structure represented as a tree. - CTT can express precisely the different actions which are performed using expressions of process algebra. Grammar describing the syntax of CTT language: T::=

T >> T | T[]T | T II T | T |= | T | [T] | T [> T | T |>T | T [> T | TN | Tat


-- Enabling -- Choice -- Concurrent -- Order independency -- Optional process -- Disabling -- Interruption -- Disabling infinite process -- Finite process iteration -- Atomic process

77


3.1.2. B Model: The B model [16] based on predicate calculus and a simplified settheory, wants to offer a complete solution, enabling write a formal specification, and successive refinements produce a proven program conforms to this specification. B has been used in major safety-critical system applications, It has robust, commercially available tool support for specification, design, proof and code generation. Recently, another formal method called Event-B has been developed. Event-B is considered an evolution of B (also known as classical B). It is a simpler notation, which is easier to learn and use. We have to admit that the level of confidence in a software developed in the formalism of the method B is optimal, but not total, it depends on the confidence in the correctness and completion of the formal specification written in the tools implementing the method, and the compiler, operating system and hardware. The development process can be summarized by the following steps: 1. Capturing the functional requirements of the system in a form that can be mathematically analyzed. 2. Systematically producing a design of the system, so that it can be verified with respect to the specification. 3. Automatically generate programs using rules that assure that the software satisfies the specification. Abstract Machine A development of B starts with the definition of an abstract machine, which corresponds to the specification of the application that will be developed. An abstract machine is composed of constants (invariant) and variables, describing a global state, properties of these constants and variables (particularly invariant), and finally operations to read or modify the global state. We can also parameterize an abstract machine: MODEL nameM REFINES nameR SETS . . . PROPERTIES . . . VARIABLES . . . INVARIANT . . . ASSERTIONS . . . INITIALISATION . . . EVENTS . . .

END Events: The events are described using generalized substitutions (based on the weaker condition of Dijkstra) [S]P: weakest precondition such that P is executed after the execution of S. - Substitutions in B models. [SKIP]P [S1 II S2]P

78

 

P [S1]P ^ [S2]P



[ANY v WHERE E THEN S END]P [SELECT E THEN S END]P [BEGIN S END]P [x := E]P

   

¥ v.(E => [S]P) E => [S]P [S]P P(x/E)

3.2. Processes and Tools of Our Approach We provide all processes and tools that permit to build and analyze this formal approach (Figure 5): first, extracting a CTT-B model by capturing the behavioural aspect of the process of the social side and the behavioural aspect of the orchestration process; this approach has a formal syntax and a behavioural semantics ,then implementing the intermediate model; finally We present several mappings between these tools: a mapping that allows to translate JAVA and BEPL4SW into Event-B, in order to proceed to their formal verification and a mapping acting as a generator of JAVA and BEPL4SW code.

Figure 5. The Proposed Approach 3.2.1. Task Model for Specification: Web 2 applications can be specified by the composition of elementary tasks with the operator of choice on CTT. In this way, an orchestration can be completely specified by the data of all the possible tasks in the form of an expression CTT, Thus, a specification will be in the form:


79


T (E)= T(E)1[]T(E)2 : : : []T(E)n T (S)= T(S)1[]T(S)2 : : : []T(S)m

T(E) : Ergonomic task T(S) : Web service task Where T(E)i and T(S)j are the basic tasks. The development of Web 2 application will be in encoding expression of tasks by B refinements using patterns of refinement operators. The events occurring in the leaves of the tree of tasks constitute the basic messages used in the design of the Web 2 application. From the viewpoint of transition systems, a task CTT is a system transitions encoded in B event. This task can either represent the system in case of a specification by a task, or represent a task to validate. The Event-B models associated with these tasks and these models describe the transition systems which are linked by a relationship of simulation. Indeed, when the task is validated, then the transition system to content is in the other. 3.2.2. Task Model for Validation: Like the specification, we can use the coding task model CTT to perform the validation as follows: A Web 2 application is described by a set of events (messages) describing the different possible interactions between web services partners. They may have been produced by a refinement of a CTT task. The task is refined according to CTT decomposition reaching the basic (leaves of the tree) events (messages) describing the behavioural of application. In this case, this development should respect the system properties of the invariant and assertion. 3.2.3. Model for Verification: Regarding the verification, two approaches can be differentiated: - The first is translating the source code of application into a formal language in order to check as in the following figure:

Figure 6. The Verification Approach (Bottom Up). - The second is to express a behavioural aspect of t he process with a formal language, in order to check, and then translate it into source code, as in Figure7:

80



Figure 7. The Verification Approach (Top-Down) 3.2.4. Source Code Generation: A development of B is most often consisting of a set of abstract machines, which are refined until an implementation, translatable into a program in an imperative language such as Java or BPEL4SW. This level of abstraction is defined as a set of assignments. These assignments are scheduled by a set of control structures (BPEL4SW/JAVA): sequential composition, loops, if, then and else. An abstract machine must be refined; the refinement corresponds to a representation of the software derived from the specification but more deterministic, more concrete and verified (Figure 7); the refinement in its turn may be refined one or many times to obtain a deterministic version which is called Implementation. The refinement is defined for substitutions (for operations). If R2 is a refinement of R1, which is denoted: R2 ref R1, then any predicate directed by R2 is achieved by R1. 3.3. Development Practices for Validation 3.3.1. Capture the Behavioral Aspect of the Process (Orchestration (BPEL4SW), AJAX (JAVA)): Projecting the behavioural aspect of the system in B model. Representing the execution of methods (BPEL4SW, JAVA) as a set of sequential and/or parallel processes compounds assignments...

a)

For BPL4SW :

Processes in BPEL export and import information by using web service interfaces exclusively. BPEL describe Web-service interactions, this interaction is ensured through Partnerlink. They represent the static part of a BPEL process and are described in a WSDL document. The dynamic part of BPEL is described by two types of activities: -

Basic activities define basic operations of a business process as : Invoke, Receive, Reply...

Structural activities define the order in which the nested activities are executed, such as: Sequence and Flow (for sequential and parallel execution..) -

Scope activity allows decomposing the BPEL process into sub-processes.


81


Figure 8. The Processes in BPEL4SW

b)

For JAVA:

Java Swing program consists of: -

A set of widgets these widgets can be associated by event listeners.

-

Event listener implements methods.

Method of listener: the body of a listener method modifies rendering interface and performs calculations per call to another web service or functional core of the application. We can imagine matching between the concept of machine in B and class in Java: MACHINE: Name of the abstract machine (same name of the class) SETS: Declaration of abstract and enumerated sets VARIABLE: Declaration of variables (same attributes of a class) INVARIANT: Typing and variable property INITIALISATION: Setting up the initial value of variables (same constructor) OPERATIONS: Statement of Operations (same methods).

3.3.2. Implementation of the Intermediate Model: The intermediate model obtained by analysis of the source code represents the methods (BPEL4SW, JAVA) as a set of assignments. These assignments are scheduled by a set of: Control structures; Sequential composition; Loops; If then else... 3.3.3. Translation of Intermediate Model to Model CTT-B: The translation of intermediate model to B model requires translation rules (Table 01) (according the substitutions in B model: Section 3.1.2. page 10) to represent these control structures:

82



Table 1. Translation Rules into B Model Specifications type

Application side

Sequential composition: SOA T(S)1 ; T(S)2 ; . . . ; T(S)n

Sequential instruction:

Ergonomic

T(E)1 ; T(E)2 ; . . . ; T(E)n

Conditional compositios:

SOA

if (Me) then T(S)1 else T(S)2

Conditional instructions:

Ergonomic

if (Ee) then T(E)1 else T(E)2

Iterative loops composition:

SOA

While (Me) {T(S) 1}; T(S) 2

Iterative loops instructions:

Ergonomic

While (Ee) {T(E) 1}; T(E) 2

B model SELECT S1 ^ Me = n THEN Me := Me − 1 II T(S)1 END; SELECT S2^ Me = n − 1 THEN Me := Me– 1 II T(S)2 END; … SELECT Sn^ Me = 0 THEN T(S)n END; SELECT EC ^ Ee = n THEN Ee := Ee − 1 II T(E)1 END; SELECT EC^ Ee = n – 1 THEN Me := Ee– 1 II T(E)2 END; … SELECT EC^ Ee = 0 THEN T(E)n END; SELECT S1 ^ Me = 1 THEN S1 II Me := Me− 1 END; SELECT S2 ^ ¬(Me) = 0 THEN S2 II Me := Me− 1 END; SELECT EC ^ Ee = 1 THEN T(E)1 II Ee := Ee− 1 END; SELECT EC ^ ¬(Ee) = 0 THEN T(E)2 END; SELECT S ^ Me THEN S1 END; SELECT S ^ ¬ (Me) THEN S2 END; SELECT EC ^ Ee THEN T(E) 1 END; SELECT EC ^ ¬ (Ee) THEN T(E) 2 END;

T(S): Web service task Me: Web service message S: Web service T (E): Ergonomic task Ee: Ergonomic event EC: Ergonomic component (JAVA)

4. Case Study: Build the Complete Application (Travel Agency) In this section, we are going to illustrate the application of our approach through a case study. Suppose that a travel agency (business process) proposes to its clients organized trips adapted to their needs by composing appropriate existing Web services. The proposed tours contain the transport, the hosting, the car rent and pay expenses through the bank. When the client decides to reserve for a tour, the client gets access to the web site of the travel agency (business process), specifying his name, the destination, the departure date and the return date. Then the travel agency proposes tickets of plan and


83


train, the rental of cars and the hotel reservation, after reimbursements (client, agency and partners) through the bank. 4.1. Preparing the Environment Before starting building our example, we need the following software resources to be installed: Table 2. Software and Tools Software and tools

Java Development Kit (JDK) [17] NetBeans IDE [18] Glassfish Application server [19] B4free and Click’n’Prove [20]

Version Required

Version 5 Version 6.5 (it is bundled with NetBeans IDE) Vx.x

The GlassFish Application Server must be configured correctly and be running. As a BPEL project is not directly deployable, we must add a BPEL project as a JBI (It defines an environment for plug-in components that interact using a services model based directly on Web Services Description Language) module to a Composite Application project. Then we can deploy the Composite Application project. 4.1. BPEL4SW Process To develop a BPEL process, we go through the following steps: 4.2.1. Get Familiar with the Involved Web Services (Import external WSDL files) and Define Partner Link Types: The five e services providers ,Train, Airline, Hotel ,Car rent and Bank Web services have been exposed over the network and their WSDL file can be accessed by URLs as following : Table 3. The WSDL URLs for the Five Web Services Web Service

URL

Train Airline Hotel Car rent Bank

http://localhost:8080/TrainReservation/TrainReservationService?WSDL http://localhost:8080/AirlineReservation/AilrlineReservationService?WSDL http://localhost:8080/HotelReservation/HotelReservationService?WSDL http://localhost:8080/CarrentReservation/CarrentReservationService?WSDL http://localhost:8080/BankPayer/BankPayerService?WSDL

Netbeans tool enables also to import the WSDL files for any external web service provider. Thus, we import the five WSDL files for the five service providers with their xml Schema. WSDL of the process imports the WSDL of other web services providers and defines the partnerlink types for them. The five partner link types are as following:  ClientPartnerLink: used to describe the interaction between the client and the BPEL process itself. This interaction is synchronous. This partner link type is declared in the WSDL of the BPEL process.

84



 AirlinePartnerLink: used to describe the interaction between the Airline service provider and the BPEL process itself. This interaction is synchronous. This partner link type is defined in the BPEL process.  HotelPartnerLink: used to describe the interaction between the BPEL process and the Hotel Reservation Web service. This interaction is synchronous. This partner link type is defined in the BPEL process.  CarPartnerLink: describes the interaction between the BPEL process and the Car rent Web service. This interaction is synchronous. This partner link type is defined in the BPEL process.  BankPartnerLink: describes the interaction between the BPEL process and the Bank Web service. This interaction is synchronous. This partner link type is defined in the BPEL process. 4.2.2. Define the Process Logic (CTT Notations): The next figure presents the business process behavior, which gathers the various tasks to be achieved by the composition. Each reservation is related to a Web service. Services run in this order with respect to the following conditions: 1- If (price