I guess if EJB limits you like that, then you'd have to jump through some hoops (but it is still possible - see below). And while EJB may not allow this, I'd be shocked if there isn't a container-specific way of supporting this (I think JBoss Remoting can support this if you're using JBoss for example).
However, if you want to remain container independent and EJB does not support the notion of user-supplied invocation metadata, I know of a work around that I have used on a project before: I wrote a little framework that creates AOP proxies that implement each Service interface. The client code calls these proxies. Each one of the proxies in turn calls a a 'MethodInvocationDispatcher' EJB remote proxy. That MethodInvocationDispatcher EJB on the server side discovers what 'real' EJB and method should being called, and invokes that local bean/method with the arguments. This is essentially an implementation of the Front Controller design pattern. For example, you could create an EJB, with a single method signature: RemoteMethodInvocationResult invoke(RemoteMethodInvocation invocation); This essentially creates a very simple/small application-level remoting mechanism that sits on top of EJB remoting. When I created mine, it didn't take long - maybe a day or two to work the kinks out. But because you would control the objects that are sent across the wire, you could leverage it for any other type of framework stuff you may need that EJB doesn't support. The RemoteMethodInvocationResult and RemoteMethodInvocation objects are yours - you can create them however you wish. So, I would ensure that a method existed: remoteMethodInvocation.getAttributes() : Map<String,Object>. This way you could populate the attribute map with whatever metadata that you wanted for your framework needs. For supporting Shiro, in a stateful app, one of those 'attributes' would be a session id, or for a stateless app, you'd send along the PrincipalCollection and authenticated state (stateless app). Once your server-side EJB receives the invocation, you'd essentially do the same thing that the SecureRemoteInvocationExecutor does in Shiro's Spring support. HTH! Best, -- Les Hazlewood CTO, Katasoft | http://www.katasoft.com | 888.391.5282 twitter: http://twitter.com/lhazlewood katasoft blog: http://www.katasoft.com/blogs/lhazlewood personal blog: http://leshazlewood.com
