UNIT V THE OMG WAY€¦ · Language mapping for Java Reverse mapping Java to IDL 7. CORBA 2.3 1998...

ITT73 COMPONENT TECHNOLOGY

Department of Information Technology, SMVEC Page106

UNIT – V

THE OMG WAY

System object model –CORBA timeline – CORBA architecture – ORB services –

Facilities - Business objects – IIOP – Transport mechanisms – IDL – CCM – CCM

container.

5.1 SYSTEM OBJECT MODEL

System object model was introduced by IBM in the year 1998.

System object model (SOM) was originally developed independently from CORBA as

a part of OS/2 work shell.

But later it was made as CORBA – 2 compliant.

In CORBA, Distributed computing is supported by the Distributed Object

Model(DSOM) libraries.

DSOM was built on SOM which became an integral part of SOM.

Features of SOM:

1. Support for Metaprogramming.

2. Support for Binary Compatability.

Metaprogramming:

In Metaprogramming model ,every class is itself an object and also an instance of

metaclass.

SOM allows classes to be constructed or modified dynamically.

For example, it is possible to add a new method to an existing class without disturbing

any other instances of the class.

The existing instances will immediately support the new method.

At present no other component supports this level of metaprogramming.

Though runtime coding is supported by CLR and Java, these donot support

modifications that affect already existing instances.

Binary Compatability:

Binary compatibility is a very important issue in a component world. Versioning and

binary compatibility are supported by the notion of a release order.

Adding new methods to a later release does not alter the code compiled against anolder

release.

It is meaningless to ask all vendors of dependent components to recompile and

redistribute the component within any reasonable time for each and every release of

new version .This is the syntactic fragile base class (FBC) problem.

SOM comes with precise rules as - to which changes in a release maintain, and which

other changes break, binary compatibility with previous releases.



SOM guarantees binary compatibility across a large number of base class changes.

SOM also guarantees that, if no interface changes took place, then building the

nextrelease of a component is guaranteed to preserve binary compatibility withclients

compiled against the previous release.

This effectively solves the syntactic FBC problem.

5.2 CORBA TIMELINE

Table 5.1 describes about various CORBA timeline versions available

Sl.no Version Year Hallmark

1. CORBA 1.0 1991 IDL, DII, Interface Repository, C mapping

2. CORBA 1.1 1992 Memory management

3. CORBA 1.2 1993 Several clarifications, especially in memory

management and object reference

comparison.

4. CORBA 2.0 1997 Interoperability architecture

Layered security

Transaction services

COM and OLE Automation interworking

5. CORBA 2.1 1997 Secure IIOP

Language mappings for COBOL and Ada

6. CORBA 2.2 1998 DCOM interworking,

Language mapping for Java

Reverse mapping Java to IDL

7. CORBA 2.3 1998 Language mappings for C/C++/Java

ORB portability

COM and automation interworking

8. CORBA 2.4 2000 Quality of service (QoS) specifications

Asynchronous messaging

9. CORBA 2.5 2001 Fault-tolerant CORBA

Portable interceptors

10. CORBA 2.6 2001 New secure interoperation specification and

general interoperability improvements.

11. CORBA 3.0 pending

Table 5.1 Timeline of CORBA

5.3 THE CORBA ARCHITECTURE

CORBA, or Common Object Request Broker Architecture, is a standard architecture

for distributed object systems.

It allows a distributed, heterogeneous collection of objects to interoperate.

CORBA is a standard defined by the OMG (Object Management Group).

It describes an architecture, interfaces, and protocols that distributed objects can use

to interact with each other.

Part of the CORBA standard is the Interface Definition Language (IDL), which is an

implementation-independent language for describing the interfaces of remote objects.



The OMG comprises over 700 companies and organizations, including almost all the

major vendors and developers of distributed object technology, including platform,

database, and application vendors as well as software tool and corporate developers.

Java IDL is an implementation of the standard IDL-to-Java mapping and is provided

by Sun in version 1.3 of Java 2 and is compliant with CORBA 2.x specification. Java

IDL provides an Object Request Broker, or ORB.

The ORB is a class library that enables low-level communication between Java-IDL

applications and other CORBA-compliant applications.

Like RMI, Java IDL gives you a way to access remote objects over the network. It

