Software Architecture

Lecture 3
A Software Architecture
• An architecture is an abstraction of a
is an Abstraction
system that suppresses details of
components that do not affect how
they:
– Use
– Are used by
– Relate to
– Interact with
…other components.
 Externally Visible
Properties of
• Components
Externally visible properties refers
to those assumptions other
components can make of a
component, such as:
– Provided services
– Performance characteristics
– Fault handling
– Shared resource usage
– Etc.
 Software Architecture
styles
• Architecture styles - A set of design rules that identify the
kinds of components and connectors that may be used to
compose a system or subsystem, together with local or
global constraints on the way the composition is done’
• Architectural Styles of Software Systems:
– Repository-Subsystems access and modify data from a
single data structure called the repository.
– Pipe and Filter-
• Case Study of Compiler Architecture
• architectural style to divide a larger processing task into a
sequence of smaller, independent processing steps (Filters) that
are connected by channels (Pipes).
– Object-Oriented- focused on modeling a business domain
and defining business objects based on entities within the
business domain.
Software Architecture
styles
– Implicit Invocation-
• instead of invoking a procedure directly, a
component can announce (or broadcast) one or
more events.
• Other components in the system can
register an interest in an event by
associating a procedure with the event.
• When the event is announced the system
itself invokes all of the procedures that have
been registered for the event.
• Thus an event 'implicitly' causes the
invocation of procedures in other modules."
Software Architecture
styles
– Layered
• A layered system is organized hierarchically, each
layer serving the layer above. In some systems, inner
layers are hidden in all but the adjacent outer layer.
– Interpreter
– Process-Control
– Client/Server
 Can a system have
more that one
• structure?
Yes, no one structure holds the claim to
being the architecture.
• Below are some examples of structures:
– Module decomposition
– Objects and message passing at runtime
– Build dependencies
– Etc.
Does Every System have
an Architecture?
• Yes.
• For small systems the architecture
may be trivial.
• For large systems it definitely
exists in the software product, but
may not have been documented.
Why is Software Architecture
Important?
• Communication among stakeholders:
– Customers, managers, designers, programmers.

• Documentation of early design decisions:

– Constraints on implementation
– Organizational structure
– Guides evolutionary prototyping

• Transferable abstraction of a system to

similar systems (reuse):
– Program families share a common architecture
– Architecture can be the basis for training.
Architectural Structures
(Module)
• Components: work Structure
assignments.
– Work assignments have products
associated with them:
• Interface specifications
• Code
• Test plans, etc.
• Relations: is-a-submodule-of
• Use: Allocating a project’s labor
and other resources during
development and maintenance.
 Considerations in
Architectural Structures
• Conceptual and logical structures:
Abstractions of the system’s functional
requirements. - shares-data-with. It is
important for understanding the
interactions between units.
• Process or Coordination Structure:
Modeling dynamic aspects of a running
system. Synchronizes-with, Can’t-run-
without and Can’t-run-with. Processes
and threads
Architectural Structures
… Cont..
• Physical Structure: Hardware
(computers, networks, etc.).
“communicates-with”. Create models to
reason about performance, availability,
security, etc.
• Uses Structure: procedures or
modules. “assumes-the-correct-
presence-of”. For modeling system
extendibility and incremental system
building (e.g., Makefile dependencies).
 Architectural
• CallsStructures .. Cont..
Structure. “Procedures”. Used to
model trace of execution in a program.
• Data Flow Structure Programs or
modules. “ transmits-data-to”. Used to
model data transmission which can aid
requirements traceability.
• Class Structure. classes and
interfaces. “inherits-from, implements”.
Used to model collections of similar
behavior and parameterizes differences.
 The Importance of
Structures
• Structures are important because
they “boil away” details about the
software that are independent of
the concern reflected by the
abstraction.
• Each structure provides a useful
perspective of the system.
• Sometimes the term view is used
instead of structure.
Abstraction
 Modeling Views
• Modeling system architectures is
best done using multiple
concurrent views

• Individual views divide the

complexity, and create artifacts
that separately address the
concerns of different stakeholders
Lines and Component
Representation
• Software architecture and design
documentation is often modeled using
components and line diagrams
• Modelers often struggle with:
– What do the lines and components represent?
– Do the lines and boxes represent the same
abstractions from one model to another?
– Do models developed by more than one
individual have the same meaning for the
lines and components?
– Is the goal of the model clear - are the lines
network messages, procedure calls, or
structural relationships? – are the boxes
functions, classes, components, servers, etc.
 Abstraction (Cont’d)

