I am not attempting to answer the rhetorical title, the market can answer for itself. However, I see Corba as some very key technology over the next few years and I strongly believe people need to be well informed about this technology. Therefore, I offer the following commentary. Defining the difference between static and dynamic binding as the resolution of external reference by library look-up at compile or run-time is misleading. It ignores the fact that some dynamic library implementations do not attempt resolution until the reference is used. The distinctions between early and late binding, static and dynamic typing, and static and dynamic linking are not truly at issue. However, this definition sets the tone by being not quite correct and continues it by omission. It equates dynamic marshalling to the dynamic model (which is really a dynamic invocation model and not about binding). This omits the fact that dynamic marshaling is frequently desirable and done in a static invocation model. Since this definition is laid as groundwork for the paper to make statements about the Dynamic Invocation Interface I shall address that first. The sentence a little research will reveal that Object Request Brokers built on a static model find it difficult to support this part of the spec [the Dynamic Invocation Interface] and where they have tried have hit real performance issues might have been correct if one substituted distasteful for difficult.

Not difficult

Static implementations frequently disdain dynamic implementations because they are typically slower in performance. It definitely is not difficult. The Dynamic Invocation Interface is defined in the Interface Definition Language. IDL borrows heavily from C++ and so by extension it is related to C. The statement a large part of IDL is derived from C syntax is very misleading since IDL is strongly typed. An IDL Compiler translates (it does not compile) IDL definitions into a language mapping. The Object Group first specified a C mapping and are hard at work on a C++ mapping. C is a static language, as is C++. So, by definition, if one were to run the Dynamic Invocation Interface through the Interface Definition Language compiler, one that generated a C mapping, the result is a static language representation (client stub/implementation skeleton) on which to implement. The only difficult part of such an implementation is in dynamically identifying parameters by their type – that is discovering what something is even though you have never seen it before. But this is easy in IDL because it pre-declares a dynamic type, called an any. The any type is an aggregate that includes a blob of some value (void * in the C mapping) and a TypeCode. The TypeCode is a type specification language, through which one can describe types. It describes the blob. All implementations of the Dynamic Invocation Interface can use TypeCodes to interpret the type of parameters. One can implement the Dynamic Invocation Interface statically even though the Dynamic Invocation Interface embodies a mechanism for dynamic invocation. Any contention between models was resolved by the Object Group when it formally declared that a standard should exist for the dynamic invocation model so that a Dynamic Invocation Interface was widely available and would appear identical to all Corba clients. Vendors interested in a static invocation model did not originally believe the dynamic model required formal specification because they believed it would constrain the implementation and because a client implementor could easily do their own on an as-needed basis. Leaving this topic, we move on to the phrase the Object Group is attempting to arbitrate between what are beginning to look like increasingly incompatible Object Request Broker technologies built in C. Throughout the paper we see implications about ORBs written in C and why this is bad.

In response to last week’s piece How the Object Management Group’s Corba may be failing the object-oriented cause (CI Nos 2,428, 2433), Alan Pope from Quantitative D

ata Systems Inc, Irvine, California replies on behalf of the Object Group.

But the conclusion I reach is that ORB technology has been misinterpreted. The Object Group specified a C mapping for Interface Definition Language in Version 1.1 of the Corba. The Object Group is in the process of specifying a C++ mapping for the 2.0 version of Corba. The mapping does not dictate either the language used to implement an ORB nor the language used to implement an ORB client. ORBs in Smalltalk having clients written in Fortran are not precluded. If such implementations use only the current standard C mapping, then they would have to support a C language Applications Programming Interface. Most ORBs I have encountered are written in C++. The ORBs may or may not support the Corba specified set of C Applications Programming Interfaces (though I think they all do). Most of these same vendors also have IDL mappings other than C available. Most vendors have C++ mappings. There is also at least one Smalltalk mapping available commercially and I have heard about other language mappings. There are a lot of negative statements about C, seemingly to advocate dropping C and adopting C++. In 1990 and early 1991 this was an interesting topic, but the C mapping was provided in order to support Legacy applications and systems where C++ support or knowledge was scarce. The Object Group decided to publish a specification in 1991, knowing that delaying it until all hard problems were solved might delay the specification for years. The C++ mapping is coming. It was not and is not blocked by some Sun and Hewlett-Packard rivalry. Sun and Hewlett-Packard have been co-operating on C++ since the start. So has IBM. It did get delayed when one of the primary submitters of a C++ mapping (HyperDesk) decided that building ORBs was outside of their purview (my totally subjective interpretation) and so they dropped their submission. Object Group is definitely not involved in compiler wars or politics surrounding the C++ language. The Object Group is involved with evaluating implementations of IDL to C++ mappings in order to make a recommendation. The paper also misrepresents Object Management Group’s role as a standards body until you get to the final paragraph. It indicates that the Object Group develops a standard and then vendors adopt and adapt. What is conveniently overlooked through most of the paper is that submissions to the Object Group are based on existing implementations. After discussion, a technical evaluation and recommendation is made and this recommendation is put to a vote before becoming part of the specification. The process is actually more elaborate but I believe this synopsis conveys the point. The specification follows the implementation and not the other way around. If no one has an implementation of an IDL to Cobol mapping, then a Cobol mapping is not made part of the specification. Simple, and it works.

Feeble

One of the cited deficiencies for Corba is that it does not specify naming conventions, persistence, security and interoperability. Based on this lack, we are told that we still do not have a viable Corba spec, the Object Group’s strategy is called feeble and Microsoft’s desktop agenda looks better in this light. These are interesting conclusions for an objective journalist. It is easy to name the things that are not in the Corba 1.1 specification, the more interesting ones are all listed on the Corba 2.0 agenda. Other omissions in the Corba spec are those for which no implementation exists. Remember, the Object Group only adopts available technology. So how could they adopt an interoperability spec when no one knew how to solve the problem? Name the vendor that has solved the heterogeneous interoperability problem? The Requests for Proposals for 2.0 went out last year and are getting very close to a final recommendation. On one hand the Object Group is chastised and it is stated possibly the Object Group should retreat from too strong an involvement in this debate and leave it up to ORB vendors how they bind IDL to

C++. Here, the phrase this debate is the C++ mapping discussion (there is no bind issue). On the other hand the Object Group is scolded for not having included interoperability. Interoperability is more difficult if everyone does their own mappings. Not only that but software vendors that want to build ORB objects would lose the advantage of having compatible interfaces available regardless of the ORB. A good portion of the paper criticizes ORB interoperability.

Middleware

The Object Group’s approach was to specify Corba as middleware. The Object Group specifically did not want to specify on-the-wire protocol. The whole philosophy behind an Interface as a contract between a client and a provider is to avoid constraining or exposing the way something is implemented. Different environments require different protocols. The Object Group does not dictate that vendors cannot use the same protocol. A single industrious vendor could build an ORB that spanned across all systems in all protocols and provided IDL mappings for all languages. However, if all of the interesting development does not happen on top of a single ORB, and it likely will not, there are a variety of tried and true mechanisms available that have already been developed and tested to bridge between incompatible systems. We use them every day and are none the worse for it, though it sometimes is a nuisance. The Object Group’s agenda is what the software industry needs. If you chastise them, I am sure they would appreciate that it be for good reason.