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
