geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Srinath Perera <>
Subject Re: JSR 109 MessageContext import
Date Mon, 03 Nov 2003 04:56:44 GMT
Hi Richard

nice to see the discussion we all needed has begin :)
> On 11/2/03 10:33 AM, in article
>, "Jeremy Boynes"
> <> wrote:
> > IIRC the current 109 architecture plans to invoke EJBs using their normal
> > remote interface.
> This is the first I've hear of this plan. Did I miss a beat? I've kind of
> been distracted the past couple of days.
this was the how wrapper web service invoke the EJB. I said at archi doc
at WIKI we should invoke EJB through the remote interface. (use local
interface if the performence is a issue and JAX-RPC run time and
Container in one mechine !!)
> > 
> > However, the invocation in Geronimo needs to attach a MessageContext with
> > the invocation and notify the EJB container that this is a web-service
> > invocation rather than an component interface invocation (so that the
> > appropriate SessionContext methods can be enabled).
> There are a number of differences between a remote invocation and an
> endpoint invocation. For one thing, the EJB Endpoint implements (directly or
> implicitly) an endpoint interface, rather than an EJBObject type interface.
> Second, there may be a Message Handler chain that needs to intercept
> incoming requests and that chain works with a SAAJ Message object. Another
> thing, is the MessageContext. It needs to be accessible to all of the
> handlers and the bean instance through its SessionContext - as you already
> mentioned.
these are happen inside the JAX-RPC runtime I belive (which support
these features). I think the JSR109 spec say no state continue to exists
over two invocation. (It says if the JSR109 impl server crash and
restart between two client rquests there is no way client Know about the
> > 
> > This seems to imply that a different invocation API is needed from the
> > normal remote interface implementation. There may be a way to hack it in
> > using the client-side interceptor stack, but given this is required
> > functionality we should have a cleaner approach.
> My understanding is that the interceptor stack is supposed to be flexible
> enough to allow different calling methods (e.g. Remote IIOP, Remote JRMP,
> Local, etc.). Is this true? I mean is it necessary to "hack" client- or
> server-side interceptor stack?
this is my point as well; the spec says (have I turning in to spec
parrot:) ) the JSR109 impl should not need new J2EE containers it should
able to use existing container compatible to J2EE spec.



View raw message