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:
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.
o that's the server's part. nothing more!
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
+ client side interceptors (there are interceptors, that can _never_ be
configured on the server / per component / per invoker (think of a
recording interceptor)
> 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.
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
