Upload
tilden
View
21
Download
0
Tags:
Embed Size (px)
DESCRIPTION
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. - PowerPoint PPT Presentation
Citation preview
PolyORBVersatile Middleware forInteroperable Critical Systems
PolyORBVersatile Middleware forInteroperable Critical Systems
Presentation cover page EU
www.adacore.com
Slide: 2
Overview
• Distributed programming paradigms
• Distribution models and middleware
• Example
• Pros and Cons of current models
• PolyORB, a versatile middleware
Sectional cover - Embedded board
Distributed Programming Paradigms
Slide: 4
Programming Distributed Systems
• Ad-hoc communication (e.g. via sockets)
• Message passing
• Remote procedure calls (RPCs)
• Distributed objects
• Shared memory
Slide: 5
Where It All Started: Sockets
Send (…, Bytes); Receive (…, & Bytes [ ]);
Slide: 6
Send bytes
Open socket
Get bytes
Open socket
Send bytes
Close socket
Get bytes
raw bytesraw bytes
raw bytesraw bytes
time time
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
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
Slide: 9
time time
function Foo (X: Integer) return Float is … return …;end Foo;
Result := Foo (Param)
Result := Foo (Param)
Send ParametersSend Parameters
Send ResultSend Result
Remote Procedure CallRemote Procedure Call
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 …
Slide: 11
Distributed Objects
• Distributed objects = RPCs in the OO world
• RPCs handling inheritance & polymorphism
Slide: 12
A Simple Comparison
Object-OrientedObject-OrientedProgrammingProgramming
Object-OrientedObject-OrientedProgrammingProgramming
Programming withGOTOs
Programming withGOTOs
StructuredProgramming
StructuredProgramming
Distributed ObjectsDistributed ObjectsDistributed ObjectsDistributed Objects
Message passing(sockets)
Message passing(sockets)
RPCsRPCs
Sectional cover- http
Distributed Models and Middleware
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)
• …
Slide: 15
Where is the Magic?
Result := Foo (Param);
function Foo (X: Integer) return Float is … return …;end Foo;
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
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
Sectional cover- Two guys working together
An example
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
Slide: 20
The Starting Point
package Types istype Sensor is …;type Temperature is …;
end Types;
package Types istype 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 isfunction Get_T (S : Sensor)
return Temperatureis
…end Get_T;
end Device;
package body Device isfunction Get_T (S : Sensor)
return Temperatureis
…end Get_T;
end Device;
Slide: 21
The Objective
package Types istype Sensor is …;type Temperature is …;
end Types;
package Types istype Sensor is …;type Temperature is …;
end Types;
Node 1Node 1
with Types; use Types;with Device;procedure Client is
S : Sensor := …;T : Temperature := Device.Get_T (S);…
end Client;
Node 2Node 2
with Types; use Types;package Device is
function Get_T (S : Sensor) return Temperature;
end Device;
package body Device isfunction Get_T (S : Sensor)
return Temperatureis
…end Get_T;
end Device;
Slide: 22
CORBA: The IDL
module Types { typedef … Sensor; typedef … Temperature;};
#include "types.idl"
interface Device { Types::Temperature Get_T (in Types::Sensor s);};
Slide: 23
Corba: Updated Packageswith 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 1Node 1
with Types; use Types;with Device;procedure Client is
S : Sensor := …;T : Temperature;D_Ref : Device.Ref;
beginCORBA.ORB.Initialize ("ORB");-- Getting the distant CORBA.ObjectCORBA.ORB.String_To_Object (..., D_Ref);T := Device.Get_T (D_Ref, S);…
end Client;
Node 2Node 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 isfunction Get_T
(Self: access Object; S : Sensor) return Temperature is…
end Get_T;end Device.Impl;
Slide: 24
SOAP (with AWS – the Ada Web Server)
ClientClientwith Types; use Types;with Device_Service.Client;procedure Client is
S : Sensor := …;T : Temperature :=
Device_Service.Client.Get_T (S);…
end Client;
unchanged
unchangedServerServer
unchangedunchanged
package Server isfunction Soap_CB (…) return …;
end Server;
package body Server isfunction Soap_CB (…) return … is
if SOAPAction = "Get_T" then return … wrapped Get_T call ... end if;
end Soap_CB;end Server;
Slide: 25
Ada 95 DSA
package Types ispragma Puretype Sensor is …;type Temperature is …;
end Types;
package Types ispragma Puretype Sensor is …;type Temperature is …;
end Types;
ClientClient
ServerServer
with Types; use Types;package Device is
pragma Remote_Call_Interface;
function Get_T (S : Sensor) return Temperature;
end Device;
unchanged
unchanged
unchanged
unchanged
Sectional cover - Embedded board
Pros and Cons of Current Models
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
NO YESTransparent in the code
The language
itselfIdentity
Vendor dependent
CORBA YES YESExplicit in the code
OMG IDL Standardized Standardized
SOAP YES NOExplicit in the code
WSDLVendor
dependentStandardized
Slide: 28
Ada 95 DSA Java RMI
CORBA
SOAP
Node 1 Code
Middleware ProtocolProtocol
Node 2 Code
Middleware
Standardized
Vendor specificVendor specific
Standardized
Standardized
GIOPGIOP
Standardized
Vendor specific
SOAPSOAP
Vendor specific
Interface
Ada/Java
IDL
WSDL
Slide: 29
PROS CONS
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
SOAPReuses web servers infrastructure (firewalls, web servers, …)
Learning curve for programmers
Strong web service orientation
Stuck with 1 vendor
Sectional cover- http
PolyORB – Connecting models
Slide: 31
Application and Protocol Personalities
Can we mix programming models and protocols?
• Yes with multiple cooperating personalities
Programming Modelapp personality
Middleware Protocolprotocol personality
Programming Modelapp personality
Middleware
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
protocol personality C
Slide: 33
PolyORB is Interoperable (1 of 2)
app personality A
PolyORBprotocol
personality B
app personality B
Other Middleware
app personality A
protocol personality B
Slide: 34
PolyORB is Interoperable (2 of 2)
app personality A
OtherMiddleware
protocol personality A
app personality B
PolyORBprotocol personality A
app personality B
Slide: 35
PolyORB as a Bridge
app personality A
Middleware A
app personality C
PolyORBPolyORBapp personality B
Middleware B
Protocol B
protocol A protocol B
app personality C
Prot
ocol
A
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
Slide: 37
Ada DSA and CORBA
Ada DSA and SOAP
Ada CORBA and CORBA
Ada CORBA and SOAP
Ada DSA
PolyORB GIOPGIOP
CORBA app
ORB
Ada DSA
PolyORB SOAPSOAP
SOAP app
Ada CORBA
PolyORB GIOPGIOP
CORBA app
ORB
Ada CORBA
PolyORB SOAPSOAP
SOAP app
38
Sectional cover- http
PolyORB – High Integrity middleware
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
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
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
Slide: 42
Summary: PolyORB – Versatile middleware
Check out the technology
http://libre.act-europe.com/
Commercial information
The interoperable, configurable middleware for critical applications
The interoperable, configurable middleware for critical applications