We saw in CI No 2,428 that criticism number one of the Object Management Group’s strategy is that it may be failing the market by aligning object request broker technology too closely with C-based development and that if it is going to get heavily involved in the politics of the C++ market then it may […]
We saw in CI No 2,428 that criticism number one of the Object Management Group’s strategy is that it may be failing the market by aligning object request broker technology too closely with C-based development and that if it is going to get heavily involved in the politics of the C++ market then it may make sense to base Corba on a C++ product. Meanwhile, the fall-out from the fight that is polarising between the rivalry of Sun Microsystems Inc and Hewlett-Packard Co is doing the object request broker industry a disservice. Possibly the Object Group should retreat from too strong an involvement in this debate and leave it up to object request broker vendors how they bind Interface Definition Language to C++. Object Group president Chris Stone strongly disagrees.
He admits that a large part of IDL is derived from C syntax but he really cannot see technically why this should pose a problem to anyone. What is more he believes that the Object Group is completely justified in specifying a mapping to C++ from IDL in the same way that a Request For Information is currently out for a mapping to Smalltalk. He agrees that whichever proposal forms the basis for the mapping will give its proposer an advantage in developing a compiler, but that is the nature of the Object Group process. Another area of contention in the esoteric world of the object request broker community rests with the old chestnut of dynamic binding. The static versus dynamic debate was laid to rest with Corba 1.0 – as far as the Object Group is concerned both are viable approaches and both are endorsed in Corba. Indeed, to be Corba-compliant (if there were any compliancy tests) would involve being able to support dynamic invocation as laid down in the original Corba specification. However, a little research will reveal that object request brokers built on a static model find it difficult to support this part of the spec and where they have tried have hit real performance issues. While all agree that dynamic invocation can be useful in areas such as prototyping, the majority of vendors have opted for a static model because static binding does not presuppose human intervention. They feel that get and put are far more efficient in terms of sharing objects across a network than requiring a programmer to activate an object and find out what it does before using it. If a program existed to query an object intelligently and deliver which method to use, then dynamic invocation would make sense, but currently for most market situations dynamic binding is not required and yet has to be supported for a vendor to claim Corba conformancy. So criticism number two is – should dynamic invocation be a necessary part of Corba compliancy? Perhaps it would be better to endorse both dynamic and static binding as legitimate but leave vendors the freedom to choose whether it makes commercial sense to offer both approaches.
By Katy Ring
Chris Stone is adamant that there will be no shifting from this basic tenet of Corba compliancy for which X/Open Co Ltd will be able to provide an application programming interface test by the end of the year. However, he believes that a lot of vendors may find it easier to comply with Corba’s dynamic invocation when a Type Repository is defined as part of the Corba 2.0 spec. This will offer support for object services such as constraints, error messages and so on and will not be as limited in scope as the Interface Repository. However, perhaps the most damning indictment of all when it comes to Corba is the seeming inability of Corba-conformant products to interoperate. Onlookers at interoperability demonstrations have been perturbed by what Corba interoperability appears to mean. It seems to mean that object request brokers can pass protocols to one another via protocol converters – these converters are written with the collaboration of the companies involved, so what exactly is Corba’s contribution to interoperability? (Indeed, one commentator has likened a Corba object request broker to a paranoid piece of software that has to dom
inate the network completely). And to follow the logic of this argument, if Corba object request brokers are unable to co-exist comfortably with each other, are they going to be in a position to communicate meaningfully with other software in a distributed environment? Chris Stone agrees that currently interoperability between object request brokers is fairly primitive, but he makes the point that this is one of the main issues addressed in Corba 2.0. The Object Group is still receiving technical solutions to the interoperability problem, many of which are rooted in protocol converters, but some have taken a megaobject request broker approach. Now, of course, none of this would matter if the Object Group was an inconsequential body, but it is not. It has worked hard for its dominance of the object-oriented industry, employs some exceptionally talented individuals and handles itself with integrity in carrying out its politically charged agenda. It is a measure of its success that Corba is on corporate check-lists for computer systems purchase. Nevertheless, it looks as if it is in a spot of bother when it has reached the stage where vendors are finding that Corba is creating a marketing problem for them because it is taking so long to deliver a workable spec. There is a feeling that the procrastination and in-fighting surrounding Corba is promoting a sense of unease and uncertainty about object request broker technology itself. So much so in fact that some vendors are reporting that customers are opting for Remote Procedure Call sockets rather than using object request broker technology. Of course, to be fair, a large part of the problem could lie with misrepresentation of the Object Group’s role, which never has been that of a de jure standards body.
Crippled with indecision
The Object Group aims to take the best productised technology available as a de facto base from which markets for object technology can grow. The fact that parts of the market are crippled with indecision as soon as Corba is raised as an issue is as much a fault of large customers being over-reliant on standardisation procedures as it is the Object Group taking its time to crank out a workable spec. Until we see the papal smoke rising from the Moscone Centre, San Francisco in July and can then see the direction that Corba 2.0 will take, the Object Group’s success or failure in this area cannot be judged. In the meantime, perhaps the pioneering users evaluating or implementing object request broker technology should not be over-assiduous in filling out Corba-conformancy tick-boxes they don’t actually mean very much today. If a vendor has a product that demonstrably serves your needs, is a member of the Object Group, and promises compliancy over time, he may well deserve your custom. Give him the benefit of the doubt. Dr Katy Ring edits Software Futures.