C2 Supplement

Jie Ren

ICS 123, Fall 2002

Based on Eric Dashofy’s slides for

ICS 123, Spring 2000

One more example

ArchStudio 3 Holds architecture descriptions

Critics watch architecture for problems

Architecture-to-implementation mappings

Manages open issues

Manages design critics

GUIs for various high-level tools

Graphical and syntax-directed editors

Manages open files and tools

Review of C2 Constraints and Properties

A Quick Look at the C2 Style

• Asynchronous, event-based communication among autonomous components, mediated by active connectors

• No component-component links

• Event-flow rules:

• Hierarchical application

Notifications fall

Requests rise Component

Connector

“push”

“pull”

Connector

Review: C2 Constraints

• Components & connectors have two interfaces (top & bottom)

• Components must only communicate through a connector

• Components may have 0-1 connector connected to each interface

• Connectors may have as many components on top & bottom as they want

• All communication through INDEPENDENT messages– NO PASSING POINTERS!

C2 Constraints (cont).

• Substrate Independence– Make assumptions about what components

above you can do for you (but not necessarily which specific components those are)

– Make no assumptions about what components are below you

• Up & Down communication only

• No side-side communication

Leveraging C2 Constraints

• The connector-connector link can be a powerful thing– If you have a component that merely passes messages untouched, consider

linking connectors

• Also, there are lots of interesting configurations that are non-obvious!

Another interesting configuration

Circular dependence

• What if you have two (or more) components that you really believe are circularly dependent?

• Five common solutions…

A B

Solution 1-3:

A+BSolution 1: Merge

A

B

Solution 2:Remove one dependency

A

BSolution 3:

Remove other

dependency

Solutions 4 & 5:

A B

ADTSolution 4:

(Data Integration)Communicate via shared data

(mini-blackboard style)

A B

Manager

Solution 5:(Control Integration)

Use a manager that can make requests of either component; notifications are turned into

invocations.

Try to avoid this…

A B

BAD

“Magic Mirror” or “Reflectors”approach: Component simply

“reflects” notifications or requests

into the opposite type of message.

Using c2.fw to Implement C2-style Architectures

Overview

• For this assignment, you will:– Be implementing the component behaviors of a C2-

style architecture using the c2.fw framework• Have components send out messages when necessary

• Have components handle all necessary messages

• You will NOT:– Create new components

– Create or modify an architectural configuration

– Create connectors

What is c2.fw?• An architecture framework, in Java, that is faithful to the

C2 architectural style• “Killer” Features

– Pluggable topology manager• You will be using the default topology manager

– Pluggable message queueing policy• You will be using one-queue-per-interface

– Pluggable threading policy• You will be using one-thread-per-brick

– More clear support for brick lifecycles and architecture configurations

• You will be using the lifecycles, configurations are taken care of for you

– Better support for distribution, dynamism than in previous frameworks

• You will not be using this for this assignment

Important Classes• AbstractC2Brick

– The base class of all C2 bricks– Two interfaces: topIface and bottomIface– Important Methods:

• init() - override– Called when the brick is instantiated

• begin() - override– Called when the brick is welded into place, send initial messages here

• end() - override– Called when the brick is about to be unwelded, send final messages here.

Not used in this assignment.

• destroy() - override– Called when this brick is about to be destroyed. Not used in this

assignment.

AbstractC2Brick (cont).

• More important methods…– sendToAll(Message m, Interface iface) - Call

• Sends message m out the interface iface• iface can be ‘topIface’ for requests or ‘bottomIface’ for

notifications

– handle(Message m) – Override• Called automatically by the framework when a message arrives

on any interface• This is where all message handling is done

– getIdentifier() – Override• Call this to get the identifier (class Identifier) of the brick• Call toString() on the identifier to get a string representation of it

Notes on Connectors

• You will rely on existing connector class

• The connector will forward all messages to the other side– Request forwarded upward– Notification forwarded downward

More Important Classes

• NamedPropertyMessage– A C2 message with a name and a property list– Properties have string names and either simple-type or serializable Object

parameters– DO NOT PASS PONINTERS IN PARAMETERS!

//Create a named property message

NamedPropertyMessage npm = new NamedPropertyMessage(“ChatText”);

//Add some parameters

npm.addParameter(“Text”, text);

npm.addParameter(“Sender”, “Strong Bad”);

//Send it upward as a request

sendToAll(npm, topIface);

More about Message• c2.fw.Message is an interface

– Operations are simple:– Where did this message come from?

• getSource()– Where did it go?

• getDestination()– Is this the same as another message?

• equals()– Make me a copy

• duplicate()

• Source and destination are returned as BrickInterfaceIdPairs– Each contains a brick identifier and an interface identifier– Useful for checking if an incoming message was a request or a

notification• If destination interface ID equals(TOP_INTERFACE_ID) it’s a

notification• If destination interface ID equals(BOTTOM_INTERFACE_ID) it’s a

request

Subclassing NamedPropertyMessage

• This is possible, but some boilerplate code is required

• Enforces better type safety, makes code clearer

• You don’t have to do this in this assignment. Using parameters to achieve a goal.

• Think how a message flows