Network Computingwww.networkcomputing.com

CORBA allows full use of other transport protocols, either as another mapping of the GIOP (such as IPX/SPX and Open Systems Interconnection) or as an Environment Specific Inter-ORB Protocol (ESIOP). We haven't found any vendors that have implemented GIOP mapping other than IIOP, but both HP and Digital support a DCE ESIOP called the DCE Common Inter-ORB Protocol (DCE-CIOP). Using the ESIOP spec, vendors can add support for other protocols as needed. This lets an ORB operate in an environment where a certain protocol, IPX/SPX, for instance, is mandatory, while still providing a half-bride to IIOP for interoperation with external ORBs.

IIOP is a key component of the CORBA 2.0 spec. To test whether it guarantees the successful operation of ORBs from different vendors, we built a simple port of the TTCP client/server test program. We invoked a server object using each of the tested products as a client ORB. This test required successful cross-vendor interoperation between the client's libraries and another vendor' s ORB. For this test, our TTCP server object was activated on a Windows NT machine running Digital's ObjectBroker with each client running on the platform submitted for testing. Although we didn't do a complete client-by-server cross-test for interoperability (CORBA doesn't completely speci fy source code portability for client stubs and server skeletons, so porting to all of our test platforms would have required an inordinate amount of time) the terms "client" and "server" are nearly arbitrary in the CORBA model, because any object can be both a client and server, depending on how it's implemented.

The original TTCP test program uses send-and-receive socket calls to transmit varying buffer lengths to the server. Using an object-oriented approach, this translates to the object method invocation ttcp.send(buffer). Under normal circumstances, this method call would perform some manipulation of the buffer. In our case, this function does nothing explicitly. However, as a result of the call itself, the ORB c ore formats the buffer, marshals the data and sends it to the remote object. We then could observe the network effects of the method call.

Before a server object can be invoked, the client needs to obtain an Interoperable Object Reference (IOR). IORs can be obtained from a text file or Naming service. The IOR encodes both an object's handle and a physical location of the active server object. This IOR is completely opaque to the client. Per the CORBA spec, the client needs to know nothing about how actually to locate an object; that is an issue that should only be resolved among ORBs.

We set up the active server object to write a string representation of its IOR to a file that was subsequently transferred to the client to read. This highlights one of the difficulties with managing CORBA objects. We used a shared file system, which made transferring IORs easy, but it's unlikely for an enterprise to have a single enterprisewide share.

Our results indicate that interoperability among these vendors wa s real. We could invoke objects across five vendors' platforms simply by providing the correct IOR to the client ORB. But this interoperability has limits: None of these vendors provided a means of exchanging information about active implementations so that client requests could be satisfied in a fault-tolerant manner. Every product, except PowerBroker, provided a means to do this within its own ORB, but not cross-ORB.

The fact that OMG specified IIOP as a requirement for CORBA 2.0 compliance simplifies deployment on networks. It guarantees a default method of communication across all ORBs. This makes a tremendous case for using it as a backbone protocol, even though it means using TCP, and using specific protocols, such as DCE RPC, where necessary to access legacy enterprise systems and subsequently bridging to the backbone. Yet IIOP is a first-rate protocol in its own right and can be used quite readily as a standard inter-ORB protocol. For what basically constitutes an RPC mechanism, it's lightweight and efficient. Though it inherently has some of the same difficulties as RPC on slow and high-latency links, where possible, it should be the default choice.