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

[Carlo de Wolf]

On 09/22/2011 03:21 PM, David M. Lloyd wrote:
> On 09/22/2011 03:52 AM, Carlo de Wolf wrote:
>> 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.
>
> That's what I said.  EJBHome are always stateless.  Therefore if 
> ?stateful is given for an EJBHome, it is ignored and a warning is issued.

That implies that home.create() will always go round trip. Isn't that 
what we want to prevent for SLSB?

>
>>> 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.
>
> Except that "java:" belongs to EE, and this is very much non-spec.  I 
> don't think this type of functionality belongs in "java:" under any 
> circumstances.
>

In that case we should also refactor java:jboss.

Carlo