DEVS Based Modeling and Simulation of the CORBA POA

1. University of Corsica UMR CNRS 6134 DEVS Based Modeling and Simulation of the CORBA POA F. Bernardi, E. de Gentili, Pr. J.F. Santucci {bernardi, gentili, santucci}@univ-corse.fr

2. Studied Problem • Main Objectives of our Research • Modeling and simulation of the behavior of a computer object • Showing up a generic methodology for the modeling of this kind of objects • Selected Approach: DEVS Based Modeling and Simulation • Selected Application: CORBA Architecture (and especially the Portable Object Adapter)

3. Outline of the Presentation • DEVS Modeling Theory • Methodology for Algorithmic functions Modeling • The CORBA Portable Object Adapter (POA) • Example: the find_poa() Function • Results and Validation • Conclusion and Perspectives

4. DEVS Modeling Theory • The DEVS (Discrete EVent System Specification) Modeling and Simulation Approach: • Describes a system by components interconnection • Allows interactions between components using communication ports • Uses two types of components • Two Main Concepts: • Event: Information arrival on a port • Modeling and Simulation: Taking into account behavioral changings according to time or events

5. DEVS Modeling Theory • Components used for Modeling considering a Given System: • Atomic Models: Basic components that provide a local description of the dynamic behavior of the system • Coupled Models: Corresponds to a set of behavioral components that describes the manner a new component is created by interconnecting some others

6. DEVS Modeling Theory • An atomic model is defined by: • A set of input ports • A set of output ports • A set of state variables: define completely the states of the model • Two transition functions: allows to change the state variables • An exit function • A time advance function

7. DEVS Modeling Theory • Why DEVS ? • Long experience in our laboratory with many works based upon this approach • Already defined and satisfying tools • Great adaptation to discrete event systems such as computer programs • Original approach: Showing up a methodology for algorithmic functions modeling

8. Methodology for Algorithmic Functions Modeling • Basic Approach (starting from the source code): • Algorithmic functions are seen as coupled models • An atomic model represents the modeling of the behavior of the function between two calls to other external functions • Internal variables of the function are binded to state variables • Variables are carried through specialized ports as long as the function need them

9. Methodology for Algorithmic Functions Modeling • For a better understanding, we introduce three kinds of ports: • Sequencement Ports: used to carry the value of the state variables between two atomic models • Call Ports: used to carry the name of the function to be called • Parameter Ports: used to carry the parameters needed by a function

10. Methodology for Algorithmic Functions Modeling • Example of function: int f(a,b) { AM1 e = g(d); AM2 AM3 return e; }

11. Sequencement Ports Parameter Ports Call Ports Methodology for Algorithmic Functions Modeling CM1: f(a,b)  c Exception a AM1 AM2 AM3 b c f(a,b) g(d) d e AM4 CM2: g(d)  e

12. AM2 AM1 AM2 AM1 AM3 The « if » statement The « while » statement AM1 AM1 AM2 The « for » statement The « do » statement Methodology for Algorithmic Functions Modeling • Basic Control Structures Modeling

13. Methodology for Algorithmic Functions Modeling • Algorithmic function: Coupled model composed by the interconnection of atomic models • Application: Modeling of the CORBA Portable Object Adapter

14. The CORBA Portable Object Adapter (POA) • CORBA: Common Object Request Broker Architecture • Reference architecture for distributed systems • Many implementations available • Object-Oriented architecture (OMG) • Based upon many concepts such as: ORB, POA, servant, client,...

15. The CORBA Portable Object Adapter (POA) • The Portable Object Adapter (POA): • Interface between the server objects and the ORB • Connected to many servants (object implementing interfaces defined using the IDL language) • Identity an object using an OID (Object IDentificator) • Mapping with currently active objects performed using an Active Object Map (AOM) • Independent from the ORB implementation • Allows servants to assume complete responsibility for an object’s behavior

16. The CORBA Portable Object Adapter (POA) • Position of the POA in the CORBA Architecture Client Servant Requests Proxy POA ORB (Object Request Broker)

17. PortableServer::POA the_name : string … create_POA() find_POA() destroy() get_servant() … The CORBA Portable Object Adapter (POA) • The POA is defined as an object presenting 25 methods • For example: create_POA(), find_POA(), destroy()

18. Example: the find_poa() function • Returns a pointer to a POA adapter name • Can raise an exception (AdapterNonExistent) • Accepts two parameters (adapter, activate)

19. Example: the find_poa() function • C++ simplified source code POA_ptr find_poa(adapter, activate) { if (getDestroyed()) throw Exception; bool check=true; if (containsKey(adapter) && activate) { adapterActivator = getAdapterActivator(); if (adapterActivator != NULL) check = unknownAdapter(adapter); } POA poa; if (check) get(adapter, poa); if (poa == NULL) throw AdapterNonExistent; return poa; }

20. Example: the find_poa() function • Definition of the Coupled Model POA: • Input ports: adapter, activate children, poa_control (ORB) find_poa (Methodology) • Output ports: Exception, POA_ptr adapter Coupled Model find_POA() activate Exception children poa_control POA_ptr find_poa()

21. Example: the find_poa() function • Components: 10 atomic models • Links to 5 other coupled models • Minimal path (without exception): 6 atomic models • Maximum path (without exception): 10 atomic models

22. Results and Validation • Simulation using a software written in Java • Validation by testing all possible paths • Good results for every function simulated

23. Results and Validation

24. Conclusion and Perspectives • Originality of our approach: Use of DEVS modeling for algorithmic functions • Modeling and simulation starting from the source code • Application: CORBA Architecture • Already done: Portable Object Adapter • Main objective: Being able to simulate the whole CORBA architecture for testing new services

25. Conclusion and Perspectives • Perspectives: • To complete the whole architecture (ORB) • To add a physical network simulation tool • To simulate a complete distributed application over a network • To develop new techniques of validation