objects to distributed components (1)

1

2

Objects to Distributed Components (1)

Typed Group Java or Active Object

ComponentIdentity Cpt = newActiveComponent (params);A a = Cpt … .getFcInterface ("interfaceName");V v = a.foo(param);

V

AExample of

component

instance

JVM

Truly

Distributed

Components

3

getA()

getB()

getAandB()

Functionalities : Without First Class Futures

Or in the case of Synchronous method calls

getA()

getB()

getAandB()

getB()

getA()getAandB()

4

getA()

getB()

getAandB() getA()

getB()

getAandB()

getB()

getA()getAandB()

Functionalities : With First Class Futures

Example 2 : Asynchronous method calls with full-fledge Wait-By-Necessity

Non-blocking method calls

value of A

value of B

Assemblage are not blocked with Asynchrony + WbN

5

IC2DInteractive Control & Debug for Distribution

GUI for Distribution

6

IC2D: Interactive Control and Debugging of Distribution

With any ProActive applicationFeatures:

Graphical and Textual visualization Monitoring and Control

7

Monitoring of RMI, Globus, Jini, LSF cluster Nice -- Baltimore

ProActive IC2D:

Width of links

proportional

to the number

of com-

munications

8

IC2D: Dynamic change of DeploymentDrag-n-Drop Migration

Drag-n-Drop

tasks

around the

world

9

On-going work : GUI for Components

10

Exampleof

Applications

11

Jem3D

12

JECS : A Generic Version of Jem3D

13

JECS : A Generic Version of Jem3D

JEM3D Components

15

Code Coupling : Vibro Acoustic (courtesy of EADS)

16

5. Model Checking:

VercorsBehavioral Specification

andModel Checking

17

Formal verification and model checking

Principles of the VERCORS platform

Behaviour ofPrimitive

Components

Specification of the

Architecture

Par

amet

eriz

ed

Mod

el

Treeof

FiniteLTSs

ParameterizedLTS

Synchronisation networks + controllers

ModelChecking

Finite Abstraction of

parameter domains

18

Behaviour of Primitives

Functional behaviour• Given by the user

• Static source code analysis (with ProActive primitives)

• Currently supported languages: FC2 and LOTOS

Usage• Parameterized LTS encoding the behaviour specification

19

Vercors Status and Relation to GCM-ProActive

Current state of tools• Functional behaviour: Ready and available (ADL2N)

• NF controllers and ProActive's semantics

• To be released in ADL2N v1

Current state of model• Functional and Non-Functional distributed components

• Extensions still needed:

• Exception handling is mandatory• Collective interfaces• A few other features of ProActive

Future Work• Modeling and Specification Language for ProActive community: TTools+

TTool+ for ProActive

• Design model of hierarchical components for ProActive:

High Level Design Tool mapped on a formal semantics,

Easy to understand, easy to use

• TTool+ :

An extension of TTool

(Developed by Ludovic Apvrille, ENST, LabSoC)

TTool+ for ProActive Alpha Version Provides:

• User design of distributed components with asynchronous calls

• Interactions between distributed components:

build behavior models ( use model checkers)

Future work:

• High Level Design of ProActive components: automatic generation of controllers of component management

• GCM: Generation of multiple instances of components and managing Group Communications

• Generation of ADL files, ProActive Template Code

Producer-Consumer System in TTool+ :a. First Level Component Design

b. Adding Subcomponents

c. Binding components through Interfaces

d. Adding a new client (consumer)

e. Defining behavior using State Machine Diagrams

27

CONCLUSIONS

28

Conclusion: Why does it scale?

Thanks to a few key features:

• Asynchrony: Connection-less,

• Messages rather than long-living interactions

RMI+JMS unified

29

Conclusion: Why does it Compose?

Thanks to a few key features:

• Because it Scales: asynchrony !

• Because it is Typed: RMI with interfaces !

No unstructured Call Backs and Ports

30

Very Last Conclusion: Key Aspects

Distributed Objects: Active Objects• Asynchronous Method Calls First-Class Futures

Calculus: ASP• Confluence (very General and Dynamic)• Determinism only based on Request-Sender Reception Order

Dist. Component Specification: GCM• Hierarchical and Runtime (Fractal)• Distributed (VN, …), Multicast, Gathercast

Middleware: ProActive• Programming, Composing, Deploying + GUI

Model Checking: Vercors• Hierarchical, Parameterized, • Practical (Multi. Source for Information, Checking vs. Telling)

31

Perspectives

32

Perspective for Components GUI Graphical Composition, Monitoring, Migration

33

Perspective for Components - PSE Graphical Composition, Monitoring, Migration

34

PerspectivesPutting everything together (ASP, ProActive, Vercors):

Still a lot of work !

Collaborations Welcome!

Behavioral specification of component composition (ongoing)

Specify and Study Non-Functional Aspects

• More Specifically:

Life-Cycle, Reconfiguration in distributed environments

ProActive.ObjectWeb.org

inria.fr/oasis/Vercors

Vercors