Introduction
One of the primary conditions for the rapid, reliable development of innovative embedded systems is appropriate tool support. In response to this need, middleware technologies have been developed to enable tools from different vendors to interoperate.

Heterogeneous object communication
The Common Object Request Broker Architecture (CORBA) was designed to solve the interoperability problem of independently developed applications in a heterogeneous distributed computing environment. The CORBA multi-vendor specification enables applications from multiple vendors to interoperate seamlessly either locally or across the Internet.

COM, DCOM or Corba?
The advantages and disadvantages of COM, DCOM, and CORBA are compared.

CORBA and Embedded Tools
CORBA makes it possible to assemble embedded-systems development environments from a set of component tools independently developed by different vendors, in a project- and user-specific fashion.

Gathering Support
An OMG initiative, dubbed CORBAnet, which displays CORBA and its multi-vendor integration capabilities, is garnering widespread support in the industry.

Introduction
(Back to top)

New 32- and 64-bit chips are rapidly replacing 8- and 16-bit processors. Shipments of 32-bit processors are expected to double in the three-year period ending this year, and 64-bit processors are growing at a compound annual growth rate of 377 percent, according to IDC. The primary force behind this trend is the rapid growth in complexity of embedded applications, which in turn is driven by new markets and demands for embedded applications in such innovative areas as Internet appliances, set-top boxes and smart telecommunications systems.

As manufacturers strive to differentiate their products by increasing their functionality and adding significant new features such as connectivity to the Internet, embedded systems developers are faced with an explosion of required functionality for their products. At the same time they are under extreme pressure for shorter development cycles and lower development and production cost. This makes appropriate tool support for rapid, reliable development of innovative embedded systems one of the primary conditions for project success.

In the past, the number of tool options available to an embedded systems developer was quite limited. Developers had to adapt their way of working to the particularities of the limited number of available tools, and customization to a company's particular development process was often impossible. Today this model is no longer affordable. Developers want and must use various tools from best-of-breed vendors integrated seamlessly in a project-specific configuration. Their short design lead times do not permit having to go through extensive tool customizations. In short, developers need to be able to set up their own project-specific tool box from the best task-focused tools on the market, using standard tool communication mechanisms for plug-and-play tool interoperability.

