C2 Supplement

1
C2 Supplement

• Jie Ren
• ICS 123, Fall 2002
• Based on Eric Dashofys slides for
• ICS 123, Spring 2000

2
One more example
3
ArchStudio 3
Holds architecture descriptions
Manages open issues
Critics watch architecture for problems
Manages design critics
Architecture-to-implementation mappings
GUIs for various high-level tools
Graphical and syntax-directed editors
Manages open files and tools
4
Review of C2 Constraints and Properties
5
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

Connector
Notifications fall
pull
Requests rise
Component
push
Connector
6
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!

7
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

8
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!

9
Another interesting configuration
10
Circular dependence

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

B
A
11
Solution 1-3
AB
Solution 1 Merge
A
B
Solution 3 Remove other dependency
Solution 2 Remove one dependency
A
B
12
Solutions 4 5
ADT
Solution 4(Data Integration) Communicate via
shared data (mini-blackboard style)
B
A
B
A
Solution 5(Control Integration) Use a manager
that can make requests of either component
notifications are turned into invocations.
Manager
13
Try to avoid this
BADMagic Mirror or Reflectors approach
Component simplyreflects notifications or
requestsinto the opposite type of message.
B
A
14
Using c2.fw to Implement C2-style Architectures
15
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

16
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

17
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.

18
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

19
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

20
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 NamedPropertyMes
sage 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)
21
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_I
  D) its a notification
• If destination interface ID equals(BOTTOM_INTERFAC
  E_ID) its a request

22
Subclassing NamedPropertyMessage

• This is possible, but some boilerplate code is
  required
• Enforces better type safety, makes code clearer
• You dont have to do this in this assignment.
  Using parameters to achieve a goal.
• Think how a message flows