CORBA Object Model
CORBA Communication Model
CORBA Object Model
CORBA Object implementations
• Object is a encapsulated entity that
• Object is referred to by an unique object
• Client software invokes object services by
• Object returns some results or returns
• A request is a message sent from a client to
• It consists of
a target object.
zero or more parameters.
an optional request context.
• An identifiable entity defined over values.
• 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.
• An operation is an identifiable entity, that denotes
a service which can be requested.
• Operation Signature consists of
• 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.
• Object Management Architecture
OBJECT REQUEST BROKER
COMMON OBJECT SERVICES
• Object Request Broker.
• Gives the communication infrastructure that is
capable of relaying object requests across
• Client calls the Object implementation through
interfaces provided by ORB.
• 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 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
• Acts as client proxy for server implementation.
– 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.
• Different kind of object implementations – objects residing in their own process and requiring
– 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
– Activating and deactivating object implementation.
– Invocation of methods via a skeleton.
• Contains information regarding the interfaces to ORB
• 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.
• Contains all the information regarding
• Provides a persistent record of how to
activate and invoke operations on object
• CORBA gives vendors free-hand in
• 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.
Client Invocation Process Scenario
1. Object string valued
2. Obtain object Handle
3. Invoke request
4. Check exceptions
5. Utilize results
6. ORBFree( )
Object Implementation Invocation Scenario
2. Registration of
Basic Object Adapter
Object Request Broker Core
5. Access BOA
Dynamic Invocation Interface
• Generic interface for making remote invocations.
• Uses interface repository at run-time to discover
• 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
• ORB invokes DIR for every DSI request it
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
– 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
Differences between Dynamic invocation and
• 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
• 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
• Two protocols are defined in the
• 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
• 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
IIOP- Internet Inter ORB Protocol
• It is a specialized form of GIOP for TCP/IP
• 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