How to relate Web Service Interfaces to other things?

1. How to relate Web Service Interfaces to other things? Philippe Giabbanelli CMPT 894 – Spring 2008

2. We will try to relate Web Service Interfaces to the hierarchy defined by Process Rewrite Systems. We will explain general principles for interfaces about software components, and how to model message passing. This will help us understanding the characteristics of Web Service Interfaces. Where are algebras over VPL in the hierarchy? Where are subclasses of VPL in the hierarchy? Principles of software contracts Modeling communicating entities 1

3. An algebra on VPL Subclass of VPL Software Contracts Entities • Last time, we presented Visibly Pushdown Languages. ∙ Subset of Context Free Languages such that checking a context-free property is decidable (but EXPTIME-complete). ∙ Good closure properties like regular languages. ∙ A symbol belongs to the calls (push on the stack), the returns (pop from the stack) or other (do not use the stack). • A long time ago, we presented a hierarchy defined by grammars of Process Rewrite Systems. 2

4. An algebra on VPL Subclass of VPL Software Contracts Entities • Basic Process Algebra (BPA) is based on context-free languages. As there is no closure under intersection, it cannot have parallel composition. P ::= a | X | p1 + p2 | p1 . p2 • It is undecidable to check if two context-free grammar generates the same language, so it’s undecidable to check trace equivalence for BPA. • It is also undecidable to check if a language is a subset of another one. …but that’s decidable for Visibly Pushdown Languages ! An algebra defined on VPL 3

5. An algebra on VPL Subclass of VPL Software Contracts Entities • An algebra called Communicating Visibly pushdown Processes (CVP) has been defined. It generalises CSP. Alternative S or R (┌┐depends on the environment) Parallel composition Sequential composition CVP An algebra defined on VPL 4

6. An algebra on VPL Subclass of VPL Software Contracts Entities Formal definition of equivalence • A labelled transition system (LTS) has: ∙ A set S of states ∙ A set A of actions ∙ A set of transitions → : S x A x S (given a state and an action, we go to a new state) • The set of actions that can take place on a state s is denoted I(s). • An equivalence is a relation R : S x S. We have many possible types: ∙ simulation iff for each transition s →a s’ in one, there is a transition t →a t’ in the other (and we can repeat the process with s’ and t’) -1 ∙ bisimulation if R = R. 5

7. An algebra on VPL Subclass of VPL Software Contracts Entities Formal definition of equivalence There is a whole hierarchy of equivalences (by Van Glabbeek). t and s supports exactly the same set of actions 6

8. An algebra on VPL Subclass of VPL Software Contracts Entities Complexity of Equivalences • Given an automaton and two of its initial states, can we decide if those states are equal given an equivalence? If so, what is the complexity? It is decidable and EXPTIME for Visibly Pushdown Automata. • A one-counter automaton is a finite-state automaton with a counter that can be incremented, decremented or compared to 0. It can be seen as a Pushdown Automata with only one symbol for the stack (+ the bottom). • A visibly one-counter automaton (v1CA) is defined like for visibly pushdown-automaton: an action a is either a call, a return or just local. ∙ If it is a call, then |α| = 2 stack size + 1 stack size - 1 ∙ If it is a return, then |α| = 0 same stack ∙ If it is local, then |α| = 1 7

9. An algebra on VPL Subclass of VPL Software Contracts Entities Complexity of Equivalences • Given an automaton and two of its initial states, can we decide if those states are equal given an equivalence? If so, what is the complexity? It is decidable and EXPTIME for Visibly Pushdown Automata. It is decidable and PSPACE-complete for visibly 1CA. It is decidable and P-complete for visibly BPA. (basic process algebra is a pushdown automata with 1 control state) CVP vBPA v1CA 8

10. An algebra on VPLSubclass of VPL Software Contracts Entities Defining Software Contracts • Software are made out of components. Using them raises two questions: ∙ How can you trust a component? ∙ What if you don’t use a component in the right way? • We need a specification to know what the component does, but we do not care how it does it. • This specification certifies what the component does: it is a contract. A contract can be more or less accurate: guarantee things at different levels. Let explore those contracts! 9

11. An algebra on VPLSubclass of VPL Software Contracts Entities Defining Software Contracts Level 1 Contract ∙ operations (or functions) ∙ input/output parameters ∙ possible exceptions It’s like an interface in Java, and it can be checked at compile time. 10

12. An algebra on VPLSubclass of VPL Software Contracts Entities Defining Software Contracts Level 2 Contract We guess what is a deposit. but what if it is negative? And what if we want to withdraw over our limit? We need to specify the behaviour. 11

13. An algebra on VPLSubclass of VPL Software Contracts Entities Defining Software Contracts Level 3 Contract Within a component, some of the services might have interactions (think of parallelism). A synchronization contract specifies the behaviour as synchronizations between method calls. 12

14. An algebra on VPLSubclass of VPL Software Contracts Entities Defining Software Contracts Level 4 Contract The quality of service that is specified in the contract could be: ∙ precision ∙ average response time ∙ result throughput for simultaneous queries (see The design of the TAO Real-Time Object Request Broker) 13

