CORBA Programming for Ada95

Real-Time and Non-Real-Time CORBA Programming for Ada95

Brad Balfour Objective Interface 13873 Park Center Road, Suite 360 Herndon, VA 20171-3247 703/295-6500 http://www.ois.com/ [email protected] [email protected]

Tutorial Goals Understand the goals and rationale behind CORBA and its usage Gain an introduction to the use of CORBA in software development effort Become familiar with both the basics of CORBA through specific examples of the use of ORBexpress Become familiar with the specific additional issues introduced by the combination of real- time applications and CORBA Be able to discuss the advantages and disadvantages of CORBA Be able to discuss the technologies and issues of

Familiarity with Ada 95 and at least one Ada 95 compiler No knowledge of: CORBA Distributed Object Computing is needed nor assumed

Questions

How many managers? How many engineers? Using? Ada 83? Ada 95? C? C++? Java? Others? Any CORBA experience? Any experience building distributed systems? Any object-oriented experience?

Leading Real-Time CORBA vendor Provider of ORBexpress for Ada 95 Provider of ORBexpress Real-Time for Ada 95 Key contributors to the CORBA standard Co-authors of the original IDL to Ada mapping Key submitters and Co-authors of the Real-Time CORBA standard Active contributors to other OMG standardization efforts

Disclaimer (and Fine Print)

Objective Interface is an ORB vendor On the positive side: We speak from experience We were part of the group that created the Ada mapping for the CORBA standard We’ve been in the ORB business since 1995 We are one of five teams that submitted proposals for the Real-Time CORBA standard and are actively writing the consolidated submission On the negative side: We are not “neutral”

Advanced Topics

Implementation Notes/ ORB internals

ORBexpress Specific Topics

Ada Specific Notes

Tutorial Topics

Section I: Introduction Section II: Overview of CORBA Section III: IDL Section IV: Client Development Section V: Server Development Section VI: Multi-Threaded CORBA Section VII: CORBA Performance Section VIII: Real-Time CORBA

CORBA Concepts What CORBA Provides Overview of the CORBA Development Process ORB Tool Components CORBA Runtime View Overview

CORBA Concepts

What are Objects ? Fundamentally: Objects Communicate IDL is the Key CORBA Clients and Servers CORBA Functionality When/Where to Use Benefits to Application Developers

Reusable self contained components of a business computing model Live blobs of intelligence and data that can be combined into an infinite number of lego-like arrangements Objects represent familiar, real-world things

ImplementationsImplementations of of an an IDL IDL interface interface that that are are containedcontained in in Servers Servers and and accessed accessed by by Clients Clients

Fundamentally: Objects Communicate Objects invoke operations on other objects and supply operation implementations If they are not in the same process, then they need a way to communicate! How could they communicate? Roll your own communication (e.g., sockets) DCE (not an OO approach) Microsoft’s DCOM [Distributed Component Object Model] (on windows only) OMG’s distributed object model called: Common Object Request Broker Architecture

10/1/00 ©2000 Objective Interface Systems, Inc. 12 IDL is the Key Provides the glue to attach the object to the software bus OMG’s Interface Definition Language (IDL) Specifies interfaces to remote objects Part of the CORBA specification Fully Object-Oriented A declarative language mapped to modern programming languages Ada 95, C, C++, COBOL, Eiffel, Java, Smalltalk,...

CORBA Clients and Servers Basic CORBA Runtime Architecture (Diagram)

Client Server

Object Request Object Request Broker Library Broker Library

Network

ClientClient sendssends aa requestrequest toto thethe serverserver Server receives request from Client Server sends a reply to the Client Client gets reply from the Server

Application Common CodeCode youyou Objects Facilities Domain write SpecificSpecific

Object Request Broker ORBexpressexpress CORBACORBA 2.02.0 CompliantCompliant ORB

Domain IndependentIndependent Object Services

When/Where to Use

To Connect multiple H/W, OSs, & Languages Unix, Windows 95/NT, OpenVMS, VxWorks Ada 95 ↔ C++ ↔ Java ↔ Smalltalk ↔ C ↔ … To distribute applications on object boundaries

TheThe Approach: Approach: OOOO Interfaces Interfaces (APIs), (APIs), Abstraction, Abstraction, Inheritance, Inheritance, Polymorphism Polymorphism TheThe Approach Approach Provides: Provides: CommunicationCommunication by by converting converting data data and and messages messages to to a a common common format format (IIOP)(IIOP) ApplicationsApplications written written as as if if the the other other side side were were using using the the same same technology technology 10/1/00 ©2000 Objective Interface Systems, Inc. 16 Benefits to Application Developers CORBA removes the need Raises the level of for abstraction Socket Level Programming Moves infrastructure Defining a client/server support to COTS vendors protocol Results: Defining a message format No more ‘stove pipe’ Marshalling of data applications Demarshalling data upon Allows Ada and other return from call languages to cooperate on an Saves developer’s time equal footing Reduces the need for bindings to GUIs, databases, etc.

What CORBA Provides

A middleware infrastructure for providing N-tier distributed systems

Seamless connectivity between: hardware architectures operating systems network transports programming languages

Location and access transparency

The basic question answered in this section: How are CORBA applications created?

Things to think about: How does this differ from the process of creating a non-distributed Ada 95 application? What aspects of the process differ depending on the Ada 95 toolset used? What aspects of the process differ if the clients as servers are built by different teams?

Diagram of Process IDL Source Code idl2ada

SpecSpec FilesFiles&& IncompleteIncomplete CompleteComplete BodiesBodies ImplementationImplementation BodiesBodies ORBexpress Libraries (object code) Ada 95 Compiler linker

CompletedCompleted ImplementationImplementation Bodies,Bodies, ServerServer Mainline, Client Client Server

Interface: The main OO construct in IDL. Defines an object class. Contains attributes, operations and associated data types and exceptions

Object: An occurrence of an interface. All objects are accessed by reference

Object Implementation: An instance of an interface’s implementation. Specifically a variable of the type Interface_Name.Impl.Object

Definitions [2] Object Reference: A distributed, network smart location transparent pointer. Also known as an IOR (Interoperable Object Reference) Server (mainline): A container of Object Implementations. An executable Ada 95 program containing Object Implementations. Client: Any program that uses CORBA IDL and Object References to execute operations on remote objects. A program (process) that uses references (of type Interface_Name.Ref) to invoke operations or set attributes.

SpecSpec Files Files&& CompleteComplete IncompleteIncomplete Bodies ImplementationImplementation Bodies Step 1: Create BodiesBodies ORBexpress Libraries (object code) Ada 95 IDL Source Compiler IDL Source linker CompletedCompleted ImplementationImplementation Bodies,Bodies, Server Server Mainline, Client IDL: Interface Definition Language Mainline, Client Client Server It is the OMG standard for defining a language neutral Application Programming Interface (API) Details will be presented in Section II of the course and are in Chapter 3 of the manual Is used to describe the services, attributes and data types that an Object in a Server provides to Clients Syntax similar to C++/Java. Semantics similar to Ada 95 IDL may be created by or provided to team IDLIDL interfaces interfaces typically typically describe describe a a distributed distributed (network) (network) interface interface

