More CORBA Articles

Record: 32

The most elegant component model in the world is useless without products to support it. By the same token, the most well-designed architecture is hamstrung without powerful yet flexible and usable tools with which to implement realworld solutions. These conundrums are influencing the future of the three prevailing models for using and managing distributed objects in a network: CORBA, DCOM and Enterprise JavaBeans.

Although the Object Management Group's CORBA (Common Object Request Broker Architecture) has existed since 1990 and many products support it on some level, it has long been criticized as being too low-level for anyone but highly specialized engineers to use. Microsoft Corp.'s model, which includes COM (Component Object Model), DCOM (Distributed COM) and the upcoming COM+, has a huge installed base and is more mature than Sun's nascent EJB; but while COM and DCOM have a fairly healthy third-party market for tools, they still primarily require users to run Microsoft tools on Microsoft platforms. Meanwhile, despite the fact that relatively few development tools are currently available for Sun's EJB, it has generated strong interest both from vendors and the market. If that interest turns into robust tool sets and truly interoperable, cross-platform products from multiple vendors, it will become a major force to reckon with.

Customers understand the message of object orientation and its benefits, as well as the need for a distributed object technology, says Roseanna Marchetti, senior product marketing manager at Netscape Communications Corp., so vendors don't need to sell the benefits of components. Rather, they must sell complete products and development tools that are easy to implement, use and reuse across whatever network architecture, infrastructure and OS their clients use. Here, CORBA faces its biggest hurdle. The technology proved too difficult to use in many instances, and too complex and expensive to implement and maintain. Although parts of its core technologies undoubtedly will remain vital to many distributed object deployments, and many products will continue to support CORBA in some form, it has likely hit its high-water mark as a separate, integrated model.

By comparison,'Microsoft provided a relatively easy-to-use alternative with DCOM and Microsoft Transaction Server (MTS), and has quickly gained a large share of the market, if not of the revenue; after all, Microsoft delivers the service free, as a part of the Windows NT OS. It remains to be seen if EJB, or a merger of EJB and CORBA, can overcome Microsoft's lead.

CORBA; Merge Ahead!

CORBA is in an interesting, but not necessarily good, place right now. On the one hand, it has a large, committed installed base and a diverse group of vendors that participate in the Object Management Group (OMG). CORBA has been available for much longer than DOOM or EJB (its original specification was released in 1990 and commercial products began appearing in 1992), and many products on the market support it. CORBA objects can be written in multiple languages, including Java, C, C++, SmallTalk, COBOL and Ada. The OMG has just announced version 3.0 of the CORBA specification, which is expected to be released in final form by midyear. This version will include some important additions, such as a new, expanded distributed component model, a scripting language and the ability to pass CORBA/IIOP (Internet Inter-ORB Protocol) through a firewall. If a client supports IIOP connections directly, new interfaces will allow a CORBA 3-compliant firewall proxy to be used on the provider's firewall proxy host, with bidirectional filtering and proxy services. If the client doesn't support IIOP, the fallback is tunneling the IIOP requests through HTTP.

On the other hand, it's been nearly impossible to create connectivity among different vendors' products. Implementing anything substantial has required a great deal of low-level coding by highly skilled staff. It is possible to create large-scale distributed systems using CORBA across heterogeneous hosts and OSes, but the investment in time and talent is huge. Many of the CORBA 3.0 specification's services are already functionally part of the DOOM or EJB specs, and while many vendors support CORBA, enthusiasm for it has been been largely eclipsed by EJB. There's no guarantee that the full 3.0 spec will be widely implemented; it's likely a case of too little, too late. We believe that at least for new system development, EJB (with essential elements of CORBA) and DOOM will soon be the two major distributed object standards in widespread use.

IONA Corp., one of the biggest CORBA boosters, recently purchased an EJB development company, and Netscape, though it supports CORBA clients, does not offer a CORBA server, per se. Rather, according to Komal Parikh, a group project manager at Netscape, the company is looking to Sun to help solidify the relationship between CORBA and EJB. Sun is unlikely to offer pure CORBA services; rather, it's pushing for greater integration between EJB and CORBA.

That's a refrain being heard throughout the industry--that CORBA and EJB are headed for a de facto merger, with elements of CORBA absorbed into the EJB specification. This will be a very fruitful marriage, if Sun and the OMG can avoid a bifurcation. The CORBA 3.0 specification includes some features designed to enhance CORBA-Java interoperability, especially support for Objects-by-Value. The extension of CORBA support to value objects is essential to enable developers to generate CORBA IDL (Interface Definition Language) files from Java-class files, and therefore to allow access to Java applications remotely under CORBA via RMI (Remote Method Invocation), using IIOP as the wire protocol (as Java is extended to make use of HOP).

The CORBA specification's vagueness has always been its major problem, as it allowed vendors to come up with widely varying, incompatible products with limited or no service-level interoperability. Microsoft plays up this weakness in its marketing, saying DCOM presents a more consistent specification and environment than CORBA. Sun is trying to keep a close eye on EJB's cross-vendor interoperability; while EJB is portable, it remains to be seen whether Sun will be able to avoid some of CORBA's intervendor confusion and difficulties. Most enterprise deployments of CORBA are designed primarily to tie together diverse data sources, and most can fairly easily standardize on one vendor. However, that's likely to change as components become commoditized and 'plug and play' becomes a larger issue for IT shops. To do a better job than OMG at cross-vendor compatibility, Sun will need a tight spec, a complete reference implementation and a strong certification process.

CORBA's future as a technology distinct from Java will further dim as many vendors merely assure interoperability with existing "legacy" CORBA assets. However, CORBA/IIOP will almost certainly remain a popular wire protocol for accessing Java components using RMI, and CORBA ORBs will be an essential part of that service; meanwhile, CORBA's IDL and OTS (Object Transaction Service) may well continue to be used, especially in conjunction with Java. CORBA has a loyal base of users in the enterprise, a fair number of success stories and some level of participation from a large number of vendors. Until the advent of EJB, it has been the only standardized cross-platform object model that has had any significant support. However, looking into the future, even shops with a large CORBA investment likely will start to wrapper their existing CORBA code and do new development with either DCOM or EJB. As for much of the remainder of the new CORBA specification, it's doubtful whether many dancers will remain at the CORBA ball.

Microsoft: Poised for COMbat

Microsoft's DCOM has both the advantages and disadvantages of being pushed by a single vendor. There's no "design by consortium," as there is with CORBA, nor even the process of working with "friends and family" that Sun has with EJB. Microsoft can consult with customers, and then implement whatever features and changes it wants. Because DCOM is a part of Windows, Microsoft instantly has hundreds of millions of potential users.

Microsoft has virtually complete control over its specification and implementations, as opposed to either Sun or the OMG. This tends to make DCOM a fairly coherent model in actual use, but also one that's limited to running in Microsoft environments. For instance, one of the most critical pieces of a distributed object model for enterprise use is robust transaction processing. In the DCOM world, that's accomplished via MTS, which runs on NT. Period. On the other hand, eliminating cross-platform interoperability avoids a host of problems.

Microsoft's control of the OS means that, at least on Windows NT servers, OS integration with DCOM is excellent. And in fact, in Windows 2000, COM+, the evolutionary successor to the current COM model, will both add some new services and subsume what had previously been discrete (though bundled) products, such as MTS. Furthermore, the DCOM infrastructure and MTS-COM+ services are distributed at no additional cost over the base OS, unlike products that use CORBA or EJB. David Chappell, an industry analyst and principal at Chappell and Associates, puts it bluntly: "The decision about which component model to use is based on which OS you want to build your server-side business logic. If a Microsoft OS is your choice across the board, use DCOM and MTS. If you don't want to use NT, you can't use MTS and DCOM."

Some NT shops won't find the choice so cut and dried; there will always be reasons to purchase or develop enterprise-level products that use CORBA and/or EJB, such as the need for extremely robust failover and dynamic load-balancing services across LANs and WANs--services that NT by itself either lacks or provides in only a limited capacity. The point about OS choice, however, is an excellent one: DCOM is based upon the assumption that all of a business' new development and business logic will be on NT, probably using MTS. And while Microsoft may be hoping for a future where that's true, most shops still support multiple OSes and platforms, not only for "legacy" data and applications, but for new applications as well, and will continue to do so for the foreseeable future. Microsoft has made a good effort to port COM to various other platforms--namely, Digital Equipment's OpenVMS, IBM Corp.'s MVS, and Unix for Hewlett-Packard Co., Digital, Silicon Graphics and Sun boxes. But this is primarily to ensure access to COM-wrappered "legacy" data sources; there are no plans to port the critical MTS piece to anything but NT, and COM+ is also intended to be a Windows-only offering.

The trade-offs to using DCOM and MTS are familiar ones: You gain a solid, consistent environment, mature development tools, and a distributed component model supported by a huge installed base. On the downside, you lock yourself into a relationship with a single vendor, Microsoft. Despite the company's recent support for "COM on Unix," you can rest assured that support for Unix will always be minimal to induce companies to migrate to Windows-based servers. Microsoft representatives have repeatedly stated that they have no interest in making Unix a stronger platform.

The subject of development tools is laced with pros and cons. Microsoft has spent considerable effort integrating its tool offerings (Visual Studio 6, for example) to make easy use of the COM/DCOM model, and to make it a straightforward proposition to create COM objects in several languages (primarily C++, Java, COBOL and Visual Basic), rather than having to write or wrapper everything in Java with EJB. But that still assumes you're using Microsoft's development tools; you're unlikely to see a Visual Basic IDE from another vendor, for instance, so you definitely hitch your wagon firmly to Microsoft by using its object model. Another double-edged sword is the ease with which COM objects are created. When a developer merely checks a box to create an object or make it transactional, it's easy to lose sight of what's going on under the hood--and what effect that may have on network traffic--and create swiftly written but poorly designed, inefficient systems.

What does the future hold for DCOM? Like Sun and the OMG, Microsoft doesn't want to make radical changes to anything in its object model. Microsoft claims that COM objects built when the specification was released in 1993 will work today. The emphasis, according to Microsoft, will be on stability and performance. Going from COM to COM+ involves folding formerly separate products, such as MTS, into the base OS, and adding some new services, such as dynamic load-balancing, in-memory database, a publish-and-subscribe events service, and a queued-components service. Unless Microsoft changes its mind, however, COM+ will be a reality for the Windows 2000 OS only.

EJB: The Challenger

EJB is the new kid on the block, released as a formal specification in March 1998. Although vendors claimed to support elements of EJB almost immediately, only now are products supporting the full spec appearing. Given the usual development cycle for tools and new products, the next six to 18 months will be crucial to EJB's long-term viability. Sun says six major EJB products are now shipping, with many large enterprise deployments of EJB-based systems expected between fall 1999 and mid-2000. For a year-old technology, that's not bad. However, enterprise systems tend to be built with proven technologies, not bleeding-edge ones, so we anticipate a fairly slow rollout of EJB.

Sun's plans for EJB's future are similar in one sense to Microsoft's plans for DCOM and COM+: They are evolutionary, not revolutionary. Every vendor wants its technology to be viewed as stable, and Sun is no exception. EJB 1.1 is expected at the JavaOne conference in June, but will probably be a tightened spec with some extensions, not a major rewrite. Sun wants to add XML (Extensible Markup Language) to the way EJB is built to help any server understand EJB. It also plans to enhance connectivity to legacy systems, such as IBM's CICS and IMS, without losing portability. Finally, Sun is developing a long-overdue reference implementation of EJB. The beta version of the reference implementation is slated for next quarter, with the final version due in the fourth quarter of this year.

The relationship between EJB and Sun's upcoming Java2 Enterprise Edition has been uncertain, especially whether Java2 would pull resources away from EJB. "Just as the Java Virtual Machine is core to Java2, EJB is core to Java2 Enterprise Edition," says Bill Roth, product line manager at Sun for the Java2 Enterprise Edition platform.

The Java2 Enterprise Edition will include and require many of the other core Java technologies: JNDI (Java Naming and Directory Interface), JDBC (Java Database Connectivity), servelets and Java Server Pages. In addition, CORBA/IIOP is a required part of Java2 (which includes a reference implementation CORBA 2.3-compliant ORB, Java IDL) and forms much of the transport infrastructure for Java2 Enterprise.

"The CORBA technologies represent the plumbing for us, and the real hope for interproduct interoperability," Roth says. Sun's stated goal is to make the underlying CORBA "plumbing" invisible to the Java2 programmer. In fact, while Sun says it is still paying attention to DCOM interoperability via a bridging strategy, Java2 Enterprise is not wire-transport neutral; Sun will use CORBA/IIOP as the communications infrastructure. Interoperability and interobject communication will be through RMI over IIOP, making CORBA essential, but invisible. Sun is planning to take a more public role in the OMG, a further indication of a gradual merging of elements of CORBA and EJB over the coming year.

Because EJB is fundamentally built on the Java language, some of the issues particular to Java have a direct impact on EJB. Primary among these is performance, long Java's Achilles' heel. Sun has released a beta version of the HotSpot compiler, and promises a final version with greatly improved performance. In the meantime, IBM's new version of Visual Age for Java produces native binaries, but that's a short-term solution that contradicts Java's "write once, run anywhere" model. Some heavy-duty, 100 percent Java-written production applications are starting to appear, so clearly the performance problems can be addressed with enough care, and Java has proved itself to have perfectly acceptable performance on the server side for most uses. Also, Sun plans to introduce a new revision to servelets soon, with improved architecture and performance features. Finally, Java's future direction will come into question if Microsoft loses its ongoing court battle with Sun and cuts off its support for Java. That action, while not necessarily fatal, would put a speed bump on the road to Java's, and thus EJB's, widespread acceptance in the enterprise space. On the other hand, it would also provide a rich market for enhancements, such as Sun's Java Plug-In, which allows enterprise developers to configure either Microsoft Internet Explorer or Netscape browsers to use a specific version of Sun's Java Runtime Environment (JRE) instead of the one included with the browser.

Sun is trying to position EJB as "the industry's best hope to deliver true interoperability," Roth says. But the OMG has shown what a difficult challenge such a goal can be. Sun also suggests that EJB can be a simplifying layer on top of CORBA and DCOM. For EJB to succeed, however, it needs to accelerate the availability of third-party development tools, and avoid the pitfalls of specification ambiguity that plagued CORBA, while at the same time not be so dictatorial as to discourage vendors. Sun says it doesn't see EJB as a direct competitor to Microsoft and this is true: EJB by itself is just a piece of paper; it's the supporting products the vendors develop using EJB that will provide competition for Microsoft and DCOM/COM+ based products.

1989
          Object Management Group founded by
          American Airlines, Canon, Data General,
          HP, Philips Telecommunications, Sun
          Microsystems, 3Com and Unisys.

October 1991
          CORBA 1.0 introduced

1992
          First CORBA commercial products appear

February 1992
          CORBA 1.1 introduced, first widely
          published specification

December 1993
          CORBA 1.2 introduced

December 1994
          CORBA 2.0 announced

August 1996
          CORBA 2.0 introduced, including IIOP
          and COM connectivity

August 1994
          CORBA 2.1 introduced, including IIOP
          over SSL

February 1998
          CORBA 2.2 introduced, including
          DCOM connectivity

Fall 1998
          CORBA 3.0 pre-release

Mid-1999 (anticipated)
          CORBA 3.0 to be released, including new
          component model, scripting, asynchronous
          messaging, Java-to-IDL mapping and IIOP
          through firewalls. OMG has more than 750
          members.

COM/DCOM

November 1987
          DDE introduced for Windows 2.03

December 1990
          OLE introduced for Windows 3.0

April 1993
          OLE 2.0 introduced

Spring 1993
          COM 1.0 introduced

Mid-1996
          DCOM introduced

January 1997
          MTS 1.0 introduced

December 1997
          MTS 2.0 released

Q4 1999 (anticipated)
          COM+ to be introduced as Windows 2000 component

Enterprise JavaBeans

January 1996
          Java 1.0 released

February 1997
          Java 1.1, including RMI and JavaBeans, released

March 1998
          Version 1.0 of EJB specification released

Summer 1998
          First EJB 1.0-compliant products available

December 1998
          Java2 (1.2) released

May 1999 (anticipated)
          EJB 1.1 specification to be released

October 1999 (anticipated)
          First major EJB systems to be deployed

CORBA

PROS
* Cross-platform
* Multiple vendor support
* Can develop in multiple languages
* Longevity

CONS
* Highly complex
* Continued cross-vendor interoperability concerns

DCOM

PROS
* Easy-to-use development tools
* Can develop in multiple languages
* Components come from with Windows Large installed base
* Large installed base

CONS
* Still largely Windows-only (with some limited cross-platform
  support)

EBJ

PROS
* Cross-platform
* Relatively easy to use
* Strong third-party vendor interest

CONS
* Sparse third-party tools and products so far

~~~~~~~~

By Richard Hoffman

Send your comments on this article to Richard Hoffman at rhoffman@nwc.com.

 

Choosing to implement a distributed application is a tough decision; choosing the underlying object model is at least as hard. With its huge installed base, Microsoft's DOOM (Distributed Component Object Model) leads the pack. A Microsoft NT shop will pick DOOM because it's so well-integrated into NT. As Microsoft migrates from NT to Windows 2000, DOOM will evolve to COM+ by folding elements, such as Microsoft Transaction Server (MTS), into the operating system and adding a handful of new services. Regardless of these changes, however, choosing DOOM means choosing Windows, and vice versa. What little support Microsoft provides for other operating systems exists to entice organizations to migrate to the Microsoft model.

 

The granddaddy of the three models, CORBA (Common Object Request Broker Architecture), is showing its age. It requires deep, low-level knowledge, and suffers serious compatibility problems from one vendor's product to the next. The scheduled midyear release of CORBA version 3.0 promises several improvements over CORBA 2.0, but many of the new services already exist in Microsoft's DOOM and Sun's Enterprise JavaBeans (EJB).

 

Meanwhile, newcomer EJB (Enterprise JavaBeans), with its promise of strong interoperability, could well be CORBA's savior. With only a handful of third-party applications available, the EJB rollout is destined to be slow. However, elements of CORBA and EJB will likely merge over the coming year. This combination of forces could be both CORBA's and EJB's best hope against Microsoft's DOOM, and your best bet if you seek to avoid getting locked into a Microsoft solution.

 

Links for Additional Information

 

"Muddied Waters: Distributed APIs" (Network Computing, Oct. 15, 1998) www.nwc.com/919/919f1side2.html

 

"Distributed Object (CORBA and OLE/ActiveX" (Network Computing, Network Design Manual) www.nwc.com/netdesign/1005part2.html

 

"EBJ: Reusability in the Enterprise" (Web Tools, March 18, 1999) www.webtools.com/storyjava/TLS19990318S0002

 

"Corba Takes Off" (InformationWeek, Sept. 14, 1998) www.informationweek.com/700/00iucrb.htm

 

"CORBA 3.0 Eases Object Development" (InternetWeek, Sept. 10, 1998) www.internetwk.com/news0998/news091098-1.htm

 

"DCOM: No Objects In Sight" (Information Week, June 29, 1998) www.informationweek.com/689/89uwtb.htm

Section: NETWORK MANAGEMENT

In the late 1980s and early 1990s, the telecommunications industry, as well as just about every other industry that relies on technology, looked to identify and develop a common platform for distributed computing. At the time, there were a number of competitors for the job, but today Common Object Request Broker Architecture (CORBA) is among the victors. Though still maturing to meet telecom's needs, CORBA has found acceptance in a back office environment where tight systems integration is critical to a service provider's ability to be competitive. The technology has its shortcomings, as nearly all do, but CORBA appears to lead the way as more and more general -- as opposed to telecom-specific -- information technology makes its way into the telecommunications industry.

A BIT OF CORBA HISTORY

The late 1980s and early 1990s witnessed the advent of distributed computing technologies such as the distributed computing environment (DCE), remote procedure call (RPC) and the beginnings of message oriented middleware (MOM). Developers chose from a wide variety of nonstandard competing technologies or developed their own, explains Paul Smith, senior vice president of worldwide sales and marketing at DSET Corporation (Bridgewater, N.J.). In May of 1989, 3Com Corporation (Santa Clara, Calif.), American Airlines (Fort Worth, Texas), Canon Inc. (Lake Success, N.Y.), Data General (Westborough, Mass.), Hewlett-Packard (Palo Alto, Calif.), Philips Telecommunications N.V. (Atlanta), Sun Microsystems (Palo Alto, Calif.) and Unisys Corporation (Blue Bell, Penn.) formed the Object Management Group (OMG). The idea behind OMG was to bring these competing technologies together in order to develop "one, agreed-to distributed computing platform so that developers could build applications that would run on anybody's platform and not be relegated to proprietary platforms," says Smith. In 1991, the OMG introduced its CORBA, which today is in its third-release generation.

Smith also explains that originally, telecom's interest in CORBA did not lie in the network management or network operations domain. Rather, the industry viewed CORBA as best suited for business support system functions such as financial systems that are essentially common across many industries and aren't touched by the complex demands of telecommunications networks. In the early 1990s, the Q3 interface standard -- which is associated with the common management information protocol (CMIP) and the guidelines for the definition of managed objects (GDMO) -- was leading the way in network management. Network management application developers were interested in finding a common distributed computing platform as well, but wouldn't consider CORBA, basically due to the old telco belief that says any technology suitable for the rest of the world can't possibly meet telecom's strict requirements.

In 1992, Bellcore and its parent telcos established the Telecommunications Information Networking Architecture Consortium (TINA-C) to research a telecom-specific, distributed computing platform that would essentially compete with CORBA. TINA-C did establish standards, some of which various vendors and service providers have implemented. However, in 1996, the consortium recognized CORBA as a suitable technology to fill some of the telecom industry's needs. Ultimately, Object Request Broker (ORB) vendors, such as Iona, Visigenic (now Inprise; Scott Valley, Calif.) and the recent Vertel acquisition Expersoft (San Diego), further integrated more telecommunications-specific services into CORBA as demand for the technology grew.

Perhaps the greatest force driving CORBA in today's environment is cost. Because CORBA is generic information technology (IT), there is a large development community to support it. Start-up service providers have looked to CORBA to provide more affordable systems than are available with other technologies such as common management information protocol (CMIP). Systems vendors have taken advantage of the relatively large development community and utilized CORBA in product development. "Our CLEC customers often say they can't afford a CMIP solution and want something that's less expensive. CORBA is much cheaper and faster to implement,' says Beth Krevis, product manager for application programming interfaces (APIs) and trouble management at MetaSolv Software (Plano, Texas).

CORBA has found the most acceptance linking applications within the layers of the telecommunications management network (TMN) model. "Peer-to-peer-type applications make very good sense for the CORBA protocol," says DSET's Smith. "Between TMN layers, there's still a little more maturity that needs to develop, but there is plenty of work being done in that area.'

CORBA APIS

One example of where CORBA is being used for peer-to-peer application integration is the competitive local exchange carrier (CLEC) Allegiance Telecom (Dallas, Texas). Allegiance uses MetaSolv's Telecom Business Solution (TBS) as its central operations support system (OSS) application and DSET's OSS Interconnect gateway technology to exchange ordering information with Bell Atlantic (New York). The link between TBS and DSET's gateway is based on MetaSolv's CORBA API.

According to Krevis, MetaSolv's API is based entirely on a CORBA platform with an Interface Definition Language (IDL; see sidebar)-defined interface. Below that IDL definition are business objects that map to the interface. These objects can be written in any language, but MetaSolv uses Java. "Part of our overall architecture is to develop APIs that represent a business function. We use multiple business objects all within the same API to represent a business function," explains Krevis.

One such business function is the Local Service Request (LSR), the process and set of documents a CLEC must file to the incumbent local exchange carriers (ILECs) to initiate a customer switchover. For any LSR there is, naturally, an associated customer, a number of roughly standardized forms, and specific validation rules attached to each form, such as required and optional data fields. The LSR process is defined in an object that has child objects associated with it containing data for the customer and all of the specific forms. The objects for a specific LSR transaction are collected in the LSR API and made available to the gateway for translation and transmission from Allegiance to Bell Atlantic.

MetaSolv's API is also tied into its workflow engine, allowing specific tasks in TBS to be dynamically associated, by the user, to the interconnection process. For example, after LSR information is successfully exchanged, Bell Atlantic will send a firm order confirmation (FOC) to Allegiance. Once notified, TBS can begin the provisioning process. In many cases, this provisioning process is dependent on further transactions with the LEC, such as orders for leased circuits and number portability. Tasks in TBS can be defined in a provisioning plan. Each new piece of required information the CORBA API delivers will kick off the next set of tasks in the plan.

CORBA works in this type of environment because its architecture allows for a granular level of configuration. Rather than utilizing "hard code" to tie applications together, each behavioral aspect or process specific to cross-application interactions can be defined with objects. Object hierarchies allow attributes of a specific object to be changed independently of related objects; global changes can be made to entire classes of objects, or broad changes can be made to a specific subhierarchy of objects. The point of all of this is that it makes it easier to add or change processes and functionality on either side of a CORBA interface without fundamentally changing the way applications exchange data or without having to rebuild a large part of the interface.

However, peer-to-peer or east-west integration involves relatively low transaction volumes. CORBA's object architecture can handle such volume. It's at the high-volume interactions between TMN layers where CORBA's effectiveness comes into question. "We don't see scalability problems in the app-to-app interfaces because the transaction volume is relatively low," says Krevis. "When you're talking about going southbound to network elements, you're talking about thousands of transactions a minute. We're talking about sending LSRs between service providers. You may have a thousand a day, but you're not talking about thousands per hour, minute, or second."

THE SOUTHBOUND INTERFACE

Generally, the highest transaction volumes are found between the network management and element management or network element layers in the TMN model. An enormous amount of data, ranging from billing to activation to fault and trouble to performance is constantly flowing back and forth between the network and OSSs. Network elements do not yet utilize CORBA to send or receive information. They often use standards such as CMIP, signaling network management protocol (SNMP) or the older TL1. There are also a number of proprietary interfaces and protocols in the network.

However, network management platforms are being built on CORBA, and this has created a need for gateways that can translate between network element protocols and CORBA. Companies such as Vertel (Woodland Hills, Calif.) and DSET have developed CORBA-to-CMIP and CORBA-to-TL1 gateways. Essentially, these gateways are specialized mediation devices that receive the flood of information from the network in various formats, translate it into CORBA, and then parse it out to the appropriate applications. This allows for communication between the layers and protects applications from being overwhelmed by the sheer volume of data flowing up from the network.

This can also work in the opposite direction, where gateways receive CORBA commands and translate them into the appropriate network element protocols. Quite often, however, element activation systems are independently designed to communicate with multitechnology, multiprotocol networks. In such cases, CORBA gateways might not be necessary.

CORBA'S FUTURE

CORBA's future in telecommunication looks pretty bright, if for no other reason than the fact that Nortel Networks (Brampton, Ontario, Canada), Lucent Technologies (Murray Hill, N.J.), Tellabs (Lisle, Ill.) and Fujitsu (San Jose, Calif.) have been shopping it to various standards bodies for further development. They first brought the technology before the Sonet Interoperability Forum, which initially rejected it. Now, about a year later, the Sonet Interoperability Forum is taking a hard look at CORBA. The four giants also went to the TeleManagement Forum, which has since established a committee to look at a CORBA IDL interface between the network management and element management layers. The GDMO model has already been converted into CORBA IDL. Although these ideas have not been fully embraced, industry momentum and current investment suggests that CORBA will mature and be utilized in some fashion at all levels of the TMN model.

CORBA basics

The Common Object Request Broker Architecture (CORBA) is designed as a standardized, vendor- and operating system independent technology for client/server, object-oriented application integration. An Object Request Broker (ORB) is a type of middleware, standardized in CORBA, which enables client-server relationships between objects. When applications communicate, one application sends a request to the ORB, which then finds the appropriate object from the answering application to fulfill the request, feeds it the parameters of the request, performs the object's function, and then relays the result back to the requesting application. This essentially shields communicating applications from having to understand how to navigate within each other. ORBs are commercially available from vendors such as Visigenic (now Inprise; Scott Valley, Calif.) and Iona. The ORB provides the architectural details and integration/communication needs of each application through its Interface Definition Language (IDL), another part of the CORBA standard. IDL is designed to help developers avoid building any specialized protocols specific to the interaction of a particular collection of applications.

Editor's note: At the time this article was written, the author was a technical analyst at MetaSolv Software.

Figure 1: CORBA in the lower TMN layers

~~~~~~~~

By Edward Finegold

Section: Development & Integration

Driving NT

Suppose you want to write a distributed application using object technology. If your application will run in a purely Microsoft environment, DCOM is the obvious choice. If your app needs to run on Unix or other non-Microsoft systems, though, DCOM isn't especially practical. So what middleware technology should you use?

The answer was supposed to be the multivendor standard for distributed object computing called CORBA. But CORBA isn't very complete, so products

built by different vendors have had a hard time working well together. Even though the vendors backing CORBA intended it to be a bulwark against Microsoft, the real competition turned out to be among the CORBA vendors themselves.

That competition has a clear winner: It's Iona Technologies, a Dublin, Ireland-based company that has the largest share of the CORBA market today. It's hard to know for sure, but it's possible that Iona is the only software company to have actually made a significant profit from CORBA. It's certainly the Only CORBA-based firm to enjoy a wildly successful IPO, something that I'm sure has made its backers quite happy.

As nearly everyone knows, CORBA was created by the Object Management Group (OMG), which has done an outstanding job of making its Work visible. OMG's original members included all the big guns, including IBM, Sun, and HP. How did Iona, a small start-up operating out of a far-away city in an economically depressed country, manage to acquire the largest share of the CORBA market?

The story is instructive. First, the big hardware vendors in OMG all seemed to believe that CORBA really was a standard, and so most of them built products that only ran on their own systems. The truth, however, was that the CORBA standards were so loosely specified that making different vendor's products interoperate was at best very challenging. What customers wanted was something that allowed them to create distributed object applications that ran on all of their systems, not just those from a single vendor. As a result, the CORBA-based products produced by hardware vendors were never very successful, and all of those original products have essentially left the scene today.

Iona understood what customers wanted from the beginning. Since the company had no vested interest in promoting any particular hardware platform, its CORBA implementation targeted multiple vendors' systems --including Windows NT and several flavors of Unix -right from the start. Iona benefited from the ultimately untrue but very appealing "CORBA is a standard" message promulgated by OMG, yet still provided a way to solve customer problems. All those customers had to do was install Iona's products on all of their systems. If pressed by their management, Iona customers could claim that they were buying a fully standards-compliant product. In reality, they were creating an effective, workable, single-vendor middleware environment.

Another difference between Iona and its competitors was in how it saw Microsoft. From the beginning, cynics observed that OMG was really the "Oppose Microsoft Group," and most CORBA vendors touted their superiority over COM. !Iona, by contrast, licensed COM from Microsoft. Iona's company slogan is "Making Software Work Together," clear evidence of their pragmatic perspective.

Just as Iona's dominance in the CORBA world has become clear, however, the game has changed. Purely CORBA-based products are on the wane as Enterprise Java moves to the fore. Enterprise Java adopts a few parts of CORBA, most notably IIOP, its core protocol. But good support for Enterprise JavaBeans (EJB) is emerging as the sine qua non for multiplatform distributed object middleware. No matter how many OMG standards a product implements today, it's nothing without EJB.

Iona understands this, as evidenced by their recent purchase of a small EJB company. But while they are the leader in the pure CORBA world, they're arguably a little late to the Enterprise Java party. Tough competitors -- IBM, BEA, and others -- have gotten there first.

The lesson for Iona, as for every organization, is that there's always another battle. Winning one may leave you in a good position to begin the next one, but that next battle is sure to happen. The lesson for end users is that pragmatic, customer-focused companies make the best partners, while religious fervor over some new standard is meaningless.

ILLUSTRATION (COLOR)

~~~~~~~~

By David Chapell

David Chappell is principal of Chappell & Associates (Minneapolis), an education and consulting firm. Contact him at david@chappellassoc.com.

Section: Application Development

During the last few years, Microsoft Corp.'s Component Object Model (COM) and the Common Object Request Broker Architecture (CORBA) have developed side-by-side as competing methods of communication among distributed objects. Historically, COM and CORBA objects haven't interacted well with one another. During the past several months, though, a number of independent software vendors unveiled initiatives on the COM/CORBA integration front.

In late May 1997, for example, Microsoft Corp. agreed to integrate its Microsoft Transaction Server with OrbixOTM, a CORBA-compliant middle-ware suite from Iona Technologies P.L.C. (Cambridge, Mass., www. iona.com). Other products that provide COM/ CORBA integration are Object-Bridge, a COM/CORBA bridge from Visual Edge Software Ltd. (St. Laurent, Quebec, www. visualedge.com) and M3, an object transaction manager that supports both COM and CORBA from BEA Systems Inc. (Sunnyvale, Calif., www.beasys.com).

More recently, InterNova Corp. (Westport, Conn., www. internova.com) released the Professional Edition of the Colibri Engine and Development Suite. Rather than providing COM/CORBA integration services, however, this product provides developers with the ability to create COM objects using Microsoft's Visual Basic development environment and then bridge them with CORBA components using integrated scripting technology, such as VBA or Javascript.

While several tool vendors have developed similar technology -- like the new version of Borland Delphi rapid application development (RAD) environment from Inprise Corp. (Scotts Valley, Calif., www.inprise.com), which can create components that are both COM- and CORBA-enabled --InterNova's Colibri Engine and Development Suite is one of the first tools that allows developers to employ discrete integrated development environments, such as Microsoft's Visual Basic or Inprise's Delphi, to do the actual development work.

According to Brock Hotaling, CEO of InterNova, because the Colibri Engine and Development Suite heavily leverages scripting technology, it provides COM to CORBA bridging functionality in an everything-under-the-hood development environment that requires very little experience in developing for either distributed component architecture.

"We have built into this engine a COM/CORBA bridge, so you don't need to worry about whether you're developing COM, or CORBA or whatever. It's all smooth," Hotaling says. "Our clients are scared of CORBA, scared of Java, and they just can't find qualified people to do CORBA or Java programming. This allows them to hire different people, because a huge population of programmers knows how to do scripting."

The Colibri Development Engine functions by linking the Microsoft COM desktop environment and CORBA services via a COM-CORBA Bridge, then bridges to an ODBC- or JDBC-compliant database, such as Oracle 8 from Oracle Corp. or SQL Server from Microsoft, with automatic persistence mechanisms using ODBC/JDBC or native drivers.

In addition to a Colibri Client Suite, the Colibri Development Suite includes Colibri Studio, the Colibri Management Console and a CORBA Template Starter Kit, which features sample templates that enterprises can use to customize business services.

InterNova's Hotaling indicates that many of his company's customers require COM/CORBA integration services because they are standardized on COM on the desktop and on CORBA in the backend. By Hotaling's account, this isn't about to change anytime soon. Although CORBA is a newer, sexier technology, it simply doesn't have the maturity or functionality of COM on the client-side. "To be honest with you, right now the Microsoft desktops are just far and away better than their CORBA counterparts," he explains.

Mike Gilpin, vice president and senior analyst, research services, with consultant Giga Information Group (Norwell, Mass., www. gigaweb.com), concurs, but cautions client-side application developers must now be attuned to the presence of the CORBA standard in the backroom. "I think that everybody knows that COM has established a firm ownership of the desktop environment as a standard, but what's making this integration more important is that in the context of Internet standards CORBA is gaining more popularity, particularly in the areas of Java and Enterprise Java Beans functionality (EJB)," Gilpin notes. "Anyone who wants to create an application available in a Windows environment now needs to provide some sort of interoperability solution [between COM and CORBA]."

