[jboss-as7-dev] EJB Remote client design

[David M. Lloyd]

On 09/20/2011 04:33 AM, Jaikiran Pai wrote:
> On Thursday 15 September 2011 09:20 AM, David M. Lloyd wrote:
>>
>> Client JNDI
>> -----------
>>
>> Client JNDI is just a simple in-memory JNDI implementation.  We will not
>> automatically bind anything to it at all, except in two possible cases:
>> 1. A simple configuration file which describes what to bind, or 2. A
>> configuration instructing a binding list to be fetched from somewhere.
>>
> I haven't found clear details around this in various JIRAs on what this
> actually means to an end user. In previous version(s) of JBoss AS and
> other application servers that are available, a remote client (for
> example a standalone Java app) works as follows for remote EJB invocations:
>
> 1) The (remote) client setup adds some app server specific jars to the
> runtime classpath of the client
> 2) The code uses a app server specific or EJB3.1 spec standardised JNDI
> names of EJBs to do a lookup using javax.naming.Context
> 3) Invokes on the returned bean view proxy.
>
> In these above 3 steps, there is no other configuration or setup
> required by the remote client to invoke on the bean using a JNDI name.
>
> So with the Client JNDI that we are proposing in AS7, does this mean,
> that in AS7 we are _mandating_ an additional step/instruction to
> configure/setup the JNDI on the client side so that the invocation via a
> jndi name works? Or is it going to be transparent to the users without
> any explicit configuration instruction?
>
> P.S: I am not talking about Java EE "application client" which is much
> more than just remote invocation. Setting up a "application client"
> always required additional configurations in all application servers
> that I know of.

Yesterday Jason and I chatted about another option: an "ejb:" JNDI 
scheme which simply directs to the API to construct any proxy.  It would 
work like this:

 
context.lookup("ejb:theApp/theModule/theDistinctName/Stateful/theBean!org.interf.Blah");

The name would be decomposed to actually create the proxy without 
contacting any server or requiring any configuration.  It could also 
coexist with a "java:" implementation meaning it could work on the 
server side too.

Note that in your above example, you'd still have to tell it at least 
what server to talk to.
-- 
- DML