Re: [jboss-as7-dev] PART 3! of EJB Remote client design
On Thursday 22 September 2011 01:04 PM, Jaikiran Pai wrote:
> This gives us configuration-free JNDI. Also, it gives us a JNDI
name
> scheme we can use in server-side EJB references as a lookup-name which
> can create dependency-free injections of remote EJBs that may not be
> present on the current system. And it's also nice in that it doesn't
> interfere with "java:" spec lookups at all.
I didn't understand the dependency-free injection part, but I guess
what you are saying is that having a new ejb: scheme has an additional
advantage too?
Furthermore, I'm not a JNDI expert, so I might be missing some basic
details. But why not treat "java:global" just like we would treat this
new "ejb:" scheme? Is it the namespace "java:" and its traditional
meaning that it's a in-VM namespace? I mean why do we need a new
"ejb:" scheme for remote clients? Furthermore, although the EJB3 spec
or other spec doesn't say anything for/against using the EJB3.1 spec
mandated JNDI name scheme (java:global) from remote JVMs, I think some
other app servers (GlassFish?) do allow these JNDI names to be used
from a remote client. EJB3.1 spec Global JNDI section talks about
portable JNDI names, so I'm not sure whether not supporting
java:global from a remote client is right or wrong.
To put this in a more practical
perspective - consider a usecase where a
user has App1 containing a Foo bean which exposes a remote view. As per
the EJB3.1 JNDI spec, this remote view becomes available in JNDI at spec
mandated namespace java:global/a/b/Foo!blah jndi name. Let's also assume
that the same server has another deployment App2 which acts a client of
App1 and uses the java:global JNDI name to lookup and invoke on the EJB.
Now all this works fine since it's in-VM (on the same server). At a
certain point in time if the user decides, due to architectural reasons,
to move App2 to a different server instance then he will have to end up
changing the jndi name from java:global to a JBoss specific custom ejb:
scheme. I personally don't think this is a good idea. Note that usecase
like this work fine in previous AS versions and JNDI name change isn't
required when the deployment is moved to a different server - it's just
a matter of passing the right PROVIDER_URL during the lookup.
Furthermore, the Java EE 6 spec section 5.2.2 says this about
java:global JNDI namespace:
<quote>
java:global - Names in this namespace are shared by all applications
deployed in an application server instance. Note that an application
server instance may represent a single server, a cluster of servers, an
administrative domain containing many servers, or even more. The scope
of an application server instance is product-dependent, but it must be
possible to deploy multiple applications to a single application server
instance.
</quote>
So the spec does allow enough scope for java:global namespace to be used
across servers from remote clients.
-Jaikiran