geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jarek Gawor" <jga...@gmail.com>
Subject Re: EJB and JAXWS integration
Date Fri, 30 Mar 2007 20:34:18 GMT
Ok, thanks. I got code working and ready to be committed once latest
OpenEJB snapshot is published.

Jarek

On 3/30/07, David Blevins <david.blevins@visi.com> wrote:
> 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
> >
>
>

Mime
View raw message