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

[David M. Lloyd]

On 09/22/2011 04:38 AM, Jaikiran Pai wrote:
> 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.

This is necessary.  The "java:" names are created in response to 
_deploying_ an EJB, not _consuming_ one.  If the Remote EJB is on a 
different server, there's no reason to expect it to appear; on the 
contrary it would at the least require extra configuration.  Things are 
further confused when accounting for remote EJBs being undeployed, which 
should not affect consuming deployments as they may be able to get the 
EJB from another server!  If we used java: then undeployment would cause 
consuming deployments to also be removed which is undesirable.

> 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.

Nevertheless, I don't consider it a good idea.

-- 
- DML