IDL Source Code idl2ada

SpecSpec Files Files&& CompleteComplete IncompleteIncomplete Bodies ImplementationImplementation Bodies Step 2: Translate the Bodies Step 2: Translate the Bodies ORBexpress Libraries (object code) → Ada 95 → Compiler IDL → Ada 95 linker CompletedCompleted ImplementationImplementation Bodies,Bodies, Server Server Mainline,Mainline, Client Client Client Server Inputs IDL generated/provided from Step 1 Process Description Invoke ORBexpress’s IDL → Ada 95 translator: idl2ada Products Multiple Ada 95 packages corresponding to the interface and implementation package specs and bodies

SpecSpec Files Files&& CompleteComplete IncompleteIncomplete Bodies ImplementationImplementation Bodies Step 3: Compile BodiesBodies ORBexpress Libraries (object code) Ada 95 Interface Packages Compiler Interface Packages linker CompletedCompleted ImplementationImplementation Bodies,Bodies, Server Server Mainline,Mainline, Client Client Client Server Inputs Generated interface packages (specs and bodies) corresponding to IDL interfaces (one per IDL interface) Process Description Compile the packages (this step may be postponed) Products Object files

IDL Source Code idl2ada

SpecSpec Files Files&& CompleteComplete IncompleteIncomplete Bodies ImplementationImplementation Bodies Step 4: Complete the BodiesBodies ORBexpress Libraries (object code) Ada 95 Ada Implementation Compiler Ada Implementation linker CompletedCompleted ImplementationImplementation Bodies,Bodies, Server Server Mainline,Mainline, Client Client Client Server Inputs Generated Object Implementation packages Process Description Complete the bodies of the Object Implementation (impl) packages Create the server mainline procedure Create the client mainline procedure Products A complete client and server implementation

SpecSpec Files Files&& CompleteComplete IncompleteIncomplete Bodies ImplementationImplementation Bodies Step 5: Compile the BodiesBodies Step 5: Compile the ORBexpress Libraries (object code) Ada 95 Compiler Implementation & linker CompletedCompleted ImplementationImplementation Bodies,Bodies, Server Server Mainlines Mainline,Mainline, Client Client Mainlines Client Server Inputs Completed Impl packages and Mainline procedures Process Description Submit the code to the compiler Code depends on supplied ORBexpress CORBA packages Products Object code for the application

IDL Source Code idl2ada

SpecSpec Files Files&& CompleteComplete IncompleteIncomplete Bodies ImplementationImplementation Bodies Step 6: Link the BodiesBodies ORBexpress Libraries (object code) Ada 95 Application Compiler Application linker CompletedCompleted ImplementationImplementation Bodies,Bodies, Server Server Mainline,Mainline, Client Client Client Server

Inputs All object code from Steps 3 and 5 Process Description Run the Ada linker Products Two (2) executable applications. One for the client mainline and one for the server mainline

Assuming the Environment has already been set up… The server application is run The client application is run and communicates with the server to make use of its provided objects and operations

ORB Tool Components

IDL Translator Client and Server Libraries (optional) Activation Environment

Takes OMG standard IDL as input Emits the corresponding Ada 95 packages Simple command line application

Client and Server Libraries These are the CORBA ORB (in a high-performance ORB) Statically linked into the application clients and servers Are represented as a series of Ada package interfaces that Ada 95 CORBA applications make use of Most interfaces are standard and described by the CORBA to Ada 95 mapping document (part of the OMG CORBA standard) Some packages are vendor specific or extra

Aids clients in obtaining valid references to implementation objects Aids clients in locating servers for object implementations Aids clients in starting/restarting server processes

CORBA Runtime View Overview Basic CORBA Runtime Architecture (Diagram)

Client Server

Object Request Object Request Broker Library Broker Library

Network

ClientClient sendssends aa requestrequest toto thethe serverserver Server receives request from Client Server sends a reply to the Client Client gets reply from the Server

10/1/00 ©2000 Objective Interface Systems, Inc. 34 CORBA Runtime View Legend:Legend: ConceptualConceptual Call Call Overview [2] ActualActual Call Call Nine Part Runtime View Client Client Side Environment Server Side Object Mainline ORB library ORB library Implementation Client process active (Daemon) Client obtains object reference (IOR) Client invokes operation on IOR Client ORB lib determines server process containing Object and connects Client ORB lib sends Server ORB lib receives request to server request and decodes

Server ORB lib invokes operation Client ORB lib receives response & returns Server ORB lib output data to client sends response completing operation back to client invocation Network Network 10/1/00 ©2000 Objective Interface Systems, Inc. 35

Basic Process for Running a CORBA Program

1. Start the launchd on the server system

launch ---d-d test ---le-le tcptcp://student1:5555://student1:5555 &

2. Run the server

A_Server & 3. Run the client

A_Client

IDL Overview Concept of IDL Purpose Why IDL The IDL Advantage IDL to Ada 95 Mapping Impact IDL Constructs and their Ada 95 Mapping Running the idl2ada tool

Concept of IDL

Interface Definition Language — A language neutral Application Programming Interface (API) Specifies “what” services and attributes an object provides No concept of “how” those services are implemented Describes the relationships among interface: Inheritance Composition Inclusion

To describe the interface between a distributed client and server A language neutral description that maps to one or more programming languages The given language is then used to implement the object(s) specified in IDL To provide a wide range of facilities for describing a distributable interface To provide a sufficient set of standard data types to communicate between clients and servers

Why IDL?

Limitations inherit in a single language distribution mechanism Little, if any, cross-language interoperability Limitations on parameter types no sequences, unions pointer chasing Compiler technology modify a compiler: tied to that compiler write a front end: problems with different compilers different language subsets

Ada 95 caller

Smalltalk caller target object Java caller

C++ caller IDLIDL interfaceinterface

Won’tWon’t some some existing existing language language suffice suffice for for defining defining interfaces? interfaces? No! No!

CORBA →→ Ada 95 Mapping Features Simple Translation Inheritance IDL Interfaces → Package Separate lines of descent declaring tagged type for interfaces and Reference Semantics implementations Basic types correspond SuperSuper directly InheritsInherits fromfrom Memory Management SubSub

All CORBA types are IDL Super.RefSuper.Ref Super.Impl.ObjectSuper.Impl.Object memory managed Client- Server- side side All Refs are reference Sub.RefSub.Ref Sub.Impl.ObjectSub.Impl.Object counted and reclaimed Parent-ChildParent-Child HierarchicalHierarchical LibraryLibrary UnitUnit

It is practical to build a system using two (or more) different programming languages Each development team need only understand IDL and their programming language — not the language used by the other team(s) Two common ways that the IDL is specified: Designed by the developers internally to the project Provided to multiple teams at the start of the project

Example

A small, simple IDL file:

interface Print_Monitor { enum Response { Quiet, Spooling, Printing, Out_of_Paper };

Response Printer_Status(); };