• Early 1950s: Software was

written in machine language:
– programmers placed instructions and
data individually and explicitly in the
computer’s memory
– insertion of a new instruction in a
program might require hand
checking the entire program to
update references to data and
instructions
Requirements for Modeling SW
Architectures

• Use multiple views, each view

addressing one specific set of
concerns
• Organize the views into
categories, with each category
being specifically targeted to be
used by a different constituency
• Use consistent notation for the
individual views
 Programming
Languages
• Late 1950s: The emerging of the
first high-level programming
languages. Well understood patterns
are created from notations that are
more like mathematics than machine
code.
– evaluation of arithmetic expressions
– procedure invocation
– loops and conditionals
 The 4+1 View Model
Architects Developers

Development
Logical View
View

Business
Scenarios Analysts

Process View Physical View

Integrators Infrastructure
Engineers

• Each view is consumed by a different

stakeholder
 Abstract Data Types

• Late 1960s and 1970s: Programmers

shared an intuition that good data
structure design will ease the
development of a program.
• This intuition was converted into
theories of modularization and
information hiding.
– Data and related code are encapsulated into
modules.
– Interfaces to modules are made explicit.
Software Architecture
Issues
• Organization and global control
structure.
• Protocols of communication,
synchronization, and data access.
• Assignment of functionality to design
elements.
• Physical distribution of data and
processes.
• Selection among design alternatives.
 The Architecture
Widgets
The “Widgets” of Architecture Connector Interface

Component A Connector Component B

• Each view is expressed using a set of

elements and connectors
• Each view can be guided by using patterns
or architectural styles to introduce
constraints on downstream design artifacts
• Each view is developed taking the
appropriate set of requirements into mind
• Each view might use different notation that
is most appropriate for the view
 Logical View
The Logical View
• This view expresses the key abstractions from
the problem domain
– Classes, Components
• Think in terms of the services that the system
will provide to the user
• Express the relationships between the logical
components
– Use, generalize, aggregate
• Define the important interfaces of the
components and connectors associated with
this view
 Logical View
The Logical View
• Choose a “style” for the logical view
– Object-oriented style
– Component style
– Service-oriented style
• The style helps define the structure
and semantics of the elements
captured in the logical view
 Process View
The Process View
• The process view takes into account
non-functional requirements such as
performance, availability
• This view also deals with concurrency,
showing the different threads of
control
– Intra-process threads
– Inter-process coordination (messages to
and from different servers)
 Process View
The Process View
• A “process” in the process view
groups tasks into logical execution
units. Execution units have a:
– Well defined point where they start and
stop as well as rule for dealing with
exceptions to the normal course of
operation
• Possible styles for the process
views:
– Client/Server, MVC, pipe and filter.
 Process View
The Process View
• Components for the process view
include:
– Processes and threads
• Connectors include
– Messages, shared memory, pipes
 The DevelopmentDevelopment
View View

• The development view defines the actual

software modules to be constructed
• The granularity of the components in
this view should be at the level where
they can be implemented by one or a
small set of developers
– Classes, Packages, Subsystems
• This view should clearly define the
import and output relations
– We will hear more about this later when we
talk about provided and required
interfaces…
 The DevelopmentDevelopment
View View

• Connectors for the development

view may include:
– Function/procedure calls, inheritance,
includes, uses, etc.
• Styles for the development view
include the layer style
– Subsystems, components,
modules/classes, functions/procedures
 The +1 View -
Scenarios Scenarios

• Scenarios are abstractions of the

most important requirements
• Map closely to use cases
• Ties the other views together
• The scenario view is redundant to
the other views (+1) but is a cross-
cutting aspect tying the
architecture together
 The +1 View -
Scenarios Scenarios

• Why scenarios:
– A mechanism to discover the key
architectural elements and
connectors
– Validation of the architecture design
after the other views are created
– Addresses the concerns of both the
functional and non-functional
requirements
 State of Practice
• There is not currently a well-defined
terminology or notation to characterize
architectural structures.
• However, good software engineers make
common use of architectural principles
when designing software.
• These principles represent rules of thumb
or patterns that have emerged informally
over time. Others are more carefully
documented as industry standards.
 Architectural Styles
