What Will Come

In the swirl of events around the announcement last year of the upcoming CORBA 3.0, the attention centered on the upcoming CORBA Component Model. While CORBA has existed in some form or another as an adopted technology of the OMG's open, neutral, standards-setting process since October 1991, this year's major revision point for the first time will address a wealth of issues that point at deployment rather than interface. Let me explain.

A decade ago the Object Management Group started down the road to infrastructure and end-user standards for interoperability in heterogeneous enterprise-wide systems. Ever since, the focus of our work has been on declaration of interfaces. Interoperability achieved through declared interfaces, especially through declaration in an interface definition language (such as OMG IDL), is a powerful concept: it supports team-oriented software construction (through clearly spelled-out interface contracts that can be built on many platforms in many languages); it is the basis for real architectural design of systems; and it is critical for long-term system maintainability. On the technical side, it also takes away from the programmer the pain of dealing with interprocess communication and network communication protocols, allowing programmers to concentrate instead on system definition (and therefore the "business logic" that needs to be implemented). All from a simple, unassuming IDL.

In 1995 OMG took a huge step forward when we not only fleshed out better support for portability, but, more important, defined a basic interoperability protocol, the Generic Inter-ORB Protocol (GIOP), for connecting CORBA systems (along with the better-known TCP/IP mapping of GIOP, the Internet Inter-ORB Protocol, or IIOP). It's important to note that most programmers never see GIOP or IIOP; rather, CORBA implementations layer automatically generated stubs, skeletons -- in effect, generated protocols -- over IIOP to ensure end-to-end interoperability between applications relying on CORBA to perform their interapplication communications.

Since those days the OMG itself has changed character significantly. Today it comprises 800 member companies, nearly half of them end users of information technology (like Citigroup, Boeing, Bellsouth and 3M), or vertical-market independent software vendors (ISVs) rather than vendors (though big names like Microsoft, Sun Microsystems, Hewlett-Packard and Fujitsu are longtime members). The OMG's open, neutral, consensus-making process today has underway about a hundred standards processes. They range from the traditional OMG infrastructure definition and maintenance (CORBA itself, the Unified Modeling Language, services for security and authentication, transactional integrity, event notification, application internationalization and even print service management) to vertical-market (in OMG parlance, "domain") specifications, from manufacturing part definitions and telecommunications network management to life sciences genomic maps and air traffic control systems.

Obviously, the end-user­oriented specification processes have a more immediate and obvious impact on the average end user and vertical-market ISV, who can see more immediately the value of a standardized patient identification interface that will make a hospital merger work more smoothly. Nevertheless, the CORBA technology space marches on, and for the first time addresses what some might consider an implementation technology -- specifically, software deployment in heterogeneous platforms.

In fact, the CORBA 3.0 processes to update CORBA focus on three major areas:

For the first time, CORBA specifications now address real-time provision of service and minimum-footprint (or embedded) implementation. Both areas are about maintaining interoperability, with some small sacrifice of code portability, in the exceptional circumstances of embedded, real-time, special-purpose processors. In addition, this category of new additions to CORBA features standardized interfaces for specifying required transport quality of service as well as the marshaling engine (the "IIOP" engine, in effect), which allows applications to layer on special-purpose communications transports such as messaging platforms.

A large and important part of CORBA 3.0 ­ and, more important, a group of interfaces that have already been completed ­ we term Internet/Java specifications. These include a standardized firewall specification (for passing IIOP communications through TCP/IP firewalls in a standard way). Interestingly, one of these specifications also allows for mapping, in a standardized way, from Java to IDL (rather than just the more common IDL to Java). This allows Java programmers to write only Java (and have their IDL interface definitions automatically generated from their Java code, leveraging the closeness of the CORBA IDL and Java object models). To my mind, the most exciting specifications in this category are the extensions to the CORBA Core that allow for binary portability of CORBA applications written in Java (more exactly, compiled for the Java Virtual Machine). Since the JVM represents a shared executable environment that runs on every kind of computer, CORBA-based applications can be deployed portably for the first time in binary form, a major step forward that can't be accomplished in the usual heterogeneous setting.

As I mentioned above, CORBA 3.0 also addresses deployment of distributed component software. This includes a large number of pieces and the ability of application programmers to (1) pass objects over the network by value rather than by reference; (2) support multiple interfaces on a single deployed object; and (3) integrate scripting languages ranging from Tcl to REXX to ECMAscript into rapidly deployed combinations of CORBA applications and, especially, a CORBA Component Model that allows declaration, in an extension of the usual CORBA IDL style, of the deployment characteristics (such as transactional integrity, secure access and connection details) of distributed, enterprise-wide clients and servers.

The greatest impact of these three components will likely be on the server side. Over the years, a large number of excellent tools have appeared to simplify the construction of software for the desktop, software for the client. Application builders typically start from the viewpoint of the design of a data display or update window and work toward the server with visual components that support front-end application duties. In contrast, the wide availability of deployment technologies such as CORBA Components (as well as Sun's Enterprise JavaBeans, closely aligned with the CORBA Component Model Java mapping) will make graphical server software design possible. Finally, the application service designer and builder -- for both the middle tier and the back end -- will be able to drag server components from a pallet, connect them graphically, select deployment options such as transactional contexts and security domains, and quickly deploy new business logic.

Which is the point, right? And it will come.