also provides tools you need to make your objects accessible to other CORBA clients.

A remote object can: find this object, call methods on it, and receive data from it, just

as if it were running on the client’s local machine.

Unlike RMI, objects that are exported using CORBA can be accessed by clients

implemented in any language with an IDL binding (C, C++, Ada etc.).

The CORBA standard is extensive and provides a rich set of services.

5.3.1 CORBA Products

Several vendors provide CORBA products for various programming languages. The

CORBA products that support the Java programming language include:

The Java 2 ORB The Java 2 ORB comes with Sun's Java 2. It is missing

several features. The main feature it has is the ability to

look up an object by name.

VisiBroker for Java A popular Java ORB from Inprise Corporation.

VisiBroker is also embedded in other products. For

example, it is the ORB that embedded in the Netscape

Communicator browser.

Orbix A popular Java ORB from Iona Technologies.

The major components that make up the CORBA architecture include the:

Interface Definition Language (IDL), which is how CORBA interfaces are defined,

Object Request Broker (ORB), which is responsible for all interactions between

remote objects and the applications that use them,

The Portable Object Adaptor (POA), which is responsible for object

activation/deactivation, mapping object ids to actual object implementations.

Naming Service, a standard service in CORBA that lets remote clients find remote

objects on the networks, and

Inter-ORB Protocol (IIOP).

This figure 5.1 shows how a one-method distributed object is shared between a

CORBA client and server to implement the classic "Hello World" application.


Fig.5.1 object sharing between a CORBA client and server

5.3.2 Architectural description:

Any relationship between distributed objects has two sides: the client and the server.

The server provides a remote interface, and the client calls a remote interface.

These relationships are common to most distributed object standards, including RMI

and CORBA.

On the client side, the application includes a reference for the remote object.

The object reference has a stub method, which is a stand-in for the method being

called remotely.

The stub is actually wired into the ORB, so that calling it invokes the ORB's

connection capabilities, which forwards the invocation to the server.

On the server side, the ORB uses skeleton code to translate the remote invocation

into a method call on the local object.

The skeleton translates the call and any parameters to their implementation-specific

format and calls the method being invoked.

When the method returns, the skeleton code transforms results or errors, and sends

them back to the client via the ORBs.

In addition to these simple distributed object capabilities, CORBA-compliant ORBs

can provide a number of optional services defined by the OMG.

These include services for looking up objects by name, maintaining persistent

objects, supporting transaction processing, enabling messaging, and many other

abilities useful in today's distributed, multi-tiered computing environments.

Several ORBs from third-party vendors support some or all of these additional

capabilities.

The ORB provided with Java IDL supports one optional service, the ability to locate

objects by name.

5.4 OMG’s OBJECT MANAGEMENT ARCHITECTURE

In the fall of 1990, the OMG first published the Object Management Architecture

Guide (OMG Guide). It was revised in September 1992. The details of the Common

Facilities were added in January 1995.



There are four main elements of the architecture:

1. Object Request Broker (ORB) defines the CORBA object bus;

2. CORBAservices defines the system-level object frameworks that extends the bus;

3. CORBA facilities define horizontal and vertical application frameworks that are used

directly by business objects; and

4. Application Object are the business objects and applications, they are the ultimate

consumers of the CORBA infrastructure.

5.4.1 The Object Request Broker (ORB):

The Object Request Broker (ORB) is the object bus. It lets objects transparently make

request to and receive responses from other objects located locally or remotely.

The client is not aware of the mechanisms used to communicate with, activate, or

store the server objects.

The CORBA 1.1 specification introduces in 1991 only specifies the IDL, language

binding, and PIs for interfacing to the ORB.

So, you could write portable programs that could run on top of the dozens of CORBA

compliant ORBs on the market (especially on the client side).

CORBA 2.0 specifies interoperability across vendor ORBs.A CORBA ORB provides

a wide variety of distributed middleware services.The ORB lets object discover each

other at run time and invoke each other’s services.

AN ORB is much more sophisticated than alternative forms of client/server

middleware including traditional Remote Procedure Calls (RPCs), Message-Oriented

Middleware (MOM), database stored procedures, and peer-to-peer services.

In theory CORBA is the best client/server middleware ever defines. In practice,

CORBA is only as good as the products that implement it.

