Corba Part 2

7/30/2019 Corba Part 2

1/31

Distributed Object-Based System : CORBA

(Common Object Request Broker Architecture )


2/31

CORBA follows an interface based approach to objects:

Compared to the objects, interfaces play important role

An object may implement one or more interfaces

Interface descriptions can be stored in an interface

repository, and looked up at runtime

It has a traditional remote object model in which an object

residing at an object server is remote accessible throughproxies

Object Request Broker connects clients, objects, and

services

Object Model


3/31


4/31

To invoke a method, one need to have an object reference to the

object that contains the method. Using the object reference a

request object is created populating the required arguments to

the created object. The created object sends the request, wait

for the reply, and obtain the result from the request.

The following steps are involved while invoking an interface

dynamically:

Step Description

1 Load the CORBA interfaces into the Interface Repository.

2 Obtain an object reference for the CORBA object on which

one want to invoke methods.3 Create a request object for the CORBA object.

4 Send the DII request and retrieve the results.

5 Delete the request.


5/31

A CORBA client application can create, populate, and send

requests for objects that were not known to the CORBA client

application when it was built.

An application has not been linked with stub code which

performs the remote operation invocation.

Using the Classes associated with DII, applications may invokeoperations on any CORBA object by determining the object's

interface dynamically.

To determine the information of the methods implemented by the

remote object, the client application uses the Interface Repository

It creates an object populating the information obtained to send

the object request

Thus the CORBA client application uses DII to send the requests,

since it does not have client stubs for the interfaces.

Using the Interface Repository with DII


6/31

Interface & Implementation Repositories

Interface repository:

Database containing interface definitions implemented by

the remote objects which can be queried at runtime

Whenever an interface definition is compiled at the server

side, the IDL compiler assigns a repository identifier tothat interface.

Implementation repository:

Database containing the information related to theimplementation of methods by the remote objects

Given an object reference, an object adaptor could contact

the implementation repository to find out exactly what

needs to be done.


7/31

The ORB is the core element within the OMG Object

Management Architecture.

ORB also implements interfaces for lower level Object

Services and higher level Common Facilities for building

robust applications and systems.

A legacy application, such as an accounting system, is

wrapped in code with CORBA interfaces and opened up to

clients on the network

Some of the examples of CORBA interfaces are naming

service for locating objects, event service for subscribing to

and publishing messages, security, transaction support, and

object license and metering etc

Services in CORBA


8/31


9/31

Naming Service

In CORBA, clients can use object names to obtain handles to

objects sitting on remote servers. The name to object references

are referred as name bindings

The Naming Service provides the ability to bind a name to an

object relative to a naming context.

A naming context is an object that contains a set of name bindings

in which each name is unique.

To resolve a name is to determine the object associated with the

name in a given context.

To invoke the remote object instance, the client first obtains its

object reference. There are many ways to do this, but the easy

ways include theNaming Service and the Trader Services


10/31

Naming service implementations can be application

specific or be based on a variety ofnaming systems

currently available on system platforms:

An URL facilitates the localization of a resource exposed

on the Web. e.g., abc.net.in means it is likely to be an

Indian entity?

A consistent and uniform naming helps processes in a

distributed system to interoperate and manage resources.

e.g., commercials use .com; non-profit organizations use

.org

Naming Services are not only useful to locate resources but

also to gatheradditional information about them such as

attributes


11/31

The CORBA Name Service provides:

An implementation of the Object Management Group (OMG)Interoperable Name Service (INS) specification.

A CORBA server puts references to CORBA objects inside a

naming service so that clients can query the naming service

and obtain the object reference and then call operations on theCORBA objects.

Typically, a client queries the naming service once, then

caches the object reference

Naming services are typically arranged in a hierarchy so thatnames can be given context or scope.

Object references which are mapped into an hierarchical

naming structure is referred as a namespace


12/31

The naming service is available in two major versions:

(1) The original CORBA Naming Service.

The full name of an object, including all the associated naming

contexts, is known as a compound name

Naming contexts and name bindings are created using methods

provided in the Naming Service interface

(2) The CORBA Interoperable Naming Service (INS).

This is an extension and revision of the original naming service.

The semantics of certain operations are specified more precisely.

A string format and a URL format are defined for names.

New operations are declared in the interface.


13/31

Trading activities are described through a design pattern that

represent the roles of importer, exporter and trader

Trading Services


14/31

The object in trader role supports a repository of offers. Each offer

describes properties of an entity. The offers are produced by objects

in exporter roles.

When an exporter sends an offer for a trader to be stored, it is said toexport.

When an exporter requests an offer to be deleted, it is said to

withdraw an offer.


15/31

The objects in importer roles make queries to the offer repository. The

query and the response to the query form an interaction called

import.

The import request has a basic form that is similar to a database query:

