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

[Jaikiran Pai]

Comments inline.

On Thursday 22 September 2011 10:30 AM, David M. Lloyd wrote:
> Client JNDI Revisited!
> ----------------------
>
> Based on feedback here and in IRC, we're changing our approach to client
> EJB thus:
>
> A new JNDI "scheme" will be introduced called "ejb".  Lookups into this
> scheme following a naming convention will yield remote EJB proxies
> directly.  If the interface is not stateful, then the proxy is
> immediately available without a server round-trip.
>
> The format for "ejb" scheme names is like this (square brackets are not
> literal; they indicate that the enclosed section is optional):
>
> "ejb:appname/modulename/[distinctname/]beanname!interface[?stateful]"
The appname (assuming it's the .ear name that we talking of, like in the 
spec) should be optional too, isn't it? Although making appname optional 
might end up with non-deterministic jndi name like:

ejb:a/b/c!interface

and we wouldn't know whether:

1) "a" is appname and "b" is module name
or
2) "a" is module name and "b" is distinctname


>
> The "appname", "modulename", and "distinctname" are the identifying
> names of the EJB deployment.  "beanname" is the EJB-spec name of the
> EJB.  "interface" is the Java type name of the interface being returned.
>    The "?stateful" query parameter indicates that a session should be
> initiated on lookup.
>
> Since it is likely that users will erroneously use "?stateful" on a
> stateful home interface (which is itself stateless), the lookup code
> will detect whether the interface extends EJBHome before attempting to
> initiate session, and if found will instead emit a warning.
What about a case where the user adds a "?stateful" to a SLSB jndi name 
and we end up doing a server trip and realize it's a SLSB. Do we throw 
an error or just log a WARN?

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

On a slightly different but related note - I believe we'll be backing 
this client JNDI impl on our EJB remote client API which uses 
EJBClientContext to select a target when a proxy is invoked. The design 
for that mandates that a (correct) EJBClientContext be associated with 
the caller thread. So in case of JNDI invocation which would look like:

MyEJB proxy = InitialContext.doLookup("ejb:app/module/bean!intf");
proxy.echo("hello");

Is the client still expected to set the EJBClientContext before the 
proxy invocation? If not, how would we associate a EJBClientContext 
(with the right set of EJB receivers) for the invocation? Does the 
jndi.properties and the properties passed to InitialContext constructor 
play any role in deciding the set of EJB receivers that are available in 
the EJBClientContext?


-Jaikiran