ITT73 COMPONENT TECHNOLOGY

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.

Department of Information Technology, SMVEC Page106

 ITT73 COMPONENT TECHNOLOGY

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

Department of Information Technology, SMVEC Page107

 ITT73 COMPONENT TECHNOLOGY

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

Department of Information Technology, SMVEC Page108

 ITT73 COMPONENT TECHNOLOGY

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.

Department of Information Technology, SMVEC Page109

 ITT73 COMPONENT TECHNOLOGY

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

Department of Information Technology, SMVEC Page110

 ITT73 COMPONENT TECHNOLOGY

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

Department of Information Technology, SMVEC Page111

 ITT73 COMPONENT TECHNOLOGY

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.

Department of Information Technology, SMVEC Page112

 ITT73 COMPONENT TECHNOLOGY

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

Department of Information Technology, SMVEC Page113

 ITT73 COMPONENT TECHNOLOGY

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.

Department of Information Technology, SMVEC Page114

 ITT73 COMPONENT TECHNOLOGY

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

Department of Information Technology, SMVEC Page115

 ITT73 COMPONENT TECHNOLOGY

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

Department of Information Technology, SMVEC Page116

 ITT73 COMPONENT TECHNOLOGY

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.

Department of Information Technology, SMVEC Page117

 ITT73 COMPONENT TECHNOLOGY

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

Department of Information Technology, SMVEC Page118

 ITT73 COMPONENT TECHNOLOGY

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

Department of Information Technology, SMVEC Page119

 ITT73 COMPONENT TECHNOLOGY

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

Department of Information Technology, SMVEC Page120

 ITT73 COMPONENT TECHNOLOGY

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

Department of Information Technology, SMVEC Page121

 ITT73 COMPONENT TECHNOLOGY

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

Department of Information Technology, SMVEC Page122

 ITT73 COMPONENT TECHNOLOGY

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 Skeletons are called server side
objects. stubs.
It forwards all invocations through It directly invokes the target
the ORB to the real target object. 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

Department of Information Technology, SMVEC Page123

 ITT73 COMPONENT TECHNOLOGY

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.

Department of Information Technology, SMVEC Page124