CORBA

The computing paradigm has been
evolving to encompass a wide variety of software and hardware in a plethora of ‘layers.’
Which makes achieving interoperability a nightmare for software professionals. Thankfully,
they can wave the CORBA wand and say: CORBAcadabra!

As companies the world over vie
with each other to build enter- prise computing infrastructures that work across ‘n’
number of hardware and software platforms, an ‘old’ new gluing force is emerging. It is
called CORBA, the Common Object Request Broker Architecture from the Object Management
Group (OMG). Old, because it was in 1991 that the first version of this software
specification emerged-a specification that enables applications to communicate with one
another, no matter on which hardware system they are located or who has designed them.
New, because it is only recently that the intended interoperability promise of CORBA is
being delivered in real-life environments.

“The age of infrastructure reinvention is coming to an end,” says Thomas J
Mowbray, one-time member of the OMG and The Father of CORBA, as he is better known.
Mowbray, who now heads the Component Management Group, a US-based non-profit organization
promoting CORBA, identifies three such “infrastructures”-Java RMI, CORBA and
COM. It is these three specifications that are today driving the corporates’ move toward
distributed computing.

For long the computing paradigm has evolved-and is continuing to evolve-into a large,
unwieldy number of operating systems, hardware platforms and applications. Things were
proprietary but comfortable in the mainframe days. They still are largely
proprietary-being driven by vendors such as Microsoft, IBM and others-but no longer
comfortable. Companies are still struggling to find ways to make their disparate computing
platforms ‘talk’ to each other-but they are being obfuscated by the technology, which
keeps on pulling a fast one on them! The three technologies available to them for
synergizing the wide variety of platforms-remote procedure calls, messaging middleware and
transaction processing monitors (together, popularly known as middleware)-have had a
common drawback. The middleware layer typically is proprietary, being defined and
maintained by the vendors at their will.

This model has worked well till a couple of years ago. And then, the internet began to
change everything. According to a Forrester Research forecast, by the year 2001 about 95%
of all software applications will be designed specifically for the net. So it becomes
imperative for the vendors, and thence for the application developers, to take an internet
view of things. Which immediately puts the focus on technologies like OMG’s CORBA, Sun
Microsystem’s Java and Microsoft’s COM/DCOM (Component Object Model/Distributed Component
Object Model). The trio is progressing fast to take the ‘proprietary’ peel off most
software, by hiding the different code under an abstract layer. Such a layer can act as a
traffic cop sending off the cars, trucks and bicycles of the software criss-cross to their
appropriate travel routes.

And then, there is the beauty of the concept of reusable components, parts of a main
program which can be invoked to interface with other components within the same system or
across a network to perform computing tasks. That not only saves the programmers’ time
otherwise spent in writing repetitive code but saves the existing investments in
technology. This may be good news for the users; however, it can spell bad omen for
certain vendors. One reason for the latter could be that the vendor might loosen its
hammerlock on the large base of customers-to which it keeps on selling souped up versions
of basically the same product. According to Dr Richard Soley, Chairman and CEO of OMG,
“Although Microsoft is an OMG member, and has been invited many times to propose COM
into the open, neutral OMG technology adoption process, they have never chosen to do
so.”

With about 150 million Windows-based systems using COM installed across the world, why
should they? In fact, Microsoft maintains (as is apparent from a document on its web site)
that “to take full advantage of a given platform [read Windows], developers have to
sacrifice cross-ORB interoperability and cross-ORB portability.” CORBA, on the other
hand, accommodates the intersection of all inter-ORB protocols (i.e. interoperability
across different object request brokers). What’s more, CORBA’s web site, www.corba.org,
has a listing of hundreds of vendors committed to CORBA, including such platform-savvy
stalwarts as Sun Microsystems, Silicon Graphics and Big Blue itself. Besides, the ‘Success
Stories’ on the site cover verticals ranging from advertising to healthcare to telcom.

Across the ORB
But then the question arises:
How do you dovetail the components developed using the three infrastructures? For
companies interested in and deploying non-Windows setups, the answer is ‘bridges,’ which
are software, mainly from third-party vendors, that try to bring the triumvirate into
unison. Unfortunately, thus far they provide “only limited communication between
these component types,” according to the Technology Forecast: 1998 report by
consulting major PricewaterhouseCoopers. The report, however, says that “the notable
exception to this rule is Object Bridge from Visual Edge Software, which provides true
interoperability between CORBA and COM/DCOM. As regards Java and CORBA, according to Dr
Soley, “CORBA is now bundled in the Java Developers Kit, and Java depends on CORBA
for enterprise-wide connectivity, especially in heterogeneous, multi-lingual
environments.” And with the componentware market growing over 40% last year (IDC data
for 1998), the situation is only going to improve over the next few years.

