Extending WISE with Contract Management

Transcription

1 Extending WISE with Contract Management Aaron Calafato Dept. of Computer Science University of Malta Abstract Nowadays transactions require an increasing amount of critical information, therefore the architecture is expected to be reliable. Trusting services involved in such sensitive transactions is an issue tackled in the semantic web with the creation of description languages including semantics and runtime veriefication by monitoring a system s behaviour. The problem in these areas is that the former does not directly lead towards monitoring systems whilst the latter may be difficult to create for a user. Here we present an approach to generate an easy to use and expressive web service workbench. This will generate and monitor web services with the use of a graphical representation tool. This work creates a Java skeleton for the web services, as well as the monitoring mechanism to handle the intermediate method calls. The monitoring mechanism is intended to be deployed on a third party service. Thus both the client and the server can declare and increase restrictions in the process flow. 1 Introduction Accessibility of remote services is a field that has been researched for quite some time. Technologies such as COM 1, CORBA 2 and Java RMI 3 have been created for this specific reason. A prevailing technology, which is widely in use nowadays is Web Services. The major advantage of using web services is that they may be invoked programmatically. Web services has been further more enhanced by ontologies (10) to be described better, like in OWL-S (13) and WSM* (12). BPEL (5) is an approach dedicated towards the modelling of web services compositions. These approaches focus in describing web services, whilst in this paper we focus on executing and monitor web services and interlinking communication. Monitoring web services method calls induces a more trustworthy environment. Runtime verification is an area where monitoring and planning of contracts are tackled. These contracts deal with the possible flow of events which may or may not occur in the system s communication. Whilst many separate studies are being carried out on semantic web services and runtime verification in a separate manner, our approach is to combine these two areas into a single framework. This is done to combine the benefits of semantic definitions and the increase in security which comes with runtime verification. Creation of web services will require little expert knowledge on the part of the user. For this reason a mechanism is required which may define as many constructs as possible. The tools provided should allow for the creation of a non trivial web service which is composed of several features. In conjunction with the web service creation, another aspect which this system aims to handle is the generation of contracts. Furthermore, contracts have to be editable and exposed to all users. Therefore the chosen mechanism has to enable sharing of contracts to all the participating parties. WISE is a user friendly tool which maps SAWSDL to OWL-S by using BPMN to model process flows. On the monitoring mechanism aspect, Larva is a runtime verification tool which is able to handle temporal logic. We here present a tool which is inspired by WISE (9), it takes a description created in BPMN, and generate (i) Java code for a web service and (ii) the monitoring mechanism script in Larva (3). Finally we present a prototype to dynamically invoke web services using a single invoking engine. 2 Background Our perspective to execute and monitor web services is to merge the two areas of semantic web and runtime verification. As the basic description language, WSDL (2) provides the least number of

2 constructs to consume services. The need to compose a flow of services is required. Thus, a number of description languages have emerged to deal with composition of services. These vary from defining I/Os, pre-conditions and post-conditions like WSM* to defining solely the expected flow of events such as BPEL. As a mature language, BPEL has evolved to express a wide range of constructs defining both the flow of events and events attached to tasks such as rollbacks. Also, having its graphical notation (BPMN), this language has proved to be very expressive and easy to understand. The problem with using only BPEL is that the existing technology only aids in executing an already existing web service. The lack of assurance is highly visible in this area, especially when both client and service should define the contract with properties of what should or should not happen. The lack of assurance is tackled by the use of runtime verification. Runtime verification is a methodology which deals with planning, verifying and monitoring contracts. The main mechanisms used in verification are static and dynamic modes. The former checks for possible traces of flow of events whilst the latter checks for the current trace at runtime. Also, for the dynamic verification mode, two ways to use this are via immediate verification or logging information to be monitored later on. In verifying the behaviour of a system, it is common to detect bugs by testing, a criticism of this methodology is that a well tested program only shows that no bugs have been encountered rather than the fact that no bugs exist. Two types of testing exist, these being white and black box testing. Within the web service environment, testing for communication may be seen as black box testing as the internal server s code is not known at the client s side like in web services. Also, automated tests like unit testing enhance the number of paths which are tested which however in most situations do not cover all possible ones. With runtime verification, monitoring a system is done by hooking extra code to the actual program, having methods pre-checked by runtime verification s checks. Similarly to Unit testing, runtime verification retrieves the required logic but instead of simulating the system with stand alone methods, the logic works in parallel to the running system. This paradigm has advantages which are required to handle most of the checking for the web services message passing; this is called dynamic runtime verification and will be used for its advantages over testing and static verification. As a runtime verification engine, Larva (3) has been set as our target engine. Larva is based on automata models, whilst being extended to the DATE model. DATEs extend automata with the use of variables, channels, clocks and numerous number of events type like pre and post events. In (1) section , the number of extensions are illustrated with a special emphasis on the benefits in using variables. For instance, figure 1 shows the automata representation of a property stating that the system should only have from 0 to 2 logged users. Without variables, the number of states would be proportional to the maximum number of users and two extra states for the error states, which does not scale up efficiently. Figure 1: Automata with variables taken from (3) 3 Execution and Monitoring of Web Services In order to deal with both ease of use and expressivity in constructs, the BPMN (8) graphical notation has been chosen to express the web service composition. Helping in executing and monitoring web services has led to create two mechanisms these being (i) generating a number of files with the described service Java code and (ii) generating a Larva script to monitor the service calls. As a general architecture regarding the Java code generation, our mechanism is designed to generate a modular web services separating the exposed method calls with the internal executing ones as shown in figure 2. As both client and server should have the possibility to generate their own mechanisms, the 2

