Common Object Request Broker Architecture CORBA

1
Lecture 14

• Common Object Request Broker Architecture (CORBA)

2
Overview

• Introduction
• Distributed Applications
• CORBA Architecture
• OMG Reference Model
• CORBA ORB Architecture
• Standard for Distributed Objects
• CORBA Services
• CORBA Products
• Interfaces Design Language

3
Introduction

• CORBA is the acronym for Common Object Request
  Broker Architecture
• Developed by a consortium of vendors through the
  Object Management Group (OMG)
• CORBA is an architecture and specification for
  creating, distributing, and managing distributed
  program objects in a network
• Allows programs at different locations and
  developed by different vendors to communicate in
  a network through an "interface broker."

4
Distributed Applications

• CORBA products provide a framework for the
  development and execution of distributed
  applications.
• Some applications by their very nature are
  distributed across multiple computers
• The data used by the application are distributed
• The computation is distributed
• The users of the application are distributed

5
Distributed Data

• Some applications must execute on multiple
  computers because the data that the application
  must access exist on multiple computers for
  administrative and ownership reasons.
• The owner may permit the data to be accessed
  remotely but not stored locally. Or perhaps the
  data cannot be co-located and must exist on
  multiple heterogeneous systems for historical
  reasons.

6
Computation is Distributed

• Some applications execute on multiple computers
  in order to take advantage of multiple processors
  computing in parallel to solve some problem.
• Other applications may execute on multiple
  computers in order to take advantage of some
  unique feature of a particular system.
• Distributed applications can take advantage of
  the scalability and heterogeneity of the
  distributed system.

7
Users are Distributed

• Some applications execute on multiple computers
  because users of the application communicate and
  interact with each other via the application.
• Each user executes a piece of the distributed
  application on his or her computer, and shared
  objects, typically execute on one or more
  servers.

8
Design Issues in Distributed Systems

• Communication
• The communication between objects in the same
  process is orders of magnitude faster than
  communication between objects on different
  machines.
• You should avoid designing distributed
  applications in which two or more distributed
  objects have very tight interactions.
• If they do have tight interactions, they should
  be co-located.
• Failures
• Co-located objects fail together if the process
  in which they execute fails, both objects fail.
• Distributed objects across process boundaries,
  can fail independently.
• Designer of the objects must be concerned with
  each of the object's behavior in the event the
  other object has failed.
• Concurrent Access
• Consider the possible orderings of access to
  objects and use synchronization mechanisms to
  control concurrent access to shared objects.
• Each distributed object is operating in a
  different thread of control.
• A distributed object may have multiple concurrent
  clients.
• Developers must consider concurrent access to
  objects and use the necessary synchronization
  mechanisms.
• Security
• When the objects are on different machines, you
  need to use security mechanisms to authenticate
  the identity of the other object.

9
Distributed Object Systems

• Distributed object systems are distributed
  systems in which all entities are modeled as
  objects.
• Distributed object systems are a popular paradigm
  for object-oriented distributed applications.
• Since the application is modeled as a set of
  cooperating objects, it maps very naturally to
  the services of the distributed system.
• In spite of the natural mapping from
  object-oriented modeling to distributed object
  systems, do not forget the realities of
  distributed systems.
• Process boundaries really do matter and they will
  impact your design.

10
CORBA Architecture

• The essential concept in CORBA is the Object
  Request Broker (ORB).
• ORB support in a heterogeneous network means that
  a client program can request services from a
  server without having to know the location or
  interface of the server
• To make requests or return replies between the
  ORBs, programs use the General Inter-ORB Protocol
  (GIOP) and, for the Internet, its Internet
  Inter-ORB Protocol (IIOP).
• CORBA automates many common network programming
  tasks
• Object registration, location, and activation
• Request demultiplexing
• Framing and error-handling
• Parameter marshalling and demarshalling
• Operation dispatching

11
OMG Reference Model Architecture
12
OMG Reference Model Architecture (Cont)

• Object Services
• Domain-independent interfaces that are used by
  many distributed object programs.
• Naming Service -- which allows clients to find
  objects based on names
• Trading Service -- which allows clients to find
  objects based on their properties.
• Common Facilities
• Oriented towards end-user applications
• Example - facilitating the linking of a
  spreadsheet object into a document
