Module 1

Single Tier

Definition:
A single computer that contains a database and a front-end to access the database.
Generally this type of system is found in small businesses. There is one computer which stores all
of the company’s data on a single database. The interface used to interact with the database may be
part of the database or another program which ties into the database itself.

Advantages;
A single-tier system requires only one stand-alone computer. It also requires only one installation of
proprietary software. This makes it the most cost-effective system available.

Disadvantages:
May be used by only one user at a time. A single tier system is impractical for an organization which
requires two or more users to interact with the organizational data store at the same time.

Client Server model

Definition: Client/server describes the relationship between two computer programs in which
one program, the client, makes a service request from another program, the server, which fulfills the
request. For example, to check your e-mail from your computer, a client program on your computer
forwards your request to a server program at your Internet Service Provider (ISP). Once the server
program has retrieved your e-mail, it forwards them to the client on your computer, which then
allows you to read the e-mail.
Why we need this model?
Early computer systems are monolithic systems in which all the processing is occurred on
the same machine. But its very time consuming processes. So we adopt this client server model.
Using Client/server model we can
-Split work among multiple machines.
- maintain a database on server that separates from clients provide more security,
reliability and performance.

Clients’ access data from the data base which is in the server. How they access this data?
They use some non procedural language (means you describe what you want rather than how
to get it). SQL (Structured Query Language) is an example. They didn’t allow the user to specify
processing semantics within a query. This meant that large amounts of data often needed to be
transferred to the client to be processed even if the result after processing was very small. Network
congestion was inevitable. So the vendors of the database needed a way to move some of the
processing back to the database server. So they offered some stored procedures which is a code that
executes on the server side within the database management system. The stored procedure can be
used to access data within the database and process it before sending the result to the client. Since
the result is much smaller than the the data being processed, the traffic between the client and
server is substantially reduced. The stored procedures can also be shared between multiple clients.
But its downside is that stored procedures are inherently non portable because they are vendor-
specific.

What is 2-tier architecture?

In this architecture management of database occurred on the server tier and all other
processing occurred on the client tier. So each client was required to posses a significant processing
power. Here we can use the storage procedure mechanism to relieve the client in many cases, but it
will not work in all cases. Why? Can you give one example?
Here we find that in the two tier architecture the client has to do a lot of processing work. In order to
minimize the processing work we need a model that will distribute the work. So the client side
processing was possible to separate into application presentation and business logic processing
resulted in three tiers: a client tier for visual presentation, a middle tier for processing based on
business logic and a data tier for persistent data management.

• Presentation logic = User Interface, displaying data to the user, accepting input from
the user.

• Business logic = Data Validation, ensuring the data is kosher before being added to the
database.

• Data Access Logic = Database Communication, accessing tables and indices, packing
and and unpacking data

So we saw that in early stages of computer systems we use single tier systems. Then
developed 2-tier and multi tier systems. Client/server describes the relationship between two
computer programs in which one program, the client, makes a service request from another
program, the server, which fulfills the request. In single tier system there is only one database and a
front end to access the data base. In two-tier system all the presentation, business, data accesses
are done by the clients.
.
Three-Tier Client/Server Architectures

In a three-tier or multi-tier environment, the client implements the presentation logic (thin
client). The business logic is implemented on an application server(s) and the data resides on
database server(s).

A Multi-tier architecture is thus defined by the following three component layers:

1. A front-end component, which is responsible for providing

portable presentation logic;
2. A back-end component, which provides access to dedicated
services, such as a database server.
3. A middle-tier component, which allows users to share and control
business logic by isolating it from the actual application;

Advantages of Multi-Tier Client/Server architectures

• Network bottlenecks are minimized because the application layer does not transmit extra data
to the client, only what is needed to handle a task.
• When business logic changes are required, only the server has to be updated. In two-tier
architectures, each client must be modified when logic changes.
• The client is insulated from database and network operations. The client can access data
easily and quickly without having to know where data is or how many servers are on the
system.
• Database connections can be 'pooled' and thus shared by several users, which greatly reduces
the cost associated with per-user licensing.
• The organization has database independence because the data layer is written using standard
SQL which is platform independent. The enterprise is not tied to vendor-specific stored
procedures.
• Changes to the user interface or to the application logic are largely independent from one
another, allowing the application to evolve easily to meet new requirements.

• The application layer can be written in standard third or fourth generation languages, such as
Java, C or COBOL, with which the organization's in-house programmers are experienced.
Differences Between 2-Tier and 3-Tier Client/Server Architectures
Every client/server application contains three functional units:

 Presentation logic or user interface (for example, ATM machines)

 Business logic (for example software that enables a customer to request an account balance)
 Data (for example, records of customer accounts)

These functional units can reside on either the client or on one or more servers in your
application. Which of the many possible variations you choose depends on how you split the
application and which middleware you use to communicate between the tiers.
In 2-tier client/server applications, the business logic is buried inside the user interface on the
client or within the database on the server in the form of stored procedures. Alternatively, the
business logic can be divided between the client and server. File servers and database servers
with stored procedures are examples of 2-tier architecture.
 In 3-tier client/server applications, the business logic resides in the middle tier, separate from the
data and user interface. In this way, processes can be managed and deployed separately from the
user interface and the database. Also, 3-tier systems can integrate data from multiple sources.
2-Tier and 3-Tier Client/Server Models

N-tier Architecture

If you consider each major service to be a separate tier, the 3-tier architecture that we’ have
described quickly become an N-tier architecture.

Example for N-tier architecture is a web based application. A web based application might consist of
following tiers:

• Tier 1- a client tier presentation implemented by a web browser.

• Tier 2- a middle –tier distribution mechanism implemented by a web server.
• Tier 3- a middle –tier service implemented by a set of server-side scripts.
• Tier 4- a data-tier storage mechanism implemented by a relational database.
 In a three-tier or multi-tier environment, the client implements the presentation logic (thin
client). The business logic is implemented on an application server(s) and the data resides on
database server(s). it has got a lot of advantages than 2-tier. If you consider each major service to
be a separate tier, the 3-tier architecture that we’ have described quickly become an N-tier
architecture.

How communication between tiers is possible?

Client/Server applications spread on multiple computers, so they need to communicate with

each other.

How they communicate with each other?

For this they rely on a networking infrastructure such as TCP/IP or IPX.

But if we implement such a low level communication the transaction to multi-tier systems would not
have been possible.

In two tier system the task of abstracting the network protocols can easily be done. The
database vendors provided specialized libraries and drivers to access the database that abstracted
the various n/w protocols. Client-tier applications could be written without regard for the actual
location of the database. The client –tier applications were able to link in the appropriate library
(either statically or dynamically) that allowed the communication with the data tier. Since the
relational model provide a very structured and generic means for accessing the database, abstracting
the networking code was not overly difficult.

But the communication between the client applications and middle tier services can’t be done in
a generic and structured way as had be done in two-tier systems. Because client needs a model of
communication that blends in with the development platform being used to implement the client
applications. So standardization began to emerge.

So what actually a middle ware is?

Middleware is connectivity software that consists of a set of enabling services that allow multiple
processes running on one or more machines to interact across a network.

