Lab CORBA

1
Lab CORBA

• CORBA Overview

2
Introduction

• CORBA addresses two challenges of developing
  distributed systems
• Making distributed application development no
  more difficult than developing centralized
  programs
• Easier said than done due to
• Partial failures
• Impact of latency
• Load balancing
• Event ordering
• Providing an infrastructure to integrate
  application components into a distributed system
• CORBA is an enabling technology"

3
Overview of CORBA

• The Common Object Request Broker Architecture
  (CORBA) OMG95a is an emerging open distributed
  object computing infrastructure being
  standardized by the Object Management Group
  (OMG).
• CORBA automates many common network programming
  tasks such as object registration, location, and
  activation request demultiplexing framing and
  error-handling parameter marshalling and
  demarshalling and operation dispatching.
• See the OMG Web site for more overview material
  on CORBA

4
OMG Reference Model
5
OMG Reference Model Components

• Object Services -- These are domain-independent
  interfaces that are used by many distributed
  object programs. (a service providing for the
  discovery of other available services)
• The Naming Service -- which allows clients to
  find objects based on names
• The Trading Service -- which allows clients to
  find objects based on their properties.
• Common Facilities -- Services that are oriented
  towards end-user applications.
• Distributed Document Component Facility (DDCF), a
  compound document Common Facility based on
  OpenDoc. (linking of a spreadsheet object into a
  report document)
• Domain Interfaces Services oriented towards
  specific application domains.
• OMG RFPs issued for Domain Interfaces is for
  Product Data Management (PDM) Enablers for the
  manufacturing domain. Other OMG RFPs will soon be
  issued in the telecommunications, medical, and
  financial domains.
• Application Interfaces - These are interfaces
  developed specifically for a given application.
• These interfaces are not standardized.
• Candidates for future OMG standardization.

6
CORBA ORB Architecture
7
Primary CORBA ORB Components

• Object -- This is a CORBA 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.
• Client -- This is the program entity that invokes
  an operation on an object implementation.
  Accessing the services of a remote object should
  be transparent to the caller.
• 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.
• ORB Interface -- An ORB is a logical entity that
  may be implemented in various ways (such as one
  or more processes or a set of libraries). To
  decouple applications from implementation
  details, the CORBA specification defines an
  abstract interface for an ORB.
• This interface provides various helper functions
  such as converting object references to strings
  and vice versa.

8
Primary CORBA ORB Components (Cont)

• CORBA IDL stubs and skeletons -- CORBA IDL stubs
  and skeletons serve as the glue'' between the
  client and server applications, respectively, and
  the ORB.
• Dynamic Invocation Interface (DII) -- 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.
• 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.
• Object Adapter -- 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.

9
The ACE ORB (TAO)

• The ACE ORB (TAO) -- TAO is a real-time
  implementation of CORBA built using the framework
  components and patterns provided by ACE.
• TAO contains the network interface, OS,
  communication protocol, and CORBA middleware
  components and features.
• TAO is based on the standard OMG CORBA reference
  model, with the enhancements designed to overcome
  the shortcomings of conventional ORBs for
  high-performance and real-time applications.
• TAO, like ACE, is freely available, open source
  software.

10
ACE Overview

• The ADAPTIVE Communication Environment (ACE) is
  an open-source object-oriented framework for
  concurrent communication software.
• The communication software tasks provided by ACE
  include
• event demultiplexing and event handler
  dispatching,
• signal handling,
• service initialization,
• interprocess communication,
• shared memory management,
• message routing,
• dynamic (re)configuration of distributed
  services,
• concurrent execution and synchronization.
• ACE is targeted for developers of
  high-performance and real-time communication
  services and applications.
• ACE is supported commercially by multiple
  companies using an open-source business model.

11
Advantages of ACE

• Increased portability -- ACE components make it
  easy to write concurrent networked applications
  on one OS platform and quickly port them to many
  other OS platforms.
• Increased software quality -- ACE components are
  designed using many key patterns that increase
  key qualities, such as flexibility,
  extensibility, reusability, and modularity, of
  communication software.