IDL Overview IDL Constructs and their Ada 95 Mapping Running the idl2adaidl2ada tool

IDL Constructs and their Ada 95 Mapping

IDL Modularity Kinds Mapping to Multiple Ada 95 Files Interfaces Inheritance Between Interfaces Modules Files Data Types Exceptions

FileFile Interface: the “object” or “class” construct of IDL. Contains types, ModuleModule operations, constants, attributes, exceptions InterfaceInterface Modules: group together one or NestedNested more interfaces ModuleModule Files: group together modules InterfaceInterface Optionally types, constants, or exceptions not in modules Optionally interfaces not in modules

Mapping to Multiple Ada 95 Files IDL File “Read-Only“Read-Only”” Not to be changed by developer interface Foo{}; Not to be changed by developer

ExpectedExpected to to be be modified modified

idl2ada

Interface Packages Implementation Packages (use with Client & Server) child of interface Packages package Foo; (use with Server-side only) package body Foo; package Foo.Impl; package body Foo.Impl;

Concept Syntax Mapping Operations Attributes Referring to Contents

Concept

The equivalent to the OOPL “class” construct Encapsulates Attributes Operations Exceptions Associated data types Does not define the implementation of the services that it provides May be extended via interface inheritance

Implementations will likely reside on separate distributed machines from where the interface is used Therefore, clients don’t work with implementation Clients work with Object References

Note:Note: CORBA CORBA programming programming always always uses uses reference reference semantics semantics

Syntax

Denoted by the keyword “interface” General Syntax: interface identifier [: parent_interface] { [sequence_of_definitions] };

10/1/00 ©2000 Objective Interface Systems, Inc. 52 Mapping Client Side: Maps to a generated “Interface Package” containing a tagged type “Ref” Server Side: Maps to a generated “Implementation Package” containing the “impl” Object type IDL Ada 95 //contents of foo.idl -- contents of foo.ads -- the "interface package" interface Foo { with CORBA; package Foo is type Ref is new CORBA.Object.Ref with null record; }; end Foo;

-- contents of foo-impl.ads -- the "implementation package" package Foo.Impl is type Object is new CORBA.Impl.Server.Object with null record; end Foo.Impl; 10/1/00 ©2000 Objective Interface Systems, Inc. 53

Operations

Concept Syntax Mapping Example Two-way vs. One-Way Overloading

10/1/00 ©2000 Objective Interface Systems, Inc. 54 Concept Operations Are services that an IDL interface provides to its clients Have zero or more parameters Parameters contain values of some type Parameters are of modes in, out and inout Parameters are separated by commas Return a value (or void) back to the caller Are only declared inside an interface

Syntax

General Syntax: [oneway] identifier ( [, ] ); Where: ::= | void ::= [ identifier] ::= in | out | inout ::= |

Operations map directly to Ada 95 procedures or functions If the operation returns a value and has only mode in it maps to a function Otherwise, it maps to a procedure If a value is returned, the procedure has an extra parameter named “returns” All types and modes translate straightforwardly The target object is made explicit as the first parameter (named Self of type Ref) All other parameters of the interface type are mapped to the class-wide Ref type

Example

IDL Ada 95 //contents of shape.idl -- contents of shape.ads -- the “interface package” with CORBA; interface Shape package Shape is { type Ref is new CORBA.Object.Ref with null record; void Display (in boolean value) procedure Display (Self : Ref; Value : in CORBA.Boolean);

Shape union_of function union_of (in Shape right); (Self : Ref; Right : in Ref’class) return Ref’class;

}; end Shape;

10/1/00 ©2000 Objective Interface Systems, Inc. 58 Two-way vs. One-Way Two-way operations One-way operations Are the default Client does not wait for Allow for replies from the the server server No replies allowed A return value No return type. Only mode Parameters of mode out in or inout No user exceptions An exception allowed

Note:Note: For For a a one-way one-way operation operation there there is is no noguaranteeguarantee of of delivery delivery

Note:Note: ORB ORBexpressexpress guarantees guarantees delivery delivery to to the the network network transport transport layer layer

Overloading

Operation names must be unique Overloading is not supported Overriding implementations and polymorphic dispatching is a separate issue and is supported

Note:Note: Overloading Overloading isn isn’t’t supported supported because because languages languages like like C C can can’t’t mapmap it. it. Proposals Proposals to to overcome overcome this this limitation limitation occasionally occasionally surface surface

Concept Syntax Mapping Example

Attributes Concept Are values/properties of an interface Are only declared inside an interface May have the value “set” and “read” A “readonly” attribute may not be set/changed Example: Out_Of_Paper attribute of printer server interface Conceptually are the data elements that represent the publicly visible state of an interface object May or may not have a relationship to actual data stored inside the object implementation Could be one of the data elements Could be computed as needed

General Syntax: [readonly] attribute identifier; Where: ::= |

Mapping Generated interface package Attributes map to a pair of “set/get” operations Names are Set_attribute_name and Get_attribute_name The “set” operation changes the attributes value The “get” operation retrieves the attributes value Generated implementation package Attributes are automatically added as fields inside the interface_name.Impl.Object record type This is a convenience for the programmer The developer is free to change the Object definition Readonly attributes generate only a “get” operation 10/1/00 ©2000 Objective Interface Systems, Inc. 64 Example IDL Ada 95 //contents of shape.idl -- contents of shape.ads -- the "interface package" with CORBA; interface Shape { package Shape is type Ref is new CORBA.Object.Ref with null record; attribute long position_x procedure Set_Position_X (Self : Ref; To : CORBA.Long); function Get_Position_X(Self : Ref) return CORBA.Long); readonly attribute function Get_Displayed (Self : Ref) boolean Displayed return CORBA.Boolean; }; end Shape; -- contents of shape-impl.ads -- the "implementation package" with CORBA,Impl.Server.Object; package Shape.Impl is type Object is new CORBA.Impl.Server.Object with record position_x : CORBA.Long; displayed : CORBA.Boolean; end record; end Shape.Impl;

Referring to the Contents of an Interface In IDL use scoped name notation interface_name::content_name Example interface parent { typedef long my_long; }; interface other { void op (in parent::my_long param); }; ReferRefer to to the the contents contents of of an an interface interface package package via via selected selected component component notation notation

Concept Mapping Concept Generated Interface Code Generated Inheritance Code Overriding Inherited Operations Preview of MI

Concept

One IDL interface may inherit from another Second interface then implicitly contains all of the attributes, operations and exceptions that the first provides Interface inheritance only — makes no assumptions about the implementation Syntax: interface name : parent_interface_name {};

InheritsInherits fromfrom CircleCircle

Shape.RefShape.Ref IDL Shape.Impl.ObjectShape.Impl.Object Mapping Concept Client Server Mapping Concept -side -side Circle.RefCircle.Ref Circle.Impl.ObjectCircle.Impl.Object