Middleware is essential to migrating mainframe applications to client/server applications and to

providing for communication across heterogeneous platforms. Middleware services are

sets of distributed software that exist between the application and the operating system and network
services on a system node in the network.

Middle Ware

Do you know which is the first middle ware technology that gain the wide acceptance?

Middleware services provide a more functional set of Application Programming Interfaces (API) than
the operating system and network services to allow an application to

• locate transparently across the network, providing interaction with another application or
service
• be independent from network services
• be reliable and available
• scale up in capacity without losing function

Middleware can take on the following different forms:

• Transaction processing (TP) monitors (see Transaction Processing Monitor Technology), which
provide tools and an environment for developing and deploying distributed applications.
• Remote Procedure Call (RPCs), which enable the logic of an application to be distributed
across the network. Program logic on remote systems can be executed as simply as calling a
local routine.
• Message-Oriented Middleware (MOM), which provides program-to-program data exchange,
enabling the creation of distributed applications. MOM is analogous to email in the sense it is
asynchronous and requires the recipients of messages to interpret their meaning and to take
appropriate action.
• Object Request Brokers (ORBs), which enable the objects that comprise an application to be
distributed and shared across heterogeneous networks.
Do you know which is the first middle ware technology that gain the wide acceptance?

What is RPC? (Remote Procedure Call)?

Remote Procedure Call (RPC) is a client/server infrastructure that increases the interoperability,
portability, and flexibility of an application by allowing the application to be distributed over multiple
heterogeneous platforms. It reduces the complexity of developing applications that span multiple
operating systems and network protocols by insulating the application developer from the details of
the various operating system and network interfaces--function calls are the programmer's interface
when using RPC.

Why we choose ORB instead of RPC?

RPC is appropriate for client/server applications in which the client can issue a request and wait
for the server's response before continuing its own processing. Because most RPC implementations
do not support peer-to-peer, or asynchronous, client/server interaction, RPC is not well-suited for
applications involving distributed objects or object-oriented programming.

What is ORB?

An object request broker (ORB) is a middleware technology that manages communication and
data exchange between objects. ORBs promote interoperability of distributed object systems because
they enable users to build systems by piecing together objects- from different vendors- that
communicate with each other via the ORB. The implementation details of the ORB are generally not
important to developers building distributed systems. The developers are only concerned with the
object interface details.

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

Object Request Broker

 An object request broker acts as a kind of telephone exchange. It provides a directory of services
and helps establish connections between clients and these services [CORBA 96, Steinke 95]. The
ORB must support many functions in order to operate consistently and effectively, but many of these
functions are hidden from the user of the ORB. It is the responsibility of the ORB, to make it appear as
if the object is local to the client, while in reality it may reside in a different process or machine. Thus the ORB
provides a framework for cross-system communication between objects. This is the first technical
step toward interoperability of object systems.

The next technical step toward object system interoperability is the communication of objects
across platforms. An ORB allows objects to hide their implementation details from clients. This can
include programming language, operating system, host hardware, and object location. Each of these
can be thought of as a "transparency, and different ORB technologies may choose to support
different transparencies, thus extending the benefits of object orientation across platforms and
communication channels.

There are many ways of implementing the basic ORB concept; for example, ORB functions can
be compiled into clients, can be separate processes, or can be part of an operating system kernel.
These basic design decisions might be fixed in a single product; or there might be a range of choices
left to the ORB implementer.

There are two major ORB technologies:

• The Object Management Group's (OMG) Common Object Request Broker Architecture
(CORBA) specification

Microsoft's Component Object Model (see Component Object Model (COM), DCOM, and Related
Capabilities)

Distributed Applications
CORBA products provide a framework for the development and execution of distributed
applications. But why would one want to develop a distributed application in the first place? As you
will see later, distribution introduces a whole new set of difficult issues. However, sometimes there is
no choice; some applications by their very nature are distributed across multiple computers because
of one or more of the following reasons:
• The data used by the application are distributed
• The computation is distributed
• The users of the application are distributed

Data are distributed

Some applications must execute on multiple computers because the data that the application
must access exist on multiple computers for administrative and ownership reasons. The owner may
permit the data to be accessed remotely but not stored locally. Or perhaps the data cannot be co-
located and must exist on multiple heterogeneous systems for historical reasons.

Computation is distributed

Some applications execute on multiple computers in order to take advantage of multiple processors
computing in parallel to solve some problem. Other applications may execute on multiple computers
in order to take advantage of some unique feature of a particular

system. Distributed applications can take advantage of the scalability and heterogeneity of the
distributed system.
Users are distributed

Some applications execute on multiple computers because users of the application communicate and
interact with each other via the application. Each user executes a piece of the distributed application
on his or her computer, and shared objects, typically execute on one or more servers. A typical
architecture for this kind of application is illustrated below. Prior to designing a distributed

application, it is essential to understand some of the fundamental realities of the distributed system
on which it will execute.

Fundamental Realities of Distributed Systems

Distributed application developers must address a number of issues that can be taken for granted
in a local program where all logic executes in the same operating system process. The following table
summarizes some of the basic differences between objects that are co-located in the same process,
and objects that interact across process or machine boundaries.

Co-located Distributed
Communication Fast Slow
Failures Objects fail together Objects fail separately
Network can partition
Concurrent access Only with multiple threads Yes
Secure Yes No

The communication between objects in the same process is orders of magnitude faster than
communication between objects on different machines. The implication of this is that you should
avoid designing distributed applications in which two or more distributed objects have very tight
interactions. If they do have tight interactions, they should be co-located. When two objects are co-
located, they fail together; if the process in which they execute fails, both objects fail. The designer
of the objects need not be concerned with the behavior of the application if one of the objects is
available and the other one is not. But if two objects are distributed across process boundaries, the
objects can fail independently. In this case, the designer of the objects must be concerned with each
of the object's behavior in the event the other object has failed. Similarly, in a distributed system the
network can partition and both objects can execute independently assuming the other has failed.
 The default mode for most local programs is to operate with a single thread of control. Single
threaded programming is easy. Objects are accessed in a well-defined sequential order according to
the program's algorithms, and you need not be concerned with concurrent access.

If you decide to introduce multiple threads of control within a local program, you must consider
the possible orderings of access to objects and use synchronization mechanisms to control
concurrent access to shared objects. But at least you have a choice of introducing multiple threads of
control. In a distributed application, there are necessarily multiple threads of control. Each
distributed object is operating in a different thread of control. A distributed object may have multiple
concurrent clients. As the developer of the object and the developer of the clients, you must consider
this concurrent access to objects and use the necessary synchronization mechanisms.

When two objects are co-located in the same process, you need not be concerned about security.
When the objects are on different machines, you need to use security mechanisms to authenticate
the identity of the other object.

Distributed Object Systems

Distributed object systems are distributed systems in which all entities are modeled as objects.
Distributed object systems are a popular paradigm for object-oriented distributed applications. Since
the application is modeled as a set of cooperating objects, it maps very naturally to the services of
the distributed system.