3 Figure 2: Generated code: exposed methods (left) and internal method calls (right) BPMN mechanism has been mapped to satisfy this issue. With these mappings, the contract written in BPMN pools can be extended by any party whilst hosted on an intermediate party(the Broker) to monitor the messages passed as shown in figure BPMN to Java Our primary goal is to aid the user to create an executable from a BPMN diagram. We therefore have created a mapping mechanism which generates Java code including method stubs, conditions, threads and other elements to help in creating a structure for the implementation of a web service. An advantage of creating a separate monitoring mechanism is that the execution is only concerned with its prescribed execution. Generated Code Architecture The different Java code classes and methods have to be designed to maximize modularity, reduce redundancy and therefore reduce chance for inconsistencies. It also splits methods to be exposed to the web and those that should be handled internally. Elements that affect this architecture are as follows: Exposed services Internal methods composing the services Classes for polymorphism Figure 3: Runtime verification using an intermediate party Decoupling of Java and Larva Handling both Java and Larva script generation with a single graphical representation, various mechanisms to represent both have been evaluated. Two approaches which could have been used were: Use a single diagram with tasks representing Larva properties and sub tasks representing the internal mechanism Use multiple pools, some of which reflect the Larva and others the Java code. With the first option, to create a task or service, it has to be monitored. The second option is highly decoupled, by not linking Larva and Java tasks to each other, therefore can be used separately for both aims. Also, if a task is to be monitored by two rules, for the first option, the task has to be redesigned by the user, inducing the chance for inconsistencies. Due to these and other advantages, our mechanism treats the two mapping independently. Classes for concurrency using threads We propose a mechanism to create a main class of exposed services making use of another class, consisting of internal methods which in turn consists of the services. In addition to this, other classes are generated for the parallel composition. With this addition, expressivity is added to make use of threads whilst synchronising when all threads are terminated. For more expressivity, BPMN events have been added to represent message returns. For instance, if a method named getrole may return a ManagerRole or an EmployeeRole, where their attributes are different. Instead of creating a condition based on the attributes, we enable the chance to define conditions based on return types. To do so, a superclass is created and these two roles are listed as subclass of this new class, whilst the method is set to return the superclass type. This approach is able to overcome a consistency issue, where methods are only created once. If multiple services require the use of a common internal method, this is found in a common class, thus implemented once by the user. Mappings The mappings of BPMN elements to Java code are listed in Table 1. The first three mappings correspond to the basic elements whilst the others are the sequence and the various gateways. 3

