Chapter 17: CORBA case study

By Carrie Mace and William Coley Redesigned by nav

What is CORBA ?
CORBA is a middleware design
Allows application programs to communicate without restriction to:
Programming languages Hardware platforms Software platforms Networks they communicate over

Applications and CORBA

Applications are built from CORBA objects Objects implement interfaces defined in CORBAs interface definition language(IDL) Clients use remote method invocation to access methods in the interface design language The Object Request Broker is the middleware component that supports remote method invocation

Main Components of CORBAs RMI framework

CORBA IDL (Interface Definition Language) CORBA architecture GIOP (General Inter-ORB Protocol) defines external data representation IIOP - defining a standard form for remote object references

CORBA architecture
Implementation repository client
request client program Proxy for A ORB core reply Or dynamic skeleton ORB core object adapter

interface repository server

skeleton

servant A

Or dynamic invocation

Figure 17.6 from the textbook: The Main Components of the CORBA architecture

Object Request Broker Core

Carries out the request-reply protocol Provides an interface that includes:
Operations enabling start and stop Operations to convert between remote objects and strings Operations to provide argument lists for references using dynamic invocation

Object Adapter
Bridges the gap between CORBA objects with IDL interfaces and the programming language interfaces of the corresponding servant.
Creates remote object interfaces Dispatches each RMI to the appropriate skeleton Activates objects Gives each object a unique object name

Skeletons
Classes generated in the language of the server by an IDL compiler Unmarshals arguments in requests Marshals exceptions and replies in responses

Client stubs/proxies
In the clients language Marshals the arguments in invocation requests Unmarshals the exceptions and results in replies

Implementation Repository
Responsible for activating registered servers on demand Locates servers currently running Uses the object adapter name to refer to servers when registering or activating them
Implementation Repository entry:
Object adapter name Pathname of object implementation Hostname and port number of server

Interface Repository
Provides information about registered IDL interfaces to clients and servers that require it Not required if static invocation is used for client stubs and server skeletons Not all Object Request Brokers provide an interface repository

Dynamic Invocation Interface

Used when not practical to use proxies Client may not have the appropriate proxy class to invoke a remote service The client can obtain from the interface repository the needed information to construct an invocation

Dynamic Skeleton Interface

Allows the CORBA object to accept invocations when a skeleton doesnt exist Perhaps the interface was unknown at compile time Inspects the request for target object, method to be invoked, and arguments

CORBA architecture
Implementation repository client
request client program Proxy for A ORB core reply Or dynamic skeleton ORB core object adapter

interface repository server

skeleton

servant A

Or dynamic invocation

Figure 17.6 from the textbook: The Main Components of the CORBA architecture

CORBA: Interface Definition Language

Defines modules, interfaces, types, attributes and method signatures Same lexical rules as C++ Has additional keywords to support distribution (i.e. interface, any, attribute,

in, out, inout, readonly, raises)

IDL Modules
Allows interfaces and IDL type definitions to be organized into logical units Defines a naming scope Prevents names defined within a module from clashing with names defined outside of it

IDL Interfaces
Describes the methods that are available in CORBA objects that implement that interface Defines a set of operations and attributes Generally depends on a set of types defined within it

IDL Methods
General form of a method signature:

[oneway]<return_type><method_name> (parameter1,,parameterL)[raises(except1, ,exceptN)][context(name1,,nameM)]

IDL Methods Continued

Parameters labeled as in are passed to the invoked object Parameters labeled as out are to be returned to the client Parameters labeled as inout are seldom used

IDL Methods Continued

Return type may be void if no value is to be returned The expression oneway is optional. Made with maybe semantics
Indicates client is not blocked

The expression raises is optional

Indicates user-defined exceptions

The expression context is also optional

Supplies mappings from string names to string values

IDL Types
Supports 15 primitive types Constants can be declared Special type called Object
values are remote object references

6 constructed types, all passed by value

arrays and sequences used as arguments must be defined in typedefs

No data type can contain references

Attributes of IDL interfaces

Attributes are private to CORBA objects
Each attribute declared results in the IDL compiler generating methods to retrieve and set the attribute

Attributes can be readonly

Only the retrieve method is generated by the IDL compiler

IDL interfaces: Inheritance

Extended interfaces can redefine types, constants, and exceptions Not allowed to redefine methods Can extend more than one interface
An interface may not inherit methods or attributes with common names from two different interfaces

How Legacy Code is Handled

Legacy code is existing code designed without distributed objects in mind Legacy code can become a CORBA object by
Defining an IDL interface for the code Providing implementation of the object adaptor and skeletons

CORBA Remote Object References

IOR: Interoperable Object References
Defined in CORBA 2.0

Format:
IDL interface type Interface repository identifier protocol and address details Object Key adapter object IIOP host domain port name name name number

Transient IORs last as long as the hosting process. Persistent IORs last between activations of the CORBA objects.

CORBA Services
Provide generic facilities that may be used by a wide variety of applications
Naming Service Event and Notification Service Security Service Transaction and Concurrency Services Trading Services Persistent Object Service

Naming Service
Allows names to be bound to the remote object references A naming context is the scope within which a set of names applies CORBA objects are given hierarchical names, which cannot be used as pathnames Allows for the Federation of Naming Services.
Each server provides a subset of the naming graph

CORBA Event Service

Defines interfaces allowing objects of interest to communicate notifications to subscribers Event channels: allow multiple suppliers to communicate with multiple consumers in an asynchronous manner

CORBA Notification Service

Extends the CORBA Event Service Notifications may be data structures Consumers may use filters Suppliers may discover what events consumers are interested in Possible to configure the properties of a channel, a proxy, or an event

CORBA Security Service

Authentication of users and servers Access controls can be applied to CORBA objects Auditing by servers of remote method invocations Facilities of non-repudiation
Verifies an invocation was carried out

Trading Services
Allows CORBA objects to be located by attributes Database contains mapping from service types and their attributes to the remote object reference of CORBA objects Can form federations that
Use their own database Can perform queries on behalf of other clients

Concurrency and Transaction Services

Allows distributed CORBA objects to participate in flat and nested transactions RMI calls are introduced with begin, commit or

rollback

Clients can suspend or resume transactions Concurrency control services use locks to control access to CORBA object
Can be used within transactions Can be used independent of transactions

Persistent Object Service

Suitable for use as a persistent object store for CORBA objects Can be implemented using
Files A Relational Database System An Object-Oriented Database System

The data store request to the POS can be implemented by the client or by the CORBA object

More Information
http://htm4.ee.queensu.ca:8000/ling/corb a.html http://www.omg.org/gettingstarted/corba faq.htm http://www.cs.indiana.edu/hyplan/kksiaze k/tuto.html http://www.cs.wustl.edu/~schmidt/corba. html