In spite of the natural mapping from object-oriented modeling to distributed object systems, do
not forget the realities of distributed systems described above. Process boundaries really do matter
and they will impact your design.

what is CORBA?

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.

The OMG

The Object Management Group (OMG) is responsible for defining CORBA. 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.
Some applications by their very nature are distributed across multiple computers because of one
or more of the following reasons:
• The data used by the application are distributed
• The computation is distributed
 • The users of the application are distributed

Distributed object systems are distributed systems in which all entities are modeled as objects.
Distributed object systems are a popular paradigm for object-oriented distributed applications. Since
the application is modeled as a set of cooperating objects, it maps very naturally to the services of
the distributed system. 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 INTRODUCTION

The Common Object Request Broker Architecture (CORBA) is a specification of a standard

architecture for object request brokers (ORBs). A standard architecture allows vendors to develop
ORB products that support application portability(the ease with which a system or component can
be transferred from one hardware or software environment to another ) and interoperability(the
ability of two or more systems or components to exchange information and to use the information
that has been exchanged) across different programming languages, hardware platforms, operating
systems, and ORB implementations:

The CORBA specification was developed by the Object Management Group (OMG), an industry
group with over six hundred member companies representing computer manufacturers, independent
software vendors, and a variety of government and academic organizations. Thus, CORBA specifies
an industry/consortium standard, not a "formal" standard in the IEEE/ANSI/ISO sense of the term.
The OMG was established in 1988, and the initial CORBA specification emerged in 1992. Since then,
the CORBA specification has undergone significant revision, with the latest major revision (CORBA
3.0) released in July 2002.

Using a CORBA-compliant ORB, a client can transparently invoke a method on a server object,
which can be on the same machine or across a network. The ORB intercepts the call, and is
responsible for finding an object that can implement the request, passing it the parameters, invoking
its method, and returning the results of the invocation. The client does not have to be aware of
where the object is located, its programming language, its operating system or any other aspects
that are not part of an object's interface. The "vision" behind CORBA is that distributed systems are
conceived and implemented as distributed objects. The interfaces to these objects are described in a
high-level, architecture-neutral specification language that also supports object-oriented design
abstraction.

CORBA ORBs are middleware mechanism. CORBA can be thought of as a generalization of remote
procedure call (RPC) that includes a number of refinements of RPC, including:

• a more abstract and powerful interface definition language

• direct support for a variety of object-oriented concepts
• a variety of other improvements and generalizations of the more primitive RPC .

What is CORBA good for?

CORBA is useful in many situations. Because of the easy way that CORBA integrates machines from
so many vendors, with sizes ranging from mainframes through minis and desktops to hand-held and
embedded systems, it is the middleware of choice for large (and even not-so-large) enterprises. One
of its most important, as well most frequent, uses is in servers that must handle large number of
clients, at high hit rates, with high reliability. CORBA works behind the scenes in the computer rooms
of many of the world's largest websites; ones that you probably use every day. Specializations for
scalability and fault-tolerance support these systems. But it's not used just for large applications;
specialized versions of CORBA run real-time systems, and small embedded systems.
 CORBA Architecture

CORBA defines architecture for distributed objects. The basic CORBA paradigm is that of a
request for services of a distributed object. Everything else defined by the OMG is in terms of this
basic paradigm.

The services that an object provides are given by its interface. Interfaces are defined in OMG's
Interface Definition Language (IDL). Distributed objects are identified by object references, which are
typed by IDL interfaces.

The figure below graphically depicts a request. A client holds an object reference to a distributed
object. The object reference is typed by an interface. In the figure below the object reference is typed
by the Rabbit interface. The Object Request Broker, or ORB, delivers the request to the object and
returns any results to the client. In the figure, a jump request returns an object reference typed by the
AnotherObject interface.

The ORB

The ORB is the distributed service that implements the request to the remote object. It locates
the remote object on the network, communicates the request to the object, waits for the results and
when available communicates those results back to the client.

The ORB implements location transparency. Exactly the same request mechanism is used by the
client and the CORBA object regardless of where the object is located. It might be in the same
process with the client, down the hall or across the planet. The client cannot tell the difference.

The ORB implements programming language independence for the request. The client issuing
the request can be written in a different programming language from the implementation of the
CORBA object. The ORB does the necessary translation between programming languages. Language
bindings are defined for all popular programming languages.

The Object Management Architecture (OMA)

OMA is a high-level vision of a complete distributed environment. It consists of four components that
can be roughly divided into two parts: system oriented components (Object Request Brokers and
Object Services), and application oriented components (Application Objects and Common Facilities).

Of these parts Object Request Broker is the one which constitutes the foundation of OMA and
manages all communication between its components. It allows objects to interact in a
heterogeneous, distributed environment, independent of the platforms on which these objects reside
and techniques used to implement them. In performing its task it relies on Object Services which are
responsible for general object management such as creating objects, access control, keeping track of
relocated objects, etc. Common Facilities and Application Objects are the components closest to the
end user, and in their functions they invoke services of the system components.

CORBA and the Object Management Architecture.

The OMA is itself a specification (actually, a collection of related specifications) that defines a
broad range of services for building distributed applications. The OMA goes far beyond RPC in scope
and complexity. The distinction between CORBA and the OMA is an important one because many
services one might expect to find in a middleware product such as CORBA (e.g., naming, transaction,
and asynchronous event management services) are actually specified as services in the OMA.

Object Management Architecture

OMA services are partitioned into three categories: CORBA Services, CORBA Facilities, and
Application Objects. The ORB (whose details are specified by CORBA) is a communication
infrastructure through which applications access these services, and through which objects interact
with each other. CORBA Services, CORBA Facilities, and Application Objects define different
categories of objects in the OMA; these objects (more accurately object types) define a range of
functionality needed to support the development of distributed software systems.

• CORBA Services or COS are defined as standard CORBA objects with IDL interfaces,
sometimes referred to as "Object Services”. They are considered fundamental to building non-
trivial distributed applications. These services are to support the integration and interoperation of
distributed objects. These services currently include asynchronous event management,
transactions, persistence, externalization, concurrency, naming, relationships, and lifecycle.
• CORBA Facilities may be useful for distributed applications in some settings, but are not
considered as universally applicable as CORBA Services. These "facilities" include: user interface,
information management, system management, task management, and a variety of "vertical
market" facilities in domains such as manufacturing, distributed simulation, and accounting.

• Application Objects provide services that are particular to an application or class of

applications. These are not a topic for standardization within the OMA, but are usually
included in the OMA reference model for completeness, i.e., object are either application-
specific, support common facilities, or are basic services.

Object Request Broker

Provides an infrastructure allowing objects to interact, independent of the specific platforms and
languages used to implement the objects.

Object Services
• Standardize the life-cycle management of objects
• Services cover such items as
• Creating objects
• Controlling access to objects
• Keeping track of relocated objects,
• Controlling the relationship between styles of objects
• Object Services provide for application consistency
Common Facilities
 • Commercially known as CORBAfacilities
• A set of generic application functions such as printing ,document management ,database
,electronic mail facilities
• Include facilities for use over the Internet