• Increased efficiency and predictability -- ACE is
  carefully designed to support a wide range of
  application quality of service (QoS)
  requirements, including low latency for
  delay-sensitive applications, high performance
  for bandwidth-intensive applications, and
  predictability for real-time applications.
• Easier transition to standard higher-level
  middleware -- ACE provides the reusable
  components and patterns used in The ACE ORB (TAO)

12
ACE Components
13
ACE OS Adapter Layer

• This layer resides directly atop the native OS
  APIs that are written in C. It provides a small
  footprint, "POSIX-like" OS adaptation layer
• Platform-specific dependentencies
• Concurrency and synchronization -- ACE's
  adaptation layer encapsulates OS APIs for
  multi-threading, multi-processing, and
  synchronization.
• Interprocess communication (IPC) and shared
  memory -- ACE's adaptation layer encapsulates OS
  APIs for local and remote IPC and shared memory.
• Event demultiplexing mechanisms -- ACE's
  adaptation layer encapsulates OS APIs for
  synchronous and asynchronous demultiplexing
  I/O-based, timer-based, signal-based, and
  synchronization-based events.
• Explicit dynamic linking -- ACE's adaptation
  layer encapsulates OS APIs for explicit dynamic
  linking, which allows application services to be
  configured at installation-time or run-time.
• File system mechanisms -- ACE's adaptation layer
  encapsulates OS file system APIs for manipulating
  files and directories.

14
C Wrappers for OS Interfaces

• The ACE C wrapper encapsulates and enhances the
  native OS concurrency, communication, memory
  management, event demultiplexing, dynamic
  linking, and file system APIs.
• Applications can combine and compose these
  wrappers by selectively inheriting, aggregating,
  and/or instantiating the following components
• Concurrency and synchronization components -- ACE
  abstracts native OS multi-threading and
  multi-processing mechanisms like mutexes and
  semaphores to create higher-level OO concurrency
  abstractions like Active Objects and Polymorphic
  Futures.
• IPC and filesystem components -- The ACE C
  wrappers encapsulate local and/or remote IPC
  mechanisms, such as sockets, TLI, UNIX FIFOs and
  STREAM pipes, and Win32 Named Pipes. In addition,
  the ACE C wrappers encapsulate the OS
  filesystem APIs.
• Memory management components -- The ACE memory
  management components provide a flexible and
  extensible abstraction for managing dynamic
  allocation and deallocation of interprocess
  shared memory and intraprocess heap memory.

15
ACE Frameworks

• This framework supports the dynamic configuration
  of concurrent distributed services into
  applications.
• The framework portion of ACE contains the
  following components
• Event demultiplexing components -- The ACE
  Reactor and Proactor are extensible,
  object-oriented demultiplexers that dispatch
  application-specific handlers in response to
  various types of I/O-based, timer-based,
  signal-based, and synchronization-based events.
• Service initialization components -- The ACE
  Acceptor and Connector components decouple the
  active and passive initialization roles,
  respectively, from application-specific tasks
  that communication services perform once
  initialization is complete.
• Service configuration components -- The ACE
  Service Configurator supports the configuration
  of applications whose services may be assembled
  dynamically at installation-time and/or run-time.
  
• Hierarchically-layered stream components -- The
  ACE Streams components simplify the development
  of communication software applications, such as
  user-level protocol stacks, that are composed of
  hierarchically-layered services.
• ORB adapter components -- ACE can be integrated
  seamlessly with single-threaded and
  multi-threaded CORBA implementations via its ORB
  adapters.

16
Distributed Services and Components

• ACE provides a standard library of distributed
  services that are packaged as self-contained
  components
• These service components play two roles in ACE
• Factoring out reusable distributed application
  building blocks -- These service components
  provide reusable implementations of common
  distributed application tasks such as naming,
  event routing, logging, time synchronization, and
  network locking.
• Demonstrating common use-cases of ACE components
  -- The distributed services also demonstrate how
  ACE components like Reactors, Service
  Configurators, Acceptors and Connectors, Active
  Objects, and IPC wrappers can be used effectively
  to develop flexible, efficient, and reliable
  communication software.

17
Higher-Level Distributed Computing Middleware
Components

• Developing robust, extensible, and efficient
  communication applications is challenging
