1. PolyORB Versatile Middleware for Interoperable Critical Systems PolyORB Versatile Middleware for Interoperable Critical Systems Presentation cover page EU www.adacore.com

2. Slide: 2 Overview Distributed programming paradigms Distribution models and middleware Example Pros and Cons of current models PolyORB, a versatile middleware

3. Sectional cover - Embedded board Distributed Programming Paradigms

4. Slide: 4 Programming Distributed Systems Ad-hoc communication (e.g. via sockets) Message passing Remote procedure calls (RPCs) Distributed objects Shared memory

5. Slide: 5 Where It All Started: Sockets Send (…, Bytes);Receive (…, & Bytes [ ]);

6. Slide: 6 Send bytes Open socket Get bytes Open socket Send bytes Close socket Get bytes raw bytes time

7. Slide: 7 Problems with Ad-Hoc Communication No interfaces –Low-level programming –Less reusable, portable, configurable –Error prone Does not lead itself to formal proofs Things like sockets exchange bytes –How do you exchange more complex data structures ? –How do you handle heterogeneous systems ? You need to marshall / unmarshall your data

8. Slide: 8 Message Passing Automatically marshall / unmarshall data transmitted Not transparent – partitioning explicit in the code Coordinating message sending / receiving can be complex Hard to do fault-tollerance in the asynchronous model Can be a good model for RT systems –Asynchronous message passing does not affect scheduling

9. Slide: 9 time function Foo (X: Integer) return Float is … return …; end Foo; Result := Foo (Param) Send Parameters Send Result Remote Procedure Call

10. Slide: 10 RPCs: A Higher Level Programming Paradigm RPC handled by the middleware Parameters and results passed across the network without programmer intervention Heterogeneity handled transparently The fact that the RPC is remote can be hidden –Ada 95 DSA & Java RMI Synchronous (and even asynchronous) RPCs can create problems for RT systems –Priority inversion problem …

11. Slide: 11 Distributed Objects Distributed objects = RPCs in the OO world RPCs handling inheritance & polymorphism

12. Slide: 12 A Simple Comparison Object-OrientedProgramming Programming with GOTOs Structured Programming Distributed Objects Message passing (sockets) RPCs

13. Sectional cover- http Distributed Models and Middleware

14. Slide: 14 Current Models Seamless integration with the programming language –Ada 95 DSA (Distributed Systems Annex) –Java RMI (Remote Method Invocation) Language-independent / vendor-independent –CORBA Language-independent / vendor-dependent –WSDL/SOAP (more of a protocol with an IDL on top) …

15. Slide: 15 Where is the Magic? Result := Foo (Param); function Foo (X: Integer) return Float is … return …; end Foo;

16. Slide: 16 The Magic Result := Foo (Param); function Foo (X: Integer) return Float is return …; end Foo; Middleware stub unmarshall results marshall parameters receive send Middleware skeleton unmarshall parameters marshall results receive send Interface

17. Slide: 17 Defining the Terms Middleware –Local client / server libraries to send / receive distant requests Interface –The interface of the distributed services exported by the server Transport protocol –The protocol used to code and transport the data between clients and servers Client stub: –Marshals the parameters –Sends the request over the network –Waits for the response –Unmarshals the result and delivers it to the client Server skeleton: –Receives the request –Unmarshals the parameters –Selects and calls the appropriate subprogram –Marshals the result and sends the response

18. Sectional cover- Two guys working together An example

19. Slide: 19 An Example Simple example of how the 3 models work –CORBA –WSDL/SOAP –Ada 95 DSA (Distributed Systems Annex) We only show (in red) the code written by the programmer –i.e. the code the programmer is forced to write in a given model We do not show the code that is generated automatically

20. Slide: 20 The Starting Point package Types is type Sensor is …; type Temperature is …; end Types; package Types is type Sensor is …; type Temperature is …; end Types; with Types; use Types; with Device; procedure Client is S : Sensor := …; T : Temperature := Device.Get_T (S); … end Client; with Types; use Types; with Device; procedure Client is S : Sensor := …; T : Temperature := Device.Get_T (S); … end Client; with Types; use Types; package Device is function Get_T (S : Sensor) return Temperature; end Device; with Types; use Types; package Device is function Get_T (S : Sensor) return Temperature; end Device; package body Device is function Get_T (S : Sensor) return Temperature is … end Get_T; end Device; package body Device is function Get_T (S : Sensor) return Temperature is … end Get_T; end Device;

21. Slide: 21 The Objective package Types is type Sensor is …; type Temperature is …; end Types; package Types is type Sensor is …; type Temperature is …; end Types; Node 1 with Types; use Types; with Device; procedure Client is S : Sensor := …; T : Temperature := Device.Get_T (S); … end Client; Node 2 with Types; use Types; package Device is function Get_T (S : Sensor) return Temperature; end Device; package body Device is function Get_T (S : Sensor) return Temperature is … end Get_T; end Device;

22. Slide: 22 CORBA: The IDL module Types { typedef … Sensor; typedef … Temperature; }; #include "types.idl" interface Device { Types::Temperature Get_T (in Types::Sensor s); };