Domain Interfaces
• Vertical areas that provide functionality of direct interest to end-users in particular application
domains

Overview of CORBA Services

Provides the ability to bind a name to an object. Similar to other forms of directory
Naming Service
service.
Supports asynchronous message-based communication among objects. Supports
Event Service
chaining of event channels, and a variety of producer/consumer roles.
Lifecycle Service Defines conventions for creating, deleting, copying and moving objects.
Persistence Service Provides a means for retaining and managing the persistent state of objects.
Supports multiple transaction models, including mandatory "flat" and optional "nested"
Transaction Service
transactions.
Concurrency
Supports concurrent, coordinated access to objects from multiple clients.
Service
Relationship
Supports the specification, creation and maintenance of relationships among objects.
Service
Externalization Defines protocols and conventions for externalizing and internalizing objects across
Service processes and across ORBs.

CORBA specifies a system which provides interoperability between objects in a heterogeneous,

distributed environment and in a way transparent to the programmer. Its design is based on OMG
Object Model.

The OMG Object Model

The OMG Object Model defines common object semantics for specifying the externally visible
characteristics of objects in a standard and implementation-independent way. In this model clients
request services from objects (which will also be called servers) through a well-defined interface.
This interface is specified in OMG IDL (Interface Definition Language). A client accesses an object by
issuing a request to the object. The request is an event, and it carries information including an
operation, the object reference of the service provider, and actual parameters (if any). The object
reference is an object name that defines an object reliably.

The Basic Mechanics of issuing a request

The picture below shows the main components of the ORB architecture and their interconnections:
 The central component of CORBA is the Object Request Broker (ORB). It consists all of the
communication infrastructure necessary to identify and locate objects, handle connection
management and deliver data. In general, the ORB is not required to be a single component; it is
simply defined by its interfaces. The ORB Core is the most crucial part of the Object Request Broker;
it is responsible for communication of requests.

The basic functionality provided by the ORB consists of passing the requests from clients to the
object implementations on which they are invoked. In order to make a request the client can
communicate with the ORB Core through the IDL stub or through the Dynamic Invocation Interface
(DII). The stub represents the mapping between the language of implementation of the client and
the ORB core. Thus the client can be written in any language as long as the implementation of the
ORB supports this mapping. The ORB Core then transfers the request to the object implementation
which receives the request as an up-call through either an IDL skeleton, or a dynamic skeleton

Table summarizes the components of CORBA and their functional role.

The CORBA runtime infrastructure. The interface to the ORB Core is not defined by
ORB Core
CORBA, and will be vendor proprietary.
A standard interface (defined in IDL) to functions provided by all CORBA- compliant
ORB Interface
ORBs.
Generated by the IDL processor for each interface defined in IDL. Stubs hide the low-
IDL Stubs level networking details of object communication from the client, while presenting a high-
level, object type-specific application programming interface (API).
An alternative to stubs for clients to access objects. While stubs provide an object type-
Dynamic specific API, DII provides a generic mechanism for constructing requests at run time
Invocation (hence "dynamic invocation"). An interface repository (another CORBA component not
Interface (DII) illustrated in Figure 2) allows some measure of type checking to ensure that a target object
can support the request made by the client.
Provides extensibility of CORBA- compliant ORBs to integrate alternative object
technologies into the OMA. For example, adaptors may be developed to allow remote
Object Adaptor access to objects that are stored in an object-oriented database. Each CORBA-compliant
ORB must support a specific object adaptor called the Basic Object Adaptor (BOA) (not
illustrated in Figure 2). The BOA defines a standard API implemented by all ORBs.
IDL Skeletons The server-side (or object implementation-side) analogue of IDL stubs. IDL skeletons
receive requests for services from the object adaptor, and call the appropriate operations in
 the object implementation.
The server-side (or object implementation-side) analogue of the DII. While IDL skeletons
Dynamic
invoke specific operations in the object implementation, DSI defers this processing to the
Skeleton
object implementation. This is useful for developing bridges and other mechanisms to
Interface (DSI)
support inter-ORB interoperation.

CORBA is currently the dominant remoting architecture Why?

• It was intended from the very beginning to create a standard for remote method invocation.
• Allows for incredible versatility
• Broad language support
• Diverse plat form support
• Multi Vendor Support
• Freely available CORBA products

The fundamental traits of distributed object system include

1. Interfaces: is used to describe the contracts that describe the capabilities of the
distributed object in the system

2.Data types: A doc must support data types that allow data to be transmitted to and from
distributed objects. CORBA provides a rich set of types as well as support for enumerated
types, constants and structures.

3.Marshaling & unmarshaling: This is for ensuring data integrity. Marshalling process
packages data into a standard format so that it can be transmitted. Un marshalling is the
reverse process.

4.Proxies, stubs & skeletons: mechanism used for the seamless access to remote objects.

5.Object handles:(object reference):used to reference distributed object instances within

the context of a client’s programming language or script

6.Object creation: A DOC must provide a mechanism for creating a new instance of
distributed object. A factory is a special type of object used to create other distributed
object. In CORBA factory interfaces are user defined.

7.Object invocation: mechanism for invoking operations on a distributed object. CORBA

provides both static and dynamic invocation.

8.Object destruction: mechanism for removing a distributed object instance from the
system once it is no longer in use. But in CORBA distributed object remains alive forever
unless explicitly or timed out.

A distributed object example

In this example we are implementing a simple checking account.

The CORBA checking account objects will implement the three interfaces as shown in the table.

INTERFACES PROPERTIES METHODS

Account Name Deposit(amount)

Balance Withdraw(amount)
 Init(name)

AccountInit

Checking Account withdrawUsingCheck(CheckNumber,amount)

CORBA Objects & Clients

In this example we are going to create a CORBA object and 2 CORBA clients. We will implement our
CORBA object using Iona’s Orbix ( a CORBA 2.0 complaint product). In server side the first thing to
do in the implementation phase is to define the interfaces. In this example the CORBA object will
support one interface called Checking account that inherits from the Account and AccountInit
interfaces. To demonstrate CORBA clients that are implemented in both C++ and Java. We need to
use CORBA products that support both C++ and Java. We implement one client with Orbix/C++ and
other with Insprise’s VisiBroker Java ORB.

The Java client application is shown in the figure.

In this example rather than specifying a server name to the client at run time , the user required to
input a string know as string field interoperable reference(IOR) identifying the CORBA factory
that should be used to create the CORBA checking account object. The IOR provides an extremely
convenient way to interoperate between the two different ORB products.

CORBA allows for a rich set of data types. This include support for constants, enumerated types,
structures and arrays in addition to common base types like long and short . In our example the
interface utilizes the string data type for account name and long data type for the check number and
double data type for balance and amount.

Next we are going to defining the interfaces. CORBA utilize an interface definition language (IDL) to
describe the respective interfaces. IDL interface provides the starting point for implementing server
object and client applications.

CORBA IDL
What makes CORBA to work across a disparate array of operating system, vendors and programming
languages?

The CORBA IDL. This is a independent language for describing distributed object interfaces. it has
also been mapped to many languages including C,C++, Java, Small talk, COBOL and Ada.

