1 / 34

Objects to Distributed Components (1)

Objects to Distributed Components (1). ComponentIdentity Cpt = newActiveComponent (params); A a = Cpt … .getFcInterface ("interfaceName"); V v = a.foo(param);. A. Example of component instance. V. Truly Distributed Components. Typed Group. Java or Active Object. JVM. getAandB().

manning
Download Presentation

Objects to Distributed Components (1)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Objects to Distributed Components (1) ComponentIdentity Cpt = newActiveComponent (params); A a = Cpt … .getFcInterface ("interfaceName"); V v = a.foo(param); A Example of component instance V Truly Distributed Components Typed Group Java or Active Object JVM

  2. getAandB() getA() getB() Functionalities : Without First Class Futures • Or in the case of Synchronous method calls getAandB() getAandB() getA() getA() getB() getB()

  3. value of A getAandB() getA() getB() value of B Functionalities : With First Class Futures Non-blocking method calls • Example 2 : Asynchronous method calls with full-fledge Wait-By-Necessity getAandB() getAandB() getA() getA() getB() getB() Assemblage are not blocked with Asynchrony + WbN

  4. IC2D Interactive Control & Debug for Distribution GUI for Distribution

  5. IC2D: Interactive Control and Debugging of Distribution With any ProActive applicationFeatures: Graphical and Textual visualization Monitoring and Control

  6. Monitoring of RMI, Globus, Jini, LSF cluster Nice -- Baltimore ProActive IC2D: Width of links proportional to the number of com- munications

  7. IC2D: Dynamic change of DeploymentDrag-n-Drop Migration • Drag-n-Drop • tasks • around the • world

  8. On-going work : GUI for Components

  9. Exampleof Applications

  10. Jem3D

  11. JECS : A Generic Version of Jem3D

  12. JECS : A Generic Version of Jem3D

  13. JEM3D Components

  14. Code Coupling : Vibro Acoustic (courtesy of EADS)

  15. 5. Model Checking: Vercors Behavioral Specification andModel Checking

  16. Tree of Finite LTSs Parameterized LTS Behaviour of Primitive Components Model Checking Parameterized Model Synchronisation networks + controllers Specification of the Architecture Finite Abstraction of parameter domains Formal verification and model checkingPrinciples of the VERCORS platform

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

  18. 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+

  19. 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)

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

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

  22. b. Adding Subcomponents

  23. c. Binding components through Interfaces

  24. d. Adding a new client (consumer)

  25. e. Defining behavior using State Machine Diagrams

  26. CONCLUSIONS

  27. Conclusion: Why does it scale? • Thanks to a few key features: • Asynchrony: Connection-less, • Messages rather than long-livinginteractions RMI+JMS unified

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

  29. Very Last Conclusion: Key Aspects • DistributedObjects: 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)

  30. Perspectives

  31. Perspective for Components GUI Graphical Composition, Monitoring, Migration

  32. Perspective for Components - PSE Graphical Composition, Monitoring, Migration

  33. Perspectives • Putting 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

More Related