of Software Systems
Style
An architectural style represents a family of
related systems
Defines the design vocabulary (and
constraints) for the components, connectors,
ports, roles, bindings and properties.
Architectural Styles of
Software Systems
• An Architectural Style defines a family
of systems in terms of a pattern of
structural organization. It determines:
– the vocabulary of components and
connectors that can be used in instances of
that style
– a set of constraints on how they can be
combined. For example, one might
constrain:
• the topology of the descriptions (e.g., no cycles).
• execution semantics (e.g., processes execute in
parallel).
 Determining an
•
Architectural Style
We can understand what a style is by
answering the following questions:
– What is the structural pattern?
(i.e., components, connectors, constraints)
– What is the underlying computational
model?
– What are the essential invariants of the
style?
– What are some common examples of its use?
– What are the advantages and
disadvantages of using that style?
– What are some of the common
specializations of that style?
 Repository Style

• Suitable for applications in which

the central issue is establishing,
augmenting, and maintaining a
complex central body of information.
• Typically the information must be
manipulated in a variety of ways.
Often long-term persistence is
required.
 Repository Style
(Cont’d)
• Components:
– A central data structure representing
the current state of the system.
– A collection of independent
components that operate on the
central data structure.
• Connectors:
– Typically procedure calls or direct
memory accesses.
 Repository Style
(Cont’d)
Memory Access

Computation

Shared Data

Memory
 Repository Style
Specializations
• Changes to the data structure
trigger computations.
• Data structure in memory
(persistent option).
• Data structure on disk.
• Concurrent computations and data
accesses.
 Repository Style
Examples
• Information Systems
• Programming Environments
• Graphical Editors
• AI Knowledge Bases
• Reverse Engineering Systems
 Repository Style
Advantages
• Efficient way to store large
amounts of data.
• Sharing model is published as the
repository schema.
• Centralized management:
– backup
– security
– concurrency control
 Repository Style
Disadvantages
• Must agree on a data model a
priority.
• Difficult to distribute data.
• Data evolution is expensive.
Object-Oriented Style

• Suitable for applications in which a

central issue is identifying and
protecting related bodies of information
(data).
• Data representations and their
associated operations are encapsulated
in an abstract data type.
• Components: are objects.
• Connectors: are function and
procedure invocations (methods).
 Object-Oriented Style (Cont’d)

object
obj obj

obj
obj

obj
obj

Me obj
th od
inv obj
oc
ati
o n
 Object-Oriented
Invariants
• Objects are responsible for
preserving the integrity (e.g.,
some invariant) of the data
representation.
• The data representation is hidden
from other objects.
 Object-Oriented
Specializations
• Distributed Objects
• Objects with Multiple Interfaces
 Object-Oriented
Advantages
• Because an object hides its data
representation from its clients, it
is possible to change the
implementation without
affecting those clients.
• Can design systems as collections
of autonomous interacting agents.
 Object-Oriented
Disadvantages
• In order for one object to interact with
another object (via a method invocation)
the first object must know the identity
of the second object.
– Contrast with Pipe and Filter Style.
– When the identity of an object changes, it is
necessary to modify all objects that invoke it.
• Objects cause side effect problems:
– E.g., A and B both use object C, then B’s
effects on C look like unexpected side effects
to A.
 Pipe and Filter
Architectural Style
• Suitable for applications that
require a defined series of
independent computations to be
performed on data.
• A component reads streams of
data as input and produces
streams of data as output.
 Pipe and Filter
Architectural Style
• (Cont’d)
Components: called filters, apply
local transformations to their input
streams and often do their computing
incrementally so that output begins
before all input is consumed.
• Connectors: called pipes, serve as
conduits or channels for the streams,
transmitting outputs of one filter to
inputs of another filter.
 Pipe and Filter
Architectural Style
filter
(Cont’d)

pipes
 Pipe and Filter
Invariants
• Filters do not share state with
other filters.
• Filters do not know the identity
of their upstream or downstream
filters.
 Pipe and Filter
Specializations
• Pipelines: Restricts topologies to
linear sequences of filters.
• Batch Sequential: A degenerate
case of a pipeline architecture
where each filter processes all of
its input data before producing
any output.
 Pipe and Filter