Parent-ChildParent-Child HierarchicalHierarchical Uses Ada 95 tagged types and inheritance LibraryLibrary UnitUnit The interface package’s Ref type is a tagged type Generated child interface’s Ref type is derived from the parent interface package’s Ref type This automatically causes all operations and attributes to be inherited The “impl” does not inherit from the either of the interface Ref types The child’s “impl” Object type does inherit from the the parent impl’s Object type

Generated Interface Code

IDL Ada 95 // file: inherit.idl -- file shape.ads with CORBA.Object; interface Shape { package Shape is type Ref is new CORBA.Object.Ref with null record; readonly attribute long x; function Get_X (Self : Ref) return CORBA.Long; readonly attribute long y; function Get_Y (Self : Ref) return CORBA.Long; void Draw(in long x, in long y); procedure Draw(Self : Ref; x : in CORBA.Long; y : in CORBA.Long); }; end Shape; -- file circle.ads with Shape; interface Circle : Shape { package Circle is type Ref is new Shape.Ref with null record; }; end Circle; 10/1/00 ©2000 Objective Interface Systems, Inc. 70 Generated Inheritance Code IDL Ada 95 // file: inherit.idl -- file shape-impl.ads with CORBA.Impl.Server.Object; interface Shape { package Shape.Impl is type Object is new CORBA.Impl.Server.Object with record x : CORBA.Long; y : CORBA.Long; end record; readonly attribute long x; function Get_X (Self : access Object) return CORBA.Long; readonly attribute long y; function Get_Y (Self : access Object) return CORBA.Long; void Draw(in long x, procedure Draw(Self : access Object; in long y); x : in CORBA.Long; y : in CORBA.Long); }; end Shape.Impl; -- file circle-impl.ads with Shape.Impl; interface Circle : Shape { package Circle.Impl is type Object is new Shape.Impl.Object with null record; }; end Circle.Impl; 10/1/00 ©2000 Objective Interface Systems, Inc. 71

Overriding Inherited Operations

Overriding in CORBA occurs only in the implementation package Never in the implementation package Modify the generated .impl package specification to add the overriding operation subprogram specification Modify the generated .impl package body to add the overriding operation subprogram body

IDLIDL doesn doesn’t’ toverride override the the operation operation signature signature in in the the interface interface to to indicate indicate that that a a new new overridingoverriding implementation implementation will will be be provided provided

10/1/00 ©2000 Objective Interface Systems, Inc. 72 Preview of MI Multiple Inheritance is supported in IDL interface child : parent_1, parent_2 ; Semantics is interface inheritance (subtyping) from multiple parents IDL MI is simply a shortcut to lexical inclusion of the parent’s interface into the child’s interface This allows the generated Ada interface packages to be simple Ada 95 inheritance is used for the first parent Other operations/attributes are generated to reflect those supplied by other parents

File Inclusion IDL does not allow one IDL file to refer to another ones contents IDL is based on C/C++ model of physical inclusion #include statement Once scope is visible (either via inclusion or because it is defined in the same file stream), the the Scoped Reference operator (“::”) is used to make nested name visible

ByBy default, default, idl2ada idl2adadoesndoesn’t’ tgenerate generate code code for for included included files files — —justjust “ “withwith”” dependencies dependencies

Simple Composite (continued) Constants String Range Constraints Bounded Concept Typedef Typedef Package Spec Composite Unbounded Struct Sequence Union Unbounded Array Bounded Misc.

Simple IDL Name Predefined Size Ada Equivalent Mapping Construct octet Yes 8 bit Interfaces.Unsigned_8 CORBA.Octet boolean yes 8 bit Standard.Boolean CORBA.Boolean char yes 8 bit Standard.Character CORBA.Char Enumerated Types no 32 bit Ada Enumerated Type None Predefined short yes 16 bit Interfaces.Integer_16 CORBA.Short unsigned short yes 16 bit Interfaces.Unsigned_16 CORBA.Unsigned_Short long yes 32 bit Interfaces.Integer_32 CORBA.Long unsigned long yes 32 bit Interfaces.Unsigned_32 CORBA.Unsigned_Long float yes 32 bit Interfaces.IEEE_Float_32 CORBA.Float double yes 64 bit Interfaces.IEEE_Float_64 CORBA.Double string yes Variable OIS.Strings.Sequence CORBA.String any yes Variable Private CORBA.Any IDL Ada 95 enum Traffic_Lights {Red, type Traffic_Lights is (Red, Yellow, Yellow, Green}; Green);

10/1/00 ©2000 Objective Interface Systems, Inc. 76 Typedef Provide ability to define a new name for an existing type New name is renaming not a new type Most languages treat typedef as a macro substitution For Ada 95 mapping, typedef is mapped to a derived type declaration This is a deviation Causes new type to inherit attributes and operations of original type Result is in line with IDL intent but adds additional type safety for Ada developers 10/1/00 ©2000 Objective Interface Systems, Inc. 77

Composite Struct String Union Bounded Unbounded Array Sequence Unbounded Bounded IDL Name Predefined Size Mapping Construct struct no Defined by Ada Record Type Components union no Defined by Ada Variant Record Type Components array no Defined by Ada Array Type Indexed 0..Length-1 Components string unbounded yes Variable Length CORBA.String bounded no Bounded Length CORBA.Bounded_String sequence unbounded no Variable Length CORBA.Sequences.Unbounded bounded no Bounded Length CORBA.Sequences.Bounded