the request specifies criteria for selecting the offers to be included to

the response.

The objects that use the traded information are not necessarily the

importers or exporters themselves. The clients and servers that use

the information are therefore drawn as separate roles in the figure


16/31


17/31

Object Clients & Object Servers

Object Servers:

The server side of CORBA begins with the specification of an

interface in IDL.

IDL is an object-oriented declarative language used to specifying

server interfaces. It is nota programming language.

An IDL compiler is used to generate a server stub, also referred toas a skeleton, which gets linked to the server program.

Server implementations are not written in IDL. Rather, IDL

interface descriptions are mapped to a programming language for

implementing the server.In IDL an interface corresponds to a class.

The server stub provides static interfaces to call methods of an

object implementation. It un-marshals parameters that come from

the client via the ORB


18/31


19/31

An IDL compiler is used to generate a server stub, also

referred to as a skeleton, which gets linked to the server

program.

The server stub provides static interfaces to call methods of

an object implementation.

The IDL compiler also generates a native language interface

for implementing the server, as well as a client side stub.


20/31


21/31

An important component of the ORB is the object adapter,

which is responsible for managing server objects and relatedobject references.

It uses the CORBA implementation repository to locate a server

name, identify the activation mode, and determine the access

permissions.

Serveractivation modes define the run-time characteristics of a

server, including whether a server process can contain one or

more objects and if multiple clients are permitted to access thesame object.


22/31

According to the CORBA specification, an object adapteris responsible for the following functions:

Generation and interpretation of object references

Method invocation

Security of interactions

Object and implementation activation and deactivation

Mapping object references to the corresponding objectimplementations

Registration of implementations


23/31


24/31

1) Specify the server interface in IDL.

2) Run the IDL description through an IDL compiler, which

generates a native language interface, server stub, and client stub.

The server and client stubs can be for different programminglanguages.

During this step, the IDL compiler can optionally write a

compiled interface description to the interface repository.

3) Implement the server.

Server Side Process:


25/31

3) Compile the server program and link in the server stub

that was generated by the IDL compiler.

The result is an executable server program that can

accept method invocations via CORBA.

4) Register the server in the implementation repository,

specifying server name, launch command, activation

mode, and launch and access permissions. The server

is now available for activation.

Server Side Process:


26/31


27/31

A client can locate a server object by obtaining an object

reference directly from a server,

by requesting an object by name via the CORBA naming

service, or

by asking the CORBA trader service to return references

to objects that match some criteria

The CORBA standard specifies a format for an interoperable

object reference (IOR) which can be passed across different

ORB implementations.

After obtaining an object reference, a client can invoke

methods on a server object using the following call modes:

Synchronous, One-way / Poll, One-way / Call-back or

One-way / Event Service

ll d


28/31

Synchronous: The client sends a request and blocks until it

receives a reply from the server.

One-way / Poll: The client sends a request, but does not await a

reply. Rather, the client polls until the server has completed

servicing the request.

One-way / Call-back: The client sends a request, passing a call-

back object reference to the server. When the server is done, itinvokes a method on the client Operating Systems call-back

object. The implication of this approach is that the client acts

like an event-driven server with an IDL interface.

One-way / Event Service: The publish-subscribe model can beemployed using the CORBA event service. The client first asks

to be notified by the event service when a completion message is

dispatched. The client then sends a request to the server. When

the server completes processing, it sends a completion message

to the event service, which in turn notifies the client.

call modes


29/31

1) Implement the client. The programmer writes server object

method calls as though they are local using the syntax and

conventions of the client Operating Systems native

programming language.

2) Compile the client program and link in the client stub that

was generated by the IDL compiler.

3) When the client is executing, it uses the ORB to bind to the

server object and obtain an object reference.

4) Using the object reference, the client invokes server object

methods.

Client Side Process:


30/31

CORBA Architecture

ORB core

DynamicInvocation

IDLStubs ORBInterface Object

Adapter

Static IDL

Skeleton

Dynamic

Skeleton

Client Object Implementation

Standard Interface Per-Object Type

Generated Interface

ORB Dependent

Interface

Interface

Repository

Implementatio

Repository


31/31

PHP5 extension to use CORBA objects

PHP: HypertextPreprocessor, an open source, server-side,

HTML embedded scripting language used to create dynamicWeb pages.

CORBA for PHP is a PHP5 extension to use CORBA

objects in PHP. The purpose of this extension is to provide

an IDL-to-PHP language mapping specification;

an IDL-to-PHP language compiler(idl2php);

a full CORBA 2.4 compliant extension.

Prior to PHP 5.3.9, a class could not implement two interfaces that

specified a method with the same name, since it would cause ambiguity.

More recent versions of PHP allow this as long as the duplicate methods

have the same signature

Corba Part 2

Documents

Transcript of Corba Part 2