"Need" is pretty subjective, I suppose. I'm trying to alleviate the confusion prevalent on the user's forums regarding "where is my EJB?" and "why can't I cast this properly?" by abstracting the JNDI calls from EJB clients. In short, I think making an enterprise client should be as simple as configuring a number of remote application server(s), and requesting services of them. ServiceLocator.getStatelessService(MyServiceRemote.class).goService(); Compared to: Properties props = [configuration]; | Context ctx = new InitialContext(props); | MyServiceRemote myService = null; | Object obj = ctx.lookup([some JNDI address that could be transparent to the developer]); | myService = (MyServiceRemote)PortableRemoteObject.narrow(obj,MyServiceRemote.class); | myService.goService(); ...which at first glance really only looks like a few lines of code, but really: * The client has to know ahead of time the JNDI Address of the remote service. What if this changes on the app server? I can imagine more than a few cases of repackaging/changing EAR names across different versions, and then the client code/configs would have to be updated as well. * SLSB and JMX stubs should be cached to avoid the overhead of JNDI trips; why not make a lib that'll do this for the developer rather than imposing this responsibility on the community? The "need" comes into play the second an application developer wants to do any of the things not addressed by JEE Application Clients (above post). There are plenty of cases in my current application where I'm not running a main class, or I'd like to invoke a Service from a non-EJB component (where injection isn't available even in-container). S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086271#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...