On Oct 1, 2006, at 11:16 AM, David Jencks wrote:
Dain has been working on a global jndi implementation that looks
really nice. However the deployment of bindings part of it has
brought up some long-festering architectural worries and perhaps we
are now in a position to deal with them in a systematic manner.
David Blevins pointed out to me a long time ago that one of the
core principles of openejb was that ejb containers should have
nothing transport specific attached to them. This was when I
installed a TSSBean reference in ejb containers to enable binding
ejbs into corba. I pointed out that letting the ejb container know
jndi-names and local-jndi-names had the same problem, and IIRC he
agreed that this was an architectural flaw. In any case,
intentionally or not, he convinced me that both the tssbean link
and the jndi names should not be attached to the ejb container. If
you install dain's global jndi stuff the jndi names now get
recycled up to 3 times: for the openejb proprietary jndi impl,
global jndi, and corba. The global jndi connector binding creates
a similar but worse problem for j2ca connectors, since it tries to
bind using only the "name" component of the abstract name, rather
than allowing a specific global jndi name, and AFAICT it doesn't
let you specify which connectors you want to bind.
I think for all of these situations a cleaner runtime solution is a
component that links the thing you want to bind and the binding
context, and includes the name(s) you want to bind under.
Currently this would I think have to be a gbean. This is what Dain
implemented for gbean bindings. So, I'm proposing that bindings
for connectors in global jndi, and ejbs in global jndi, corba, and
the openejb jndi, each be set up by gbeans, each holding the name
(s) to bind under and a reference to the object to be bound. This
part is pretty easy to write.
Slightly harder is deployment: setting up these gbeans. If we
modify our schemas this can be done using NamingBuilders: here they
won't be constructing the components jndi context but rather
exposing the component in various naming systems. I think the
really hard part is figuring out some xml that is manageable to
write and expresses the meaning clearly.
For connectors it's pretty easy, we can just have a repeating element
<global-jndi-name>foo</global-jndi-name>
For ejbs with the current 3 naming systems it's a bit harder. One
possibility would look something like this:
<jndi>
<global/>
<corba>
<tss-link>foo-tss</tss-link>
</corba>
<openejb/>
<remote-name>foo</remote-name>
<local-name>bar</local-name>
</jndi>
where the global, corba, and openejb elements indicate which naming
system to bind to and the names are supplied with remote-name and
local-name. A remote jndi would ignore the local-name elements.
You could have multiple jndi elements to get different bindings in
different naming systems.
To make this extensible the naming system elements would have to be
in a substitution group and extend an abstract element. The ones
we know about now could all be in the same namespace.
Thoughts?
There was a discussion on this in context of OpenEJB 3. It was short
and no real conclusion was made, but let me see if I can't dig it up.
-David
thanks
david jencks