23. Slide: 23 Corba: Updated Packages with CORBA; package Types is type Sensor is new CORBA.…; type Temperature is new CORBA.…; end Types; with CORBA; package Types is type Sensor is new CORBA.…; type Temperature is new CORBA.…; end Types; Node 1 with Types; use Types; with Device; procedure Client is S : Sensor := …; T : Temperature; D_Ref : Device.Ref; begin CORBA.ORB.Initialize ("ORB"); -- Getting the distant CORBA.Object CORBA.ORB.String_To_Object (..., D_Ref); T := Device.Get_T (D_Ref, S); … end Client; Node 2 with Types; use Types; with PortableServer; package Device.Impl is type Object is new … with null record;... function Get_T (Self: access Object; S : Sensor) return Temperature; end Device.Impl; package body Device.Impl is function Get_T (Self: access Object; S : Sensor) return Temperature is … end Get_T; end Device.Impl;

24. Slide: 24 SOAP (with AWS – the Ada Web Server) Client with Types; use Types; with Device_Service.Client; procedure Client is S : Sensor := …; T : Temperature := Device_Service.Client.Get_T (S); … end Client; unchanged Server unchanged package Server is function Soap_CB (…) return …; end Server; package body Server is function Soap_CB (…) return … is if SOAPAction = "Get_T" then return … wrapped Get_T call... end if; end Soap_CB; end Server;

25. Slide: 25 Ada 95 DSA package Types is pragma Pure type Sensor is …; type Temperature is …; end Types; package Types is pragma Pure type Sensor is …; type Temperature is …; end Types; Client Server with Types; use Types; package Device is pragma Remote_Call_Interface; function Get_T (S : Sensor) return Temperature; end Device; unchanged

26. Sectional cover - Embedded board Pros and Cons of Current Models

27. Slide: 27 Language independent Vendor independent from the programmer point of view Partitioning distributing services on machines IDL IDL to language mappings Transport Protocol Ada 95 DSA Java RMI NOYES Transparent in the code The language itself Identity Vendor dependent CORBAYES Explicit in the code OMG IDLStandardized SOAPYESNO Explicit in the code WSDL Vendor dependent Standardized

28. Slide: 28 Ada 95 DSA Java RMI CORBA SOAP Node 1 Code Middleware Protocol Node 2 Code Middleware Standardized Vendor specific Standardized GIOP Vendor specific SOAP Interface Ada/Java IDL WSDL

29. Slide: 29 PROSCONS Ada 95 DSA Java RMI Programmers have a very small learning curve Distribution not hardcoded Same language for all the nodes Stuck with 1 vendor CORBA Many things standardized Language independence Vendor independence Very steep learning curve for programmers Distribution hard coded SOAP Reuses web servers infrastructure (firewalls, web servers, …) Learning curve for programmers Strong web service orientation Stuck with 1 vendor

30. Sectional cover- http PolyORB – Connecting models

31. Slide: 31 Application and Protocol Personalities Can we mix programming models and protocols? Yes with multiple cooperating personalities Programming Model app personality Middleware Protocol protocol personality Programming Model app personality Middleware

32. Slide: 32 PolyORB – Colocated, cooperating personalities With PolyORB you can mix and match Application and protocol personalities app personality A PolyORB app personality B PolyORB app personality A protocol personality C app personality B protocol personality C

33. Slide: 33 PolyORB is Interoperable(1 of 2) app personality A PolyORB protocol personality B app personality B Other Middleware app personality A protocol personality B

34. Slide: 34 PolyORB is Interoperable(2 of 2) app personality A Other Middleware protocol personality A app personality B PolyORB protocol personality A app personality B

35. Slide: 35 PolyORB as a Bridge app personality A Middleware A app personality C PolyORB app personality B Middleware B Protocol B protocol Aprotocol B app personality C Protocol A

36. Slide: 36 Standardized Code and Protocol Personalities Standardized Ada code personalities –Ada 95 DSA (Distributed System Annex) –Ada 95 CORBA Standardized protocols –CORBA GIOP –SOAP PolyORB supports all 4 combinations

37. Slide: 37 Ada DSA and CORBA Ada DSA and SOAP Ada CORBA and CORBA Ada CORBA and SOAP Ada DSA PolyORB GIOP CORBA app ORB Ada DSA PolyORB SOAP SOAP appAda CORBA PolyORB GIOP CORBA app ORB Ada CORBA PolyORB SOAP SOAP app

38. 38 Sectional cover- http PolyORB – High Integrity middleware

39. Slide: 39 PolyORB – Adapting to the application Configurable and scalable Can change scheduling model/policy Can be configured to be deterministic Allows you to reuse code written for different distribution models

40. Slide: 40 PolyORB – Adapting to the operating environment Multiple tasking profiles: full tasking, Ravenscar-only, or no tasking Can configure memory management policy Multiple transport mechanisms

41. Slide: 41 PolyORB – Formally proven distribution kernel Modular architecture isolating primitive modules Identified behavioural properties for each core module Colored Petri net modelization of μBroker Formal validation by model reduction and model checking –10**17 states… –… verified in 36 hours on a 3.4 GHz Pentium IV / 3 Gb of RAM

42. Slide: 42 Summary: PolyORB – Versatile middleware Check out the technology http://libre.act-europe.com/ Commercial information sales@adacore.com The interoperable, configurable middleware for critical applications