[omniORB] transport filters in 4.0

[Duncan Grisby]

On Tuesday 10 September, tect0003@flashnet.it wrote:

> I apologize, Sai-Lai talked just about "filters".
> I cite here:
> "As for fully encrypting the bytes sent on the wire, I 
> suggest implement this as a transport. There is (or will 
> be) a well-defined interface to hook-up a transport at 
> runtime. No need to recompile omniORB4 of course. There 
> are other details, such as how to insert the bit of info 
> into an IOR so that the client knows when to use 
> your "special" transport, etc. These can also be done via 
> interceptors."
> 
> Is all of this still valid in the sense of the capability 
> to add new transports without recompiling OmniORB ?

Yes, that's still valid.

> Furthermore, is it possible for an interceptor to reject a 
> call ? What I would get is to fetch a token at the server 
> side by an interceptor, and reject the entire call if its 
> validation fails. The target object should not even know 
> about this failure.
> Is it possible and how ? Throwing an exception from the 
> interceptor ?

Yes. You can either reject a call at the transport level, or by
throwing an exception from a serverReceiveRequest interceptor.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan@grisby.org     --
   -- http://www.grisby.org --