~~~~~~~~

By STEPHEN SWOYER

Microsoft's COM and the Object Management Group's CORBA have long been portrayed as fierce competitors. Forests have been leveled to generate paper for the voluminous written attacks by partisans in both camps, and megawatts of electricity were expended to convey their electronic equivalents. COM vs. CORBA is one of the most visible industry conflicts of the last few years.

But it's not really correct.

Don't worry. I'm not going to explain how COM and CORBA can actually live in harmony, or how the Microsoft lion will lie down with the OMG lamb and peace will reign in the land. None of that is going to happen. All the hopeful predictions of the eventual technological union between COM and CORBA are wrong. These two technologies will remain distinct --although the CORBA camp has understood the necessity of defining mappings to COM, if only to support those ubiquitous Visual Basic clients.

If COM and CORBA were really competitors, however, you'd be faced with situations where you were forced to choose between them. In fact, this almost never happens. And if you don't get to choose between two technologies for a given application, then, by definition, those technologies can't be competitors.

To explain what I mean, let me start by pointing out that there are some important cases where CORBA just doesn't apply. The OMG never really defined a standard for running objects in the same process as their client, for example, while this is a critical part of COM. A more correct comparison, then, is between CORBA and Distributed COM. Both CORBA and DCOM focus on the same thing: creating and communicating with objects running on remote machines. So the real question becomes, when are you faced with a choice between DCOM and CORBA?

Suppose you've decided to build an application using distributed object technology. If your clients are Windows 9x or Windows NT machines, and your servers run NT, DCOM is the obvious choice. You certainly could go out and purchase an appropriate number of licenses for your favorite CORBA-based product and use it instead, but why would you? DCOM is free, it has reasonable security (something that's harder to find in CORBA-based products), and it has great tool support on Microsoft platforms.

If, on the other hand, you'd like to use Unix or the mainframe for your server, DCOM isn't really an option. True, Microsoft and others do sell DCOM products for operating systems other than Windows and Windows NT, but it's hard to take these products seriously. Microsoft has said publicly that COM's next release, COM+, won't be available anywhere except Windows and Windows NT, which means that COM on non-Microsoft systems is already becoming legacy technology. But more fundamentally, do you really believe that Microsoft cares about operating systems other than its own? While it's plausible that they're interested in connecting to existing applications and data on those systems, it's much less believable that Microsoft will help you build new business logic on those systems. All of this means that choosing to build a new server application on non-Microsoft platforms using DCOM, while technically possible, is a very risky choice.

So here's the very simple decision tree for building distributed object applications: If both client and server run Microsoft operating systems, use DCOM. If not, use a CORBA-based product. Once you've chosen the operating systems, the choice of a distributed object technology is already implied. The apparent competition between DCOM and CORBA is really just an artifact of a much more titanic struggle: the fight between Windows NT and everything else.

One final note: The COM vs. CORBA battle gets so much attention that I sometimes think other middleware choices don't get the consideration they deserve. In particular, there are plenty of situations where message queuing middleware, such as IBM's MQSeries, makes much more sense then either COM or CORBA. And some projects that are built using distributed objects might have been doable as Webbased applications instead. Despite the hype around objects, there are other choices worth considering than just COM or CORBA.

~~~~~~~~

By DAVID CHAPPELL

David Chappell is principal of Chappell Associates (Minneapolis), an education and consulting firm. Contact him at david@chappellassoc.com.

Section: Feature

As more users take advantage of distributed computing, and Internet technologies become more prevalent, many middleware trends are appearing. These trends aim to provide organizations with the application development environments required and the access to diverse services demanded by Web-based clients.

Of the four main types of middleware that support applications --Application Development Environments (ADE), data access services, message-oriented middleware (MOM), and object/component services --Object Request Broker (ORB) technology is apparently getting the most ink.

ORBs, designed according to the Common Object Request Broker Architecture (CORBA), allow objects within an application system to interact. In a distributed environment, the ORB keeps track of objects and their location on the network. Applications requesting services need only make the request to the ORB, which routes the request transparently.

Because of the complexity of the object/component environment, there is a clear need for standards. The Object Management Group (OMG) maintains responsibility for the CORBA specifications, and is also responsible for the Internet Inter-ORB Protocol (IIOP), which is intended for similar object services over the Internet. CORBA, however, is primarily deployed in the Unix and large-scale systems domain.

Then there is Microsoft's COM/DCOM (Distributed/Component Object Model), an ORB that is available on Windows platforms only and that does not comply with CORBA specifications. DCOM allows COM-enabled applications to interact with other COM-enabled applications over a network. Although proprietary, it is able to take advantage of operating system functions and services by effectively re-using them.

There is now an ongoing CORBA-versus-COM/DCOM debate and there isn't likely to be a clear winner in the short term. CORBA is today more open, mature, robust and scalable, while COM/DCOM is rapidly gaining because of the widespread use of Microsoft operating systems.

An emerging class of "object" middleware involves Object Transaction Monitors (OTM), which combine the power, robustness and scalability of Transaction Processing Monitors (TPMs) with the re-usability and flexibility of ORBs. Microsoft's Transaction Server (MTS), because of its strong integration with DCOM, fits in this category. It can manage any ActiveX object, and any component built with development tools such as Java++ and C++ can be managed by the MTS. OTMs are also available in the Unix world where CORBA has developed a specification called Object Transaction Server (OTS). Sybase's Jaguar Component Transaction Server is built using this standard.

With the emergence of Enterprise Resource Planning (ERP) systems, middleware is evolving to solution-oriented implementations. Packaged solutions from companies such as CrossRoads Software link two or more ERP applications in plug-and-play fashion. CrossRoads provides the application components and the underlying middleware components to enable interoperability between ERP systems.

Specific solutions are evolving for the Internet. Java Database Connectivity (JDBC) provides access from Java applications to distributed databases and the Remote Method Invocation (RMI) is the Java equivalent to Remote Procedure Calls.

The greatest change due to the Internet will be componentization. To isolate an unknown number of "browser-based" users from various segments of an enterprise's applications, enterprises will increasing rely on application (or component) servers.

These middleware servers will take advantage of many of the services described above, but attempt to package them in a single product offering.

Application servers will typically allow "browser-based" clients to access a variety of distributed applications, transparently providing them with the required underlying middleware support.

As this is new technology, applications will likely be developed using newer Web application development tools (e.g. Java, JDBC, IIOP, Web Server-specific APIs) and be developed as objects or components where possible.

However, applications will still require access to basic middleware services such as data access, message-oriented middleware and ORB technology.

In the short term, enterprises developing distributed computing applications can expect to use a combination of middleware types. As Internet technologies gain greater acceptance, middleware that enables application development and deployment in this environment will become widespread.

Although some features and functionality of different types of middleware are converging, enterprises can expect to use multiple types to address their specific needs.

~~~~~~~~

By Geoff Ribek

The author is associate director in DMR's Technology Consulting Practice based in Ottawa. His e-mail is geoff(underbar)ribek@dmr.ca.

