Constructing Reliable Software
Components Across the ORB
M. Robert Rwebangira
mrweba@scs.howard.edu
Howard University Future Aerospace Science
and Technology (HUFAST) Center
http://hufast.howard.edu
Overview






Overview of Software Fault tolerance
Fault tolerant Object-Oriented
Framework
Research Objectives
Overview of CORBA
Fault tolerant CORBA Framework
Conclusions and Future Work
What is Software Fault
tolerance (SFT) ?
Software fault tolerance is
concerned with techniques
necessary to enable a system
to tolerate software faults.
Examples:


Faults in the design
Faults in the construction of the
software itself.
SFT Implementation
Techniques
Redundancy in some form is
usedResearch
Our
to implement
Focussoftware
is on: fault
fault tolerance.
tolerance.



Time redundancy
Algorithm redundancy or Design
Diversity
Data redundancy
Design Diversity
Design Diversity Software Fault
tolerance techniques are
implemented using
Redundant Software Components


Versions, or
Variants
Object Oriented Redundancy
Redundancy in design of objectoriented programming can be
incorporated at three levels of
granularity:
1.
2.
3.
Redundant methods,
Redundant homogeneous objects, or
Redundant heterogeneous objects
designed from the same specification.
SFT Implementation
Techniques
A mechanism is used to decide
which of the “answers”
resulting from the redundancy
is “correct”.
Use an Adjudication Algorithm
Adjudication Techniques
An adjudicator decides on the
best “answer” from each
version; if one exists!
Examples:


Majority Vote – answers in the
majority win.
Acceptance test – is system and
programmer defined.
Design Diversity
Implementation
We will focus
Standard
SFT on:
techniques
Design using
Design Diversity
Diversity
are:
are:


N-Version Programming (NVP)
Recovery Block (RB)
NVP Scheme
INPUTS
V1
Vi = Variants
Majority vote
V2
V3
Parallel
Invocations
V4
Vn
Adjudicator
Decision
Exception raised
Output Selected
SFT Drawbacks



SFT techniques increase the software
complexity, causing the design of the fault
tolerant software itself to be error-prone.
There is no standard language structure for
various forms of SFT that could lead to a
systematic use of existing schemes
The development cost of SFT solution is
typically high.
SFT Approaches
[J. Xu, et al, 1995] proposed an
object oriented approach to the
problems of:



Controlling complexity,
Building abstraction, and
Cost reduction.
Abstract Model [J. Xu, et al, 1995]
A Fault tolerant component is composed
of three parts:
 Redundant variants of diverse design,
 an adjudicator, and
 a control.
Variant Class
The Variants deliver the same service
through independent designs
EX: SelectionSort, BubbleSort…
Variants can be new designs, or derived
from reusable components
Variant
MYVariant
Variant
Reusable Object
MYVariant
Adjudicator Class
The Adjudicator selects the result
produced by the variants
EX: majority Vote, acceptance Test
Voter and AcceptanceTest derive from
an Abstract Adjudicator Class.
Adjudicator
Voter
AcceptanceTest
Control Class
Control is in charge of the invocation of
the Variants.
Control determines the overall output of
the component with the aid of the
Adjudicator.
Control Class (cont)
The Control Class is an Abstract class
with the following attributes, and
functionality.
Attributes
Functions
Adjudicator
Variant[]
NVP()
RecoveryBlock()
Virtual Functions
A Derived class must provide an
implementation
Abstract Framework
Conceptually
Research Objectives
We extend the abstract framework to
facilitate and simplify the production of
reusable fault tolerant CORBA
components.
In particular, we present a design
pattern for constructing fault tolerant
CORBA objects.
What is CORBA?
The Common Object Request Broker
Architecture (CORBA) [OMG:95a] is an
emerging open distributed object
computing infrastructure being
standardized by the Object
Management Group (OMG).
CORBA Overview (cont)
CORBA provides a framework for
the development and execution
of distributed Object Oriented
applications.
CORBA is language and
Operating system independent.
CORBA Overview (cont)




CORBA provides the necessary
framework to automate many common
distributed programming tasks such as:
Registering an object,
Locating an object on the network,
Error handling, and
Parameter marshaling and unmarshaling.
CORBA Conceptually
Object Implementations
Hello h = new Hello();
h.sayhello();
Sayhello()
Hello
Bye
Client
Saybye()
ObjectX
Interface Hello
{
Remote Invocation
STUB
Machine A
The “GLUE”: does paramater
marshalling/unmarshalling
Skeleton
void Sayhello();
ORB
}
Machine B
Defines the remote methods
that can be invoked from a
client.
ORB Architecture


The Client is the entity that wishes
to perform an operation on the
object.
The Object Implementation is the
code and data that actually
implements the object.
ORB Architecture

The ORB is responsible for all of the
mechanisms required to



find the object implementation for the
request,
to prepare the object implementation
to receive the request,
and to communicate the data making
up the request.
CORBA IDL



