A Component- and Message-Based Architectural Style

1
A Component- and Message-Based Architectural
Style for GUI Software BY Richard N. Taylor, et.
Al Presented By Deepashree Krishnamurthy
2
What is this paper about?

• A novel architectural style
• Directed at supporting larger grain reuse and
  flexible system composition.
• Supports design of distributed, concurrent
  applications.
• Components are not built with any dependencies
  on what typically would be
• considered lower- level components, such as
  user interface toolkits.
• Draws its key ideas from another UI development
  system called Chiron-1
• Hence called as Chiron-2 or C2

3
GOALS

• Ability to compose systems in which
• Components may be written in different
  programming languages
• Components may be running concurrently in a
  distributed, heterogeneous
• environment without shared address spaces.
• Architectures may be changed at runtime
• Multiple users/toolkits/dialogs may be
  interacting with the system.
• A network of concurrent components hooked
  together in a hierarchy by message
• routing devices, such that a component could
  only be aware of components above it
• and completely unaware of components which
  reside beneath it.

4
Stack Manipulation System
5
Components
6
Notifications Requests
7
Connectors

• Connectors bind components together.
• They may be connected to any number of
  components as well as other connectors.
• Responsibility
• Routing and broadcast of messages.
• Filtering messages.
• Filtering policies
• No Filtering Each message is sent to all
  connected components.
• Notification Filtering Each notification is
  sent to only those components that
• registered for it.
• Prioritized The connector defines a priority
  ranking over its connected components.
• e.g., spell-checking a document, with
  possibly different implementations.
• Message Sink The connector ignores each
  message sent to it.

