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 used to implement software fault tolerance. Time redundancy Algorithm redundancy or Design

Diversity Data redundancy

Redundancy in some form is Our Research Focus is on: fault 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 object-oriented programming can be incorporated at three levels of granularity:

1. Redundant methods,2. Redundant homogeneous objects, or3. 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

Standard SFT techniques using Design Diversity are: N-Version Programming (NVP) Recovery Block (RB)

We will focus on: Design Diversity are: N-Version Programming (NVP) Recovery Block (RB)

NVP Scheme

Vi = Variants

V1 V2 V3 V4 Vn

Decision

Adjudicator

INPUTS Parallel Invocatio

ns

Exception raised

Output Selected

Majority vote

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

MYVariant

Variant Reusable Object

Variant

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.

AcceptanceTest

Voter

Adjudicator

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 NVP()

Variant[] 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

ORB

Skeleton

STUB

Machine A Machine B

Client

HelloSayhello()

ByeSaybye()

ObjectX Interface Hello

{

void Sayhello();

}

Defines the remote methods that can be invoked from a client.

Remote Invocation

Hello h = new Hello();

h.sayhello();

Object Implementations

The “GLUE”: does paramater marshalling/unmarshalling

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 functionality of the

interfaces

Compile the byte-code

Implement the client

side

Start the naming service

Start the server and the client application

Implement the server

side

IDL skeletons

Compile IDL

CORBA APPLICATION DEVELOPMENT STAGES

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

FTComponent

F() {

…

}

Adjudicator

F2() {

…

}

Variant

F1() {

…

}

Variant

Fn() {

…

}

Variant

Client Server1 Server2 Servern

invocation

Return value

4. Callbacks with Return values

2. Asynchronous

invocations

1. Invocation on object

3. Execution

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.

FTComponent

F() {

…

}

Adjudicator

F2() {

…

}

Variant

F1() {

…

}

Variant

Fn() {

…

}

Variant

Client Server1 Server2 Servern

invocation

Return value Network Error

invocations

Server Failure

Waits for N results or timeout T.

Callback

Callback

FTComponent

Data Members

AdjudicatorCallBack;

Variant[] v;

Functions

Init()

invoke()

AdjudicatorCallBack

adjudicator()

Variant

exec()

<<Interface>>

Abstract Class

<<Interface>>

2 ..*

Server

Client

1

Local

CORBA

object

Remote

CORBA

object

Must provide an Implementation to all interfaces and abstract methods

UML DIAGRAM

FTComponent

Data Members

AdjudicatorCallBack;

Variant[] v;

Functions

Init()

invoke()

AdjudicatorCallBack

adjudicator()

Variant

exec()

<<Interface>>

Abstract Class

<<Interface>>

2 ..*

Server

Client

1

Local

CORBA

object

Remote

CORBA

object

FTCOMPONENT contains 1 instance of the Callback Object.

FTCOMPONENT contains at least 2 remote Variants

UML DIAGRAM

FTComponent

Data Members

AdjudicatorCallBack;

Variant[] v;

Functions

Init()

invoke()

AdjudicatorCallBack

adjudicator()

Variant

exec()

<<Interface>>

Abstract Class

<<Interface>>

2 ..*

Server

Client

1

Local

CORBA

object

Remote

CORBA

object

Contains code to resolve all remote object references, and register the AdjudicatorCallBack with the local ORB

UML DIAGRAM

FTComponent

Data Members

AdjudicatorCallBack;

Variant[] v;

Functions

Init()

invoke()

AdjudicatorCallBack

adjudicator()

Variant

exec()

<<Interface>>

Abstract Class

<<Interface>>

2 ..*

Server

Client

1

Local

CORBA

object

Remote

CORBA

object

Contains code to invoke all remote Variants and wait for adjudicator callback or the timeout to occur

UML DIAGRAM

FTCORBA IDLModule FTCORBA { interface adjudicatorCallBack { void adjudicator(in …<param>); }; interface Variant { oneway void exec(in adjudicatorCallBack ref, in …

<param>); };};

Interface for CALLBACK Object

Interface for Remote Variants

FTCOMPONENT CLASSabstract 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