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

[Stuart Douglas]

On 22/09/2011, at 5:34 PM, Jaikiran Pai wrote:

> 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 distinct name
> 

This problem is why we decided to make the app name required. 

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

Personally I think this should be an error, but it could go either way.

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

java:ejb is different to java:global in that it can contain references to EJB's from a 
different VM. It can also only contain EJB references. This means that you will never
get a NameNotFoundException when looking up a non-stateful bean in java:ejb, instead
the backing JNDI implementation will parse the name and return a proxy for the given 
app/module/ejb name (the same as what would happen with a call to EJB.getProxy()). 

This is not really something we could do in the java:global namespace.

Stuart

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