On Fri, 21 Jun 2002, Bill Burke wrote: > Holger, in JBoss 3.0 we have client interceptors, and pluggable transports. > The invocation has been totally decoupled from the EJB container. The EJB > Container is now just an MBean and all EJB invocations go across the JMX > bus.
Great! > JBoss 3.1 takes things a bit further. In 3.1 you can now define multiple > invokers (transports) per EJB container. So an EJB container can be > configured to receive requests from RMI, IIOP, SOAP, HTTP, whatever all at > the same time. We'll want to hook your HTTP invoker into this architecture. Ok, I'm already trying to do that. > The files and java packages you'll want to look at are as follows, There's > also a detail email I sent out 2 months ago that is copied later on in this > email: > > In server module: > Packages org.jboss.invocation, org.jboss.proxy > > org.jboss.invocation.jrmp.server.JRMPInvoker.java is the main entry point on > the server side. It accepts invocation requests and routes them across the > JMX bus. I think your HTTP POST protocol can be very simple. Just marshall > an Invocation and send it across the wire. The JRMPInvoker is stateless and > can route any Invocation. So far, that's straight forward. I' am writing a HTTPInvoker, that deploys a servlet (same hack as jboss.net axis servlet) and forwards invocations to the HTTPInvoker. The invoker feeds them into jmx. > For the client side, you'll need to implement a new > org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy. This is really the > "Transport" on the client side. You'll also need to implement a > org.jboss.proxy.ejb.ProxyFactory. The JBoss clustering can be used as an > example since it has extended JRMPInvokerProxy, ProxyFactory and has its own > Invoker. see the cluster module. All classes under the above packages. If I understand it correctly, the ProxyFactory is an MBean, running on the server, facturing InvokerProxy instances that are moved to and used on the client (caller side)!? > What sucks is that even if you've implemented this stuff, its not very > helpful because JNDI does not have pluggable transports. Maybe I am still missing something, but what if the server configuration would simply end with the invoker layer. container is server side. invoker is the entry point for the container, thus also server side. remaining config is _client_side_. The client (another bean, application-client, web-application) is always referring an (ejb|ejb-local|..)-ref (coded name) in its private jndi namespace. It is never accessing the server's jndi namespace directly! The ejb-ref is the place for configuration bits that: o identify the target component o determine the transport protocol o locate the invoker o setup the client interceptors (terms server and client often used in the sense of callee/caller) This would have some big advantages: o decoupling of client and server o no jndi plugins for different protocols required o jndi is mostly (if not completely) local o server is responsible for containment and accessibility o client can connect wherever it wants (also to different appservers in different locations with different protocols) o client code uses coded names instead of deployment specific jndi-names o client interceptors are configured per client .. thus server makes no assumptions about the client Holger ------------------------------------------------------- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