Another healthy indication of the ongoing CORBA movement is the large number of CORBA
books being sold every year. Says Dr Mowbray, “Last year we [CMG] alone sold over
20,000 books on CORBA.” Although neither he nor Dr Soley would give an estimate as to
how many programmers are working on CORBA, the success of this next big wave of computing
can be gauged from the fact that from the eight companies that formed OMG in 1989, it has
grown to become a gigantic consortium of over 800 members. And this concourse is building
up enough momentum to establish CORBA as the ‘Middleware that’s Everywhere’ through
propagating its various worldwide standard specifications: CORBA/IIOP, Object Services,
Internet Facilities and Domain Interface specifications. In all probability, the Middle
Route could prove to be an enterprise’s path to IT Nirvana. Just chant the CORBA mantra.

SANJAY GUPTA,
in New Delhi.

The figure illustrates the primary components in the OMG
Reference Model architecture. Descriptions of these components are as follows:
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 life-cycle 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 toward 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 toward specific application domains. For example, one
of the first OMG REPs issued for Domain Interfaces is for Product Data Management (PDM)
Enablers for the manufacturing domain.

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.

Courtesy: CMG

The figure illustrates the primary
components in the CORBA ORB architecture. Descriptions of these components are as follows:
OBJECT IMPLEMENTATION: This defines operations that implement a CORBA IDL
interface. Object implementations 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: 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.

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: The DII 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 one-way
(send-only) calls.

DYNAMIC SKELETON INTERFACE: DSI is the server side’s analog 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 the dynamic skeletons.

OBJECT ADAPTER: This assist 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).

Courtesy: CMG

A Tale Of Two ORBs

CORBA’s only real competition is DCOM. RMI is currently a niche ORB; this will change when
it runs on IIOP. Sockets is just a low-level protocol. And, HTTP/CGI just doesn’t cut it.
So, it’s CORBA versus DCOM. CORBA has won the first round. But the battle will continue
for the remainder of the century.
From past wars, we have learned-the hard way-never to underestimate Microsoft. We also
learned that superior technology alone doesn’t always win-especially in the face of a
superior marketing machine. So why does the CORBA/Java camp stand a better chance against
Microsoft where many others have failed?

In the last year [1997], the CORBA camp was joined by fast-moving newcomers. This new
guard looks at CORBA as a way to build products, not just standards. The new guard
includes some agile pure-software companies like Netscape, Oracle, JavaSoft, BEA and
NetDynamics. They join long-standing CORBA players like IBM, Novell, Borland/Visigenic,
SunSoft, Iona, Tandem and Expersoft. Together, these companies form a formidable bloc.
They have the support of hundreds of other software vendors as well as some major IT
shops.

This new CORBA coalition is building around a killer app called the Object Web. The Web
transforms CORBA from a set of standards to a set of products that fulfill an
intergalactic need. CORBA becomes a powerful architecture that ties together products that
form the Object Web. JavaBeans and Enterprise JavaBeans provide the component foundation
and tool support. This is a very potent combination of intergalactic technologies. The
CORBA/Java camp has what it takes to give Microsoft a run for their money.

Excerpted from the book, Client/Server Programming with Java and CORBA. Courtesy: John
Wiley & Sons

“One of the major reasons
why CORBA is so successful today was the lack of delivery on the Distributed Component
Object Model of Microsoft.”

-Dr Thomas J Mowbray,
Chairman, Component Management Group.

The Father of CORBA, as he is fondly
known, Dr Mowbray eats, sleeps
and drinks CORBA, the Common Object Request Broker Architecture specification for enabling
interoperability between software components. What that essentially means is effective
communication between the multitude of software and hardware platforms in use today. His
subject may sound drab to some, but his work heralds the next wave of computing-Component
Orientation-that will take the old with the new and help create the applications
infrastructure of the next century. A PhD in Computer Science from the University of
Southern California, Dr Mowbray has written a number of books on CORBA. Apart from
chairing the Component Management Group, a non-profit organization promoting the use of
CORBA and componentware, he is Chief Scientist at Blueprint Technologies Inc, a
Virginia-based software product and consulting company focusing on reusable software
frameworks. Dr Mowbray was recently in the capital to speak at a seminar on CORBA and for
announcing a partnership of CMG with the Software Technology Parks of India. Speaking to
Sanjay Gupta of DATAQUEST in his first, extensive interview in the country, he fielded
questions on CORBA, the object-oriented movement and, yes, Microsoft-some of them rather
reticently. Excerpts:

How is a component-oriented approach different from an object-oriented one?
The object-oriented approach is based on merging the data process models and that is
usually done in terms of the programming language. The result of the object-oriented
approach is to focus on small-scale modeling issues, first for development of systems
which were generally useful 10 years ago-which do not represent the kind of systems we are
developing today. Component orientation includes several different aspects which are not
directly tied to programming-language issues [unlike in object orientation]. Within the
scope of component orientation we have the idea of a deployable software unit which is
specified as an architectural component…

