The interoperability issue
Next we move on to the interoperability issue. Alan claims that as I am suggesting that vendors be given the freedom to map C++ to IDL as makes best sense for their product interoperability between Object Request Brokers would become more difficult. In fact I am puzzled by Alan’s logic here since if the main issue for Object Request Broker interoperability is a standard mapping to a language then every Object Request Broker with an Object Group-approved C interface should interoperate, and they don’t. So why can’t the Object Group simply outline the IDL side of the mapping and leave vendors to decide how their use of C++ can reach it. As for interoperability, the Object Group itself explains the problem in the CORBA spec: In general, there is no single protocol that can meet everyone’s needs, and there is no single means to interoperate between two different protocols. There are many environments in which multiple protocols coexist, and there are ways to bridge between environments that share no protocols. These same truths will hold for Object Request Brokers as well.
Shoot-out shaping up
Well this is a ticklish problem isn’t it? Noble though it is, Alan’s suggestion that a single industrious vendor could build an Object Request Broker that spanned across all systems in all protocols and provided IDL mappings for all languages is unlikely to be realised and in the meantime we appear to be stuck with Object Brokers that cannot communicate meaningfully with each other. It is all very well to suggest that ORBs can communicate via RPCs or ISDN but at the end of the day Object Request Brokers will be talking to another system not to another Object Request Broker. To communicate properly Object Request Brokers must be able to pass object references to each other. In fact I think an awful lot of people would be shocked if they realised that CORBA 2.0 does not provide such interoperability. The market is looking to CORBA 2.0 to save it from vendor wars and without interoperability it fails to do this. So where does this leave the market? Well, would you believe it, we have a shoot-out shaping up between IBM Corp and Microsoft Corp for de facto control of the market for Object Request Brokers. That is, on one side we have the C/Unix/Old/Big Business/US Hardware Vendors versus the C++/PC/New/Small Business/US Software Vendors. But don’t take my word for it, go and see Object Magazine February 1994 issue where David Taylor, a respected US spokesperson for object technology, says within two months of the release of SOM 2.0, a partnership was announced among IBM, Hewlett-Packard and SunSoft to make SOM the standard distribution medium for re-usable objects. This announcement has triggered support from other vendors, so the possibility of a de facto standard for class distribution is definitely there. The only serious industry hold-out is Microsoft, which as usual is heading in an entirely different direction with its OLE-type features in Cairo… In my opinion the Object Group stands a much greater chance of retaining its influence over the object-oriented community if it stands up and says that backward compatibility between the C and C++ mappings is further delaying CORBA and so the decision has been taken to make a clean break.
Failing the market
Otherwise the Object Group and CORBA could become a tiny skirmish in the ongoing war between IBM and Microsoft. So in conclusion I will answer my own rhetorical question. Yes the Object Group is failing the market with CORBA because it cannot provide interoperability and therefore cannot insulate customers for object-oriented technology from vendor wars. Its failure to capture Microsoft’s attention on the one hand, or to act as an effective lobby for customers of object-oriented technology on the other has left it in the untenable position of riding as the jockey for IBM’s SOM stable. This summer the stakes are high for the Object Group but everybody involved in this debate should remember that the odds were set by the marketplace and I am just
commenting on the form.
