Lab CORBA - PowerPoint PPT Presentation

1 / 26
About This Presentation
Title:

Lab CORBA

Description:

... be written in a variety of languages, including C, C , Java, Smalltalk, and Ada. ... struct, enum, union, typedef. consts. exceptions. CS539 Client/Server ... – PowerPoint PPT presentation

Number of Views:50
Avg rating:3.0/5.0
Slides: 27
Provided by: course61
Category:
Tags: corba | enum | lab

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com