CORBA Framework Elements - PowerPoint PPT Presentation

About This Presentation
Title:

CORBA Framework Elements

Description:

Incarnate. Etherealize. Default Servant. Server details. Host, ... Incarnation: binding the servant object to CORBA object. Etherealization: break the binding ... – PowerPoint PPT presentation

Number of Views:192
Avg rating:3.0/5.0
Slides: 27
Provided by: shangp
Learn more at: http://www.cs.iit.edu
Category:

less

Transcript and Presenter's Notes

Title: CORBA Framework Elements


1
CORBA Framework Elements
  • Object Request Broker (ORB)
  • This is the object manager in CORBA
  • Mechanisms for specifying interfaces
  • Interface Definition Language (IDL) - for static
    interface definitions
  • Dynamic Invocation Interface (DII) - lets clients
    access interfaces as first-class objects at
    run-time from an Interface Repository.
  • Internet Inter-Orb Protocol (IIOP)
  • A binary protocol for communication between ORBs.
  • Was added in CORBA 2.0

2
Object Request Broker (ORB)

There can be more than one object adapters
3
Object Request Broker (ORB)
  • The Object Manager in CORBA
  • Both on the client side and the server side
    (allows agents to act as both clients and servers
    of remote objects)
  • On client side the ORB is responsible for
  • accepting requests for a remote object
  • finding implementation of the object
  • accepting client-side reference to the remote
    object(converted to a language specific form,
    e.g., a Java stub object)
  • routing client method calls through the object
    reference to the object implementation
  • On server side the ORB
  • lets object servers register new objects
  • receives requests from the client ORB
  • uses objects skeleton interface to invoke
    objects activation method
  • creates reference for new object and sends it
    back to client

4
Internet Inter-Orb Protocol (IIOP)
  • CORBA specification is neutral with respect to
    network protocols
  • the CORBA standard specifies what is known as the
    General Inter-ORB Protocol (GIOP)
  • GIOP is a high-level standard protocol for
    communication between ORBs
  • not used directly instead, it is specialized by
    a particular protocol that would then be used
    directly
  • Internet Inter-ORB Protocol (IIOP)
  • IIOP is the GIOP-based protocol for TCP/IP
    networks
  • As of the 2.0 version of the CORBA specification,
    vendors are required to implement the IIOP
    protocol
  • CORBA Networking Model
  • CORBA applications are built on top of
    GIOP-derived protocols such as IIOP
  • these protocols, in turn, rest on top of TCP/IP,
    DCE, or other underlying transport protocol the
    network uses
  • an application architecture can be designed to
    use a bridge that would interconnect, for
    instance, DCE-based application components with
    IIOP-based ones.

5
Internet Inter-Orb Protocol (IIOP)

Component
Component
Component
Component
Component
Component
Component
OLE
ORB
ORB
ORB
RPC
Bridge
Bridge
6
Passing Objects by Reference
  • In a distributed application, there are two
    possible methods for an application component to
    obtain access to an object in another process
  • When an object is passed by reference, the object
    itself remains "in place" while an object
    reference for that object is passed. Operations
    on the object through the object reference are
    actually processed by the object itself.
  • When an object is passed by value, the object's
    state is copied and passed to its destination
    (via object serialization), where a new copy of
    the object is instantiated. Operations on that
    object's copy are processed by the copy, not by
    the original object.
  • Note in CORBA, objects are only passed by
    reference (however, the new CORBA specifications
    include facilities for passing objects by value).

7
Object References
  • An Object Reference is the information needed to
    specify an object within an ORB.
  • The representation of an object reference handed
    to a client is only valid for the lifetime of
    that client.
  • The language mapping also provides additional
    ways to access object references in a typed way
    for the convenience of the programmer.
  • There is a distinguished object reference, the
    null reference, guaranteed to be different from
    all object references, that denotes no object. In
    Java, this is a Java null.
  • To invoke a CORBA object, you need a reference
    for the object. There are two ways to get a
    reference for a CORBA object
  • from another object, such as a factory or a name
    service
  • from a string that was specially created from an
    object reference
  • Interoperable Object References
  • CORBA uses IOR as a pointer to a specific
    instance of a class in a distributed environment
  • encodes host, port, object identity
  • may be externalized (using object_to_string)