The server side of CORBA begins with the specification of an interface in IDL. IDL is an object-
oriented declarative language for specifying server interfaces. It is not a programming language;
that is, 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.
A property is defined as an attribute, which is mapped by the IDL compiler to get and set methods;
a readonly attribute maps to a get method only. An operation corresponds to a method;
parameters must be specified as in, out, or inout. The following example illustrates an IDL interface
description.

The CORBA IDL code used for implementing CORBA checkingaccount object is shown below

CORBA IDL focuses strictly on interface definition. The first element in the code is a module
named ch3. This is used to scope IDL identifiers when mapping IDL to other languages. For example
when mapping this file i.e. Ch3.idl to C++, all generated symbols will be scoped to C++ namespace
named ch3. Similarly when mapped to Java all the generated symbols will be placed in java package
named ch3.

The next element in our IDL file is a definition for InvalidNameException.This exception will be
raised when an invalid name is passed to the init method of CORBA object (which is defined in the
AccountInit interface). The exception contains IDL data type, including simple types,structs,
unions,enums and reference to other CORBA objects. In this example the exception contains one
member called reason. This allows the CORBA object to pass a reason back to the client if the
exception is raised.

The first interface defined in our IDL file is Account. The Account interface supports 2 readonly
attribute: name and balance and supports two methods deposit() and withdraw(). Next method
is the destroy() method used by the client to destroy the object instance when it is no longer in
use.

The second interface is AccountInit. This interface is used to initialize the account using Init()
method . This method raises an exception if an invalid name is passed as an argument.

The next interface is checking account. This interface multiply-inherits from the Account and
AccountInit interface. checking account defines a new method -withdrawusingCheck().
Because the checking account inherits from AccountInit & Account , checking account
supports the name and balance attribute as well as the deposit() , withdraw(),init() and
destroy().

The last interface is the CheckingAccountFactory. This type of interface is unique to to CORBA.
In CORBA the , the factory interface which is used for creating another type of CORBA object is user
defined. In this interface we define a Create() that can be used by the clients to create a
CheckingAccount instance

CORBA Proxies, Stubs and Skeletons

What are proxies, stubs and skeletons?

They are the mechanism used for remote method invocation. In COM the client side mechanism is
called proxies and server side mechanism is called stub. In CORBA the client side mechanism refer to
as client stub and the server side mechanism as a server stub.

A RMI is implemented as follows

• A client invokes a remote method. The remote method is actually invoked in the client stub.
• The client stub creates a message containing information needed for the RMI(marshalling)
• The client stub sends the message to the server stub using the communication bus
• The server stub receives the message and unpack it.(unmarshalling)
• The server stub calls the appropriate server method based on the information provided in the
message
• The server stub creates a message based on the outputs of the call to the server method(i.e.
the return value and the out parameters)
• The server stubs sends the result message to the client stub using the communication bus
• The client stub receives the result message, unpacks the message, and returns the result to
the client.

The stub and skeleton are used to support the custom interfaces that are used in the system. So it
should not be a hand-coding. So CORBA provides tools to generate client and server stubs from IDL
description.

Let us now look how the stub and skeletons are generated from CORBA IDL

CORBA stubs and Skeletons

In our example one client is implemented by using c++ and other by java. To generate Orbix stub
and skeleton, we invoke the Orbix IDL compiler as shown
C:\orbix\bin\idl.exe –B ch3.idl

The following files are generated by the IDL compiler

Ch3.hh //declarations

Ch3c.cpp //Orbix client stub

Ch3s.cpp //Orbix server skeleton

The structure CORBA client, stub, skeleton and server in checking Account example is as shown
below.

The stub (ch3c.obj) allows the client to link with the ORB and the skeleton (ch3s.obj) allows the
server to link with ORB. The client and server ORBs communicate usion a protocol called IIOP –
CORBA 2.0 standard communication protocol for TCP/IP.

The Java client invokes the VisiBroker IDL compiler to generate the VisiBroker client stub.

C:\vbroker\bin\idl2java...\...\servers\idl\ch3.idl

This Idljava2 compiler generates a package named ch3 corresponding to the ch3 IDL module. This
package contains the stub classes needed by the java client.

The VisiBroker and Orbix ORBs communicate using IIOP.

Implementing the servers

For implementing the server we need to do the following things

1. We create our IDL description using a generic editor. The IDL description is
vendor specific and implementation –neutral
2. We compile our IDL description using IDL compiler that is provided with Orbix
product. This generates the files ch3.hh, ch3c.cpp and ch3s.cpp (name given
are Orbix specific)
3. We implement the server using the files generated in step2 and an Orbix
specification implementation approach.

The most important point is that when using both COM & CORBA is that distributed object clients do
not care how the distributed object servers are implemented. The clients rely on IDL definitions.

Implementing the Clients

To avoid being distracted by any code not related to distributed objects, we have chosen to create
wrapper classes called MyCheckingAccount.

Each client application uses its wrapper classes in the following way:

1. The client application starts up and creates an instance of the MycheckingAccount class.
2. Whenever the user initializes a new connection (by clicking on the initialize button) , the client
application calls Init() on the MyCheckingAccount instance.
3. During Init(),the MyCheckingAccount instance is releases any previously held reference and
set its reference to a newly created distributed object. It then enters the enabled state.
4. All wrapped methods call the appropriate methods on the distributed object when the
MyCheckingAccount instance is enabled.

Steps to develop a Corba application

1. Writing an IDL source

2. Creating stubs and skeletons

3. Implement Server
4. Implement client

CORBA OBJECTS

A CORBA object is a virtual entity in the sense that it does not exist on its own, but rather is
brought to life when, using the reference to that CORBA object, the client application requests an
operation on that object. The reference to the CORBA object is called an object reference. When the
client or server application issues a request on an object via an object reference, the server
application instantiates the object specified by the object reference, if the object is not already active
in memory. Instantiating an object typically involves the server application initializing the object's
state, which may include having the object's state read from durable storage, such as a database.
The object contains all the data necessary to do the following:

*Execute the object's operations.

* Store the object's state in durable storage when the object is no longer needed.

Creating objects is simple. New operator can be used.Creating a distributed object instance
requires more effort since object is usually created in a different process on a different machine.An
abstraction is needed to redirect creation of a distributed object to a remote location.CORBA relys on
factory to create distributed object instances.

* In C++ object is deleted using delete operator

*Java uses garbage collection
* Reference Counting is used
* Server object is destroyed when no longer a client is using it.
*Another method is to maintain a list of object references and timestamps all object instances
the time stamp indicates the

CORBA Object References

Introduction

Correct use of object references is an essential skill for CORBA developers. Object references
are largely a client-side issue but there is server-side implications’ arising from the C++
language mapping that defines how object references are exchanged during CORBA request
invocations. The object references are (_ptr) type and (_var) type that assists with memory
management and parameter passing.

Object Reference Defined

