geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: EJB and JAXWS integration
Date Wed, 28 Mar 2007 22:49:08 GMT

On Mar 28, 2007, at 10:29 AM, Jarek Gawor wrote:

> David, Dain,
>
> I've been looking more into the OpenEJB and JAX-WS integration and I
> think I identified a few things that I will need from the OpenEJB code
> in order to get this integration done.
>
> 1) Handlers and security
>
> After looking at EJB interceptors and JAX-WS handlers and realizing
> that they are not quite the same I decided to let the JAX-WS engine to
> invoke its handlers and EJB engine to invoke its interceptors (instead
> of somehow wrapping a JAX-WS handler into an EJB interceptor).

If you could shed some of your insights on how they are the same and  
how they are different, that'd be really helpful.  Some spec  
references would great if you have them.

I know the data returned from InvocationContext is different but that  
part doesn't have an direct affect on the handlers themselves.  Not  
sure if there are any differing rules on handler ordering or flow.

> The
> only thing that I need to do for handlers is ensure that method-level
> authorization is performed before any JAX-WS handlers are executed.
> For that, I believe I need to perform the following check in the very
> first handler:
>
>   getSecurityService().isCallerAuthorized(callMethod, null);

We are already performing an authorization check before invoking  
handlers of any kind  (i.e. we could never invoke your ws-hanlder- 
chain ejb interceptor without a security check).  But I do know the  
check needs to contain the MessageContext rather than method args,  
which is pretty much the same difference in how InvocationContext  
works for a ws call vs. an rpc call.  There's also a method in  
javax.ejb.SessionContext for getting the MessageContext only usable  
on a web service call.

What I can't remember is what JACC permission we're supposed to  
construct.  Do you know?

> 2)  InvocationContext and delaying deserialization/serialization of  
> parameters
>
> If OpenEJB allowed Geronimo to pass a custom implementation of the
> InvocationContext object (e.g. maybe an extension of
> ReflectionInvocationContext) I could modify it so that:
>
>  a) getContextData() would return the same object as MessageContext
> (as per spec)
>  b) getParameters() would deserialize the SOAP message (delay  
> deseralization)
>  c) setParameters() would update the SOAP message
>  d) proceed() would keep the object returned and the SOAP message  
> in synch

We definitely need to do something along these lines and a new  
InvocationContext is not an entirely bad idea.  The gotchas that may  
prevent us from taking that route exactly are that I'm pretty sure  
the full ejb interceptors apply to all calls, not just rpc, and would  
need to get invoked too.  Would have to verify that, so any info you  
have about ejb interceptors as they may differ from ejb web service  
handler chains would help.  Also there are some very complex  
exception handling rules for ejb which might make that hard -- app  
exception vs system exception and now in the ejb3 spec ejbs can throw  
runtime exceptions as app exceptions on any call if they've marked  
them in the deployment descriptor and this directly affects how  
interceptors are processed.  We also need to handle the java to xml  
marshaling of the bean method's return value or exception.  Not sure  
how that would fit in.

It's definitely clear we need the MessageContext itself passed in  
from the web service layer as it's required in at least three  
different places that i can think of.  We might be able to get by  
with a CXF or Axis Interceptor that we insert into interceptor stack  
right before the bean method call.  It's job would be to unmarshall  
the data in the MessageContext into some known place in the  
ContextData so we can invoke the bean, then it would marshal the  
return value or exception so it can be passed up the chain normally.

That would be assuming of course that ejb rpc and ejb ws handlers are  
the same and only the InvocationContext needs to be different.  So I  
guess that's really the question of the day.

Will dig around.

-David


Mime
View raw message