4 BPMN Element Task Cancel Event Looping Task Sequence Data-based Explicit, cond. c1 (default) and c2 Data-based Implicit, cond. c1 (default) and c2 Event-based Explicit, events e1 and e2 Parallel, X and Y processes Java Code (i) Method creation (ii) method call System.out.exit(0); (i) Method creation (ii) While(false) loop Sequence of method calls if(c1 (!c1 &&!c2))... else if (c2)... if(c1 (!c1 &&!c2))... if (c2)... (i) Create classes (ii) Get result (E) (iii) if(e1.getclass() == E.getClass())... else if (e2.getclass()==e.getclass())... (i) Create classes (ii) Collect threads (iii) Loop to initiate threads (iv) Loop to synchronise threads Table 1: Mappings of BPMN to Java code 3.2 BPMN to Larva Parallel to the execution of a service, the monitoring of the service behaviour has to be automatically generated to avoid typing errors. In doing so, we have generated a mapping mechanism of BPMN elements subset to Larva. The databased inclusive gateways has not been mapped as this generates non determinism which is not handled in Larva. DATEs contain a number of state types which define the kind of state the current position is in. This is opposed to the actual position which will be needed to identify states upon which these rules will function. We are here interested mostly in three state types; starting, accepting and bad states drawn respectively as shown in figure 4. Figure 4: State Types initial, accepting and bad states Merging Error States Two options in error states were to either merge error states, which reduces the number of states whilst always showing the same error, or leaving all error states spread out. Our choice was to leave the separate error states so that if a violation is detected, the point of violation can be detected. As an example, having a property tackling posting a number of messages, possible bad states could be: User not yet logged in Number of posts exceeding a limit Positive vs. Negative directing automata For the user to define a number of rules (or properties) within the contract, a mechanism represented by BPMN is chosen. Four variations were considered to define basic elements, variations were: 1. If an event happens, a violation should occur 2. If an event does not happen, a violations should occur 3. Defining what can and cannot happen in the same rule (or property) 4. Having both options in 1 and 2 in different rules The difference in the first two options is that for a large scale system, the number of possible paths may be difficult to bind. Therefore we opted to define what causes violations, thus option 1. Options 3 and 4 both express more constructs. However option 3 could misguide the user due to its complexity by declaring what can and what cannot happen, whilst option 4 could have been the better option whilst not implemented due to time restriction. The generated DATE for a task or event is shown in figure 5. Merging Mechanism In merging the BPMN elements, two approaches were studied. These are using direct transitions or channel transitions. The former reduces the number of states whilst cannot cover for parallel composition whilst the latter handles all compositions whilst increases slightly the number of states. Our choice was to develop mappings using channel transitions to create a uniform mechanism. Figure 5: BPMN (left) to Larva (right) Events and Task mappings Mapping Elements In mapping and merging elements, the two step process includes (i) generating a number of separate DATEs and (ii) merging the DATEs with their respective starting and bad 4

5 states. Therefore the overall structure consists of a set of dates and a pointer towards the starting and bad states. Our approach maps a number of BPMN elements to DATEs which are later on merged into a number of linking DATEs. For instance, having a BPMN pool with two tasks, RejectLogin linking to PostMessage. Our proposed work first recognises the two tasks as leading towards violations, whilst later on merges the DATEs such that if a RejectLogin occurs, a PostMessage cannot occur. This type of merging mechanism is uniform throughout all merging mechanisms. To create a more expressing mechanism, the list of gateways which have been mapped are (i) Sequence, (ii) Data-based explicit, (iii) Event-based explicit and (iv) Parallel compositions. Also, besides the basic element/task, a looping event and a complement of an event have been mapped. For temporal logic, two constructs have been implemented, these are what cannot happen before and after a time period. For example defining If a login happens, another login cannot happen before 5 seconds or If a request happens, a reply cannot happen after 5 seconds The only BPMN gateway which was not mapped to Larva, is the Data-based Implicit gateway. This gateway induces non-determinism which is not supported by Larva. 3.3 Dynamic Invocation The third part of this work consists of invoking web services automatically, independent of the description language with which these are described. Due to the time restriction, based on the study carried out, only the design was created. It has been concluded that a two layer mechanism would have been created. The upper layer should handle constructs about (i)the basic constructs such as parameters, (ii) flow of processes defined by languages such as OWL-S and BPEL and (iii) choreography constructs such as pre and post conditions defined by languages like WSML. For the second layer, the collected processes should be executed individually by another mechanism. The mechanism should use a native method such as Apache Axis 4 or Axis2 5 which gives flexibility to invoke services which are not yet bound with the system OWL-S OWLS2MVC Mapping Our Mapping Composite process Servlet class Method in main class Atomic process Method Method in separate class Sequence of tasks Sequence of code Sequence of code If-then-else If-then-else Exclusive (if... else if..) or Inclusive (if... if...) Choice Switch N/A Repeat While While While Repeat Until Do-while N/A Input Arguments N/A Output Return N/A Parameter type Type of attribute In loops or event-based Table 2: Constructs expressed by OWLS2MVC 4 Evaluation and Related Work Java Mappings First hand constructs which have not been implemented in the system were the return types, parameters, and exception handling mechanisms. We focused our work to provide constructs representing the flow of events. We have created a mapping for every existing BPMN gateway. To our knowledge no other similar work has been conducted which maps such a number of constructs to Java. The most relevant work was identified as OWLS2MVC (4) which has a mixture of mechanisms involving processes, flows and data types. The expressivity of the OWLS2MVC s constructs is shown in table 2. On the other hand, various constructs which we defined were not mapped in OWLS2MVC. These being: Cancel event Use of polymorphic classes Parallel composition Comparing Properties Expressivity A comparison to the constructs found in (11) and (6) has been done. These two approaches tackle different construct types. In (6), constructs are built with respect to states in time. For example a construct Becomes(X ) is defined by: when X is true in the current state and false in the previous state. In (11), the mechanism is of the form Head Body, where if the Head happens, the Body is expected to happen. Therefore, both approaches define different constructs, which we try to express. We pointed out that both approaches defined their constructs in a bounded environment such as after(a,b) which means that if a happens, b should happen. This cannot be proved true or false at runtime. Thus a number of constructs could not 5