…it’s like a building block?
Yes, so you need a technology for specifying architecture as one of the requirements of a
component. The Component Management Group is promoting the use of open distributed
processing, which is a standard from the ISO as also a standard from the ITU represented
by the X900 series. So there is a very well thought out way of specifying software
component interfaces. Component orientation also includes the use of patterns-software
patterns, design patterns…we don’t have to reinvent designs in other kinds of solutions
from scratch.

How are OMG and CMG related?
The OMG is responsible for infrastructure standards related to CORBA. They’ve been
successful in adopting a standard which has been commercialized which is widely available.
They have achieved their mission in that respect. CMG is interested in higher levels of
interoperability, particularly between application-level components in vertical domains
and across vertical domains. At CMG we believe that an architecture-based approach is the
right way to define the technology and create complete solutions for vertical markets. In
this respect we are proceeding to define standards in finance and other areas which will
be relevant to national organizations. We have participated in some OMG standardization to
achieve that objective.

How does the CORBA movement go
with similar attempts of specific vendors?
One of the major reasons why CORBA is so successful today was the lack of delivery on the
Distributed Component Object Model of Microsoft. Microsoft’s original intention with DCOM
was to develop a multimedia technology for the internet. They failed on both counts. DCOM
today has inadequate security for internet applications. This weakness is why we’ve
recognized there are so lax system management capabilities along with other Microsoft
platform features that make it less applicable to large-scale system integration and
management than our technologies. CORBA is at the right place at the right time with a
mature solution which is stable, and which provides security and the capability to manage
systems.

How do these three things fit
into the move toward language- and OS-independent software-Java, CORBA and COM?
The three major infrastructures are Java RMI (remote method invocation), CORBA and
COM. All three infrastructures have to find interoperability relationships among each
other-including the COM-CORBA interworking and Sun Microsystems’ adoption of the CORBA
IIOP (inter-object resource broker communication protocol) as an extension to RMI
technology. All together, these infrastructures can interoperate and the vendors are
moving them closer and closer together as time progresses. We envision a future
environment where all three infrastructures will coexist and CORBA providing the mechanism
for interworking across the entire range of programming languages and operating platforms.

But the large installed base of
Windows would prompt more and more programmers to adopt COM instead of CORBA, as the
former is said to be more compatible with the desktop operating system…
…Our members can apply technologies in many deployment environments including COM-based
and Unix-based environments, applying the appropriate technology at present in each
situation. We’ve no requirement for mandating the use of CORBA if the use of COM is
appropriate. We encourage the use of appropriate technologies in each case.

CORBA has been under development
for the past 10 years. Why is this technology taking too long and when will it mature?
CORBA is an enterprise technology used by more than 50% of Fortune 1000 companies. And
these companies predict that they will increase their utilization of CORBA perhaps by up
to the 90% level in their deployed systems in the future.

Of your 20,000 or so members how
many are from India?
Component Management Group India has registered over 7,000 members today. The growth has
been dramatic and is continuing as the organization is beginning to disseminate its
message through the ‘Applying Patterns in CORBA’ seminar in the component category

Could you name some of your
members from India?
Oh yes. For example, Vipin Tyagi, President of Network Programs India; Pawan Nagpal,
President of NEPL; and Dr V Thyagrajan, Head of Product Realization Group at LG Soft.
These are people who are deeply involved in the CMG’s advisory board. Also, we have in
India an additional 200 CEO-level members and we’ll be talking to them in a CEO conclave
in Delhi and Bangalore.

A white paper on the subject
says that “unfortunately, there are no fully compliant public domain implementations
of CORBA.” Now, what does that mean and why is it “unfortunate?”
The public domain implementations of CORBA are excellent resources for learning purposes.
There are many different public domain CORBA implementations available on the Internet.
I’ve found that these implementations have a level of standards-compliance which is
comparable to many of the commercial products.

It is said that he who controls
the interface to the operating system controls the future. Your comments?
I think the age of infrastructure reinvention is coming to an end. As the application
development community starts to create mission-critical applications on great
infrastructure, we will demand that unnecessary innovation and instability of operating
systems interfaces change into a new market in which those types of design issues are
stable along with relatively defect-free technologies and provide operating systems and
distributing computing capabilities.

You said in your presentation
that vendors are making money by obsoleting their own technologies. How will CORBA change
that, if at all?
CORBA changes the obsolescence model by providing a boundary between application
software and ‘vendor’ software through the interface definition language. IDL is a stable
specification that is resistant to vendor-specific technology changes.

A white paper on the subject
says that "unfortunately, there are no fully compliant public domain implementations
of CORBA." Now, what does that mean and why is it "unfortunate?"
The public domain implementations of CORBA are excellent resources for learning purposes.
There are many different public domain CORBA implementations available on the Internet.
I’ve found that these implementations have a level of standards-compliance which is
comparable to many of the commercial products.

Related Posts

Leave a Reply Cancel reply