On Thu, 27 Jun 2002, Bill Burke wrote:
> 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.
Actually I've already learned from this discussion ;-)
>
> 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?
You mean no url provider, but jndi.properties (=environment)? OK. But I
can't live with global jndi.properties. I need them on a per *-ref basis,
because the components I connect are spreaded across several different
application servers.
> > 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.
Good point! Never thought of that. However, the result of an invocation
are handles or something similar, right?. Can we put the configuration,
that is comming from the server into these handles? Thus a proxy is
partially configured from the client (client chooses the transport and
might in very few cases add its own interceptors) and mostly from the
information, that comes with the handle?
> Also, many server-side interceptors require a mirror client-side interceptor
> to work. Security, Transactions and especially Clustering fall into this
> category.
>
> 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.
I want to keep these addresses out of my code, thus only use *-refs (call
it nicknames). But these nicknames have to be mapped to something, that
fully identifies the target. For the server doesn't know the client, but
the client knows, what components are there on the server, this mapping
has to be done on the client? I cant send an email to a nickname. I have
to lookup the email address.
OK, you convinced me, that most of the interceptor chain has to be
configured from the server. My point is now, that I don't want the lookup
in the server's jndi-namespace, before invoking the create method.
1. an invoker proxy is choosen on the client
2. the client knows the address of the invoker (always the same)
3. the client knows what component it wants to connect to (jndi-name)
4. this is all, we need to know, in order to send the create invocation
5. the jndi-name is passed with the invocation of create. the result is
a handle carrying all information, that is required to setup the client
side interceptor chain.
What am I missing?
Holger
-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
