The C2 Architectural Style

1
The C2 Architectural Style

• ICS 123
• Richard N. Taylor and Eric M. Dashofy
• UC Irvine
• http//www.isr.uci.edu/classes/ics123s02/

2
Architectural Styles

• Walk like this!
• Why should I walk like that?
• Canonical structures and rules
• provide context
• focus attention
• promote shared understanding
• carry hard-won domain knowledge and proven
  solution techniques

3
The C2 Style(Taylor et al., UC Irvine)

• A general multi-tier architectural style
• Asynchronous message-based integration of
  independent components
• Based on past experience with the
  model-view-controller design pattern and the
  Chiron-1 UIMS
• Generalizes architectures for user interface
  management systems
• Notable feature flexible connectors
• Accommodate arbitrary numbers of components
• Facilitate runtime architectural change
• Principle of substrate independence
• A component need not know anything about
  components beneath it
• Well define the layering rules and the notion of
  beneath shortly
• Rich design environment for composition analysis

4
The C2 Style

• Autonomous components
• own thread and non-shared address space
• All communication is by asynchronous events which
  must pass through a connector
• connectors may be complex and powerful
• Some additional rules to promote reuse
• (A variety of implementation techniques)

5
Intellectual Heritage

• Domain-specific software architectures
• concurrent, loosely coupled, distributed, dynamic
  apps
• Smalltalks model-view-controller paradigm
• Fields event-based integration
• Abstraction and separation of concerns
• OO typing
• Lisp, et.al.s dynamic properties

6
Qualities Affected

• Advantages
• Reusability (discrete components promote
  reusability)
• Evolvability/Flexibility Because event receivers
  are not explicitly named, it is possible to
  integrate new components fairly easily
• Dynamism (can change architecture on the fly)
• Visibility (explicit mandatory connectors
  provide points for observation)
• Distributability (all events are assumed to be
  independent, and therefore components can be
  distributed across hosts)
• Understandability (particularly promoted via
  substrate independence)
• Disadvantages
• Familiarity Programmers often not initially
  familiar with event-based asynchronous
  programming
• Complexity Because of asynchrony, concurrency
  issues are more prevalent and must be handled,
  event interactions are not always obvious
  (although tools can help!)

7
A Second 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
8
Example KLAX Video Game

• KLAX Chute
• Tiles of random colors drop one cell at a time,
  starting at random times and locations
• KLAX Palette
• Palette manipulated to catch tiles coming down
  the Chute and to drop them into the Well
• KLAX Well
• Horizontal, vertical and diagonal sets of three
  or more consecutive tiles of the same color are
  removed, and any tiles above them collapse down
  to fill in the newly-created empty spaces
• KLAX Status
• Points scored as sets are formed
• Lives lost as Well or Palette spills over

9
A Simple Example KLAX

• KLAX game
• 16 components, approx. 4k SLOC, 100kb compiled
• implemented from scratch inthe C2 architectural
  styleTMA96

10
KLAX Adaptability

• Spelling KLAX
• spell words from falling letters
• replaces 3 components
• High score list
• adds 3 new components
• Multi-player networked KLAX
• a match adds a tile toopponents chute

11
KLAX Adaptability

• Spelling KLAX
• spell words from falling letters
• replaces 3 components
• High score list
• adds 3 new components
• Multi-player networked KLAX
• a match adds a tile toopponents chute

12
KLAX Adaptability

• Spelling KLAX
• spell words from falling letters
• replaces 3 components
• High score list
• adds 3 new components
• Multi-player networked KLAX
• a match adds a tile toopponents chute

13
KLAX Adaptability

• Spelling KLAX
• spell words from falling letters
• replaces 3 components
• High score list
• adds 3 new components
• Multi-player networked KLAX
• a match adds a tile toopponents chute

14
C2 Component Structure (I)

• The internal object is the guts of the
  component
• The wrapper maps messages to operations of the
  internal object
• Requests ? Operation Invocations
• Operation Results ? Notifications
• Wrapped object can be described in terms of
  method signatures
• This organization allows reuse of
  independently-developed, off-the-shelf
  components as the internal object

Domain Translator
Wrapper
Internal Object
Dialog
requests
notifications
15
C2 Component Structure (II)

• The dialog provides the control logic, routing
  any relevant message to/from the internal object
• The domain translator translates messages from
  this components vocabulary to that of the
  layer above
• Note that a component never requests anything of
  components beneath it

Domain Translator
Wrapper
Internal Object
Dialog
requests
notifications
16
C2 Component Connection

• C2 Connectors
• Broadcast all messages received on the bottom
  side to the top side, and vice versa
• Operate across machines
• Operate across languages
• Accommodate dynamic attachment and removal of
  components
• Can be implemented in a number of ways
• Procedure calls
• Ada rendezvous
• Java events
• CORBA ORBs

Connector
17
A Typical C2 Configuration

• Computation originates mostly in lower layers
• Components need not process all messages they
  receive
• Connectors need not fully segregate layers

Comp1
Comp5
Conn1
Comp2
requests
notifications
Conn2
Comp4
Comp3
18
Rules of the C2 Style

• Components are never attached to other components
• A component can be attached to at most one
  connector on its top side and one on its bottom
  side
• Connectors can be attached to other connectors
• A connector must have at least one component or
  connector attached on its top side and one
  attached on its bottom side
• Requests only go up in an architecture
• Notifications only go down in an architecture
• There is no circularity allowed
• A component can never receive its own messages

19
Component Interfaces
Comp1 top bottom request query(ID
int, M msg) notification ack(ID
int) Comp2 top request notification
ack(ID int) bottom request
init(ID int) notification ...
Comp1
Comp5
Conn1
Comp2
requests
notifications
Conn2
Comp4
Comp3
20
A C2 Style Architecture for KLAX

• Exhibits typical C2 characteristics
• State components reside in upper layers
• Interface components reside in lower layers
• Intermediate layers provide control logic

21
Turning KLAX intoSpelling KLAX

• Flexible connectors facilitate the necessary
  architectural changes
• Next Letter Placing Logic component substituted
  for Next Tile Placing Logic component
• Spelling Logic substituted for Tile Logic
• Letter Artist substituted for Tile Artist

22
Example A Long-Distance Telecommunications System

• Telephones
• Local Switches (one per area code)
• Long-Distance Switches (communications backbone)
• Call Records database
• Other embellishments
• 800 numbers
• 911 stations
• Operator stations
• Bill generators