• Network addressing and service identification.
• Presentation conversions, such as encryption,
  compression, and network byte-ordering
  conversions between heterogeneous end-systems
  with alternative processor byte-orderings.
• Process and thread creation and synchronization.
• System call and library routine interfaces to
  local and remote interprocess communication (IPC)
  mechanisms.
• Can alleviate some of the complexity of
  developing communication applications by
  employing higher-level distributed middleware,
  such as CORBA, DCOM, or Java RMI.
• Higher-level distributed middleware resides
  between clients and servers and automates many
  tedious and error-prone aspects of distributed
  application development,
• Authentication, authorization, and data security.
  
• Service location and binding.
• Service registration and activation.
• Implementing message framing atop byte
  stream-oriented communication protocols like TCP.
  
• Presentation conversion issues involving network
  byte-ordering and parameter marshaling.

18
TAO Overview
19
OMG IDL Compiler

• A OMG IDL compiler generates client stubs and
  server skeletons
• Stubs and skeletons automate the following
  activities (in conjunction with the ORB)
• Client proxy factories
• Parameter marshalling/demarshalling
• Implementation class interface generation
• Object registration and activation
• Object location and binding
• Per-object/per-process lters

20
OMG IDL Features

• OMG IDL is a superset of a subset of C
• Not a complete programming language, it only
  defines interfaces
• OMG IDL supports the following features
• modules
• interfaces
• methods
• attributes
• inheritance
• arrays
• sequence
• struct, enum, union, typedef
• consts
• exceptions

21
Example Distributed Logging Facility

• The logging server collects, formats, and outputs
  logging records forwarded from applications
  residing throughout a network or inter-network
• An application interacts with the server logger
  via a CORBA interface

22
Server-Side OMG IDL Specification
// IDL specification interface Logger // Types
of logging messages enum Log_Priority
LOG_DEBUG, // Debugging messages LOG_WARNING,
// Warning messages LOG_ERROR, //
Errors LOG_EMERG // A panic condition, normally
broadcast exception Disconnected
struct Log_Record Log_Priority type //
Type of logging record. long host_addr // IP
address of the sender. long time // Time
logging record generated. long pid // Process
ID of app. generating the record. sequenceltchargt
msg_data // Logging record data. //
Transmit a Log_Record to the logging server void
log (in Log_Record log_rec) raises
(Disconnected) attribute boolean verbose //
Use verbose formatting
23
Writing Main Server Program
// Shared activation int main (void) //
BOAImpl instance. Logger_i logger () try
// Will block forever waiting for
incoming // invocations and dispatching method
callbacks CORBAOrbix.impl_is_ready
("Logger") catch (...) cerr ltlt "server
failed\n" return 1 cout ltlt "server
terminating\n" return 0
24
Exception Handling

• The preceding example illustrated how CORBA uses
  C exception handling to propagate errors.
• However, many C compilers don't support
  exceptions yet
• Therefore, CORBA implementations provide an
  alternative mechanism for handling errors

// Shared activation int main (void) // Start
with verbose mode enabled Logger_i logger
(true) TRY // Will block forever waiting for
incoming // invocations and dispatching method
callbacks CORBAOrbix.impl_is_ready ("logger",
IT_X) CATCHANY cerr ltlt "server failed due
to " ltlt IT_X ltlt endl ENDTRY cout ltlt "server
terminating\n" return 0
25
Binding a Client to a Target Object

• Steps for binding a client to a target object
• A CORBA client (requestor) obtains an object
  reference" from a server
• May use a name service or locator service
• This object reference serves as a local proxy for
  the remote target object
• Object references may be passed as parameters to
  other remote objects
• The client may then invoke methods on its proxy

26
Client-Side Example
int main (void) LoggerRef logger Log_Record
log_rec logger Logger_bind () // Bind to
any logger. // Initialize the log_record log_rec
.type LoggerLOG_DEBUG log_rec.time time
(0) log_rec.host_addr // ... // ... try
logger-gtverbose (false) // Disable verbose
logging. logger-gtlog (log_rec) // Xmit logging
record. catch (LoggerDisconnected) cerr
ltlt "logger disconnected" ltlt endl catch (...)
/ ... / return 0