An object reference is a handle to a CORBA object. A CORBA object is a vague concept but
two aspects of CORBA objects are clear. Every CORBA object realizes a specific interface and
has a distinct identity. An object's interface defines the operations and attributes it offers to
its clients. An object's identity informs an ORB where and how to dispatch its client's
requests. An object reference embodies the corresponding CORBA object's identity and
interface, and constitutes the primary means for invoking a CORBA object's operations.
(Attributes in effect define operations so hereafter an object's interface will be described only
in terms of operations.)

An object reference can take many forms. Some forms are language independent and some
are language specific. A stringified IOR is a language independent form of object reference.
The following is a stringified reference to a CORBA object

IOR:010000001900000049444c3a6f63697765622e636f6d2f48656c6c6f
3a312e3000000000010000000000000060000000010102cd050000006469
6e6f00cde12e1b00000014010f005253547fb8d63dd48809000000000001
00000001000000cd02000000000000000800000001cdcdcd004f41540100
00001400000001cdcdcd01000100000000000901010000000000

The CORBA object it refers to realizes the following interface:

#include "example_exceptions.idl"

interface Hello
{
void say_hello();
string ior_please();
 void take_exception() raises (ExampleExceptions::SimpleException);
void shutdown();
};

A corbaloc URL is another language independent form of object reference. The following
corbaloc URL is another reference to the object denoted by the preceding stringified IOR:

corbaloc:iiop:dino:12001/Hello

Language independent object references are essential to interoperability. They allow the
exchange of object references between clients and servers deployed on heterogeneous
platforms and implemented in different languages. Language specific forms are defined by
formal language mappings to enable concrete development in the various languages
supported by CORBA.

An object reference in the C++ language is a pointer to an object that proxies for the target
CORBA object and has the target object's interface. A client invokes a request by
dereferencing the pointer using native C++ syntax. When a client invokes a CORBA request,
the proxy forwards the request to the local ORB. The local ORB uses identity information held
by the object reference to locate the target object and dispatches the request accordingly. A
synchronous request's reply is returned to the proxy by the local ORB and the proxy returns
the reply to the client.

For each interface, the IDL compiler generates the servant base class, the proxy object class,
several helper types, and two pointer types, a basic pointer and a smart pointer. For the Hello
interface presented earlier, servant based class is named POA_Hello, the proxy object class is
named Hello, the basic pointer type is named Hello_ptr, and the smart pointer type is named
Hello_var. The basic pointer is analogous to a native C++ pointer. The smart pointer has the
same behavior as the basic pointer but provides additional features that simplify memory
management and parameter passing. One of the generated helper classes assists with
passing object references as out mode parameters. For the Hello interface, this helper type is
named Hello_out. It is common practice to refer to these types in a general sense, e.g. the
"pointer type," the "var type," and the "out type." These phrases refer respectively to
generated _ptr, _var, and _out types.

Creating and Obtaining Object References

An object reference is created when the corresponding CORBA object is created. CORBA
objects are commonly created when servants are activated via
PortableServer::POA::activate_object(). However, CORBA objects can be created without
activating servants via other operations. CORBA servers often export object references, in
different forms using a variety of mechanisms, to provide clients with access to their CORBA
objects. However, object references can be exposed to clients without the server's direct
participation using forms such as corbaloc URLs.

An object reference can be introduced into a client's address space in many ways. Clients
frequently employ ORB operations such as CORBA::ORB::resolve_initial_references() and
CORBA::ORB::string_to_object() to obtain object references. Clients often use a Naming
Service and obtain object references via CosNaming::NamingContext::resolve(). Clients may
also obtain object references by invoking requests on known CORBA objects, i.e. objects
already accessible in their address space, that act as factories for other CORBA objects.

When an object reference is introduced into a client's address space, regardless of the
mechanism, the local ORB creates a proxy object and returns a basic pointer to that proxy. An
ORB chooses a proxy object class based on the interface type information at hand when a
reference is introduced. This allows ORBs to produce object references in a type-safe manner.
Often, the available type information is sufficient only to return a CORBA::Object reference.
This is the case with operations such as CORBA::ORB::resolve_initial_references(),
CORBA::ORB::string_to_object(), and CosNaming::NamingContext::resolve(). When the ORB
returns a CORBA::Object reference, the client is then obligated to narrow the reference to a
more specific type. Factory object interfaces typically return specific object types, which allow
an ORB to create a type specific reference in a safe manner.

Clients are specifically prohibited from directly creating object references with the exception
of a nil reference. Clients are permitted to copy object references, to narrow and widen object
references to other related types, and to pass object references as parameters during CORBA
request invocations. Clients are also obligated to collaborate with the ORB in managing
resources allocated to object references. This includes informing the ORB when object
references are copied (duplicated) and destroyed (released). Most ORBs employ reference
counting as a memory management technique but this is not required. The memory
management interfaces and a client's obligations are independent of the ORB's
implementation.

Basic Pointer: The _ptr Type

This section demonstrates use of the basic pointer, the _ptr type. The examples are based in
part on the Hello interface shown previously. All references are initially introduced into the
client's address space using CORBA::ORB::string_to_object() but there are some examples
that demonstrate factory object behavior.

CORBA::ORB::string_to_object() returns CORBA::Object_ptr types, i.e. CORBA::Object

references, because there isn't sufficient type information to return a more specific type, e.g.:

CORBA::Object_ptr obj = orb->string_to_object("file://server.ior");

The caller should always verify that the object reference returned is not nil:

if(CORBA::is_nil (obj))
{
// error: nil object reference returned
}

The client now has a reference to a CORBA::Object, a basic pointer to a proxy having the
CORBA::Object interface:

To gain access to something more useful than a CORBA::Object, the client must narrow the
object reference:

Hello_ptr Hello_obj = Hello::_narrow(obj);

This operation returns an object reference having the Hotel interface or a nil reference. A nil
reference will be returned if the target object's interface is not Hotel. Consequently, clients
should always verify that the object reference returned from a _narrow () operation is not nil:

if (CORBA::is_nil (Hello_obj))
{
// error: nil object reference returned
}
The client now has a reference to a Hello object:

A consequence of the preceding two operations is that the ORB has allocated resources for
two distinct proxy objects, a proxy for a CORBA::Object and a proxy for a Hello object.
Although both proxies are associated with the same target object, their interfaces are
different and therefore they are separate proxy objects. The client has access to these
objects, via pointers provided by the ORB, but the ORB retains ownership so it can manage
resources in a coherent manner. Because clients have access to resources owned by the ORB,
clients must collaborate with the ORB to protect their interests in the use object references
and to assist the ORB in the recovery of its resources.

To inform the ORB that an object reference is no longer in use and may be destroyed, a client
calls CORBA::release():

CORBA::release(obj);

The ORB may destroy the obj reference and recover its resources upon the call to
CORBA::release() or anytime thereafter. The client must assume, however, that the object
reference is destroyed immediately upon the call to CORBA::release() and treat it
accordingly:

The obj variable can be re-used to refer to other CORBA::Objects but it must not be used to
invoke requests until it has been associated with another CORBA object.

The release of obj has no effect on Hello_obj because they are distinct references so the
following sequence is valid:

CORBA::Object_ptr obj = orb->string_to_object("file://server.ior");

Hello_ptr Hello_obj = Hello::_narrow(obj);
CORBA::release(obj);
Hello_obj->say_hello();

