[omniORB] Bi-directional (BiDir) GIOP on basis of IOR obtained from Naming Service?

[Stefan Schweitzer]

Hello everybody,

I am trying to get my server application to pick up an existing rope from the client, and I am failing.

I have set up both my client and my server applications to support bidirectional GIOP. After debugging into omniORB, I am confident that all requirements regarding configuration have been met.

The problem seems to be of a different nature:
- Client invokes a server method but does NOT pass any object references. (This gets a TCP connection from client to server into existence.)
- Server wants do make callback to client.
- Server gets client IOR from COS Naming Service (!).
- omniObjRef::_unMarshal() unmarshals the string on the basis of a cdrMemoryStream passed by the calling method (which is omniObjRef::_fromString()).
- Since the stream is NOT a giopStream (but a cdrMemoryStream), _unMarshal() does NOT put TAG_OMNIORB_BIDIR into the IOR.
- This later leads to createObjRef() failing to select the existing bidir rope for the callback.

Why use the COS naming service to obtain the callback reference? - Because the receiver of the callback is one of hundreds of objects existing in the client, and the server is to decide who gets the callback, and we are reluctant to put hundreds of object references into any Server IDL interface method.

In the omniORB source code, I can see the following comment:

  // Provide interim BiDir GIOP support. Check the stream where this IOR
  // comes from. If it is a giopStream and this is the server side of
  // a bidirectional stream, add the component tag TAG_OMNIORB_BIDIR to the
  // ior's IOP profile list. The component will be decoded in createObjRef.
  //
  // In the next revision to bidir giop, as documented in OMG doc. 2001-06-04 
  // and if it ever gets adopted in a future GIOP version, the tag component
  // TAG_BI_DIR_GIOP will be embedded in the IOR and this step will be
  // redundent.

So, what does "interim BiDir GIOP support" mean here? Does it mean that server -> client rope selection works only in the scope of an upcall containing the client object reference (so the server unmarshals any object reference from a giopStream rather than a cdrMemoryStream)?

The CORBA standard says: " The client creates an object for exporting to a server, and arranges that the server receive an IOR for the object. The most common use case would be for the client to pass the IOR as a parameter in a GIOP request, but other mechanisms are possible, such as the use of a Name Service."

What about the TAG_BI_DIR_GIOP embedded in IORs; has it ever become part of the standard? I have not been able to find a lot of information about this.

Any hint is greatly appreciated. If I should be on the wrong track altogether, I would be glad to be told as well ;-). Thank you.

omniORB version 4.2.3