• Domain Interfaces
• Oriented towards specific application domains.
• Example - telecommunications, medical, and
  financial domains.
• Application Interfaces
• Developed specifically for a given application.
• Application-specific, and because the OMG does
  not develop applications (only specifications),
  these interfaces are not standardized.

13
CORBA ORB Architecture
14
CORBA Objects

• CORBA applications are composed of objects,
  individual units of running software that combine
  functionality and data
• Programming entity that consists of an identity,
  an interface, and an implementation, which is
  known as a Servant.
• Servant
• This is an implementation programming language
  entity that defines the operations that support a
  CORBA IDL interface.
• Servants can be written in a variety of
  languages, including C, C, Java, Smalltalk, and
  Ada.

15
CORBA Client

• Program entity that invokes an operation on an
  object implementation.
• Accessing the services of a remote object should
  be transparent to the caller.
• Ideally, it should be as simple as calling a
  method on an object, i.e., obj-gtop(args)
• The interface between the client and server is
  simply a contract that specifies what kind of
  services are provided by the server
• CORBA interfaces are specified in a special
  definition language known as the Interface
  Definition Language (IDL).

16
Object Request Broker (ORB)

• The ORB provides a mechanism for transparently
  communicating client requests to target object
  implementations.
• The ORB simplifies distributed programming by
  decoupling the client from the details of the
  method invocations.
• Client requests appear to be local procedure
  calls.
• When a client invokes an operation, the ORB is
  responsible for finding the object
  implementation, delivering the request to the
  object, and returning any response to the caller.

17
ORB Interface

• An ORB is a logical entity that may be
  implemented in various ways
• To decouple applications from implementation
  details, the CORBA specification defines an
  abstract interface for an ORB.
• This interface provides various helper functions
• Converting object references to strings and vice
  versa
• Creating argument lists for requests made through
  the dynamic invocation interface.

18
CORBA IDL Stubs and Skeletons

• CORBA IDL stubs and skeletons serve as the
  glue'' between the client and server
  applications, respectively, and the ORB.
• The transformation between CORBA IDL definitions
  and the target programming language is automated
  by a CORBA IDL compiler.
• The use of a compiler reduces the potential for
  inconsistencies between client stubs and server
  skeletons and increases opportunities for
  automated compiler optimizations.

19
Dynamic Invocation Interface (DII)

• The CORBA DII presents an API that enables
  objects and their methods to be specified and
  called at run-time
• This interface allows a client to directly access
  the underlying request mechanisms provided by an
  ORB.
• Applications use the DII to dynamically issue
  requests to objects without requiring IDL
  interface-specific stubs to be linked in.
• DII also allows clients to make non-blocking
  deferred synchronous (separate send and receive
  operations) and one-way (send-only) calls.

20
Dynamic Skeleton Interface (DSI)

• This is the server side's analogue to the client
  side's DII.
• The DSI allows an ORB to deliver requests to an
  object implementation that does not have
  compile-time knowledge of the type of the object
  it is implementing.
• The client making the request has no idea whether
  the implementation is using the type-specific IDL
  skeletons or is using the dynamic skeletons.

21
Object Adapter

• One of the object adaptor's functions is to map
  from object reference to an object
• This assists the ORB with delivering requests to
  the object and with activating the object.
• More importantly, an object adapter associates
  object implementations with the ORB.
• Object adapters can be specialized to provide
  support for certain object implementation styles
• OODB object adapters for persistence
• Library object adapters for non-remote objects.

22
Standard for Distributed Objects

• One of the goals of the CORBA specification is
  that clients and object implementations are
  portable.
• The CORBA specification defines an application
  programmer's interface (API) for clients of a
  distributed object as well as an API for the
  implementation of a CORBA object.
• Code written for one CORBA product could, with a
  minimum of effort, be rewritten to work with a
  different product.
• Reality of CORBA products is that CORBA clients
  are portable but object implementations need some
  rework to port from one CORBA product to another.

23
CORBA Services

• CORBA standard defines a set of distributed
  services to support the integration and
  interoperation of distributed objects.
• CORBA Services or COS
• Defined as standard CORBA objects with IDL
  interfaces, sometimes referred to as "Object
  Services."

