1. 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

2. Overview  Overview of Software Fault tolerance  Fault tolerant Object-Oriented Framework  Research Objectives  Overview of CORBA  Fault tolerant CORBA Framework  Conclusions and Future Work

3. 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.

4. 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

5. Design Diversity Design Diversity Software Fault tolerance techniques are implemented using Redundant Software Components  Versions, or  Variants

6. 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, or 3. Redundant heterogeneous objects designed from the same specification.

7. SFT Implementation Techniques A mechanism is used to decide which of the “answers” resulting from the redundancy is “correct”. Use an Adjudication Algorithm

8. 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.

9. 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)

10. NVP Scheme V i = Variants V1V1 V2V2 V3V3 V4V4 VnVn Decision Adjudicator INPUTS Parallel Invocations Exception raised Output Selected Majority vote

11. 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.

12. SFT Approaches [ J. Xu, et al, 1995] proposed an object oriented approach to the problems of:  Controlling complexity,  Building abstraction, and  Cost reduction.

13. 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.

14. 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 VariantReusable ObjectVariant MYVariant

15. 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. AcceptanceTestVoter Adjudicator

16. 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.

17. Control Class (cont) The Control Class is an Abstract class with the following attributes, and functionality. AttributesFunctions Adjudicator NVP() Variant[] RecoveryBlock() Virtual Functions A Derived class must provide an implementation

18. Abstract Framework Conceptually

19. 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.

20. 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).

21. CORBA Overview (cont) CORBA provides a framework for the development and execution of distributed Object Oriented applications. CORBA is language and Operating system independent.

22. 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.

23. CORBA Conceptually ORB Skeleton STUB Machine A Machine B Client Hello Sayhello() Bye Saybye() 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

24. 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.

25. 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.

26. 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.

27. 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

28. FTCORBA Abstract Model A Fault tolerant CORBA component is composed of three parts :  Redundant REMOTE variants of diverse design,  an adjudicator, and  a control.

29. FTCORBA Abstract Framework Conceptually Server A Server B Server Z

30. FTComponent F() { … } Adjudicator F 2 () { … } Variant F 1 () { … } Variant F n () { … } Variant Client Server 1 Server 2 Server n invocation Return value 4. Callbacks with Return values 2. Asynchronous invocations 1. Invocation on object 3. Execution

31. 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

32. 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.

33. FTComponent F() { … } Adjudicator F 2 () { … } Variant F 1 () { … } Variant F n () { … } Variant Client Server 1 Server 2 Server n invocation Return value Network Error invocations Server Failure Waits for N results or timeout T. Callback

34. FTComponent Data Members AdjudicatorCallBack; Variant[] v; Functions Init() invoke() AdjudicatorCallBack adjudicator() Variant exec() > Abstract Class > 2..* Server Client 1 Local CORBA object Remote CORBA object Must provide an Implementation to all interfaces and abstract methods UML DIAGRAM

35. FTComponent Data Members AdjudicatorCallBack; Variant[] v; Functions Init() invoke() AdjudicatorCallBack adjudicator() Variant exec() > Abstract Class > 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

36. FTComponent Data Members AdjudicatorCallBack; Variant[] v; Functions Init() invoke() AdjudicatorCallBack adjudicator() Variant exec() > Abstract Class > 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

37. FTComponent Data Members AdjudicatorCallBack; Variant[] v; Functions Init() invoke() AdjudicatorCallBack adjudicator() Variant exec() > Abstract Class > 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

38. FTCORBA IDL Module FTCORBA { interface adjudicatorCallBack { void adjudicator(in … ); }; interface Variant { oneway void exec(in adjudicatorCallBack ref, in … ); }; Interface for CALLBACK Object Interface for Remote Variants

39. 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 }

40. 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).

41. 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