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 , 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 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.

height="125" align="left">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

"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 . 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.

...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.