Similarly, the release of Hello_obj has no effect on obj. The following sequence, although
nonsensical, demonstrates the point:

CORBA::Object_ptr obj = orb->string_to_object("file://server.ior");

for(int i = 0; i < 10; ++i)
{
Hello_ptr Hello_obj = Hello::_narrow(obj);
Hello_obj->say_hello();
CORBA::release(Hello_obj);
}

To copy an object reference, a client calls _duplicate() using the appropriate proxy class. For
example, to copy a Hello object reference:

Hello_ptr Hello_obj2 = Hello::_duplicate(Hello_obj);

Hello_obj2 is a reference to target object referred to by Hello_obj.

Other object references, including CORBA::Objects are also be copied in this manner:

CORBA::Object_ptr obj2 = CORBA::Object::_duplicate(obj);

Conceptually, the ORB performs a deep copy when object references are duplicated. Most
ORBs employ reference counting so this operation usually amounts to incrementing a proxy
object's reference count. Similarly, a release operation usually amounts to decrementing a
proxy object's reference count. A proxy object continues to exist until its reference count
reaches 0 at which time the object is destroyed and associated resources recovered.
However, it is important to treat different object references, e.g. Hello_obj and Hello_obj2, as
distinct references each having dedicated resources managed by the ORB.

Exchanging Object References Using _ptr Types

This section discusses the exchange of object references using the _ptr type. From the client
side, object references are exchanged using just the _ptr types. Server implementations also
employ _ptr types except for object references passed as out mode parameters where the
_out type is used. The examples that follow are based on the Hello interface seen previously
and the following:

#include "Hello.idl"

interface Hello_Utils
{
Object object_from_ior(in string ior);
Hello hello_from_object(in Object obj);
void save_hello(in short which, in Hello hello);
void get_hello(in short which, out Hello hello);
void change_to(in short which, inout Hello hello);
};

This interface was designed to demonstrate passing and returning object references to and
from CORBA requests. Hello_Utils::object_from_ior() accepts a string form of object
reference, a stringified IOR, a corbloc URL, etc., and returns a CORBA::Object reference.
Hello_Utils::hello_from_object() accepts a CORBA::Object reference and returns a Hello
object reference. Hello_Utils::save_hello() accepts a short integer, which serves as a key, and
a Hello object reference. The object reference is retained for subsequent retrieval using the
given key value. Hello_Utils::get_hello() returns, via an out parameter, the Hello object
reference associated with a given key value. Hello_Utils::change_to() performs a similar
function using an inout parameter instead of an out parameter.
In the subsequent examples, Utils_obj is a Hello_Utils object reference.

The first example, Hello_Utils::object_from_ior() demonstrates returning an object reference

from a CORBA request. The operation definition:

Object object_from_ior(in string ior);

maps to the following proxy class method signature:

CORBA::Object_ptr Hello_Utils::object_from_ior(const char * ior);

An IOR is passed as a C string and the operation returns the corresponding CORBA::Object
reference:

CORBA::Object_ptr obj = Utils_obj->object_from_ior("corbaloc:iiop:dino:12001/Hello");

