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
