DCOM (Distributed Component Object Model) and CORBA (Common Object Request Broker Architecture) are two popular distributed object models. In this paper, we make architectural comparison of DCOM and CORBA at three different layers: basic programming architecture, remoting architecture, and the wire protocol architecture.

1. NADAR SARASWATHI COLLEGE OF ARTS &
SCIENCE,THENI.
DEPARTMENT OF CS & IT
DISTRIBUTED COMPUTING
PRESENTED BY
G.KAVIYA
M.SC(IT)
TOPIC:CORBA, DCOM

2. SYNOPSIS:
CORBA:
• Introduction.
• CORBA includes four
components.
• Pre-CORBA Approach to
Client/Server Development.
• CORBA Approach to
Client/Server Development.
• Interface definition
language(IDL)
DCOM:
• What is DCOM (Distributed
Component Object Model)?
• Dynamic Data Exchange
• How Does DCOM Work?
• DCOM Architecture
• DCOM vs. CORBA

3. CORBA:
• Introduction
• CORBA includes four components.
• Pre-CORBA Approach to Client/Server Development
• CORBA Approach to Client/Server Development.
• Interface definition language(IDL).

4. CORBA
INTRODUCTION:
 The Common Object Request Broker architecture (CORBA) is a standard
developed by the Object Management Group (OMG) to provide interconnectivity
among distributed objects.
 CORBA is the world’s leading middleware solution enabling the exchange of
information, independent of hardware platforms, programming languages, and
operating systems.
 CORBA is essentially a design specification for an Object Request Broker
(ORB), where an ORB provides the mechanisms required for distributed objects
to communicate with one another, whether locally or on remote devices, written
in different languages, or at different locations on a network.

5. CONTINUE;
 The CORBA Interface Definition Language, or IDL, allows the development of
language and locations-independent interfaces to distributed objects.
 Using CORBA, application components can communicate with one another no
matter where they are located, or who has designed them.
 CORBA provides the location transparency to be able to execute these
applications.
 CORBA is frequently described as a “software bus” because it is a software-
based communications interface through which objects are located and
accessed. The for example below identifies the primary components seen within
a CORBA implementation.

6. CONTINUE;
• Data communication from client to
server is accomplished through a well-
defined object-oriented interface.
• The Object Request Broker (ORB)
determines the location of the target
object, send a request to that object, and
returns any response back to the caller.
• Through this object-oriented
technology, developers can take
advantage of features such as
inheritance, encapsulation,
polymorphism, and runtime dynamic
binding.

7. CONTINUE;
• These features allow applications to
be changed, modified and re-used
with minimal changes to the parent
interface.
• For Example below identifies how a
client sends a request to a server
through the ORB;

8. CORBA includes four components:-
Object Request Broker(ORB)
CORBA server
Naming service
CORBARequest node
Object Request Broker(ORB):-
The Object Request Broker (ORB) handles the communication,
marshaling, and unmarshaling of parameters so that the parameter handling is
transparent for a CORBA server and client applications.

9. CONTINUE;
CORBA server:-
The CORBA server creates
CORBA objects and initializes them with
an ORB. The server places references to
the CORBA objects inside a naming
service so that clients can access them.
Naming service:-
The naming service holds
references to CORBA objects.
CORBARequest node:-
The CORBARequest node acts
as a CORBA client.

10. Pre-CORBA Approach to
Client/Server Development:-
In Client/server computing, an
application consists of two parts:
The client application and the
server application. These two
applications a typically run on different
machines, connected by a network.
The client application makes requests
for information or services and
typically provides users with a means
to display results.
The key advantages of
client/server model are:
 Computing functions run on the
most appropriate machine system.
 Developers can balance the load
of application processing among
several servers.
 Server applications can be shared
numerous client applications.

11. CORBA Approach to Client/Server
Development:-
The CORBA model provides a more
flexible approach to developing distributed
application.
The CORBA model:
• Formally separates the client and sever
portions of the application.
The client application asks for the server
application to accomplish the task.
• Logically separates an application into
objects that can perform certain tasks,
called operations.

12. INTERFACE DEFINITION LANGUAGE(IDL)
 A foundation of the COBRA standards is the Interface Definition Language .
 IDL is the OMG standard for defining language – neutral APIs and provides the
platform-independent delineation of the interfaces of distributed objects.
 The ability of the COBRA environments to provide consistency between clients
and serves in heterogeneous environments begins with a standardized
definition of the data and operations constituting the client/sever interface .
 IDL defines the modules ,interfaces and operations for the applications and is
not considered a programming language. The various programming languages ,
such as Ada ,C++, C# , Java ,supply the implementation of the interface via
standardized IDL mappings.

13. The basic steps for CORBA development can be seen in the
following Example:
An overview of how the IDL is translated to the corresponding language (in this
example C++), mapped to the source code , complied, and then linked with the ORB
library, resulting in the client and server implementation.

14. DCOM
• What is DCOM (Distributed Component Object Model)?
• Dynamic Data Exchange
• How Does DCOM Work?
• DCOM Architecture :
• DCOM vs. CORBA