15. An algebra on VPLSubclass of VPL Software Contracts Entities How we sign Contracts in Software’s world • To use a component, we have to establish a contract. • A component can have different class of contracts, more or less ‘weak’. • The person using the component will choose one contract, specify parameters such as delays, and submit the contract for approval by the component. • The component modifies the term of the contract to make it duable. If the user is not satisfied with the contract, he can try contracts with weaker quality of service. Here is the negociation! (see Rusken scheme) 14

16. An algebra on VPLSubclass of VPL Software Contracts Entities What if a contract is violated? • For the bank, the contract specifies that we cannot withdraw more money than we have. What if we try? ∙ We ignore the contract and proceed. « You know that what you are doing is bad… » ∙ We reject: raise an exception and propagate. « We tell you that it’s bad and we refuse it! » ∙ We wait until the contract becomes valid again. The customer wants to take more money than he have. We will wait until he has enough money, i.e. a deposit. This can work in parallel world. ∙ We negociate the terms of the contract again. 15

17. An algebra on VPLSubclass of VPL Software Contracts Entities • In basic process algebras such as the one we saw two weeks ago (CCS), processes are interconnected by a static topology. What does that mean? • A follow-up to CCS allowing a dynamic interconnection topology is the π-calculus. It generalises conventional process algebras. Once a link is established between two processes, it doesn’t change. • Another model is the Actor Theory. Basically, an actor: All the links are known at the beginning. ∙ Encapsulates datas and procedures. It’s hidden inside. That’s not very realistic. Thus, we need a model where dynamic interconnection topology is possible. ∙ Actors are units of concurrence: they execute asynchronously. ∙ An actor has a unique name but his behaviour might change with the time (just like a human: fixed name but not behaviour). ∙ Communications is asynchronous by sending messages. 16

18. An algebra on VPLSubclass of VPL Software Contracts Entities • Just to make it clear, two differences between actors and π-calculus: • Just to make it clear, actors vs nomadic π-calculus: ∙ A name identifies an agent vs a communication channels. ∙ Buffered asynchronous communications vs synchronous. • π-calculus has been extended by types to overcome certain limitations, and it is possible for actors to simulate synchronous communications (handshake…) or for π-calculus to ‘somehow’ simulate asynchronous. • Extensions and simulations are one more layer that we have to think of: in other words, it makes it more complicate than an abstraction which already has those things in it. • There is also something in between: the Nomadic π-calculus model. ∙ A process identified by a name communicates asynchronously. ∙ All processes are associated with a host site, and can migrate between sites during the execution. 17

19. An algebra on VPLSubclass of VPL Software Contracts Entities • Just to make it clear, actors vs nomadic π-calculus: ∙ Both have names and asynchronous communications. ∙ In the nomadic π-calculus, communication primitives might require to know the location of the target. It is not the case for actors which are not associated with hosts. • Actors have been extended by adding location informations to the names, so that names could be unique over the World Wide Web. Thus, the difference becomes quite thin… • There are some implicit differences between synchronous/asynchronous ∙ What we have in mind is the idea ‘asynchronous, we drop our message and we go back to our work’ vs ‘synchronous is realiable’. ∙ There is more than that… ∙ In asynchronous you do not know the state of the other entity! 18

20. An algebra on VPLSubclass of VPL Software Contracts Entities • We send a message to an entity. As we do not know its state, maybe that the entity is not able to process the message at this time (think of a server with a file being already accessed by another client in WRITE). ∙ In synchronous communication, different messages are received on different ports and you can disable a port if you are too busy, which will block the communication. ∙ The actor can buffer the message that cannot be processed, i.e. store it into a mailbox. In Rosette, each state of an actor tells us which methods can be executed. We look in the Mailbox for the first message asking to do something duable (calling a method of enabled set). ∙ A similar idea is the local synchronization constraint: we will deliver the message when some constraint is satisfied. 19

21. An algebra on VPLSubclass of VPL Software Contracts Entities • In the Theory of Actors, we often use the following two tools: ∙ Computation tree (representing transitions between configurations) ∙ Interaction Path (sequence of computations showing only the interactions, i.e. messages, and hidding all internal actions) Two configurations are equivalent if they have the same set of actors to interact with and their interaction paths are the same. Want to know more on this topic? Here are some references: Actors: a model for reasoning about open distributed systems (Gul Agha, Prasannaa Thati & Reza Ziaei, in Formal methods for distributed processing: a survey of object-oriented approaches 2001) A calculus of Mobile Processes Part I & II (Robin Milner, Joachim Parrow, David Walker, 1989 revised 1990) 20

22. Articles used for this presentation (topics 1 to 3) Undecidable Equivalences for Basic Process Algebra (Jan Groote & Hans Hüttel, Report CS-R9137 at CWI, August 1991 ) CVP: A visibly pushdown process algebra (Md Tawhid Bin Waez & Stefan Bruda, Technical Report at Bishop’s University, 2008) Visibly Pushdown Automata: From Language Equivalence to Simulation and Bisimulation (Jiri Srba, Springer 2006.) Making Components Contract Aware (Antoine Beugnard, Jean-Marc Jézéquel, Noël Plouzeau, Damien Watkins, Computer 1999) I D O N O T T H A N K Y O U