To give an idea of why CORBA ORBs make such great client/server middleware, the

following list of benefits that every CORBA ORB provide:

Static and dynamic method invocation. A CORBA ORB lets you either statically

defines your method invocation at compile time, or it lets you dynamically discover

them at run time. So you either get strong type checking at compile time or maximum

flexibility associated with late (or run-time) binding. Most other forms of middleware

only support static bindings.

High-level language binding. A CORBA ORB lets you invoke methods on server

object using your high-level language of choice. It doesn’t matter what language ,

server object are written in. CORBA separated interface from implementation and

provides language-neutral data types that make it possible to call objects across

language and operating system boundaries. In contrast, other types of middleware

typically provide low-level, language-specific, API libraries. And they don’t separate

implementation from specifications- the API is tightly bound to the implementation,

which makes it very sensitive to changes.

Self-describing system. CORBA provides run-time metadata for describing every

server interface known to the system. Every CORBA ORB must support an Interface



Repository that contains real-time information describing the functions a server

provides and their parameters. The clients use metadata to discover how to invoke

services at runtime. It also helps tools generate code “on-the-fly”. The metadata is

generated automatically either by an IDL directly from an precompiler or by

compilers that know how to generate IDL directly form an OO language.

Local/remote transparency: An ORB can run is standalone mode on a laptop, or it

can be interconnected to every other ORB in the universe using CORBA 2.0’sinternet

inter-ORB protocol (IIOP) services. AN ORB can broker inter-objects call within a

single process, multiple processes running within the same machine, or multiple

processes running across networks and operating systems. This is completely

transparent to your objects.

Built-in Security and transactions. The ORB includes context information in its

messages to handle security and transactions across machine and ORB boundaries.

Polymorphic Messaging. In contrast to other forms of middleware, an ORB does not

simply invoke a remote function, it invokes a function on a target object. This means

that the same function call will have different effects, depending on the object that

receives it.

Coexistence with existing system. CORBA’s separation of an object’s definition

from its implementation is perfect for encapsulating existing applications. Using

CORBA IDL, you can make your existing code look like an object on the ORB, even

if it’s implemented in stored procedures, CICS, IMS, or COBOL.

5.4.2 CORBA 2.0: THE INTERGALACTIC ORB:

CORBA1.1 was only concerned with creating portable object application; the

implementation of the ORB core was left as an “exercise for the vendors.” The result was

some level of components portability, but not interoperability.

CORBA 2.0 added interoperability by specifying a mandatory Internet Inter-ORB

Protocol (IIOP). The IIOP is basically TCP/IP with some CORBA-defined message

exchanges that serve as a common backbone protocol. Every ORB that calls itself CORBA-

Compilant must earlier implement IIOP natively or provide a half-bridge to it. Note that it is

called a half-bridge because IIOP is the “standard” CORBA backbone. So any proprietary

ORB can connect with the universe of ORBs by the translating request to and from the IIOP

backbone.In addition to IIOP, CORBA supports Environment-Specific Inter-ORB Protocols

(ESIOPs) for “out-of-the-box” interoperation over specific networks.

CORBA 2.0 specifies CE as the first of many optional ESIOPs (Pronounced “E-SOPs”).

The DCE ESIOP provides a robust environment for mission-critical ORBs.

5.5 CORBA SERVICES

CORBAservices are collections of system-level services packaged with IDL-specified

interfaces. You can think of object services as augmenting and complementing the



functionality of the ORB. You use them to create a component, name it, and introduce it into

the environment.

OMG has published standards for fifteen object services:

The Life Cycle Services defines operations for creating, copying, moving, and

deleting components on the bus.

The Persistence Service provides a single interface for storing components

persistently on a variety of storage servers, including Object Databases (ODBMSs),

Relational Databases (RDBMSs), and simple files.

The Naming Service allows components on the bus to locate other components by

name; it also supports federated naming contexts. The service also allows objects to

be bound to existing network directories or naming contexts, including ISO’s X.500,

OSF’s DCE, Sun’s NIS+. Novell’s NDS, and the Internet’s LDAP.

The Event Service allows components on the bus to dynamically register or

unregister their interest in a specific event. The service defines a well-known object

called an event channel that collects and distributes events among components that

know nothing of each other.