Definitions of the interfaces to objects can be
defined using Interface Definition Language IDL.)
IDL stubs and skeletons are generated by an
IDL compiler.
CORBA IDL stubs and skeletons serve as the
“glue” between the client and server
applications, and the ORB.
Define the interfaces
in IDL
IDL stubs
Implement
the client
side
Compile IDL
Implement the
functionality of the
interfaces
Compile the bytecode
CORBA
APPLICATION
DEVELOPMENT
STAGES
Start the naming
service
Start the server and
the client application
IDL
skeletons
Implement
the server
side
FTCORBA Abstract Model
A Fault tolerant CORBA component is
composed of three parts:
 Redundant REMOTE variants of
diverse design,
 an adjudicator, and
 a control.
FTCORBA Abstract
Framework Conceptually
Server A
Server B
Server Z
2. Asynchronous
Server
Client
1
Server2
Servern
invocations
FTComponent
invocation
F() {
1. Invocation
}
on object
F1() {
F2() {
…
…
}
}
Fn() {
…
3. Execution
}
…
Variant
Return value
Adjudicator
4. Callbacks with
Return values
Variant
Variant
Artifacts



Method invocations on remote Variants must
be asynchronous.  will not return results.
We need a way to return results
asynchronously to the client for adjudication
to take place.
Must consider DEADLOCK when failure of a
remote Variant, the network, or machine
occurs
Solutions




The IDL provides a oneway keyword that
provides for asynchronous remote method
invocation.
Results are returned asynchronously to the
client using a CALLBACK object.
CALLBACKs must be atomic (i.e. mutual
exclusion).
Deadlock is avoided by using a timer, that is
set to be the execution time of the longest
running remote variant; including the network
propagation delay and adjudication time.
Server Failure
Client
Server1
Server2
Servern
F1() {
F2() {
Fn() {
…
…
…
}
}
}
invocations
FTComponent
invocation
F() {
…
Callback
}
Variant
Variant
Callback
Return value
Network Error
Adjudicator
Waits for N results or timeout T.
Variant
Client
<<Interface>>
AdjudicatorCallBack
adjudicator()
1
AdjudicatorCallBack;
Variant[] v;
2 ..*
Must provide an
Implementation to all
interfaces and abstract
methods
Functions
Init()
invoke()
Server
UML DIAGRAM
Remote
CORBA
object
CORBA
object
Abstract Class
FTComponent
Data Members
Local
<<Interface>>
Variant
exec()
Client
<<Interface>>
AdjudicatorCallBack
adjudicator()
FTCOMPONENT contains 1
instance of the Callback
Object.
1
AdjudicatorCallBack;
Variant[] v;
Functions
Init()
2 ..*
FTCOMPONENT
contains at least 2
remote Variants
invoke()
Server
UML DIAGRAM
CORBA
object
Abstract Class
FTComponent
Data Members
Local
Remote
CORBA
object
<<Interface>>
Variant
exec()
<<Interface>>
AdjudicatorCallBack
Client
adjudicator()
1
AdjudicatorCallBack;
2 ..*
Variant[] v;
Functions
Init()
invoke()
Contains code to
resolve all remote
object references, and
register the
AdjudicatorCallBack
with the local ORB
Server
UML DIAGRAM
Remote
CORBA
object
CORBA
object
Abstract Class
FTComponent
Data Members
Local
<<Interface>>
Variant
exec()
<<Interface>>
AdjudicatorCallBack
Client
adjudicator()
1
AdjudicatorCallBack;
Variant[] v;
Functions
Init()
invoke()
Server
UML DIAGRAM
2 ..*
Contains code to
invoke all remote
Variants and wait for
adjudicator callback or
the timeout to occur
Remote
CORBA
object
CORBA
object
Abstract Class
FTComponent
Data Members
Local
<<Interface>>
Variant
exec()
FTCORBA IDL
Module FTCORBA {
interface adjudicatorCallBack {
Interface for CALLBACK Object
void adjudicator(in …<param>);
};
interface Variant {
oneway void exec(in adjudicatorCallBack ref, in … <param>);
};
Interface for Remote Variants
};
FTCOMPONENT CLASS
abstract class FTCOMPONENT {
protected Variant v[] = null; // used to reference the remote variants
protected long timeout = 0; // timeout used to avoid DEADLOCK
protected AdjudicatorCallBack adj = null // reference to CALLBACK obj
public FTCOMPONENT (long t) {
timout = t;
init();
}
public FTCOMPONENT() { init(); }
public abstract void init(); // must implement
public abstract void invoke(); // must implment
}
Conclusion



We presented a design pattern for
constructing fault tolerant CORBA objects.
In particular, we show how to develop design
diverse CORBA objects using the NVP
approach.
Our method is not transparent to the
programmer. (Must consider the
occurrence of deadlock).
Future Work




To conduct experiments to measure
the performance of FTCORBA objects.
Investigate other CORBA services to
handle asynchronous messages.
Use design pattern in conjunction with
transparent ORB-level fault tolerant
strategies.
Implement Recovery Block scheme