1 / 42

Presentation cover page EU

Presentation cover page EU. PolyORB Versatile Middleware for Interoperable Critical Systems. www.adacore.com. Overview. Distributed programming paradigms Distribution models and middleware Example Pros and Cons of current models PolyORB, a versatile middleware.

tilden
Download Presentation

Presentation cover page EU

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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. Programming Distributed Systems • Ad-hoc communication (e.g. via sockets) • Message passing • Remote procedure calls (RPCs) • Distributed objects • Shared memory

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

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

  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. 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. Remote Procedure Call Send Parameters Result := Foo (Param) function Foo (X: Integer) return Float is … return …; end Foo; Result := Foo (Param) Send Result time time

  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. Distributed Objects • Distributed objects = RPCs in the OO world • RPCs handling inheritance & polymorphism

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

  13. Sectional cover- http Distributed Models and Middleware

  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. Where is the Magic? Result := Foo (Param); function Foo (X: Integer) return Float is … return …; end Foo;

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

  17. 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 Defining the Terms

  18. Sectional cover- Two guys working together An example

  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. The Starting Point package Types is type Sensor is …; type Temperature is …; end Types; 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; with Types; use Types; with Device; procedure Client is S : Sensor := …; T : Temperature := Device.Get_T (S); … end Client;

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

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

  23. Corba: Updated Packages with CORBA; package Types is type Sensor is new CORBA.…; type Temperature is new CORBA.…; end Types; 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; 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; package body Device.Impl is function Get_T (Self: access Object; S : Sensor) return Temperature is … end Get_T; end Device.Impl;

  24. SOAP (with AWS – the Ada Web Server) Server unchanged unchanged package Server is function Soap_CB(…) return …; end 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; 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. Ada 95 DSA Server package Types is pragma Pure type Sensor is …; type Temperature is …; end Types; with Types; use Types; package Device is pragma Remote_Call_Interface; function Get_T(S : Sensor) return Temperature; end Device; Client unchanged unchanged

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

  27. SOAP Protocol GIOP Vendor specific Node 1 Code Vendor specific Standardized Standardized Middleware Standardized Standardized Node 2 Code Vendor specific Middleware Interface Ada/Java IDL WSDL

  28. Sectional cover- http PolyORB – Connecting models

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

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

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

  32. app personality A Other Middleware app personality B PolyORB PolyORB is Interoperable (2 of 2) app personality B protocol personality A protocol personality A

  33. app personality A app personality B Middleware A Middleware B app personality C PolyORB PolyORB as a Bridge app personality C protocol A protocol B Protocol B Protocol A

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

  35. GIOP SOAP SOAP GIOP Ada DSA Ada CORBA Ada DSA Ada CORBA PolyORB PolyORB PolyORB PolyORB SOAP app CORBA app CORBA app SOAP app ORB ORB

  36. Sectional cover- http PolyORB – High Integrity middleware

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

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

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

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

More Related