Title: Lab CORBA
1Lab CORBA
2Introduction
- 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"
3Overview 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
4OMG Reference Model
5OMG 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.
6CORBA ORB Architecture
7Primary 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.
8Primary 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.
9The 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.
10ACE 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.
11Advantages 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)
12ACE Components
13ACE 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.
14C 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.
15ACE 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.
16Distributed 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.
17Higher-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.
18TAO Overview
19OMG 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
20OMG 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
21Example 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
22Server-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
23Writing 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
24Exception 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
25Binding 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
26Client-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