The Seescoa Component Architecture

1. The Seescoa Component Architecture contact: werner.van.belle@vub.ac.be

2. Embedded systems • Code Size • Real time (latency, throughput,…) • Robust • Connectivity • Remote updates (update running software)

3. OO Limits • Modularity • Where does one class-hierarchy stop ? • C++: STL • Java: Streaming Libraries • Over abstraction of frameworks ? • Reusability of a framework • What about adding an extra parameter ?

4. OO Limits • Static structure • Plug in new behavior at runtime ??? • Dynamically replace behavior of certain objects • C++: Multiple Inheritance • Java: Interfaces • Write interface wrappers between classes • C++: IDL -> proxy • Java: RMIC

5. OO Limits • Very rigid calling structure !!! • Call method • Wait for answer • Continue • Debugging • Trace Program Execution • Profile Program Execution

6. OO Limits • Concurrency • Try to do two tasks at the same time • C++: Different threading/signal libraries • Java: Synchronize • Scheduling • Lower the logging priority in favor of the UI • Distribution • Shared memory no good • Synchronous calls doesn’t work

7. The Component Architecture • Component • Piece of self-contained code & data • Communicate asynchronously • Messages are send trough ports • Precompiler: .component -> .java • Makes it easier to write component code • Enables the automatic extraction of MSC’s

8. The Component Architecture • Component System/Architecture = Runtime Environment • Message Handling Service • Scheduler • Naming Service

9. HttpDaemon (1) Provided Interface by HttpDaemon • Html(Data) • HtmlDone() • RespondTo(Socket)

10. HttpDaemon (2) Required Interface for an URL-Handler • GenerateHtml(Url)

11. HttpDaemon (3) HttpDaemon AccessCounter RespondTo(Socket) GenerateHtml(Url) Html(Data) Html(Data) HtmlDone() Socket.Close()

12. Writing a Component ? Use componentclass componentclass Httpd { … }

13. Handling Messages ?  The CS takes care of delivery, we only have to implement the messages Html, HtmlDone, GenerateHtml  These methods doesn’t return anything, nor do they take any parameters. (message keyword) componentclass Httpd {... message Html() message HtmlDone() message RespondTo() }

14. Retrieving Arguments ?  Message methods doesn’t take any parameters. To retrieve the arguments use the <> notation. componentclass Httpd {... message Html() {System.out.println(<Data>)} ...}

15. Sending Messages ?  To contact another component the Httpd can send a message to another component using the special .. Notation ...{... message RespondTo() {dispatcher(URL)..GenerateHtml(<Url:URL>);} ...}

16. How do we know this Socket ? HttpDaemon (4) HttpDaemon AccessCounter RespondTo(<Socket>) GenerateHtml(<Url>) Html(<Data>) Html(<Data>) HtmlDone() Socket.Close()

17. Hidden Arguments ?  We can pass extra hidden arguments from one message call to another using the >< notation ...{... message RespondTo() {dispatcher(URL)..GenerateHtml( <Url:URL>, >Socket:<Socket><);} ...}

18. HttpDaemon (5) HttpDaemon AccessCounter RespondTo(<Socket>) GenerateHtml(<Url>,>Socket<) Html(<Data>,>Socket<) Html(<Data>,>Socket<) HtmlDone(>Socket<) >Socket<.Close()

19. Writing an Adapter (1) A

20. Writing an Adapter (2) A RealA

21. Writing an Adapter (3) componentclass Adapter { message ReceiveMessage() { Message m:copyMessage(<Message>); m.invoke=“foo”+m.invoke; m.target=“RealA”; sendMessage(m) } …

22. Writing an adapter (4) … message SendMessage() { Message m=copyMessage(<Message>); m.invoke=”bar”+m.invoke; sendMessage(m); } …

23. Writing an Adapter (5) … message Init() { ComponentSystem..Rebind(“A”,”RealA”); ComponentSystem..AddReceiver(“A”,this); ComponentSystem..AddSender(“A”,this); } }

24. The Raw Component System • a scheduler • a naming service • Bind • Rebind • Unbind • Message delivery • sendMessage(…) • receiveMessage(…)

25. Sending Messages • Before sending a message, the CS checks whether there is a proxy • If there is one, we wrap the message in a SendMessage(<Message:…>) message and queue it • Otherwise the message goes to the scheduler

26. Receiving Messages • Before receiving a message, the CS checks whether there is a proxy • If there is one, we wrap the message in an ReceiveMessage(<Merssage:…>) message and queue it • If there is an immediate target, we call receiveMessage upon the Target • Otherwise, we wrap the message in an Undeliverable(<Message:…>) message and queue it.

27. The Standard Component System • Is called “ComponentSystem” • ..Init(…) • ..CreateComponent(…) • ..DestroyComponent(…) • ..SendMessage(…) • ..ReceiveMessage(…) • ..AddReceiver(…) • ..AddSender(…) • ..Bind(…), ..Rebind(…), ..Unbind(…) • ..Undeliverable(…)

28. The Distributed Component System • Rebinds “ComponentSystem”, is called “Portal” • When creating a component, the instancename has to be prefixed with the name of the machine • When sending a message to a local undeliverable target, we forward it to the effective machine • When receiving a forwarded message, we send it through to the actual target. • Written as a component itself

29. Benefits (1) • Plug in new behavior at runtime ??? • Connect ports at runtime • Dynamically replace behavior of certain objects • Rebind the name of a component • Write interface wrappers between components • HandleMessage(…) • ReceiveMessage(…) • SendMessage(…)

30. Benefits (2) • Concurrency • Component system alternates between two or more tasks. • #Tasks is independent of #Processes • Flexibility • Very small system • Support for tracing, profiling, debugging • Extendable