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

2. Slide - 2 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

3. Slide - 3 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 (component behaviour) and respective mismatches? 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

4. Slide - 4 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

5. Slide - 5 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 … 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 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!)

6. Slide - 6 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

7. Slide - 7 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 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 Description in full (recursive) Pi-CalculusNonrecursive description as projection over time

8. Slide - 8 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 Adaptor specifications Spec Semantics: „Whenever Output then Input“ Parameter have global scope within the mapping Generation Possible Adaptor satisfying mapping M1

9. Slide - 9 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

10. Slide - 10 Adaptor specifications (III) … Important cases of adaption Nondeterministic action correspondence [4] Name passing [5] Examples … Adaptor specifications The generation process takes care of dealing with nondeterminism adequately!

11. Slide - 11 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

12. Slide - 12 (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 last-added-action Select an action a which is capable of triggering one of those deadlocks (if any) If there is such an a and not (P|A|Q may also succeed after executing last-added-action ) Expand A (after last-added-action )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 StageA / last 00 / tau 1 (Case 1; a) a?().0 / a!() 2 (Case 1; b) a?().b?().0 / b!() 3 (Case 2) a?().b?().0 / a!() 4 (Case 1, c) a?().(b?().0 + c?().0) / c!() TerminationA = a?().(b?().0 + c?().0)

13. Slide - 13 (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

14. Slide - 14 (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: Adaptor derivation A = request?(url).0 A = request?(url).query!(url).0 … … Options: Request!(url) or Query?(q) Options: Reply?(url) or Query?(q)

15. Slide - 15 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

16. Slide - 16 FTP transmission (II) … File transmission phase The server opens a seperate thread (deamon) for the transmission Example

17. Slide - 17 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