DISTRIBUTED SYSTEMS RESEARCH GROUP CHARLES UNIVERSITY PRAGUE Faculty of Mathematics and Physics Behavior Composition in Component Systems Jiří Adámek

Jiří Adámek Dagstuhl, November 2006 Outline The context  SOFA, Fractal, and Behavior protocols  Projects and tools Behavior composition  What is it?  Why is it important? My contribution  Detection of composition errors  Support for reentrant component specification

Jiří Adámek Dagstuhl, November 2006 The Context Behavior protocols  A component behavior specification language Similar to process algebra Behavior – the ordering of the events occurring on the interfaces  method calls, requests, responses  Applied to SOFA component model Fractal component model The common features of SOFA and Fractal  Hierarchical components Primitive and composite components  Provided and required interfaces

Jiří Adámek Dagstuhl, November 2006 The Context: Example Example: the Token component  A part of a complex application providing wireless internet access on airports  This component manages the session of a single user

Jiří Adámek Dagstuhl, November 2006 The Context: Example ?ICustomCallback.InvalidatingToken_1 { !IAccount.AdjustAccountPrepaidTime_1 }*}* | ?ICustomCallback.InvalidatingToken_2 { !IAccount.AdjustAccountPrepaidTime_2 }*}*

Jiří Adámek Dagstuhl, November 2006 ?Invalidating Token_1^ !Invalidating Token_1$ !AdjustAccount PrepaidTime_1^ ?AdjustAccount PrepaidTime_1$ ?Invalidating Token_2^ !AdjustAccount PrepaidTime_2^ ?AdjustAccount PrepaidTime_2$ !Invalidating Token_2$

Jiří Adámek Dagstuhl, November 2006 The Context: Projects & Tools The SOFA project  Hosted by ObjectWeb  Tool BPChecker The CRE project  Supported by France Telecom  Tools BPChecker ported to Fractal Run-time checker Code checker  A complex case-study was developed The Osiris project  Hosted by ObjectWeb  A new project – no implementation yet  Idea: Using behavior protocols to specify web-services

Jiří Adámek Dagstuhl, November 2006 ? What is behavior composition?

Jiří Adámek Dagstuhl, November 2006 Why is behavior composition important? Case 1  Behavior model is not manually specified for a composite component  We want to verify the behavior of composite components Case 2  Behavior model is manually specified for a composite component  We want to compare the manually written behavior model of a composite component with the automatically constructed one In order check that the design is consistent  Vertical compliance checking

Jiří Adámek Dagstuhl, November 2006 My contribution Analysis of behavior composition in current component models Identification of drawbacks Proposal of improvements  Detection of composition errors  Support for reentrant component behavior specification  The improvements were designed for SOFA and behavior protocols

Jiří Adámek Dagstuhl, November 2006 Detection of composition errors Composition errors  Erroneous communication among the components  Caused by composition of the components with incompatible behavior Detection of composition errors  During behavior composition the representation of both correct behavior and composition errors is constructed  Otherwise the information about the composition errors would be lost

Jiří Adámek Dagstuhl, November 2006 Detection of composition errors Example of a composition error  ValidityChecker tries to call two methods on ICustomCallback in parallel  CustomToken is not able to accept parallel calls

Jiří Adámek Dagstuhl, November 2006 Detection of composition errors Four types of composition errors identified  Bad activity  No activity  Divergence  Unbound requirement error

Jiří Adámek Dagstuhl, November 2006 Standalone detection Context-dependent detection Detection of composition errors

Jiří Adámek Dagstuhl, November 2006 Support for reentrant component specification A component performs tasks in parallel  Reentrant component A single task is specified by a finite-state model The number of the tasks depends on the input from the environment  For every run, the number of the tasks is finite  There is no upper bound to the number of the tasks when all possible runs are considered  An infinite-state model is needed to describe the behavior of the component  Our tools are able to handle only finite state models

Jiří Adámek Dagstuhl, November 2006 Support for reentrant component specification DatabaseClient 1 Client 2 Client n … What is the number of the clients? What is the number of the threads featured by a client? A Component Unknown Environment Component design time

Jiří Adámek Dagstuhl, November 2006 Support for reentrant component specification DatabaseClient 1 Client 2 3 threads2 threads Deduced from the behavior models of the clients 5 threads Application design time

Jiří Adámek Dagstuhl, November 2006 Support for reentrant component specification Observation  The “source” of unbounded parallelism is the lack of information at the component design time  At the architecture design time, unbounded parallelism often “collapses” into bounded parallelism A proposal  At the component design time Behavior of a reentrant component is specified using a behavior template  At the architecture design time The behavior template is transformed into a finite-state model automatically Such a model is application-specific

Jiří Adámek Dagstuhl, November 2006 Support for reentrant component specification Behavior templates  Based on behavior protocols  Special constructs for reentrancy Example parallel(?P.query*, mip P) Database P

Jiří Adámek Dagstuhl, November 2006 Support for reentrant component specification Behavior template transformations  Behavior template  Common behavior protocol  The transformation is done at the application design time  Information about the application architecture is used for this transformation A problem: transformation dependencies  The constructs describing reentrancy in the behavior templates introduce dependencies among the transformations  Solved Acyclic dependencies A special kind of cyclic dependencies  Unsolved General cyclic dependencies

Jiří Adámek Dagstuhl, November 2006 Conclusion Behavior composition in current component models was analyzed Two improvements  Detection of composition errors  Support for reentrant component behavior specification Future work  Behavior template transformation in a general case A case study

Jiří Adámek Dagstuhl, November 2006 Thank you for your attention. Questions?