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.