Interface Formalism for Web Services

Interface Formalism for Web Services

Philippe Giabbanelli CMPT 894 – Spring 2008

1

Why ?

Signature Interface

Consistency Interface

Protocol Interface

ApplicationsApplications

Applications

Applications

Applications

Applications

Applications

Applications

Applications

Why a formalism? Signature Consistency Protocol

2

• For Web Services, we have neither the source code nor the binaries.

• You want to know something? Read the documentation!

∙ Each developper has his own way to write the documentation. More or less wordy, more or less accurate…

∙ The more services you use and the more it might get confused.

→ We need a standard and accurate description: a formalism.


3

• What do we want to describe? What are we trying to formalize?

Signature Name of the method? Return type? Methods of which it relies?

Consistency: some methods behaviours can be exclusive.

Protocol: how do the methods communicate?


4

• Signature Interface: name ProcPay. Can return OK and FAIL.

• Consistency Interface: In a conversation, can ProcPay return FAIL and ShipItem return OK? NO!

• Protocol Interface: ProcPay must be invoked with value OK before ShipItem can be invoked with OK.


5

• Signature interfaces. What do we have?

∙ A set M of methods (think of names).

∙ We can call a method given some parameters, and it will give us a result. This is an instance. I is the set of instances.

∙ An action is an instance of a method. A is a subset of M x I.

∙ Methods might be in several namespaces (think of C++). A namespace N is a subset of A.

• A signature interface is S = (N, J, K, D). N is the namespace, J is a subset of actions performed on methods belonging to this namespace (supported), K is a subset of actions performed on methods outside from the namespace (thus external actions that are required), D is the set of actions that can be called by a supported action.

• A signature S supports a method M if there is an action on this method.


6

• Now that we formaly defined a signature, let’s play a bit with it!

• When are two signature interfaces compatible ?

∙ We do not want one signature to have interactions with the other one. They must be clearly separated. Straightforward way: different namespaces!

∙ If two signature interfaces do not have interactions, then we can safely combine them by taking the union.

• A signature interface is a refinement of another if has the same environment, and it does at least the same things (and maybe more).

• A signature interface S1 can be substituted by S2 if they are compatible and S2 is a refinement of S1.


7

• We will extend the signature interface by the consistency interface.

• A consistency interface is C = (N, J, K, F). N namespace, J supported actions, K external required actions and… F that assigns to each supported action a boolean formula of actions.

∙ F = { <SellItem, SOLD> → aaaaaaaaaaaaaa<ChkAvail, OK> ^ <ProcPay, OK> ^ <ShipItem, OK>, aaaaaai<SellItem, FAIL> → <ChkAvail, FAIL> v (<ChkAvail, OK> ^ aaaaaaai(<ProcPay, FAIL> v (<ProcPay, OK> ^ <ShipItem, FAIL>)))i}

• Two consistency interfaces are compatible if their underlying signature interfaces are compatible. We combine them by taking the union.

• In the consistency world, we are dealing with interactions between the methods during the execution. A conversation is a set of actions that happen together in one execution.


8

• I am sorry to flood you with those definitions. That’s what a formalism is! So, what do we have to define now for consistency interfaces?

• Refinement. We want to know if we can replace A by B: thus B is a more concrete piece. It does maybe more things, but it cannot do less.• F is a set of restriction. To do an action, we need this and this… Thus a more concrete system can have less restrictions, which leads to less conversations: we might not need so many things to happen.• A consistency interface A is a refinement of B if the signature interface of A is a refinement of the one from B, and it doesn’t add conversations for actions of B.


9

• Given an action a, there might be some other actions that are forbidden. In other words, the forbidden actions should not take place altogether in a conversation.

∙ F = { <SellItem, SOLD> → aaaaaaaaaaaaaa<ChkAvail, OK> ^ <ProcPay, OK> ^ <ShipItem, OK>, aaaaaai<SellItem, FAIL> → <ChkAvail, FAIL> v (<ChkAvail, OK> ^ aaaaaaai(<ProcPay, FAIL> v (<ProcPay, OK> ^ <ShipItem, FAIL>)))i}

• We can check the actions launched by a if we look at the set F:

• A specification of a consistency interface takes an action a and gives a set S of such forbidden actions. A specification is satisfied if a does not lead to S in F.

• If the composition of two consistency interfaces satisfies a specification, then the consistency interfaces separately satisfy the specification too. However the converse is not true: taking the union can create things!


10

• Now, let’s try to model the global communications of the system.

SellItemChkAvail

OK OKProcPay

OKShipItem

FAIL ChkAvail

FAIL

OK ProcPayOK

FAIL

ShipItem

FAIL

ChkAvail

OK

FAIL

ChkStore

ChkStore

OK

FAIL

OK

• A protocole interface is P = (N, J, K, H, R). N namespace, J supported actions, K required external actions, H automaton (states Q; transition δ), R function that maps supported actions to a state of the automaton.


11

• We have distributed components. We must allow concurrency: the orther in which tasks execute might not be determined. One may execute before, after, or together (parallelism)…

• For each transition in the automaton, we have a term from the following

• Where to put the concurrency in the formalism? At the automaton!

Next!Execute action a

Next!

Execute A in parallel When all done, Next!

Execute A in parallel When one done, Next!


12

• Two protocol interfaces are compatible if their underlying signature interfaces are compatible, and if they do not have interactions (i.e. do not share states in the automaton). The composition is realized by doing the union.

• The way a protocol works can be understood as a game, where the system plays against the environment by making moves that change the state of both the system and the environment. The scheduler goes between the player to tell them when they can move.

∙ ε-move: comes back to the scheduler (i.e. give up / skip).

∙ call-move: executes one action, come sback to the scheduler.

∙ fork-move: executes a set of actions, and comes back to the scheduler when they are all done.

∙ fork/choice-move: executes a set of actions, and comes back to the scheduler when the first one is done.


13

• A protocol interface A is a refinement of B if the underlying signature interface of A is a refinement of B, and A has at least the same behaviour in the game.

• A specification now has temporal restrictions: there are things that must not happen before others are not done.

• A specification for an action a says that a set of actions B must not be executed before a set of actions C.

• What we mean with the specifications is not right now. Instead, we mean that at the end of the execution of the whole system, B must not have been executed before C. Thus, we are more considering the conversations that a leads to.

• If a protocol interface satisfies a specification, then any refinement of this protocol interface satisfies the specification too.

14

There are not only applications to the Web, but also to programming languages. For example, actor languages: everything is an actor, and they communicate by exchanging messages.

Object-oriented languages can be considered as actor languages too, in this aspect… They have a local environment (a closure) and they accept messages.

This presentation is from the article An interface formalism for Web Services by Dirk Beyer, Arindam Chakrabarti and Thomas

Henzinger.

T H A N K Y O U

Interface Formalism for Web Services

Documents

Transcript of Interface Formalism for Web Services