24
CORBA Services (Cont)

• Object life cycle
• Defines how CORBA objects are created, removed,
  moved, and copied
• Naming
• Defines how CORBA objects can have friendly
  symbolic names
• Events
• Decouples the communication between distributed
  objects
• Relationships
• Provides arbitrary typed n-ary relationships
  between CORBA objects
• Externalization
• Coordinates the transformation of CORBA objects
  to and from external media
• Transactions
• Coordinates atomic access to CORBA objects
• Concurrency Control
• Provides a locking service for CORBA objects in
  order to ensure serializable access
• Property
• Supports the association of name-value pairs with
  CORBA objects
• Trader
• Supports the finding of CORBA objects based on
  properties describing the service offered by the
  object
• Query

25
CORBA Products

• CORBA is a specification several vendors provide
  CORBA products for various programming languages
• The Java 2 ORB
• The Java 2 ORB comes with Sun's Java 2 SDK. It is
  missing several features.
• VisiBroker for Java
• A popular Java ORB from Inprise Corporation.
  VisiBroker is also embedded in other products.
  For example, it is the ORB that is embedded in
  the Netscape Communicator browser.
• OrbixWeb
• A popular Java ORB from Iona Technologies.
• WebSphere
• A popular application server with an ORB from
  IBM.
• Netscape Communicator
• Netscape browsers have a version of VisiBroker
  embedded in them. Applets can issue request on
  CORBA objects without downloading ORB classes
  into the browser. They are already there.
• Various free or shareware ORBs
• CORBA implementations for various languages are
  available for download on the web from various
  sources.

26
CORBA Objects are Described by IDL Interfaces

• The OMG Interface Definition Language IDL
  supports the specification of object interfaces.
• An object interface indicates the operations the
  object supports, but not how they are
  implemented.
• The implementation of a CORBA object is provided
  in a standard programming language
• IDL interfaces are programming language neutral.
• IDL defines language bindings for many different
  programming languages.
• Currently, the OMG has standardized on language
  bindings for the C, C, Java, Ada, COBOL,
  Smalltalk, Objective C, and Lisp programming
  languages.
• OMG IDL describes without regards to any
  particular programming language
• Modularized object interfaces
• Operations and attributes that an object supports
  
• Exceptions raised by an operation
• Data types of an operation return value, its
  parameters, and an object's attributes
• The IDL data types are
• Basic data types (long, short, string, float...)
• Constructed data types (struct, union, enum,
  sequence)
• Typed object references
• The any type, a dynamically typed value

27
Interface Design Language (IDL)

• The key to developing applications that
  interoperate in heterogeneous distributed systems
  is to separate interfaces from
  implementations
• The CORBA IDL is an object-oriented language that
  enables developers to specify interfaces that
  describe methods and attributes of objects that
  may be distributed throughout a computer system

28
Interface Definition Language (IDL) (cont'd)

• CORBA IDL separates interface from implementation
  . And also
• Provides a hook' into services offered by the
  software bus
• Services may collaborate in either a
  client/server or peer-to-peer manner .
• A CORBA IDL compiler is used to automatically
  produce the client stubs and server skeletons
• Marshaling routines
• Client proxies
• Implementation class interfaces and
  initialization mechanisms

29
Interface Definition Language (IDL) (cont)

• Many IDLs are currently available
• OSI ASN.1, OSI GDMO, SNMP SMI, DCE IDL, CORBA
  IDL, ONC's XDR, etc.
• CORBA IDL is designed to map onto multiple
  programming languages

30
Interface Definition Language (IDL) (cont'd)

• CORBA IDL is a superset of a subset of C
• Not a complete programming language, it is only
  used to define interfaces
• CORBA IDL supports the following features
• Modules
• Interfaces
• Methods
• Attributes
• Inheritance
• Constants
• struct, enum, union, typedef
• Sequence
• Arrays
• Exceptions

31
Summary

• CORBA specifies the following functions of an
  Object Request Broker (ORB)
• Interface Definition Language (IDL)
• A mapping from IDL onto a programming language.
• An Interface Repository
• Can be queried at run-time .
• A Dynamic Invocation Interface
• Used to compose method requests at run-time
• The Basic Object Adaptor
• Allows server programmers to interface their code
  with an ORB