The Seescoa Component Architecture

contact: werner.van.belle@vub.ac.be

Embedded systems

Code Size

Real time (latency, throughput,…)

Robust

Connectivity

Remote updates (update running software)

OO LimitsModularityWhere does one class-hierarchy stop ?

C++: STLJava: Streaming Libraries

Over abstraction of frameworks ?Reusability of a frameworkWhat about adding an extra parameter ?

OO Limits

Static structurePlug in new behavior at runtime ???Dynamically replace behavior of certain

objectsC++: Multiple InheritanceJava: Interfaces

Write interface wrappers between classesC++: IDL -> proxyJava: RMIC

OO Limits

Very rigid calling structure !!!Call methodWait for answerContinue

DebuggingTrace Program ExecutionProfile Program Execution

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

The Component Architecture

ComponentPiece of self-contained code & dataCommunicate asynchronouslyMessages are send trough ports

Precompiler: .component -> .javaMakes it easier to write component codeEnables the automatic extraction of MSC’s

The Component Architecture

Component System/Architecture = Runtime EnvironmentMessage Handling ServiceScheduler Naming Service

HttpDaemon (1)

Provided Interface by HttpDaemon Html(Data) HtmlDone() RespondTo(Socket)

HttpDaemon (2)

Required Interface for an URL-Handler GenerateHtml(Url)

HttpDaemon (3)

HttpDaemon AccessCounterRespondTo(Socket)

GenerateHtml(Url)

Html(Data)

Html(Data)

HtmlDone()

Socket.Close()

Writing a Component ?

Use componentclass

componentclass Httpd {…}

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()}

Retrieving Arguments ?

Message methods doesn’t take any parameters. To retrieve the arguments use the <> notation.

componentclass Httpd {... message Html() {System.out.println(<Data>)} ...}

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>);}...}

HttpDaemon (4)

HttpDaemon AccessCounterRespondTo(<Socket>)

GenerateHtml(<Url>)

Html(<Data>)

Html(<Data>)

HtmlDone()

Socket.Close()

How do we knowthis Socket ?

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><);}...}

HttpDaemon (5)

HttpDaemon AccessCounterRespondTo(<Socket>)

GenerateHtml(<Url>,>Socket<)

Html(<Data>,>Socket<)

Html(<Data>,>Socket<)

HtmlDone(>Socket<)

>Socket<.Close()

Writing an Adapter (1)

A

Writing an Adapter (2)

A

RealA

Writing an Adapter (3)componentclass Adapter

{

message ReceiveMessage()

{

Message m:copyMessage(<Message>);

m.invoke=“foo”+m.invoke;

m.target=“RealA”;

sendMessage(m)

}

…

Writing an adapter (4)

…

message SendMessage()

{

Message m=copyMessage(<Message>);

m.invoke=”bar”+m.invoke;

sendMessage(m);

}

…

Writing an Adapter (5)

…

message Init()

{

ComponentSystem..Rebind(“A”,”RealA”);

ComponentSystem..AddReceiver(“A”,this);

ComponentSystem..AddSender(“A”,this);

}

}

The Raw Component System

a scheduler a naming serviceBindRebindUnbind

Message deliverysendMessage(…) receiveMessage(…)

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

Receiving Messages

Before receiving a message, the CS checks whether there is a proxyIf there is one, we wrap the message in an ReceiveMessage(<Merssage:…>) message and queue itIf there is an immediate target, we call receiveMessage upon the TargetOtherwise, we wrap the message in an Undeliverable(<Message:…>) message and queue it.

The Standard Component System

Is called “ComponentSystem” ..Init(…) ..CreateComponent(…) ..DestroyComponent(…) ..SendMessage(…) ..ReceiveMessage(…) ..AddReceiver(…) ..AddSender(…) ..Bind(…), ..Rebind(…), ..Unbind(…) ..Undeliverable(…)

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 machineWhen receiving a forwarded message, we send it through to the actual target.Written as a component itself

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(…)

Benefits (2)

ConcurrencyComponent system alternates between two

or more tasks. #Tasks is independent of #Processes

FlexibilityVery small systemSupport for tracing, profiling, debuggingExtendable