Middleware technologies have been developed to enable various tools from different vendors to interoperate. The goal of middleware is to provide a middle layer of task-specific communication between low-level services (such as operating system, or platform-dependent communication via sockets or RPC 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 platform, location (whether the tools run on the same or different workstations, or what network), what programming language they were written in, or by what vendor they are developed and sold.

Heterogeneous object communication
(Back to top)

The Common Object Request Broker Architecture (CORBA) was designed by the world's leading experts on distributed object-oriented (OO) computing who formed the Object Management Group (OMG) to solve the interoperability problem of independently developed applications in a heterogeneous distributed computing environment. The OMG is a rapidly growing non-profit industry consortium in which some 700 companies currently participate, making it the world's largest software-development consortium ever; some claim it is the most successful. Virtually all vendors involved with software development are OMG members, including Integrated Systems Incorporated.

The primary work of the OMG has been to define the CORBA multi-vendor specification to enable applications from multiple vendors to interoperate seamlessly either locally or across the Internet. CORBA 2.x implementations are offered by a significant number of Object Request Broker (ORB) vendors, and application vendors can chose any CORBA 2.x-compliant ORB to interoperate with any other CORBA 2.x-compliant ORB.

CORBA can be used from applications implemented in any of a large set of programming languages. Language bindings are available not only for the most important tool implementation languages such as C++, C, Java and Smalltalk, but also for languages such as Ada or even COBOL and Lisp.

For tool developers or systems integrators, this means not needing to know or having to care about the implementation details such as the programming language or application architecture of another vendor's component, greatly simplifying the task of application integration. First, however, developers must decide between CORBA and the other de facto standard, Microsoft's Component Object Model (COM).

COM, DCOM or CORBA?
(Back to top)

COM has, after many iterations, 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 most well-known COM applications is the integration of Microsoft Word and Microsoft Excel within Microsoft Office.

DCOM is a recent extension to COM that enables applications that are on a network to also access COM, and thus replicates many of CORBA's benefits. The primary drawback of COM at this point is that it is only fully supported on Microsoft Windows desktop platforms. Other platforms (e.g., UNIX) are only partially supported, if at all. Unlike CORBA, they are very few non-Windows applications that use COM.

The fact that COM is a solution defined by only one vendor (Microsoft), vs. CORBA, which is defined by an open consortium in a democratic process, has both advantages and disadvantages. Obviously, a vendor choosing to build on top of COM is totally dependent on Microsoft's COM strategy; on the other hand, Microsoft is certainly able to move more quickly than a large consortium like the OMG -- although the OMG has an outstanding record in regard to speed of standards adoption, compared to virtually any other software consortium.

Outside the desktop, and in particular in the embedded market, however, the consensus so far is 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 that has to 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 enable other tools to access the information in the file it is currently displaying, the debugger application 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 the case of a debugger, "get list of currently active breakpoints in that file". 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.

The interfaces objects expose can be discovered by other tools at run-time. CORBA enables clients to query for information such as "does this object support a 'print()' operation?", but in a typical implementation, the interfaces are documented in a so-called OMG IDL file. OMG IDL is an "interface definition language" defined for the sole purpose of documenting interfaces of objects on the object bus that are accessible by other tools. OMG IDL is also standardized by the Object Management Group. While regular languages (such as C) are used for programming, OMG IDL is only used to describe the interfaces of objects. An OMG IDL file, plus the agreement to conform to CORBA, is all a vendor needs to be able to interoperate with another vendor's tool; if the interface discovery mechanisms are used, not even the OMG IDL file is necessary. The CORBA ORB takes care of the rest, such as the conversion between different floating-point formats or calling conventions on different platforms, or programming languages, or where on the Internet to find the other application.

A CORBA client implementation, i.e., an application that wishes to communicate with a CORBA (server) object, talks to a local "proxy object" that is in the process space of the client. This proxy object is generated by the CORBA implementation. Its implementation redirects the call to the ORB, which in turn finds a server object that can serve the request. The ORB is responsible for marshaling the parameters, setting up a new (or reusing an existing) network connection, blocking the calling thread until an answer returns, unmarshalling the results, and returning the results to the caller.

For the client, the call just appears to be a local call to the proxy object, and thus the programming overhead for the vendor is minimal, unlike other RPC-type mechanisms that are chronically expensive to use. In reality, however, the call might have traveled halfway around the world across the Internet (or might have only gone to a different process on the same machine), the server object might be implemented in a different programming language on a different operating system, using a different CORBA vendor's implementation. In fact, the server object might even travel between invocations to a different host machine without the client noticing.

The client does not have to be aware of any other aspects than the object's declared interface. Objects on the ORB can act as both client and server. It is the CORBA ORB, and the underlying vendor-independent CORBA standard, which gives both the client and server this high level of implementation independence.

CORBA and Embedded Tools
(Back to top)

All these 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 try-to-do-it-all (and not being particularly good at anything) packages. What middleware and, in particular, CORBA make 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 impossible without compromising on the host tools because these tools depended on the specific version of this low-level protocol.

With CORBA, a middleware layer, defined in OMG IDL, can be provided 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, such a communications server can be replaced by another communications that uses a different underlying protocol; as long as the new server offers the same set of interface definitions (same OMG IDL file) as the old, the client will not even notice that the underlying protocol has changed.

This of course enables a tool vendor to focus on building advanced embedded-systems development tools, rather than having to mess around with low-level proprietary protocols whose support is typically expensive while not adding value to the tool offering. 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 can alternate on the same place within a CORBA environment. Tools that the tool vendors can make truly interoperate because they don't have to rewrite point-to-point interfaces and thus can write off tool-integration work over multiple tool integrations.

Gathering Support
(Back to top)

An OMG initiative, dubbed CORBAnet, displays CORBA and its multi-vendor integration capabilities. It is regularly shown at trade shows. The number of vendors participating is constantly increasing and many large and influential companies have made CORBA one of their strategic directions.

Netscape Communications Corporation is promoting CORBA's underlying IIOP protocol as a new Web protocol, one that is, according to Mark Andreesen, supposed to replace the ubiquitous HTTP in the long term. Netscape has integrated CORBA throughout their products, including the currently shipping Netscape Navigator 4.0 and their latest server offerings. Sun reportedly will bundle a CORBA implementation with the next version of the Java Developer's Kit. There are roughly about two dozen CORBA implementations on the market, from large vendors like IBM and Hewlett-Packard to dedicated CORBA vendors such as Iona and Visigenic. CORBA applications now number in the thousands, with no end of the growth curve in sight.

Embedded development tool vendors presently fall into two categories: vendors who have realized that CORBA enables a quantum leap in tool support for increasingly difficult embedded-systems development projects, and those who have not. Correspondingly, vendors either have built their top-of-the-line development environments, tool-integration platforms and tools on top of CORBA, or they use their older, less flexible, non-object-oriented approaches that do not scale and whose tool integration and customization potential is very limited. In the latter case, a user is still stuck in the old paradigm -- monolithic, proprietary, inflexible, and locked-in. In the case of CORBA, it is open, vendor-independent, plug-and-play, best-of-breed tools from user-configurable toolboxes, customized for this month's (almost) impossible project. And that's most certainly the user's preferred choice for development tools.