Pasar en Corba informacion de usuario del cliente al servidor de manera transparente

En la aplicación que estamos haciendo hay que registrar en base de datos que usuario y con que role hace unas determinadas operaciones. La aplicacion es cliente/servidor.

Se tiene un Servicio CORBA de Seguridad que mantiene informacion sobre las sesiones que mantiene un usuario (claro, con un role determinado). El alta de la sesion se hace desde el cliente y el servicio es accesible tanto desde el cliente como desde el servidor. Pero para obtener información en el proceso servidor, se deberá tener algo que identifique la sesión. Aqui surge el problema que comento hoy.

Como al final lo que tengo que hacer, es almacenar un usuario y su role en una tabla de la BD, lo mas facil es pasarlo como un argumento mas. Pero esta solución no me gustaba nada, ya que se mezclan los datos de la operación con datos, llamemosles, administrativos. Además se tienen mucha operaciones de este tipo.

Se me ocurrió que en CORBA debería haber algun mecanismo para pasar este tipo de información. Y efectivamente asi es. Pero es una pena que no lo pueda usar, ya que el ORB que usamos es propietario y no lo soporta. Lo podrían implementar, pero no nos podemos permitir esperar ese tiempo. Por lo tanto usare la opción de pasar la información del usuario en todas las llamadas que lo necesiten. Eso si, en un struct :).

Ahora a lio, a la investigacion realizada al respecto....
Lo primero que hice fue buscar en el estándar sobre el objeto Context, ya que me sonaba de que por ahi podrían ir los tiros. Tras mirarlo (rapidamente) y no quedarme muy claro, hice una busqueda en el grupo adecuado, comp.object.corba y según lei, es un mecanismo que no merece la pena usar. Al final, y mas importante, por no ser un mecanismo trasparente y por ser bastante inseguro (se pasan cadenas)
Por lo tanto puse un mensaje, al cual me respondieron indicandome que la manera de hacerlo es usando los siguiente mecanismos:

Portable Interceptors

ServiceContext

En el cliente el PI añade los tokens al ServiceContext y en el servidor el PI comprueba los tokens y realiza las acciones pertientes.
Los Portable Interceptores, como su nombre ya indica lo que hacen es interceptar la llamada entre el cliente y el servidor, para poder realizar acciones de manera transparente. Hay servicios estandares que hacen uso de ellos, como el de seguridad.
El cliente hace la llamada y antes de enviar los datos por la red, se ejecuta el codigo en el interceptor cliente. Una vez llegan los datos al servidor se ejecuta el interceptor servidor y despues se pasa ya al codigo del servidor.
Tras la llamada al metodo del servidor se vuelven a ejecutar los interceptores asociados al retorno, primero el PI del servidor y despues el PI del cliente.

En TAO si estan implementados. Hay informacion sobre el tema en este paper.