DOC - Distributed Object Computing
Developing distributed software using heterogeneous systems. DOC incorporates distributed computing and object technology.
CORBA
* uses an OO model( abstraction, encapsulation, inheritance,
modularity)
* uses an open distributed computing environment.
* uses component integration and reuse
these are the foundational principles.
In this concept everything is an interface. CORBA itself is just a specification.
OO Model
A client server model - Both client and server
are objects.
This supports a peer to peer communication between two objects. Both server and client objects can be in any address space on any machine. Client may not know where the server object resides. CORBA enables in discovering where possible servers reside.
Open distributed computing environment :
CORBA makes it open by the virtue of the concept of a broker.
Provides common services:
messaging, communication, directory services, security services and so
on.
Insulates the application objects from hardware,platform, OS, netwrok protocols,
languages etc.
Enablels Component reuse and integration
When a new component E was incorporated the advantage is evident in systems
using CORBA
The Common Object Request Broker Architecture (CORBA) is an emerging open distributed object computing infrastructure being standardized by the Object ManagementGroup (OMG). CORBA automates many common network programming tasks such as object registration, location, and activation; request demultiplexing; framing anderror-handling; parameter marshalling and demarshalling; and operation dispatching.
The following figure illustrates the primary components
in the OMG Reference Model architecture.
Architecture of CORBA
Object Services -- These are
domain-independent interfaces that are used by many distributed object
programs. For example, a service providing for the discovery of other available
services is almost always necessary regardless of the application domain.
Two examples of Object Services that fulfill this role are:
The Naming Service -- which allows clients to find objects based on names;
The Trading Service -- which allows clients to find objects based on their
properties.
There are also Object
Service specifications for lifecycle management, security, transactions,
and event notification, as well as many others.
Common Facilities -- Like Object
Service interfaces, these interfaces are also horizontally-oriented, but
unlike Object Services they are oriented towards end-user applications.
An example of such a facility is the Distributed Document Component Facility
(DDCF), a compound document Common Facility based on OpenDoc. DDCF
allows for the presentation and interchange of objects based on a document
model, for example, facilitating the linking of a spreadsheet object
into a report document.
Domain Interfaces -- These interfaces
fill roles similar to Object Services and Common Facilities but are oriented
towards specific application domains. For example, one of the first
OMG RFPs issued for Domain Interfaces is for Product Data Management (PDM)
Enablers for the manufacturing domain. Other OMG RFPs will
soon be issued in the telecommunications, medical, and financial domains.
Application Interfaces - These are
interfaces developed specifically for a given application. Because they
are application-specific, and because the OMG does not develop applications
(only specifications), these interfaces are not standardized. However,
if over time it appears that certain broadly useful services emerge
out of a particular ap plication domain, they might become candidates for
future OMG standardization.
CORBA ORB Architecture
The following figure illustrates the primary components in the CORBA ORB architecture. Descriptions of these components are available below the figure.
CORBA ORB Architecture
Object -- This
is a CORBA programming entity that consists of an identity, an interface,
and an implementation, which is known as a Servant.
Servant -- This
is an implementation programming language entity that defines the operations
that support a CORBA IDL interface. Servants can be written in a
variety of languages, including C, C++, Java, Smalltalk, and Ada.
Client -- This is the program entity that invokes
an operation on an object implementation. Accessing the services of a remote
object should be transparent to the caller. Ideally, it should be
as simple as calling a method on an object, i.e., obj->op(args). The remaining
components in the figure help to support this level of transparency.
Object Request Broker
(ORB) -- The ORB provides a mechanism for transparently
communicating client requests to target object implementations. The ORB
simplifies distributed programming by decoupling the client from the details
of the method invocations. This makes client requests appear to be local
procedure calls. When a client invokes an operation, the ORB is responsible
for finding the object implementation, transparently activating it if necessary,
delivering the request to the object, and returning any response to the
caller.
ORB Interface --
An
ORB is a logical entity that may be implemented in various ways (such as
one or more processes or a set of libraries). To decouple applications
from implementation details, the CORBA specification defines an abstract
interface for an ORB. This interface provides various helper functions
such as converting object references to strings and vice versa, and creating
argument lists for requests made through the dynamic invocation interface
described below.
CORBA IDL stubs
and skeletons -- CORBA IDL stubs and skeletons serve
as the ``glue'' between the client and server applications, respectively,
and the ORB. The transformation between CORBA IDL definitions and the target
programming language is automated by a CORBA IDL compiler. The use of a
compiler reduces the potential for inconsistencies between
client stubs and server skeletons and increases opportunities for automated
compiler optimizations.
Dynamic Invocation
Interface (DII) -- This interface allows a client
to directly access the underlying request mechanisms provided by an ORB.
Applications use the DII to dynamically issue requests to objects
without requiring IDL interface-specific stubs to be linked in. Unlike
IDL stubs (which only allow RPC-style requests), the DII also allows
clients to make non-blocking deferred synchronous (separate send and receive
operations) and oneway (send-only) calls.
Dynamic Skeleton
Interface (DSI) -- This is the server side's analogue
to the client side's DII. The DSI allows an ORB to deliver requests to
an object implementation that does not have compile-time knowledge
of the type of the object it is implementing. The client making the request
has no idea whether the implementation is using the type-specific
IDL skeletons or is using the dynamic skeletons.
Object Adapter --
This
assists the ORB with delivering requests to the object and with activating
the object. More importantly, an object adapter associates
object implementations with the ORB. Object adapters can be specialized
to provide support for certain object implementation styles (such as OODB
object adapters for persistence and library object adapters
for non-remote objects).
Glue between ORB and CORBA object implementations
Object Adapter
Use of IDL -Interface definiton language in CORBA. IDL
is a universal notation for software interfaces and is an ISO standard.It
defines the interface between client code and object implementation. It
is the basis for every specification adopted by OMG. And is languaged independent.Also
supports multiple language bindings : C, C++, Java, Ada. IDL produces
stubs, skeletons and classes.IDL is used for specifying interfaces.
An Ideal interface looks like this:-
interface Airline Reservation {
type def unsigned long confnumber;
enum seatkind (wind,aisle,mid };
exception seatnotavailable { };
exception badconfnumber { };
confnumber makereservation (
in string passengername;
inout seatkind seatkind;
out string seat-assignment;
raises(seatnotavailable, badfrequentflyernumber);
context("Ticket Agent", "Agency");
}
IDL Complier
Please follow this link for FAQs in CORBA:-
http://www.omg.org/gettingstarted/corbafaq.htm#TotallyNew
Other Mechanisms for Distributed Objects:-
1.RPC (Remote Procedure call ) -1970s
2.CORBA -DOC -Inroduced OO in distributed system -1980s
3.COM/DCOM/COM+ (not very good in heterogeneous environment)
-1990s
4.Java RMI/JRMP Remote Method Invocation
5. RMI/IIOP
6.SOAP/XML/HTTP/WSDL/UDDI/eBXML
7.J2EE , .NET.
-----------------------------------------------------