The Concurrency Control Service provides a lock manager that can obtain locks on

behalf of either transactions or threads.

The Transaction Service provides two phase commit coordination among

recoverable components using either flat or nested transactions.

The Relationship Service provides a way to create dynamic associations(for links)

between components that know nothing of each other. It also provides mechanisms

for traversing the links that group these components. You can use the service to

enforce referential integrity constraints, track containment relationship, and for any

type of linkage among components.

The Externalization Service provides a standard way foe getting data into and out of

a component using a stream-like mechanism.

The Query Service provides query operations for objects. It’s a superset of SQL. It is

based on the oncoming SQL3 specification and the Object Database Management

Group’s (ODMG) Object Query Language (OQL).

The Licensing Service provides operations for metering the use of components to

ensure fair compensation for their use. The service supports any model of usage

control at any point in a component’s life cycle. It supports charging per session, per

node, per instance creation, and per site.

The Properties Service provides operations that let you associate named values (or

properties) with any component. Using this service, you can dynamically associate

properties with a component’s state.

The Time Service provides interfaces for synchronizing time in a distributed object

environment. It also provides operations for defining and managing time-triggered

events.



The Security Service provides a complete framework for distributed object security.

It supports authentication, access control lists, confidentially, and non-repudiation. It

also manages the delegation of credentials between objects.

The Trade Service provides a “yellow Pages” for objects; it allows objects to

publicize their services and bid for jobs.

The Collection Service provide CORBA interfaces to generically create and

manipulate the most common collection.

All these services enrich a distributed component’s behavior and provide the robust

environment in which it can safely live and play.

5.5.1 CORBA FACILITIES

CORBAfacilities are collection of IDL-defined frameworks that provide services od

direct use to application objects. Think of them as the next step up in the semantic

hierarchy.

The two categories of common facilities, horizontal and vertical- define rules of

engagement that business components need to effectively collaborate.

The Common Facilities that are currently under construction include mobile agents,

data interchange, workflow, firewalls, business object framework, and

internationalization.

Like the highway system, Common Facilities are an unending project. The work will

continue until CORBA defines IDL interfaces for every distributed service we know

of today, as well as ones that are yet to be invented.

When this happens, CORBA will provide IDL-interface for virtually every networked

service (many will be IDL-ized version of existing middleware).

5.5.2 CORBA BUSINESS OBJECTS

Business Object provide a natural way for describing application-independent

concepts such as customer, order, competitor, money, payment, car, and patient.

They encourage a view of software that transcends tools, applications, database and

other system concepts.

The ultimate promise of object technology and components is to provide these

medium-grained components that behave more like the real world does.

Of course, somebody must first define the rules of engagement for these components

to play, which is where the OMG comes into the picture.

According to OMG’s Business Object Task Force, a business is an application-level

component you can use in unpredictable combinations.

A business object is, by definition, independent of any single application. Post-

monolithic applications will consist of suites of business objects,

The application simply provides the environment to execute these business objects. In

other words, a business object is a component that represents entities that make sense

only to information systems and programmers, they’re not something an end user

recognizes.



5.6 IIOP

RMI-IIOP (read as "RMI over IIOP") denotes the Java Remote Method Invocation

(RMI) interface over the Internet Inter-Orb Protocol (IIOP).

It is based on two specifications: the Java Language Mapping to OMG IDL, and

CORBA/IIOP 2.

It was developed by Sun Microsystems and IBM, combining features of Java RMI

technology with features of CORBA technology.3.1.

IIOP is CORBA's communication protocol.

IIOP allows clients using a CORBA product from one vendor to communicate with

objects using a CORBA product from another vendor thus permitting interoperability,

which is one of the goals of the CORBA standard.

It defines the way bits are sent over a wire between CORBA clients and servers.

Interfaces to remote objects are described in a platform-neutral interface definition

language (IDL).

The IIOP protocol connects CORBA products from different vendors, ensuring

interoperability among them.

5.6.1 RMI Vs CORBA:

Fig.5.2 communication between CORBA client and server

Figure 5.2 shows communication between CORBA client and server.

It used to be difficult to choose between RMI (JRMP) and CORBA when starting a new

project.

If you selected RMI (JRMP), you got easy programming, but lost interoperability across

