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

Architecture Meeting - D2 - 07/08/2004 Outline è Motivations è Dream è Experiments è Future work

Architecture Meeting - D3 - 07/08/2004 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

Architecture Meeting - D4 - 07/08/2004 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, …

Architecture Meeting - D5 - 07/08/2004 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

Architecture Meeting - D6 - 07/08/2004 Outline è Motivations è Dream  Core  ADL  Component library è Experiments è Future work

Architecture Meeting - D7 - 07/08/2004 Dream core è Define abstractions and tools to manage resources  Messages  Activities è 105 classes (12054 lines) è dream-core.jar = 113k

Architecture Meeting - D8 - 07/08/2004 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

Architecture Meeting - D9 - 07/08/2004 Message managers è Shared components that manage messages and chunks  Implement the MessageManager interface  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

Architecture Meeting - D /08/2004 Inputs/outputs è Fractal interfaces that allow message exchanges between components push(message, ctxt) ; void push(Message m, Map ctxt){ // Processing of message m } Push connection Message m = pull(ctxt); // Processing of // message m Message pull (Map ctxt){ // Returns a message } Pull connection Component A Component B Input Output Principle

Architecture Meeting - D /08/2004 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

Architecture Meeting - D /08/2004 Activity managers è Shared components that encapsulates tasks and schedulers Activity manager Task (thread) FIFO Scheduler Task A1Task A2Task B Component A Third party Component B taskManager schedulerManager taskController Task (thread) schedule execute register(A1 )

Architecture Meeting - D /08/2004 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 !

Architecture Meeting - D /08/2004 Outline è Motivations è Dream  Core  ADL  Component library è Experiments è Future work

Architecture Meeting - D /08/2004 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

Architecture Meeting - D /08/2004 Outline è Motivations è Dream  Core  ADL  Component library è Experiments è Future work

Architecture Meeting - D /08/2004 Component library (1) è Components commonly found in CMs  Fine grain components Ease reuse Improve configurability è 76 classes (9025 lines) è dream-lib.jar = 116k

Architecture Meeting - D /08/2004 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 …

Architecture Meeting - D /08/2004 Outline è Motivations è Dream è Experiments è Future work

Architecture Meeting - D /08/2004 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)

Architecture Meeting - D /08/2004 Joram

Architecture Meeting - D /08/2004 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

Architecture Meeting - D /08/2004 Performances (2) Nb of Rounds / secMemory footprint (KB) 0 kB1 kB Joram x 1447 Dream (non-reconf) x 1580 Dream (reconf) x 1587 è Dream non-reconf  Optimized binding Interface object bypassed  No lifecycle interceptor Non stoppable application è Julia has no execution cost and low memory cost

Architecture Meeting - D /08/2004 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

Architecture Meeting - D /08/2004 Configurability assessment (2) è An Agent Server for mobile devices Router Atomic Reactor Agent Factory Agent Repository MessageToNotif NotifToMessage TCPChannelIn (Pull) TCPChannelOut (Push) Repository AtomicityProtocol Engine ChannelOut (Pull) TCPChannelI n (Push) Conduit Network (details not shown) RemoteRepresentative Towards other agent servers Mobile deviceProxy

Architecture Meeting - D /08/2004 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

Architecture Meeting - D /08/2004 SEDA architecture Event Handler Thread Pool Controller Event Queue Outgoing Events

Architecture Meeting - D /08/2004 SEDA-Dream architecture

Architecture Meeting - D /08/2004 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

Architecture Meeting - D /08/2004 Outline è Motivations è Dream è Experiments è Future work

Architecture Meeting - D /08/2004 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

Architecture Meeting - D /08/2004 Questions?