8
EXAMPLES AND TRIAL APPLICATIONS
A. Petri Net Tool with Multiple Presentation
Components
( http//pdv.cs.tu-berlin.de/azi/petri.html )

• This example considered building a petri net
  editor such that
• Places in the net are depicted by polygons
  whose number of sides equals the number of tokens
  inside each place.
• Clearly, places with 0,1, or 2 tokens cannot be
  represented by polygons and have to be depicted
  by an empty circle, a point (filled circle), and
  a line respectively.
• Every time a transition is fired, the shapes of
  all the places connected to that transition
  potentially change.
• In order to achieve this
• The layout will need to be separated from
  its presentation.
• The presentation of places with different
  numbers of tokens needs to be entrusted
  to separate components.

9

• Artist
• Maintains the coordinates of places,
  transitions,
• and arcs
• Addresses issues of adjacency, and maintains
• logical associations with Petri net ADT
  objects.
• It has no knowledge of the artists in the
• presentation layer or the look of Petri
  net
• Therefore,
• When ever a place is added, deleted, or
  repositioned, or its number of tokens changes due
  to a transition firing, ? the layout artist
  broadcasts the appropriate notifications ?
  Artist maintaining the presentation of places
  with the specified number of tokens responds to
  them.
• The separation of the 2 layers, the
  presentation of Petri net places could be easily
  changed from the standard circle-with-dots-as-toke
  ns to polygons.
• The components in the presentation layer are
  simple and entirely independent of each other.
  They can be added, interchanged, or substituted
  with new ones, without affecting the rest of the
  system.

10
ARGO THE C2 DESIGN ENVIRONMENT

• Argo is a design environment for building
  C2-style architectures.
• Constructs an architectural model
• Checks for syntactic and semantic correctness,
• Gives domain-specific feedback about various
  design qualities,
• Keeps track of unfinished steps in the design
  process,
• Generates running programs for that system.

Notation A connected graph of software
components and connectors. Critical Feedback
Active agents provide critical and timely
feedback from making wrong design decisions. But
does not provide a feedback about the design.
Code Generation Allow the designer to specify
the mapping from conceptual to efficient
implementation architectures. Argo finishes the
mapping via default rules. Architecture Analysis
The design environment supports several types of
static analysis on the architecture using
pro-active design critics.
11
RELATEDWORK

• A. Implicit Invocation
• In the C2 style, implicit invocation occurs
  when a component reacts to a notification sent
  down an architecture by invoking some code.
• Contrasting with other systems, the C2 style
  provides a discipline for ordering components
  which use implicit invocation. Hence yielding
  substrate independence.
• B. Messages and Message Mechanisms
• The experiences from Chiron-1,Avoca systems
  on message communication is that
• If message traffic occurs across a
  process boundary in a non-shared address space,
  then interprocess communications (IPC) becomes a
  key performance determinant.
• This motivated a key goal of the C2 style which
  was
• To provide a discipline for using service
  request and notification messages which can be
  mapped to either inter- or intra-process message
  mechanisms as needed.

12
RELATEDWORK (Contd.)

• C. Layered Systems
• Concentrating solely on the layering in an
  architecture, existing approaches span a wide
  range.
• Systems such as Field and SoftBench have only
  a single layer.
• The client/server spilt was supported by X
  hence bring about two layered architecture.
• Chiron-1 has three layers the application,
  artists, and graphics server.
• Certain Models partition the work of
  supporting UI into specific layers. One of it
  partitions the work into five layers, known as
  the domain-specific (application) component,
  domain adaptor, dialog, presentation, and
  interaction toolkit components
• BUT C2 style allows natural layering to handle
  each specific domain. Furthermore, C2 provides a
  layering mechanism based on implicit invocation,
  rather than the explicit calls providing greater
  flexibility in achieving substrate independence
  in an environment of dynamic, multi-lingual
  components.

13
RELATEDWORK (Contd.)

• D. Language and Process Support
• In contrast to certain other systems like
  Smalltalk, C2 embodies no language
• assumptions components may be written in
  any convenient language.
• C2 supports simultaneous satisfaction of
  arbitrary numbers of processes in a
• non-shared address space is achieved.
• E. Component Interoperability Models
• There are a lot of models that provide standard
  format for describing services offered by a
  component and runtime facilities to locate, load,
  and execute services of other components Ex
  OLE and OpenDoc.
• BUT these models are concerned with low-level
  implementation issues and provide little or no
  guidance in building a system out of components.
• THEREFORE C2 is not based on them but subsumes
  them IN THAT These models may be used to
  realize an architecture in the C2 style.

14
RELATEDWORK (Contd.)
F. Design Environments Aesop Generation tool
for software architecture design environments
which focuses on architectural styles. Aesop
interoperates with external analysis and code
generation tools and a component repository.
However, it is not organized around critics and
has very little support for the designers
beyond graphical support. Argo Domain-oriented
design environment for the domain of C2 style
software architectures.
G. Relating C2 Concepts to Object-Oriented Types

• The distinction between notifications, requests
  and the topology imposed by the C2
• style on a set of components in an
  architecture.
• Programming languages generally adopt a single
  type checking method. On the other
• hand, C2 allows several subtyping mechanisms.
  

15
CREATING AN ARCHITECTURE IN THE C2 STYLE

• Designing an architecture involves
• An iterative process of subdividing
  functionality into components
• (modular decomposition)
• Determining the external interfaces of
  components
• Positioning components within a C2
  architecture.
• Implementing a message passing
  infrastructure for connectors and
• developing a component template.

16
OPEN ISSUES

• Notifications Need for full state broadcast
  as when an operation causes a
• complex state change to occur within the
  component.
• In this case, full state notifications greatly
  reduce the complexity of listening
• components.
• Connectors, are like software buses. There
  are no of bus technologies that may
• be suitable in the implementation of an
  architecture.
• Trade-off between scalability and performance
• All the trial applications completed have
  been smaller scale systems.
• Much work remains to be done on both
  architectural description (ADL) and
• interface definition (IDL) languages and
  the corresponding code generation
• and analysis tools.

17
Conclusion

• One notable characteristic is the inability
  for a component to have dependencies
• on the technologies upon which it rests.
• Rather, a component is hopeful that the
  components below it will perform
• useful work based on notification of
  actions that it performs.

Future work

• Future systems are going to be increasingly
  distributed, complex, multimedia, heterogeneous,
  and multi-user.
• Assessing key scalability factors
• Construction of a design environment
• Exploration of how current commercial
  Research offerings may be adapted to serve as
  reusable C2 components.

18
AUTHORS

• Richard N. Taylor
• Professor of Information and Computer Sciences
  UC Irvine .
• Research interests software architectures .
• (Event-based peer-to-peer systems).
• Director of the Institute of Software Research
  ( Fostering innovative
• basic and applied research ).
• Chairman of ACM's Special Interest Group on
  Software Engineering,
• SIGSOFT.
• Chairman of the steering committee for the
  International Conference
• on Software Engineering.

• Nenad Medvidovic
• Assistant Professor in the Computer Science
  Department at
• University of Southern California.
• Faculty member of the USC Center for Software
  Engineering (CSE).
• Recipient of the National Science Foundation
  CAREER (2000) and
• ITR (2003) awards.

19

• Kenneth M. Anderson
• Assistant Professor, Department of Computer
  Science at the
• University of Colorado, Boulder
• Vice Chair of ACM SIGWEB.

• E. James Whitehead Jr.
• Assistant Professor, University of California,
  Santa Cruz.
• Chair, Web Distributed Authoring and Versioning
  (WebDAV).

20

• Jason E. Robbins
• Lecturer , UC Irvine, School of Information and
  Computer Science

• Kari A. Nies
• Research Programmer/Analyst III , Institute for
  Software Research,
• UC Irvine

• Peyman Oreizy
• Working at Microsoft Corporation
• Deborah L. Dubrow ??