multiple languages.

If you selected CORBA, you got interoperability, but faced a more daunting

programming task.

Consider a Situation an RMI-IIOP client calls a CORBA server, and a CORBA client

calls an RMI-IIOP server.



By an RMI-IIOP client, we mean a client program that was written by an RMI

programmer who knows nothing about CORBA or IDL. Likewise, a CORBA client is a

client program that was written by a CORBA programmer ignorant of RMI.

Separation of interface from implementation is a well-established technique for allowing

programmers to access different resources without needing to know how those resources

are implemented;

If this technique is followed, users of both RMI-IIOP and CORBA can use the services of

the other protocol, if they can get access to its interface.

An RMI Java interface file is the interface to RMI-IIOP users, while IDL is the interface

to CORBA users; interoperability between RMI-IIOP and CORBA is achieved by

providing each user with his expected interface, while keeping the actual implementation

hidden.

5.6.2 RMI IIOP Design:

There were two major prerequisites that shaped the design of the RMI-IIOP protocol:

1. The RMI semantics had to be left as intact as possible.

2. CORBA needed to be enhanced so that RMI semantics could be implemented using

the CORBA infrastructure.

RMI IIOP defines the separation between

Interface: exposes to the client what methods can be invoked on an object and what

are their parameters

Implementation: the programming logic provided by the object

RMI-IIOP needs to define a Remote Interface which extends java.rmi.Remote

RMI-IIOP masks weather the object you are invoking is local or remote

Uses a stub to accept method calls locally and delegate those calls to the actual object

implementation which might reside across the network

Uses a skeleton on the remote host to receive calls over the network and delegate the

calls to the object implementation.

Stubs and skeletons are automatically generated by a tool, called rmic, provided as

part of the Java RMI-IIOP implementation is shown in figure 5.3.



Fig.5.3 Design of RMI IIOP

RMI –IIOP and Object serialization:

Java RMI-IIOP uses serialization for passing parameters via remote method

invocation. A parameter is serialized and passed by-value

Java RMI-IIOP can also simulate pass-by-reference.

- The parameter must be declared as a remote object

- The stub for the remote object is serialized and passed by-value.

Rules for member variables:

- All primitive types are serializable and will be serialized unless marked as

transient

- Objects marked as transient will not be serialized

- Objects not marked as transient must be Serializable Advantages:

Interoperability

Between different ORB vendors

Between different languages Disadvantages:

Need to learn Interface Definition Language (IDL)

Complex Programming



5.6.3 The working of IIOP

IIOP is a high-level protocol that takes care of many of the services associated with

the levels above the transport layer, including data translation, memory buffer

management, dead-locks and communication management as shown in figure 5.4.

It is also responsible for directing requests to the correct object instance within an

ORB.

CORBA and IIOP assume the client-server model of computing in which a client

program always makes requests and a server program waits to receive requests from

clients.

For a client to make a request of a program somewhere in a network, it must have an

address for the program (object instance).

This address is known as the Interoperable Object Reference (IOR). Part of the

address is based on the server's IP address and port number. In the client's computer, a

table can be created to map IORs to proxy names that are easier to use.

A Common Data Representation (CDR) provides a way to encode and decode data so

that it can be exchanged in a standard way.

The client application can access the object using the IOR, which masks the client

application’s ORB implementation from the ORB implementation used to host the

CORBA object.

Fig.5.4 IIOP in protocol stack

5.7 INTERFACE DEFINITION LANGUAGE (IDL)

The services that an object provides are given by its interface. Interfaces are defined

in OMG's Interface Definition Language (IDL).

IDL is independent of any programming language.



Mappings from IDL to specific programming languages are defined as part of the

CORBA specification.

Mappings for C, C++, Smalltalk, Ada, COBOL, and Java have been approved by

OMG.

Figure 5.5 shows the general structure of IDL.

The syntax of both Java and IDL were modeled to some extent on C++, so there are a

lot of similarities between the two in terms of syntax.

However, there are differences between IDL and Java.

In IDL, you declare only the names and types for interfaces, data members, methods,

method arguments etc.

Fig.5.5 Structure of IDL

The method implementations are created in implementation language you choose after

you’ve used an IDL compiler (idlj is the IDL compiler for Java) to convert your IDL