8
Object References
  • Lifecycle and Longevity of Object Reference
  • Object Reference can be created without
    instantiating any servant object
  • Object Reference outlives the CORBA object to
    which it refers.
  • (CORBAOBJECT_NOT_EXIST meaning the object has
    been permanently deleted.)
  • Factory Objects
  • Create objects on remote servers (Example a
    customer at a bank needs to create an Account
    object when opening a new account.)
  • remote constructor
  • Factory design pattern
  • IDL definition
  • Interface Account
  • Interface AccountFactory
  • Account create (in string name, in long
    initialBalance)
  • Account find (in string name)

9
Object References
  • Interoperable Object Reference
  • Structure of an IOR
  • Repository id identifies the type of object
  • Number indicate the version of the ID interface,
    and usually is 1.0
  • Each profile is specific to a particular
    transport protocol and contains complete details
    about the location of an object and how to open a
    connection to the object
  • Make the same object accessible via different
    protocol
  • Multiple profiles can be used as a way of
    implementing fault tolerance.

RepositoryId
Profiles
IDFoo1.0
n
profile1
Profile n

10
Object References
  • IIOP

Tag
IIOP Version
0
1.2
host
Optional components
object_key
port
11
CORBA Components
  • Client stub
  • Each stub represents (it is a proxy) an object
    operation (a possible request) which a client
    invokes in a language-dependent manner (e.g., by
    calling a subroutine which represents the
    operation).
  • The stubs make calls on the rest of the ORB using
    interfaces that are private to JavaIDL.
  • Alternatively, a client may dynamically
    construct and invoke request objects which can
    represent any object operation.
  • Implementation Skeleton
  • Each skeleton provides the interface through
    which a method receives a request (dynamic and
    static skeletons)
  • Object Adapter
  • Purpose is to interface an object's
    implementation with its ORB
  • Each object adapter provides access to those
    services of an ORB (such as activation,
    deactivation, object creation, object reference
    management) used by a particular type of object
    implementation.
  • ORB Interface
  • The interface to the small set of ORB operations
    common to all objects, e.g., the operation which
    returns an object's interface type.

12
ORB and Object Interface
  • ORB Interface
  • module CORBA
  • interface ORB // PIDL
  • string object_to_string(in Object obj)
  • Object string_to_object(in string obj)
  • Object resolve_initial_references(in
    ObjectId identifier)
  • .
  • interface Object
  • interfaceDef get_interface()
  • boolean is_nil()
  • Object duplicate()
  • void release()
  • boolean is_a (in string logical_type_id)
  • boolean non_existent()
  • boolean is_equivalent(in Object other_object)
  • ORB ORB_init()

13
Duplicate() and release()
  • Text book Chapter 2 figure 2.8 2.11

14
The Portable Object Adapter (POA)
  • The POA defines standard interfaces to do the
    following
  • Map an obj ref to a servant that implements that
    object
  • Allow transparent activation of objects
  • Associate policy information with objects
  • Make a CORBA object persistent over several
    server process lifetimes
  • POA interface is locality constrained interface
    (i.e., references to the POA cannot be passed
    outside of a servers address space).
  • Main functionality dispatch incoming invocation
    requests to the correct servant
  • There can be multiple POAs active in a particular
    server
  • There is always a root POA from which all of the
    other POAs are created
  • Relative name to the parent POA

15
The Portable Object Adapter (POA)
  • Related concept
  • Servant
  • Object ID
  • Active Object Map
  • Incarnate
  • Etherealize
  • Default Servant

Used by server
IOR Location Details
Object_Key
Server details
Host, port (for client to Locate the server
process)
ObjectID
POA name
Not necessarily 1-1
Servant Object
manages
POA instance
16
POA Architecture
  • Text book figure 2.12

17
Object and Servant Lifetimes
  • Servant object is associated with server process
  • Incarnation binding the servant object to CORBA
    object
  • Etherealization break the binding
  • Text book figure 2.13

