Search code examples
javacorba

How to Identify various CORBA clients in a CORBA server


I have created a CORBA Server and two clients - Client1 and Client2, the server is implemented using Java which are connecting to this Server. When the client(s) connect to the server, the server has to maintain the connection state, i.e., connected = true or false

For instance, there are two methods in the server :

  1. connect()
  2. disconnect()

When a client calls the connect() method, this connected state should be saved at the Server for this Client1. If the same (connected) client calls connect() method again, then the Server should return an error.
Similarly, if the Client2 calls disconnect() before connecting, the Server has to detect that Client2 has not connected yet and return an error

My question is how to identify the CORBA client uniquely ?

Any ideas/suggestions are appreciated. Thanks..

Solution

  • CORBA does not precisely define the notion of a "client", because it has a number of meanings for different people:

    • The client's machine (identified by an IP address)
    • The NIC which the client used to connected to the server (identified by a MAC address)
    • The client's process (identified by a process ID)
    • The client's socket for their connection to the server (identified by a file descriptor)
    • The ORB within that process (identified by the ORB identifier which might be passed to ORB::init())
    • The thread within the process making the call (identified by a thread ID)

    Adding to the complexity is the fact that some of these items (especially connection-based identity) cannot be used reliably within CORBA to identify clients or track their lifetime because ORBs are allowed to close idle connections and later re-establish them when activity resumes.

    The best way to deal with this problem is to push the management of client lifetime into your application, and specifically into your IDL. Have the client request a cookie at "connect" time and pass that cookie within each subsequent request:

    interface Foo {
   void connect(out string cookie) throws AlreadyConnected;
   void doWork(in float data, in string cookie) throws NotConnected;
   void disconnect(in string cookie) throws NotConnected;
};

    My IDL syntax might not be perfect, but you'll get the idea. You should also look into ways to transparently send the cookie without having to affect your IDL using PortableInterceptors and/or Service Contexts.

    Regardless of how you transmit the cookie or session token, your server will have to manage them carefully and purge old ones if necessary. Session cookie management can be a real burden on a service and impede its ability to scale well.