On 2002.12.09 10:01:05 -0500 Scott M Stark wrote: > > ----- Original Message ----- > From: "David Jencks" <[EMAIL PROTECTED]> > To: "jboss-dev" <[EMAIL PROTECTED]> > Sent: Sunday, December 08, 2002 6:16 PM > Subject: [JBoss-dev] Invokers (jboss 4) > > > > I've been studying the invokers while working on the xid-based > transaction > > propagation and plan to do some refactoring if there are no strong > > objections. > > > > 1. I plan to make both the client (sending) and server (receiving) > halves > > of the invokers layered with aspects or interceptors. This will enable > > reuse of everything except the transport layer across most invokers. > > > So do you have a prototype configuration for a stateless session bean > using RMI as the transport here to demonstrate what this is going to > entail?
Bean configuration would be unaltered. You'd set up the invoker as a stack somehow: I'm not even sure this needs to be configurable, hard coding might be ok. So far I'm thinking the typical trunk-like invoker would look like tx-to-xid converter (ProxyXAResource) multiplexer transport send-end transport receive-end demultiplexer WorkManager driver I don't have even a prototype yet, but I do think this will make a lot of stuff reusable and simpler. > > > 3. In order to use the work import contracts, I plan to make all the > > invokers asynchronous, as the trunk invoker is today. The Work object > will > > include both the code to call the mbean target (i.e. ejb) and the > > information necessary to return the result back through the transport > > mechanism. It's possible that separate inbound and outbound > > interceptor/aspect stacks may be desirable. > > > This would seemingly add a lot of complexity to synchronous > configuration. > Can't both synchronous and asynchronous be used? How is this going to > mesh > with inherently syncrhonous protocols like http and jrmp? I need to think about this some more. Using the WorkManager to insert work requests into the system tends to introduce some asynchronicity. I think there is a way to avoid this by using the doWork method and putting the return value in the Invocation object, which the layer calling the work manager can keep a reference to. Were we planning to do this anyway, put the return value as an attibute of the invocation object? > > > 4. There has been some discussion about two way transport, as > implemented > > in the trunk invoker. It seems to me that any way of calling an ejb > has in > > it 2 communication channels, one in each direction. If these are based > on > > accessible sockets, the channels can be used in the opposite direction > and > > order, thus providing two way transport. I propose to provide this two > way > > transport when the underlying transport supports these separable > transport > > directions (for instance, my impression is that rmi does not). If > there > > are problems with this approach I'd like to know about them. If you > > disagree with this approach please explain why the in and out streams > from > > a socket should not be used in both directions for this purpose and > explain > > in at least a little detail an alternative approach. > One thing that you need to be careful of in splitting the return channel > from the > request channel is maintaining the thread context class loader for the > marshalling > of return values and exceptions that are coming from the deployment jars. Indeed. Thanks david jencks > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
