Sunday, June 30, 2013
ABSTRACT
CORBA, which stands for
Common Object Request Broker Architecture, is an industry standard developed by
the OMG to aid in distributed objects programming. CORBA is just a specification
for creating and using distributed objects; CORBA is not a
programming language. The CORBA architecture
is based on the object model. This model is derived from the abstract core object model defined by the OMG.
The model is abstract in the sense that it is not directly realized by any
particular technology; this allows applications to be built in a standard
manner using basic building blocks such
as objects. Therefore, a CORBA-based system is a collection of objects that
isolates the requestors of services (clients) from the providers of services (servers)
by a well-defined encapsulating interface. CORBA works behind the scenes
in the computer rooms of many of the world's largest websites; ones that you
probably use every day
It is important to note that CORBA objects
differ from typical programming objects in three ways:
·
CORBA objects can run on any platform.
·
CORBA objects can be located anywhere on the network.
·
CORBA objects can be written in any language that has IDL mapping.
CORBA is composed of five
major components: ORB, IDL, dynamic invocation interface (DII), interface
repositories (IR), and object adapters (OA).
INTRODUCTION
The
Common Object Request Broker Architecture (CORBA) is an emerging open
distributed object-computing infrastructure being standardized by the Object
Management Group (OMG). The Common Object Request Broker Architecture
(CORBA) is an object-oriented infrastructure for distributed computing. CORBA
enables software interoperability across multiple programming languages and
platforms.
CORBA CONCEPTS
CORBA’S theoretical underpinnings are
based on three important
concepts
·
Object-Oriented model
·
Open distributed
computing environments
·
Component integration and
reuse
The ORB is the communication infrastructure through which all objects communicate.
The object request broker
The CORBA specification must have
software to implement it. The software that implements the CORBA specification
is called the ORB. The ORB, which is the heart of CORBA, is responsible for all
the mechanisms required to perform these tasks:
·
Find the object implementation for the request.
·
Prepare the object implementation to receive the request.
·
Communicate the data making up the request.
CORBA defines a set of
communication protocols between objects. Calls will be made using the IIOP or
the GIOP protocols on top of the existing network layers.
OBJECT MANAGEMENT ARCHITECTUR:
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
application domain, they might become candidates for future OMG
standardization.
CORBA facilities are higher level
services. Examples include compound presentation and interchange facility and
the system management
facility. The focus of CORBA facilities is on application level
interoperability rather than
ORB-ORB interoperability. CORBA
facilities represent interfaces
that are common to multiple domains.
HORIZONTAL CORBA FACILITIES
The Horizontal CORBA facilities
sit between the CORBA services and Application Objects. Horizontal CORBA
facilities include user interface, information management, systems management,
and task Management. Unlike the Domain CORBA facilities, these facilities are
potentially useful across business domains. There are only four horizontal
CORBA facilities: The Printing Facility, the Secure Time Facility, the
Internationalization Facility, and the Mobile Agent Facility. This is the only
category in the OMA that lacks a Task Force of its own at the OMG.
The
following are the examples of Horizontal CORBA facilities:
Distributed
Document Component Facility.
DDCF
is the combination of
Compound Presentation Facility
and Compound Interchange
Facility. Compound Document is a
collection of information from a variety
of application sources.
Compound Interchange facility
is a set of
interfaces that provides for
interoperability among compound document
parts. Each Compound document
part is an instance of an object
that contains state
information. The embedded document can
be manipulated by
compound document application. Each of
these applications can
exchange information with
other kinds of
applications .
Compound Interchange Facility includes interoperability definitions that support the
storage of information in a
multiple format, which is
part of the
proposal. Compound interchange
also supports drag and drop ,another form
of interchange in
which end user selects
data by using
the mouse on
the screen and
interactively drags the information
by depressing the mouse
button between different
compound document parts
displayed on the screen. When the end user
releases the mouse
button ,the compound is
deposited in the destination
part.
Compound Linking .
Compound document
can store application data embedded
in their file presentation
.Embedding occurs when
information is stored with the
compound document file linking
occurs when the application data
is stored externally
to the compound document
file. Active linking allows a
single version of information
to be updated and
modified dynamically in several compound documents.
The final
form of compound interchange involves
linking of parts. In linking, the interchange occurs indirectly by tying compound documents or
parts of document
together. This creates an active linkage am9ong parts so that when one part
is updated ,the linked
part in other document
can be automatically
updated as well.
An open doc can contain information from
several applications .The overall
container for the document manages the file representation for all the
embedded compound parts.
Figure
is a visual representation of an
Open Doc compound document. The
container manages the desktop environment, including resources such as menus
and toolbars. The container also
arbitrates the allocation
of screen space and
resource in the compound document. When a compound
document is the current part of the
desktop ,the part receives
events generated by the menus
for the current window. These
menus comprise some general purpose capabilities from the root
part, such as the document and
edit windows as well as
some part specific menus, which
vary based on the currently active part.
Open Doc
allows flexible negotiation and
allocation of screen real estate in the compound document as
shown in figure. The boundaries
of an embedded part do not
have to be rectangular. parts can be of
any arbitrary shap4e,and
compound document part does
not need be
limited to a single page.
VERTICAL CORBA FACILITIES
Vertical (or Domain) CORBA facilities
are domain-based and provide functionality
for a specific domain such as telecommunications, electronic commerce,
or health care. The following are the examples of vertical CORBA facilities:
Business Object
Framework and Common Business Objects
The Business object Framework Facility is a
unifying set of interfaces for access to
the capabilities of all
lower level facilities
and services and includes comprehensive support necessary for
business applications that need
the capabilities of the
lower level services .on top of this
framework ,a number of
generic business objects and
vertical market business objects
are built.
The fig
shows the enabling services
and interface ,including CORBA,CORBA
services, and CORBA facilities, as the bottom
layer. The business object
framework abstracts and unifies access to
these lower level interfaces. The business object framework provides a uniform
abstraction for business
software that manages the complexity of the
lower level services.
Business objects represent the first
area of domain specialization to
the OMG standards. There was
much discussion at the
OMG prior to
initiation of this because
of several reasons. One
reason was that
business objects make up
the first domain
area and therefore are
ground breaking. Another
concern was that business
object framework layer
over existing facilities and services ,including basic
CORBA interfaces.
The
Meta–Object Facility extends the meta-data
definitions supported by
OMG Standards into
the areas of
interface semantics,
constraints and related
areas. Prior to meta-objects ,the
definitions of OMG interface was limited to
the syntax of Cobra’s
IDL. Perhaps, IDL captures
only a subset of information in object
oriented analysis and design
models. IDL does not
capture information about other
relationships among object
classes other than inheritance.
The above
figure illustrates the use
of meta-Object facility.
One of the
most advanced areas of vertical-market interests is
in financial services. The financial
domain task force has
created the CORBA
financial architecture to
identify the facilities
to be adopted in this
arena.
` The above
architecture identifies categories
of interfaces that
will be the
subject of future
OMG adoptions processes .CORBA financials define
horizontal and vertical specializations within the
financial services market.
LEAVERAGING
THE OMG PROCESS
OMG helps
hand in hand for
the growth of software
markets. A fundamental principle
of the OMG is the inherent assumption that
vendors in the OMG agree to
cooperate on their software interfaces and compete and implementations.
Exploiting a Predictable Process
The
OMG process is predictable.
It typically takes from 12 to 18 months from initiating an RFP to the completion of the technology adoption process.
The OMG has delivered significant technologies using this process.
Because the OMG
process is predictable, it
is feasible to align future
technology plans to their future
and current adoption activities.
The
architecture documents identify
the services and facilities
for adoption. Each facility is defined by a template
that defines the scope of the
facility and the basic requirement.
A companion planning goes with each
architecture ,called a Roadmap. The Roadmaps provide timing information that
allows one to predict the approximate availability of planned
OMG specifications.
Application Profiles
When application
developers build on the more primitive interfaces, they need to write
substantial software to derive benefits
from technology .Developers need to
define profiles that detail conventions
for how the technology is used ,to
assure that the technology delivers the appropriate interoperability and
portability benefits.
In the profiles ,
these users and integrators define the appropriate subset of the
technology and the conventions for how the technology is used .
Request for
information Process
The RFI is a general
request to all members and nonmembers
of the OMG to submit any kind of
input that is relevant to the OMG’s
process .The input RFI can include
end-user requirements, descriptions of technologies and products,
architectural input.
As the OMG
process produces specifications responsively compared to ISO and others ,it is
able to anticipate market needs and deliver products in a timely manner. The
RFI is at the OMG process is an important step
in initiating the coordination of
industry .Once the RFI process is complete ,it is the responsibility of
the OMG members in the task force to
define the architecture and begin the
adoption process through RFP’s and
RFC’s.
Limitations :
ü
IDL
is a "least-common denominator" language. It does not fully exploit
the capabilities of programming languages to which it is mapped, especially
where the definition of abstract types is concerned.
ü The price of ORB’s varies
greatly, from a few hundred to several thousand dollars.
ü Training is essential for
the already experienced programmer.
ü CORBA specifies only a
minimal range of security mechanisms; more ambitious and comprehensive
mechanisms have not yet been adopted by the OMG
CONCLUSION
The OMG's CORBA organizes standards for
distributed object systems and today
dominates the object landscape. CORBA is not a programming language;
it’s a specification for creating and using distributed objects. The "vision" behind CORBA
is that distributed systems are conceived and implemented as distributed
objects. CORBA’s interoperability ,
remote invocation have made it most popular.
Recent advances in distributed
computing have altered the landscape CORBA occupies. Specifically, the recent
emergence of mobile objects via Java, and the connection of Java with "web
browser" technologies has muddied the waters concerning the role of CORBA
in future distributed systems. CORBA have the advantage of flexibility in response to changes in market
conditions and technology advances