The Common Object Request Broker Architecture (CORBA) describes the architecture of a middleware platform that supports the implementation of applications in distributed and heterogeneous environments. The CORBA standard is issued by the Object Management Group (OMG), an international organization with over 750 information software vendors, developers, and users. In contrust to other middleware platforms (like Microsoft's DCOM), CORBA is a specification that does not prescribe any specific technology. In fact, the specification is freely available from the OMG (http://www.omg.org/) and anyone can implement a CORBA-compliant system. In this article, I'll present one such system-MICO (short for "Mico Is COrba"), a freely available CORBA implementation.

The MICO sources are available at http://www.icsi.berkeley.edu/~mico/. The compilation and installation of MICO requires the usual GNU tools. Precompiled binaries as well as a more detailed manual are available from Morgan Kaufmann Publishers (http://www.mkp.com/). The distribution currently contains binaries for IBM-AIX, Linux, DEC Alpha, and HP-UX. It should not be difficult to port MICO to any platform where GNU tools are available (for instance, we were able to compile MICO under Windows NT).

The current version of MICO supports:

• IDL to C++ mapping.

• Dynamic Invocation Interface (DII).

• Dynamic Skeleton Interface (DSI).

• Graphical Interface Repository browser that lets you invoke arbitrary methods on arbitrary interfaces.

• Interface Repository (IR).

• IIOP as native protocol (ORB prepared for multiprotocol support).

• Support for nested method invocations.

• An interface for inserting and extracting constructed types that were not known at compile time.

• Full Basic Object Adapter (BOA) implementation, including all activation modes, support for object migration and the implementation repository.

• BOA can load object implementations into clients at run time using loadable modules.

• Portable Object Adapter (POA).

• Support for using MICO from within XII applications (Xt, Qt, and Gtk) and Tcl/Tk.

• Naming service.

• Event service.

• Trading service.

• Dynamic Any.

• Interceptors.

• Support for secure communication and authentication using SSL.

Overview of CORBA

Figure 1 presents an overview of the components required for a CORBA 2.0-compliant implementation (depicted in gray), as well as the embedding of an application in such a platform (white components). The Object Request Broker (ORB) is responsible for transferring operations from clients to servers. This requires the ORB to locate a server implementation (and possibly activate it), transmit the operation and its parameters, and finally return the results back to the client.

An Object Adapter (OA) offers various services to a server such as the management of object references, the activation of server implementations, and the instantiation of new server objects. Different OAs may be tailored for specific application domains and may offer different services to a server. The ORB is responsible for dispatching between different OAs. There is only one OA required for a CORBA 2.0-compliant implementation--the BOA. As its name implies, it offers only basic services to a server.

The BOA has access to the Implementation Repository (IMR), which contains information concerning the activation of servers; for example, the location of the executable to handle particular incoming operations. The ORB, on the other hand, has access to an Interface Repository (IR) at run time. The IR holds information about the interfaces (IDL specifications, for instance) used within the domain of the ORB.

The interface between a client and server is specified by an Interface Definition Language (IDL). According to the object paradigm, an IDL specification separates the interface of a server from its implementation. This way a client has access to a server without being aware of the server's implementation details. An IDL compiler generates a stub for the client and a skeleton for the server, which are responsible for marshalling the parameters of an operation.

The Dynamic Invocation Interface (DII) allows a client to invoke a remote operation without requiring a stub, and likewise, the Dynamic Skeleton Interface (DSI) enables a server to receive an operation invocation without requiring a skeleton. Thus the DII and DSI represent generic methods for sending and receiving operations. A possible application for the DII and DSI is a gateway, which provides bridges between CORBA and other middleware platforms. Without the DII and the DSI, the gateway would have to be recompiled with the appropriate stubs and skeletons and restarted every time a new IDL specification is introduced to the system.

Design Criteria for an ORB

If someone sets out to implement the CORBA standard, it is necessary to decide on the design criteria according to which the implementation should be structured. The design principles which guided the implementation of MICO include:

• Start from scratch. Use only what standard UNIX API has to offer. Don't rely on proprietary or specialized libraries.

• Use C++ for the implementation.

• Make use of widely available, nonproprietary tools.

• Omit bells and whistles. Only implement what is required for a CORBA-compliant implementation. Run-time efficiency is not an issue.

• A clear design, even for implementation internals, ensures extensibility.

The result of 10 months work and 90,000 lines of code, MICO is a fully CORBA 2.0-compliant implementation. Since MICO implements the Internet InterORB Protocol (IIOP), it is fully interoperable with other CORBA implementations. Interoperability was successfully tested with Orbix from Iona, VisiBroker from Inprise, and Sun's JDK 1.2 beta 2 (which now includes a "little ORB").

MICO's Modular Architecture

The design of our ORB as the central component of a CORBA implementation follows a microkernel approach. This means that as much functionality as possible is moved outside the ORB in order to keep it small and efficient. Our implementation of IIOP demonstrates this principle.

The way parameters and operations are coded and transferred via TCP/IP between two ORBs is defined by the CORBA standard through IIOP; thus, it should be possible to run one application across ORBs from different vendors if they correctly implement IIOP. The CORBA standard purposely does not prescribe any specific technology for the implementation of IIOP. To facilitate the integration of future transport mechanisms between ORBs, we located the implementation of IIOP in MICO outside of the ORB.

In Figure 2, the implementation of the IIOP protocol is located in a special-purpose OA (IIOP client) and an object (IIOP server). When a client sends an operation, this operation first enters the ORB. The ORB then dispatches the operation to one of the OAs that have previously registered with the ORB. The decision of where to send the operation is solely decided on the basis of the object reference; the ORB itself has no knowledge of remote or local objects. If the server object resides in a different address space, the operation is dispatched to the IIOP client.

This special-purpose OA opens a TCP/IP connection to a remote IIOP server. The IIOP server behaves like an ordinary CORBA object and forwards the operation to its local ORB. Here, the operation is dispatched by the ORB via the BOA to the server object.

Once an OA has taken over the responsibility of an operation invocation, the ORB does not need to know what the OA is doing with it. Whether the OA opens a TCP/IP connection or does something else is out of the jurisdiction of the ORB. Using this microkernel architecture we have also implemented the various activation modes CORBA prescribes for a compliant implementation by means of a special-purpose OA. This guarantees a modular and easily extensible architecture.

Which Came First?

An IDL compiler translates an IDL specification into the stubs and skeletons. The code that the IDL compiler generates for stubs and skeletons must be in the same programming language used in the implementation for the client and the server (client and server need not be written in the same programming language). The CORBA standard defines mappings from IDL to several high-level programming languages. According to the rules for CORBA compliance, an implementation has to offer at least one IDL language mapping to one high-level programming language: MICO implements the IDL-to-C++ mapping.

An IDL compiler works in two steps: The IDL specification to be translated is checked for correct syntax and semantics, and then code is generated for the target language according to the language mapping. These two steps are called the "front-end" and "back-end" processing in compiler construction terminology.

The front end of the IDL compiler must somehow pass on information to the back end. This data structure is commonly known as a "syntax tree." In this case, a careful analysis shows that the logical structure of the syntax tree is equivalent to the logical structure of the Interface Repository (IR). As previously noted, the IR is responsible for storing and retrieving IDL specifications.

Since the IR is mandatory for a CORBA-compliant implementation, MICO's IDL compiler makes use of the IR to pass information from front-end to back-end. Here, however, lies an interesting problem: Because the IR itself is a proper CORBA object, its interface is defined in terms of an IDL specification; this leads to a chicken versus egg problem, since implementing an IDL compiler requires an IR, and, since a stub and skeleton are necessary for the implementation of the IR, the converse is true as well. However, this issue is easily resolved via a bootstrap process: The stub and skeleton for the IR are first generated manually by the developer, and then later replaced by the ones automatically generated by the IDL compiler. If you download the sources for MICO, you will find code generated by the IDL compiler during this bootstrap process.

Another specialty of MICO is related to the code generated by the IDL compiler. The stubs and skeletons generated by the IDL compiler are responsible for marshaling the parameters associated with an operation. MICO's marshaling is done via a standard interface offered by the ORB, while other CORBA implementations came up with their own (and proprietary) interface. The stubs and skeletons in MICO use the DII and DSI that are mandatory for a compliant implementation; therefore, the code generated by the IDL compiler also demonstrates the uses of the DII and DSI interfaces of a CORBA platform.

Sample Application

The first step toward creating a distributed application with CORBA technology such as MICO is to define the interfaces between the objects of the application using IDL. As an example, I'll use a banking scenario: The server models a bank account where a client can deposit and withdraw money. Listing One (at the end of this article) shows one possible IDL specification for this.

The server implements three operations: deposit, withdraw, and balance. The keyword in denotes an input parameter, and similarly, the keywords out and inout denote output and combined input/output parameters. The IDL specification in Listing One is fed into the IDL compiler to generate a stub and a skeleton for this interface. Next, the server must be implemented as in Listing Two. The server provides an implementation for all the operations listed in the IDL specification. This implementation is represented by the C++ class Account(underbar)impl, and is derived from class Account(underbar)skel: a class part of the skeleton. The class Account(underbar)skel receives an operation invocation and dispatches it to the proper C++ method. The three methods of class Account(underbar)impl are declared as pure virtual methods in class Account(underbar)skel.

The first step of every CORBA application is the initialization of the ORB and the BOA. Following this, a new account object can be instantiated. The function object(underbar)to(underbar)string converts the object reference of the newly created object from an internal binary representation to an ASCII string. This string is called an Interoperable Object Reference (IOR) by the CORBA standard and allows clients to locate the account object. Clearly, the IOR must encode a hostname and port number for this to work. The question is how to transfer the IOR to the client. For the scope of our little example, we simply use a UNIX file to store the IOR. A better (but more complex) way would be to use CORBA's naming service.

Listing Three presents the implementation of the client which uses the account object. Like the server, it first initializes the ORB, and then the client reads the IOR from the previously created UNIX file. The client does not need to initialize the BOA, because the BOA is only required for server functionality. Subsequently, the function string(underbar)to(underbar)object is used to convert the ASCII representation of the IOR back to a binary representation. This leaves you with an object reference to an interface Obect--the base interface of all CORBA interfaces. The interface must now be downcasted to the proper type. This is accomplished by the function (underbar)narrow, which is also generated for every stub.

Once the object reference is downcasted to match the interface type "Account," the client can invoke any of the operations belonging to the interface. The operation invocation is indistinguishable from a normal C++ method call and it is transparent to the client whether the server resides in the same address space or on a remote host. In fact, if the server happens to reside in the same address space, then the operation invocation is mapped to an ordinary C++ method call with no extra overhead. Just as the server's location is transparent to the client, so is the programming language with which the server is implemented.

If you have installed MICO on your system, compiling the example is easy. MICO provides you with some wrapper scripts, which add proper command-line arguments to the compiler and linker (such as include directories). From a UNIX shell, use Example 1 to generate the executables of the bank demo. This example is part of a tutorial from the MICO documentation that comes with the sources. The tutorial enhances the example by showing how to use the CORBA activation modes or the persistency mechanism. Another component of MICO is a graphical browser for the IR.

IR Browser

A CORBA-compliant implementation must provide an Interface Repository (IR) which can be seen as a database for IDL specifications accessible at run time. The information managed by the IR is organized hierarchically. Two different types of objects are managed by the IR: those objects which can contain other objects (called "Container") and those which are contained in other objects (called "Contained"). The IDL-type const is an example of a Contained, whereas the IDL-type "interface" is a Container as well as a Contained (for example, it contains other objects like const declarations and can itself be contained in a module).

Upon starting the graphical IR-browser, top-level objects are represented by icons. Moreover, the IDL source code can be shown for each object. The contents of the objects representing containers may be viewed as if the user had descended one level along a branch of the hierarchy.

Figure 3 is the IR browser in action. Prior to starting the IR browser, the IR was fed the IDL specification from Listing One. The interface Account is a Container containing three Contained objects. Each of these Contained objects represents one of the operations belonging to the interface Account. The upper window shows the content of the interface Account, and the three icons on the right side denote the operations deposit, withdraw, and balance. The left side of this window shows the IDL source code of the currently selected operation, deposit.

The IR browser also permits calling arbitrary operations at run time using the DII. Using the information from the IR, the tool constructs a graph representing the signature of an operation. This graphical notation is derived from a knowledge representation technique called "conceptual graphs" (CG). The lower-right window from Figure 3 displays the signature of the operation deposit as a conceptual graph. The lower-left window shows the same conceptual graph; this time in its textual notation (white nodes are surrounded by square brackets and black nodes by round brackets).

Some of the white nodes represent actual parameters which can be edited using the tool. In Figure 3, the value of the node ULONG is changed from 0 to 100. The resulting conceptual graph represents the operation invocation deposit(100). The tool can also be used to construct arbitrary IDL types like struct or sequence on-the-fly via conceptual graphs. The MICO homepage contains an online demonstration in the form of a Java applet that connects you to an Account object running on one of our machines.

Lessons Learned

The CORBA standard represents a specification of a middleware platform. It leaves room for design and implementation decisions which must be carefully considered. Some parts of the CORBA Standard, such as the BOA, are underspecified. This led to different implementations of the BOA for different ORB vendors, making it impossible to just exchange the underlying ORB and recompile the application. The OMG has recognized this problem and has released the specification of a Portable Object Adapter (POA).

Although MICO is not a commercial product, it is used by many research institutes and companies. Universities find it useful for term projects, while other groups find the availability of the source code advantageous for their own research. Gnome (http://www.gnome.org/), a set of applications and desktop tools similar to CDE but based entirely on free software, uses MICO for the internal communication and activation of its components.

The CORBA standard is far from complete. Version 2.2 of the specification was released by the OMG early in 1998. Our goal is to keep MICO compliant to the most recent version of the standard. We hope that placing the sources under the GNU General Public License will encourage other programmers to contribute to MICO's development.

Listing One

// File: account.idl
interface Account {
    void deposit( in unsigned lonbg amount );
    voide withdraw( in unsigned long amount );
    long balance();
};

Listing Two

// File: server.cc

#include <fstream.h>
#include "account.h"

// Implementation of Interface Account
class Account(underbar)imp1 : virtual public
Account(underbar)skel
{
private:
  CORBA::Long(underbar)current(underbar)balance;
public/:
  Account(underbar)imp()
  {
   (underbar)current(underbar)balance = 0;
  }
  void deposit( CORBA::ULong amount )
  {
    cout << "Operation deposit( "<< amount ")" << end1;
    (underbar)current(underbar)balance += amount;
  };
  void withdraw( CORBA::ULong amount)
  {
   cout << "Operation withdraw(" <<amount << " )" << end1;
    (underbar)current(underbar)balance -= amount;
  }
  CORBA::Long balance()
  {
   cout << "Operation balance() => " <<
(underbar)current(underbar)balance <<
    end1;
   return (underbar)current(underbar)balance;
  };
};
int main( int argc, char *argv[] )
{
 // ORB and BOA initialization
 CORBA::ORB(underbar)vara orb = CORBA::ORB(underbar)init(argc,
                                argv, "mico-local-orb" );
 CORBA::ORB(underbar)var boa = orb->BOA(underbar)init(argc,
                               argv, "mico-local-boa");
 // Create new Account object
 Account(underbar)impl* server = new Account(underbar)imp1;
 // Write IOR to file
 ofstream out ( "account.ior" );
 CORBA::String(underbar)var ref = orb->object(underbar)
                                  to(underbar)string( server );
 out << ref << end1;
 out.close();

 // Start processing incoming operations
 bo->imp1(underbar)is(underbar)ready
 (CORBA::ImplementationDef::ni1() );
 orb->run();

 CORBA::release( server );
 return 0;
}

Listing Three

// File: client.cc

#include (iostream.h>
#include <fstream.h>
#include "account.h"

int main( int argc, char *argv[] )
{
  {
    // ORB initialization
    CORBA::ORB(underbar)var orb = CORBA::ORB(underbar)init(argc,
                                  argv, "mico-local-orb" );

    // Read IOR from file
    ifstream in( "account.ior" );
    if( !in ) {
      cerr << "Can not open file 'account.ior'" << end1;
      return - 1;
   }
   char ref[1000];
   in >> ref;
   in.close();

   // Generate object reference from stringified IOR
CORBA::Object(underbar)var obj = orb->string(underbar)
                                 to(underbar)object( ref );
   Account(underbar)var client = Account::(underbar)narrow
                                 ( obj );
   of( CORBA::is(underbar)nill( client ) ) {
     cerr << "IOR does not refer to an Account object" << end1;
     return -1;
   }
   // Invoke operation on remote object
   client->deposit( 700 );
   client->withdraw( 250 );
   cout << "Balance is " << client->balance() << end1;

   return 0;
}

DIAGRAM: Figure 1: An overview of components required for a CORBA 2.0-compliant implementation.

DIAGRAM: Figure 2: Implementation of the IIOP protocol is located in a special-purpose OA (IIOP client) and object (IIOP server).

PHOTO (COLOR): Figure 3: IR browser in action.

PHOTO (COLOR): Example 1: Generating executables of the bank demo.

~~~~~~~~

By Arno Puder

Arno is working for the Deutsche Telekom AG and is currently on sabbatical at the International Computer Science Institute in Berkeley, California. He can be contacted at puder@icsi.berkeley.edu.

Section: INDUSTRY WATCH

Executives from BEA Systems, IBM and Oracle were among Object Management Group (OMG) members and customers announcing the new CORBA 3.0 initiatives at a Sept. meeting in San Francisco.

OMG members, whose goal is to set the standards for distributed computing, feel CORBA 3.0 will achieve a new level of capabilities for both experienced distributed computing programmers and less technical business analysts.

This version will simplify the use of CORBA ORBs for developing distributed object applications and should facilitate CORBA's adoption into the enterprise, OMG says.

The CORBA Component Model is a feature specifying the framework for "plug-and-play" and facilitates integration with JAVA.

CORBA objects by having the creation, life cycle and events for one object for clients to explore. It also facilitates integration with JAVA.

A simplifying feature is the scripting language specifications. These remove the need for memory allocation and de-allocation as well as compilation and linking procedures. Passing information in an object-oriented form across a network can be achieved through CORBA support for Objects-by-Value.
www.omg.org

Section: JAVA

Just when it seemed that big business was ready to tap into distributed computing by choosing between Microsoft's COM (Component Object Model) and the Object Management Group's CORBA (Common Object Request Broker Architecture), Enterprise JavaBeans (EJB) came along to muddy the waters.

To be fair, it isn't just EJB that makes distributed computing look like California in the mud season. While ISVs eagerly eye Microsoft's COM and COM+, most large businesses seem to have concluded that they'll need to write to both COM and CORBA, and now momentum is also mounting for EJB as the API set to which businesses will write their distributed applications.

Ultimately, the long-term role of Java in the enterprise will hinge on its acceptance as a distributed computing framework-either alone or in conjunction with CORBA. But that role has yet to be assured for Java, COM or CORBA. In fact, some of the most important interfaces could actually arrive as private APIs from companies that are virtually unknown today. That's because just about every major vendor and a slew of innovative startups see a huge market in building combo packages that leverage some or all of these frameworks. And these new middleware combos-commonly packaged as application servers-represent an ever-increasing accordion of disparate APIs, vendor-specific extensions and platforms that intermingle components (see "Some Well-Known Application Servers,").

Middleware now seems to stretch from the simplest application servers to high-end transaction services like BEA Systems Tuxedo. Mudware, in fact, may be a better name.

The traditional wisdom is that 1998 is the year for big businesses to choose between COM and CORBA. Since that choice will reflect a recognition that support must be provided for both, users must now select an integration platform as well. Then they must choose an API set, since, for example, platforms like CORBA may also have their own distinct APIs. Finally, they will have to choose the middleware server product on which to write their applications and provide component services-a choice that increasingly entails committing to a proprietary API.

John Rymer, president of Upstream Consulting, is among those predicting the emergence of a wide variety of standard and proprietary distributed computing interfaces and platforms to unify disparate frameworks. The private APIs are intended to provide a layer of API abstraction in front of existing CORBA, COM or EJB APIs, to simplify the task of writing to multiple frameworks or to add value to those frameworks. Private APIs will also be used to flesh out the limited functionality of EJB.

Rymer says he expects OMG to vote on CORBA 3 this fall, which will position CORBA as a platform to bridge multiple object models. He also points to private application server superAPIs-from Sun's NetDynamics to Novera Software and ObjectSpace-that create their own entry into various distributed computing frameworks.

But how these superAPIs are implemented highlights possibly dramatic differences in the world of application servers. Vendors such as BEA Systems, for example, plan to support both a superAPI and a repository approach providing direct access to APIs for frameworks like EJB. Sun's NetDynamics is moving toward supporting EJB atomically within its BusinessBeans private API set.

In fact, Rymer expects most application server providers to distinguish their products by extending their own APIs or those proffered by OMG and Microsoft. The trade-off for this added functionality is user lock-in. It's a price many businesses are willing to pay to cut development cycles. Some application server platforms, for example, are credited with cutting COM and CORBA development time in more than half-primarily by offering prepackaged components and services that users would otherwise have to build.

An interesting example of yet another type of emerging integration platform with private APIs is ObjectSpace's Voyager product series, with its popular Object Request Broker. Voyager provides CORBA and RMI compatibility, with DCOM compatibility promised in an upcoming version.

But what really impresses software developers is how ObjectSpace lets them create special components, known as agents. These agents can move independently from one device or program to another-a mobile code talent that's particularly suited to tasks like dynamic load-balancing.

Java deployment may be further delayed by the sheer volume of competing products and the lack of uniform feature sets between them. For example, many application servers are ramping up to support EJB exclusively, with others adding CORBA and an even smaller set also adding COM.

What is clear from the emergence of so many APIs is that it makes sense for large users to select platforms that at least blend support for frameworks. Sun and the OMG have taken the first steps toward common ground with OMB's RMI over IIOP specification. David Curtis, formerly OMG's director of platform technology and now with Inprise, says the specification allows RMI to be mapped to CORBA's Interface Definition Language. RMI over the Internet InterORB protocol (IIOP) lets an RMI program talk to a CORBA object without requiring IDL knowledge on the part of the Java programmer. A key advantage of the specification is that applications addressed by CORBA won't have to be rebuilt to become part of a Java infrastructure.

Still, concern remains over the nuances of shipping a JDK that supports not one, but two approaches. Certainly, duplication generally heightens complexity and boosts overall cost-which explains why some enterprises would prefer even tighter EJB-CORBA integration.

50% Java/COM pragmatists:
      Will rely on Java development with COM and
      Microsoft-flavored JVMs (these pragmatists will devote
      resources to Dynamic HTML and will be prepared to migrate
      from NT to Unix on the server if necessary)
25% Java/CORBA opportunists:
      Will rely on Java development with CORBA and without
      Sun-pure JVMs (these object opponunists will tap COM-CORBA
      bridges and rely on development tools that make it easy for
      4GL programmers to migrate to Java)
20% Low-tech COM adherents:
      Will rely on Java development, CORBA and Sun-pure JVMs
      these dreamers will spend 30 percent or more on application
      development to gain a market edge or leapfrog client/server)
5% Java/CORBA dreamers:
      Will ignore Java, tap COM and steer clear of Sun-pure JVMs
      (this low-tech group will probably write in VB, buy
      inexpensive PCs and rely extensively on packaged
      applications)

Source: Forrester Research

ILLUSTRATION

Section: INTRANET APPLICATIONS: APPLICATION LOGIC

Specifications lead an interesting life. In particular, take a look at the Common Object Request Broker Architecture specification, which is now entering its third major revision.

CORBA has received many kudos, but it also has received an equal amount of criticism. This vast difference in opinion on CORBA is due to three key issues:

First is the problem it is intended to solve. CORBA is a specification for defining how to integrate apps in a manner that is independent of the development language, hardware and operating system, using an object-oriented programming paradigm.

Second, CORBA defines no implementation detail.

Third, CORBA is defined by a committee whose members are primarily vendors that sell CORBA implementations.

Regardless of where you stand on CORBA, version 3.0 will require many' developers to re-examine their past decisions about this technology.

Today, the CORBA developers are mainly elite programmers with experience building distributed applications using third-generation languages. But this could all change with the appearance of version 3.0 object request brokers (ORBs) on the market. One of the key changes in 3.0 is the development of a CORBA component model and a corresponding scripting language facility. This single addition changes the resource requirements for CORBA to include scripting and RAD programmers as well.

Other additions to the specification include an enhanced persistence service that makes it easier to save and load CORBA objects; asynchronous messaging support for easier operation in an occasionally networked environment; and firewall support for using CORBA in a secure manner from the Internet.

Changes also were made to the naming service to make it easier for ORBs from different vendors to find one another's objects; minimum footprint requirements for embedded CORBA implementations; and requirements for using CORBA in a real-time environment.

The CORBA specification has persevered through rapid changes in the computer industry. It has adapted where necessary to complement both Microsoft's Component Object Model and Java, and remains the pre-eminent leader for large-scale application integration tasks. With version 3.0 implementations, CORBA will once again prove its value to the industry.

PHOTO (COLOR): JP Morgenthal

~~~~~~~~

By JP Morgenthal

JP Morgenthal is president of NC.Focus, which provides strategic planning, analysis and consulting of application integration technologies. Contact him with your comments at jp@ncfocus.com.

Section: NEWS: NEWS BRIEFS

On Sept. 9 at Enterprise Comdex in San Francisco, the Object Management Group (OMG) will define for the first time the pending CORBA 3.0 specification. New to CORBA 3.0, which will arrive in a preproduction release in the fourth quarter, will be an object-packing scheme that supports the Enterprise JavaBeans (EJB) specification. That will allow EJB to be reusable as CORBA services. Also new are enabling visual-application envrionments for CORBA component design, support for CORBA objects on asynchronous real-time message-queuing transports, a quality-of-service specification, and other specifications to provide integration with legacy environments.

Section: INTRANET APPLICATIONS

IN BRIEF

Enterprise resource planning vendor J.D. Edwards recently unveiled plans to support both Microsoft's Component Object Model (COM) and the Object Management Group's Common Object Request Broker Architecture (CORBA). The company plans to use the component models to better integrate third-party applications with OneWorld, its suite of products.

Section: TECH VIEW

The enterprise software and middleware industry spends a healthy amount of energy debating the relative merits of object models and component architectures. Lately, the debate has come down to two major camps: Microsoft and its minions rally around the COM architecture, while a sizable part of the rest of the industry is preaching the virtues of an architecture based on the Object Management Group's Corba.

The question is whether anyone other than the vendors really cares about this debate, or whether the participants are having delusions of grandeur. Under current conditions, the debate seems like a waste of oxygen.

There's a simple explanation for this--right now, those of us who have to actually work with technology to solve problems are more focused on being productive than on what the underlying technology is. Architecture seems to be the furthest thing from most IT professionals' mind right now--their plates are too full with other concerns, like year 2000 problems and demand for Web applications.

And it's not as if an emphasis on architecture would buy anyone any additional productivity right now. Religious dedication to one or the other doesn't particularly lend itself to quick solutions to enterprisewide problems. Both Corba and COM have their shortcomings for example, the absence of a common implementation of Corba, and the limited manageability and scalability in COM.

There are other problems with neat compartmentalization of this debate. Even though Corba is the richer of the two architectures, it is also the slower-moving of the two. Microsoft can issue a new specification for its architecture to adapt to new technologies once a week if it wants to and sometimes, that seems to be the case.

Corba is driven by approval committees, and some parts of its functionality progress faster than others. The result may be that Corba goes the way of ODI in the networking world, with the most useful pieces such as IIOP and some of Corba's brokering services outlasting the standard itself.

Microsoft's architecture clearly isn't a single best answer either. While Microsoft has brought COM along quickly, the Distributed interNet Application "architecture" is still a year or two away from providing even a majority of the pieces required of the solution.

In the interim, anyone seeking to build large, complex applications will end up having to rely upon a piece of this, a piece of that, and some vendor's proprietary implementation of both in order to get any solution out the door quickly. That doesn't make for pretty IT, and it's not exactly a long-term strategy for success. But who thinks long-term these days anyway? Let's just get past next year first.
--Sean Gallagher can be reached at sgallagh@cmp.com

~~~~~~~~

By Sean Gallagher

Iona Technologies will become one of the first middleware providers to move to a protocol-independent component-based architecture with the release of its next-generation object transaction monitor -- code-name Art -- later this year.

This new architecture will give developers an integration tool that dynamically straddles the major competing object models, such as Microsoft's Component Object Model (COM), Sun Microsystems' JavaBeans, and the Object Management Groups (OMG's) CORBA.

These technologies have been locked in academic battles, forcing customers to either chose only one or use bridges that function as gateways between different implementations.

Art achieves protocol-independence through support for the OMG's CORBA 3 object specification, which allows Art to dynamically load components, as well as transport, transaction, and messaging protocols, according to Annrai O'Toole, Iona's chief technology officer.

"Art is like an empty shell with a small kernel," O'Toole said. "It not only loads the object but it also loads what it needs to run that object"

This means that when Art encounters an Enterprise JavaBean (EJB) it will load a Java virtual machine at run time and run the objects.

"The key is that it will load any component or object," O'Toole said. "We are calling these objects '*.Objects.'"

Iona will bundle a software development kit (SDK) that will enable third-party vendors to integrate their applications with Art.

This should make it easier to develop applications for Art, according to Mike Gilpin, vice president at the Giga Information Group, a consultancy, in Cambridge, Mass.

"This means that you are not tied to deciding what protocols you have to support when you develop the application," Gilpin said.

Building CORBA-based applications is generally perceived to be a black art because of the complexity of using Interface Definition Language, or IDL. However, according to O'Toole, the company will soon be making some partnership announcements with tools vendors that are intended to help those difficulties.

"With Art it will be possible to build components through a graphical user interface," O'Toole said.

The technology is being developed in Ionas Boston facility by the ex-Hewlett-Packard object request broker guru Steve Vinoski, and will be designed to support services including events, transactions, trader, and security, and it will also support features of CORBA 3, such as portable object adapters.

However, Iona is not currently a licensee of Sun's server-side COM EJB, but will support the model in future releases of its product, according to O'Toole.

Art will be rolled out as Orbix, Version 4.0, toward the end of this year and will go into early pre-release in the third quarter.

Iona Technologies, in Dublin, Ireland, can be reached at 35 (31) 662-5255 or http://www.iona.com.

~~~~~~~~

By Niall McKay

Section: Technology

Comment

Systems universality-one of banking's largest goals-is also one of its most elusive and expensive.

The ability to consolidate and use any and all data pertinent to a transaction, customer, or product is lacking in most large banks today. For example, most customers cannot get a mortgage balance or a mutual fund return by visiting a bank branch; rather, they must place a phone call.

When it comes to determining the services an individual uses, most large banks are hamstrung by their systems. The situation is only becoming worse as banks expand into areas such as brokerage, indirect lending, and life insurance.

Nonetheless, the strategy of adding products to maximize the ability to cross-sell and ultimately cement lifetime customer relationships is in vogue.

Anyone following this year's mergers knows that the Citigroup transaction assumes improvements in front office cross-selling and customer relationships, not back-office rationalization.

Even before the merger wave, the advent of multiple delivery channels was driving banks toward the same end. With usage of the Internet and call centers increasing, customers will expect to have access to all their accounts or products, to open new services easily, and to see data that is consistent and correct regardless of channel.

The increasing complexity and proliferation of products also is leading toward systems universality. The implication of the highly touted "market of one" is a very tailored, complex product mix. High-volume distribution also has made it less expensive to put extra products-like credit cards-in people's pockets.

With bank products becoming commodities, product-customer linkages offer a new way to differentiate. The result is the absolute need to have a complete view of the customer, to know when to cross-sell, to have data consistent between channels, and to ensure any decisions on customer treatment reflect customer-specific data, not rote or mechanistic rules.

But systems universality is very expensive, mainly because of banks' "stovepipe" systems and the sheer volume of data banks possess.

Stovepipes are specialty systems that handle specific products or transactions and create or use highly specific data. For example, a deposit system is precisely tailored for what it does; no other system needs to post 20 million debits per night. Theorists decry stovepipes in favor of integrated systems, but for several reasons stovepipes are not likely to vanish soon.

Also creating difficulties and driving up costs is the increasing volume of data. Each time a transaction occurs-at the ATM, call center, Internet, or branch-a record is captured and stored somewhere in the systems. Even daily balances of funds or investments can be tracked.

The issue then becomes: what data to access, when, and why. The possible combinations are endless, and the number of calculations and statistics that could be derived are astronomical.

Complicating the issue is the fact that banking is a mass production business. A sophisticated data mining tool might let a skilled analyst investigate all data pertaining to one customer. But unless the customer is a large corporation, this will never pay off. For the hundreds of millions of retail customers, simplifications must be made. Banks end up trying to find simple combinations of data that can be matched across a wide array of customers.

To cope, a cost-benefit ratio must be applied to systems universally.

Picture the banking industry as a large cubed matrix. Down one side run about 150 lines of business, ranging from stock transfer to factoring. Down another side run the channels used for reaching the customer. Down the third side run aggregations of customer groupings, ranging from wealthy families to small businesses to importers-exporters. There would be about 50,000 cells in all, reflecting about 10 channels and 30 to 40 major customer groupings.

If only 20% of the cells have a combination of product, channel, and customer group that makes business sense, there are 10,000 viable units. Within each, there is the potential for at least one shared application system. Certain cells share common channels, for example, both the equity mutual fund cell and the securities cell go through the broker channel. Other cells have common back-end reporting or analysis.

The result is an extremely complex matrix. Connecting all these cells, for example, through true systems universality would require about 50 million connections. Even if none of the retail cells were connected to any of the wholesale cells, we could still envision a reduced set of high-probability connections in the millions.

Take some examples from Citigroup. In its commercial lines business, Travelers Group writes involuntary workers compensation pool coverage. Should the systems that support that line of business be connected with Citibank's retail businesses? Presumably not, so performing that cost benefit would be easy.

But how about connecting with the Citibank unit that lends to insurance companies and states-the same customer grouping as the involuntary workers comp business? Here the decision isn't so easy and requires in-depth analysis.

On top of the systems work, the people, processes, and policies within and around any cells that get connected may have to be changed dramatically. Training, new products, repricing, or even re-engineering may all be needed. The bottom line is enormous difficulty in determining where cell connections make sense and where they don't.

There are some technology solutions that can help reduce the costs of systems universality. One such trend is called "middleware," a layer of software that sits between all the other applications, such as those in our cells. Instead of a separate connection between each set of systems, all systems connect only once, to the middleware.

To make the middleware effective, data must be passed back and forth in a standard way. The best standard for large financial institutions with multiple legacy systems is called CORBA, which stands for Common Object Request Broker Architecture. CORBA is a specification for programmers that is produced and controlled by a nonprofit industry group with some 700 members called the Object Management Group.

Worldwide, financial institutions' spending on CORBA-based middleware is growing about 38% a year and should reach $380 million this year. The spending is touted as a way not only to reduce the cost of systems universality but also to enhance the longevity of banks' legacy systems.

CORBA is not a silver bullet in any way, shape, or form. Talk of systems universality will probably remain just that. Banks that understand this will be the best equipped to avoid wasting costs where no business benefits can be derived.

PHOTO (BLACK & WHITE): Diogo Teixeira

~~~~~~~~

By By DIOGO TEIXEIRA, Tower Group

Section: News & Analysis

A small development tools vendor believes it has the answer not only to COM and CORBA interoperability, but also to integration of the object world with programming's procedural past.

NobleNet Inc. this week will take the wraps off Nouveau, a compiler-based tool that lets developers automatically generate communication code for Component Object Model (COM) and Common Object Request Broker Architecture (CORBA), Java and remote procedure call (RPC) applications.

The new tool offers an alter-native to emerging COM-to-CORBA bridges or component wrapper technologies, which NobleNet executives said come up short anyway.

The company, which was founded in 1991 but just this year received its first venture funding-including an investment from Intel-has some big customers for its current NobleNet RPC technology, including The Sabre Group and Wal-Mart Stores Inc.

But with Nouveau, the company is extending its RPC-based Interface Definition Language (IDL) technology to work with COM, CORBA and Java as well, said Bob Blauth, vice president of marketing at NobleNet.

"We looked at all of these environments and said, 'Is there a common denominator?' " Blauth said. "The common denominator is the IDL. We take any IDL in, compile to a common data representation and put any IDL out."

NobleNet's tricks don't end there. With Nouveau, the developer also has found a way to "use IIOP [Internet Inter-ORB Protocol] to marshal requests between clients and servers so that the client thinks it is always talking to a native server," according to Blauth.

Nouveau also generates open, readable source code, which enables programmers to better understand how the whole thing works, Blauth said.

Meta Group analyst Doug Lynn said, "It's a great idea if it works from a performance perspective. I have to question: Am I going to lose functionality when I do this translation?"

NobleNet's Blauth said the problem to be solved isn't just COM-to-CORBA integration, but interoperability with legacy procedural applications as well.

"Where vendors have fallen down is [when they are] not paying particular attention to the need to bring object and legacy apps together," he said. "We don't ask people to replace investments [in applications] that they've already made."

Nouveau version 1.0 ships July 29 on Windows 95/NT, Sun Solaris, HP-UX, IBM-AIX and SCO Unix. It costs $5,000 for the first developer seat and $1,500 for additional seats, plus a concurrent user license per application server.

Highlights of the company's latest offering:

• Supports interoperability across middleware environments

• Generates CORBA, COM, Java and RPC-based communication code

• Open, readable source code

Source: Noblenet

Chart by Dawn Landi

~~~~~~~~

By Richard Karpinski

Section: Intranet Applications

CORBA and enterprise messaging are about to be married.

Object Management Group (OMG), caretakers of the Common Object Request Broker Architecture (CORBA)-the standard for object-oriented programming-is expected this week to launch the voting process for CORBA Messaging, a specification that for the first time will bring asynchronous messaging to the CORBA environment.

Among other things, the new capability-which is expected to be approved formally later this summer and deployed in vendor products beginning later this year-will enable CORBA applications to tap into commercial enterprise messaging systems from BEA Systems, IBM, Tibco Inc. and others.

By bringing enterprise-class messaging into the CORBA object world, developers should be able to build more scalable and more robust distributed object applications.

"If you think about CORBA, in order to remain a viable option for the enterprise it really has to be able to live in a world with existing messaging platforms and has to support them," said Judith Hurwitz, president of Hurwitz Consulting.

J.P. Morgenthal, president of consulting company NC.Focus, added, "What's important to walk away with is that OMG is trying to build a generic services layer, such that you could build portable distributed object applications and just hook into any set of ORB services and use them."

CORBA Messaging is not precisely a CORBA service, but rather an extension to the core specification, said David Curtis, OMG's director of platform technology.

Specifically, it brings asyn-chronous method invocation to CORBA. Today, method calls are made synchronously, which means an application makes a call and is blocked until the call is passed back.

A major benefit of this addition is that CORBA applications will be able to take advantage of the more sophisticated message queuing capabilities of products such as BEA's MessageQ and IBM's MQSeries.

"CORBA developers have expressed a strong desire to have some melding of ORBs and the kind of message queuing and middleware products they are using today," Curtis said. "They want the reliability, scalability and load distribution they are used to in their messaging systems, but in the context of the ORB programming model."

Other benefits of CORBA Messaging include enabling disconnected applications, such as the exchange of data between a server and an off-network palm computer, and the addition of quality-of-service metrics to CORBA applications, said Jon Goldberg, senior software engineer at Inrpise Corp. and primary editor of the CORBA Messaging spec.

Messaging and ORB vendors view the CORBA messaging spec as an important step forward.

"Overall, adoption of CORBA within the enterprise has accelerated. Messaging has been on a parallel growth path," said Alistair Rennie, marketing executive for IBM's Component Broker. "A well-architected connection between the two has grown substantially in importance."

Since IBM plays in both the ORB arena with Component Broker and in messaging with MQSeries, Rennie said, it should be fairly simple for the vendor to implement the final CORBA Messaging spec.

Meanwhile, BEA, which last week launched its M3 Object Transaction Monitor, helped draft the CORBA Messaging spec. "CORBA today is basically request- and response-oriented. We'd like to see the architecture support store-and-forward messaging as well. I see it as being very important," said Ed Cobb, technical director of systems architecture for BEA.

The latest draft of CORBA Messaging was put on OMG servers in mid-May. It is expected that OMG task forces will vote on the proposal this week. Next will come an electronic poll of OMG membership, a process that could take several months to complete. Hurwitz, however, criticized the OMG process of bringing new technologies like CORBA Messaging to market. "They are going to start voting, yes, but voting and getting it done are two different things," she said. "The pace of this is probably not what it should be."

~~~~~~~~

By Richard Karpinski

Section: PRODUCT APPLICATION DESIGN solutions

Design and development tools

Scientists at the Lawrence Livermore National Laboratory in Livermore, Calif., needed an automated object-oriented software application to run a research laser system. The found their answer with the ORBexpress object request broker developed by Objective Interface systems in Reston, Va.

The laser system, at the National Ignition Facility at the Livermore lab, is part of the Integrated Computer Control System (ICCS), which uses the laser to produce an energy reaction similar to the ignition of a small sun.

"ICCS must be highly automated and robust, and must operate continuously around the clock," says John Woodruff, lead architect for supervisory software at Livermore. Designers are building the software control system with the Ada 95 programming language on a "modern object-oriented software framework that will be extensible and maintainable throughout the facility's lifecycle," Woodruff says.

The software's "reference domain concept allows us to isolate and use multiple versions of application software or operating systems," says Robert Crey, an ICCS computer scientist. "And it is visibly speedier than earlier versions, which is important in applications involving huge amounts of data."

Within the ORBexpress environment, Livermore programmers can develop code that is "reusable across multiple platforms applications, and indeed other projects," Woodruff says. The ICCS is a $1.2 billion laser facility to be completed in 2003 to maintain the U.S. nuclear stockpile without resorting to underground testing.

The system will integrate more than 40,000 control points to manage 192 laser beamlines that deliver 2-megajoule pulses onto a BB-sized fusion fuel capsule in a pulse 25 nanoseconds long to simulate the fusion energy of a sun.

ORBexpress is a third-generation, CORBA 2.2-compliant object request broker.

For more information on ORBexpress or Objective Interface Systems contact Allison Alberich by phone at 800-800-6477, by fax at 703-295-6501, by post at Objective Interface Systems, 1892 Preston Dr., Reston, Va., 20191-5448, by e-mail at info@ois.com, or on the World Wide Web at http://www.ois.com.
Circle 107

~~~~~~~~

By John McHale

Section: innovations

Until recently, as long as a new risk management product worked reasonably well and did the job of integrating into a firm's established technology, it could anticipate at least a basic acceptance and use on Wall Street. But the Object Management Group (OMG), a non-profit organization founded in 1989 by eight technology companies (now over 800 members) to create a component-based software marketplace, plans to raise the bar on this process. Instead, it wants to measure how good a product is by how easily it integrates with a firm's approach to risk management -- risk management defined by actual business needs rather than by the products available.

To this end, the OMG's Risk Management Working Group has issued a Request for Information (RFI) to anyone who deals with systems that handle financial risk: banks, investment houses, traders, brokers, exchanges, regulators, tax offices and software vendors. The RFI elicits comments and input on the requirements, projects and products related to risk management system interoperability. Its intention is to establish "reusability, portability and interoperability of object-oriented software components in distributed computing environments" (according to information posted on the OMG Web site).

In a way, the RFI aims to take software components to their most flexible state, in order for a firm to be able to purchase a risk management system and then have a standardized way of interfacing to it -- way standard sockets that can plug and play with the rest of the systems. At present, it is often the case that all the connections have to be developed and redeveloped each time something new comes along.

OMG's Corba interface definition language (IDL) will be the technology for expressing the outcomes of the RFI and its subsequent Request for Proposal (RFP). (Corba is a type of middleware code that sits underneath applications and translates while different systems communicate with each other.) "It's a specification, a set of documents, put out by the OMG, that details how any application -- in the Microsoft world, the UNIX world, any program or software -- can communicate seamlessly by using Corba-enabled objects or components," says Doug Moss, spokesman for the working group and division director of the quantitative applications division at Macquarie Bank, in Sidney, Australia. At present, Corba is most extensively used by firms writing entirely new applications. (Motorola has 50 satellites around the earth communicating with each other and the ground using Corba. By mid-'98, this Corba project will enable global cellular communications.) But it's possible to integrate the language into established apps. "We're teasing out the core bits of an app and putting them inside software objects," says Moss. "We create a wrapping of the Corba protocol that allows Java or Excel apps -- any app -- to communicate to the part that is. say. doing some analytical pricing function on a UNIX server, for example."

A potential drawback to wrapping established routines into an object is a slow-down in processing time. But that doesn't have to be the case in using Corba, says Kevin Tyson, who is principal systems architect for consultant firm, Enterprise Engineering Associates, in Marlboro, N.J., and who is on the OMG architecture board. "There are different points at which you can integrate with Corba." For example, an object interface with an app that does transaction processing against a Sybase database can be new code that goes directly against the database, rather than just wrapping the existing code.

Potential benefits abound from introducing Corba to risk management: 1) Being able, for example, to quickly and easily integrate a new program that cuts processing time down from two hours to five seconds-- instead of building it yourself. 2) Outsourcing becomes easier, because you're able to outsource just bits and pieces instead of all or nothing. 3) This, of course, would have an impact on the number of staff needed, says Moss. "You might be able to share those resources with 10 other banks and not lose any competitive advantage since it is such a basic function." 4) Once standards develop, ratings for software components--like ratings for disk drive efficiency -- would become possible. "It will be like authorized Mercedes parts for your Mercedes automobile," says Moss.

PHOTO (COLOR): The Object Management Group's request for information can be found on the group's Web site at www.omg.org

~~~~~~~~

By Laure Edwards

Section: Behind the News

DEVELOPMENTS

Computing utopians have dreamt of a day when many kinds of applications running on many kinds of hardware and software platforms would seamlessly interact with one another. Platform interoperability, we visionaries foresaw, would honor software legacies, give users maximum choice, and simultaneously enable applications to work together to accomplish increasingly ambitious tasks with ever-greater efficiency. A series of advances--PCs, client-server, objects, the Web--all seemed to be major steps toward platform openness, but the goal has remained elusive.

The most promising development of recent years has been the Object Management Group's Corba standard. Corba provides standardized plumbing for connecting heterogeneous objects written specifically to their home platforms. It lets these objects communicate with one another. Corba now has several years worth of enhancements behind it, and the support of hundreds of vendor-partners. Building applications with Corba is quite rewarding, but it's also very complex, requiring specialized skills and strong motivation.

Recently, an exciting alternative has emerged. Java's built-in distributed object mechanism, Remote Method Interface (RMI), makes everything that is hard to do in Corba--debugging, distributed object creation, cleanup--virtually effortless. Credit is due to solid engineering, but RMI's real strength is the power of the Java-based architecture.

Java objects are truly portable. More than that, they are mobile and can move around the network on a moment-by-moment basis. This makes distributing the computing radically easier. Objects don't stay put and shout to each other; they can actually zip over and pay a visit, execute a bit of behavior at the location that makes the most sense, then return home or move somewhere else.

Java objects can execute anywhere because Java works everywhere. This is the advantage of a universal language. While Corba works like a magical translator that lets English speakers, Russian speakers, and Farsi speakers understand each other, RMI gets everybody speaking Esperanto. Conversations are effortless, and everybody can operate equally well in any country.

To old openness idealists like ourselves, RMI presents a quandary. Its amazing interoperability comes at the expense of inclusiveness. Java embraces all platforms, but it talks only to itself and excludes all other object models. Do we really want to cut our C++, Object Cobol, and Smalltalk objects out of the picture entirely?

A Java-Corba alliance is in the works. Sun declared last year that it would make RMI speak Corba's on-the-wire protocol, permitting interoperability with non-Java objects. But you can't use any of the fancy functionality of RMI when talking to a Corba object, so every compromise in this direction removes a little of RMI's raw power.

It would be interesting to let the best mix of Corba and RMI emerge over time, but we may not have time. Here, as everywhere else, the Microsoft juggernaut threatens. Microsoft's own Distributed Computing Model is far inferior to either Corba or RMI, totally proprietary, essentially platform-specific, and technologically mediocre. But it comes built into Microsoft products, pushed by Redmond both overtly and covertly. This model for distributed objects will sweep the industry unless the alternative is virtually irresistible.

The dilemma, then, is how much openness we can we afford with Microsoft looming on the distributed-object horizon. How much power and ease of use can RMI give up to achieve a Corba alliance?

Is the sadder but wiser course to go for broke with Java, on the theory that the only way to counter one sweeping world-view juggernaut is with another?

It's wonderful that interoperability really does seem to be within reach, even if not in as pristine a form as we'd once hoped. Our industry, particularly in the Gates era, turns idealists into pragmatists fast.

~~~~~~~~

By Tibbetts & Bernstein

John Tibbetts and Barbara Bernstein are partners in Kinexis, a San Francisco consulting firm. You can visit them at their Web site at www.kinexis.com.

Section: Application Development

In the old days, IT organizations often found themselves sucked into marketing battles when new technologies hit the scene. As the vendors duked it out, their corporate IT customers would try to put their money on the best bet--sometimes with disastrous results. But those days are gone. Customers today are more savvy about the ways of vendors and are less likely to buy into their marketing hype--even if it means taking far longer to make purchasing decisions.

Nowhere is this more evident than in the distributed object or component software market. This emerging development strategy could have tremendous impact on IT organizations--lowering development costs through software reuse while making the entire development process more flexible and timely.

Thanks to its potential, the distributed object software market is a hotbed of activity, with the battle lines drawn between Microsoft and its allies on one side, and vendors like Oracle, Sun, and IBM--who support the Corba spec--on the other. Despite the awesome firepower of these vendors, few customers seem to be getting rattled by this conflict or hurried into making a decision. Instead, they are approaching distributed objects as a business issue and are crafting strategies based on their existing infrastructure and business requirements. To avoid being victimized as early adopters, most IT shops are proceeding cautiously, experimenting with ad hoc solutions rather than buying into one architectural vision or another.

"We are playing this a little loosely," says Ron Heiner, a consultant with Boardroom Inc., a publisher in Greenwich, Conn. Boardroom is a Sybase customer doing some preliminary software component design. "We just don't know what the hot technologies will be next year. So we want to stick with good, sound fundamentals. That means using tools from reliable vendors and using good programming techniques and good relational database design. We aren't in a position where we can spend a huge amount of money every year, so we try to leverage the tools we have."

Heiner is moving toward a multi-tier architecture, adding a Sybase Power-Dynamo application server that will let Boardroom run Web sites from its database. While Heiner is skeptical about the Corba vs. DCOM battle, he expects multiple tiers and component software to bring him greater flexibility. "The marketing people are constantly coming up with new ways to do business," he says. "The only way we can adequately prepare for that is to design a system that will be as nimble as possible."

Despite the technical issues that make choosing component suppliers complicated, the decision to select one set of distributed object standards over another is primarily a business issue. Few IS shops are willing to rip out their existing infrastructure so they can adopt a particular flavor of object standards.

"In reality, it's the hottest solution looking for a problem," says Tom Loane, senior VP and CIO at Transport International Pool, a GE Capital company. "If you rate the problems that we are trying to solve this week, it isn't on the list. It is not ahead of Y2K or the Euro. But it's a method for new development, so it's wonderful for the consulting community to shove around."

Like his colleagues in other companies, Loane is leery of buying into any architectural vision that makes his existing infrastructure obsolete. "We are heavily invested in PowerBuilder and we wouldn't throw that away," says Loane.

A similar attitude prevails at the Wholesale Markets Division of GTE. Their long-term strategy is to adopt a distributed object architecture, but they're in no hurry, either. "It is just not a short-term solution," says Cliff Belliveau, a technical lead for the division. Currently, Belliveau is working on a data access application based on components. "Longer term, we are moving to distributed objects, but you can't get there all at once," he says.

Belliveau echoes the same disenchantment with Corba/DCOM as his colleagues, and says the only sensible approach to distributed object standards today is an incremental one. "There's a lot of `this vs. that' right now, so companies are cautious and not ready to spend lots of dollars on big projects."

In the Microsoft model of distributed object computing, customers use Visual Studio to create reusable ActiveX components based on DCOM, the rules describing how objects are designed so they can be distributed across a network. The development environmental includes a standard notation system and repository so the components can be labeled, found, and reused. Components are dropped into Microsoft Transaction Server (MTS), a distributed app server whose message-oriented middleware and transaction services can be used to package and deploy components in multi-tiered apps. The sole proviso is that these applications must run in a Windows NT environment. Companies that are ripping out Unix or avoiding it altogether in favor of NT say ActiveX, DCOM, and MTS make the most sense for them.

The principal alternative to Microsoft is the OMG's Corba spec. Theoretically, Corba ensures platform and application interoperability by establishing middleware standards for ORBs and related services that allow components to work with each other, The OMG has selected notation language and defined repository standards to support reuse. Organizations with a mix of mainframes, Unix servers, and Wintel desktops tend to lean toward distributed objects la Corba.

Merrill Lynch and Co. is currently putting the final touches on a component-based order management system that should be ready for prime time in Q2/98. The software, which uses Microsoft' DCOM interfaces and was written in Visual C++ and Visual Basic, is a multi-tier, component-based system with interfaces to series of heterogeneous data sources at the back end.

The components software will support a mission-critical order management application and will be used both internally by some 25,000 Merrill Lynch financial consultants as well as externally by customers placing orders electronically.

Andy Spicer, director of order management system, says a chief benefit of the components-based design was ability to use the same software in different configurations for both internal and external order management systems. In effect, Spicer's staff was able to put different pieces of the code on different tiers to achieve maximum efficiencies for these related, but distinct, order management applications.

In the internal order management process, financial consultants need to perform immediate order validation and therefore needed a fat client with business intelligence up close on the workstations. For external orders, the validation doesn't need to happen in realtime and therefore that code didn't need to reside on the front end. There, a thin client was appropriate.

"Our business is extremely dynamic and we need to respond even faster than in the past," says Spicer. "So the business rules are their own component and it is dependent on interaction with other software. We don't have to risk breaking the system to change them."

In the internal order management system, the client-side software contains user interface and business rules components, as well as some communications components. The middle tier is Microsoft's IIS 4.0 and MTS 2.0. This NT 0based transactions server handles the communications to the back-end data sources on the third tier. The third tier relies on IBM MVS, with Tandem and Stratus hardware running DB2, DB2/6000, and IMS.

Spicer and his team evaluated the distributed object models of both Microsoft and the OMG before choosing DCOM. They observes some glitches in cross-platform compatibility in Corba implementations. "Plus," says Spicer," we had existing skill set in Microsoft and there had to be compelling reason to move away from that." He adds, "Microsoft offers me a complete suite of product in this space. The products may not always be best, but they continue to make them better."

When evaluating development tools,
how important are the following OO capabilities?

                                         More important

Supports Corba                              3.25

Supports object databases                   3.92

Supports Microsoft's DCOM                   3.92

Supports object languages like C++          4.14

Supports objects access in
 relational databases                       4.29

~~~~~~~~

By Rose Cafasso

Section: CLIENT/SERVER

At its first ever user group meeting last week, Iona Technologies unveiled new products and partnerships designed to push its Orbix object request broker (ORB) product line into new markets.

With the announcements, Iona is hoping to portray the CORBA technology -- upon which its Orbix products are based -- as a viable, mainstream architecture. To that end, the company announced that Hongkong Telecom has signed on for 100,000 copies of Iona's OrbixWeb for use in set-top boxes.

"People are building large-scale systems on CORBA, and it is working ... in the real world," said Mark Evensen, senior manager for research and development at Hongkong Telecom.

Iona unveiled OrbixMX, ORB-based middleware for managing multimedia data and integrating it with an organization's IT infrastructure, said Annrai O'Toole, Iona's chief technology officer. (See "Iona brings Orbix to multimedia, OpenView," March 16, page 6.)

Designed to integrate multimedia with traditional data, OrbixMX consists of Iona's Orbix ORB; Orbix MediaStreams -- based on the CORBA A/V Streams specification -- which initiates, manages, and terminates streams; CORBA Trading and Naming; and Orbix's Internet Inter-ORB Protocol (IIOP) engine, which has a 16KB footprint that allows it to run on small, mobile devices, O'Toole said. It is slated for third-quarter release.

Iona also announced that Hewlett-Packard will sell and support the Orbix product line. And HP revealed plans to integrate Orbix products into a number of its own offerings, including OpenView.

Iona pinned a third-quarter release date on its COMet Server, a bidirectional bridge that integrates Microsoft's Component Object Model (COM) code into a CORBA environment and allows either IIOP or Distributed COM to be the wire protocol, O'Toole said.

And finally, Iona inked a partnership with NEC, which will sell and support the Orbix line, and will allow Iona to offer its implementation of Object Management Group's Notification Service in its product line.

Iona Technologies Inc., in Dublin, Ireland, is at http://www.iona.com.

~~~~~~~~

By Cara Cunningham

Nancy Weil, a Boston correspondent for the IDG News Service, an InfoWorld affiliate, contributed to this article.

Section: SOFTWARE

REASON: Got to start somewhere

LANDMARK GRAPHICS, one of Sun Microsystems Inc.'s largest resellers and ISVs, opted to use Microsoft Corp.'s Component Object Model (COM) for integrating Unix and Windows NT applications.

The announcement raised eyebrows because Landmark, based here, chose COM over CORBA, the component model espoused by many Unix and non-Microsoft powers.

Bill Curtis, director of computer science for Landmark, downplayed the significance of this announcement, vis-a-vis Landmark's relationship with Mountain View, Calif.-based Sun, a rival of Microsoft, Redmond, Wash. "The advantage to us is we intend to move forward with a component-type architecture, and you have to start somewhere," he said.

The pact will not diminish Landmark's support for other platforms, Curtis said, adding: "We'll need high-end Unix platforms for years to come, especially for computer graphics applications."

Landmark specializes in oil and gas exploration packages that use graphics-intensive seismic charts.

While Microsoft bragged about the deal, Ted Rozsa, Landmark's director of strategic relationships, said the pact is limited to interoperability and has no effect on Landmark's relationship with Sun or other vendors.

Microsoft has ardently wooed key Sun resellers and ISVs for at least a year, flying in reseller executives to Redmond for high-level briefings. That effort mirrors Microsoft's courting of important ISVs and VARs in the Lotus Development Corp. Notes/Domino communities and Oracle Corp. database developers and partners.

Microsoft has had a particularly vivid love/hate affair with Unix. Two years ago, Microsoft Chairman Bill Gates gave the keynote address at Unix Expo in New York (the show was subsequently renamed Unix and Windows NT Expo). But last May at a Microsoft-sponsored scalability day, Gates slammed Unix/RISC solutions for being expensive and proprietary, compared with Wintel counterparts.

Sun maintained Microsoft overemphasized the Landmark deal and that Landmark remains an important Sun reseller.

~~~~~~~~

BY BARBARA DARROW, Houston

Section: CLIENT/SERVER

Enterprisewide messaging

Although individual vendors have produced tools and APIs for shielding developers from the complexities of messaging software, several industry initiatives are now under way to provide varying degrees of standard interfaces and methodologies messaging.

The Object Management Group (OMG), Microsoft, and Sun's JavaSoft are all working to make asynchronous messaging -- which handles the transmission of messages between systems at different times, through store-and-forward mechanisms, or message queues -- an integral part of their component models.

With the release of its CORBA 3 specification this year, the OMG will add support of asynchronous messaging to the popular object architecture and services.

CORBA-based object request brokers (ORBs) have leveraged message queueing for some time, but the addition of asynchronous messaging to the CORBA architecture is important from a competitive standpoint, according to Eric Brown, an analyst at Forrester Research, a market research company, in Cambridge, Mass.

"CORBA is a unifying force for IBM, Oracle, Netscape, and Sun to bring together their application-server strategies around a consistent interoperability model as the only viable alternative to Microsoft's model," Brown said. "Asynchronous messaging is a critical component of distributed systems, and it must be expressed through some sort of object model. It's necessary for there to be a meaningful [CORBA] specification that the key vendors can implement."

CORBA 3 will support asynchronous message-queueing protocols as part of the base communications interfaces, so that messages can be passed on to methods for later execution.

The change is seen as essential but not innovative.

"It's not a ground-breaking move, other than the fact that there is a standard," Yefim Natis, research director at the Gartner Group, in Stamford, Conn. "I expect mostly smaller vendors will make the biggest investments in supporting it -- companies like Iona, Visigenic, and BEA, as opposed to IBM and Oracle."

CORBA already supports some asynchronous communications, according to Natis.

The CORBA Dynamic Invocation Interface, which allows client applications to make requests to objects whose definitions and interfaces are unknown when the client application is compiled, already has an asynchronous communications API, although there is no standard method for using it, Natis explained. With CORBA 3, message queueing will be one option, he said.

Asynchronous messaging support in CORBA 3 still will require the use of a message-queueing engine, which will likely become one of the requisite pieces of ORB packaging, according to Natis.

"You need to acquire a messaging engine. The protocol is just a veneer," Natis said. "Then, there has to be a class library that offers the OMG-defined interfaces. So, the ORB gives you an object adapter, IIOP [Internet Inter-ORB Protocol] engine, Interface Definition compiler, and now a messaging engine, with API libraries to include the functions to make calls to this engine."

"You need consistent APIs, because they're easier to learn and design with," Natis said.

Similarly, although in the context of a single-vendor's component scheme, Microsoft's Component Object Model (COM) and forthcoming COM+ represent asynchronous messaging as one of a series of system-level services.

Developers will be able to invoke Microsoft Message Queue Server and Microsoft Transaction Server, Windows NT 5.0's Active Directory, and other services at a higher level through a well-defined interface.

Meanwhile, Sun Microsystems' JavaSoft division is attempting to define a standard messaging API for the Java language that will also be accessible through its Enterprise JavaBeans component model.

However, the effort could prove contentious, according to one analyst.

"JavaSoft is trying to establish a standard API for messaging -- a single API for store and forward, publish and subscribe -- and messaging vendors will have to support it. They're just getting under way, and I expect there's going to be a long, drawn-out battle over the JMS [Java Messaging Service] API," said Anne Thomas, editor in chief of the Patricia Seybold Group's Distributed Computing Monitor, in Boston. "Just look at the Enterprise JavaBeans specification. It took about twice as long as anyone expected, because everyone had an opinion about what it should look like."

Another organization, the Business Quality Messaging special interest group (BQM SIG), headed by IBM, Intel, and Microsoft, has taken a less direct approach to promoting and standardizing message queueing.

Rather than define specific APIs, the group has issued rough functional requirements for systems ranging from e-mail to high-volume message-queueing software.

The BQM SIG's functional requirements, as presented to its parent group, the Enterprise Messaging Association, outline message handling, queueing, transactions, security, and embedding within other applications. To date, the group has been faulted for failing to generate practicable specifications.

The next BQM meeting is slated to take place in March.

~~~~~~~~

By Ted Smalley Bowen

Section: Application Development

With every revision, upgrade, iteration, and extension of Web technology, life gets faster and more complicated for corporate developers.

The big question last year was the choice of application model: Microsoft's ActiveX or Sun Microsystems' Java? ActiveX provided a familiar, widely adopted, yet proprietary automation standard. Java, until recently an unproven solution, promised portable applications at the expense of native performance and a new learning curve.

The raging debate turned out to be a colossal waste of time. Neither Java nor ActiveX achieved significant penetration of client-side Web computing. But this year, the application battle will shift to the server, thanks to new component models on tap from the big three standard-bearers: Microsoft, the Object Management Group (OMG), and Sun.

Component Bake-Off

The good news is that interoperability between these competing object standards keeps getting better. The bad news is that corporate architects will still have to make tough technology choices as they design their next-generation applications.

"It used to be you could analyze the requirements, choose a platform and some best-of-breed tools, and you were good to go," says Alexander Pellow, director of Internet technology with Cornerstone Information Services in Austin, Texas. "Now we have to digest a dozen new technologies every week, and test as many as possible, just to keep up. When you think it's safe to settle, something new comes along. It's enough to make you want to go back to client-server."

Among the three major object models--Microsoft's COM, OMG's Corba, and Sun's JavaBeans--slated for dramatic component makeovers this year, Corba is first in line. Version 3.0 promises to upset the component apple cart by making scalable Corba parts available to programmers who have little more than basic scripting skills.

Expected by midyear, Corba 3.0 will include four new component features intended to make the multiplatform model easier to use while retaining compatibility with previous specifications. Standardization on passing of "objects by value," a required component feature, will let systems exchange object data directly, instead of passing mere references or "handles" to objects.

"With pass-by-value, the network could go down or suffer a glitch, but your client workstation would still have the data it needed to operate the software," says J.P. Morgenthal, president of NC.Focus, a distributed-computing consulting firm in Hewlett, N.Y.

Also new will be multiple object interfaces, which will allow components to sport flexible APIs to meet varying requirements, without recoding client applications. Corba components will also use a single event model, and will support introspection (the "interface repository" in OMG vernacular). Introspection lets developers browse and connect to available component services, without requiring source code, which promotes reuse.

Lastly, Corba 3.0 calls for a standardized scripting language that, for the first time, lets developers compose multiplatform solutions on the fly, without knowledge of C++ or other advanced programming skills. In a nutshell, and compared with ActiveX and Java, Corba 3.0 components will have the most open fit for client- and server-side Web development projects.

"It means being able to take Corba components written in any language--Java, C++, Fortran, Cobol, Ada, Smalltalk--and linking them together more easily, not just on the user interface, but also on the server," says Richard Solely, chairman and CEO of OMG in Framingham, Mass. "In a real distributed object system, it's important that server components get reused as heavily as clients across multiple platforms, in a `real' distributed object system."

Baked Beans

At about the same time that OMG delivers Corba 3.0, industry observers expect Sun's Enterprise JavaBeans (EJB) specification to have stabilized, with vendors beginning to deliver beta versions of tools that support the new server-side portable component model.

A preliminary version of the spec was introduced in December at the Internet World trade show in New York.

JavaBeans components, when dispatched to the server under the EJB scheme, automatically gain scalability and enterprise-oriented attributes that client components don't require, such as transaction monitoring and security services. This is a boon for IT shops investing in server-side Java that wish to avoid building their own security infrastructures, or manually fitting homegrown components into established transaction-processing monitors, such as BEA Systems' Enterprise Transaction Framework, IBM's TX Series, NCR's Top End, Sybase's Jaguar Component Transaction Server, and Borland's Midas.

"I'm interested in the turnkey transaction processing and security enhancements," says Charles Nettles, VP of technology at McKesson Corp. in San Francisco, the $18 billion pharmaceutical distributor and large-scale adopter of server-side Java. "We're building our extranet application using server-side Java.

I need robust security, but I hardly feel justified in providing secure ID cards and those kinds of things. That's where EJB gets to be very interesting."

Not Without Pain

Moving to EJB won't be entirely painless since the spec will not provide a clean superset of the JavaBeans desktop-component application programming interfaces. Developers will have to learn some 10 additional methods and radically new visual tools and techniques for encapsulating business rules as objects.

"It's an extension, not a superset," says Sharada Achanta, Sun's product line manager for enterprise Java. "And right now it's just a spec; there are no tools. When the tools arrive, EJB [development] will be very much like rapid application development is today on the client."

Applying RAD to server-side components opens the door for tools, middleware, and application vendors to deliver entire systems as reusable component frameworks. They'll use virtually the same visual development metaphors that dominate client-side GUI building tools. Discrete back-end application services can be browsed, queried, or scripted into working applications, in similar fashion to client-side widgets, with one major difference: It all happens on the server.

Java developers look forward to leveraging RAD technology against the server. "It's rapid development of server applications," says Mark Benerofe, VP of programming and platform development for Sony Online Ventures, a division of Sony Corp. in New York. "EJB does for sever apps what ActiveX and JavaBeans did for clients. You can visually script reusable business objects together into new kinds of systems and applications."

But just as OMG and Sun begin delivering their respective component solutions, Microsoft's COM appears poised to be a spoiler. Once strictly viewed as a proprietary, Windows-only standard, COM is now making serious inroads into OMG's and Sun's once-exclusive multiplatform domains.

Microsoft announced in January a number of cross-platform licensing agreements that will drive COM into the heart of enterprise Unix shops. One of the leading Corba object request broker vendors, Iona Technologies Inc. in Dublin, Ireland, is incorporating native COM into its Orbix ORB for Solaris and Windows NT. Systems vendor Silicon Graphics Inc. in Mountain View, Calif., has agreed to integrate COM into its flagship Irix Unix operating system. Both Iona's and Silicon Graphics' COM implementations are on tap for midyear, and promise seamless interoperability between Windows and Unix application services.

Licensing Deals

All of this comes on the heels of Digital Equipment's agreement to incorporate COM into its OpenVMS and Digital Unix, both of which should be in beta testing. COM has also been licensed by Hewlett-Packard and Siemens Nixdorf Information Systems for use with their respective Unix operating systems.

Microsoft officials say they have no plans to implement Corba or EJB components on Windows platforms, preferring to interoperate through COM instead.

"We're already delivering these capabilities with COM objects under the Microsoft Transaction Server," says Joe Maloney, Microsoft's group manager for objects. "OMG and Sun have only moved from 'slideware' to 'specware.' It's going to be a while before these things come out as code."

Regardless, the ability to hook applications together over multiple operating systems and component standards has some developers salivating, and they are willing to wait for all the pieces to fall into place.

"There is no client or server anymore," says Art Machado, president of the Machado Group LLC, a Web-development consulting firm in Emeryville, Calif. "It's just a lot of distributed components. It now just becomes a deployment issue--where do you want to run them?

COM focus: Microsoft says it has no plans to integrate Corba on Windows.

Enterprise Transaction
Framework

BEA Systems Inc.
Sunnyvale, Calif.
888-232-7878
www.beasys.com

Jaguar Component
Transaction Server

Sybase
Emeryville, Calif.
800-879-2273
www.sybase.com

Midas

Borland International Inc.
Scotts Valley, Calif.
800-932-994
www.borland.com

Top End

NCR Corp.
Dayton, Ohio
937-445-5000
www.ncr.com

TX Series2

IBM
White Plains, N.Y.
800-426-2255
www.software.ibm.com

DATA: INFORMATIONWEEK

PHOTO (COLOR): Wealth of choices: Developers see so many Web technologies, it can be hard to choose, says Cornerstone's Pellow.

~~~~~~~~

By Rich Levin

Section: NEWS

Transaction servers

As Microsoft's Transaction Server (MTS) begins to gain momentum, object-middleware vendors are debating the best way for their CORBA-compliant products to interoperate with the Windows NT-based software.

One approach, announced last week by Iona Technologies, is to work with Microsoft. The two vendors will join efforts to let MTS applications interoperate with CORBA-based systems that implement CORBA's Object Transaction Service (OTS) by mapping between the semantics of the two transaction systems. Iona has laid the foundation for this work by licensing Microsoft's Component Object Model (COM) technology for its forthcoming OrbixCOMet software, a bridge designed to let messages, but not transactions, pass between the two environments.

"We have a new friend in Microsoft," said Annrai O'Toole, chief technology officer at Iona. "We believe that MTS has improved dramatically since its introduction, and it is now very important that the MTS and CORBA worlds interoperate."

Meanwhile, Visual Edge Software, whose bi-directional COM-to-CORBA Object Bridge is resold by most major CORBA vendors save Iona, this week will announce the addition of Expersoft to the ranks of its licensees.

Unlike Iona's OrbixCOMet bridging technology, which will offer the option of the CORBA Internet Inter-ORB Protocol (IIOP) or Microsoft's Distributed COM (DCOM) as the wire-level protocol, Visual Edge's Object Bridge maps between COM and CORBA at the object level. OrbixCOMet will rely on just-in-time (JIT)-compiled proxies to handle the translation, said Visual Edge president Mike Foody, in Saint Laurent, Quebec.

The latter approach, Foody contends, provides better performance and obviates licensing COM source code from Microsoft, relying instead on publicly available and less transitory specifications.

"You don't need the source code to do this. Iona tried to take DCOM directly off the wire and change it to IIOP, and emulating that externally is not tractable, so [Iona] had to go to license [COM source code]," Foody said. "With JIT compilation, and dealing at the well-specified object level, you just don't need [a source-code license]."

In a similar vein, Foody said Visual Edge's forthcoming work on integrating MTS and OTS will also be feasible without contractual ties to Microsoft.

The adoption of a CORBA component model in the forthcoming CORBA 3.0 architecture update should simplify the integration of MTS and OTS because the latter uses a procedural programming model, according to Mitch Kramer, an analyst at the Patricia Seybold Group, in Boston.

"Should CORBA support that kind of component approach, integration will be easier," Kramer said.

Iona Technologies Inc., in Dublin, Ireland, is at http://www.iona.com/. Microsoft Corp., in Redmond, Wash., is at http://www.microsoft.com/.

~~~~~~~~

By Niall McKay and Ted Smalley Bowen

 

In the Feb. 2 issue, "CORBA vendors mull integration approaches" (page 3) attributed design features to the wrong product. The product that relies on just-in-time compiled proxies to handle COM-CORBA translations is Visual Edge's Object Bridge.

Section: CLIENT/SERVER

Microsoft is ratcheting-up its interoperability offerings with a fresh effort to provide the Component Object Model (COM) on Unix systems, and an unprecedented truce with the CORBA object standard camps, in the form of Iona Technologies' licensing of ActiveX core technologies.

Iona plans next month to deliver OrbixCOMet, a product that will be seen as a bridge between COM and CORBA. The planned initial release, OrbixCOMet Desktop, is an add-on for Windows development tools such as Delphi, Visual Basic, and PowerBuilder, which will allow developers to open Windows applications to integrate with those on Unix, MVS, OS/2, and other platforms, according to Iona officials.

"This marks the beginning of the end of the gap between COM and CORBA," said Bob Muglia, Microsoft's vice president for server applications.

However, despite the apparent collaboration of the two companies, industry watchers warn that there is still a great deal of enmity between them.

As recent as just two weeks ago, Microsoft officials dismissed CORBA as an unsupported, unnecessary technology.

"There is no market in CORBA," said Gary Voth, Microsoft's group manager for platform marketing, "There are only 50,000 or 60,000 deployments of CORBA around the world."

Ironically, Iona has been very critical of Microsoft's component strategy. And Iona officials acknowledge that the driving force behind their decision was Microsoft's Windows dominance, not a warm relationship.

"I think it's fair to say that ourselves and Microsoft will continue to disagree about the importance of CORBA," said Annrai O'Tool, chief technology officer at Iona. "[Microsoft] won't, ain't, and don't support CORBA, but if you happen to be one of the poor unfortunates that is running CORBA, then they will tell you that COMet is the solution." Iona's Orbix is the most common implementation of CORBA.

Joe Maloney, Microsoft's group manager for object marketing, said the company's about-face with regards to linking COM and CORBA was a "real mature move," and a recognition that "there are Unix [systems and] mainframes out there that aren't going to go away."

Microsoft will also announce similar licensing deals with other object request broker vendors in the coming months, Maloney said.

Although Iona and Microsoft are forging better underlying integration between the CORBA and COM environments, developers can expect an even greater variance of the middleware services built on each component model, according to one analyst.

"They may come to some agreement about the lowest level of how components communicate and pass data over a network, but both [camps] are doing asynchronous messaging, security, and transaction services and fleshing out the run-time components for each environment," said Eric Brown, an analyst at Forrester Research in Cambridge, Mass. "This is a continuous process of resolving things that are relatively simple, but [higher-level] things are getting more and more different."

The other half of Microsoft's interoperability story is COM on Unix. Muglia announced last week at the company's Web TechEd conference that later this month Microsoft plans to announce pricing and support for its Unix-COM initiative.

In addition to adding an internal development team, Microsoft will push several of its third-party integrators -- including Vanstar, Andersen Consulting, KPMG, and EDS -- to back the effort.

Silicon Graphics also announced its licensing of COM, and Digital announced a beta release of COM on its OpenVMS operating system, and promised a beta version of the Digital Unix OS to follow.

Microsoft Corp., in Redmond, Wash., can be reached at http://www.microsoft.com/. Iona Technologies Inc., in Dublin, Ireland, can be reached at http://www.iona.com/. Silicon Graphics Inc., in Mountain View, Calif., can be reached at http://www.sgi.com/.

PHOTO (COLOR): ALSO AT WEB TECHED, Microsoft last week rolled-out the beta release of Site Server, Version 3.0.

~~~~~~~~

By Bob Trott and Niall McKay

Ted Smalley Bowen contributed to this article.

Section: Intelligence & Software

Although vendors are lining up behind common object request broker architecture as a key tool for implementing Telecommunications Management Network strategies and providing interoperability between applications, carriers are still leery of the technology.

A core group of vendors, including Iona, Orbix, TSCI, Bull, Nokia and Objective Systems Integrators, has been championing CORBA as a solution for providing flexibility in management and network integration for service providers. Other software vendors, including Hewlett-Packard and Microsoft, have used the technology in other industries where CORBA has become an established architecture for heterogeneous networks, said Jeff Cotrupe, program manager for public network management at Dataquest. "Vendors are moving toward CORBA much more rapidly than their carrier customers. It's very much a vendor-driven technology," he said.

"For carriers, [common management information protocol] has been seen by many as a way to go," said David Friedman, framework product marketing manager for OSI, which unveiled a CORBA component to its NetExpert operations support system (OSS) in December. "The difference is that people who have extensive experience in CMIP are few and far between, while people can become experienced with CORBA in any number of industries. That means that carriers can once again afford to have their own programmers."

To make CORBA work, carriers must have open, non-proprietary operating systems in place. In OSI's case, its new component, CORBA Access, provides a CORBA 2.0-compliant interface for integrating various applications with its NetExpert-based OSSs. It allows users to more easily integrate NetExpert functionality with other OSSs and with applications such as customer service and billing.

The product consists of two parts: an interface definition language (IDL) and a software module called the "caserver," which interacts with object request brokers from the leading CORBA vendors. The caserver interfaces with NetExpert's expert system component and the management information base, which stores states, relationships and objects associated with the network.

"This allows external systems to access, modify, delete or get information from the stored objects," said Friedman. "With that kind of functionality, carriers could use the system to monitor the status of alarms and perform more detailed analyses. Any ideas to make better use of the data in these objects can be put into effect, giving carriers a huge amount of flexibility in the way they do things."

While this flexibility is attractive, CORBA's relative immaturity in the industry is not. Telcos' previous attempts to use the technology have revealed "performance gaps that the carriers couldn't live with," said Cotrupe, although he said the continued evolution of CORBA systems bodes well for the future.

"CORBA's going to go through a period of slow growth," he said, "but eventually these vendors' efforts will yield enough test sites to show the potential. When the market is ready, the vendors will be ready. It'll just take people at the carriers realizing that it doesn't make sense to be disorganized and proprietary anymore."

~~~~~~~~

By Chris Bucholtz, Intelligence & Software Editor

Section: NEWS

PHOENIX -- The need to cut costs and save time in systems development is leading aerospace and defense engineers to use the Common Object Request Broker Architecture (CORBA) standard to bind different software programming technologies together.

"With the CORBA architecture, we've re-defined the starting point of every new CORBA application we build and we now have the potential to avoid $750,000 in development and implementation costs," says Wayne Haughey, information system group leader at AlliedSignal Engines in Phoenix. "Every CORBA project we start leverages our company investment because our components avoid a combined total of five to six man-years of development and implementation effort."

CORBA is an open distributed object computing infrastructure introduced in 1991 by the Object Management Group in Framingham, Mass. It automates many common network programming tasks such as object registration, location, and activation; request demultiplexing; framing and error-handling; parameter marshaling and demarshaling; and operation dispatching.

Reusable software

The initial launch of the AlliedSignal CORBA project showed engineers in the company's engines division in Phoenix can reduce development costs by $750,000 per new application by using a library of reusable CORBA software components.

Engineers at the Boeing Commercial Aircraft Group in Seattle, meanwhile, are using an object request broker called Orbix from Iona Technologies in Cambridge, Mass., to integrate third-party software applications for a manufacturing re-engineering project.

An object request broker helps software engineers develop CORBA objects, and arranges for objects to access each other at run-time as defined by the CORBA specification.

"Our work in integrating a host of diverse applications into a reliable robust manufacturing infrastructure presented us with a host of challenges," explains Tom Schick, senior vice president at Boeing. "By taking the open standards-based approach offered by Orbix we have been able to develop a full-featured, distributed system which has exceeded our expectations."

CORBA components include: security, persistence, tracing, help, and the ability to send e-mail. Developers can leverage the functionality of each component in application development projects without having to understand the complexity of the component and can focus on providing business solutions.

CORBA has a well-defined abstract interface, a definite interface language, and provides flexibility across applications, says John Siegel, director of domain technology at the Object Management Group. It decouples systems to enable software engineers to modify separate components in isolation, and reduce development costs through shared-application services.

CORBA also defines the interface definition language and the application programming interfaces that enable client/server object interaction within a specific implementation of an object request broker, he says. CORBA 2.0, defines interoperability by specifying how object request brokers from different vendors can interoperate.

Object request broker

Using an object request broker, a client transparently invokes a method on a server object, which can be on the same machine or across a network. It intercepts the call and is responsible for finding an object that can implement the request, pass it the parameters, invoke its method, and return the results.

The client does not have to know the location of the object, its programming language, its operating system, or any other system aspects that are not part of an object's interface, according to an Object Management Group statement. In so doing, the object request broker provides interoperability between applications on different machines in heterogeneous distributed environments and seamlessly interconnects different object systems.

The object request brokers also let programmers choose the most appropriate operating system, execution environment, programming language to use for each component of a system under construction, and enable the integration of existing components. CORBA also provides a strong defense against system obsolescence. Software engineers can easily map all common functionality through the object request broker, Siegel says.

An object request broker defines the protocol through the interface definition language -- an implementation language-independent specification.

The interface definition language defines the types of objects by specifying their interfaces. An interface consists of a set of named operations and the parameters to those operations. The language is the means by which a particular object tells its potential clients what operations are available and how they should be revoked. From the interface definition language definitions, it is possible to map CORBA objects into particular programming languages or object systems.

Engineers also can add interfaces to an interface repository service, which represents the components of an interface as objects, permitting runtime access to these components.

The primary components in the CORBA object request broker architecture are: object implementation,; the object request broker, the object request broker interface, the CORBA interface definition language stubs and skeletons, the dynamic revocation interface, the dynamic skeleton interface, and the object adapter.

Another aspect of CORBA is the Internet inter object request broker protocol -- an object request broker transport protocol defined as part of the CORBA 2.0 specification. This protocol enables network objects from several CORBA-compliant object request brokers to interoperate transparently over the Internet.

Different products that have emerged from CORBA object request brokers range from small-footprint "ORBlets" for widely distributed web-based clients, to industrial-strength object request brokers suitable for high-volume mission-critical transactional systems.

Java connection

"Java is the first step toward creating an Object Web, but it is still not enough," say Robert Orfali and Dan Harkey in their book, Client/Server Programming with Java and CORBA. "Java offers tremendous flexibility for distributed application development, but it currently does not support a client/server paradigm. To do this, Java needs to be augmented with a distributed object infrastructure, which is where the Object Management Group's CORBA comes into the picture. CORBA provides the missing link between the Java portable application environment and the world of intergalactic back-end services. The intersection of Java and CORBA object technologies is the natural next step in the evolution of the Object Web."

"The respective object models of Java and CORBA correspond closely to one another-they both support the notion of abstract interfaces distinct from implementations or classes; CORBA interface definition language data types map naturally to Java data types; their interface inheritance mechanisms are nearly identical; CORBA name spaces-modules-map directly onto Java packages;" writes David Curtis, director of platform technology at the Object Management Group. "Java allows you to create portable objects and easily distribute them; CORBA allows you to connect them together and to integrate them with rest of you computing environment-databases, legacy systems, objects or applications written in other languages."

Engineers at the Object Management Group are incorporating support for Java into their architecture, specifying a standard language mapping from interface definition language to Java, and developing specifications for automatically generating interface definition language from Java interfaces, Curtis adds.

"The OMG's membership recognize the importance of Java as a programming platform for distributed object technology, and work proceeds apace to merge the two technologies (Java and CORBA) to produce a combined capability whose whole is more powerful than the sum of its parts."

CORBA's main competition in the middleware solutions market is Distributed Component Object Model from Microsoft Corp. of Redmond, Wash. It is a low-level extension of the Component Object Model, the core object technology within Microsoft's Activex software.

A third distributed object technology, JavaTM RMI (Remote Method Invocation) is part of the Java 1.1 Development Kit, and is a solution for building distributed Java-only applications.

One of the main problems with Distributed Component Object Model is its lack of object-oriented capability, while another strength of CORBA is its security, Siegel says. "One of the goals of our architecture and interface is to distribute object system using well known secure mechanisms such as KERBEROS encryption."

For more information on CORBA contact the Object Management Group by phone at 508-820-4300, by fax at 508-8204303, by mail at Object Management Group, 12 Framingham Corporate Center, 492 Old Connecticut Road, Framingham, Mass., 01701, by e-mail at info@omg. org, or on the World Wide Web at http:// www.omg.org.

~~~~~~~~

By John McHale

Section: EMBEDDED SYSTEMS

Mating the software and the hardware that power invisible computing

The Common Object Request Broker Architecture Facilitates Work On Applications Without The Worry Of Communication Issues.

The Internet has changed the way the world does business. It also I has given new life to a 20-year old programming methodology---objectoriented programming. The Internet ushered in a world of standardized transport mechanisms, browsers, and distributed applications, then fired our imaginations to figure out how objects could be applied to this global network. Distributed objects became the hottest technology of the year due to three distinct product trends:

• The remarkably rapid acceptance of light objects such as those produced by Sun Microsystems' Java. The objects are simpler to produce than ever, and offer cross-platform capabilities, as well.

• The rise of component-style, object-based architecture in enterprise applications. The basic concept of plugging in additional functionality is being applied to applications ranging from Netscape's Navigator to Oracle's WebServer cartridges to SAP AG's R/3. IT shops are starting to think in similar ways about building functional components for in-house applications.

• The Common Object Request Broker Architecture (CORBA), which is the glue that holds all of these systems together. CORBA allows objects to locate each other and interact on any network, without having to know their implementation. Thus, the vision of truly worldwide interoperable distributed computing can become a reality with objects and CORBA.

The allure of objects is compelling. Distributed objects can unify application architectures in a way that has never been attempted before, providing leaps in improved productivity, as well as cross-platform compatibility. Developers can easily develop, use, or re-use distributed software components that interoperate independently of hardware, network, or software platforms. This feature is particularly important in the embedded systems field where devices may operate without a GUI front end. Objects allow the designer to add incredible functionally such as interactive remote access from a JAVA-based terminal to real-time objects. Objects are also key to the software architecture of today's Internet appliances such as set-top boxes and web phones. However, the challenge of incorporating objects, and more importantly, CORBA is a daunting one.

RPC To Distributed Objects

During the mid-1980s, distributed system architectures were defined by two key software trends: client/server computing based on the concept of Remote Procedure Call (RPC), and object-oriented programming supported by such programming languages as C++. The software became more of a determing factor of the overall system capability than either the hardware or networks. The limitations of the software-constrained architectures often were defined by the implementations of the RPC-based client/server and object-oriented software.

Today, a major architectural shift in the computing industry is taking place again. The distributed characteristics of the client/server computing model are being combined with a systemwide object software perspective, referred to as "distributed-object computing." It is being widely adopted within the embedded systems marketplace for the scalability and functionality offered by distributed objects.

Object-Oriented Programming

Object-oriented programming is a design and program structuring concept. An object is a software component or building block providing some services. The designer only needs to know the interface to the object to access its services. The actual code and data that implement the services within an object are invisible outside of that object. They are encapsulated within the object.

Encapsulating software functions within objects provides a straightforward way of decomposing complex applications and software systems into a set of simpler components implemented as objects, and interacting through their object interfaces. Interface and implementation need not be specified and written at the same time. Different embedded system design and programming teams can separately implement the functions (also called methods) of a set of objects without the need to interact with other teams implementing other objects. A controls expert, for example, can build the control objects, and a less-experienced application engineer can then apply them quickly and correctly. Such an approach is recursive, and objects can be made of other objects of finer grain and so forth.

An important benefit of object-oriented programming is the ability to reuse objects in different contexts. Object software is organized into hierarchical classes and subclasses. Starting from libraries of object classes, engineers can create new classes or extend existing ones by inheriting properties of previously defined classes when new services are needed. Those new classes will then be available for future uses, possibly in different contexts, saving programming, reducing testing, and ensuring consistent operation

Polymorphism is a characteristic that allows object methods to react differently, depending on specific class or subclass membership. For example, this characteristic would allow a pump object to respond differently if it were part of a reactor unit than if it were part of a mixer.

Because the code and data that implement the services of an object are encapsulated within the object, such code and data can evolve over time and be modified without any effect on the use of that object by other objects as long as the object interface does not change. Therefore, software upgrades can be performed transparently on individual parts of the system without impacting others.

In addition, legacy code can be encapsulated into objects by wrapping a software layer that provides the object interface around the old code, allowing current embedded system software to be used as a foundation layer.

Reusability of legacy code, as well as commercial off-the-shelf (COTS) software components enabled by object-oriented programming, allows developers to focus their energy on application-specific objects that implement their own core added-value. This feature makes their products more competitive, and faster to market.

Object-oriented languages have been designed to support that model. Smalltalk was the precursor; C++ was designed as an object-oriented extension of the C language; and Java is the latest born. Eiffel, Ada, and ObjectiveC are other examples of object-oriented programming languages.

Distributed Objects

The client/server model of today's enterprise computing is undergoing a fundamental paradigm shift. The model is moving from the concept of a two-way interaction, supported by the remote procedure call (RPC) paradigm, to the concept of distributed services. In a distributed system, clients request services, and not applications. Clients do not know how and where services are implemented. They only need to know what to ask from a particular service. Services can be programs or data servers, written in any kind of programming language, running on any kind of machine, anywhere on a network. In order to provide a given service, a server can, in turn, ask for other services, and so forth. Complex services can be provided through the cooperation of a multitude of servers.

This very powerful concept is made possible by the introduction of object technology into client/server systems. As seen above, objects provide services through well-defined interfaces. Distributed objects extend access to their services to other objects running on other computers in a network.

Distributed objects don't have to be written in the same programming language or run on the same operating system and computer. Distributed objects are smart pieces of software that can invoke each other's services transparently, anywhere in the network. They can interrogate each other--"tell me what you do." Distributed objects are very dynamic; they come and go, and move around.

Today, the IT industry is building distributed-object applications that span networked desktops and services taking advantage of the increased network bandwidth. Those applications allow geographically separated hardware components to participate in a single computer system, like the Internet does.

The environment that lets objects talk to each other so that developers can share them among different applications, operating systems, and hardware platforms is the Common Architecture Request Broker (CORBA). CORBA is a set of standards developed by the Object Management Group (OMG), which comprises over 700 member companies developing or using distributed-object systems and applications.

CORBA defines a standard language, the interface definition language (IDL), used to express the interfaces to access the services provided by an object. IDL is independent of the programming language used to write the code of client and server objects. Standards for mapping the IDL to common programming languages such as C, C++, or Java have been defined by the OMG.

At runtime, invocation of object services is supported by an object request broker (ORB). The ORB allows objects to interact with each other even when they don't know about each other. It translates service invocation requests and their associated parameters from a client object into the format understandable by the server object. The ORB then transports requests and replies by underlying operating systems and networks (Fig. 1). It acts like a standard software bus that also can interact with proprietary object protocols such as Microsoft's ActiveX (OLE/COM).

A client, in CORBA terminology, is a computational context that makes requests on a CORBA object through one of its references. A CORBA object is an abstract programming entity with an identity, an interface, and an implementation. From a client's perspective, the object's identity is encapsulated within the object's reference.

The interface of a CORBA object is specified in a programming-languageindependent IDL. A client running on the ORB can use anobject reference to make requests in two ways. The most common way is through a compiler-generated stub. Using the stub, a request takes the syntactic form of a native programming-language-obj ect invocation, or function invocation. The advantage of using a stub is that invocations are type checked (dynamic or static check, depending on the programming language used). Moreover, the implementation of stub-based invocation can be highly optimized.

Alternatively, the client can use an object reference together with the dynamic invocation interface (DII). The DII allows a client to make invocations without compile-time knowledge of the object type. Independently of the way the invocation is performed, the ORB directs the request to the server identified by the object reference. A server is a computational context in which the implementation of an object resides. Generally, a server corresponds to a process or task. When a request is received in a server, the server identifies the Object Adapter used by the object implementation. An object adapter is an identifiable entity within the context of a server. A server may support multiple object adapters.

The object adapter is responsible for locating, and possibly creating, a servant incarnating the invoked CORBA object. A servant can be anything executable, for instance a script, but typically it takes the form of a programming language object, such as a C++ object. The object adapter also must locate the skeleton through which the servant can be invoked. Generally, the skeleton can take two forms: static and dynamic. A static, compiler-generated skeleton transforms a request into an appropriate invocation of the servant. A dynamic skeleton uses the dynamic skeleton interface (DSI). When using a dynamic skeleton, the application must provide a generic implementation for all operationsof the CORBA object interface. Finally, the server invokes the servant through the skeleton.

The application code executing in the server must register CORBA objects in an object adapter. This operation is called binding. Also, a binding is an object-adapter-maintained relationship between a CORBA object, and the different elements making up its implementation. Bindings also include skeleton code which allows the object adapter to access the CORBA object incarnated as a programminglanguage-servant object, and code information which allows the ob adapter to locate, and possibly create, a servant object incarnating the voked CORBA object.

Servants are instances tion code while the skeleton is typically provided by the IDL compiler. general, a servant is only associated with the CORBA object during an invocation. A CORBA object need not be incarnated by the same servant each time it is invoked. The mapping of CORBA objects to servants is the sole responsibility of the object adapter (see "Implementing A Distributed Service With CORBA," p. 128).

The ORB

The role of the ORB is to send requests and receive replies, using the services of an underlying transport network (e.g., TCP/IP). However, many embedded-system applications need some control over the execution resources, not only for the application's own use of these resources, but also for the ORB's. Platform-independent abstractions of such resources are provided by a new generation of ORBs targeting real-time embedded systems.

For example, the CORBA ORB standard implemented by Chorus Systems' CHORUS/COOL provides flexible bindings to optimize object invocations depending on an object's location, operating system capabilities, and network protocols. In addition, it's componentized structure allows the optimization of the memory footprint and run-time performance by installing only those ORB services required by the application and the supporting configuration. This design allows minimal ORB profiles well adapted to various embedded system constraints.

Real-Time Is On The Mark

Many of today's embedded systems interact with a physical environment requiring real-time systems in which timing constraints must be met for the application to be correct. The environment produces stimuli, which must be accepted by the system within time constraints. Time-constrained behavior can obviously be critical to not just mission success, but to the safety of property and human life in the case of transportation systems or air-trafficcontrol software.

In addition, most embedded systems need to operate continuously, 24 hours a day, seven days a week, with a behavior that remains acceptable, even in the case of faults. Moreover, distributed embedded systems also need to be integrated with other distributed embedded systems as well as distributed enterprise systems, in multitier architectures. Such multitier architecture includes the control or operational layer, consisting of a network of control computers, connected on an industrial bus in process control systems, or on a signaling network in telecommunications systems.

Many companies building these types of critical systems are looking for the combination of a real-time embedded ORB with a real-time operating system platform that is fully configurable and componentized. For example, the CHORUS/ClassiX communication-oriented RTOS platform can accommodate application-defined policies, taking into account various real-time constraints as well as other embedded systems requirements such as memory footprint. Additionally, there's fine grain management of resources such as thread scheduling, memory management, synchronization, interrupt management, timers, and interprocess communication. It can support simultaneously different system and Application Programming Interfaces (APIs), in particular, for the migration of legacy applications, and conformance with recognized API standards such as RT-POSIX. Finally, it provides non-stop operation features, such as fault confinement, onthe-fly dynamic software reconfiguration, and hot-restart of system and applications.

Before There Were ORBs

Before ORBs came into fashion, the main support for message passing within a system was the RPC. However, RPCs do not offer the simple elegance offered by today's ORBs. RPCs allow communication between network addresses, while ORBs establish communications between objects (Fig. 2).

An RPC is a simple extension of the traditional procedure call programming facility, which refers to a procedure of a program running on a remote computer. This concept was introduced in the mid-70's in a famous research paper by Greg Nelson from DEC Research Center, Palo Alto, Calif. A client thread calls (with some parameters) a remote server procedure which processes the call and provides a reply to the client thread. The client thread remains blocked until the reply comes back from the server. A RPC facility assumes a homogeneous environment between client/server programming languages and execution environments. However, it can be complemented by standard data representation protocol. For example, the External Data Representation (XDR) standard, in order to accommodate different data representations between clients and servers. RPC is a low-level communication mechanism between procedures, within the context of a given programming language, or a given operating system environment. An example is DCE's RPC.

An ORB is a high-level communication mechanism allowing objects to invoke each others services. The main function of an ORB is to accommodate the differences between the client and server object programming language and execution environments, therefore making heterogeneity transparent. In that respect, ORBs encapsulate the RPC mechanism. A given ORB implementation can take advantage of an underlying RPC mechanism (e.g. DCE). If the communication transport layer used by the ORB does not provide an RPC facility, the ORB will need to implement it by itself, as part of its functions.

For a programmer, an ORB is much simpler to use because the ORB will automatically take care of the adjustment of the client's request to the server execution environment. The only thing that the client needs to know is the high-level definition of the server's interface described in IDL. With RPCs only the communication environment is made transparent.

Bottom line, the ORB communication model is much richer, offering naming (instead of network addresses), security, dynamic adaptation, and other powerful features, while providing a very clear and strict framework.

From Islands To Unification

The move toward a distributed object architecture benefits engineers and companies. By removing concerns about architectural constraints, management can focus on process improvements. Future advanced system software architectures for embedded systems will behave like unified automation architectures rather than isolated islands that need to be integrated together.

The technology can be extended out onto the World Wide Web to allow access to complex software applications via browsers, to assist with such critical business operations as inventory, customer orders, and shipping and delivery.

Distributed objects offer an infrastructure that makes it easy to provide a functional analysis of an embedded system without having to worry about the physical construction of the system. This advantage will reduce configuration costs, enable faster start-ups, and increase the capacity to have more secure and reusable code. Object-oriented embedded systems can extend object technology right down to the instrument level. As suppliers shift their focus from dealing with architecture issues to developing distributed-object application components, they can improve the performance of their customer's installations.

DIAGRAM: 1. In the CORBA model objects communicate over a software bus by references. Any object requesting service is a client, and the object supplying the service is the server. Objects communicating on the same machine would not use the transport network. The network is transparent to objects that use it to communicate between separate computers.

DIAGRAM: 2. The remote procedure call (RPC) differs from the ORB model in that the calling process assumes that the server is identical, in terms of protocols, programming language, and operating system environment. RPCs communicate in terms of network addresses, while ORBs communicate by object reference.

~~~~~~~~

By MICHEL GIEN, Chorus Systems, 1999 S. Bascorn Ave., Suite 400, Campbell, CA 95008; (408) 879-4116.

Michel Gien is co-founder and chief technology officer at Chorus Systems. He joined the Cyclades computer network research team at INRIA (French National Institute for Research in Information Sciences) in 1971. In 1979, still at INRIA, he led a project that introduced Unix in France.

 

The following example shows how to implement a simple distributed service using CORBA. The pro'pose of the service is to allow clients to print messages on a a remote console. This service is provided by a single CORBA objeci representing the console. The interface for this CORBA object is defined in the OMG IDL as follows:

 

interface Console { void print (in string message);

 

The console object will be implemented by a server program. Depending on the ORB, it may be possible to implement the service in a way where the ORB plays an active role in launching the server program. However, for simplicity, we will assume that the server program is started by a means outside of the ORB, and that it will run for the entire lifetime of the service.

 

While the details may differ, depending on the ORB and the object adapter being used, the server program must generally perform the following tasks:

 

• Initialize the ORB and the object adapter.

 

• Create a programming language entity (code and data) incarnating the CORBA object. This entity is called the servant. In this example, the servant will be a C++ object.

 

• Bind an object reference representing the CORBA object with the servant and the skeleton, which the ORB will use to call the servant.

 

• Make the object reference available to clients.

 

• Wait for invocations.

 

A client of the console service must generally do the following:

 

• Initialize the ORB.

 

• Obtain an object reference for the, CORBA object providing the service.

 

• Use this object reference to make requests.

 

The most common, and simplest, way of implementing CORBA programs uses compiler-generated stubs (client) and skeletons. The dynamic invocation interface and the dynamic skeleton interface provide increased flexibility, but are more difficult to use, and usually less efficient.

 

Stub and skeleton code are generated according to a programming language mapping for IDL, in our case the C++ mapping, How this is done depends on the IDL compiler. For the propose of this example we will assume thai: the following four files are generated:

 

console. H - header file for the stub for the Console interface

 

console. C - implementation of the stub, compiled and linked with both client and server programs

 

sk-console. H - header file for the skeleton

 

sk-console. C - implementation of the skeleton, compiled and linked with the server program only.

 

The servant used in the server to incarnate the console object must be an instance of a C++ class, which implements the console interface. Different styles of implementation classes have been specified by the OMG. Here we show one fo the styles supported by the CHORUS/COOL ORB.

 

#include "skconsole.H"

 

//

 

// Implementation class for Console, skeleton inheritance style // class ConsoleImpl : public sk Console { public:

 

void

 

print(const char[*] message, CORBA-Environment&);

 

Using the CHORUS/COOL ORB, the server program's main function could look like this:

 

#include <api/api.h> #include <stdio.h> #include "consoleImpl.H"

 

int

 

main(int argc, char* argv[Lowercase xi]) { // Initialize the ORB and the Object Adapter. CORBA ORB ptr orb = CORBA-ORB-init(argc, argv, 0); CORBA BOA ptr boa = orb->OAinit(argc, argv, 0);

 

// Instantiate the servant incarnating the CORBA object. ConsoleImpl consoleImpl;

 

// Bind the servant to a new object reference. Console-ptr console = consoleImpl.-this();

 

// Export the object reference to the simple COOL naming service. // The CORBA naming service could be used for added portability, // but the example would grow. COOL-NamingServicevar naming = thisCapsu]e->namingservice(); naming->export ("consoleService", console);

 

// Wait for invocations. boa->run(); return 0; }

 

A simple client for writing "Hello World" on the console would look like this:

 

#include "console.H"

 

int main(int argc, char[*] argv[Lowercase xi]) ( // Initialize the ORB. CORBA-0RB-iotr orb = CORBAORB init(argc, argv, 0);

 

// Obtain the object reference from the COOL naming service. COOL-NamingService-var naming = thisCapsule->naming service(); CORBA-Object-ptr obj; naming->import("consoleService", obj); Console-ptr console = Console::-narrow(obj);

 

CORBA-release(obj);

 

// Call the Console service. console->print ("Hello World!\n"); return 0; }

Section: CLIENT/SERVER

Paul Wahl steers SAP toward the Internet

SAP has emerged as the dominant supplier of enterprise resource planning (ERP) software that touches every aspect of enterprise computing. Paul Wahl, president of SAP USA, talked with InfoWorld Editor in Chief Sandy Reed, Executive News Editor Michael Vizard, and Editor at Large Katherine Bull about the company's Internet strategy and alliances.

Where will SAP show up on the Internet?

We've said that there are three elements. One of them is consumer-to-business. We think we've figured out a nice way to get together a very efficient process to take orders over the Internet, ship the product, [and] collect the money. Business-to-business is the other space we are interested in. We said last year that business-to-business is a domain that we were late [in entering]. The third one is the intranet. We need to make sure that our information is being shared with many users in an enterprise or even beyond the enterprise.

I think that on the Internet we can show that with push technology you can get information from this computer to the right people at the right time in the right place. Those are the three cores, and in each of them we are in full deployment and ongoing development.

So the push technology is internally developed? Or are you working with one of the major push vendors?

We're sitting on top of it. We do not have our own push technology.

Will there be a future version of R/3 that will be optimized with push features?

Yes. We already have business workflow integrated in our system. The next step is pushing our processes over mail systems so everything that sits on top of MAPI [Messaging API] or our mail interconnect is a logical extension. In regards to systems integration, I think we will have a business-to-business solution developed as a logical extension of our EDI [electronic data interchange] concept to make sure that it runs on top of a number of zze-business' [electronic-business] infrastructures, whether that's Microsoft, Netscape, or IBM.

How big a threat is Oracle as a competitor in the ERP space, and what is SAP's relationship with Oracle?

It's getting stronger and stronger all of the time. They recognize how important we are for them. SAP has about 30 percent of the business; Oracle [has] about 10 percent. In the license business, SAP is eight to 10 times larger.

Must SAP enter the database business?

No. Databases will become a commodity; they'll eventually become a feature of the operating system.

What's the status of the SAP-Microsoft relationship?

We're neutral on platforms; we don't have a preference. Customers can choose whatever works best for them. As memory becomes cheaper, we'll probably rely on Windows NT even more. About 45 percent of our new shipments are on NT now.

Where does SAP stand on the CORBA/DCOM debate?

We started our development with Microsoft and OLE years ago. Today, we exploit more of DCOM [Distributed Component Object Model] than CORBA because they have more components. The opportunity for us is to source components that we can make cooperate and be part of our environment without development. And wherever we get more of them faster is where we'll go.

PHOTO (COLOR): PAUL WAHL: Oracle recognizes how important we are . . . databases will eventually become a feature of the OS.

~~~~~~~~

By Sandy Reed, Michael Vizard, and Katherine Bull

Section: CLIENT/SERVER

The smooth business and technology relationship between SAP and Microsoft may hit some bumps in the future as both companies struggle for control of enterprise-software standards.

The two companies are doing great business together: Nearly 45 percent of SAP's R/3 sales are on Windows NT, as are almost 28 percent of all existing R/3 sites.

However, earlier this month at SAP's Technology Days developer conference, in Karlsruhe, Germany, Microsoft Chairman Bill Gates positioned client/server applications such as SAP's R/3 as just one element within a software infrastructure linked by Microsoft's Common Object Model (COM). Gates' presentation clearly raised hackles with some SAP executives present.

Speaking after Gates, Karl-Heinz Hess, SAP executive vice president of system technology development, took pains to stress SAP's commitment to the Object Management Group's CORBA standard, the rival object technology which promises similar software integration but without a Windows-centric view of the world.

Hess was quite clear on where SAP and Microsoft part company.

"Microsoft wants to get into the infrastructure business; [SAP] does not want to be locked into somebody's strategy," Hess said. "We want the possibility of working with other partners and other platforms. I'm not sure that COM should be the only technology we should use. For 25 years, we have done most of the middleware ourselves. I'm not sure we should lose this."

There is a certain irony in SAP crying foul at Microsoft's attempt to control software fundamentals. The company has established dominance in it own market space -- much as Microsoft has with Windows -- and now has a vehicle to extend that dominance outward to other software developers through its Business APIs (BAPIs).

These interfaces that let developers hook their applications into R/3 specify both business and technology processes, and could provide SAP with formidable power in the market for business applications.

The challenge facing SAP in limiting Microsoft's object model stronghold is that the competing CORBA standard has not generated enough momentum to produce a single, dominant object request broker (ORB) that could go head-to-head with Microsoft.

SAP is pinning its hopes on IBM to save the industry from a world in which only Microsoft can provide a coherent object model.

"I guess that IBM will galvanize the CORBA guys into providing value," Hess said.

For at least one analyst, SAP's position on CORBA is full of contradictions.

"SAP has come out with varying statements," said Helmuth Gumbel, managing partner of Strategy Partners International, a consultancy in Scuol, Switzerland. "First it was, we'll support DCOM and CORBA on an equal basis, but it was lip service. As long as Microsoft didn't blunder, they couldn't avoid DCOM. Now they say they'll concentrate on DCOM and support CORBA with Visual Edge."

In August, the company announced that it would work with Visual Edge, a Canadian software vendor with technology that will provide a common interface to different ORBs.

"What the ERP [enterprise resource planning] vendors are going through is kind of a microcosm for how developers must approach this [object model] choice," said John R. Rymer, director of Upstream Consulting, in Emeryville, Calif.

SAP AG, in Walldorf, Germany, can be reached at http://www.sap.com.

DIAGRAM: SAP's Business Application Programming Interfaces (BAPIs)

~~~~~~~~

By Michael Parsons

Stannie Holt contributed to this article.

Section: TEST CENTER ANALYSIS

Distributed onject infrastructure

The Object Management Group and Microsoft are trying to elbow CORBA and DCOM past each another, but neither packs the one-two punch of a complete specification, implemented completely.

As a pioneer of part standardization, Samuel Colt might have appreciated the idea of component software. But however visionary Colt may have been, it is doubtful he ever imagined a lock in Chicago, connected to a stock in Los Angeles, firing a bullet down a barrel in Denver.

For some, distributing and interoperating standardized software components across a network may be a solution looking for a problem (see Enterprise Computing, page 113), but as we move toward increasing componentization and "assembly-line" creation of applications, the logical direction for enterprise computing is toward a standard communication interface for disparate object types on a heterogeneous mix of platforms.

A COMMON LANGUAGE. The challenge of object-based distributed computing lies in building a system that lets software objects transparently communicate and use each other's services, whether the objects are located in the same address space, in different address spaces, or on entirely different machines. Without a way for objects to call one another across a network -- an object bus -- applications are bound to the desktop.

At the crux of discussions concerning object-based distributed computing are two object-bus technologies -- the Object Management Group's (OMG's) CORBA and Microsoft's Distributed Component Object Model (DCOM). The question, of course, is which technology offers a more strategic object platform.

Until fairly recently, you could rely on conventional CORBA-vs.-DCOM wisdom to help you choose what to use and when. CORBA had very little existing desktop presence, so rolling CORBA out to a large user base promised to be an expensive, time-consuming proposition. DCOM, on the other hand, was to be (and is) included in Windows NT 4.0 and is downloadable as an addition for Windows 95. On the server side of things, however, DCOM was available only on NT, and so there was no easy way to put Unix objects on the bus. In contrast, a CORBA object request broker (ORB) was available for almost every important server, and client, platform in existence.

THAT WAS THEN. Things are a little different these days. In the middle of last year, Netscape Communications and Visigenic Software announced a licensing agreement for Netscape to include Visigenic's Java-based VisiBroker ORB in Communicator and SuiteSpot, giving CORBA (or at least Visigenic's version of it) a relatively instantaneous, large user base. Moreover, VisiBroker complies with the CORBA Internet Inter-ORB Protocol (IIOP), which gives it the capability to interoperate with other vendors' IIOP-compliant ORBs.

Microsoft, in turn, has shored up DCOM's platform support by licensing the technology to Software AG, Digital Equipment, and Hewlett-Packard. Software AG has begun shipping EntireX, a DCOM port for Sun's Solaris 2.5 operating system. It is also shipping beta versions of DCOM for Linux 2.0 and Digital Unix 4.0, and the company is planning to release versions for HP's HP-UX, IBM's OS/390, AIX, and OS/400, SCO's UnixWare, Digital's OpenVMS, and Siemens-Nixdorf's SINIX. Digital plans to include DCOM in Digital Unix and OpenVMS, and HP is porting it to HP-UX.

For the truly ambivalent, or for those whose IT strategies necessarily include both CORBA and DCOM, several vendors, including Iona, HP, Digital, and Sun, have developed CORBA-to-DCOM bridges. Finally, the OMG expects to have its COM-CORBA interworking specification adopted soon.

CORBA: DESIGNED FOR THE ENTERPRISE. The CORBA 2.1 specification is a product of the OMG, a consortium comprising more than 760 organizations. CORBA's strength lies in its cross-platform and cross-language capabilities. ORB products support the majority of platforms available on the market, and most commercial ORBs support multiple programming languages, including Ada, C, C++, Cobol, Java, and Smalltalk.

Because the OMG provides vendors with specifications rather than implementation details, all ORBs are not created equal. Some ORB vendors include proprietary extensions to their products, and to take full advantage of those extensions, developers may have to sacrifice cross-ORB interoperability and portability.

CORBA gives a multitier environment an object-oriented programming paradigm. Every application under CORBA, whether running on the client side or server side, is treated as an object. Because server objects can call client objects and vice versa, the traditional distinctions between client and server become blurred.

The central element of the CORBA architecture is the ORB, which passes client requests to, and returns results from, server components locally or remotely located. To a client object, the location of a server object should be transparent. As with DCOM clients, CORBA clients communicate with server components through interfaces that store server components' invocation methods and available functions. These interfaces are defined in the interface definition language (IDL).

To ensure interoperability across languages, operating systems, networks, and ORBs, the OMG provides standard IDL language mappings, such as data-type mapping and exception-handling mapping to increase code reusability. CORBA also supports implementation inheritance, which allows one interface to be derived from another interface and inherit the interface's implementations.

CORBA allows a client component to statically or dynamically invoke a server component. Using static invocation, a client has to specify which server component it would like to invoke and which functions under the server it would like to call. Using dynamic invocation, instead of knowing the server component interfaces in advance, a client discovers a server object at run time through CORBA's Naming Service or Trader Service. Then, it dynamically invokes the server's methods. Compared to static invocation, dynamic invocation offers more flexibility because ORBs can offer new services and interfaces whenever they become available. On the other hand, dynamic invocation is more complex to program and its performance is slower.

To solve CORBA 1.0's interoperability problems, CORBA 2.0 provided a solution: Every CORBA 2.0-compliant ORB either supports IIOP or provides a bridge that translates from one ORB to another. Furthermore, ORBs create a unique reference (called an Interoperable Object Reference, or IOR) for each object. Based on IORs, CORBA applications can find objects located anywhere across the network.

Although not uniformly or particularly well implemented among all ORB vendors, CORBA's security specification provides a more complete security model than that of DCOM. CORBA's security service provides authentication, authorization, encryption, security domains, and even audit services to track the security activities on the network. There also are security interfaces that allow the manipulation of security options from within a client application, and administrative interfaces that allow manipulation of ORB's access-control policies.

In a Distributed Component Environment (DCE), a client may call another object, which may in turn call other objects. CORBA allows administrators to set up an access decision for each calling point that limits this delegation. CORBA's security service allows administrators to choose to audit events by object, object type, operation, and time.

Besides the mechanisms that let objects request each other's services, the OMG also provides specifications under CORBAservices and CORBAfacilities for managing and manipulating objects in the CORBA environment. However, since CORBAservices and CORBAfacilities are not required for CORBA compliance, different vendors may implement different services and facilities. For the most part, the ORBs we tested functioned purely as object brokers, passing requests and returning results. As such, they provided minimal performance monitoring, load-balancing, or fault-tolerance.

TESTING CORBA. Learning the IDL is not difficult, but getting familiar with a command set provided by an ORB vendor can take some time. Working with multiple ORBs compounds the problem, because different ORB vendors may implement different sets of commands. Unlike what Microsoft does for DCOM, most ORB vendors do not provide productivity tools for creating CORBA components except the IDL compiler. The compiler comes with an ORB and generates the client stub and server skeleton based on your IDL code. For client and server component development, generally you will use third-party development tools that compile the same language the ORB uses.

We found that two ORBs from the same vendor running on different platforms communicated well with each other, and we had no trouble calling objects between them. On the other hand, to get a client application on one vendor's ORB to call an object on another vendor's ORB was a little tricky, and we needed to program differently. Specifically, we had to obtain the IOR from the called object's ORB first, use the vendor-provided Naming Service to register the object, then use the same Naming Service to call the object. We thought this would begin to get tedious with a large number of objects.

DCOM: STRONG TOOL SUPPORT. DCOM, Microsoft's distributed-computing strategy, was developed based on the Open Software Foundation's DCE Remote Procedure Call (RPC) protocol. DCOM is an extended version of Microsoft's Component Object Model (COM), which is the foundation technology for ActiveX. The main difference between COM and DCOM is that COM components run on a single machine, whereas DCOM components can be distributed across a network. Despite DCOM's availability on non-Windows platforms, limitations on these platforms make it more useful for Windows environments.

One of the advantages of DCOM is the quality and variety of tools available for creating COM and DCOM components -- C++ tools such as Microsoft Visual C++ and RAID tools such as Microsoft Visual Basic, Delphi, and PowerBuilder. Furthermore, there are a large number of prebuilt, off-the-shelf ActiveX components commercially available.

Like CORBA, DCOM takes an object-oriented approach, with all applications referred to as objects. Under the DCOM environment, client applications communicate with COM objects only through interfaces that contain an array of pointers to available functions under an object.

In COM and in DCOM, interfaces are the key. Components are just the implementations of interfaces. A component can be transparently removed and replaced with another component if the new component supports the same interface. DCOM supports interface inheritance, which means that an interface can be derived from another interface, but the derived interface cannot inherit the components available under the original interface. DCOM does let you reuse existing components by passing another object's interface pointer to clients.

Every object must be registered on the local machine for the client to find the object through its Globally Unique Identifier in the registry. Like CORBA, DCOM supports both dynamic and static object invocation, but the implementations are a little different. Under CORBA, the interface implementation is the same, regardless of the invocation method. DCOM, on the other hand, supports dual interfaces for objects; the different invocation methods need different interface implementations.

To use static invocation, we defined an interface and its components and let Visual C++'s Microsoft Interface Definition Language (MIDL) compiler automatically generate the proxy and stub code that connects to the components. DCOM supports dynamic invocation through the type library, which includes files that describe a component. Client applications obtain interfaces at run time through a COM interface, called IDispatch. The advantage here was that, instead of defining an interface manually and using MIDL to generate proxy and stub code, we were able to use the default IDispatch proxy-stub code.

Both CORBA and DCOM support multithreaded servers. In CORBA, initiation is not necessary before creating a thread; everything is handled by the ORB through an object adapter. DCOM, on the other hand, requires you to initiate COM libraries that are used by threads.

Like CORBA, DCOM also allows existing client and server applications to be distributed across a network by registering and configuring them on the host. To do this, you can use a DCOM configuration tool included with Windows NT, or OLEView, supplied with Microsoft Visual C++ and the Win32 Software Development Kit.

DCOM uses Windows NT's security framework rather than providing its own. For non-NT Windows platforms, DCOM will use the security mechanism available on those platforms and provide a Windows NT-compatible security provider. DCOM provides Access Control Lists, which store users' and groups' access rights for particular components. These lists can be configured using a DCOM configuration tool or by calling the Windows NT registry and Win32 security functions from within a program. DCOM also provides APIs and interfaces that components may use to perform their own security checking. The default security checking will be used if neither client nor server component implements any security checking.

There is no automatic fault tolerance or load-balancing under DCOM. To address these two critical enterprise issues, the Microsoft Transaction Server (MTS) sounds like the most attractive solution compared to the other options suggested by Microsoft because MTS provides transaction rollback and load-balancing features.

If you want to make a go of it without MTS, Microsoft provides a pinging protocol that lets a client detect if a connection to a server still exists or not. If a dead server or broken link is detected, an intelligently designed client can reconnect to the server and deal with lost or inconsistent data, if necessary. But in practice it can take a long time to retrace a program and manually recover data, and a large number of objects pinging each other across the network could introduce significant overhead.

A second possible solution is to install your server components on two different machines and have your clients connect and issue requests to both.

LEARNING GROUND. DCOM is not particularly easy to learn, especially for developers without any OLE background. Even with OLE experience, it may take a while to fully understand exactly how DCOM works. Fortunately, Microsoft provides a great tool, Active Template Library (ATL) for creating DCOM and COM objects.

Through the ATL COM AppWizard, Visual C++ generates most of the behind-the-scenes processes, such as proxy and stub code, and creates necessary COM classes. Through the ATL ObjectWizard, you can select the type of COM objects to insert and configure the object's attributes, such as thread model, interface type, and component aggregation. The wizard then generates more C++ code based on your configuration.

We found that using the wizards let us focus our efforts on implementing component details based on business problems, which shortened the development time. The wizards were also a learning tool; studying the generated code help us learn how COM and DCOM works.

Results at a glance

The Internet-intranet boom has brought distributed object computing back into focus for a lot of people, and riding especially high on this renewed wave of interest are vendors of CORBA- and Distributed Component Object Model (DCOM)-based products. The choice of which to standardize on is not obvious for any except shops that are all Windows 95, Windows NT, or Unix. To further complicate issues, third parties are now porting COM to non-Windows platforms, and strategic licensing agreements are landing CORBA on many more desktops than has previously been the case.

Hoping for a little clarity, we used Microsoft's Visual C++ 5.0 and Windows NT 4.0, Iona's Orbix 2.0 on NT and Sun Solaris, Visigenic's VisiBroker for C++ on NT and Solaris, and IBM's System Object Model 3.0 on NT to poke under the hoods of DCOM and CORBA. We did not set out to conduct a comprehensive evaluation of DCOM and CORBA products, but we got a good sense of the state of the art of the technologies from these established products.

We found that CORBA is a powerful technology for application integration. But if it is to maintain its temporal, if not technological, lead against DCOM, CORBA vendors need to implement the standards faster than they have been. If not, CORBA will be a great technology that no one wants to use.

As for DCOM, Microsoft's allegiance to developers promises to maintain the primacy of COM-based technologies in a great many installations. But without seeing DCOM fully supported across a large number of platforms and provide a better environment for mission-critical applications, we don't believe it is the best choice for enterprise computing yet.

CORBA

Core technology

CORBA leaves little to ask for, and the Object Management Group is rapidly incorporating the missing elements. Language bindings are all but complete, integration with other object buses are around the corner, and development of application frameworks is under way.

Quality of products

Most ORB vendors have done a good job of implementing basic CORBA functions, and the overall platform support can't be beat. But service implementation is still a mixed bag. Most development tools we have seen don't compare well to their Windows counterparts.

(1) Broad platform support -- ORBs implemented on a large number of operating systems

(2) Strong programming language support -- ORBs span all the main languages

(3) Local/remote transparency -- objects can invoke services without needing location details

(4) Static or dynamic method invocation -- ORBs support both

(5) Implementation inheritance -- one interface can inherit another's components

(6) Strong security -- Authentication, authorization, encryption, security domains, and audit services

(7) Reliable cross-ORB behavior -- ORBs interoperated well on different platforms

(8) Multithreaded server support

(9) No initiation necessary for multithreading

(10) Strong fault-tolerance and load-balancing specification

(1) Proprietary extensions to CORBA -- vendors may add nonstandard features that may sacrifice interoperability and portability

(2) Lack of full specification support -- products could go further to supply CORBA-specified services

(3) Large command sets -- learning an ORB vendor's particular commands can be a significant time investment

(4) Nonstandard command sets -- ORB vendors may implement different commands, which compounds the learning headaches in a multi-ORB environment

(5) Lack of development tools -- many ORB vendors don't provide productivity tools for building components

(6) Less-than-straightforward ORB-to-ORB interoperation -- getting a client application on one ORB to call an object on another ORB took more work than we liked

DCOM

Core technology

COM is a solid desktop technology, and its popularity is understandable. But distributing COM objects raises complications that are not well addressed, including the reliance on the operating system for authorization.

Quality of products

The fact that major tool vendors have focused so much attention on making their development frameworks attractive and easy to use is a boon for DCOM developers. Wizards make the jump from COM to DCOM development a lot less painful.

(1) High-quality development tools -- many Windows developers will feel right at home

(2) Handy Microsoft wizards -- they make it easy to generate proxy and stub code and to add COM objects

(3) Large selection of commercially available ActiveX components -- the prevalence of Windows on the desktop has insured that independent software-component developers will think twice before deciding against developing for this platform

(4) Static or dynamic interface support -- developers can take their pick depending on an application's performance and flexibility requirements

(5) Local/remote transparency -- clients can remain blissfully ignorant of server locations

(6) Includes multithreaded server support

(1) Limited operating system availability -- currently, only Windows NT 4.0, Windows 95, and Sun Solaris 2.5 are supported

(2) Interface inheritance only -- an interface can derive from another interface, but the derived interface does not inherit the components available under the original

(3) Different interfaces required for static and dynamic invocation

(4) Initiation of COM libraries required for multithreading

(5) Lack of robust fault-tolerance and load-balancing features --Microsoft offers work-arounds, but the Microsoft Transaction Service is what's needed

(6) Steeper-than-expected learning curve -- good tools notwithstanding, DCOM takes some getting used to, and OLE newbies will find it a challenge

Analysis contents

92 Creating CORBA interfaces

92 CORBA architecture

94 Overview of COM/DCOM

94 Requesting CORBA object services: Interface definition language and bus architecture assure location transparency.

96 Software AG's DCOM porting schedule

96 Developing DCOM interfaces: Wizards and other polished features ease DCOM development.

96 ORB vendors and products

96 Requesting DCOM object services

Exclusively on InfoWorld Electric: Go to http://www.infoworld.com/printlinks/

Creating CORBA interfaces

CORBA development reflects architecture

The method for building a complete CORBA application that uses static invocation reflects the fact that the client needs prior knowledge of the object services it needs to use. So, the client-side and server-side code are compiled and linked to the client stub and server skeleton code in one step.

CORBA architecture

CORBA defines multiple interface types for flexibility

One of the main objectives of the CORBA specification is to provide integration among multiple flavors of client and object implementation. As such, the Object Management Group has placed a heavy emphasis on the standardization of static and dynamic interfaces rather than on specifics of the implementation of the object request broker (ORB) itself.

Overview of COM/DCOM

DCOM provides local/remote transparency for remote servers

Using Component Object Model (COM), clients can access either in-process or local cross-process server objects transparently. Distributed COM (DCOM) adds the capability of calling server objects on remote systems through a remote object proxy and Microsoft's Object Remote Procedure Call (ORPC). Local cross-process calls are made through an operating system-dependent interprocess communication. Like CORBA, DCOM supports both static and dynamic method invocation.

Requesting CORBA object services

Invoking methods using CORBA's static invocation interface

Interface defination language (IDL) stubs and skeletons define CORBA's static mode of invoking objects and accessing their services. Unlike the dynamic invocation interface, which lets clients specify services at run time, static interfaces are defined at compile time. But because it is easier to understand and a more natural invocation procedure, many developers may choose static invocation over the potentially more flexible dynamic method. The diagrams below illustrate static invocation on a single object request broker (ORB) and from one ORB to another. It is important to note that, as with Distributed Component Object Model, the system maintains object location transparency.

Requesting DCOM object services

Invoking methods using Distributed COM

Instantiating a class (also called creating an object) is required before invoking its methods, and to do this, the Component Object Model (COM) library needs to be located on the client. The COM library does not ship with Windows 95, but it can be downloaded from Microsoft's Web site. It is included with Windows NT 4.0.

Developing DCOM interfaces

Visual C++ wizards simplify interface creation

Two of Microsoft's development wizards make building Component Object Model (COM) objects an easy task. The ApplWizard generates a basic skeleton and lets you add your own interface definition language (IDL) code as needed. The ObjectWizard helps you assemble COM object members before final compilation.

Software AG's DCOM porting schedule

Microsoft, the Open Group pave way for DCOM on Unix

With the Open Group now controlling the Distributed Component Object Model (DCOM) specification, a number of Unix vendors, most notably Software AG, are taking the opportunity to widen DCOM's platform presence.

Legend for Chart:

A - Platforms
B - Expected general availability

                              A                  B

Software AG Americas          Sun Solaris        Now

http://www.sagus.com          Digital Unix       End of October

(703) 860-5050                OS/390             End of November

                              AIX, HP-UX, Linux  End of December

                              OpenVMS, OS/400,   1998
                              SINIX, UnixWare

ORB vendors and products

Purveyors of CORBA-compliant ORBs multiply

Membership in the Object Management Group has increased by about 50 percent during the past two years, the CORBA specification keeps evolving, and object request broker (ORB) vendors are hustling to keep their offerings current.

Legend for Chart:

A - Vendor
B - Product name
C - URL
D - Phone

A                           B
                            C
                            D

Bea Systems                 ObjectBroker 3.0[1]
                            http://www.beasys.com
                            (408) 743-4000

Expersoft                   CORBAplus line
                            http://www.expersoft.com
                            (619) 824-4100

Hewlett-Packard             ORB Plus 2.0
                            http://www.hp.com
                            (650) 968-5600

IBM                         System Object Model 3.0 Component
                              Broker[2]
                            http://www.ibm.com
                            (520) 574-4600

ICL                         Dais 3.2
                            http://www.icl.com
                            (703) 648-3300

Iona Technologies           Orbix line
                            http://www.iona.com
                            (800) 672-4948

Sun Microsystems            Neo and Joe
                            http://www.sun.com
                            (650) 960-1300

Visigenic Software          VisiBroker line
                            http://www.visigenic.com
                            (650) 286-1900

1. Recently acquired from Digital.

2. Currently in beta testing.

PHOTO (COLOR): 94 Requesting CORBA object services: Interface definition language and bus architecture assure location transparency.

DIAGRAM: Development process for static invocation

DIAGRAM: Structure of an ORB

DIAGRAM: Single-ORB request

DIAGRAM: Cross-ORB request

DIAGRAM: COM object development

DIAGRAM: Creating an object

Section: ENTERPRISE COMPUTING

The complex but idealistic goal of distributed objects -- where a single object model lets you rebuild corporate applications by assembling and buying interoperable objects -- has been blown off course.

That's the good news.

What's happened instead is that pragmatic choices over middleware --Microsoft's Distributed Component Object Model (DCOM) vs. a marriage of Java and the CORBA standard -- have overtaken academic discussions of pure object orientation. And simplified objects, or components in the form of JavaBeans and Microsoft's COM, are rapidly taking over as the software building blocks of choice on the Web.

Although simple components are quickly showing up in tools, surveys of corporate end-users show that large-scale distributed object projects are really not common yet. But users are laying the groundwork to build distributed applications with object middleware.

The problem, analysts and users say, is that DCOM, and to a lesser degree CORBA, are not quite mature enough for mission-critical applications because vendors are just beginning to deliver some key services, such as transactions, application and system management, fail-over, and availability.

Because components are taking over as the programming model of choice and object middleware is where all IT organizations are going, what should an IT architect do today?

The answer, says Roy Schulte, vice president and research director in charge of middleware at Stamford, Conn.-based Gartner Group, is to trust today's middleware and design for the future.

"If you design software for components but use the middleware that is mature today -- such as CICS, Tuxedo or even stored procedures -- then you'll be able to come back and wrapper that code and be able to use that code as components for several more years," Schulte says.

With that philosophy in mind, leading-edge companies such as Boeing and Union Bank of Switzerland, are buying into CORBA in a big way. The users that fall into this camp are typically cutting-edge companies that have a lot of resources to devote to CORBA projects, which may not be wide-scale for several years. Union Bank of Switzerland, for instance, is structuring its software infrastructure around business objects that are tied together by CORBA and message-oriented middleware. But this is beginning a pilot phase that should last six to 12 months.

ASSIDUOUS ATTENTION. For now, users and analysts generally accept that the CORBA camp, lead by the Object Management Group (OMG) consortium, has a head start in object middleware, but Microsoft is coming on fast. Its assiduous attention to developers and its ability to ease programming is paying off. The company's rival component object model, COM, and transport protocol, DCOM, are hard wired into its OSes. Rather than presenting an object request broker (ORB) with a C++ or Java toolkit, Microsoft tries to shield developers from the object infrastructure with tools, such as Microsoft Transaction Server and Microsoft Message Queue Server, aimed at Visual Basic programmers.

Additionally, some analysts and users argue that Microsoft has more deliverables in object services than many of the ORB vendors.

"It's not like Microsoft invented the concept of component architectures or the concept of an n-tier architecture," says Dan Greenberg, CEO and chief technology officer at Visteon, a health care ISV in Maitland, Fla. "The net bottom line is Microsoft is doing better job of managing the rollout of this environment. It's a more consistent vision."

Comments like these, lauding Microsoft's thrust into the distributed systems realm, have had a unifying effect on the company's enemies. In the past year, a long list of software vendors from Oracle to Netscape, have licensed third-party ORBs, usually Visigenic's VisiBroker, and pledged support to the Internet Inter-ORB Protocol (IIOP).

This convergence on CORBA and IIOP is not purely political: Vendors are moving their products to an object-based infrastructure, and CORBA middleware, spawned largely from the Unix camp, can boast enterprisewide scalability, an installed base, and a standards-based approach. Once vendors complete the transformation of packaged application to components, corporate developers can write to these interfaces to more easily modify vendors' wares.

Because vendors are taking sides on whether they will implement DCOM or CORBA to break their software into components, it's clear that both models will exist for at least the next five years. The upshot of these competing object models is that users need to plan for both.

"We see the COM/CORBA interface as a requirement. We need to have an interface between purchase systems, and we're not in control of all the elements of the system," says Tom Hein, manager of technology integration at Deere, in Moline, Ill. "Clearly, Microsoft also has a presence in the products we buy. CORBA provides enterprise services that aren't there yet in COM, so our basic strategy is to make appropriate use of both."

LOW-LEVEL INTEROPERABILITY. The vendors are working on improving interoperability, but the results are likely to only address low-level interactions between objects. Vendors recently standardized a DCOM/CORBA bridge, but the results will likely not appear in products until next year. Also, analysts note that protocol-level interoperability does not solve the problem of choosing one object standard over another.

"Interoperability will be at the lowest level," says Ted Schadler, an analyst at Forrester Research, in Cambridge, Mass. "We're not talking about object bridges, we're talking about service bridges. Do the CORBA transaction service and Microsoft transactions work together? No, maybe someday, but it will be lowest common denominator."

Some CORBA critics note that interoperability between competing ORBs --the main purpose of IIOP -- is hardly seamless. For this very reason, the OMG says it will initiate branding services in the form of a test suite set for December release and administered by the Open Group.

Meanwhile, Microsoft has its own plan to provide cross-platform interoperability by porting DCOM to non-Microsoft platforms. Microsoft partner Software AG recently released DCOM on Sun Solaris and will ship DCOM on OS/390 in December, but users note that several tools and services are lacking cross-platform DCOM.

Microsoft Chairman Bill Gates acknowledged that Microsoft's perceived lack of commitment to cross-platform DCOM is a "big issue" and said that the company will support DCOM on Unix and MVS.

Although infrastructure questions such as interoperability are critical to object-middleware adoption, what's holding users back is server services and better development tools.

"One of the biggest decisions to be made is not the ORB itself but the CORBA services it has," says Joe Carroll, assistant director of systems architecture at UBS, in London, who says that security, transactions, naming, and events top his wish list. "Also we need to know the details of the implementation in terms of queuing and events architecture."

Carroll notes his CORBA choices are growing. UBS does not need to buy into an ORB vendor, such as Visigenic or Iona, to build a CORBA system because many middleware vendors are entering the ORB fray. For example, BEA Systems Tuxedo and Tibco's message-queuing software are being modified so that services are exposed with CORBA, JavaBeans, or COM interfaces, paving the way for end-users to introduce more object programming in-house.

MERGING MIDDLEWARE. But even as middleware vendors break into the ORB market and Microsoft rolls out its own wares, the merging of multiple middleware functions is still a work in progress.

"All of these tools, like IBM's Component Broker or the TP [transaction-processing] monitors with ORBs -- none of it is all delivered. Nobody has all the pieces yet, and CORBA doesn't have it all. So it leaves people in a valley," says Sally Cusack, market analyst at Software Productivity group, based in Natick, Mass.

Some users are taking a "wait til objects are ready" view. Retailer and manufacturer The Timberland, in Stratham, N.H., has already bought into IBM's MQSeries. The company plans to integrate distributed object technology as its manufacturing application and message-queuing software make the shift.

"I think [object analysis and design] is great, but it's a big, big mind shift when you have a traditional, non-object-oriented environment," says Dan Grosz, director of business system planning at The Timberland. "The whole life cycle product development changes, not just coding."

But what's really holding up wide-scale adoption of objects is the availability of business objects that are specialized to a specific industry, Grosz says.

"We need objects that we can readily use," Grosz says. "I don't think a company like Timberland will be in pioneering position with almost unlimited resources. If we can buy and sell them, then it makes business sense."

Progress in building business-specific objects is under way.

While the OMG is moving ahead in defining more technical services and promoting ease of use in the CORBA 3.0 specification, the consortium has been signing on end-user groups to help define industry-specific objects. And as Microsoft's COM dominates desktop and packaged applications, these vertical industry groups are also working with Microsoft.

"We're working with both the OMG and Microsoft," says Kevin Schipani, group manager of research and development at the Agency Company Organization for Research and Development, an insurance industry group in Pearl River, N.Y. "We want to broker between them to implement universal standards for the insurance industry. We're extending COM with custom interfaces for insurance with our object model in UML [Unified Modeling Language], so we'll can generate IDL [Interface Definition Language] as well."

These efforts promise a big payback by letting corporations share data with partners over the Net and by promoting a third-party industry of off-the-shelf business objects.

But that's a long-term view. Analysts say that simplified components, slung together with high-level tools, is where the action is at in the near term.

"Any time you see a Web-enabled application, there's very likely a distributed object running somewhere on a server," Forrester's Schadler says. "It's component platforms. The technology formerly known as distributed objects hasn't gone away, it's just changed its spots."

And for deciding which object model is strategic, Gartner's Schulte says a user's operating environment determines a lot.

"There are huge debates about which object model is better, but in the end it's not going to matter ... The Microsoft world is integrated from top to bottom for better or for worse, but if you're looking to talk to Unix servers and mainframes, there will be a variety of tools from CORBA vendors," Schulte says. "Pick an OS, and I'll tell you what object model to choose."

What kinds of middleware are you deploying?

Legend for Chart:

A - Now
B - In two years

                                               A               B

Remote Procedure Call                         42%            28%
Transaction-processing monitor                42%            52%
Messaging                                     60%            70%
Distributed objects                           26%            74%

Results of 50 Fortune 1000 companies interviewed.

SOURCE: FORRESTER RESEARCH

~~~~~~~~

By Martin LaMonica

Ted Smalley Bowen contributed to this article.

 

Distributed objects and components represent a major programming shift, but it's clear that the dawning of the component age will not come at the expense of existing systems.

 

"We're in no position to take a big bang approach [to our transition to CORBA]," says Joe Carroll, assistant director of systems architecture at Union Bank of Switzerland, in London. "We can't deploy applications before it's proven that the [infrastructure] is proven to be resilient and robust."

 

The company plans to write a series of new CORBA business objects that can be triggered by events, but its plans include pulling in its existing mainframe applications and entrenched relational databases.

 

The lack of good tools to tie in relational databases kept the U.S. Department of Transportation from building its electronic grants project in a pure CORBA environment.

 

"We wanted to use CORBA, but CORBA is not ready for prime time," said Brad Smith, electronic grants project manager for the Department of Transportation, in Washington. "Either you have to have object databases or do a lot of extra work."

 

For those users who are not willing to buy into high-end middleware but want to dabble in objects, "wrappering" existing applications with component interfaces is living in both worlds.

 

"People are using good enough technology like HTTP and the Web and kludging things together like server-side management and state management," says David Smith, an analyst at the Gartner Group, in Stamford, Conn. "There's lots of talk of CORBA and DCOM [Distributed Component Object Model] to lessen those problems, but there are other ways that may not be as robust, but they're less risky."

 

Although the computer industry is no stranger to shotgun weddings, JavaBeans and CORBA's impending nuptial seems odd at first blush, but upon closer examination reveals not only a technological alliance, but a savvy marketing move.

 

JavaBeans is the logical extension of the Java platform. Java's object-oriented nature makes it a prime candidate for a component architecture. JavaBeans provides the necessary services for Java objects to interact.

 

In broad terms, take an object in Java, provide it an interface that allows communication with other objects, hide unnecessary details, and you have JavaBeans.

 

The inevitable question is whether the world truly needs another component model, especially given that Component Object Model (COM) and CORBA have a significant head start. To answer this, a subtle distinction needs to be drawn between a component architecture and a distributed object architecture. The two are frequently used interchangeably, but there is a subtle difference.

 

A component model is a system for self-contained chunks of software code to interact, providing the building blocks for an application.

 

A distributed object model allows for those same software building blocks to exist on separate computer systems and operate over a network.

 

So where does JavaBeans sit in the whole component model world? JavaBeans is fundamentally a component architecture for Java. A commitment to JavaBeans implies a commitment to Java itself. Java objects are put inside a JavaBeans "wrapper," which provides a standard interface for components to communicate with each other. It provides a method for one bean to query another bean and pass information, while at the same time, hiding some of the inner workings of the bean that aren't relevant to their usage. JavaBeans then communicate with each other over a network using Java's Remote Method Invocation.

 

On many practical levels, JavaBeans mimics other distributed object models and component architectures, such as CORBA and DCOM.

 

But JavaBeans doesn't provide for non-Java components. Although it is possible for Java components to make calls to non-Java components, JavaBeans relies heavily on the Java Native Interface, making communication outside Java cumbersome at best.

 

For some developers, a commitment to Java isn't a problem, but others will balk, having already made considerable investments in other systems, or they are simply unwilling to walk down the aisle with Java.

 

Hence, the movement toward integrating JavaBeans and CORBA. CORBA provides a robust system for dissimilar components to communicate with each other. Much of Java's abstraction is similar to CORBA's, making the two seem like a perfect match.

 

Essentially, those who tout the CORBA-JavaBeans convergence, notably IBM, Netscape, Oracle, and Sun, see CORBA as the bridge between components, with Java providing portable components that can exist on multiple systems.

 

And there are some lingering concerns about CORBA and JavaBeans integration. For one, it's difficult enough to get different CORBA object request brokers to cooperate, and it is unclear whether JavaBeans might ease or exacerbate the problem.

 

~~~~~~~~

 

By Sean Dugan

Section: CLIENT/SERVER

At its recent member meeting in Dublin, Ireland, The Object Management Group (OMG) made progress toward expanding its core CORBA technologies, advancing its business object frameworks initiative, and shoring-up CORBA interoperability with Microsoft's competing Common Object Model (COM). (See "OMG to address modeling, DCOM bridge," Sept. 15, page 3.)

Also at the OMG meeting, the groups newly appointed Chairman and CEO, Richard Soley, emphasized the need to maintain CORBA's language and platform independence, even while working to support key technologies such as Java.

While underscoring the group's strong commitment to supporting Java, Soley stressed that the CORBA platform and services would remain open.

OMG members reacted negatively to a recent suggestion to replace CORBA Interface Definition Language (IDL) with Java, Soley noted. CORBA IDL links client and server applications to CORBA ORBs, and includes mappings to a number of languages.

"I don't want CORBA Javaized, because Java is not universal. There are other languages with other models," Soley said. "[But] CORBA should be at least as friendly to Java as it is to other languages. We want the mapping to Java to be as natural as possible."

A Java-to-IDL mapping that allows Java programmers to automatically generate IDL, rather than having to wrestle with the complexities of IDL programming, is on tap for later this year, according to Soley.

At the meeting, the group began final balloting on the adoption of the Unified Modeling Language (UML) and a corresponding Meta Object Facility (MOF) -- an extension of its COM-to-CORBA bridge specification, Part B -- and revisions of its original COM-to-CORBA bridge specification, Part A.

All are expected to be adopted by the end of the polling process, which usually lasts 10 weeks or more, according to OMG company officials.

The UML standard promises to simplify the object analysis and design process by providing a lingua franca for the many analysis and design tools on the market, Soley explained. The MOF provides a means of defining and manipulating application meta models.

Part B of the COM-to-CORBA Interworking specification is an extension of the existing COM-to-CORBA bridge that bolsters performance by leveraging Distributed COM, Soley said. The bridge specification includes a mapping, or translation from CORBA IDL to the COM interface definition language, Microsoft's IDL Compiler, and a protocol to handle communications between the components.

"You can use any protocol you want for connecting CORBA and COM components. You can use IIOP [Internet Inter-ORB Protocol], Distributed COM, or a piece of string with two tin cans, but you have to support IIOP to start with [in order to be OMGapproved]," Soley said.

The OMG cannot contractually obligate vendors implementing the COM-to-CORBA bridge to support IIOP, but could refuse to endorse products that don't, or deny any eventual OMG branding, according to Soley.

Responses to the OMG's requests for proposals of CORBA component model and scripting specifications are due in October, according to Soley. The so-called CORBA beans and CORBAscript specifications, along with objects-by-value support in IIOP, a CORBA messaging service, and multiple interface support constitute much of the CORBA 3.0 update due early next year.

The Object Management Group, in Framingham, Mass., can be reached at (508) 820-4300.

• The OMG meeting, held in Dublin, Ireland, the week of Sept. 22, drew roughly 450 members and guests.

~~~~~~~~

By Ted Smalley Bowen

Historically, `open systems' have meant that the specification and design of a software or hardware architecture is not controlled by a single vendor. In that respect, since Microsoft is solely responsible for developing Windows NT, COM/OLE is not open. CORBA, (the Common Object Request Broker Architecture), on the other hand, is. This standard is being developed by the Object Management Group (OMG), a consortium of software vendors and end users. Many OMG member companies are developing commercial products that support these standards and/or are developing software that uses it.

CORBA provides the mechanisms by which objects transparently make requests and receive responses, as defined by OMG's Object Request Broker (ORB). The CORBA ORB is an application framework that provides interoperability between objects, built in (possibly) different languages, running on (possibly) different machines in heterogeneous distributed environments.

CORBA is the OMG's answer to the need for interoperability among the rapidly proliferating number of hardware and software products currently available today. Simply stated, CORBA allows applications to communicate with one another no matter where they are located or who has designed them.

CORBA 1.1 was introduced in 1991 and defined the Interface Definition Language (IDL) and the Application Programming Interfaces (API) that enable client/server object interaction within a specific implementation of an ORB. CORBA 2.0, adopted in December of 1994, defines true interoperability by specifying how ORBs from different vendors can interoperate.

ORB is the middleware that establishes the client-server relationships between objects. Using an ORB, a client can transparently invoke a method on a server object, which can be on the same machine or across a network. The ORB intercepts the call and is responsible for finding an object that can implement the request, pass it the parameters, invoke its method, and return the results. The client does not have to be aware of where the object is located, its programming language, its operating system, or any other system aspects that are not part of an object's interface.

In so doing, the ORB provides interoperability between applications on different machines in heterogeneous distributed environments and seamlessly interconnects multiple object systems.

Fielding typical client/server applications, developers use their own design or a recognised standard to define the protocol to be used between the devices. Protocol definition depends on the implementation language, network transport and a dozen other factors. ORBs simplify this process. With an ORB, the protocol is defined through the application interfaces via a single implementation language-independent specification, the IDL. ORBs also let programmers choose the most appropriate operating system, execution environment and even programming language to use for each component of a system under construction. More importantly, they allow the integration of existing components. In an ORB-based solution, developers simply model the legacy component using the same IDL they use for creating new objects, then write `wrapper' code that translates between the standardised bus and the legacy interfaces.

With CORBA, users gain access to information transparently, without having to know what software or hardware platform it resides on or where it is located on a network.
Object Management Group
Tel: US +1 508 820 4300
Enter 477

Section: Embedded Systems

Developers today need to be able to set up their own project-specific tool box from the best task-focused tools on the market, using standard communication mechanisms for plug-and-play interoperability. Middleware technologies have been developed for the very purpose of solving the problem of enabling tools from different vendors to interoperate.

The goal is to provide a "middle layer" of task-specific communication between low-level services (such as operating system, socket or remote procedure calls that are too low level for task-specific integration) and high-level tool functionality (that is, typically dependent on the tool). This communication must be task-centric and therefore independent of OS and hardware platform; location (whether the tools run on the same or different workstations, or what network); programming language; and vendor of origin.

The Common Object Request Broker Architecture (Corba) was designed by the world's leading experts on distributed object-oriented computing, who formed the Object Management Group (OMG) to solve the interoperability problem of independently developed applications in a heterogeneous, distributed computing environment. Some 700 companies currently participate in the OMG, making this nonprofit industry consortium the world's largest for software development. Virtually all vendors involved with software development are OMG members, including Integrated Systems Inc.

Two standards

Today, developers must decide between Corba and the other de facto standard: Microsoft's Component Object Model, or COM. After many iterations, COM has become Microsoft's solution to the component-integration problem on the desktop. Like Corba, COM enables independently developed components to collaborate, and it covers the entire spectrum of components from fine-grained objects to coarse-grained existing applications. One of the best-known COM applications is the integration of Microsoft Word and Microsoft Excel within Microsoft Office.

DCOM is a recent extension to COM that3 enables applications on a network to also access COM, and thus replicates many of Corba's benefits. The primary drawback at this point is that COM is essentially fully supported only on Microsoft Windows desktop platforms. Other platforms--Unix, for example--are only partially supported, if at all. Unlike Corba, there are very few non-Windows applications that use COM.

Outside the desktop, and in particular in the embedded market, the consensus so far rests with Corba. For example, various vendors have announced Corba implementations on the target. On the host, embedded-systems developers typically work in a heterogeneous environment that has to be cross-platform and must talk to the target; the types of tool interoperability required for embedded-systems development tools are far less desktop-centric than they might be, for example, when integrating a word processor and a spreadsheet. And so Corba comes out ahead.

Applications that wish to participate in a Corba-enabled development-tool environment expose a set of objects (in the object-oriented sense) on the Corba object bus. The objects are described in terms of interfaces, making them independent of their implementation (such as programming language or physical location).

For example, if a Corba-enabled debugger wants to give other tools access to the information in the file it is currently displaying, it would expose a Corba object to the bus that provides high-level polymorphic operations that other tools can apply on that file. For a file, these operations might include "print" or "get current selection" or, in case of a debugger, "get list of currently active breakpoints in that file."

Independent interface

The interface of that file object seen by other tools is typically independent of the particularities of the tool that exposes the object: for example, knowledge of a particular command language or output syntax provided by the debugger is not required to be able to obtain the list of breakpoints. As long as tools agree on what a breakpoint and a file is (many debuggers do), an application that accesses a debugger-exposed file object does not need to know or care what debugger product from what vendor it is talking to. This independence of the implementation details of the participating tools makes Corba a very powerful integration solution for development tools in general and embedded development tools in particular.

Corba features are important to the tool user because they enable a paradigm shift in the way embedded development tools are developed, packaged and deployed. What we had in the past were monolithic, single-vendor packages that were jacks of all trade, masters of none. What middleware, and in particular Corba, makes possible is to assemble embedded-systems development environments from a set of component tools independently developed by different vendors, in a project- and user-specific fashion.

An example illustrates this point: the communication of host tools to the target. In the past, every host tool had to know the particularities of the communication channel between the host and the target. Changing or augmenting the protocol on this channel was essentially impossible without compromising on the host tools, because these tools depended on the specific version of this low-level protocol.

Corba provides a middleware layer that enables any host tool to talk to any target using any communication mechanism between host and target; Corba encapsulates the particularities and shields clients from having to know them. Also, a communications server can be replaced by another that uses a different underlying protocol; as long as the new server offers the same set of interface definitions as the old, the client will not notice the change.

Core competency

This, of course, enables a tool vendor to focus on its core competency--building advanced embedded-system development tools. Gone is the need to mess around with low-level proprietary protocols whose support is typically expensive while adding no value to the tool offering and distracting from support of the end user.

From a tool user's perspective, this will mean better tools with more capabilities. It also means being able to select the best tools for a given job, because multiple tools are able to alternate on the same place within a Corba environment--tools that truly interoperate because the tool vendors don't have to rewrite point-to-point interfaces and thus can write off tool integration work over multiple tool integrations.

Corba embeds objects

~~~~~~~~

By Johannes Ernst, Staff Engineer Integrated Systems Inc. Sunnyvale, Calif.

Section: NEWS; NEWS BRIEFS

The Object Management Group (OMG) last week in Dublin, Ireland, began final balloting on the adoption of the Unified Modeling Language and a corresponding Meta Object Facility. The OMG is also voting on an extension of its COM/CORBA bridge specification, Part B, as well as revisions to its original COM/CORBA bridge specification, Part A. All are expected to be adopted by the end of the polling process, which usually takes about 10 or more weeks, according to OMG officials.

Section: NEWS

CORBA initiative

The Object Management Group (OMG) next week in Dublin, Ireland, will advance its CORBA initiative with the expected adoption of a key object-modeling language, and the group will assess the latest proposal for the strategically important -- yet politically sensitive -- bridging specification between CORBA and Microsoft's Distributed Component Object Model (DCOM).

At the OMG Technology Committee Meeting, the OMG's 24-member board of directors will vote on ratification of the Unified Modeling Language as a standard modeling language for components. Rational Software, which took the lead on the initiative, last week submitted the latest UML proposal to the OMG Object Analysis and Design task force.

The OMG will also address its recently launched Component Initiative, which intends to yield a component model and standard scripting language for working with CORBA components as part of CORBA 3.0, due in early 1998.

The JavaBeans component model is expected to be the basis of the CORBA component model, and scripting languages ranging from JavaScript, VBScript, and Perl to Tool Command Language and ObjectRexx are expected to be proposed, said Richard Soley, OMG's chief technical officer and acting chairman and CEO.

Also up for vote by the Technical Committee is the much-anticipated Component Object Model (COM)/CORBA Interworking Part B specification, which allows the existing COM-to-CORBA bridge specification to better handle DCOM.

"Part B extends Part A to get better performance, when you have a [CORBA component communicating with a] COM component across DCOM, as an option to IIOP [Internet Inter-ORB Protocol]," Soley said.

The proposal eliminates the restriction of handling DCOM/IIOP translation only on the COM client.

The proposal reflects changes to Hewlett-Packard's original, which stemmed from input by object request broker and platform vendors, including BEA Systems, Expersoft, Iona Technologies, Visigenic Software, and Visual Edge Software.

The latest proposal steers clear of endorsing DCOM, members said.

A draft proposal for adding asynchronous messaging capabilities to the CORBA services was also to be on the docket for the Dublin meeting. That proposal will instead be presented at the OMG meeting in December, Soley said. The COM/CORBA extension and messaging are slated for CORBA 2.2

"Messaging is probably my biggest concern," said Stephen Uczekaj, senior principal engineer at Boeing, in Seattle. "CORBA needs a data-flow-type architecture, which is critical for the development of embedded applications."

The group will also take up the issue of its leadership, after the departure this summer of President Chris Stone. Soley and Acting President and Chief Operating Officer Bill Hoffman are expected to retain their respective posts on a permanent basis, pending board review.

The Object Management Group, in Framingham, Mass., can be reached at (508) 820-4300.

~~~~~~~~

By Ted Smalley Bowen

Section: MIDDLEWARE

Facing stiff competition, the airplane manufacturer revamped its outmoded business processes with the help of Iona's Orbix

It might have been Iridium, Motorola's out-of-this-world effort to surround the earth with telecommunications satellites, that put Iona Technologies on the map. But it was another high-flyer, Boeing's Commercial Airplane Group, that locked Dublin-based Iona into a steadier orbit. While applications such as Hong Kong Telecom's video-on-demand system have been providing flashy publicity for the object request broker vendor, Boeing has had its nose to the grindstone redesigning much of what it does here on the ground using Iona's Orbix product. The project, which the airplane manufacturer calls DCAC/MRM (Define and Control Airplane Configuration/Manufacturing Resource Management), entails a wholesale overhaul of its business processes, from design and production to sales and support.

Back in 1994, Boeing began to assess its outmoded practices in light of future competition. As a 75-year-old company that has had to support millions of parts for the duration of their life cycles, Boeing required a continually maintained database of engineering documents covering every part, model, and design. In the past, such complex data was stored in the form of physical part drawings--not the most easily manipulated or integrated data type. Moreover, every customer demands a plane somewhat different from the other guy's, and revising a basic design in one area often necessitates revisions in other areas. The solution to slow, tangled redesigns seemed to lie in the creation of a computerized database of parts, rather than planes, so Boeing created the Single Source of Product Data (SSPD).

The IT team realized that such a change, while meant to facilitate the design process, would simultaneously benefit sales, engineering, and support staffs, who require easy access to airplane configuration details. Thus began what Iona not so humbly calls "the single largest business process redesign project in the world. "

The plane part, after all, is but one of numerous business concepts that have significance across all of Boeing's departments. Like many such business concepts, it lends itself to an object-oriented approach to programming. This approach, if carried through all relevant applications, can facilitate integration throughout the company, as well as between Boeing and its customers and suppliers. In its search for a long-term, object oriented solution, Boeing decided to go with the industry-standard ORB architecture--Corba--to provide interoperability between applications.

Although Corba was still rather young, Boeing threw in its lot with the Object Management Group (OMG), the ORB industry consortium that created the spec. When Boeing's developers found commercial software packages that they thought were best-suited to each process, they asked the vendors to make their products Corba-compliant. These packages include SDRC's Metaphase for product data management, Baan's Enterprise Resource Planner, and CimLinc's Linkage Computer Aided Process-Planning. As a proof-of-concept step, Boeing's development team tried integrating the off-the-shelf products as single objects by writing definitions in Corba IDL encapsulating large chunks of application functionality. When that worked, they began the long and ongoing process of breaking the applications down into smaller business objects that can be shared across applications.

Because a standards-based ORB struck Boeing as key to future stability, the company chose Iona's Orbix. At that time, "Iona was by far the most Corba-compliant," says Van Cleland, Boeing's application integration product manager. Since buying into Corba, the airplane manufacturer has continued to work through the OMG to push for the added capabilities it sees as vital to ORBs--services such as store-and-forward communications and systems management features. One capability that has been in the works this year is a messaging service, which Boeing strongly desires. Standard ORBs, including Orbix, build in IIOP (Internet Inter-ORB Protocol) communications capabilities, but these are based on TCP/IP's point-to-point style of communicating and are therefore limited to synchronous exchanges. Recognizing this limitation, Orbix provides two further options: OrbixTalk, a value-added implementation of the Corba Event Service, which facilitates decoupled messaging between distributed objects; and bridges to IBM's MQSeries message-oriented middleware (MOM) as well as to PeerLogic's Pipes.

Boeing has embraced both of these add-one, using OrbixTalk as a store-and-forward mechanism for asynchronous messaging, and the MQ link for yoking-in legacy systems. "We have quite a few computing systems in place that will be in use for quite some time during the transition," says Cleland. "In fact, some will never go away. And we need to interface with those systems."

At the time Boeing began its project, there was no MVS product from Iona to support legacy links without additional MOM. But that's about to change. Iona has built gateways that allow Orbix to take programs that look like objects on the network, convert them into Cobol code, and send them over to Cobol applications. In a further foray into the mainframe world, Iona is currently beta-testing Orbix bridges to IMS and CICS transaction processing monitors. "We see that as a huge market," says Iona CTO Annrai O'Toole. "The mainframe is here for good. Corporations understand the value of making those systems into peer entities in their networks so that Java applets can call them. Our high-end customers want the mainframe as a client of Unix."

In addition to its array of messaging options, Orbix offers Boeing a multitasking capability, which enables the company to do what Cleland calls "dispersing--where we send to, dial up, and utilize multiple servers at once rather than a single server. " But despite Orbix's plethora of useful features, Cleland claims that his team chose the ORB primarily because it was a "lean implementation.

"They don't build in a whole bunch of extra features you have to take along, with a lot of overhead," he says. "You can use them if you like, but you can also use the ORB just as an ORB."

Still, there are features that ORB makers will all need to develop, Cleland remarks. Like other ORB vendors, "Iona is realizing that the ORB isn't a toy anymore; people are using it as a production product, and it has to be supported as a production product. Things like system management capabilities, security--those capabilities are required in the real world." If ORBs are going to play leading roles in distributed computing systems, they will have to behave more like robust, sturdy, ever-dependable transaction processing monitors, notes Cleland.

If you ask O'Toole, Iona is ahead of the pack on that front. He maintains that his firm understands that the IT world has moved to a network-centric infrastructure. All of this means that companies have to rely on middleware to manage a great deal of communication, and the people in charge of building these infrastructures "need to support lots of different types of transportation as well as transactional semantics--they want all their databases updated or none of them, and they need to do it in a manner that guarantees the security of the operation," he says.

With such complex demands, the average IT department may need a good deal of help implementing a thorough and appropriate middleware strategy. Analysts seem to agree that this is one area where Iona has fallen short. As O'Toole himself admits, the company has primarily worked with a volume sales model-"stick it in the box, and ship it out the door." Donald DePalma, senior analyst at Forrester Research, calls this a "shotgun approach." Iona, he says, will have to "get a little more focused" as the industry matures, working with vertical channel players and tools vendors.

Boeing, however, has not found Iona to be the detached supplier it's painted to be. "We have five Iona consultants on board," says Cleland. "We have found our onsite people very valuable, especially in the early days of distributed computing, when they had the knowledge of how we could implement ORB technology."

Object request brokers mediate between clients and implementations of application objects, using a standard interface. When an object-oriented program calls a remote object, the ORB runs off and retrieves it from wherever it resides, then pulls it into the running program without letting on that it's smuggling in a foreign operator.

As the maker of Orbix, Ione's claim to fame is absolute compliance with the Object Management Group's Corba. Indeed, notes Yefim Natis, research director at the Gartner Group, lone will push proposed additions through the OMG before it puts them in its own product. Orbix implements the Corba capabilities as a pair of runtime libraries--one for client applications and one for servers--and the Orbix activation daemon.

Orbix is available on more than 20 operating systems, including a dozen versions of Unix, Windows for Workgroups 3.11, Windows 95, Windows NT, OS/2, VMS, MVS, pSOS, QNX, VxWorks, and Macintosh.

If you've bought into the object oriented vision and you need your objects distributed across a network, your options have been boiled down to two: Corba, the OMG's set of standards, and DCOM, Microsoft's Distributed Component Object Model, which comes embedded in the Microsoft package that includes Microsoft Transaction Server and Microsoft Message Queue Server.

"Today, if you're a Microsoft shop, there's a predilection to go with what you know, with Visual Basic and PowerBuilder leveraging OLE and ActiveX," says Donald DePalma, senior analyst at Forrester Research. According to DePalma, "DCOM is a natural default" in that arena, whereas the Internet Inter-ORB Protocol (IIOP) used by the Corba crowd would be more of a leap. On the other hand, Microsoft did not invent computing, and most companies require cross-platform communication. For the majority of IS shops, "[IIOP] solves a lot of problems on the back end," says DePalma.

Yefim Natis, research director at the Gartner Group, agrees: "Microsoft does not intend to extend the life of other systems or make it in any way beneficial for users to build systems on other platforms." So while competing with Microsoft on NT poses a significant challenge, most expect the Corba crew to provide a viable alternative to DCOM. "Corba is real, and it works," says lone CTO Anorai O'Toole. "People depend every day on Corba's being around. It's more mature [than DCOM], and it's had the kinks rolled out of it."

"As usual, Microsoft has come up with a technology that solves 40% to 50% of the problem," says DePalma. For many users, that will be enough.

In an effort to step up the kind of cooperation taking place in the OMG, four major industry players have formed what Natis refers to as a "back-room consortium." Called variously NOIS by Natis and "the IIOP gang of four" by DePalma, the group includes Netscape, Oracle, IBM, and Sun. The participants are negotiating over naming, components, scripting, and other features they believe are required for their Corba-based products to succeed.

THE ORBIX 2.1 ARCHITECTURE

SINGLE SOURCE OF PRODUCT DATA (SSPD) FROM BOEING.

~~~~~~~~

By Debra O'Donnell

Section: RESEARCH NEWS

GENOMICS

Because the world's major biological databases are constructed differently, it is virtually impossible to devise search programs to tap into them all effectively. A user has to hop from one to the other using each database's search engine to retrieve information that comes in a variety of different formats. That may soon change, however. A group of leading pharmaceutical companies last week put their considerable weight behind the development of common standards for the interface between biological databases, based on an approach popular in the computer industry. But bioinformatics specialists who run some key databases used by academic researchers say they are not enamored of the interface standards chosen, although they may now be forced to adopt them.

The strategy was agreed to at a meeting in Philadelphia, attended by representatives of pharmaceutical giants such as Smith Kline Beecham, Glaxo Wellcome, and Zeneca, together with a number of software companies and representatives of databases, including the European Bioinformatics Institute (EBI) in Cambridge, U.K., and the Genome Data Base at Johns Hopkins University. The participants unanimously agreed on a fast-track plan to bring life sciences databases under standards drawn up by the world's largest software consortium, the Object Management Group (OMG). "The pharmaceutical industry is fed up by the lack of standards between biological databases," says the EBI's head of services, Graham Cameron.

The OMG was set up 8 years ago to tackle the problem of incompatible databases. The OMG's approach, dubbed the Common Object Request Broker Architecture (CORBA), does not impose an external set of rules for the contents of databases to which everyone must adhere. Instead, CORBA defines interfaces that allow different databases to communicate with each other no matter what their format. Software companies then use these interfaces to devise programs that allow researchers to access data in otherwise incompatible locations. "The idea behind CORBA is that database managers will never entirely agree on common formats for data entry in databases," says Eric Neumann of the biological software company NetGenics.

The EBI has already championed the CORBA approach, winning funds from the European Union to study its application to biological databases in collaboration with other European partners. The Philadelphia meeting, chaired by Cameron, agreed to work toward getting the OMG to establish a life sciences "task force" by the end of the year to hammer out the details of applying CORBA to life sciences databases. Seven task forces in various business areas already exist.

Cameron is concerned, however, that biologists may not back a move to CORBA in the belief that other standards may ultimately be more useful for life scientists. "The plan is by no means a done deal," he says. Researchers at the National Center for Biotechnology Information (NCBI) in Bethesda, Maryland, for example, are not convinced that CORBA will provide the best solution for biologists. "CORBA is one among many technologies," says head of applications development, Jim Ostell. "There's no real reason why a number of other standards couldn't be applied, but given the critical mass of interest in CORBA it's a reasonable choice," he adds. NCBI will be looking at CORBA alongside other potential technologies for linking databases.

Supporters of CORBA will ultimately have to convince skeptics to use the standards, but they are optimistic. "The best outcome would be standards to which software developers and database managers adhere. It could do us all a great deal of good," says Cameron.

~~~~~~~~

By Nigel Williams

Section: NEWS

At its meeting next month in Dublin, Ireland, the Object Management Group (OMG) hopes to ratify as many as 13 new technologies for its forthcoming CORBA 2.3 and 3.0 specifications.

Also, the industry standards body will aim to expand into vertical domain interfaces that will govern industry-specific implementation of object request brokers, such as those embedded in telecommunications, health care, finance, manufacturing, and business applications, said CEO Chris Stone.

Vendors currently are submitting proposals governing areas such as components, scripting, objects by value, notification, audio/visual interface, the COM-to-CORBA bridge Part B, and asynchronous messaging for review at the meeting.

One user welcomed the CORBA 2.3 and 3.0 standards, but also warned that the OMG still has a great deal of work to do before it dispenses too much energy on the vertical domain-specific interfaces.

"The OMG really needs to address some of the interoperability issues surrounding CORBA," said James Smith, planning and project manager for Southwestern Bell, in St. Louis.

Also expected at the Dublin meeting is the standardization of the Unified Modeling Language, according to Stone.

AAVS and LYSIS have announced plans to use CORBA-2 (Common Object Request Broker Architecture} based communications software to link their broadcast and multichannel technologies. CORBA is a standard devised by the Object Management Group and both companies plan to use the technology to provide their customers with traffic, scheduling and automation within a single package. This represents one of the first times that CORBA, a growing force in the computer industry, will be used in this way.

Section: NEWS

Object management

Iona last week launched OrbixManager 1.0, a tool designed to enable the management of CORBA environments.

The tool aims to provide administrators with a way to manage software objects on a network. Iona unveiled OrbixManager during last weeks Object World West show in San Francisco. (See related article, page 43.)

Also, officials said the company is currently beta testing Java-based services -- include Java Naming, Java Directory, and Java Transaction services -- for its OrbixWeb object request broker (ORB) for Java. The new services will let developers build applications in Java that were previously only available to users of CORBA.

OrbixManager is designed to work with Iona's Orbix and with the company's messaging product, OrbixTalk, but ORBs from competing vendors such as Visigenic will not work with the tool.

"We will add support for Java later this year," said an Iona representative. "But we don't foresee the necessity of adding support for any competing object request brokers."

OrbixManager will let network managers monitor networks for the number of objects found on a network and configure the CORBA environment itself, officials said, and it will work with other network-management tools via an SNMP gateway.

Iona Technologies Inc., in Cambridge, Mass., is at http://www.iona.com/.

DIAGRAM: ORB management emerges

~~~~~~~~

By Niall McKay

Niall McKay is a San Francisco correspondent for the IDG News Service, an InfoWorld affiliate.

Section: A.M. Report

A Partnership between two software companies to incorporate common object request broker architecture technology into a Telecommunications Management Network-based solution could yield a more elegant way to integrate carriers' legacy networks and provide a workable approach to interconnection.

The partnership between OpenCon Systems Inc. and Expersoft Corp. is aimed at creating a new gateway that will give carriers an open, protocol-independent method of accessing legacy systems. OpenCon will integrate Expersoft's CORBAplus technology into its TMN Gateway product, which it hopes to roll out within three months.

"The problem that many carriers face is that there has never been a single standard set for network management," said Wind Chen, vice president of product planning and sales engineering for the Piscataway, N.J.-based OpenCon Systems. "The three most common protocols are TL-1, [simple network management protocol] and [common management information protocol], and these all may exist within the same carrier's operations."

To secure the investments already made in software and equipment, the gateway will target these three protocols and provide what Chendescribed as a "staging facility" to support the translation of CORBA IDL to TL1, SNMP and CMIP protocols at the open systems interconnection seven-layer level.

CORBA provides the gateway with an efficient, object-based method of translating between protocols, supporting applications written in C++, Java and Visual Basic languages.

The gateway development will target three facets of telecommunications, said Steve Sybert, vice president of worldwide telecommunications for the San Diego-based Expersoft. "The object-oriented nature of CORBA will help developers create new applications faster by providing reusable software elements," he said. "While that's important, the other two areas we're focusing on are even more pressing issues for the telecommunications industry -- providing a view of network and customer information to the external world, and refining the interaction between legacy systems internally."

"There are 6000 carriers out there, and for each carrier to negotiate an individual agreement based on proprietary network systems with every other carrier is impossible," he said. "CORBA can serve as a Rosetta Stone between these systems, and we think this fits into the bigger business picture."

CORBA is a key method for simplifying network management and interconnection issues, although its impact on the telecommunications industry will depend on carriers' eagerness to solve problems, analysts said.

DIAGRAM: CORBA-ENABLED TMN GATEWAY

~~~~~~~~

By CHRIS BUCHOLTZ

Intelligence & Software Editor

Section: NEWS

Following Sun Microsystems Inc.'s lead with Java, the Object Management Group is trying to make CORBA, the Common Object Request Broker Architecture, an international standard.

Like Sun, the Object Management Group (OMG) has requested to become a submitter of Publicly Available Specifications (PAS), or a standards body in its own right. Becoming a PAS also would allow the OMG to submit specifications through the International Standards Organization's fast-track process.

Votes on the OMG's move are due to the JTC 1 TAG--a U.S. technical advisory group--on Oct. 10. If the United States approves the OMG's request, it goes to an international vote.

Sun's application to become a PAS has hit a snag largely because it is a for-profit company. JavaSoft Vice President Jim Mitchell said that most of the international votes have come back with comments, which Sun will spend the next 60 days addressing.

But the OMG is a nonprofit consortium of companies and expects to be approved in about six months.

In fact, the International Standards Organization (ISO) and the OMG already work together, and ISO is expected to approve the OMG's Interface Definition Language (IDL) as a standard this month, said Jon Siegel, OMG director of domain technology.

IDL defines interfaces to objects and maps to all the major languages, including C&PLUS;&PLUS;, Java and Visual Basic, although the Visual Basic bindings are not yet an OMG standard, Siegel said. Programmers then can write objects in different languages that have the ability to interact.

"IDL is the key to accessing CORBA interoperability and all the other CORBA features. That's why it makes sense for it to be the first part of CORBA to be standardized," Siegel said.

The OMG also will submit other parts of CORBA, including the Internet InterOrb Protocol (IIOP), Siegel said.

CORBA and IIOP are now backed by Netscape Communications Corp., Oracle Corp., IBM Corp. and Sun, which refer to themselves as the Gang of Four. JavaSoft this month was persuaded to back IIOP along with its own Java-to-Java protocol.

However, not everyone who works with CORBA is positive.

"Someone will evolve a lightweight object protocol--something beyond RMI-where we will have anchored objects and only pass requests for objects and replies from objects. But there's so much inertia behind CORBA and IIOP that the OMG is blind to this possibility," said a Sun reseller who asked not to be named.

"We don't want to split the market three ways--Java, CORBA and DCOM [Microsoft Corp.'s Distributed Component Object Model]--because that just feeds Microsoft," said an OMG official who requested anonymity.

Microsoft senior officials maintained that Microsoft has no plans to work more closely with the OMG. Microsoft is currently an OMG member.

ISO certification is a requirement for purchasing technology in some foreign countries, and that could be beneficial for CORBA.

It is nonprofit consortium.

The International Standards Organizations is Expected to approve the OMG's Interface Definition Language as a standard this month.

OMG also will submit other parts of COBRA.

~~~~~~~~

BY DEBORAH GAGE, Framingham, Mass.

Section: SERVER

Seeking to promote widespread use of its CORBA technology and services, the Object Management Group (OMG) is pursuing an ambitious agenda to lower the technical barriers to developing CORBA applications.

Working toward CORBA 3.0, the OMG is reading requests for proposals (RFPs) for a unifying scripting language and component model, according to President Chris Stone.

The initiatives follow the specification of myriad current and pending CORBA Interface Definition Language (IDL) mappings, which allow developers writing in Cobol, Java, or fourth-generation languages, such as Sybase division Powersoft's PowerBuilder, to access and generate CORBA objects without wrestling with the abstruse IDL.

The organization, which includes IBM, Sun, Oracle, and Netscape among its members, last month issued the component RFP and will shortly issue one for scripting, according to Stone.

"The biggest barrier to the adoption of our 15 different object services is the lack of a component model to share those services and a single scripting language for all CORBA services," Stone said.

A CORBA component model would allow developers to create components visually on a project palette and access methods and properties more easily than the coding-intensive approach required by IDL, Stone said.

The component model will be based largely on JavaBeans. Java-Script will be among the scripting languages considered, Stone said.

IDL has restricted CORBA's growth, according to one analyst.

"We predicted a while back that CORBA would disappear as a programming model," said John Rymer, an analyst with market research company Giga Information Group, in Cambridge, Mass.

"[The language mappings to IDL] make IDL a glue language, and all the CORBA language bindings are irrelevant," Rymer said.

According to Rymer, the OMG's ultimate role with CORBA will be to provide an integration substrate for multiple object models rather than to furnish a full-blown development architecture.

More important than the pending CORBA object model and scripting proposals, the OMG's recent decision to integrate its Internet Inter-ORB Protocol transport with the Java Remote Method Invocation (RMI) interface for distributed object communication indicates the future position of CORBA in the development technology food chain, according to Rymer. (See "JavaSoft to fix RMI compatibility," page 14, June 30.)

In pursuing tighter integration with Java and providing mappings to common programming languages, the "OMG is not shooting its own foot," Rymer said.

"It doesn't have any choice. The group is returning to its roots. The genesis of CORBA was as interoperable middleware for object systems," Rymer said.

Separately, the OMG is readying for September release the first of its vertical industry, end-user object specifications for telecommunication finance and manufacturing, according to Stone. The group has also issued an RFP for workflow management.

The Object Management Group, in Framingham, Mass., can be reached at (508) 820-4300.

• Java-CORBA Interface Definition Language (IDL) mapping: adopted as standard in June and expected to be in Java Development Kit 1.2

• Asynchronous messaging API: scheduled vote in September in Dublin, Ireland

• Internet Facility requests for proposals (RFPs): CORBA IDL to connect to TCP/IP, FTP elnet, SMTP, and others; submissions expected by early 1998

• CORBA scripting language: RFPs due later this year

• CORBA component model: RFPs due later this year

• Adoption of Universal Modeling Language: expected in September

SOURCE: OBJECT MANAGEMENT GROUP.

~~~~~~~~

By Ted Smalley Bowen

Section: NEWS

FROM THE NEWS DESK

The time has come for Microsoft to prove how big it really is by putting aside politics to reach some sort of practical working relationship with the backers of CORBA. As noted in Niall McKay's Page One article this week, the Object Management Group (OMG),which spearheads CORBA, now intends to extend I hat architecture to include a component model that will be compatible with JavaBeans.

Although it remains to be seen whether the vendors that make up the OMG can deliver on this promise, the mere fact that there appears to be some real consensus building around distributed objects means that Microsoft can no longer play politics as usual.

From Microsoft's point of view,force of arms provided by the increased sales of Windows NT loaded with the rival Distributed Component Object Model (DCOM) specification should make CORBA irrelevant. That position might actually be credible if we thought NT would be as scalable as Unix any time soon, but it simply won't happen before the end of the century.

This means customers are going to be living with a mixture of NT and Unix systems for a long time to come, and we're going to need a unified distributed object architecture today to foster application development across the enterprise. We simply can't wait for NT to eventually win out over Unix.

Microsoft may want to hold on to DCOM for business reasons as the glue that binds together the pieces of Windows. Windows' many flavors are starting to resemble the multiple implementations of Unix that have long plagued the industry a situation Netscape's Marc Andreessen likes to refer to as the "Unixification" of Windows.

But the rest of us need something that works today. That means Microsoft needs to actively support CORBA before we can fully embrace NT.

So are customers going to hold off on fully adopting NT until this issue gets resolved, or are we going to contribute to our own demise by wistfully hoping for some technical miracle that makes all these headaches magically disappear? Write to me at michael(underbar)vizard@ infoworld.com.

~~~~~~~~

By MICHAEL VIZARD

Section: In The Middle

Don't get me wrong. I'm a huge Java fan--Java, the language that is. Unfortunately, the incredible hype surrounding Java has emboldened JavaSoft to attempt the displacement of the Object Management Group's (OMG's) Common Object Request Broker Architecture (CORBA) with Java Beans for the Enterprise (JBE), to vie with Microsoft's Distributed Component Object Model (DCOM) as the distributed component architecture for Web applications. I'm all in favor of using Java as the language for implementing a distributed component architecture, but we don't need another component standard. Accordingly, users should ignore the hype and consider only CORBA and DCOM as standards.

Java will play an important role in enterprise applications, but it will not revolutionize every aspect of application architecture-contrary to JavaSoft's claims. At the JavaOne conference in April, JavaSoft outlined JBE, a server-side component model. Previously, JBE had been positioned as a client-side GUI-component standard. Some of JavaSoft's statements regarding JBE position it as a distributed component model that will compete with both DCOM and CORBA for the hearts and minds of developers. At other times, JBE is merely positioned as a Java-specific instance of these other models. Two competing distributed component models is bad enough. Users must resist any attempts by JavaSoft to establish JBE as an alternative to DCOM and CORBA. Otherwise, the CORBA camp, which is just beginning to consolidate, could be torn apart by a standards war that would leave Microsoft's DCOM the winner. The upside is that we would have a single standard; the downside is that the winner would be Windows-centric (leaving Unix and other platforms with second-rate support or none at all).

CORBA Gets Its Act Together Microsoft and the CORBA vendors have moved rapidly to deploy their competing component models. Microsoft has begun shipping its Transaction Server (formerly Viper)-the foundation of its DCOM-based Active Server technology. In the CORBA world, major players-BEA Systems, IBM, Oracle, Sun and Sybase-are backing the CORBA standard and moving quickly to improve interoperability and portability among different vendors' object request brokers (ORBs). More important, IBM, Oracle, Sun and Netscape have formed a "grand alliance" to ensure that their implementations interoperate and that they fill in the gaps in the CORBA standard in a consistent way.

This momentum behind CORBA is essential to attracting the support of ISVs, systems integrators and corporate developers. Corporate developers are ready to pick a strategic distributed component standard next year. Unfortunately, JBE is diluting the CORBA consolidation message. Although the developers at SunSoft are fully behind CORBA, the developers at JavaSoft have delusions of grandeur for JBE. At various times, JavaSoft has touted a Java alternative to a CORBA standard. Although JavaSoft pays lip service to CORBA by offering a Java-to-CORBA mapping known as JavaIDL, its public statements have positioned CORBA as merely a legacy application wrappering technology, while JBE has been positioned as the distributed component model for new application development.

Put Java Beans in Its Place JavaSoft must get on the CORBA bandwagon and turn JBE into nothing more than a Java instantiation of CORBA and CORBA Object Services Specifications (COSS) on the server side. On the client side, JBE can fill a gap in CORBA that was originally meant to be filled by OpenDoc-a model for GUI components. CORBA's main focus has always been on the server side. CORBA has never had a model specification to compete with desktop Object Linking and Embedding (OLE) components because ORB vendors were betting on OpenDoc on the client side. With the demise of OpenDoc, JBE GUI components can offer a standard for heterogeneous client GUIs.

Users are ready to choose a distributed component strategy this year, and must choose wisely. Ignore the hype and put Java Beans back in its place-on the desktop.

PHOTO (COLOR): Nick Gall

~~~~~~~~

By Nick Gall

Nick Gall is a program director with the META Group's Open Computing & Server Strategies service. He can be reached at nick.gall@metagroup.com.

Section: DISTRIBUTED COMPUTING

Organizations are building complex distributed computing environments and are relying on these systems to help them remain competitive. CIOs who want to link their distributed environments now face a difficult question: Which of three major middleware platforms--Distributed Computing Environment (DCE), Common Object Request Broker Architecture (Corba), or Distributed Component Object Model (DCOM)--is best?

For years, DCE was the only choice. It was introduced 10 years ago as the first attempt to standardize the basic infrastructure for distributed applications, and over the years it has gained a foothold in many organizations.

But analysts say the highly complex DCE is losing ground as the two newer solutions gain support from vendors. Corba, an open standard overseen by the Object Management Group, in Framingham, Mass., and DCOM from Microsoft show promise as middleware platforms of the future.

The stakes are high in this battle for control of distributed computing environments. These middleware technologies promise to meld diverse networks, allowing mainframes, workstations, and all forms of client-server systems to work together easily. They work by providing a common interface language that serves as a universal translator of sorts between any two applications.

"The idea is to tie together all the different systems that have been developed over 20 years," says Bob Anderson, managing analyst for application component services at Datapro Information Services Group in Delran, N.J.

The need for dependable distributed computing middleware environments is greater than ever as complex three-tier networks--which include database or transaction servers combined with traditional client-server networks--become more commonplace. Also, companies are under increasing pressure to harness their computing resources and deliver data to partners, vendors, and suppliers.

DCE, a standard managed by the Open Group in Boston, is the middleware of choice at many organizations (see story, p. 100). The Open Group says DCE is provided by more vendors and has been ported to more platforms than any other middleware technology, and predicts strong growth for DCE through 1999.

Despite DCE's maturity and support by major vendors, some observers say it's a fading star as the early technology used to create it falls out of favor.

"For whatever reason, DCE missed the boat. Perhaps it was too far ahead of its time," says Nick Gall, a senior research analyst at Meta Group Inc. in Waltham, Mass.

DCE's complexity and a lack of expertise on the technology has been a major hindrance to its widespread adoption.

DuPont & Co. in Wilmington, Del., wants to give its network users broader access to data and is testing DCE to see if the technology can deliver. But Rob Harris, a senior IS specialist at DuPont, says efforts have been slowed by DCE's long learning curve. "Our problem is a lack of trained resources," Harris says.

Though DCE has been around for years, there aren't a lot of people who understand it. An InformationWeek survey of 100 IS managers shows that lack of expertise was the top reason given for not moving to DCE, followed by a lack of DCE-based products, high costs, and security concerns.

Observers say the newer, object-based technologies seem to hold the most potential for creating seamless distributed computing environments, despite the fact that Corba is struggling to establish its standards and DCOM has yet to prove it can operate as a cross-platform solution.

"The hope is that as Corba and DCOM evolve, you'll find that object request brokers are the way to go," Anderson says. "They just need to evolve to encompass security, directory, and other critical services."

Object request brokers serve as control centers of sorts for translating Information between disparate applications. They work in conjunction with an interface definition language (IDL), which provides the "wrapper" for object-oriented middleware that lets various programs talk to one another.

A Boost For Corba

Corba got a major lift last month, when IBM introduced a Corba-based suite of middleware products, including Component Broker Connector and Component Broker Toolkit. Karen Boucher, an analyst with the Standish Group in Dennis, Mass., says the suite was a big boost for Corba. Until then, organizations interested in using Corba had to search far and wide to assemble the tools they needed to build a Corba environment.

Boucher expects IBM to offer its Corba development suite for free with many of its products, just as Microsoft provides DCOM for free with its Windows NT systems.

Some organizations getting an early taste of Corba are finding that dealing with its object-oriented approach is within their capabilities. Cable News Network's CNN Interactive division in Atlanta has been piloting a program since December that uses Corba to distribute part of its news content to 100 different Internet publishing partners. Before that, CNN had to screen-scrape its Web site for news stories, deconstruct them from HTML, then send them out. Now, a Corba application goes out on the network, finds any new content, and automatically notifies users, says Al Issa, a software-development architect with CNN Interactive.

Corba also makes the content appear local to programmers so that they don't have to worry about details such as IP addresses. "It actually made life a lot simpler," Issa says. Implementation of the middleware has gone so well that Issa plans to use Corba to distribute the rest of CNN's news content by the end of the summer.

But Corba isn't without its dark side. The technology still lacks a security standard, though that is promised for the coming year. There's also some question of how much support the technology will receive from vendors. Although companies such as Netscape, Oracle, and Sun Microsystems have agreed to support emerging standards, they could decide not to create many Corba products if another technology comes along.

Risk Vs. Rewards

Still, Corba boosters say the rewards more than outweigh the risks. Wayne Haughey, a group leader at the engines information systems division of AlliedSignal Inc., a maker of airline engine parts in Phoenix, says his company selected Corba because the object-oriented programming environment lets his staff reuse and quickly modify program designs.

Also, since programmers don't have to start from scratch each time they build an application, it's easier to refine an existing program or customize a standard design. And since Corba is cross-platform, code created for a program on one platform can be easily transferred to another. Haughey says AlliedSignal is so confident in Corba that it's committed to using it in a two-year project to develop a Web-equipped network.

Others are going with DCOM. "If you're Microsoft-centric right now, DCOM is a very elegant way to go," Anderson says. The only drawback is that DCOM is far from being a cross-platform solution. It's not yet operable on many systems outside of Windows NT--no small issue when considering an environment for multiplatform networks.

"You want the highest degree of flexibility when setting up one of these middleware environments, and you can't get that with DCOM because it's created by one vendor," Boucher adds.

DCOM support is coming. Software AG of North America in Reston, Va., this month will release a number of porting solutions for DCOM to Unix, including one for Linux, Digital Unix, and Sun's Solaris. It's also working on porting for IBM's MVS.

A spokesman for Microsoft says the company is recruiting partners to port DCOM to other platforms, but he wouldn't provide details.

The porting solutions for DCOM might prove effective. Joe Persichetti, a senior software designer for Dow Jones & Co. in Princeton, N.J., wanted to access data on a Solaris machine to meet a special request by customers to view some of Dow Jones' financial data via Excel spreadsheets. Persichetti says he wanted to port DCOM rather than work with Corba because most of his experience is with Windows. "It wasn't such a reach for me to use DCOM," he says. He used an unpublished beta version of Software AG's DCOM for the Enterprise product and experienced no problems,although he had to write additional code to compensate for DCOM's asynchronous protocols.

Regardless of which middleware platform an organization selects, the key for IS managers is to commit to a particular approach and stick with it, says Marvin Allen Wolfthal, technology director of consulting firm Fusion Systems Group Inc. in New York. "Frequent changes in a network environment will be too disruptive to provide any benefit," he says.

But companies "need to start at least experimenting with this technology because in the future, it will be absolutely critical to get all systems working together," Anderson says. "If you don't do it, you'll be out of business."

While some observers believe the Distributed Computing Environment (DCE) is fading, others say it's the only middleware environment that's dependable enough for critical applications.

"DCE is still the most production-oriented schemeout there," says Bob Anderson, managing analyst for application component services at Datapro Information Services Group in Delran, N.J.

Phyllis Byrne, the Austin, Texas-based VP of distributed systems services for IBM, says DCE, as it originally conceived a decade ago was, very complex. But IBM and other vendors are providing starter kits and other support that make the technology easier to work with.

Some IS chiefs says DCE is their best bet for pulling together disparate elements of their computer systems, especially those networks where object-oriented programming isn't an option.

Bill Won, VP of enterprise and software security technologies at Chase Manhattan Bank in New York, began exploring the technology in 1993 by testing an IBM beta version of DCE for the OS/2 platform. He says Chase has several projects in development, including using DCE to download mainframe files to a database server. DCE isn't always easy to work with, Won admits, but it's the only viable option he has found to securely connect diverse platforms. "If someone is looking for a silver bullet, it doesn't exists," Won says.

Network managers such as Roger Lawson associate director of computing and IT at the University of Vermont in Burlington, are finding the best approach to DCE is to use only what you need. Lawson tapped DCE to create a single system image for his servers, which allowed him to modify IBM RS/ 6000s to meet the exploding computing demands of the 15,000-account university system.

With the DCE single-system image in place, the network treats the group of servers as one, which lets Lawson work on one or more servers without bringing the system down.

Lawson started the project in late 1995, and since the university was one of the earliest adopters of the DCE feature from IBM, it ran into several reliability problems, such as coding glitches and memory leaks. But with daily support from IBM and long hours by his staff over the course of three months, Lawson finally got the technology working. Now, he says, it performs dependably.
--Charle Waltner

Distributed Computing Environment

Pros: More mature, not object, reliant,
excellent security

Cons: Older, more complex technology;
fading from popularity

Common Object Request Broker Architecture

Pros: Object-oriented, relatively simple to
set up, resurable coding

Cons: Immature, lacks standards, lacks
support for critical network features

Distributed COM

Pros: Objected-oriented broad support,
well-developed for NT platfrom

Cons: Controlled by one vendor, not
cross-platform oriented

DATA: INFORMATIONWEEK

PHOTO (COLOR): CNN Interctive's Issa says Corba has simplified his life, and plans to use it to distribute CNN's news by the end of summer.

~~~~~~~~

By Charles Waltner

Section: NEWS

Three months into their touted object alliance, the companies that comprise "The Gang of Four" have agreed on basic methods to bring JavaBeans closer in line with the CORBA specification in their unified attempt to fight off Microsoft.

The Gang of Four -- IBM, Netscape, Oracle, and Sun -- last week jointly published a position paper that details specific enhancements to the CORBA specification in an attempt to foster integration with other component models, most notably JavaBeans.

The four companies have jointly generated Request for Proposals (RFPs) to the Object Management Group (OMG), which are expected to be voted on in a meeting in Montreal later this month. The RFPs are for a component model; scripting, which will be based on JavaScript; and an Internet naming service.

The four have also agreed to combine forces on two existing OMG projects. The first is Objects By Past Value, an essential Java capability that will now become a CORBA feature, and the second involves multiple-interface support, another basic Java capability.

"What you are basically seeing here is the continued intertwining of Java and CORBA," said Chris Stone, chief executive officer of the OMG, in Framingham, Mass.

Some of the proposed enhancements will enable visual development tools to automatically generate JavaBean interfaces for CORBA-compliant components, a step most observers see as essential.

"Developing for CORBA right now is very difficult. It is a little like brain surgery. What you want is to have something like a JavaBeans component framework available to jump-start your enterprise development. This is a step that lets those users do that" said Melinda Ballou, a senior research analyst at the Meta Group, in Waltham, Mass.

Separately, JavaSoft officials more aggressively endorsed CORBA for large corporate accounts doing sophisticated development in heterogeneous environments, noting that Java Remote Method Invocation (RMI) should be restricted to small Java-to-Java applications.

But one official argued that the RMI protocol has inherent advantages.

"Interoperability is the primary value of Internet Inter-ORB Protocol [IIOP]. RMI gives you the ability to download code dynamically with safety. RMI is more about ease-of-use and flexibility if you're programming both sides of a distributed application in Java," said Jim Mitchell, JavaSoft vice president of technology, in Cupertino, Calif. He added that combining RMI and IIOP would not be feasible.

~~~~~~~~

By Ed Scannell and Ted Smalley Bowen

Section: THE END

DOWN TO THE WIRE

To know what the computer industry is really like, watch a gangster movie. Gangsters take territory based on nothing more than the fact that they want it. The mob pretends to offer the current residents protection for a piece of the action, but everybody knows it's a question of how much the mob will let them keep.

That's how Microsoft claimed the territory of distributed computing last week. Microsoft's distributed computing strategy centers on its Component Object Model (COM). COM is an object request broker (ORB), which is a technology used to allow client and server components to communicate with other client and server components. The components can be composed of anything from raw C++ to Activex and JavaBeans.

One argument Microsoft makes for COM is that it is finally being ported to platforms other than Windows 95 and Windows NT. As evidence of this new multiplatform strategy, Microsoft got Digital to agree to port COM to OpenVMS by the end of this year, and Hewlet-Packard is shooting to deliver COM on HP-UX within a year. And Software AG is tackling putting COM on Sun Solaris and MVS.

Ready on the set

In this movie, the camera sweeps slowly across the dimly lit room. It rests on the Digital and HP representatives, who are sobbing and kissing the hand of the Godfather.

"Don Gateleone, we need your help. The trades don't write about us. Our stock is unstable. And we have boo-boos on our knees," they moan.

"You pathetic babies. I should throw you out. But because you helped my son, NT, when he was in need, I will make the trade pubs an offer they can't refuse. When they wake up, they'll find a stack of partnership press releases in their beds," the Don offers.

"However, I require something in return. My enemies in the CORBA family, Lou Gerstaglia, Scott McNealioni, and Jim Barksdaliani ... even now they plot my demise. For this favor, you must port COM to your other operating system platforms."

But life does not always imitate art. Microsoft's claim to victory hangs on the hypnotic quality of Bill's billions and the promise of products based on technology that's unproven in the large enterprise. In other words, it's too little too late, especially where it really counts. This battle will not be decided on the desktop. The coveted territory is the server. And the CORBA families have already taken over that space.

Ironically, Digital, Microsoft's most heralded supporter of COM, provides the most dramatic proof. Digital's CORBA-based Object-Broker is shipping today running on OS/2, AIX, OS/400, MVS, MacOS, Digital Unix, OpenVMS, HP-UX, and all versions of Windows. Iona Technology's Orbix supports Sun Solaris, HP-UX, AIX, MVS, Irix, Digital Unix, Windows 95, and Windows NT. Visigenic Software's VisiBroker is available for Novell IntranetWare, and Visigenic has aversion of its ORB that is written entirely in Java.

Then there's IBM's System Object Model (SOM) and Distributed SOM and Expersoft's PowerBroker. And while we're still waiting for Mama Celeste to cook up some COM on Unix, some of these CORBA products have been simmering in the pot since 1993.

Some envision a future in which COM dominates the desktop and CORBA the server. Maybe. But remember three things: First, network computers aren't Windows-based, so Microsoft has no leverage there. Second, Netscape is making the Internet Inter-ORB Protocol nearly ubiquitous by including it in Navigator. Third, you take a performance hit when you mix COM desktop components with CORBA server components. I predict the industry will want to standardize on one or the other sooner or later. And because CORBA already owns the server space -- where the big money will be made -- it is the obvious choice.

The magnificent seven

Seven is the biblical number of completeness, so it is somewhat prophetic that after seven years I am leaving my full-time position at Info World to become editor in chief of a new IDG Web publication dedicated to network computing, NC World (http://www.ncworldmag.com). I am happy to say that I'll continue to write Down to the Wire and host my forum on Info World Electric. So consider me absent in body but present in spirit.

Make an offer I can't refuse and send it to nicholas(underbar)petreley@infoworld.com or visit my forum on InfoWorld Electric at http://www.infoworld.com.

PHOTO (BLACK & WHITE): NICHOLAS PETRELEY

~~~~~~~~

By NICHOLAS PETRELEY

Section: Intelligence & Software

Common Object Request Broker Architecture technology will play a key role in a new Web-based strategy from Cabletron Systems for the management of customer networks. By 1998, CORBA will be partly used for pure Java device management in solutions from Rochester, N.H.-based Cabletron.

"We're setting 1998 as the time frame for modifying our platforms to fit a [Telecommunications Management Network]based world," said Joe Massey, Cabletron's director of platform development.

The strategy's goal is to provide customers with greater flexibility and cost-effectiveness, which is precisely what the use of the World Wide Web, CORBA and Java will allow, Massey said.

By integrating CORBA into the Spectrum management platform, "the number of applications available to our customers will dramatically rise," Massey said. "And by using Java and its write-once, deploy everywhere capabilities, customers can change versions of their software without having to shut down their systems."

CORBA will allow software developers writing applications for Spectrum and other Cabletron management software to write applications in Java, C++ or C. During 1998, CORBA will enhance Spectrum application programming interfaces (APIs), improve the platform's scab ability, and open up new opportunities for custom applications, Massey said.

Cabletron will offer these enhancements to other management vendors in the interest of interoperability across multiple platforms. The new APIs will not require CORBA expertise and will allow application integration to be done within the Java, C++ and C language skill sets for enterprise and desktop environments.

Additional development of Spectrum APIs will be aimed at making implementation easier for software developers, much in the way predefined menus are provided for developing graphics-oriented applications for Windows. Cabletron will provide a set of reusable objects for software developers targeted at specific management functions such as distributing software or viewing topology "Our goal is to give our customers the widest possible choice of applications," said Massey.

Cabletron is targeting the improved platform at the carrier, Internet service provider and enterprise markets. Service providers would offer these network management tools to their customers as a value-added service, said Massey. "Cabletron is really the first major player to spell out the details for us," said Rick Villars, director of network architecture and management research at International Data Corp.

"Virtually every vendor has committed to CORBA as the foundation of Java object management," said Villars. "It makes sense to support it, but part of committing to the technology as a standard is to move toward it, which is what Cabletron's announcement signifies."

Within the carrier community, however, CORBA faces the same challenge that other technologies have faced: overcoming an installed base of technology that performs the same task, Villars said.

"The problem is that real users have invested time and money in the systems they have in place, and they don't want to throw them out, especially when they're doing their job," he said. "It's very likely that the first round of CORBA-based systems won't be able to match the functionality of the existing systems for a year to 18 months. The vast majority of those in the carrier world want to see CORBA, but they can't afford to see any performance problems. You're likely to see a gradual phase-in rather than a big rush to CORBA."

DIAGRAM: Cabletron's Java Strategy

~~~~~~~~

By CHRIS BUCHOLTZ, Intelligence & Software Editor

Section: Soundbites: Middleware

A move to unite two key middleware technologies--object request brokers and message-oriented middle-ware (MOM)--could make life easier for IT managers who want to leverage the benefits of both.

The Object Management Group (OMG) is reviewing proposals for extending the Common Object Request Broker Architecture (CORBA) standard, which specifies how objects communicate in distributed environments, to include links to messaging systems such as IBM Corp.'s MQSeries and PeerLogic Inc.'s Pipes Platform. The OMG has received seven proposals for the CORBA extension, known as the messaging service specification, and is expected to certify a standard by mid-year.

While object-to-messaging links might sound like a topic for late-night debates among Jolt cola-addicted programmers, the lack of such a standard is proving to be a big headache for IT managers, according to Gerald Henson, a senior technologist with Southwestern Bell. Henson says object-oriented technology is most popular for building applications because it's good for modeling business processes. But MOM is winning favor as a means of linking applications running on heterogeneous systems because of its scalability and multi-platform, asynchronous architecture.

The problem is that there is no standard way to link the two technologies, which effectively forces IT managers to choose one or the other. "Messaging would be a very nice set of services to complement CORBA," Henson says.

~~~~~~~~

By Rick Whiting

Section: Network Applications

OBJECT SOFTWARE

Although four leading vendors have taken a step toward letting organizations connect different companies' object-oriented applications, it could still be some time before the move facilitates transaction-based electronic commerce.

It already has been more than a year since the Object Management Group (OMG) released a key standard toward achieving that goal: the Internet InterORB Protocol. But IIOP is a baseline specification that does not address higher-level hierarchies of how different vendors' objects connect to one another.

Looking to break that roadblock, IBM, Netscape Communications. Oracle and Sun Microsystems earlier this month said they will work jointly on that surround the IIOP standard and on proposals of new Common Object Request Broker Architecture (CORBA) service implementations to the OMG. These implementations operate at a level above the basic CORBA Services 1.0 specifications.

By extending CORBA, a single distributed application might call upon objects located in five or six different companies' object request brokers (ORBs) involved in a sales transaction across the Internet. The vending company may need to link to an object at the buying company to update its inventory level directly and at the same time call upon a third-party financial organization to receive electronic payment for the order. For both of these tasks, the naming mechanism of the vending company must be able to interoperate with the naming services used on the ORBs of the two other parties. In addition, all three parties must be using the same implementation of CORBA's Object Transaction Service so that the deal can be rolled back, or undone, should one part of the application fail or be rejected.

Basic specifications for CORBA Services have been on the OMG's books since December 1995, but the implementations of such services, including the important object naming service, have lacked a higher level of unity. All four companies have a vested interest in achieving a higher level of Web- and enterprise-based object interaction, and all four feel Microsoft's competing Distributed COM and ActiveX-based efforts are a major threat.

The vendors' recent agreement promises to facilitate interoperability, but it could be some time before key compatibility issues are resolved, said Anne Thomas, senior analyst for distributed objects at the Patricia Seybold Group, Boston.

"We still need a way to transparently locate a specific object to allow multiple users to share objects," she said. That includes letting users update objects and ensuring that the objects are stored permanently, she added. The vendors also need to address authenticating users and objects, and to develop a common model to certify that a user or object has in fact performed a given transaction.

Some progress had been made last September when IBM and Sun took the first step by starting on a common naming service syntax, an effort that has only just reached the alpha stage. Last month, ORB-maker Visigenic Software, San Mateo, Calif., joined in that effort. Oracle's Jerry Held, senior vice president of server products, said that Cambridge, Mass.-based Iona Technologies had also committed to support the CORBA Naming Service. At the recent Object World East show, the first implementations of CORBA's Object Transaction Service were demonstrated in beta form (CommWeek, March 3).

The executives from IBM, Netscape, Oracle and Sun (Steve Mills, general manager, IBM Software Solutions Division; Steve MacKay, senior vice president, Sun Solaris products; Jerry Held, senior vice president, Oracle server products; and Rich Schell, senior vice president, client division, Netscape), gave few specific timetables for their submissions of CORBA Services implementations.

"The Naming Service implementation should be presented to OMG some time in the first half of this year," said Held.

CORBA naming services were selected as the first joint service implementation because the ability to locate and call objects held on remote ORBs is fundamental. The other CORBA Services that the companies expect to be working on this year include implementations of Object Transaction Services and CORBA Security Services.

"On the transaction services, we need to map to a common set of semantics. align our message queuing services, extend our language mappings to cover Smalltalk and Java as well as the current C+ + and come up with common business objects facilities," IBM's Mills said.

IMPLEMENTING OBJECTS

Four major vendor's applications platforms will be easier to link within enterprises and beyond with extensions to COBRA. Here's how each will benefit:

Oracle        The company's Network Computing Architecture
              depends on different vendors' objects to connect;
              without it, NCA will be a piecemeal solution
              at best

Sun           Enterprise scalability of Java applications will
              depend on the extent to which COBRA services can
              be deployed for naming, transactions and security

IBM           IBM's System Object Model (SOM) is the basis of
              COBRA; interoperable implementations will be
              facilitated by Java and NCA compatibility

Netscape      COBRA is key to the company's roadmap for Web
              commerce and extranets

Source: CommunicationsWeek Chart by David R. Bautista

~~~~~~~~

By MARTIN MARSHALL

Section: UPDATE

IBM, Sun Microsystems, Oracle, and Netscape Communications have agreed to work together to ensure their products can interoperate using the object standards defined by the Object Management Group (OMG). Those standards are the Common Object Request Broker Architecture (Corba) and the Internet Inter-ORB Protocol (IIOP). When setting the goal of achieving this interoperability by year end, the four vendors acknowledged a key motivation for their pact is to derail enterprise support for Microsoft's competing standard, the Distributed Component Object Model (DCOM).

Our take: The real news in this announcement -- all but ignored in the first reports of the mid-March deal -- is the tacit acknowledgment that the OMG's specs require vendors to perform a Cot of extra work to ensure their "Corba-compliant" apps actually interoperate. All four members of the new coalition were already Corba and IIOP backers. If the specs lived up to the OMG's claims, there would be no need for this mobilization effort. As such, we don't see the pact as good news for the OMG. :Instead, it suggests -- as Microsoft Loves to claim -- that the group's specs are in disarray and require lots of fine-tuning to actually work as billed.

Section: Application Development

The Corba specifications set by the Object Management Group have the express purpose of allowing distributed object computing to take. place transparently in a multivendor, multiplatform network environment. Yet until recently, the. multivendor part of the equation was missing.

At the heart of multivendor inter-operability is the Internet Inter-ORB Protocol (IIOP), introduced with the Corba 2.0 version of the OMG's object request broker (ORB) specifications more than a year ago. IIOP addresses how Corba applications communicate in a distributed environment. IIOP is the version of the General Inter-ORB protocol that runs over a TCP/IP network. There are other GIOPs under development for other network transports such as Novell's IPX and IBM's SNA protocols. Object tool vendors are finally making IIOP and distributed objects a reality. This means customers no longer must depend on one vendor to meet their distributed-computing needs.

Now that multiple ORB vendors support IIOP, companies can mix and match best-of-breed ORBs. One vendor might offer the fastest ORB on the market. Another might have the smallest embedded ORB. With IIOP, all these different object components can interoperate within and between systems.

A company might use this technology in migrating an OLTP (online transaction processing) order-entry system from a mainframe to a browser-based application. An ORB that runs on MVS from Iona Technologies could be placed on the mainframe to allow wrapping of the jobs that will remain on the host Another ORB that supports Corba's Object Transaction Service could be used on a Unix server to migrate some of the jobs off the mainframe. A third ORB--say the Java ORB from Visigenic Software--could be used to write Java client applets for the browser interfaces. All ORBs can invoke methods upon one another. Each ORB is selected because of its ability to perform its specific function.

IIOP also lets an IS department use a consolidated approach to system development. Large organizations typically have multiple, concurrent development projects-- each selecting the technologies that best meet their particular needs. IIOP provides interoperability among these previously independent systems and simplifies systems integration--at least from a communications standpoint.

Test Results

Our lab evaluations of seven ORB products show that impressive progress is being made (see chart, p. 4A). We selected the products from Iona Technologies, Sun Microsystems, and Visigenic Software as a representative sample of ORB products available in the market. Iona, whose world headquarters are in Dublin, Ireland, has long been synonymous with Corba, having marketed one of the first Corba ORB products. Sun has distinguished itself with the phenomenal early success of the Java language, and the company is integrating Java with Corba into its Joe and NEO products. Visigenic acquired its ORB technology (ORBeline and Black Widow) from Post Modern Computing. Netscape recently licensed Visigenic's technology for inclusion in its Web browser and server products.

We selected a few enterprise business classes from our business Object library for evaluation. Test interfaces corresponding to the business objects were specified using Corba's Interface Definition Language (IDL), which lets developers define each object's interface The IDL interfaces were then compiled using each vendor's particular IDL compiler.

IDL compilers are used to generate server skeletons; these provide the starting point for implementation of server objects. IDL compilers also generate client stubs, which allow for remote method invocation on server objects by client applications. Each of the ORB products we evaluated provided sample documentation and examples that made it easy to create server skeletons and client stubs.

The next step involved the creation of an Interoperable Object Reference (IOR) for each of the server objects. An IOR is a string of characters which can be used by client applications to reference a server object across ORBs that support IIOP. Most important, an IOR is not vendor-specific. A VisiBroker client, for instance, should be able to access an Iona Orbix or Sun NEO server object if it has a valid IOR for that server object.

We created IORs using whatever approach we deemed most appropriate for that particular vendor. In the case of the NEO server objects, we wrote a simple client application that used NEO's proprietary method for first creating a reference to a server object, followed by converting that reference to a string using a stringify method on the object reference. The NEO stringify method is a proprietary wrapper around the object(underbar)to(underbar)string method. The Corba 2.0 stringify method converts an internal Corba object reference to an ASCII string.

In the case of the Orbix and Visigenic ORBs, we placed source code in the server object's implementation, which converted the server object's reference to an IOR the first time the server object was instantiated. IORs were placed in files so they could be accessed by C++ clients. In the case of Java applets, the IORs were passed as parameters to the applets.

Finally, we created client applications and applets to access the

Interoperability: A sample application tests client-server communications among various IIOP implementations. server objects using the IORs. After ensuring that each product's client. worked with its corresponding. server implementation, we then explored its cross-product and cross-platform interoperability. Each client was tested for:

correctly instantiating a server object using an IOR;

correctly causing the implementation to be started if it wasn't already running;

correctly invoking the object method;

correctly managing a diverse range of IDL data types, including strings, integers, foating-point numbers and sequences;

correctly receiving and handling any exceptions that we generated.

Our evaluation demonstrated that that IIOP does work (see chart, p. 6A).

Our main objective in evaluating the ORBs was to demonstrate functional interoperability. While some data regarding relative performance was also collected, we believe that comparisons of remote-method-invocation speeds is of secondary importance. We've found that the true issues of application performance using Corba ORBs are based much more dramatically on system architecture issues--such as the allocation of logic, persistence mechanisms, implementation object model, server implementation, and threading--than on the speed of the request over the network.

Java ORBs

One of the most pleasant surprises during the evaluation was the strength of the Java-based ORBs.

A though these products have been on the market only a short time, it's obvious that they were designed with a strong emphasis on IIOP support--which is not surprising given that Java is a likely choice for developers when creating distributed client applications.

Each of the three Java-based ORBs interoperated correctly with all of the server objects. The Java client applets were tested on a wide range of platforms, using both Netscape Navigator 3.01 and Microsoft Internet Explorer 3.0 browsers.

Although the ORB vendors still . have some work to do with regard to apples security, the ORBs we tested provide a reliable means for accessing distributed objects from Java applets.

At the time this article was written, there was still no OMG-adopted specification for mapping Corba IDL to the Java language. This spec is expected to be complete this spring, with compliant vendor releases to follow shortly thereafter. Until then, source code written for one Java ORB might not directly port to another vendor's Java ORB; however, the ORBs should be able to interoperate via IIOP.

Visigenic offers one of the most robust and easy-to-use Java ORBs (as well as a solid C++ ORB). Visigenic uses IIOP as its only communications mechanism, so there is no mapping to a proprietary internal protocol. It makes sense that Visigenic's implementation of IIOP was the most robust of those we tested.

The ease-of-use aspects of Visigenic's products include the generation of an intuitive C++ server skeleton, elegant IDL-to-Java bindings, and development-environment support for creating clients and servers. Ease of use is certainly relative. None of the products tested could be called an Integrated Development Environment (IDE) and none matched the ease of use of products like Microsoft's Visual Basic and Visual C++ or Symantec's Cafe. But then, ORB products must be supported on multiple platforms in order to really meet the goal of interoperability, and many of these platforms would not support a visual IDE (such as mainframe environments like MVS).

Distributed Capabilities

Iona leads the Corba ORB marketplace in both market share and mindshare. To strengthen its base product, Iona has successfully established key partnerships with companies such as Transarc Corp. and Isis Distributed Systems, which has resulted in the addition of object transaction services and fault tolerance.

Having long provided a C++ ORB and having ported this ORB to an extraordinarily wide number of platforms, Iona recently introduced its Java ORB product, OrbixWeb. We were surprised to encounter a number of problems in getting Iona's C++ ORB to work with other vendors' ORBs.

Our greatest concern was that the Orbix 2.1 C++ client was unable to interoperate with NEO and VisiBroker server objects, even though it was able to interoperate with Orbix server objects using IIOP. Of less concern was NEO's inability to interoperate with an Orbix server object, since the NEO product we evaluated was a beta release.

Iona was generally helpful in working with us to solve these problems. But we were surprised that we had to call on support so often to do something that should have been simple and relatively transparent.

Sun had the most comprehensive offering of those we tested. Sun promises to provide a number of services in addition to the base ORB, including Naming Service, Property Service, Lifecycle Service, Event Channels, and Relationship Service. While we verified that these services were in the beta, we did not test them extensively.

In addition to the ORB and the services, Sun's offering also provides a fair amount of support for a truly scalable development environment, addressing issues such as separation of development and production environments, migration of implementations from development to production, as well as deployment and administration support.

This is primarily due to the fact that Sun's C++ ORB is supported only on the Solaris platform, which makes it easier to support a more complete development and production environment.

Sun's ORB and IIOP implementations functioned as well as the other vendors', although there were some shortfalls in what we have come to expect from a Corba ORB (such as a lack of support for(underbar)var and (underbar)ptr mappings, which meant we could not perform some space-or time-sensitive memory management). Sun claims these issues will be addressed in the production release, which should be available this month. Though we tend to take vendor promises with a grain of salt, we are excited about the potential of the eventual Sun product.

Wider Specifications

OMG's Corba specifications cover both the ORB and a number of additional services. Version 1.0 of the Corba specifications failed to adequately cover the issue of ORB interoperability. While the advent of Corba 2.0 ORB specifications came a long way toward pinning down the holes that were in the version 1.0 specification, there are still a number of areas left either unaddressed or loosely addressed. This allows a fair amount of variability in vendor implementations.

Corba 2.0 compliance has not yet completely solved the interoperability problem, in part because a standardized and accepted compliance test suite is still being worked out. Despite the issues of compliance, our evaluation indicates that ORB vendors are racing toward plug-and-play interoperability.

Which product is right for you? That depends on your environment. Visigenic's IIOP, Iona's support for Object Transaction Services and fault tolerance, Sun's consideration of large-scale development issues--what is most important? The most exciting aspect of IIOP is that you can mix and match vendor ORBs in your enterprise to meet a variety of distributed computing challenges. Each of these subset solutions will work together and provide a common foundation for object-oriented code development and component reuse. We've never been closer to realizing the promise of distributed objects.

~~~~~~~~

By Michael McCown and Jason Pritchard

Michael McCown is VP of business systems and Jason Pritchard is a senior software engineer with PSW Technologies Inc., an Austin, Texas, systems integrator specializing in object-oriented application development and distributed systems. They can be reached at mccown@pswtech.com and jason@ pswtech.com, respectively.

 

The Internal Inter-ORB Protocol is a messaging protocol that lets object request brokers (ORBs) communicate across Internet domains. IIOP specifies how General Inter-ORB Protocol messages are exchanged using TCP/IP connections. GIOP is a protocol-independent interface that specifies a standard syntax and set of message formats for communications between ORBs.

 

IIOP supports seven message types: Request, Reply, CancelRequest, LocateRequest, LocateReply, CloseConnection, and MessageError.

 

A request encodes a request for invocation from the client to the server. A Reply encodes a reply from the server to the client. A CancelRequest is sent from the client to the server to indicates that it is expecting a response for a particular message. A LocateRequest is sent from the client to the server to determine whether an object request is valid, whether the server can receive requests for an object reference, and what the address is for the server handling the request for that object reference.

 

A LocateReply is sent from the server to clients in response to a LocateRequest. A CloseConnection is sent from the server to the clients to indicate that the server is closing a connection. A MessageError is sent in response to any GIOP message whose version or message type is unknown.

 

Stubs/Skeletons
    GIOP
    IIOP
   TCP/IP

Building block: IIOP is the TCP/IP version of
the General Inter-ORB Protocol.

DATA: OBJECT MANAGEMENT GROUP

 

Vendor                  Product           Platform

Iona Technologies       Orbix 2.1         Sparc/Solaris 2.5
Cambridge, Mass.
800-672-4948            OrbixWeb 2.0      Sparc/Solaris 2.5
www.iona.com

Sun Microsystems        NEO 2.0           Sparc/Solaris 2.5
Mountain View, Calif.
415-968-6292            Joe 2.0 (beta)    Sparc.Solaris 2.5
www.sun/com

Visigenic Software      VisiBroker for    Windows NT 4.0
San Mateo, Calif.       C++ 1.51
415-286-1900            VisiBroker for    Sparc/Solaris 2.5
www.visigenic.com       C++ 1.51

                        VisiBroker for    Sparc/Solaris 2.5
                        Java 1.2.4

Vendor                  Language

Iona Technologies       C++
Cambridge, Mass.
800-672-4948            Java
www.iona.com

Sun Microsystems        C++
Mountain View, Calif
415-968-6292            Java
www.sun/com

Visigenic Software      Visual C++
San Mateo, Calif.
415-286-1900            C++
www.visigenic.com

                        Java

DATA: INFORMATIONWEEK

 

Legend for table:

A - VisiBroker Server NT 4.0 C++
B - VisiBroker Server Solaris C++
C - VisiJava Server Java
D - Orbix Server C++
E - NEO Server C++

                        A        B        C        D        E

VisiBroker NT 4.0       X        X        X        X        X
Visual C++ client

VisiBroker C++          X        X        X        X        X
TTY client

VisiBroker Java         X        X        X        X        X
applet

Orbix C++ TTY           --       --       --       X        --
client

OrbixWeb Java           X        X        X        X        X
applet

NEO C++ TTY             X        X        X        --       X
client

Joe Java applet         X        X        X        X        X

DATA: INFORMATIONWEEK

 

DIAGRAM: IIOP In A Distributed Object Environment

 

PHOTO (COLOR): Interoperability: A sample application tests client-server communications among various IIOP implementations.

Section: NEWS

Four industry powerhouses are banding together to accelerate object standards on the Web in direct opposition to MicrosoftCorp.'s object standard efforts.

The goal of the alliance between IBM Corp., Oracle Corp., Sun Microsystems Inc. and Netscape Communications Corp. is to enhance and fill holes in the Object Management Group's (OMG) standards,including the Common Object Request Broker Architecture (CORBA), so the standards can work well with the new breed of Internet applications. There is no timetable set up for the rollout of the plan.

The move makes it easier for VARs to build CORBA-based applications, but they increasingly will have to choose between CORBA and Microsoft's object standard,said vendors and analysts.

"What we want to do is accelerate to Web speed these standards," said Jerry Held, senior vice president for server technologies at Oracle. "We want to provide a clear alternative to those proprietary standards such as ActiveX from Microsoft."

Specifically, the group is trying to coalesce around Netscape's Internet inter-orb protocol (IIOP) standard and the various IIOP interfaces.

But the alliance also is developing standards such as security services, naming services, transactional services, directory services and other items, which are not yet part of CORBA or are deemed inadequately defined by the four companies.

The four companies have pledged to first come up with their own standards in these areas, then to make their own particular development environments adhere to the standards. They then will submit these standards to the OMG for approval.

Executives from the four companies did not say what technologies would be priorities or give a timetable of when the enhancements would be submitted to the OMG.

"We are focused on 1997; although there are a number of areas that will take us beyond 1997, there are some specifications that we are working on right now," said Steve Mills, general manager of IBM's Software Solutions Division.

Microsoft, which seems to be the main target of the alliance, was quick to respond tO the initiative. "Somebody had to do something about CORBA because there is no interoperability and it doesn't add much value to customers," said Cornelius Willis, Microsoft director of platforms marketing.

Karen Boucher, director of research at the Standish Group, Dennis, Mass., said CORBA does have some problems. But she said those problems can be solved. "This stuff does work--it is difficult sometimes, but it does work."

The alliance's work would make it easier for developers to build CORBA applications that interoperate, she said.

"Individually, it's hard for these companies to go against Microsoft, but together they have a good story," she added.

"If you are an Oracle developer, it will now be easier [also] to become a Netscape developer," said David Pann, group product manager at Netscape.

It is unclear how the rest of the OMG, which has 700 members, will fit into the plan. But Boucher implied that whatever the four companies decided would be accepted by the OMG.

"By us [four] endorsing it, we think it will be the de facto standard," said Pann. Industry observers, however, said the OMG processes would not be circumvented.

FAST FACTS

VARS WILL HAVE TO CHOOSE BETWEEN CORBA, MICROSOFT.

OBJECT MANAGEMENT GROUP TO APPROVE ALLIANCE'S NEW STANDARDS.

~~~~~~~~

By SHAWN WILLETT, San Mateo, Calif.

Section: COBRA technology

THIS WEEK'S Object World exposition in Boston will demonstrate the increasing proliferation of products based on the Object Management Groups (OMG's) CORBA.

Many CORBA developers will unveil products that implement the latest OMG specifications, including security and transactions, while crucial additions to the architecture -- such as messaging and standards for analysis and design -continue to be honed.

Despite its recent momentum, the CORBA market faces the imminent challenge of Microsoft's Distributed Component Object Model (DCOM) technologies, which spearhead the Redmond, Wash., software giant's enterprise software push.

"The lack of [Transaction Server] DCOM and Falcon [message-oriented middleware] from Microsoft gives CORBA vendors an important window of opportunity over the next 18 to 24 months, but Microsoft will get there with the DCOM infrastructure, transactions, and messaging," said Melinda Ballou, senior analyst with the Meta Group, in Stamford, Conn.

In addition to hammering out the integration of messaging support within the CORBA architecture and bridging DCOM and CORBA, the OMG is working on a Portable Object Adapter for the portability of object request brokers (ORBs).

Among those vendors looking to push objects toward the mainstream is Platinum Technology, which this week will unveil entry-level and departmental versions of its Paradigm Plus analysis and design package.

The company's Paradigm Plus Learning Edition and Professional Edition are single-user versions of the enterprise-level tool that sport limited versions of its modeling and round-trip engineering capabilities. The Learning Edition will be distributed for free; the Professional Edition will cost $1,495 for a single-user license.

ICL Inc. will update its DAIS ORB with security services that conform to the OMG's security specifications, including user authentication, access control, security associations, message protection, auditing, and administration.

Expersoft will unveil an upgrade of its CORBA-plus C++ ORB that boasts a 40 percent performance boost and support of CORBA events and relationships services.

Irish middleware developer Iona Technologies, which last week issued an initial public offering, will debut an implementation of the CORBA Trader technology that applies fuzzy-logic search capabilities to object browsing.

~~~~~~~~

By Ted Smalley Bowen

Section: ENTERPRISE COMPUTING: MANAGEMENT

IN TODAY'S highly competitive business climate, it's just as important for a bank to get its products and services to market as it is for manufacturers, says Isaac Applbaum, president and CEO of Concorde Solutions, in San Francisco, a recently formed subsidiary of financial giant Bank of America.

"Our mission is to empower the bank's executives to get at their information through the A4 paradigm: anywhere, anyplace, anyhow, anyway," Applbaum says.

That information exists within a horizontal framework in many disparate legacy systems in the bank's enterprise. Until a few months ago, Bank of America's business managers did not have an easy time collating all the vital financial data about a corporate customer on their desktop PCs.

One of the applications Concorde developed was a corporate-customer, relationship-management system called Vista. It allows you to take accounts and drill down and extract customer information from many varied systems. The tools that built this application were based on CORBA-compliant object-oriented technology.

THE OBJECT-ORIENTED SCOOP. Bank of America did not reach into a magician's hat and decide on a whim that object-oriented technology was the solution to a complex business process. The bank's flirtation with object-oriented technology began in 1991. It had just rolled out a client/server re-engineering product that it hoped would solve the problems it was having with specific mainframe applications that resided in the telecommunications area.

"The applications weren't scalable," says Narinder Bajwa, the systems architect who piloted the bank's first use of object-oriented technology. "They were difficult to maintain and even more difficult to evolve and adapt to meet our rapidly changing business conditions."

But the bank soon discovered that the client/server concept coughed up a variety of interoperability and administrative issues IT wasn't prepared to handle. Bajwa and his team decided that object technology might provide the right solution.

With the assistance of outside consultants and mentoring assistance from IBM, Bajwa had a working prototype of his Network Management and Configuration application ready in six months. It took another year to pilot test and deploy the application. Although its roll-out in early 1993 was hugely successful and won the bank some industry awards in 1994, no one was jumping on the object-oriented technology bandwagon --yet.

Bajwa and his associates were aware that before more object applications were designed, several key functions had to be put in place. These he characterized as an infrastructure of object-based components that communicate across the enterprise and as a development process for the program modeling.

"The application has to be able to speak the user's language," Bajwa says.

To create this synthesis, it is necessary for developers to work closely with users during the program modeling so that the application responds intuitively to the way users need access to data. Dumping an application on a user's desk is not the answer, Bajwa adds.

Somewhere down the road the business process will change, and developers have to respond by making those changes quickly.

"If you involve users in the development process to the point where they understand how objects work, their input on future revisions will be most helpful," says Paul Westover, vice president of global payment operations, who has worked closely with the banks object-development teams.

THE HIRED GUNS. Bank of america created Concorde in 1995 to build object functionality into the bank's existing mainframe systems and to create a library of business objects that could be used and reused throughout the bank.

"We're domain experts," Applbaum says. "We understand what to build and how to build it, and we bring in partners to help us build specific applications."

So even before the Corporate Customer Relationship Management System was coded, Concorde built the Data Object Module (DOM).

Applbaum characterizes this as Concorde's most critical contribution to the bank's enterprise. It's the transport broker that sniffs out and collects the legacy data across many varied systems, from mainframes to servers such as IBM RS6000s, Sun Sparcservers, and Hewlett-Packard HP9000s.

DOM was designed as a series of business objects that can talk to all the different middleware, whether it's MVS or CICS. And because DOM was built around the CORBA architecture, its components can be plugged in to any application.

"Many companies fail with objects," Applbaum says, "because they try to build applications before they have their architecture and infrastructure in place."

Applbaum says that the Corporate Customer Relationship Management System took 15 months to develop using Microsoft C++ and IBM's System Object Model toolkits. He says that Concorde is investing extra time and money to make certain that object modules have as much reusability as possible.

"Building a one-off application would be a lot faster," Applbaum says, but that's not building for the future.

By creating reuse the first time, developers can reduce the amount of time it takes to write future applications.

Applbaum says that there have been significant reductions in development time on the second application that is scheduled for rollout later this year in the bank's consumer retail-banking division because many common business objects can just be plugged in.

Called the Credit Card OnLine System, it will allow customers to access information about their credit-card history via the Internet. The bank side of the application contains customer-service functionality, customer-credit information, cycle-state information, account history, and transaction history.

Because Concorde isn't married to any one set of CORBA-compliant object tools, it is following a path of using the best solution available for a specific application. For example, Hitachi's transaction-processing monitor and Visigenix's object request brokers (ORBs) provide the core tools for the credit-card application.

Now that ORBs containing vertical-market solutions for the financial industry are arriving, Applbaum's subsidiary is evaluating them for future object-application development.

"That makes a great deal of sense," says Karen Boucher, senior analyst with The Standish Group, in Dennis, Mass. "Why reinvent the wheel when you can buy a packaged ORB that gives you up to 85 percent of the functionality that you need to build your application." The savings can be enormous, she adds.

Bank of America is determined to be a leader in object development for the financial services and banking industry, Applbaum says, and Concorde will be given the go-ahead to license and sell its core business objects to other financial institutions.

PHOTO (COLOR): USING NEW APPLICATION TOOLS, Bank of America's Narinder Bajwa and Isaac Applbaum have reduced development time.

Problem: How to speed up application development to solve changing business conditions.

Solution: Use CORBA-based object-oriented technology.

Benefit: Can reuse existing business objects to build foundations for new applications, thereby saving development time and money.

~~~~~~~~

By Peter Ruber

Peter Ruber is an Oakdale, N.Y.-based freelance writer.

 

There can be no better example of the advantages and flexibility of objects, says Paul Westover, Bank of America's vice president of global payment operations in San Francisco, than the year-2000 project that has given IT departments anxiety attacks for the past few years.

 

Vast sums of money and time have been spent employing countless legions of programmers and engineers to sift through billions of lines of code to find and change those simple lines of code for the time bomb that would have shut down their enterprises when system docks reached the year 2000.

 

"In the object world," Westover says, "that would have been a simple solution."

 

Because system date-time information would have been developed in a single business object and reused many times, changing the code would have been a routine software-maintenance project.

 

"Once that change was made, the new object could have been plugged in to every system in the enterprise. Ergo: no year-2000 problem," Westover says.

Section: BEST 1996 TECHNOLOGIES

One of the major technology trends in embedded systems in 1996 has been the move by software developers and systems designers to incorporate the common object request broker architecture (Corba) into their products. Already accepted in the desktop, workstation and server markets, Corba offers cross-plat-form portability and the availability of development tools from more than 500 vendors.

However, embedded developers face drawbacks: memory requirements beyond the limits of many designs, slower performance due to additional overhead required by the object layers, and the need to learn a new language and set of interfaces.

Nevertheless, Corba is gaining in embedded systems. The most recent sign was this year's introduction of Integrated Systems Inc.'s (Sunnyvale, Calif.) Prism+ embedded-development-tools suite built around an object bus that conforms to the Corba 2 standard, a middleware specification created and controlled by the Object Management Group standards body. Supported by more than 700 companies, the Corba object bus provides a unified system architecture and capability to support components that run in the same process, as well as components that run across a distributed system.

It also provides an extensive set of bus-related services for creating and deleting objects, accessing them by name, keeping them in persistent store, externalizing their states and defining ad hoc relationships. The object request broker (ORB) is the middleware that establishes client-server relationships between objects. An ORB allows a client to transparently invoke a method on a server object on the same machine or across a network. It intercepts a client call and is responsible for finding a server object that can execute the request, passes the parameters, invokes its method and returns the results.

This is all accomplished without the client having to know where the object is located, its programming language, its operating system, or any other system aspects that are not part of an object's interface. The Corba ORB provides complete interoperability between applications on different machines in heterogeneous distributed environments, seamlessly interconnecting multiple systems within a work group, an enterprise, a LAN, or a WAN.

In the ISI implementation, the Corba bus is used to link development tools, all of which are accessible via the Prism+ Manager graphical user interface; a set of dedicated servers that provide support to all client software tools; and a set of support services. The tools linked together fall into three categories: project management tools; development tools for coding, debugging, and integration; and analysis and visualization tools. All are provided a common set of services via four types of server programs: the repository and symbol server, the debug server, the communication server, and the Prism+. In addition to the Corba bus, what makes the new tool suite unique, said John Hogan, director of product marketing at ISI, is the linkage to all of the Corba services provided by the more than 500 software vendors in the Object Management Group (OMG).

The introduction by ISI is the most recent move by embedded tool vendors to accommodate the Corba 2 specification, a process that started late last year with many of the RTOS vendors working out cross-licenses and technology agreements and integrating a number of Corba-based tools into their development environments.

Telecom imperative

Initially, the key reason for the move was the increasing importance of Corba to the telecom market and the providers of the switch-based public telephone and telecommunications, such as AT&T, MCI and U S West.

Stephen Li, vice president of telecom products at WindRiver Systems Inc. (Alameda, Calif.), said the telecommunications companies have long been users of embedded processors and OSes, but until the last few years, on the software side at least, telecom vendors have stuck to an inhouse strategy. But with the opening up of the telecommunications market to a wider range of companies, telecom providers are outsourcing many components of their hardware and software, going to the embedded market for off-the-shelf designs. "They are also the biggest backers of standards and have played a key role in promoting and sup, porting the Corba specification," Li says. "So any hardware or software vendor who wants to play in that market had better be aware of that."

This has led many of the leading RTOS and development-tool vendors, including ISI, Microtec and WindRiver, to link tools from a variety of Corba-based providers into their environments. Some of the most important Corba vendors are Iona Technologies Inc., an ORB development-tool vendor; ObjecTime Ltd., a real-time object-oriented tool provider; and Visigenic Systems Inc., a Corba tools and services vendor. "As reliability and correct code become more of an issue, especially in markets like telecommunications, such tools remove another portion of the software with which the engineers have to concern themselves," said Jim Ready, chief technical officer at Microtec (Santa Clara, Calif.). "This approach also reduces the relearning time to become competent in the intricacies of Corba compliance and decreases the time it will take to get to market."

A second reason for the increased attention to Corba has been the emergence of embedded-systems and RTOS opportunities in set-top boxes, Web TVs, network computers and information and Internet appliances. "A key aspect of all of these devices is the idea of thin clients, which contain a minimum of applications software and just enough of a kernel to run the graphical user interface," said Dan Hildebrand, senior software designer at QNX Systems Software Ltd. (Kanata, Canada).

"The servers take over the vast majority of the computing operations," he said, "with only the results displayed on the connected thin client."

Getting the paradigm to work requires not only a distributed-objects environment, but one in which the objects can function on any platform, independent of the underlying OS or hardware. That requires adherence to a common standard such as Cor-ba to achieve such platform independence and interoperability, Hildebrand said.

Beyond such emerging markets, said Ready, a wider role for Corba in the embedded market is not likely soon. "A common characteristic of these new markets is that while the memory requirements are smaller than those required for the desktop, typically from 1 to 4 Mbytes vs. 8 to 16 Mbytes, the extra memory space to allow for the extra layers of software that the protocols would require would fall very easily within this range." But for traditional embedded applications, even those that require some form of distributed control, that's far from the case.

Li said work is under way within the OMG to come up with a subset of Corba that is more appropriate to the embedded market. "There is a lot of overhead in the existing specification, which was designed mainly for desktop systems, that is simply unnecessary in the embedded environment.

"The trick will be to come up with a set of features and capabilities appropriate to the embedded market, without violating the spirit of the full specification. That ... will not occur very soon."

DIAGRAM: Cobra is object of ISI bus

SOURCE: ISI

~~~~~~~~

By Bernard Cole

Section: Embedded Systems

Developers' demands for applications and tools that interoperate within an open framework have resulted in the development of the common object request broker architecture, or Corba, an inter-application communications standard that was introduced in 1991 by the Object Management Group (OMG). OMG is a non-profit industry consortium dedicated to promoting the theory and practice of object technology for the development of distributed computing systems.

Corba's platform-independent nature provides a seamless communication mechanism that enables developers to access information transparently--that is, without having to know which software or hardware platform that information resides on or where it is located on a network. Corba 2.0, introduced in 1994, defined true interoperability by specifying how object requestbrokers (ORBs) from different vendors can operate together.

The ORB is the middleware that establishes client/server relationships between objects. The Corba ORB provides complete interoperability between applications on different machines in heterogeneous-distributed environments, seamlessly interconnecting multiple systems within a work group, an enterprise, a LAN or a WAN.

Integrated Systems Inc. (ISI) adopted Corba as its open tools framework for the company's Prism+ embedded development tools and for interprocess communications in ISI's pSOS realtime operating system. Other highly influential industry players, such as Netscape Communications Corp., Oracle Corp. and Informix Software Inc., have also announced Corba initiatives.

As a software backplane for an embedded-software tool-development environment, Corba's Internet InterORB protocol (IIOP) lets objects use queues and interprocess communications to speed up message delivery and reduce overhead. IIOP transport services are provided for interoperability between heterogeneous ORBs,and IIOP allows objects developed using different Corba ORBs to interoperate transparently.

Abridge between Corba and Microsoft Corp.'s object linking and embedding (OLE) even allows Corba-compliant applications to communicate with commercial OLE-compliant analysis software.

ISI's embedded development tool, Prism+, was created around two key technical concepts: Prism+ servers, and an open, distributed, Corba-based communication framework. The implementation of these concepts allows Prism+ tools to be tightly and efficiently integrated with other tools-of-choice from other vendors. Both Prism+ tools and servers interface with the Corba bus via a common API known as interface-definition language (IDL). Components written to the Corba IDL are portable, and can be bound to various programming languages such as C/C++, Java and SmallTalk, and can be used across heterogeneous networks.

New initiatives on the part of the Corba Object Management Group, in relation to the Internet, bring an additional set of possibilities to a design environment built around the specification. In particular, OMG has started a new initiative to demonstrate Corba interoperability via the World Wide Web. Called Corbanet, its focus will be to provide Corba-based product vendors with a vehicle to demonstrate interoperability, and their Corba2.0 conformance, to a worldwide audience through the Web.

In addition, Netscape Communications Corp. is strongly promoting the Corba IIOP as a new Web protocol, and is planning to integrate Corba into its products. Netscape's latest offering, the Netscape ONE development environment, will include support for a distributed-object model based on the IIOP standard. Netscape ONE is an open network environment, based on publicly defined standards, which lets developers and enterprises quickly and easily create robust, dynamic, cross-platform Internet/intranet applications.

Netscape ONE's IIOP-compliant infrastructure transparently supports distributed method innovation for Java classes. This infrastructure includes IIOP-compliant Netscape Internet foundation classes, making it easy for developers to build Web-based distributed applications. In addition, client/server systems that are Corba-compliant can be interfaced to Netscape ONE applications via the IIOP protocol. Netscape also plans to include a fully IIOP-compliant ORB into Galileo and Orion.

Other companies also have announced their intentions to employ Corba.

DIAGRAM: Corba means interoperability. SOURCE: ISI

~~~~~~~~

By Nick Epperson, Director of Tools Integrated Systems, Inc. Sunnyvale, Calif.

Section: Top Of The Week

Bank of America's Concorde Solutions Inc. software subsidiary announced last week plans to build an object-based customer service system that will let credit-card holders access account information over the Internet. The system, due next spring, will be based on Corba, a network-independent standard for deploying distributed objects. The project marks Bank of America's second major deployment of Corba. The company is already using an object-based customer relations management system called Vista.

The forthcoming system, Concorde CreditCard OnLine, will give the bank's credit-card customers access to their accounts over the Internet and let them perform the functions normally available via a customer service line, such as checking balance and payments, says Isaac Applbaum, president of Concorde Solutions in Concord, Calif.

Concorde chose Corba because the company felt no other architecture delivers the kind of scalability necessary for handling a large volume of users and data. "We like Java, but we don't think it will be ready when we're going to be ready," says Applbaum. "With Corba, we know it works. [Vista] is in production, and it works."

CreditCard OnLine will be built on Hitachi Ltd.'s TP-Broker object transaction manager, a combination of Hitachi's OpenTP online transaction processor and Visigenic Software Corp.'s VisiBroker Object Request Broker. CreditCard OnLine is set for deployment to Bank of America employees in March, with full consumer availability coming in June, says Applbaum.

"What they are doing is absolutely incredible," says Karen Boucher, an analyst with the Standish Group, a consultancy in Dennis, Mass. "Concorde has pushed Bank of America further into object technology than any other company I've seen. Vista and CreditCard OnLine have proven that objects are capable of creating mission-critical transactional applications."

PHOTO (COLOR): Sure: Concorde chose Corba because "we know it works," says Applbaum.

~~~~~~~~

By Andy Patrizio

Section: APPLICATION DEVELOPMENT

 

As object-oriented development takes off, corporate developers find they need tools to distribute objects across all major operating platforms

For a technology that has languished for several years, the Object Management Group's Corba specification is showing strong signs of life. Interest in Corba-related products is at an all-time high, as evidenced by a slew of product announcements over the past several weeks.

"Corba is starting to grow up," says Jeffrey Nickerson, technical director of emerging technologies for Coopers & Lybrand in Edison, N.J. "Corba development tools are maturing, and corporations are building applications with them. Most important, the tools vendors recognize there's a market here."

Having the support of major tools vendors is critical to Corba's success, Nickerson says. "Corba is great, but look at the size of the companies support it. They're tiny. The involvement of big, stable companies, like Sun and IBM, will give users a feeling of security." In fact, Sun Microsystems and IBM recently announced a cross-licensing deal to share their respective object technologies (IW, Aug. 19, p. 15).