CORBA Architecture

1
CORBA Architecture

• Nitin Prabhu

2
Outline

• CORBA Object Model
• CORBA Architecture
• Static Invocation
• Dynamic Invocation
• CORBA Communication Model

3
CORBA Object Model
Client
Encapsulation
Request
Object Implementation
Exception value

• CORBA Object implementations
• Request
• CORBA Types
• Interfaces
• Operations
• Exceptions

4
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

5
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.

6
CORBA Types

• An identifiable entity defined over values.

Value
Object Reference
Basic Value
Constructed Value
Short long Ushort Ulong Float Double Char String B
oolean Octet
Struct Sequence Union Array
7
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.

8
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

9
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.

10
OMA

• Object Management Architecture

COMMON FACILITIES

• Horizontal
• User Interface
• Mail
• Printing
• Vertical
• Telecom
• Finance
• Health Care

APPLICATION OBJECTS
OBJECT REQUEST BROKER
naming
trading
security
persistence
COMMON OBJECT SERVICES
11
CORBA Architecture
Per-Object Type Generated Interface
ORB Dependent Interface
Standard Interface
Client
Object Implementation
Object
Static IDLSkeleton
Dynamic Skeleton
IDLStubs
ORBInterface
Dynamic Invocation
Adapter
ORB core
12
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

13
Interoperable Object Reference(IOR)

• An ORB must create an IOR whenever an object
  reference is passed across ORBs
• Includes ORBs internal object reference and
  addressing information

14
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.

15
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.

16
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)

17
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.

18
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.

19
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.

20
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.

21
Development Steps
IDL
CORBA Compile
Stubs
Skels
Client
Server
Compile Link
Compile Link
Client
Server
22
Static Invocation
Server
Servant
Client
IOR
Server IDL Skeleton
Client IDL Stub
Server ORB
Client ORB
IIOP
23
Client Invocation Process Scenario
Client Program 1. Object string valued
2. Obtain object Handle 4. Check
exceptions object reference 3. Invoke
request 5. Utilize results
6. ORBFree( )
String_to_object( )
user_fun( )
Results exceptions
File
ORB Interfaces
Interface Stub
ORB CORE
24
Object Implementation Invocation Scenario
Object Implementation
Methods
3. Activate object
5. Access BOA service
2. Registration of implementation
4. Invoke method
1. Activate Implementation
Basic Object Adapter
Skeleton
Object Request Broker Core
25
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.

26
(No Transcript)
27
Dynamic Skeleton Interface

• Allows the ORB and OA to deliver requests to an
  object without the need of pre-compiled
  skeletons.
• Implemented via a DIR (Dynamic Invocation
  Routine).
• ORB invokes DIR for every DSI request it makes.

28
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.

29
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

30
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

31
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 inter-platform issue.
•  GIOP also defines a format for Interoperable
  Object References(IOR).

32
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.