Alright, the web-service address information is ported over from the
old plan. There is now a <web-service-binding> list in the geronimo-
openejb.xsd which is now available in that set of XmlBeans objects in
the EjbModule.
-David
On Mar 28, 2007, at 3:49 PM, David Blevins wrote:
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
