Just a small point: do we agree that independing on the protocol used to communicate with JNDI, the proxy needs to be obtained in a specific way (like now, through standard TCP) to bootstrap.
> -----Message d'origine----- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]De la part de Bill > Burke > Envoye : jeudi, 27 juin 2002 10:11 > A : [EMAIL PROTECTED] > Objet : RE: [JBoss-dev] http transport > > > Holger, your ideas are very interesting and thought provoking. Although I > disagree with a lot of them (read further), I believe that this is a good > conversion and something very cool will come out of it. > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of > > Holger Engels > > Sent: Thursday, June 27, 2002 2:36 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] http transport > > > > > > On Wed, 26 Jun 2002, Bill Burke wrote: > > > > > > > > > > > > -----Original Message----- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED]]On > > Behalf Of marc > > > > fleury > > > > Sent: Wednesday, June 26, 2002 12:55 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: RE: [JBoss-dev] http transport > > > > > > > > > > > > |Seems like I don't need an HTTPInvoker. Only an > > HTTPInvokerProxy and a > > > > |InvokerServlet, that forwards invocations to the local > invoker. If I > > > > > > > > use the JMX bus directly, > > > > > > > > |understand it, the proxy must provide a > TransactionPropagationContext > > > > |instance to each Invocation. This has to be "imported" in > the servlet > > > > |before the invocation is forwarded to the LocalInvoker. > > > > > > > > The transaction is not mandatory, but if it is there then yes > > it has to be > > > > "imported" (this is a weakness, necessary I am told (?) of > the current > > > > transaction engine design). > > > > > > > > > > This weakness needs to be corrected. > > > > > > > |Also, there must be a HTTPProxyFactory, that binds an > > HTTPInvokerProxy > > > > |into jndi for every ejb. An then, there's the setup / > > integration. I need > > > > |some MBean, that sets up the proxy factory and deploys the servlet. > > > > > > > > I am thinking, bill, we should do a "factory bind" in JNDI > > that knows what > > > > > > I think we may have to use JNDI properties to implement this i.e. > > > > > > jndi.properties: > > > > > > > java.naming.factory.initial=org.jnp.interfaces.HTTPNamingContextFactory > > > java.naming.provider.url=http://yomama.com/JrmpInvoker > > > > > > Also, this may be the best solution anyways. I really want > to avoid any > > > proprietary configuration on the client side. > > > > Coding the protocol into the jndi-name is a good idea, but I'm still not > > confident with this approach. I see it this way: > > > > That's not what I meant. IMHO, coding the protocol into the > jndi-name is a > hack. i.e. ctx.lookup("http/foo") > > I think how you communicate to jndi should be described in the > jndi.properties file. But how you get references to other > objects should be > different. > > I would rather have one of these possible solutions: > > 1. Depending the transport type, a different value for "foo" is returned. > If you do a ctx.lookup("foo") and you're talking HTTP, you get a foo HTTP > proxy back to communicate. > > 2. Let the application developer decide how things are mapped in > JNDI. For > instance, we can recommend that they bind a invoker-proxy binding > into jndi > as "http/foo" , iiop as "iiop/foo". Am I making sense? > > > o the server hosts components and makes them accessible through > > rmi, iiop, > > http, .. (different invokers) > > o serverside interceptors and container are configured per component on > > the server. Invokers are configured as part of the server > configuration. > > Right now, client and container and invoker configurations are > all separate. > This allows us to have multiple transports per EJB(later per MBean too). > > > o that's the server's part. nothing more! > > > > Not true at all. The server has to have knowledge of the client-side > interceptors. Where you idea breaks down is when an method returns a > different EJB or a collection of EJBs of different types. How will your > ideas work then? How will the correct client-side interceptor chain and > transport and endpoint be attached to the EJB refs contained in these > arbitrary collection objects? When I was implementing the multi-invoker > stuff, I played with the idea of having generic EJB refs, but the > idea fell > apart in this scenario. > > Also, many server-side interceptors require a mirror client-side > interceptor > to work. Security, Transactions and especially Clustering fall into this > category. > > > o the client / caller does a lookup in its local jndi namespace with a > > coded name. The coded name is declared somewhere as an > ejb-ref, res-ref, > > *-ref > > o the declaration of this *-ref is parameterized in a jboss specific > > descriptor (jboss.xml): > > + protocoll (InvokerProxy) > > + identifier of the target component (jndi-name) > > + both, the protocol and the address of the component can be > coded into > > a single jndi-name, by using a special url context factory for every > > protocol or by using a subcontext > > This just goes against location transparency and I can't see why anybody > would want to hard-code the address of each component in their > system, or to > manage and know what protocols and what bindings and what client-side > interceptors are required. Client side configuration just does > not scale. > Too many config files in separate places to manage. People want > centralized > config, especially ISVs. > > > + client side interceptors (there are interceptors, that can > _never_ be > > configured on the server / per component / per invoker (think of a > > recording interceptor) > > > > Currently in 3.1 you CAN configure client-side interceptors per component > and per invoker. You're right on this point it would be cool to > have client > specific interceptors. > > > > I also agree that this whole proxy mess needs to be non-EJB > specific and > > > generic to MBeans. The first step though is creating an > > HTTPInvokerProxy > > > and HTTPInvoker. > > > > The HTTPInvoker is a servlet or httpd. There's no lookup of > this invoker, > > only invocations, that are sent to the servlet. > > > > how many remote calls are involved in a simple acces to a bean method: > > > > 1. lookup > > 2. create > > 3. bean > > > > why not skip the first one? just give the client a proxy, wether the > > target component is accessible or not. the invocation of create can fail > > anyway. there's no way, how we could assure, that a create works, if the > > lookup has worked. thus imo there's no problem, if we skip the lookup. > > > > Your ideas are cool. I think it would be very useful to be able > to create a > proxy at the client side. i.e. give an interceptor chain, transport, > endpoint, and Java interface and you get an MBean connection. But I think > this would be the exception and not the norm. > > > That's like communication happens in real life. If I send you a message, > > you won't give me the pencil, I have to use. I don't lookup your address > > at your door. I look it up in my private addressbook. If I send the > > message, I don't know, if the address is correct. However, I'll > notice if > > it was incorrect. > > > > Holger > > > > > > > > ------------------------------------------------------- > > Sponsored by: > > ThinkGeek at http://www.ThinkGeek.com/ > > _______________________________________________ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > ------------------------------------------------------- > Sponsored by: > ThinkGeek at http://www.ThinkGeek.com/ > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ------------------------------------------------------- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
