InformationWeek

September 14, 1998

Corba Takes Off

continued...page 3 of 3

Illustration by Matt Foster

October marks the seventh anniversary of Corba, and the OMG early next year will roll out Corba 3.0. Given the maturity of the technology, Corba proponents find it hard to excuse Corba shortcomings as the problems of immaturity.

Expertise Required
Corba isn't for the casual development shop. While the Corba interface definition language, which specifies the actions a Corba component can take, looks disarmingly simple--a declarative, macro-like language with only a handful of commands--it represents only the starting point. Developers then have to write the C++ or Java client and server code, referred to as skeletons or stubs, that implements the IDL for the front and back applications. For this, the organization needs to buy or patiently cultivate the object-oriented programming skills that are in such great demand today.

Corba's distributed object services have not lived up to user expectations. The Corba event service, for example, is a critical service for applications that are intended to automate a complete business process. The event service lets Corba objects dynamically register their interest in specific events. For example, when a loan origination object is invoked, the credit-checking object might want to know, so it can begin the mandatory credit check.

"We tried to use the event service, but there were some problems and we ended up writing our own," says Sundar Swaminathan, a senior IT manager at the Sabre Group. Swaminathan's team is about to deploy a real-time, cargo logistics management application. It uses Corba as the middle tier communications middleware, which eliminated the need for the developers to write low-level communications code. Eventually, Swaminathan intends to swap its homegrown event service for the Corba event service.

Sabre Group's application runs on a Windows NT client and server with an Oracle database. It seems like a natural for Microsoft's COM approach to component interoperability, but the developers opted for Corba instead, despite its weaknesses. "We wanted to be sure that Windows clients could talk to Unix servers if it got to the point where we needed real server horsepower for scalability," Swaminathan says. COM lacks the cross-platform interoperability the developers wanted.

Protocol Pushes Corba Forward

The maturation of the Internet Inter-ORB Protocol promises to finally bring Corba into the mainstream of Web application development. IIOP is the TCP/IP protocol with some Corba-defined message exchanges included.

It forms the underlying communication protocol that provides common backbone communications for interoperability between components.

"IIOP has given Corba a tremendous boost," says Sally Cusack of SPG Analyst Services. When and if it's fully implemented by the object request broker vendors, IIOP should eliminate the problem of interoperability and portability between ORBs.

Corba vendors are betting that IIOP interoperability for Corba and the implementation of a diverse set of distributed object services will usher in Corba's golden age. But even its proponents concede that Corba is a tool for expert programmers to use in generating complex multitier systems.

--Alan Radding

Software companies have gravitated to Corba as a way to minimize coding and emerge as a leader in a hot technology space, says Bob Bickel, senior VP at Bluestone Software Inc., an application server vendor. For software vendors, Corba eliminates some low-level coding and solves some nagging cross-platform interoperability problems as well as generally expediting component-based development.

Still, some of these early adopters are approaching Corba with caution. For example, DBS Systems Inc., a provider of high-volume transaction processing systems to the telecom industry, is building its next generation systems using Dynasty and Corba as the component middleware. But it's hedging its bets. "We will have 12 to 15 major components and a Corba backbone if the customer wants it," says William Guinn, DBS's chief technical director. However, the product will be middleware neutral--supporting Corba, Tuxedo, or TCP/IP sockets, Bickel says. Although inherently different, each of these technologies can be used to build multitier, distributed enterprise applications.

DBS can be flexible because it is building its components in Dynasty. "With Dynasty, we can choose which middleware we want to support and just push a button. No matter what middleware wins, we win," Guinn says. "We looked at Corba alone, and it was just too much work," he adds.

The DBS customers who opt for the Corba version will be those who have to interface to other vendors' products. "These customers want a lot of interoperability, but it comes at a cost," Guinn says. The extra cost results mainly from the amount of server resources Corba consumes.

To-Do List
The list of things Corba still needs is long: universally implemented enterprise services, such as event and transaction services; tools to provide higher levels of abstraction for ease of development; and improved portability and interoperability.

But for organizations that have waited this long for a useful Corba, a few more years won't matter as long as they can start building real business applications with Corba today, which is exactly what a growing number of organizations are doing. It isn't easy or foolproof, but it's the best available option.