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

[Carlo de Wolf]

On 09/22/2011 07:00 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", "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.

Both a SLSB and a SFSB can have an EJBHome interface for their remote 
home view. So I don't see how this can play a role in determining the 
session characteristic.

In fact a call to a home view is always session-less, both for SLSB and 
SFSB. The proxy returned by the create method represents the possible 
session.

> 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.
>
> This should address all the issues raised with client JNDI thus far.
>

Binding the URL ObjectFactory to java:something would result in exactly 
the same functionality. We can still offer this choice to users.

Carlo