MSCS 6340

Component Architecture

Object-Oriented Distributed Component Software

Development based on CORBA

Outline
Component based software for distributed
applications
Component based software for real-time
distributed applications

Motivation for Software Components

Higher productivity demands software reuse
Shorten development cycle and cost
Reuse well-designed units: high performance, need less
resource, etc.
Reuse well-tested units: better reliability
Continuous need to upgrade and reintegrate of existing
software systems.

Motivation for Distributed

Component-Based Software Development
Distributed systems tend to be built using various software units.
Need a common representation of software units, a wrapping
entity is needed to ease the encapsulation of heterogeneous
software pieces in order to produce a homogeneous view for
integration
Objects are not enough for this purpose because they are
commonly defined in a closed environment.
Distributed Components with common interface
representation meet this requirement.
4

Existing Component Specification

JavaBeans
One of the two major component specifications of today:
Defined and dependent on Java language.
A Java software unit
Runs inside some container
Exposes its methods to its container
Communicates with its container through events
Cross-platform, but not cross-language
Lacks support of distributed integration
5

Existing Component Specification

Microsoft
Defined and dependent in Microsoft COM environment
Encapsulates various software components behind the
Windows32 API.
Still platform-specific to Microsofts Windows 95/NT/XP.
- COM on other platforms is incomplete
- ActiveX Control developing environment is
Windows-specific
- Assembly
6

Desirable Features of Distributed Components

To satisfy cross-platform, cross-language integration,
a software component needs :
Environment independent service access

Location transparent
Interface separate from implementation
Self-describing interface
Composibility

Using CORBA/DCOM as Component Bus

to Satisfy the Features
Specification is independent from hardware,

programming languages, O.S.

Naming Service/Monikers offer location
transparency
Interface Definition Language (IDL) separates
object interface from implementation
Interface Repository/Type Library supports
interface self-description of objects/components

Distributed Component Model at ASU

Additional Interfaces
Special Services

Exceptions

Component Common Interface

Changeable
Properties
Out-Events

Component
Objects

In-Events

States

Exceptions

Distributed Component Interfaces

Distributed component common interface
Interface publishing and retrieving
Event handling
Persistence state maintenance
Changeable properties support
Component replication interface
Run-time state retrieval and update
Exception handling against member crashes
Additional interfaces (expendable model), like real-time:
Real-time requirements specification
Exception handling against RT requirements fails
10

Distributed Component Integration

A distributed component can be developed by wrapping
a software unit with distributed common interfaces.
The next step is to compose distributed software from
components through integration.
The integration is an interactive process of the user with
an integration tool that understand distributed common
interfaces and can generate adapters to glue components
together.
11

Integration process of
distributed components

12

Functions of the Integration Tool

Visualize distributed components and their interfaces
Generate glue code --- component adapters
Modify changeable properties
Generate group adapters
Embed other special adapters into run-time environment
Component management
Import, Store, Deploy, Delete, Retrieve, Replicate
13

Functions of Component Adapter

Redirect invocations/events to proper server

components
Re-establish connections with other components in case
of temporary communication errors
Invoke exception handler when connection with related
components fail

14

An Example of Component Adapter

Component/Adapter Pair Name=SC
SC
assign

IDL

Adapter.Req()
Adapter.Req()

TC
IDL

Serv()
Serv()

A1.Req()
A1 Adapter

TC.Serv()

Connection table

method
Req()

target method
TC Serv()

assign

15

State Consistency of Replicated

Component Group
A group of replicated distributed components make

software fault-tolerant against member crash, partial

network down.
These replicas must maintain state consistency to offer
consistent and continuous services just like one component.
Group Adapter to make state consistency maintenance
transparent to component designers and software
developers.
16

State Consistency Maintenance between

Group Adapters
Outgoing events
only from prime GA

Group
Adapter
Prime GA2.1

for
wa
rd

Component
Component
IDL
C3
C3

Incoming
Component
Component
Group
IDL
events
C1
C1
Adapter
GA2.2

Component
Component
IDL
C2.2
C2.2

Component
Component
IDL
C2.1
C2.1

negotiate/
update states
broadcast

Group
Adapter
GA2.3
Component
Component
IDL
C2.3
C2.3

17

Implementation issues
a prototype distributed component-based
software development environment on Orbix/OrbixWeb 3.0
CORBA
Distributed Component Model: defined in OMG IDL 2.0
Integration Tool: developed using Java, tested on
Windows 95/NT/Solaris
Example Distributed Components: on both Windows/Solaris,
using C++/C/Java

18

Implementing the Integration Tool

19

Cross-Platforms and Cross-Languages

Support of ASUs Approach

20

Other Advantages of the Approach

Ease of reuse legacy systems: Component wrapping,

Gateway components
Dynamic Self-explaining Service Publishing
Composibility/Location Transparency: Adapters
Ease of fault-tolerant server implementation:
Group Adapters
Ease of distributed component management
21

Future Work
Implement the approach based on real-time operating

systems ( like VxWorks) and real-time CORBA to

support real-time application software development.
Component semantic interfaces, like GUI control
interface to support distributed GUI components
integration.
Component retrieval: formal description, intelligent
component repository
22

