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

[Jason Greene]

Note that java: global names have no notion of "distinct name" so can not be used to represent multiple servers without configuration.

Sent from my iPhone

On Sep 22, 2011, at 8:24 AM, "David M. Lloyd" <david.lloyd at redhat.com> wrote:

> 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
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev