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

[Stuart Douglas]

I have an initial implementation of this at https://github.com/stuartwdouglas/jboss-ejb-client/commits/master/ if anyone wants to give feedback. 

Stuart

On 23/09/2011, at 12:50 AM, David M. Lloyd wrote:

> On 09/22/2011 08:59 AM, Carlo de Wolf wrote:
>> 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?
> 
> Yeah I wanted to prevent that but given that (a) it's considerable added 
> complexity (we'd need another proxy type) and (b) it's one edge case of 
> EJB2-style stuff that hopefully is less-used, it doesn't really seem 
> worth the trouble.
> 
>>>>> 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.
> 
> The reason I don't feel "java:jboss" applies the same way as "ejb:" is 
> that (a) it is very unlikely to conflict, given that "jboss" is 
> basically trademarked, and (b) it behaves very similarly to other 
> "java:" namespaces.
> 
> 
> -- 
> - DML
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-as7-dev/attachments/20110926/4e298d0d/attachment.html