Disadvantages of
IBM Component Broker
No fault-tolerance support
Not expandable: for example, real-time support
IBM dependency: The CB requires its own Object
Builders IDL compiler to generate component
interfaces. This may force migration from popular
CORBA products like Orbix. Our approach works with
all ORB-compliant products.

23

Advantages of
IBM Component Broker
CBs advantages come from its better implementation:
Security on component communication
Pre-developed legacy application adapters: DB2,
CICS, Encina, IMS, MQSeries
More component management: Monitoring, logging
Certain capability to import information from some
CASE tools, like Rational Rose.
24

Approach to Distributed Component

Development and Integration
Wrap software units with common interfaces defined
in a Distributed Component Model for services
publishing, fault-tolerance;
Integrate distributed components together using an
interactive integration tool with transparent glue code
generation;
Use component adapters in Distributed Object
Middleware as the run-time environment
25

The Distributed Component-based

Development Process
User Requirement
Analysis
Component
Modeling
Technology

Decomposition

Legacy Software Reusing Existing

Wrapping
Components

Components
acquisition

Components
Development

Process
Management

Distributed
Integration
Component
Repository
Server

Executing/Testing

26

Distributed Component-Based
Software Architecture

27

Desirable Features of Distributed Components

To satisfy cross-platform, cross-language integration,
a software component needs :
Environment independent service access

Location transparent
Interface separate from implementation
Self-describing interface
Composibility

28

Using CORBA/DCOM as Component Bus

to Satisfy the Features
Specification is independent from hardware,

programming languages, O.S.

Naming Service/Monikers offer location
transparency
Interface Definition Language (IDL) separates
object interface from implementation
Interface Repository/Type Library supports
interface self-description of objects/components

29

Component-based approach
for real-time software

30

Distributed Component-Based Software Architecture

Wrapped Legacy Software

Replicated Components
SubComponent

SubComponent

Gateway
Component

Common Object Environment

Common Object Services
31

Distributed Real-time Component Architecture

Real-time Interface
RT requirements

Exceptions

C om m o n Interface

Changeable
Properties
Out-Events

Component
Objects

In-Events

States

Exceptions

32

Distributed Component Interfaces

Distributed component common interface
Interface publishing and retrieving
Event handling
Persistence state maintenance
Changeable properties support
Component replication interface
Run-time state retrieval and update
Exception handling against member crashes
Real-time specification interface
Real-time requirements specification
Exception handling against RT requirements fails
33

Distributed Component Integration

Using an integration tool that understands distributed common
interfaces and can generate adapters to glue components
together.
Visualize the distributed components and their interfaces
Generate component adapters
Modify properties
Generate group adapters
Embed real-time request monitor and scheduler into
the adapter

34

Real-time requests through Monitor/Scheduler

RT Component
RT Adapter
RT Monitor

RT Component
RT Adapter
RT Scheduler
Request Queue
...
35

Implementation issues
Distributed Component Interfaces
Every component implements ComponentInfo interface
to skeptically describe its interfaces;
Details interface syntax will be retrieved accordingly from
interface repository.
IDL files of each components are released with the component
as a package. So interface repository entry can be established
wherever the component runs.

36

Implementation issues ( Cont. )

Integration Tool
Adapter
Adapters are separate processes to the components residing
on the same hosts.
Adapters use Dynamic Skeleton Interface to accept requests
and Dynamic Invocation Interface to relay them. This
allows two methods in different interfaces to be connected.

37

Implementation issues ( Cont. )

Integration tool: (Cont.)
Handling soft real-time requests:
Real-time monitor times every real-time calls locally
Real-time adapters run at a high priority
Multi-threading the adapters of real-time server components
to reduce request acceptance time.
Real-time scheduler sorts requests according to emergency.

38

An Example: Component Architecture of a Simple

Airlines Reservation System
This system includes:
Client consoles that can accept requests from end users and send
requests to two travel agents that are in different locations. The
client may specify real-time requirements like the response time of
each request.
Agents carry out clients requests and show the flights information
to clients
Airlines handle query and reservation requests from agents. In
order to offer continuous services, it should have fault-tolerance
support
39

Component Architecture of a simple

Airlines Reservation System
A

10

Yahoo

Query

Name WaitTime Query

Client
Java/NT
enpc978

True

Query

Name IsDiscount

Reservation
Reservation
Discount
Reservation

Reservation

Agent
C++/NT

UA

Discount
Reservation

enpc666

Query

Name

Airline
B

MSN

False

Query
Discount
Name WaitTime Query Reservation Name IsDiscount
Reservation
Query
Reservation
Reservation
Discount
Java/NT
C++/NT Reservation

Client

Agent

enpc667

enpc665

enws631
Reservation
enws632

C++/Solaris

40

Discussions
Advantages of the approach:
Easy to satisfy the heterogeneous environments requirements in
many distributed systems
Easy to upgrade and reintegrate existing distributed
real-time systems.

41

Discussions (Cont.)
Limitations:
Component-based software method introduces overhead
with extra communication relays through adapters and group
communication.
In the current implementation, the real-time control is in
adapters which run in separate processes.
The communication time between components and
their adapters depend on the operating systems scheduling.
So this implementation does not support
hard real-time requirements.
42