geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <>
Subject Re: EJB and JAXWS integration
Date Fri, 30 Mar 2007 08:16:28 GMT
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.


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

View raw message