6 Construct in (11) Definition Mapping in BPMN absence(a) a must not execute A blocks(a,b) if a happens, b cannot happen A B notbetween(a,b,a) if a happens and then b happens, a A B A cannot happen again rightafter(a,b) if a happens, b has to immediately happen next A!B Table 3: Constructs in (11) expressed well by our mechanism have been mapped by our mechanism. Table 3 illustrates the constructs (11) which were expressed successfully. Case Study To demonstrate better the expressivity of our mechanism we have used the scenario found in (7). The scenario and rules were not intended for our use. The case study was implemented in the form of Head Body, where if the former event happens, the latter should occur. The proposed mechanism, is based on what should not happen. With some alterations, the monitoring mechanism has been generated equally expressive. Also, the Java code has been generated for the three entities, namely the customer, supplier and warehouse. We refer the reader to (1) chapter 11 for the full case study. Finally, the mechanism has been shown to users varying from no background to professional Java and Larva users. The feedback was that whilst the Java code is understandable for all users, the monitoring mechanism using negative approach may be misleading with the use of temporal logics. 5 Conclusions Our mechanism has resulted as an overall intuitive system which is capable to map constructs in BPMN to be mapped to Java code and Larva script. The expressivity has been evaluated to be sufficient to create a non trivial web service. Limitations were induced mainly by two factors; (i) BPMN elements restriction which are mostly focused towards flow of events and (ii) Time restrictions which stopped us from enriching the system with more constructs. The target of dynamic invocation of web services had to be reduced due to time restrictions. [2] Erik Christensen, Francisco Curbera, Greg Meredith, and Sanjiva Weerawarana. Web Services Description Language (WSDL) 1.1. IBM Research and Microsoft, 15 March [3] Cristian Colombo. Dynamic analysis overview and a proposed verification tool for temporal properties in security-critical software. Master s thesis, University of Malta, [4] Cássio Prazeres V. S. et al. Semantic web services: from owl-s via uml to mvc applications. In SAC 09: Proceedings of the 2009 ACM symposium on Applied Computing, pages , New York, NY, USA, ACM. [5] Charlton Barreto et al. Web Services Business Process Execution Language Version 2.0. Adobe Systems, Amberpoint, SOA Systems, Microsoft, IBM, Oracle, iway Software, Sun, SAP ansd TIBCO Software, 09 May [6] Luciano Baresi et al. Keep it small, keep it real: Efficient run-time verification of web service compositions. In FMOODS 09/FORTE 09: Proceedings of the Joint 11th IFIP WG 6.1 International Conference FMOODS 09, pages 26 40, Berlin, Heidelberg, Springer- Verlag. [7] Marco Alberti et al. Computation logic for run-time verification of web services choreographies: Exploiting the socs-si tool, September [8] Object Management Group Inc. Business Process Model and Notation (BPMN) 1.1. Object Management Group Inc., January [9] Keith Lia. Web service workbench - a service composition editing suite. In WICT Proceedings, University of Malta, November [10] Natalya F. Noy and Deborah L. McGuinness. Ontology Development 101: A Guide to Creating Your First Ontology. Stanford Knowledge Systems Laboratory Technical Report KSL and Stanford Medical Informatics Technical Report SMI , March [11] Dumitru Roman and Michael Kifer. Semantic web service choreography: Contracting and enactment. In ISWC 08: Proceedings of the 7th International Conference on The Semantic Web, pages , Berlin, Heidelberg, Springer-Verlag. [12] Nathalie Steinmetz, Ioan Toma, and the WSML working group members. D16.1v1.0 WSML Language Reference. The WSML working group members, 8 August [13] David Martin wt al. OWL-S: Semantic Markup for Web Services. SRI International, BBN Technologies, USC Information Sciences Institute, Nokia, University of Toronto, Yale,Carnegie Mellon, Maryland and Southampton, and International Institute of Computer Science, 22 November References [1] Aaron Calafato. Extending wise with contract management. In B.Sc.IT(Hons) Thesis, University of Malta, May