10/1/00 ©2000 Objective Interface Systems, Inc. 78 Struct Equivalent to Ada 95 record Contents are named fields Fields are any pre-defined, named or typedef defined types Syntax similar to C struct struct name { type_name field_name; //optionally repeat }; Example: IDL Ada 95 Code struct Basics { type Basic is record octet o; o : CORBA.Octet; boolean b; b : CORBA.Boolean; }; end record; 10/1/00 ©2000 Objective Interface Systems, Inc. 79

Union Similar to Ada 95 discriminated record Contains mutually exclusive components Switch type must be one of: integer, character boolean or enumerated type Switch labels are values of the type or the keyword “default” Fields are pre-defined or typedef defined types Mapped to Ada 95 unconstrained record Syntax similar to C union union name switch (enumerated_type){ case value: type_name field_name; //optionally repeat case default: type_name field_name; 10/1/00}; ©2000 Objective Interface Systems, Inc. 80 Union Example

IDL Ada 95 Code union Example switch type Example (Switch : Traffic_Lights := (Traffic_Lights) { Traffic_Lights’FIRST) is record case Switch is case Red: when Red => string s; s : CORBA.String; case Yellow: when Yellow => long l; l : CORBA.Long; case Green: when Green => boolean b; b : CORBA.Boolean; }; end record;

Array

Similar to Ada 95 array Usually declared in a typedef statement May be single or multiple dimension Elements any pre-defined or user defined type Base type the same for all dimensions Index always integer values only Most languages map from 0 to bounds size-1 Ada mapping follows suit

Syntax typedef element_type_name array_type_name [size]; typedef element_type_name array_type_name [size][size]; Example: IDL Ada 95 Code typedef double type Double_Array is Double_Array[20]; array(0..19) of CORBA.Double; typedef long Multi[4][5]; type Multi is array(0..3, 0..4) of CORBA.Long;

String

Unbounded Concept Package Spec Bounded Concept Package Spec

10/1/00 ©2000 Objective Interface Systems, Inc. 84 Unbounded Concept Predefined IDL type Dynamically sized Grows and shrinks as needed Maps in Ada 95 to a private type named CORBA.String Mapping calls for CORBA.String to provide equivalent capabilities as Ada.Strings.Unbounded All unbounded strings map to types derived from CORBA.String

ImplementedImplemented as as a a controlled controlled record record type type containing containing an an access access type type to to a a heap-allocated heap-allocated array array ofof characters. characters. Deep Deep copies copies in in the the “ “adjustadjust”” operation operation implement implement copy copy semantics semantics

Bounded Concept Predefined IDL type Sets limit on maximum length string can reach Syntax: typedef string type_name; Mapping to Ada 95: An instantiation of a generic package named CORBA.Bounded_Strings Bounded string type is then derived from the type Bounded_String exported by the instantiation Mapping calls for CORBA.String to provide equivalent capabilities as Ada.Strings.Bounded 10/1/00 ©2000 Objective Interface Systems, Inc. 86 Sequence — The Concept Variable length collections of elements Unbounded: No upper limit Bounded: Maximum upper bound Mapping An instantiation of either generic package CORBA.Sequences.Bounded or CORBA.Sequences.Unbounded Type is then derived from the type Sequence exported by the instantiation IDLIDL’s’s arrays arrays are are always always bounded. bounded. SequencesSequences are are most most similar similar to to Ada Ada’s’s unconstrained unconstrained arrays arrays

SyntaxUnbounded Sequence typedef sequence type_name; Example IDL Ada 95 Code typedef sequence type IDL_SEQUENCE_short_Array is Short_Sequence; array (Integer range <>) of //unbounded sequence CORBA.Short; //no maximum # package IDL_SEQUENCE_short is //of elements new CORBA.Sequences.Unbounded (Element => CORBA.Short, Index_Type => Integer, Element_Array => IDL_SEQUENCE_short_Array); type Short_Sequence is new IDL_SEQUENCE_short.Sequence; 10/1/00API ©2000 Objective Interface Systems, Inc. 88 Bounded Sequence Syntax typedef sequence type_name; Example IDL Ada 95 Code typedef sequence type IDL_SEQUENCE_long_Array is Long_Sequence; array (Integer range <>) of //Bounded sequence CORBA.long; //Maximum is 10 elements package IDL_SEQUENCE_long is new CORBA.Sequences.Bounded (Element => CORBA.Long, Index_Type => Integer, Element_Array => IDL_SEQUENCE_Long_Array, Max => 10); type Long_Sequence is new IDL_SEQUENCE_Long.Sequence; API 10/1/00 ©2000 Objective Interface Systems, Inc. 89

Exceptions Very similar to Ada 95’s exceptions Three main differences for IDL exceptions: Distributed — raised on the server and propagated across the network to a client IDL operations define the exceptions they raise as part of their declaration May optionally have user-defined data stored with the exception Two Kinds: User Defined CORBA System — deferred until the section on Client Side programming 10/1/00 ©2000 Objective Interface Systems, Inc. 90 User Defined

Single IDL exception is mapped to three (3) Ada 95 constructs An Ada exception A tagged record type containing any IDL defined exception data A generated subprogram to extract the data from an instance of CORBA.Exception_Occurrence Which is a subtype of Ada.Exceptions.Exception_Occurrence

User Defined Example IDL Ada 95 Code Exception No_Data {}; No_Data : exception type No_Data_Members is new CORBA.IDL_Exception_Members with null record; procedure Get_Members ( From : in CORBA.Exception_Occurrence; To : out No_Data_Members); exception Error { Error : exception; string message; type Error_Members is new long error_number; CORBA.IDL_Exception_Members }; with record message : CORBA.String; error_number : CORBA.Long; end record; procedure Get_Members ( From : in CORBA.Exception_Occurrence; To : out Error_Members); 10/1/00 ©2000 Objective Interface Systems, Inc. 92 Section III - IDL

IDL Overview IDL Constructs and their Ada 95 Mapping Running the idl2adaidl2ada tool

Running the idl2ada Tool A command line tool Basic invocation: IDL File “Read-Only” Interface Foo{}; Not to be changed by “developerRead-Only” idl2ada idlfile...idl.idl Not to be changed by developer Expected to be modified Ada 95 code is place Expected to be modified into files with correct idl2ada names in directory names in directory Interface Packages Implementation Packages (use with Client & Server) child of interface Packages where the tool is run Package Foo; (use with Server-side only) Package body Foo; Package Foo.Impl; Default is to generate Package body Foo.Impl; code only for IDL directly defined in file No code generated for #included files 10/1/00 ©2000 Objective Interface Systems, Inc. 94 Example

H:H:\\\ttt>idl2adattt>idl2ada tictactoe.idl idl2ada: creating game.ads idl2ada: creating game.adb idl2ada: creating gamegame----impl.adsimpl.ads idl2ada: creating gamegame----impl.adbimpl.adb

Section IV — Client Development

Clients & Servers — Temporary Roles for Programs Client Development — The Mainline

A separately running program (process) Makes use of one or more references to Object Interfaces Accesses operations and attributes of those interfaces In Ada 95, clients accomplish this by making use of the generated Ada 95 packages These packages map to the original IDL Clients are always manually launched by the user

Servers: A Summary

A separately running program (process) Contains one or more implementations of Object Interfaces Registers itself as an CORBA server A process known as Object Adapter activation May be manually launched or automatically launched on demand by the Activation Environment

The definitions on the last two slides are not as rigid as they first appear “Clients” and “Servers” are temporary roles that programs take on at certain times Often a Server program will act as a Client of another Server A client may wish to act as a Server — a typical example is a callback To do this the “client” must do do the extra things a server must do

Section IV — Client Development

Clients & Servers — Temporary Roles for Programs Client Development — The Mainline Characteristics Life-Cycle Obtaining an Object Reference Reference Semantics Writing the Body Example Body

A separate Ada 95 program (process) “With”s in one or more Object interfaces with Interface_Name; Obtains Object References to one or more Object Is always launched (activated) by the user

ClientsClients are are Simple! Simple!

Very Simple Client Example with CORBA.ORB.IIOP_English; with Game; procedure Client is G : Game.Ref; Move : Game.Position_Type := Game.MiddleMiddle; Player_Board : Game.Board_Type; Computer_Board : Game.Board_Type; Game_Status : Game.Status_Type := Game.Continue; begin G := -- Bind to the object implementation -- use Naming Service or proprietary -- convinience routine like Bind Game.New_Game(G); Game.Move (G, Move,Player_Board, Computer_Board, Game_Status); end Client; 10/1/00 ©2000 Objective Interface Systems, Inc. 102 Life-Cycle 1. The “user” manually launches the client

IOR 2. Client obtains a reference to some Object contained in a Server Client 3. Client invokes one or more ORB Server operations on an Object contained Library in Server

4. Repeat 3&4 with Server(s) 5. Client completes. ORB library terminates Server

Reference Semantics Before Object Object CORBA requires Object Reference A Reference B References to exhibit reference semantics All variables of the type Object Object Interface_Name.Ref have this Implementation X Implementation Y No copying occurs After A:=B; Object Object Assignment causes both “Ref” Reference A Reference B objects to designate the same Object Implementation

Overview/Skeleton Invoking Operations Using Attributes

Overview

Developers must write clients — they are not generated Clients, in general, will: “with” in one or more Object Interface packages Obtain a reference to an Object Implementation Invoke operation on the Object in accordance with the logic of the client All client mainline programs can be based on a common Ada 95 program outline

10/1/00 ©2000 Objective Interface Systems, Inc. 106 with CORBA.ORB.Default; with Interface_Name; -- ProvidesClient access to theSkeleton Interface_Name package with Text_IO; with Ada.Exceptions; with Ada.Command_Line; procedure Client is Some_Ref : Interface_Name.Ref; -- holds the reference to the Object Implementation -- other declarations go here begin Some_Ref := ...; -- locates an Object Implementation of the Interface -- "Interface_Name" on the server and returns an -- Object Reference to it -- Use the naming service or a proprietary convinience -- routine like Bind Text_IO.Put_Line("Welcome to My Client!"); -- Client logic goes here exception -- handle any exceptions here 10/1/00... ©2000 Objective Interface Systems, Inc. 107 end Client;

Invoking Operations Prerequisite: Client has already obtained a valid Object Reference As simple as calling a local subprogram exported by a package Just call the subprogram in the generated Interface package — the ORB library does the rest Example ... procedure Client is A_Game : Game.Ref; begin A_Game:= -- Bind to the object implementation -- use Naming Service or proprietary -- convinience routine like Bind Game.New_Game(A_Game); end Client; 10/1/00 ©2000 Objective Interface Systems, Inc. 108 Demo

Tic Tac Toe demo program from standard ORBexpress installation IDL and generated Ada 95 code shown previously Assume that Server has already been built Now look at Tic Tac Toe’s client.adb file

References vs. Object Lifetimes

Object References in Clients provide access to Object Implementations in Servers However, they are two different variables of two different types They live in two separate applications Therefore, they have separate lifetimes

10/1/00 ©2000 Objective Interface Systems, Inc. 110 References vs. Object Lifetimes [2] Earlier Later It is possible for Object Client Object Client Object References to “point to” Reference A Reference A Object Implementations whose lifetime has Object Object ended Implementation X Implementation X It is possible for Object Before During After Implementations to Client Object Implementations to Reference A exist before and after the client-side Object References that “point References that “point Object Object Object to” them Implementation X Implementation X Implementation X

References vs. Object Lifetimes [3]

Concepts to remember: Even though Object References go out of scope, Object Implementations are never affected Object Implementations are never deleted based on the lifetimes of remote References Client developers must be prepared to handle CORBA.INV_OBJREF exception at any time for any operation Since the implementation may have been deleted while the reference lives on

Object Implementation Server Mainline

Object Implementation (Server Side) [Part I]

Contents of the Impl Package Spec Contents of the Impl Package Body Modifying the Impl Package Body Adding Data to the Object Implementing Operations Raising Exceptions in Server Code

Note:Note: This This is is one one of of two two parts parts of of creating creating the the Server. Server. The The other other step step is is toto create create the the Server Server Mainline. Mainline. These These may may be be done done in in parallel parallel

Skeleton packages Syntactically and semantically complete and correct None of the application logic needed to implement the objects defined by the IDL interface

Contents of the Impl Package Spec [2] Generated code looks similar to Interface packages Main difference is the type exported by the package Interface package exports type Ref All IDL defined operations are primitive on this tagged type Implementation package exports type Object All IDL defined operations are primitive on this tagged type

Note:Note: Both Both types types Object Object and and Ref Ref are are controlled, controlled, tagged tagged types types

Generated Ada 95 Code Modified Ada 95 Code with CORBA; with CORBA; with CORBA.Impl.Server; with CORBA.Impl.Server; package game.Impl is package game.Impl is type Object is new type Object is new CORBA.Impl.Server.Object CORBA.Impl.Server.Object with with null record; record Board : Board_Type := (others => (others => Empty)); Game_Satus : Status_Type := Continue; end record; end game.Impl; end game.Impl;

Implementing Operations

The next step is to complete the Object Implementation’s operations Both declarative and executable regions Consider both Capabilities to be provided and Error conditions that may arise Example

Inside an operation Object Implementation may detect error condition has occurred Typically this corresponds to one of the IDL exceptions declared in the operation’s IDL interface Operation should then raise the exception using the standard mechanisms

Raising Exceptions in Server Impl Code [2] Process for raising a CORBA exception in an operation body: 1. Declare a variable of the exception members type Foo : idl_exception_name_members; 2. For each member of the IDL exception, set the member’s field value Use an ordinary Ada 95 assignment operation 3. Raise the exception in the current calling client by invoking CORBA.Raise_Exception (exception_members) This is very similar to a raise statement Control does not return to the calling Object Implementation

10/1/00 ©2000 Objective Interface Systems, Inc. 120 Example Tic Tac Toe Body of Operation Move ... if Self.Game_Status /= Continue then What happens declare Exception_Data : Illegal_Move_Members;to the flow of begin control after Exception_Data.Position := this operation? Position; Exception_Data.Game_Status := Continue; CORBA.Raise_Exception(Exception_Data); end; end if; ...

Server Mainline

Characteristics of a Server Server Lifecycle Creating Object Implementations Template Body

Server Mainline is the CORBA Server’s “main program” It is a separate operating system process It is a separate Ada 95 executable program The Server Mainline is responsible for: Creating Object Instances Notifying the ORB that a program is ready to become a server

Characteristics of a Server[2]

Server

Object Object Implementation X Implementation X

Object Server is a collection of Object Implementation X Implementations Has the following characteristics: “Withs” in one or more Object Implementations (with interface_name.Impl) “Withs” in an Object Adapter via (with CORBA.BOA)

Note:Note: An An Object Object Adapter Adapter receives receives requests requests and and directs directs them them to to the the appropriate appropriate Object Object Implementation.Implementation.

10/1/00 ©2000 Objective Interface Systems, Inc. 124 Characteristics of a Server[3] Has the following characteristics (continued): Creates one or more Object Implementations, each with a corresponding Object Reference (via a interface_name.Impl.Create call) Registers itself as a server with the ORB (via a CORBA.BOA.Impl_Is_Ready call) Note: Clients can then receive Object References to one or more Objects contained in the server Server’s promise to contain Object Implementations of a specific Interface are communicated outside of the software Server can be launched manually or automatically 10/1/00 ©2000 Objective Interface Systems, Inc. 125

Server Life-Cycle Overview

1. The “user” launches the server Ref2 Ref 2. The Server Mainline creates one or more instances of Ref each interface implementation in variables of type .Ref

3. The server is now running and calls Impl_Is_Ready (this enters the event loop)

4. Server is now ready to accept requests for objects that it contains (serves) Client Server ORB ORB 5. Client obtains a reference to some object contained in Library Library the server

6. Client invokes one or more operations on an object contained in the server

7. Event Loop times out when calls don’t come in after a specified period

8. Server Mainline completes

Concept of Object Impls Template Body Example

Concept of Object Impls

All Object Implementations are of type Interface_Name.Impl.Object These are descendents of CORBA.Imp.Server.Object This is a controlled type The Implementation package defines them The Server Mainline declares the variables and actively creates the instances

with Interface_Name.Impl; with CORBA.BOA; procedure Server is ... An_Object_Ref : Interface_Name.Ref := Interface_Name.Impl.Create(…); begin CORBA.BOA.Impl_Is_Ready (...); end Server;

Section VI Multi-threaded CORBA

Multi-Threaded Clients

Multi-Threaded Servers

Concept Overview Benefits and Reasons The Costs of Tasking Analysis of Total Concurrency in System The Role of Multiple Client Tasks Client Multi-Tasking Task Safety Within ORBexpress Exceptions and Multi-Tasking Client-Side Pattern using Tasks

Concept Overview ORBexpress fully supports multi-threaded clients and servers Most OS’ map Ada tasks to OS threads within processes Each provides an independent thread of control and local variables (stack space) Each independently executes (or is blocked) regardless of other tasks Increases the power of clients and servers

10/1/00 ©2000 Objective Interface Systems, Inc. 132 Benefits and Reasons Non-Blocking Behavior: client can make remote calls that do not block the entire process Includes simultaneous calls on the same Object Implementation (OI) or on different OIs Better Response Time: server is able to respond to multiple requests simultaneously From same client or different clients Each task can concurrently process & respond to an operation request Keeps long server operation implementations from starving operations with shorter times May use additional tasks within body of OI package to provide better response time 10/1/00 ©2000 Objective Interface Systems, Inc. 133

The Costs of Tasking Development time: Programmer must expend effort to protect shared data structures from concurrent access Same requirements as any other multi-tasking Ada program Run-time efficiency: Positive gains in responsiveness and decreased latency Costs for increased context switching and task startup Example: server is infrequently used and operation processing time is small compared to the network data transmission time 10/1/00 ©2000 Objective Interface Systems, Inc. 134 Analysis of Total Concurrency in System

Concurrency is the combination of both processes and threads Multiple ways to get true concurrent operation execution: Multiple Ada tasks (threads) in a server — acting as “worker tasks” Multiple copies of a single server running as separate processes (one the same machine or on different machines) Multiple servers each containing different Object Implementations on separate machines

Analysis of Total Concurrency in System [2] Multiple copies of a Server Mainline is similar to a server with “worker tasks” However, each copy must have a different Server Instance Name Drawbacks: Object Implementations are duplicated (they are shared with a “worker task” approach). Harder to coordinate data and ensure consistency Each new Server causes duplication of code + data Each new Server Mainline process consumes additional OS resources like file descriptors However, if server is a wrapper for non-thread safe legacy code that can’t be made thread safe, then multi-server approach is preferred 10/1/00 ©2000 Objective Interface Systems, Inc. 136 The Role of

Multiple Client Tasks Call and Client can make calls that do return Client Client Server Object not block the entire ORB ORB Impl processes Normally, clients block on Blocked a two-way call while awaiting the return With tasks, only the task’s thread blocks True even if other tasks call the same Server Can have two tasks use the same object reference ORBexpress packages are all multi-tasking safe (reentrant) 10/1/00 ©2000 Objective Interface Systems, Inc. 137

Client-Side Pattern using Tasks Want Asynchronous call Properties: Client doesn’t wait for response from Server Client knows that Server received message and is doing the processing One-way calls give #1 but not #2 Two-way calls give #2 but not #1 Solution: Create a “waiter” task Pass the operation call responsibility to this task Task makes a two-way call Result: Guaranteed connection but no client wait 10/1/00 ©2000 Objective Interface Systems, Inc. 138 Multi-Threaded Servers

Concept Overview Benefits and Reasons The Thread of Control: Single Processing Vs. Multiple “Worker Tasks” Multiple Calls to Impl_Is_Ready Server Multi-Tasking Both Sides Multi-Tasking Protecting Data in an Implementation Terminating Multi-Tasking Servers Server-Side Pattern using Tasks

Concept Overview and Benefits & Reasons Servers may create additional tasks as “worker tasks” These will process incoming requests Advantages: Overlap processing of concurrent requests from clients Prioritized processing of requests Priority can be a parameter This can be used in concert with Ada’s task priorities Tasks can also be used inside of object implementations for concurrency

10/1/00 ©2000 Objective Interface Systems, Inc. 140 The Costs of Tasking Development time: Programmer must expend effort to protect shared data structures from concurrent access Same requirements as any other multi-tasking Ada program Run-time efficiency: Positive gains in responsiveness and decreased latency Costs for increased context switching and task startup Example: server is infrequently used and operation processing time is small compared to the network data transmission time 10/1/00 ©2000 Objective Interface Systems, Inc. 141

Single Processing vs. Multiple “Worker Tasks” If server has no tasks ORB server library uses the thread of the “main” subprogram Enters ORB server library on call to Impl_Is_Ready Stays in event loop processing client requests Processing includes invoking the implementation operation body and returning the response Until no activity for the time out period Single threaded server can respond to one client request at a time All other requests are queued by the ORB library internals 10/1/00 ©2000 Objective Interface Systems, Inc. 142 Single Processing vs. Multiple “Worker Tasks” If server declares multiple “worker tasks” ORB server library uses each thread Each task enters ORB server library on its own call to Impl_Is_Ready Stays in event loop processing client requests Multi-threaded server can respond to many client request at a time N threads allow concurrently processing N client requests from event queue (from any combination of separate clients or client threads) “Extra” requests are queued by ORB library internals Note:Note: Use Use of of multiple multiple tasks tasks implies implies that that implementation implementation must must protect protect itsits own own data data structures structures

Section VII CORBA Performance

Network Performance

ORB Performance

ORB Overhead

In order to judge the performance of an ORB you first have to eliminate or baseline the: Client and server application efficiency Client and server CPU performance Client and server network adapter performance Network speed

Only then can you evaluate the ORB’s overhead!!!

ORB Performance

A High Performance ORB: A High Performance ORB Avoids: Locates objects quickly Making extra copies of data Invokes operations Multiple context switches quickly Making unnecessary system Marshals data quickly calls Uses network transport Flipping endians unnecessarily efficiently Unnecessary mutex seizes and Scales efficiently to large releases numbers of objects, Using unbounded or FIFO interfaces, operations, etc. system calls Provides bounded response time

Things a good ORB avoids doing

Making extra copies of data Context switches Making unnecessary system calls Flipping endians unnecessarily Unnecessary mutex seizes and releases

ORB Performance (cont.)

Things a good ORB does

Looks up objects quickly Looks up operations quickly Marshals data quickly Uses network transport efficiently Scales gracefully to large numbers of objects, interfaces, operations, etc.

10/1/00 ©2000 Objective Interface Systems, Inc. 148 ORB Overhead ORBs represent a (preferably) small piece of the puzzle Client application efficiency Client ORB efficiency Client CPU performance Client network adapter performance Network speed Server network adapter performance Server CPU performance Server ORB efficiency Server application efficiency 10/1/00 ©2000 Objective Interface Systems, Inc. 149

ORB Overhead (cont.)

Let’s analyze a benchmarking application (i.e. time spent in application code is 0)

There are two elements of overhead that a CORBA ORB (or any other middleware adds): Client & Server CPU Time (time) Extra bytes on the wire (space)

In any decently implemented ORB: Time 80-95% of the wall clock time is spent in the protocol stack (TCP, IP, NDIS, NIC, …) 5-20% of the wall clock time is spent in the ORB Space ethernet has 26 octets overhead per frame IP adds 12 octets per packet (one per ethernet frame) TCP adds 24 octets (+options) per packet CORBA IIOP adds 40 to 80 octets per message

ORB Overhead (cont.)

Typical ORB throughput: Desktop ORB ~400 two-way remote invocations per second Browser ORB ~600 two-way remote invocations per second “Tweaked” Research ORB ~1200 two-way remote invocations per second Real-Time ORB (ORBexpress benchmarks used) 2,700 two-way remote invocations per second

Definition of Real-Time for this Discussion Why use CORBA for Real-Time OMG CORBA Standard Process Time Table Concepts Details

Definition of Real-Time for this Discussion L A real-time system is one which ensures time constraints are met L A real-time system produces a value to the overall system which is a function of time

Value Non-Real-Time System Time Value Hard Real-Time System

Time Value Soft Real-Time System

Time

Why Use CORBA in a Real- Time System? [1]

… for flexibility Many real-time systems must run on multiple computers & are written in mixed languages CORBA solves many real-time system integration problems if the ORB is: fast predictable small has native support for embedded transports

CORBACORBA doesn doesn’t’t have have to to be be slow, slow, bulky bulky or or indeterminate indeterminate

… to save money! Future system changes are much easier change CPU type change O/S change transport (bus or network) Upgrade components one at a time New components can interoperate with old components

Two Different Views of Real-Time CORBA

Two communities see both “real-time” and “real- time CORBA” differently Hard Real-Time: End-to-end predictability Fixed scheduling with priorities Static allocation of memory a 2nd order requirement Soft Real-Time: Priority based scheduling Allocation of resources Allocation of memory is a 1st order requirement

OMG lets RFP Multiple vendors propose response Vendors work to resolve differences Resubmit responses Ideally, a single consolidated response is submitted Possibly, multiple revised responses re-submitted (may occur more than once) OMG selects standard Vendors implement new standard

OMG Real-Time CORBA Standard: Timetable OMG Issues RFP 27-Sep-1997 Initial submissions 19-Jan-1998 Revised (joint) submissions 18-Oct-1998 Presentations 9-Nov-1998 Second Revised submission 2-March-1999 Presentations 23-Mar-1999 OMG ORBOS vote 24-Mar-1999 Final Adoption 2-June-1999 Products Introduced 2nd Quarter 2000 10/1/00 ©2000 Objective Interface Systems, Inc. 160 Real-Time CORBA Standard’s Goals

Extension to CORBA 2.2 and the Messaging Service specification Support developers in meeting real-time requirements Provide interoperability with conventional CORBA ORBs

Concepts of RT CORBA

Objective Predictability Ingredients of a Real-Time ORB Priorities Threads Mutex

Respect thread priorities between client and server Bound duration of thread priority inversions Bound latencies of operation invocations Provide explicit control over resources Thread pools Queues Transport connections

Real-Time System Predictability

Client Application Predictability Server Application Predictability Client Priority Server Priority

Preemption Client Preemption Server

Predictable ORB ORB Predictable Memory Memory Management Management

Network Predictable Invocation Predictable, Bounded Priority Propagation Predictable Transport Algorithms

CORBACORBA isis anan importantimportant partpart ofof thethe solution!solution!

Deterministic/Predictable Behavior: Developers must be able to analyze application to assess ability to satisfy real-time constraints Operations and ORB must exhibit bounded, repeatable behavior ORB vendor must document upper bound of execution times and priority inversions Predictable remote operations across machines

Ingredients of a Real-Time ORB

Predictable ORB infrastructure Predictable memory management Use of predictable, bounded algorithms Analysis and documentation of behavior Distributed Priority Inheritance and Priority Ceiling Locking Protocol Predictable transport (i.e. not TCP) Native ATM (ANI) Reflective Memory FDDI Shared Memory FireWire (IEEE 1394) VME/PCI ORB must understand and use deterministic transports & Quality of Service (QoS) metrics ORB must allow designer to control QoS and map → → 10/1/00them from client ©2000 Objectivenetwork Interface Systems, Inc. server 166 Real-Time CORBA Priority

Universal, platform-independent priority scheme Native operating system priority mapped to and from CORBA Priority through default or application-defined priority mapping Provides ability to propagate priority from client to server 2 Priority Models: Client Propagated Priority Model Server Set Priority Model

CORBA Priority Propagation CORBACORBA PRIORITYPRIORITY 2828 Windows RTOS:RTOS: ServerServer ThreadThread executesexecutes passedpassed inin NT:NT: ClientClient atat prioritypriority 6464 Thread serviceservice contextcontext Thread Client Server prioritypriority 77

ORB ORB

OS priority 77 mappedmapped CORBACORBA PRIORITYPRIORITY 2828 mappedmapped toto CORBACORBA toto RTOSRTOS prioritypriority 6464 PRIORITYPRIORITY Network 2828

“Thread” is the schedulable entity POSIX Threads Native (RTOS) Priorities v.s. CORBA Priorities 0 .. 32767 32767 is the “highest” priority Universal priority scheme User installable mapping functions

ORB Resource Control Server-Side Threadpools Preallocation to ensure a certain number of concurrent invocations Partitioning of threads by priority Mutex that implements priority inheritance Coordinates contention for system resources Transport connection management Multiplexed connections Priority Banded connections Private connections

The Essential Abstraction for Resource Protection

Context for Priority Inheritance Discussions

Makes the mutex used by the ORB available to the application developer

Mutex IDL: module RT_CORBA { interfaceinterface MutexMutex {{ void lock(); void unlock(); boolean try_lock (in(in TimeBase::TimeTTimeBase::TimeT max_wait);max_wait); // if max_wait = 0 then return immediately };}; interfaceinterface ORBORB :: CORBA::ORBCORBA::ORB {{ ...... Mutex create_mutex(); ...... };}; };}; 10/1/00 ©2000 Objective Interface Systems, Inc. 172