Dream A Fractal-based communication framework

1. DreamA Fractal-based communication framework ObjectWeb Architecture Meeting July, 8th 2004 M. Leclercq, V. Quéma, J.-B. Stefani Sardes Project, INRIA-LSR-IMAG

2. Outline • Motivations • Dream • Experiments • Future work

3. Motivations • Existing communication middleware (CM) • Provide a fixed communication model • RPC (CORBA, RMI, SOAP, …) • JMS (JORAM, WebSphere MQ, iBus, …) • Ad-Hoc (BEA MessageQ, Gryphon, SIENA, …) • But… share a lot of architectural components • Provide several non-functional properties • Are not extensively (re)configurable • Fixed monolithic architecture with few parameters to configure • The application developer is constrained to fixed abstractions

4. What do we need? • (re)configurable CMs • Functionally • Build various communication paradigms • RPC, Message passing, event/reaction, publish/subscribe • Non functionally • Provide various non-functional properties • Security, transactions, persistency, ordering, … • Architecturally • Adapt to various kind of execution environments • PC, PDA, cell phones, …

5. What is Dream? • A framework for building CMs • Core • Abstractions and tools for resource management • Messages • Activities • ADL for the configuration and deployment of CMs • A component library • Components commonly found in CMs • Used to build several personalities • JMS, Probabilistic broadcast, Internet services, … • Integrated in LeWYS

6. Outline • Motivations • Dream • Core • ADL • Component library • Experiments • Future work

7. Dream core • Define abstractions and tools to manage resources • Messages • Activities • 105 classes (12054 lines) • dream-core.jar = 113k

8. Messages • Messages are fractal composites encapsulating • Chunks • Unit of data allocation • Implement a Fractal server interface • Sub messages • Two interfaces • Message • Methods to retrieve chunks and sub messages • ExtensibleMessage extends Message • Methods to add/remove chunks and sub messages

9. Message managers • Shared components that manage messages and chunks • Implement theMessageManagerinterface • Methods to create, delete, duplicate chunks and messages • Pool messages and chunks for efficiency • Generic versus specific implementations • Future work: dynamic generation of messages using ASM

10. Inputs/outputs • Fractal interfaces that allow message exchanges between components void push(Message m, Map ctxt){ // Processing ofmessage m } Message m = pull(ctxt); // Processing of // message m Component B Input Output Component A push(message, ctxt) ; Message pull (Map ctxt){ // Returns a message } Principle Push connection Pull connection

11. Activities • Components can be active or passive • Active components define tasks to be executed • For a task to be executed, it must be registered to one activity manager component

12. Activity managers • Shared components that encapsulates tasks and schedulers Activity manager Third party schedulerManager Task (thread) Task (thread) schedule taskController FIFO Scheduler taskManager Component A execute register(A1) Task A1 Task A2 Task B Component B

13. Schedulers and tasks • Schedulers are responsible for mapping higher level tasks onto lower-level tasks • Schedule server interface • Execute client interface • Implement a scheduling policy • FIFO, round-robin, with priority, ... • Tasks • Execute server interface • Schedule client interface • Three kinds of tasks • Higher-level tasks = applicative tasks • Lowest-level tasks = threads (Execute = Runnable) • Middle-level tasks = allow inter-schedulers scheduling • Note: shares a lot of similarities with P. Merle’s orchestration framework… should be merged soon !

14. Outline • Motivations • Dream • Core • ADL • Component library • Experiments • Future work

15. ADL • Use Fractal ADL • All this work is not Dream specific • Added modules • Description of legacy components • Class loading management (uses OSCAR’s module loader) • Future work • Extend (re)configuration capabilities • Support for distributed asynchronous deployment

16. Outline • Motivations • Dream • Core • ADL • Component library • Experiments • Future work

17. Component library (1) • Components commonly found in CMs • Fine grain components • Ease reuse • Improve configurability • 76 classes (9025 lines) • dream-lib.jar = 116k

18. Component library (2) • Message queue • Ordering (FIFO, causal, …) • Behavior in the different states (empty, full) • Router • Routing policy (round-robin, chunk name, …) • Aggregator • Aggregate messages received on the input(s) • Deliver a message on its output • Pump • Periodically pull a message on its input and then push it • Channel • Allow message exchanges between different address spaces (TCP socket, …) • Protocol components, Transformers, Filters …

19. Outline • Motivations • Dream • Experiments • Future work

20. Experiments • Goals • Check that • Various personalities can be built • There is a gain in configurability • Performances for functionally equivalent CMs are comparable • Performances can be better when CMs are adequately configured • Experiments • Joram, an open-source implementation of the JMS API • Lightweight Probabilistic Broadcast (LPBCast) • Staged Event-Driven Architecture (SEDA)

21. Engine AtomicityProtocol Repository MessageToNotif Agent Repository Atomic Reactor Agent Factory NotifToMessage Router Conduit Router Network 1 Network 2 Causal Sorter DestinationResolver ChannelOut ChannelIn DestinationResolver ChannelOut ChannelIn Joram

22. Performances (1) • Compare performance of the same application running on Joram agent server and its Dream based implementation • Four Agent servers • Each server hosts an agent • Agents are organized in a virtual ring • A message is forwarded by each agent around the ring • Measure • Number of rounds made by the message per second • Memory footprint

23. Performances (2) • Dream non-reconf • Optimized binding • Interface object bypassed • No lifecycle interceptor • Non stoppable application • Julia has no execution cost and low memory cost

24. Configurability assessment (1) • Allow changing non functional properties • Causal ordering • Atomic reaction • Allow changing the architecture • Allow changing the concurrency model • Allow building an architecture for mobile devices

25. Configurability assessment (2) • An Agent Server for mobile devices Engine RemoteRepresentative Repository AtomicityProtocol ChannelOut (Pull) TCPChannelIn (Push) MessageToNotif Agent Repository Atomic Reactor Agent Factory NotifToMessage Router Conduit TCPChannelOut (Push) TCPChannelIn (Pull) Network (details not shown) Towards other agent servers Mobile device Proxy

26. SEDA (Staged Event-Driven Architecture) • UC Berkeley project (SOSP 2001, USITS 2003) • Dedicated to the construction of highly concurrent Internet services • Service = network of event-driven stages • Stage • Event queue (incoming events) • Event handler • Thread pool

27. SEDA architecture Outgoing Events Event Handler Event Queue Thread Pool Controller

28. Stage Stage Functional interfaces taskController Event Queue Event Handler Pump batching Attribute taskManager ActivityManager Activity manager Task (thread) threadManager Task (thread) Pump Task Scheduler Stage Task (thread) SEDA-Dream architecture

29. Configurability assessment • Event handlers have direct control over threads • Allows avoiding the use of locks, … • Activity managers can be shared between several stages • Common scheduling policy for accessing shared state • Every architectural element is a component • Reconfiguration • Ordered queues • Allows changing the concurrency model

30. Outline • Motivations • Dream • Experiments • Future work

31. Future work • Improving Dream • Persistency, transactions • Improving resource management • Integrating Dream with other projects (CLIF, LeWYS) • Binding factory for Julia • Building other personalities • Synchronous middleware (requires Jonathan concepts) • Group communication library (with JGroups as a basis) • Implementing various publish/subscribe middleware

32. Questions?