Examples
• Unix Shell Scripts: Provides a notation
for connecting Unix processes via pipes.
– cat file | grep Erroll | wc -l
• Traditional Compilers: Compilation
phases are pipelined, though the phases
are not always incremental. The phases
in the pipeline include:
– lexical analysis + parsing + semantic
analysis + code generation
 Pipe and Filter
Advantages
• Easy to understand the overall
input/output behavior of a system as
a simple composition of the
behaviors of the individual filters.
• They support reuse, since any two
filters can be hooked together,
provided they agree on the data that
is being transmitted between them.
 Pipe and Filter
Advantages (Cont’d)
• Systems can be easily maintained
and enhanced, since new filters can be
added to existing systems and old filters
can be replaced by improved ones.
• They permit certain kinds of
specialized analysis, such as
throughput and deadlock analysis.
• The naturally support concurrent
execution.
 Pipe and Filter
Disadvantages
• Not good choice for interactive
systems, because of their
transformational character.
• Excessive parsing and unparsing
leads to loss of performance and
increased complexity in writing
the filters themselves.
 Client-Server Style
• Suitable for applications that involve
distributed data and processing across
a range of components.
• Components:
– Servers: Stand-alone components that
provide specific services such as printing,
data management, etc.
– Clients: Components that call on the
services provided by servers.
• Connector: The network, which allows
clients to access remote servers.
 Client-Server Style

Client 1 Client 2 ... Client N

Network

File Server Database Server Object Server

 Client-Server Style
Examples
• File Servers:
– Primitive form of data service.
– Useful for sharing files across a
network.
– The client passes requests for files
over the network to the file server.
 Client-Server Style
Examples (Cont’d)
• Database Servers:
– More efficient use of distributing
power than file servers.
– Client passes SQL requests as
messages to the DB server; results are
returned over the network to the
client.
– Query processing done by the server.
– No need for large data transfers.
– Transaction DB servers also available.
 Client-Server Style
Examples (Cont’d)
• Object Servers:
– Objects work together across
machine and network boundaries.
– ORBs allow objects to communicate
with each other across the network.
– IDLs (Interactive Data Language)
define interfaces of objects that
communicate via the ORB.
– ORBs are the evolution of the RPC.
 RPCs Versus ORBs

Client Server
Client Server
Object X Object Y
Code Data call foo call foo Data Data
call foo on on
Object X Object Y Code Code
execute foo

RPC Mechanism Object Request Broker

1) Remote Procedure Call (RPC) 2) Object Request Broker

 Client-Server
Advantages
• Straightforward distribution of
data.
• Transparency of location.
• Mix and match heterogeneous
platforms,
• Easy to add new servers or
upgrade existing servers.
 Client-Server
Disadvantages
• Performance of the system depends
on the performance of the network.
• Tricky to design and implement C/S
systems.
• Unless there is a central register of
names and services, it may be hard
to find out what services are
available.
 Reading
• Implicit Invocation Style
• Layered Style
• Interpreter Style
• Process-Control Style
 Implicit Invocation
Style
• Suitable for applications that involve
loosely-coupled collection of
components, each of which carries out
some operation and may in the process
enable other operations.
• Particularly useful for applications that
must be reconfigured “on the fly”:
– Changing a service provider.
– Enabling or disabling capabilities.
 Implicit Invocation
Style (Cont’d)
• Instead of invoking a procedure
directly ...
– A component can announce (or broadcast)
one or more events.
– Other components in the system can register
an interest in an event by associating a
procedure with the event.
– When an event is announced, the
broadcasting system (connector) itself
invokes all of the procedures that have been
registered for the event.
 Implicit Invocation
Style (Cont’d)
• An event announcement “implicitly”
causes the invocation of procedures in
other modules.
procedure procedure procedure

Broadcasting System
 Implicit Invocation
Invariants
• Announcers of events do not know
which components will be affected by
those events.
• Components cannot make
assumptions about the order of
processing.
• Components cannot make
assumptions about what processing
will occur as a result of their events
(perhaps no component will respond).
 Implicit Invocation
Specializations
• Often connectors in an implicit
invocation system include the
traditional procedure call in
addition to the bindings between
event announcements and
procedure calls.
 Implicit Invocation
