Hi,I am afraid it is not so easy... First, the repository ID is not available at all (Imean, the Interface Repository id. What is available is the object key, which completelly identifies the target object on the server side. It is available as an array of bytes, and is already passed to the service handler. The repository ID is not part of the GIOP message header.Since the Service Handler interface does not conform to the PortableInterface anyhow, I would like to suggest to extend the parameter lists of its methods so that the target object's repository id and the name of the
requested/replied operation be available in the callback handlers. Both (rep id and operation name) are available 3 or 4 level above up in the call stack, so all what we need to do is pass them onto the called methods.
The operation name is part of the GIOP header, but it is not easy to provide it to the service handler. This is related to the Jonathan architecture. The issue is with the coexistence of Jeremie and David over GIOP : Jeremie uses integers to identify methods, whereas David uses the operation name as a String. To let these two possibilities coexist over the same invocation protocol, the responsibility of encoding and decoding the operation name has been left to the skeletons (or, more precisely, to an interceptor placed between the GIOP session and the skeleton). The GIOP protocol implementation provided in Jonathan doesn't decode the operation and principal information, and thus can't provide it to the service handlers.
Changing this would require rewriting quite a lot of code... And would make the sharing of service code between David and Jeremie more difficult. We could think of a different place where the service handler could be called, but this may cause other problems, e.g., in case of exceptions.
The object identity is available through the object key, and lets you provide access control on a per object basis. But you don't have access to the operation name. I understand your point, but I am afraid I can't provide you with this mechanism easily... Sorry !
I know changing an interface is a tough proposition, but it is probably not that much tough considering that it would be extended and not really changed. On the up side would be the possibility, that based on these
new parameters, much more functionality could be concentrated in the service handlers. For examle, the security related code could be significantly reduced in the implementation of the business objects, because
much of the authorization could be done in the service handlers based on the object's identity and the operation requested. Wouldn't it be nice, it this was possible?
Best regards,
Bruno
-- ******************************************************************* Bruno Dumant Directeur Technique / Chief Technology Officer Kelua 9 Chemin de la Brocardière 69570 Dardilly
tel: +33 4 37 49 63 94 fax: +33 4 37 49 63 91 *******************************************************************
begin:vcard n:Dumant;Bruno tel;fax:33 4 37 49 63 91 tel;work:33 4 37 49 63 94 x-mozilla-html:FALSE org:Kelua adr:;;9 chemin de la Brocardi�re;Dardilly;;69570;France version:2.1 email;internet:[EMAIL PROTECTED] title:CTO x-mozilla-cpt:;0 fn:Bruno Dumant end:vcard
