marc fleury wrote: > Bill got my hear yesterday (and today is talking to microsoft about > his love for open source :) where he pitched the interceptor design > on the 3.0 client side. > > Instant love. >
Sounds pretty interesting (the interceptor design that is :). I'm vaguely familiar with using client-side interceptors with CORBA in the past but the situation here is much less static. Can you clear up one or two things? > We are not that far from it in fact, it a bit of renaming and > factory game on the server. Essentially the client does > > Generic Proxy -> Handler -> EJB behavior -> Transport > > In the transport layer we extract the Tx and Security information. > OK. So that's the current state? What's the Handler in this context - is that the JRMPInvokerProxy, for example? > The pitch was simple it had to do with moving > > GP->Handler->interceptor 1 (EJB behavior for example) ->interceptor > 2 (Tx extraction) -> interceptor 3 (Security) -> Transport > (invoker). > So this is basically just moving the code that sets the security and transaction contexts from the JRMPInvokerProxy and setting them in the appropriate interceptors instead? What is the current situation with the IIOP transport and how will that fit in with the generic proxy stuff and this stack of interceptors? Presumably there will just be an IIOPInvoker instead, which will perform the invocation via the chosen client orb (rather than formatting its own IIOP message). How will it insert the security and transaction contexts into the IIOP buffer as it won't have access to it at this stage? Or is there some other way to do this? > > The application could specify a jboss.xml that describes the client > side interceptor like the server side does <ejb> <tx> <security> > <jrmp/iiop> > > would be a way to declare a given client (in this case EJB behavior > (local calls fielded). > > The factorization right behind it is on the server side. Where we > expose the "ProxyFactory" (already there in a primitive form) and > that PF can export any combination of (interfaces, stack of client > interceptors, transport) and generates the client for it. > Do you mean the proxy.ejb.ProxyFactory? So this would provide a return a proxy object which contained the appropriate client-side invocation stack, based on the above jboss.xml configuration? Would you be able to have multiple client-invocation stacks per container? > This way for ANY MBean SAR that you deploy on the server you can > create proxies that exposes a pluggable behavior example you would > deploy your SAR and create clients with <my proxy behavior that I > wrote for my client> <security> <... no tx> <soap> > > and the connectors on the server side will know to route your > message to the right mbean with the right security integration and > no tx for example. Voila instant framework distribution. > Ummm. So here you're talking about deploying Mbeans as server components which can be invoked by a remote client? I don't quite understand what the advantage is. Why would you want to remotely invoke an Mbean rather than just using an existing technology such as EJB to wrap it? > What is missing here is the location of the objects and the finders > for these objects... this is where and EJB like semantic would be > handy... > Won't binding them into JNDI be sufficient? Are you likely to need finders for MBeans? Are there many situations where you would have "keyed" MBeans? I thought they were basically services - though I'm sure Juha can come up with many other uses for them :). Sorry for all the questions, but I usually need things spelt out to get an understanding of what's going on. Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523C http://www.mkeym.com _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
