Constructing Reliable Software Components Across the ORB

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: • Redundant methods, • Redundant homogeneous objects, or • 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 INPUTS Parallel Invocations V1 V2 V3 V4 Vn Adjudicator Vi = Variants Exception raised Decision Majority vote Output Selected

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. VariantClass The Variants deliver the same service through independent designs EX: SelectionSort, BubbleSort… Variants can be new designs, or derivedfrom reusable components Variant Variant Reusable Object MYVariant MYVariant

15. Adjudicator Class The Adjudicator selects the result produced by the variants EX: majority Vote, acceptance Test Voter and AcceptanceTest derive from an AbstractAdjudicator Class. Adjudicator Voter AcceptanceTest

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 ControlClass is an Abstract class with the following attributes, and functionality. AttributesFunctions AdjudicatorNVP() 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 Object Implementations Hello h = new Hello(); h.sayhello(); Sayhello() Hello Saybye() Bye Client ObjectX Interface Hello { void Sayhello(); } Remote Invocation STUB Skeleton ORB Machine A Machine B Defines the remote methods that can be invoked from a client. The “GLUE”: does paramater marshalling/unmarshalling

24. ORB Architecture • The Clientis 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 Compile IDL IDL skeletons IDL stubs Implement the functionality of the interfaces Implement the client side Implement the server side Compile the byte-code CORBA APPLICATION DEVELOPMENT STAGES Start the naming service Start the server and the client application

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. Client Server1 Server2 Servern 2. Asynchronous invocations FTComponent F() { … } Adjudicator F1() { … } Variant F2() { … } Variant Fn() { … } Variant invocation 3. Execution 1. Invocation on object Return value 4. Callbacks with Return values

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 onewaykeyword 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. Server Failure Client Server1 Server2 Servern invocations FTComponent F() { … } Adjudicator F1() { … } Variant F2() { … } Variant Fn() { … } Variant invocation Callback Callback Return value Network Error Waits for N results or timeout T.

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

35. <<Interface>> Client Local CORBA object AdjudicatorCallBack adjudicator() Abstract Class FTComponent Data Members AdjudicatorCallBack; Variant[] v; Functions Init() invoke() FTCOMPONENT contains 1 instance of the Callback Object. 1 2 ..* FTCOMPONENT contains at least 2 remote Variants <<Interface>> Remote CORBA object Server Variant exec() UML DIAGRAM

36. <<Interface>> Client Local CORBA object AdjudicatorCallBack adjudicator() Abstract Class FTComponent Data Members AdjudicatorCallBack; Variant[] v; Functions Init() invoke() 1 2 ..* Contains code to resolve all remote object references, and register the AdjudicatorCallBack with the local ORB <<Interface>> Remote CORBA object Server Variant exec() UML DIAGRAM

37. <<Interface>> Client Local CORBA object AdjudicatorCallBack adjudicator() Abstract Class FTComponent Data Members AdjudicatorCallBack; Variant[] v; Functions Init() invoke() 1 2 ..* Contains code to invoke all remote Variants and wait for adjudicator callback or the timeout to occur <<Interface>> Remote CORBA object Server Variant exec() UML DIAGRAM

38. FTCORBA IDL Module 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

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