Examples
• Used in programming
environments to integrate tools:
– Debugger stops at a breakpoint and
makes that announcement.
– Editor responds to the announcement
by scrolling to the appropriate source
line of the program and highlighting
that line.
 Implicit Invocation
Examples (Cont’d)
• Used to enforce integrity
constraints in database
management systems (called
triggers).
• Used in user interfaces to
separate the presentation of data
from the applications that manage
that data.
 Implicit Invocation
Advantages
• Provides strong support for reuse since
any component can be introduced into
a system simply by registering it for the
events of that system.
• Eases system evolution since
components may be replaced by other
components without affecting the
interfaces of other components in the
system.
 Implicit Invocation
Disadvantages
• When a component announces an
event:
– it has no idea what other components
will respond to it,
– it cannot rely on the order in which
the responses are invoked
– it cannot know when responses are
finished
 Layered Style

• Suitable for applications that involve

distinct classes of services that can be
organized hierarchically.
• Each layer provides service to the layer
above it and serves as a client to the
layer below it.
• Only carefully selected procedures from
the inner layers are made available
(exported) to their adjacent outer layer.
Layered Style (Cont’d)

• Components: are typically

collections of procedures.
• Connectors: are typically
procedure calls under restricted
visibility.
 Layered Style (Cont’d)

Useful System

sets of
procedures
Basic Utilities

Core Layer

procedure
calls
 Layered Style
Specializations
• Often exceptions are made to
permit non-adjacent layers to
communicate directly.
– This is usually done for efficiency
reasons.
Layered Style Examples

• Layered Communication
Protocols:
– Each layer provides a substrate for
communication at some level of
abstraction.
– Lower levels define lower levels of
interaction, the lowest level being
hardware connections (physical layer).
• Operating Systems
– Unix
 Unix Layered Architecture

System Call Interface to Kernel

Plain Cooked
Socket
File Cooked Raw Raw TTY
Block Block TTY
File Interface Interface Interface Line
Protocols System Disc.

Network
Block Device Driver Character Device Driver
Interface

Hardware
 Layered Style
Advantages
• Design: based on increasing
levels of abstraction.
• Enhancement: Changes to the
function of one layer affects at
most two other layers.
• Reuse: Different implementations
(with identical interfaces) of the
same layer can be used
interchangeably.
 Layered Style
Disadvantages
• Not all systems are easily
structured in a layered fashion.
• Performance requirements may
force the coupling of high-level
functions to their lower-level
implementations.
 Interpreter Style

• Suitable for applications in which

the most appropriate language or
machine for executing the solution
is not directly available.
 Interpreter Style
(Cont’d)
• Components: include one state machine
for the execution engine and three
memories:
– current state of the execution engine
– program being interpreted
– current state of the program being interpreted
• Connectors:
– procedure calls
– direct memory accesses.
 Interpreter Style (Cont’d)
Memory

Current State
inputs Program
of
Being
Program Being
Interpreted
Interpreted

Computation
State Machine store

selected
outputs instruction Current
Execution State of
Engine Execution
Selected Engine
data (fetch)
 Interpreter Style
Examples
• Programming Language
Compilers:
– Java
– Smalltalk
• Rule Based Systems:
– Prolog
– Coral
• Scripting Languages:
– Awk
– Perl
 Interpreter Style
Advantages
• Simulation of non-implemented
hardware.
• Facilitates portability of
application or languages across a
variety of platforms.
 Java Architecture

Java Bytecode
Source Verifier
Code
Class
Loader

Java Interpreter
Compiler

INTERNET Run-time
Environment

Java Hardware
Bytecode
 Interpreter Style
Disadvantages
• Extra level of indirection slows
down execution.
• Java has an option to compile
code.
– JIT (Just In Time) compiler.
Technologies for Distributed
Architectures
 IBM’s MQSeries

• MQSeries provides application-

programming services that enable
programs to communicate with
each other in a distributed fashion
using messages and queues.
• This kind of communication is
called asynchronous messaging.
 IBM’s MQSeries
(Cont’d)
• The MQSeries software enables
applications to exchange information
across more than 25 different
operating system platforms.
• This flexibility allows MQSeries
applications to run on hardware
ranging from modest desktops to
high-end mainframe computers.
MQSeries Components

• Queue Managers manage one or more

queues and ensure that messages are put
on the correct queue or that they are
routed to another (remote) queue
manager.

• Applications must make a successful

