[jboss-as7-dev] PART 3! of EJB Remote client design

[Jaikiran Pai]

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