This operation is implemented simply as (by convention, _i is appended to Hello_Utils to

denote the Hello_Util's servant implementation.):

CORBA::Object_ptr
Hello_Utils_i::object_from_ior(const char *ior)
throw ( CORBA::SystemException )
{
CORBA::Object_ptr obj = orb_->string_to_object(ior);
return obj;
}

This is not a particularly interesting implementation. It serves only to demonstrate that object
references are returned as _ptr types, that object references returned from CORBA requests
are released upon the return, and that clients assume responsibility for object references
returned by CORBA requests. The servant implementation does not explicitly release the
reference, this occurs automatically upon the operation's return. A client that receives an
object reference via a CORBA request must release the reference when it is no longer
required.

The client's behavior is demonstrated by the following:

CORBA::Object_ptr obj = orb->string_to_object ("file://utils.ior");

Hello_Utils_ptr Utils_obj = Hello_Utils::_narrow (obj);
CORBA::release(obj);
obj = Utils_obj->object_from_ior("corbaloc:iiop:dino:12001/Hello");
Hello_ptr Hello_obj = Hello::_narrow(obj);
CORBA::release(obj);
//
// do useful stuff with Hello_obj;
//
CORBA::release(Hello_obj);

Each object reference, obj and Hello_obj, is released prior to its re-use or when it is no longer
needed.

Object references passed to CORBA requests are passed as _ptr types. The operation:

Hello hello_from_object(in Object obj);

maps to the following Hello_Utils proxy method signature:

Hello_ptr Hello_Utils::hello_from_object(CORBA::Object_ptr obj);

A server can use an object reference passed as an in parameter for the duration of the
request. However, the server isn't responsible for the resources allocated to the object
reference and therefore shouldn't release it. A simple implementation of this method is:

Hello_ptr
Hello_Utils_i::hello_from_object(CORBA::Object_ptr obj)
throw (CORBA::SystemException)
{
Hello_ptr hello_obj = Hello::_narrow(obj);
return hello_obj;
}

The server has use of the object reference obj but doesn't have responsibility for it and so
doesn't release it. Moreover, the reference is automatically released upon the operation's
return so the server must copy the reference to retain it. Retaining an object reference
beyond the lifetime of a single CORBA request is demonstrated by the following operation:

void save_hello(in short which, in Hello hello);

A simple implementation of this operation is:

void
Hello_Utils_i::save_hello(CORBA::Short which, Hello_ptr hello)
throw (CORBA::SystemException)
{
if(1 <= which && which <= 2)
{
if(!(CORBA::is_nil(hello_objs_[which - 1])))
{
CORBA::release(hello_objs_[which - 1]);
}
hello_objs_[which - 1] = Hello::_duplicate(hello);
}
}

The servant's implementation retains references to Hello objects in a small array. The value
which, serving as a key, is used as the array index. This operation receives a Hello object
reference along with its key, releases the reference previously associated with the given key,
if any, and then duplicates the new reference using the appropriate proxy class method. Using
the operations seen so far a client can first obtain and then preserve, for later use, a Hello
object reference as follows:

CORBA::Object_ptr obj = orb->string_to_object ("file://utils.ior");

Hello_Utils_ptr Utils_obj = Hello_Utils::_narrow (obj);
CORBA::release(obj);
obj = Utils_obj->object_from_ior("corbaloc:iiop:dino:12001/Hello");
Hello_obj = Utils_obj->hello_from_object(obj);
CORBA::release(obj);
//
// do stuff with Hello_obj
//
Utils_obj->save_hello(1, Hello_obj);
CORBA::release(Hello_obj);
Note that the client's release of the Hello reference has no effect on the Hello_Util server's
reference to the same target object. These references are distinct and independent
references. It is likely that they exist in separate address spaces but even if that were not the
case the references are independent of one another.

The next operation demonstrates passing an object reference to a CORBA request as an out
mode parameter. Conceptually, the client passes to the server a reference to a _ptr and the
server populates the reference. The client can use the reference after the request returns if
no exceptions occur. If an exception occurs, the condition of the object reference is undefined
and the client should not attempt to access it.

By definition, a reference passed as an out mode parameter should be nil when the operation
is invoked. The client continues to employ _ptr types as with the other modes. The server,
however, employs the _out helper type generated by the IDL compiler in its implementation.
The following operation:

void get_hello(in short which, out Hello hello);

maps to the following proxy class method:

void Hello_Utils::get_hello(CORBA::Short which, Hello_out hello)

throw (CORBA::SystemException)

A client invokes this operation as follows:

Hello_ptr Hello_obj = Hello::_nil();

Utils_obj->get_hello(1, Hello_obj);
Hello_obj->say_hello();

This example illustrates the point that object references exchanged via out parameters are nil
upon invocation and populated during the operation. This is enforced by the _out type, which
sets the reference to _nil in its constructor.

A simple implementation of this operation consistent with the preceding void

Hello_Utils_i::save_hello() is:

void
Hello_Utils_i::get_hello(CORBA::Short which, Hello_out hello)
throw (CORBA::SystemException)
{
if(1 <= which && which <= 2)
{
hello = Hello::_duplicate(hello_objs_[which - 1]);
}
}

The server populates the hello object reference by duplicating a reference previously retained
by the save_hello() operation. Duplicating the reference is essential because responsibility for
references exchanged via an out parameter passes from the server to the client upon the
operation's return. The reference passed by the server is released from the server's address
space so it can be transferred to the client's address space. If the server's source reference
was not duplicated, the server would be left with a dangling reference. Of course, releasing
the reference is not necessary if the server doesn't wish to retain a copy for subsequent use.
However, it is necessary in this example because the server retains copies of the references
obtained via save_hello.
 The role of the _out class, in this example a Hello_out, is to simplify handling of references
exchanged via an out paramter and insure consistency with the parameter passing rules.

An object reference passed to a CORBA request as inout mode parameter is passed as a

reference to a _ptr. The operation:

void change_to(in short which, inout Hello hello);

maps to the following proxy class method:

void Hello_Utils::change_to(CORBA::Short which, Hello_ptr & hello)

throw (CORBA::SystemException)

The server obtains responsibility for an object reference passed as inout mode parameter. It
has access to the reference upon the invocation and must release the incoming reference if it
is modified, which is the typical case. Following is a simple implementation that demonstrates
the rule:

void
Hello_Utils_i::change_to(CORBA::Short which, Hello_ptr & hello)
throw (CORBA::SystemException)
{
if(1 <= which && which <= 2)
{
if(!CORBA::is_nil(hello_objs_[which - 1]))
{
CORBA::release(hello);
hello = Hello::_duplicate(hello_objs_[which - 1]);
}
}
}

The important difference between this operation's implementation and the preceding example
is that the server must release the incoming reference before assigning the new value. As
with the preceding example, the reference assigned to the parameter hello is first duplicated
in accordance with memory management policy.

The client passes a valid reference to the request as follows:

Utils_obj->get_hello(2, Hello_obj);
Hello_obj->say_hello();
//
// Change to the first reference.
//
Utils_obj->change_to(1, Hello_obj);
Hello_obj->say_hello();

The client does not release the Hello_obj reference prior to invoking Hello_Utils::change_to()
because this is the server's responsibility.

Comparison of CORBA & DCOM Architectures.

DCOM
*Supports multiple interfaces for objects and uses the QueryInterface() method to navigate
among interfaces. This means that a client proxy dynamically loads multiple server stubs in the
remoting layer depending on the number of interfaces being used.
 *Every object implements IUnknown. *
Uniquely identifies a remote server object through its interface pointer, which serves as the
object handle at run-time * Uniquely
identifies an interface using the concept of Interface IDs (IID) and uniquely identifies a named
implementation of the server object using the concept of Class IDs (CLSID) the mapping of which
is found in the registry. * The remote server object reference generation
is performed on the wire protocol by the Object Exporter
* Tasks like object registration, skeleton instantiation etc. are either explicitly performed by the
server program or handled dynamically by the COM run-time system.
* Uses the Object Remote Procedure Call(ORPC) as its underlying remoting protocol * When a
client object needs to activate a server object, it can do a CoCreateInstance()-
* The object handle that the client uses is the interface pointer *The
mapping of Object Name to its Implementation is handled by the Registry * The type
information for methods is held in the Type Library *The responsibility of
locating an object implementation falls on the Service Control Manager (SCM)
* The responsibility of activating an object implementation falls on the Service Control Manager
(SCM) * The client side stub is
called a proxy. The server side stub is called stub *All parameters passed
between the client and server objects are defined in the Interface Definition file. Hence,
depending on what the IDL specifies, parameters are passed either by value or by reference.
* Attempts to perform distributed garbage collection on the wire by pinging. *Allows you to
define arbitrarily complex structs, discriminated unions and conformant arrays in IDL and pass
these as method parameters. Complex types that will cross interface boundaries must be
declared in the IDL. * Will run on any platform as long as there is a
COM Service implementation for that platform
*Since the specification is at the binary level, diverse programming languages like C++, Java,
Object Pascal (Delphi), Visual Basic and even COBOL can be used to code these objects
* Each method call returns a well-defined "flat" structure of type HRESULT, whose bit settings
encode the return status. For richer exception handling it uses Error Objects (of type IErrorInfo),
and the server object has to implement the ISupportErrorInfo interface.

CORBA
• Supports multiple inheritance at the interface level
• Every interface inherits from CORBA.Object
• Uniquely identifies remote server objects through object references(objref), which serves as
the object handle at run-time. These object references can be externalized (persistified) into
strings which can then be converted back into an objref.
• Uniquely identifies an interface using the interface name and uniquely identifies a named
implementation of the server object by its mapping to a name in the Implementation
Repository
• The remote server object reference generation is performed on the wire protocol by the
Object Adapter
• The constructor implicitly performs common tasks like object registration, skeleton
instantiation etc
• Uses the Internet Inter-ORB Protocol(IIOP) as its underlying remoting protocol
• When a client object needs to activate a server object, it binds to a naming or a trader service
–
• The object handle that the client uses is the Object Reference
• The mapping of Object Name to its Implementation is handled by the Implementation
Repository
• The type information for methods is held in the Interface Repository
• The responsibility of locating an object implementation falls on the Object Request Broker
(ORB)
• The responsibility of locating an object implementation falls on the Object Adapter (OA) -
either the Basic Object Adapter (BOA) or the Portable Object Adapter (POA
• The client side stub is called a proxy or stub. The server side stub is called a skeleton
• When passing parameters between the client and the remote server object, all interface types
are passed by reference. All other objects are passed by value including highly complex data
types
• Does not attempt to perform general-purpose distributed garbage collection
• Complex types that will cross interface boundaries must be declared in the IDL
• Will run on any platform as long as there is a CORBA ORB implementation for that platform
• Since this is just a specification, diverse programming languages can be used to code these
objects as long as there are ORB libraries you can use to code in that language
• Exception handling is taken care of by Exception Objects. When a distributed object throws an
exception object, the ORB transparently serializes and marshals it across the wire