| Previous | Table of Contents | Next |
The IOP::ServiceContext used to support bi-directional IIOP contains a BiDirIIOPServiceContext structure as defined below:
// IDLmodule IIOP {
struct ListenPoint {string host;unsigned short port;
};
typedef sequence<ListenPoint> ListenPointList;
struct BiDirIIOPServiceContext {ListenPointList listen_points;};};
The data encapsulated in the BiDirIIOPServiceContext structure, which is identified by the ServiceId BI_DIR_IIOP
as defined in Section 13.7, “Service Context,? on
page 13-28, allows the ORB, which intends to open a new connection in order to
invoke on an object, to look up its list of active client-initiated connections and examine the structures associated with
them, if any. If a host and port pair in a listen_points list matches a host and port, which the ORB intends to open a connection
to, rather than open a new connection to that listen_point, the server may re-use any of the connections that were initiated
by the client on which the listen point data was received.
The host element of the structure should contain whatever values the client may use in the IORs it creates. The rules for
host and port are identical to the rules for the IIOP IOR ProfileBody_1_1 host and port
elements; see Section 15.7.2, “IIOP IOR
Profiles,? on page 15-52. Note that if the server wishes to make a callback connection
to the client in the standard way, it must use the values from the client object's IOR, not the values from this BiDirIIOPServiceContext
structure; these values are only to be used for bi-directional GIOP support.
The BI_DIR_IIOP service context may be sent by a client at any point in a connection's lifetime. The listen_points specified
therein must supplement any listen_points already sent on the connection, rather than replacing the existing points.
If a client supports a secure connection mechanism, such as SECIOP or IIOP/SSL, and sends a BI_DIR_IIOP service context over
an insecure connection, the host and port endpoints listed in the BI_DIR_IIOP should not contain the details of the secure
connection mechanism if insecure callbacks to the client's secure objects would be a violation of the client's security policy.
It is the ORB's responsibility to ensure that an IOR contains an appropriate address.
15.8.1.1 IIOP/SSL considerations
Bi-directional IIOP can operate over IIOP/SSL (see CORBAservices Chapter 15) without defining any additions to the IIOP/SSL
or the bi-directional GIOP mechanisms. However, if the client wants to authenticate the server when the client receives a
callback this cannot be done unless the client has already authenticated the server. This has to be performed during the initial
SSL handshake. It is not possible to do this at any point after the initial handshake without establishing a new SSL connection
(which defeats the purpose of the bi-directional connections).