interface to your target language.

When you run theidlj compiler over your interface definition file, it generates the

Java version of the interface, as well as the class code files for the stubs and skeletons

that enable your applications to hook into the ORB.

IDL includes, like C++, non-class data structure definitions like structs, unions etc.

(these are not part of Java).

Method parameters in IDL include modifiers that specify whether they are input,

output, or input/output variables.

In Java, all primitive data types are passed by value, and all objects are passed by

reference.

An IDL file can include multiple public interfaces.

Java allows multiple inner classes within a single public class definition and multiple

nonpublic classes per file, but only a single public class can be defined in a given

Java file.

Modules, which are similar to Java packages, can be nested within other modules in

the same IDL file.

In Java, you can define a class only within a single package in a single Java file.



The POA connects the server object implementation to the ORB. It extends the

functionality of the ORB and some its services include:

1. Activation and deactivation of the object implementations.

2. Generation and management of object references.

3. Mapping of object references to their implementations.

4. Dispatching of client requests to server objects through a skeleton.

5.8 CORBA COMPONENT MODEL (CCM)

CORBA 3 biggest contribution is probably the new CORBA Component Model

(CCM).

CCM is an extension of Enterprise JavaBeans.

CCM promises a fully compatible embedding of existing EJB solutions.

CCM is both language and platform independent.

CCM FEATURES:

Portable Object Adapter

CCM Components

CCM Container

5.8.1 PORTABLE OBJECT ADAPTER:

The main function of a CORBA object adapter is to mediate between an ORB and the

object receiving incoming calls and returning results.

An instance of the portable object adapter accepts requests on behalf of a group of

objects.

Fig.5.6 Generation of stub, POA skeleton, and servant template from given IDL

specification



Working of POA as shown in figure 5.6: 1. Clients direct calls to object references.

2. Object references are created by POAs at the server side and then passed to clients.

3. To enable clients to talk to any objects, a set of well-known objects is made available by

ORBs on the client side.

4. The object reference contains the information needed for a client ORB to locate the server

ORB.

5. The object reference also contains the name of the POA that created the object reference

and an object ID that is valid only relative to that POA.

6. A POA instance handles an incoming request by handing it off to a servant. Servants are

the implementations of CORBA objects.

5.8.1 CCM COMPONENTS:

A CCM application is an assembly of CCM components, each of which may be

custom-built or off-the- shelf, in-house or acquired.

A CCM component is classified into one of the four categories

o Service Component

o Session component

o Entity component

o Process component

Service components are instantiated per incoming call and thus cannot maintain state

across calls. The structure of CCM component is described in figure 5.7.

Instances of session components maintain state for the duration of a transactional

session and allow for multiple calls within such a session.

Instances of process components have persistent state – their lifetime corresponds to

the lifetime of some process they are servicing.

Entity components finally have persistent instances that correspond to entities in some

database – they can be accessed by presenting the database entity’s primary key.

Fig.5.7 Structure of CCM component



CCM component features:

Ports that are classified into facets, receptacles, event sources, and event sinks.

A facet is a provided interface and a receptacle is a required interface.

A component instance’s receptacles are connected to other instances’ facets.

Event sources and sinks are similar, but instead of being connected to each other, they

are both connected to event channels.

Receptacles provide connect and disconnect operations and internally correspond to

object references to other objects of appropriate type.

Configuration interfaces support initial configuration of new component instances.

5.9 CCM Containers

Every component instance is placed inside a CCM container.

Components interact with POA as well as transactions, security, persistence, and

notification services via interfaces on their container.

A container also has receptacles that accept callbacks into the component instance.

Transaction control can be container-managed or self-managed.

In the container-managed case, a component configuration states if transactions are

supported, required, required new, or not supported.The container will begin and end

transactions to meet these requests.

Similarly, persistence can be declared as container-managed or self-managed. In the

container-managed case, PSDL is used to declare what needs to be persisted.

TWO MARKS

1) What is mean by CORBA?

Common Object Request Broker Architecture (CORBA) is an architecture and

specification for creating, distributing, and managing distributed program objects in a

network.

It allows programs at different locations and developed by different vendors to

communicate in a network through an "interface broker."

2) Why we need CORBA?

It is used to solve one fundamental problem-“how can distributed object oriented systems