connection to a queue manager before
they can put or get messages to or from a
queue.
MQSeries Applications

• An application can only connect to

one queue manager at a time.
• Before an application can use a
queue, it must open a queue for
putting, getting, or both putting
and getting messages.
 MQSeries Queued
Messages
• A queued message consists of two
parts:
– The first part includes application-
specific data contained in a buffer.
– The second part includes control
information, such as a message type,
destination, and various other
options.
 Programs Communicating via a
Queue on the Same Workstation

Queue Manager
put get
A B

Queue
 Programs
Communicating via a
•
Queue on the Same
Figure illustrates two programs A and B
Workstation
that are communicating
managed message queue.
through a

• In this example, A, B, and the queue

manager are all executing on the same
workstation.
• The communication between the
programs is conducted through a queue
onto which program A puts messages and
from which program B gets messages.
 Programs Communicating via a
Queue on Different Workstations
Queue Manager
put
A

Transmission Queue

Channel

Queue Manager
get
B
Queue
 Programs
Communicating via a
• Queue
Figure on two
illustrates Different
programs A
and B that are communicating
Workstations
through a managed message queue.
• A,B are executing on different
workstations.
• Program A puts a message onto the
queue, specifying not a local queue
but a local definition of a remote
queue.
 Programs
Communicating via a
Queue on Different
• The local queue definition identifies a non-
Workstations
local queue that is managed by another
queue manager.
• The queue manager, to which program A
is connected to, puts the message on a
special queue called a transmission queue.

• The message is then automatically sent

along a defined channel that connects the
two queue managers.
 Programs
Communicating via a
• IfQueue
for some on Different
reason the channel is
Workstations
not active (possibly due to a
network failure) the message
remains on the transmission
queue.
• The message will be sent
automatically when the channel is
available again.
 Programs
Communicating via a
Queue
• The on Different
destination queue manager
Workstations
puts the message on the queue
that is specified by program A.
• Once a message is placed on the
destination queue, the queue
manager can invoke program B
automatically and B can then get
the queued message.
 Using MQSeries to Create a Server that
Handles a Single Service S1

Trigger
Client
Request Queue
Manager
(QM) S1

Data
(Response)
R
 Scaling-Up to Multiple Queues
and Services
Q1
Trigger

Q2 S1
Client Data
Requests Trigger (Response)
Queue
Manager S2
(QM)
Data
R (Response)
Q3

S3
Trigger
 CORBA
• The Common Object Request
Broker Architecture (CORBA) is a
standard defined by the Object
Management Group (OMG) that
enables software components written
in multiple computer languages and
running on multiple computers to
work together (i.e., it
supports multiple platforms)
 CORBA Messages

• Distributed objects in a CORBA

system communicate by sending
messages to each other.
• These messages, however, are not
queued, as is the case with
MQSeries.
 CORBA Skeletons

• The skeleton code transforms the

call and parameters into the
required implementation-specific
format before calling the object.
 CORBA Platform
Independence
• The client is unaware of the
CORBA object’s location,
implementation details, and which
ORB is used to access the object.
• The connections between
distributed objects are managed
through a name server.
 CORBA IDL and IIOP

• The client may only invoke

methods that are specified in the
CORBA object’s interface.
• Object interfaces are defined
using OMG’s Interface Definition
Language (IDL).
• Different ORBs communicate via
the Internet InterORB Protocol
(IIOP).
 Server Objects in
CORBA
• The server side ORB receives the request
over a network connection and then
determines which of the objects on its
machine is the target.
• When the ORB locates the object, it must
prepare it to receive the request. E.g.,
– Start a server process that contains the
object.
– Retrieve the object from persistent storage.
Hiding Services Behind an
Object Adapter
S1 S2 S3 S4

Adapter
(CORBA OBJECT)

ORB
 Object Adapters in
CORBA
• The Figure shows how an adapter can
act as a proxy between a set of services
and the ORB.
• Clients will access each service through
the adapter that is responsible for that
service.
• The adapter will be responsible for
finding the appropriate filters to handle
each client request.
Object Adapters in CORBA
(Cont’d)
• These filters may be:
– on the same machine as the adapter,
– or may be on another machine, in
which case the adapter must
delegate the client request to another
adapter.
CORBA architecture
Client
objects

Server objects
Object
adapter

Object request broker core

Interface
CORBA services
repository