EJB and JAXWS integration

[Jarek Gawor <jg...@gmail.com>]

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). 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);

So, if in Geronimo I could somehow get a reference to the
SecurityService from DeploymentInfo or RpcContainer I would be set.

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

Thoughts?

Thanks,
Jarek

Re: EJB and JAXWS integration

[Jarek Gawor <jg...@gmail.com>]

Ok, thanks. I got code working and ready to be committed once latest
OpenEJB snapshot is published.

Jarek

On 3/30/07, David Blevins <da...@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
> >
>
>

Re: EJB and JAXWS integration

[David Blevins <da...@visi.com>]

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
>

Re: EJB and JAXWS integration

[David Blevins <da...@visi.com>]

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