implemented in different languages and running on different platforms?”. It allows

programs at different locations and developed by different vendors to communicate in a

network through an "interface broker."

3) What are the essential parts of CORBA?

Invocation Interfaces

Object Request Broker

Object Adapters




4) How CORBA was developed?

CORBA was developed by a consortium of vendors through the Object Management

Group (OMG), which currently includes over 500 member companies. Both International

Organization for Standardization (ISO) and X/Open have sanctioned CORBA as the

standard architecture for distributed objects (which are also known as components).

5) What is mean by OMG?

The OMG (Object Management Group) was formed in 1989 by a group of vendors for

the purpose of creating a standard architecture for distributed objects (also known as

"components") in networks. The architecture that resulted is the Common Object Request

Broker Architecture (CORBA).

6) What are the types of Transparencies available in CORBA?

Location transparency - A remote object appears the same as a local object.An Object

Request Broker (ORB) is used to locate objects

Language transparency - remote object do not have to be implemented in the same

language (Java, C++, Smalltalk) as local objects.

7) What is meant by ORB?

A central element in CORBA is the Object Request Broker (ORB). An ORB makes it

possible for a client object to make a server request without having to know where in a

network the server object or component is located and exactly what its interfaces are.

8) What are the two major ORB technologies ?

The Object Management Group's (OMG) Common Object Request Broker

Architecture (CORBA) specification

Microsoft's Component Object Model ( Component Object Model (COM), DCOM,

and Related Capabilities).

9) What are all the relevant functions of an ORB technologies ?

ORB technology promotes the goal of object communication across machine, software,

and vendor boundaries. The relevant functions of an ORB technology are

Interface definition

Location and possible activation of remote objects

Communication between clients and object

10) Draw a diagram for ORB



11) What is mean by proxy server?

A proxy server is a computer network service that allows clients to make indirect network

connections to other network services.

12) What are the CORBA features?

It specifies an interface description language (IDL), that allows you to specify the

interfaces to objects. IDL object interfaces describe, among other things:

The data that the object makes public.

The operations that the object can respond to, including the complete signature of the

operation. CORBA operations are mapped to Java methods, and the IDL operation

parameter types map to Java data types.

Exceptions that the object can throw. IDL exceptions are also mapped to Java

exceptions, and the mapping is very direct.

13) What is mean by IDL?

IDL is the language that CORBA uses to specify its objects. You do not write procedural

code in IDL--its only use is to specify data, methods, and exceptions.

14) What are the CORBA services?

System management

Task management

Information management

15) Differentiate stubs and skeletons.

Stubs Skeletons

Stubs are called client side proxy

objects.

Skeletons are called server side

stubs.

It forwards all invocations through

the ORB to the real target object.

It directly invokes the target

method.

16) Specify the features of SOM.

Meta programming

Binary compatibility

17) What are the features of CCM components?

Ports that are classified into facets, receptacles, event sources and

event sinks.

Primary keys, which are values that instances of entity components



Attributes and configuration

Home interfaces

18) What is facet?

A specialty of CCM components is the equivalent interface, which enablesnavigation

between the different facts of a CCM component.

19) How is IDL working?

ORB interfaces are defined via an Interface Definition Language (IDL). The IDL defines

the interface between one object and the next. OLE (DCOM) uses a similar mechanism,

known as the ODL (Object Definition Language).

20) What is meant by marshalling?

Converting request & response into suitable format for transmission from client to server.

Marshalling is the process of gathering data from one or more applications or non-

contiguous sources in computer storage, putting the data pieces into a message buffer, and

organizing or converting the data into a format that is prescribed for a particular receiver

or programming interface.

21) Define IIOP.

Internet Inter ORB Protocol(IIOP).

Distributed programs written in different languages can communicate over the

Internet through IIOP.

IIOP is a critical part of CORBA.By using CORBA,s IIOP a programmer can write

programs that can communicate with other programs via internet , immaterial of the

location and construction details of the program.

UNIT V THE OMG WAY€¦ · Language mapping for Java Reverse mapping Java to IDL 7. CORBA 2.3 1998...

Documents

Transcript of UNIT V THE OMG WAY€¦ · Language mapping for Java Reverse mapping Java to IDL 7. CORBA 2.3 1998...