15. WHAT IS DCOM (DISTRIBUTED
COMPONENT OBJECT MODEL)?
• DCOM is a programming construct that allows a computer to run programs over
the network on a different computer as if the program was running locally.
DCOM is an acronym that stands for Distributed Component Object Model.
DCOM is a proprietary Microsoft software component that allows COM objects
to communicate with each other over the network.
• An extension of COM, DCOM solves a few inherent problems with the COM
model to better use over a network:
Marshalling.
Distributed garbage collection.
Using DCE/RPC as the underlying RPC mechanism

16. CONTINUE;

17. CONTINUE;
• Marshalling:
Marshalling solves a need to pass data from one COM object instance to
another on a different computer – in programming terms, this is called “passing
arguments.” For example, if I wanted Zaphod’s last name, I would call the COM
Object Last-name with the argument of Zaphod. The Last-name function would
use a Remote Procedure Call (RPC) to ask the other COM object on the target
server for the return value for Last-name(Zaphod), and then it would send the
answer – Beeblebrox – back to the first COM object.

18. CONTINUE;
• Distributed Garbage Collection:
Designed to scale DCOM in order to support high volume internet
traffic, Distributed Garbage Collection also addresses a way to destroy and
reclaim completed or abandoned DCOM objects to avoid blowing up the memory
on webservers. In turn, it communicates with the other servers in the transaction
chain to let them know they can get rid of the objects related to a transaction.
• Using DCE/RPC as the underlying RPC mechanism:
To achieve the previous items and to attempt to scale to support
high volume web traffic, Microsoft implemented DCE/RPC as the underlying
technology for DCOM – which is where the D in DCOM came from.

19. (DCOM) both object and component paradigm consists of a number of issues.
1.Interoperability
2. Versioning
3. Language independence
4. Size and complexity of system
Dynamic Data Exchange :
Dynamic Data Exchange or DDE, used to be designed for Microsoft
Windows to enable applications to exchange information of any specific type. As DDE
protocol is actually a little complicated and this complexity used to be interpreted by
using many software program vendors, Dynamic Data Exchange Management Library
(DDEML) was created. This library simplified interfacing with DDE protocol as well as
furnished a frequent interface for all developers.

20. How Does DCOM Work?
In order for DCOM to work, the
COM object needs to be configured
correctly on both computers – in our
experience they rarely were, and you had
to uninstall and reinstall the objects
several times to get them to work.
• The Windows Registry contains the
DCOM configuration data in 3 identifiers:
1) CLSID.
2) PROGID.
3) APPID.

21. • CLSID :-
The Class Identifier (CLSID) is a Global Unique Identifier (GUID). Windows stores a
CLSID for each installed class in a program. When you need to run a class, you need the
correct CLSID, so Windows knows where to go and find the program.
• PROGID :-
The Programmatic Identifier (PROGID) is an optional identifier a programmer can
substitute for the more complicated and strict CLSID. PROGIDs are usually easier to read
and understand. A basic PROGID for our previous example could be Hitchiker. Last Name
There are no restrictions on how many PROGIDs can have the same name, which causes
issues on occasion.
• APPID :-
The Application Identifier (APPID) identifies all of the classes that are part of the
same executable and the permissions required to access it. DCOM cannot work if the
APPID isn’t correct. You will probably get permissions errors trying to create the remote
object, in my experience.

22. DCOM Architecture :
• DCOM structure is designed for promoting software interoperability.
• The architecture supports a “software bus” on which reusable software program
components can be used and built-in with one any other seamlessly.
• Object model used to be selected due to fact of its incapability to provide inheritance.
• This means that architecture is successful in keeping off fragile base class syndrome
which exists in different models.
• The fragile base class syndrome seems when one class inherits members and behavior
of any other class.
• Class which offers behavior and member functions is recognized as base class while
other class is recognized as derived class.
• Changes like this end result in having to alter base class which in turn requires
compilation of all dependent classes.

23. A basic DCOM transaction looks like this:
• The client computer requests the remote computer to create an object by its
CLSID or PROGID. If the client passes the APPID, the remote computer looks up
the CLSID using the PROGID.
• The remote machine checks the APPID and verifies the client has permissions to
create the object.
• DCOMLaunch.exe (if an exe) or DLLHOST.exe (if a dll) will create an instance of
the class the client computer requested.
• The Client can now access all functions in the class on the remote computer.
• If the APPID isn’t configured correctly, or the client doesn’t have the correct
permissions, or the CLSID is pointing to an old version of the exe or any other
number of issues, you will likely get the dreaded “Can’t Create Object” message.

24. DCOM vs. CORBA
• Common Object Request Broker Architecture (CORBA) is a JAVA based
application and functions basically the same as DCOM. Unlike DCOM, CORBA
isn’t tied to any particular Operating System (OS), and works on UNIX, Linux,
SUN, OS X, and other UNIX-based platforms.
• Neither proved secure or scalable enough to become a standard for high volume
web traffic. DCOM and CORBA didn’t play well with firewalls, so HTTP became
the default standard protocol for the internet.