how to relate web service interfaces to other things?

How to relate Web Service Interfaces to other things?

Philippe Giabbanelli CMPT 894 – Spring 2008

1

Where are algebras over VPL in the hierarchy?

Where are subclasses of VPL in the hierarchy?

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.

Modeling communicating entities

Principles of software contracts

An algebra on VPL Subclass of VPL Software Contracts Entities

2

• 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.


3

• 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


4

• An algebra called Communicating Visibly pushdown Processes (CVP) has been defined. It generalises CSP.

An algebra defined on VPL

Alternative S or R (┌┐depends on the environment)

Parallel composition Sequential composition

CVP


5

• A labelled transition system (LTS) has:

Formal definition of equivalence

∙ 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’)

∙ bisimulation if R = R.-1


6

Formal definition of equivalenceThere is a whole hierarchy of

equivalences (by Van Glabbeek).

t and s supports exactly the same set of actions


7

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∙ If it is a return, then |α| = 0∙ If it is local, then |α| = 1

stack size + 1stack size - 1same stack


8

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


9

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!


10

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.


11


Level 2 Contract

but what if it is negative?

And what if we want to withdraw over our limit?

We need to specify the behaviour.

We guess what is a deposit.


12


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.


13


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)


14

How we sign Contracts in Software’s world

• The component modifies the term of the contract to make it duable.

• 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.

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)


15

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.


16

• 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?

Once a link is established between two processes, it doesn’t change.

All the links are known at the beginning.

That’s not very realistic. Thus, we need a model where dynamic

interconnection topology is possible.

• A follow-up to CCS allowing a dynamic interconnection topology is the π-calculus. It generalises conventional process algebras.

• Another model is the Actor Theory. Basically, an actor:

∙ Encapsulates datas and procedures. It’s hidden inside.

∙ 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.


17

• Just to make it clear, two differences between actors and π-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.

• Just to make it clear, actors vs nomadic π-calculus:


18

∙ 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.

• Just to make it clear, actors vs nomadic π-calculus:

• 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!


19

• 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.


20

• 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)

T H A N K Y O U

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 )

Visibly Pushdown Automata: From Language Equivalence to Simulation and Bisimulation (Jiri Srba, Springer 2006.)

CVP: A visibly pushdown process algebra (Md Tawhid Bin Waez & Stefan Bruda, Technical Report at Bishop’s University, 2008)

I D O N O T

Making Components Contract Aware (Antoine Beugnard, Jean-Marc Jézéquel, Noël Plouzeau, Damien Watkins, Computer 1999)

how to relate web service interfaces to other things?

Documents

subclasses of vpl

state s

set s of states

vplan algebra

vplalternative s

pushdown languages

set of actionsan algebra

software components