18
CORBA Components
Object Implementation
Client
Object Adapter
Implementation Skeletons
Dynamic Invocation
Client Stubs
ORB Interface
ORB Core
standard interface
Proprietary ORB interface
One interface per object adaptor
Normal call interface Up call interface
One interface per object operation
19
Client Side
Clients perform requests using object references.
Clients may issue requests through object
interface stubs (static) or dynamic invocation
interface.
Client
  • Clients may access general ORB services
  • Interface Repository.
  • Context Management.
  • List Management.
  • Request Management.

Dynamic Invocation
Client Stubs
ORB Interface
20
Implementation Side
Implementations receive requests through
skeletons (without knowledge of invocation
approach).
Object Implementation
Object Adapter
Implementation Skeletons
ORB Interface
  • The Object Adapter provides for
  • management of references
  • method invocation
  • authentication
  • implementation registration
  • activation/deactivation.

21
Static v. Dynamic Invocation
  • Static Invocation
  • Static interfaces are generated in form of client
    stubs by the IDL (pre-) compiler.
  • This means that the structure of the object has
    to be known before hand (at compile time).
  • Allows for better type checking less runtime
    overhead self-documentation.
  • Dynamic Invocation
  • Dynamic Invocation Interface (DII) allows clients
    to invoke operations on remote objects without
    having access to object stubs (another way to do
    this without dynamic invocation is to download
    static client stubs via a Java applet).
  • Clients must discover interface-related
    information at runtime (e.g., using the interface
    repository)
  • Servers can offer new services anytime without
    the need for recompilation on the client side.

22
Dynamic Requests
  • The Dynamic Invocation Interface (DII) allows
    clients to dynamically
  • discover objects
  • discover objects interfaces
  • create requests
  • invoke requests
  • receive responses.
  • Major features of Dynamic Invocation Interface
  • requests appear as objects themselves
  • requests are reusable
  • invocation may be synchronous or asynchronous
  • requests may be generated dynamically, statically
    or in combination approach.

23
CORBA Interface Repository
  • The Interface Repository is a service that
    provides persistent objects that represent the
    IDL information in a form available at runtime.
  • Note The JavaIDL runtime does not include an
    implementation of an Interface Repository and one
    is not generally required by clients at runtime.
  • Using the IR, it is possible for a program to
    encounter an object whose interface was not known
    at compile time, yet be able to determine what
    operations are valid on the object and make
    invocation on it.
  • Interface Repository provides
  • Dynamic client access to interface definitions to
    construct a request.
  • Dynamic type-checking of request signatures.
  • Traversal of inheritance graphs.
  • ORB-to-ORB interoperability.

24
CORBA Implementation Repository
  • The Implementation Repository contains
    information that allows the ORB to locate and
    activate implementations of objects.
  • Ordinarily, installation of implementations and
    control of policies related to the activation and
    execution of object implementations is done
    through operations on the Implementation
    Repository.
  • In addition to its role in the functioning of the
    ORB, the Implementation Repository is a common
    place to store additional information associated
    with implementations of ORB objects. (e.g.,
    debugging information, administrative control,
    resource allocation, security, etc)
  • The Implementation Repository supports the
    implementation of object servers. It is not
    needed by clients in order to access servers.

25
Summary of CORBA Interfaces
Implementation Installation
IDL Interface Definitions
Interface Repository
Implementation Repository
Client Stubs
Implementation Skeletons
Describes
Includes
Accesses
Includes
Client
Object Implementation
  • All objects are defined in IDL by specifying
    their interfaces.
  • Object definitions (interfaces) are manifested as
    objects in the Interface Repository, as client
    stubs, and as implementation skeletons.
  • Descriptions of object implementations are
    maintained as objects in the Implementation
    Repository.

26
Summary CORBA Remote Method Invocation
  • Clients use object interfaces through language
    mapping
  • Java clients should work on any ORB that supports
    the Java language bindings.
  • Clients can call any object instance remotely, so
    long as the object instance implements the
    interface.
  • Clients can call remote objects statically or
    dynamically
  • The server cannot tell whether the client is
    using static or dynamic invocation.
  • Objects are identified using a unique id
    Interoperable Object Reference (IOR)
  • CORBA normally passes objects by reference
  • IOR was Introduced in CORBA 2.0
  • Object references can be converted to strings and
    back to live objects via ORB interface
    functions.
Write a Comment
User Comments (0)
About PowerShow.com