Application Client access EJB on Glassfish via a remote interface. Can I do it via local interface?

I recently gone through a Netbeans article about how to create and Enterprise Application Client that access EJB deploy on Glassfish.(Article Link Here) I have couples questions about this article.

The article exposes the EJB via a remote interface, I think this will result in application client have to make a remote invocation. There are overheads for doing this. While local interface parameters are passed by reference, remote interface parameters are passed by value, which results in parameters being copied -> this could be quite expensive.

So my question is why use remote开发者_如何学Go interface here? Is it because the client machine and the Glassfish might be on different machines (different JVM). So if I say that the client code and the Glassfish server are on the same machine (same JVM), can I somehow alter the design to use local interface to avoid overheads.

Since all the codes are provided in the article, I wont post it again here. Please let me know if you still insist me post the code

The EJB FAQ on the Glassfish site addresses this question, and it is quite clear that it is not possible, unless you use the embedded container:

I have an EJB component with a Local interface. Can I access it from an Application Client or a stand-alone java client ?

If the EJB component is running within the server, no. The EJB Local view is an optimized invocation path that uses call-by-reference semantics. It is only available to web components and EJB components that are part of the same application as the target EJB component. To access EJB components that are running in the server from an Application Client or stand-alone java client, you'll need to use either a Remote 3.x Business interface, a 2.x Home interface, or web services.

One alternative, if using GlassFish v3, is to use the EJB 3.1 Embeddable API. This allows a Java SE program to directly execute EJB components within the same JVM, without using a server process.

The next question also gives a hint on why this is the reason - the Java EE specification has never explicitly specified that local interfaces MUST be accessible across multiple applications in the same JVM/container.

Application server vendors, therefore, have never done this, except for one or two cases. Most of the reasons eventually boil down to classloaders - the EJB module has it's own classloader (which sometimes is also the application classloader), and if the local interface has to be shared across multiple applications, then all of them must share the same classloader, or the application server must load the interface classes in a parent classloader.

It uses a remote interface because the application client is in a separate JVM than the EJB server. The only way to talk between the two is via a socket.

What you're are talking about is something more akin to an embedded EJB server, that's embedded in the client. That's not what the app client model is supporting.

GFv3 can be embedded, so it can be done, but it's not a described part of the Java EE model or profiles, where the app client model is part of the Java EE spec.