CORBA Architecture
Nitin Prabhu
Outline
•
•
•
•
•
CORBA Object Model
CORBA Architecture
Static Invocation
Dynamic Invocation
CORBA Communication Model
CORBA Object Model
Encapsulation
Client
Request
Exception value
•
•
•
•
•
•
Object
Implementation
CORBA Object implementations
Request
CORBA Types
Interfaces
Operations
Exceptions
CORBA Object
• Object is a encapsulated entity that
performs services
• Object is referred to by an unique object
reference
• Client software invokes object services by
generating request
• Object returns some results or returns
exception
CORBA Request
• A request is a message sent from a client to
an object.
• It consists of
–
–
–
–
an operation.
a target object.
zero or more parameters.
an optional request context.
CORBA Types
• An identifiable entity defined over values.
Value
Basic Value
Short
long
Ushort
Ulong
Float
Double
Char
String
Boolean
Octet
Constructed Value
Struct
Sequence
Union
Array
Object Reference
CORBA Interface
• An Interface comprises a set of operations
and attributes that a client may utilize to
request services of an object.
• All interface information is public.
• Interfaces are defined in IDL.
CORBA Operations
• An operation is an identifiable entity, that denotes
a service which can be requested.
• Operation Signature consists of
–
–
–
–
–
–
Operation name
Parameters required
Return Value
Exceptions thrown
Contextual Information
Execution Semantics
• Synchronous
• Asynchronous
CORBA Exceptions
• An exception is an indication that an operation
request was not performed successfully.
• Two types
– Standard Exceptions
– User defined Exceptions
• CORBA guarantees that the client will not hang.
Either it returns successfully or with an exception.
OMA
• Object Management Architecture
COMMON FACILITIES
Horizontal
•User Interface
•Mail
•Printing
APPLICATION OBJECTS
Vertical
•Telecom
•Finance
•Health Care
OBJECT REQUEST BROKER
naming
trading
persistence
COMMON OBJECT SERVICES
security
CORBA Architecture
Standard Interface
Per-Object Type
Generated Interface
Client
Interface
Repository
Dynamic
Invocation
IDL
Stubs
ORB Dependent
Interface
Object Implementation
ORB
Interface
Static IDL
Skeleton
Dynamic
Skeleton
Implementatio
Repository
Object
Adapter
ORB core
ORB
• Object Request Broker.
• Gives the communication infrastructure that is
capable of relaying object requests across
distributed platforms.
• Client calls the Object implementation through
interfaces provided by ORB.
• Advantages:
• Separates Client and Server implementation
• Separates both client and Server from underlying
communication infrastructure and protocol stack and so
replaceable while migration from one implementation to other
Interoperable Object Reference(IOR)
• An ORB must create an IOR whenever an
object reference is passed across ORB’s
• Includes ORB’s internal object reference
and addressing information
Client Stubs
• Client side proxy for server.
• Joins to the client at one end and to the ORB
core at the other end.
• Client-to-stub interface is decided by the
standard OMG language mapping for the
chosen programming language.
• Clients actually invoke methods on stub
objects.
Server Skeletons
• Acts as client proxy for server implementation.
• Connects
– to the server object via the mapping defined for its
programming language on .
– To the Object Adapter via a proprietary interface.
• Invocation pass through Object Adapter to
skeletons, which in turn actually invoke
methods on server object.
Object Adapter
• Different kind of object implementations – objects residing in their own process and requiring
activation.
– others not requiring activation.
– or some residing in same process as ORB.
• OA helps the ORB to operate with different
type of objects.
• Most widely used OA - BOA (Basic OA)
• Recently standardized - POA (Portable OA)
Object Adapter Contd...
• Services provided by ORB via OA – Registering implementations.
– Generation and interpretation of object references.
– Mapping object references to their corresponding
implementation.
– Activating and deactivating object implementation.
– Invocation of methods via a skeleton.
Interface Repository
• Contains information regarding the interfaces to ORB
objects.
• Can be used by the ORB in 2 ways – To provide type-checking of request signatures, whether a request
was issued through DII or stub.
– To check correctness of inheritance graph.
• Client objects can use it – To manage installation and distribution of interface definitions
around your network.
– Language compilers may use them to generate stubs and skeletons.
• Can be shared by more than one ORB or one ORB may
refer to more than one interface repository.
Implementation Repository
• Contains all the information regarding
object implementation.
• Provides a persistent record of how to
activate and invoke operations on object
implementations.
• CORBA gives vendors free-hand in
handling implementations.
Marshaling
• Refers to the process of translating input
parameters to a format in which it can be
transmitted over the network.
• Unmarshaling is the reverse of marshaling.
• Stubs and skeletons contain code for
marshaling and unmarshaling.
Development Steps
IDL
CORBA
Compile
Stubs
Skels
Client
Server
Compile
Link
Client
Compile
Link
Server
Static Invocation
Server
Servant
Client
IOR
Server
IDL Skeleton
Client
IDL
Stub
Object Adapter(BOA/POA)
Server ORB
Client ORB
IIOP
Client Invocation Process Scenario
Client Program
1. Object string valued
object reference
2. Obtain object Handle
3. Invoke request
String_to_object( )
user_fun( )
File
ORB
Interfaces
4. Check exceptions
5. Utilize results
6. ORBFree( )
Results &
exceptions
Interface
Stub
ORB CORE
Object Implementation Invocation Scenario
Object Implementation
Methods
2. Registration of
implementation
3. Activate
object
4. Invoke
method
1. Activate
Implementation
Skeleton
Basic Object Adapter
Object Request Broker Core
5. Access BOA
service
Dynamic Invocation Interface
• Generic interface for making remote invocations.
• Uses interface repository at run-time to discover
interfaces.
• No need of pre-compiled stubs.
• Steps – Obtain IOR.
– Ask IOR of the interface name and get a reference to an
object in the interface repository.
– Obtain the method description.
– Create the request to be passed.
– Invoke the operation/method.
Dynamic Skeleton Interface
• Allows the ORB and OA to deliver requests
to an object without the need of precompiled skeletons.
• Implemented via a DIR (Dynamic
Invocation Routine).
• ORB invokes DIR for every DSI request it
makes.
Dynamic Skeleton Interface Contd...
• Steps – OA up-calls the DIR servant and provides the request
information (targeted object and operation name etc.).
– DIR asks IOR for the interface name of the targeted
object and gets the meta-data information about it from
interface repository.
– Creates the request to targeted object, using other
parameters from the received request.
– Locates the Servant and send the request to it.
– Takes the return parameteres and give them back to
OA.
Differences between Dynamic invocation and
static invocation
• Use
• SI used for general purpose
• DI used for special purpose where extra flexibility is needed
• In SI interfaces should be known at compile time,In DI
interfaces are discovered during run time using data in
interface repository
• Static Interface are easier to use and code
CORBA Communication model
• It is independent of underlying protocol
suite and assumes an underlying
connection-oriented protocol at transport
layer.
• Two protocols are defined in the
communication mode.
• GIOP-General Inter ORB Protocol
• IIOP- Internet Inter ORB Protocol
GIOP-General Inter ORB Protocol.
• IT is a high level standard protocol for communication
between ORB implementations. It is designed to directly
work over any connection- oriented transport protocol
• GIOP defines a transfer syntax known as CDR (Common
Data Representation) and seven messages that cover ORB
request reply semantics.
• No format negotiations are needed.In most cases,clients
send a request to objects immediately after they open the
connection.
• CDR maps data types defined in IDL in to flat, networked
message representation. CDR also takes care of the interplatform issue.
• GIOP also defines a format for Interoperable Object
References(IOR).
IIOP- Internet Inter ORB Protocol
• It is a specialized form of GIOP for TCP/IP
networks.
• IIOP specifies how GIOP messages will be
exchanged over TCP/IP network
• An ORB must support IIOP in order to be
considered compliant with CORBA 2.0.
• It consists primarily of the specification for the
IIOP IOR, which contains the host name and the
port number.