WSMO Presentation „A formal Approach to Component Adaption“

–

Summary on a paper by A. Bracciali, A. Brogi and C. Canal

… to appear in

The Journal of Systems and Software, 2004

Uwe Keller (DERI), May 19th 2004

Starting point …

Component adaption is one of the crucial problems in Component-based Software Engineering Realistic assumption for a component marketplace Off-the-shelf components can not be combined without

additional effort What is needed?

Possibility of easy adaption of available components to make them interoperable

One approach …

Automation of (parts of) the component adaption process

Motivation

Slide - 2

Current component platforms …

Available component platforms address interoperability typically via IDLs (Interface Description Language) CORBA, COM, JavaBeans, .NET

But this is only a static view on a component interface Only highlight signature mismatches!

What about the dynamic view ( and respective mismatches?

component behaviour

) Does the inclusion of some existing component in my system cause deadlocks?

How do we make the communication patterns of two components interoperable?

For such tasks a formal description of component behaviour is needed!

Motivation

Slide - 3

Contribution described in the paper …

Focus on adapting mismatching behaviours that components may exhibit Provide formal methodology for behavioural adaption with the following main aspects … (1) Compent interface descriptions are extended with behavioural descriptions (IDL + subset of π–Calculus) (2) Adaptor specification by means of a set of correspondences between actions and parameters of two interacting components (3) Automatic derivation of a concrete adaptor from its partial specification and the component interface descriptions Benefit: No detailed implementation of adaptor needed!

Contribution of the paper

Slide - 4

Describing component interfaces …

Terminology … Component interface = set of roles Role = Abstract description of a specific facet of the behaviour that the component plays in an interaction Description of roles is divided into … Set of messages sent and received by the role (Methods, Exceptions) Essential aspects of the FINITE interactive behaviour that the component shows to ist environment in this specific context (Can be repeated!) In contrast to common IDLs: Offered & required actions are indicated Messages may have (typed) parameters Interaction patterns are described in a subset of polyadic π-Calculus Tupels can be communicated, dynamic communication topology

Component interfaces

Slide - 5

Describing interfaces (II) …

Language for specification of interaction patterns

Semantics … Actions a

Input resp. Output actions: x?(d) resp. x!(d) (using link x and parameters d) Non-observable actions denoted by „tau“

Processes (resp. expressions) E

0: Inaction (Noop) a.E: Process that is engaged in action a and then behaves as process E (x)E: Restriction, creation of a new link name x in expression E [x=y]E: conditional behaviour, like E if x=y otherwise like 0 E+E‘: non-deterministic choice, proceed either as E or as E‘ E || E‘: parallel execution No recursion within interaction patterns, since they are intended to specify finite fragements of the interaction

Component interfaces

Slide - 6

Describing interfaces (III) …

Recursive definitions vs. finite interaction patterns

Example …

A reader component R that sequentially reads a file and which can decide at any point in time to break the transmission

Description in full (recursive) Pi-Calculus Nonrecursive description as projection over time

Why capture interaction patterns only finite aspects?

Less complex descriptions lead to more comprehensible specifications Verification becomes more tractable Obviously: Both descriptions are not equivalent!

Compatibility of a set of interaction patterns does not garantuee correctness of the composed system, but helps in eliminating errors!

Component interfaces

Slide - 7

Adaptor specifications (I) …

Approach taken here: Providing a methodology for specifying the required adaption in an abstract way Simple, high-level language for describing the intended mapping among the functionalities provided by the components

Rules relate actions and data of interacting components

Used later on to automatically construct an adaptor that actually mediates the interaction of the components Components talk with each other only indirectly via the adaptor

Semantics: „Whenever Output then Input“ Parameter have global scope within the mapping Spec Generation Possible Adaptor satisfying mapping M1 Adaptor specifications

Slide - 8

Adaptor specifications (II) …

Important cases of adaption One-to-one action correspondence (see previous example) Multiple action correspondence (relating groups of actions) [2] Actions without a correspondent [3] Examples …

Adaptor specifications

Slide - 9

Adaptor specifications (III) …

Important cases of adaption Nondeterministic action correspondence [4] Name passing [5] Examples …

The generation process takes care of dealing with nondeterminism adequately!

Adaptor specifications

Slide - 10

Adaptor derivation …

Task: Given … a mapping (specification) M and Interaction patterns of components P and Q … generate a concrete adapter (if any exists) Intuitively, an adapter A is a component in the middle (process) such that The parallel composition „P | A | Q“ will not deadlock and A will satisfy all the action correspondences and data dependencies specified in M The full details of the derivation algorithm are not given in the paper, but both

issues are only sketched

!

Finite interaction patterns revisited … Exhaustive search with backtracking is garantueed to terminate!

Adaptor derivation

Slide - 11

(1) Deadlock elimination …

Try to build a completion process A incrementally by progressively eliminating all deadlocks that may occur in the evolution of P | A | Q Basic algorithm … A := 0; last-added-action := tau; While P|A|Q is not deadlock-free Case (1): P|A|Q may deadlock after executing those deadlocks (if any) after executing last-added-action Expand A (after ) last-added-action last-added-action Select an action a which is capable of triggering one of If there is such an a and not (P|A|Q may also succeed )with a; last-added action := a else backtrack to the state preceding the inserting of last-added-action in A Case (2): P|A|Q may deadlock, but no deadlock occurs after executing action last in A last-added-action:= the action preceding the current last added-action

Example:

P = a!().(tau.b!().0 + tau.c!().0) Q = 0 P*= a!().b!().0 + a!().0)

Adaptor derivation 0 Stage

0 / tau

A / last 1 (Case 1; a) 2 (Case 1; b) 3 (Case 2) 4 (Case 1, c)

a?().0 / a!() a?().b?().0 / b!() a?().b?().0 / a!() a?().(b?().0 + c?().0) / c!()

Termination

A = a?().(b?().0 + c?().0) Slide - 12

(2) Mapping satisfaction …

What is needed is not only a simple completion but one which satisfies the constraints specified by the mapping M This amounts to suitably constrain the way in which triggering actions are chosen in (1)

Technically …

Exploit the properties defined by the mapping (= set of constraints one the possible actions that an adaptor may perform at each moment) Describe each property as a Pi-Calculus-Process (where actions are described from the point of view of the adaptor itself) Example:

Adaptor derivation

Slide - 13

(2) Mapping satisfaction (II) …

Combination with the completion algorithm (1) When trying to solve an existing deadlock in P|A|Q, select a triggering action which

respects all the given properties

Rewrite the processes representing the properties in order to keep track of the history of actions/events Example:

A = request?(url).0

Options: Request!(url) or Query?(q) A = request?(url).query!(url).0

Options: Reply?(url) or Query?(q) … … Adaptor derivation

Slide - 14

Example: FTP transmission …

Scenario

A file is sent from a server to a client, where both parties employ different protocols Modular specification by using 2 roles per party (Session managent + file transfer)

Session management roles Example

Slide - 15

FTP transmission (II) …

File transmission phase The server opens a seperate thread (deamon) for the transmission

Example

Slide - 16

Relevance for WSMO …

Problem applies to WSMO as well Adapter maps directly to a mediator in WSMO The approach can simplify the creation of adapters Specification of mapping is easier (faster) than building the concrete connector Outcome here is an „executable description“ of the concrete adaptor Including data transformations in the specification should be easy

Open questions

Is abstract view on interaction (finite patterns) a severe restriction resp. problematic?

What extensions are needed with respect to WSMO-Full?

What about interactions between groups of services?

Finale

Slide - 17