I didn't see the original thread, but it seems the gist of it is you have two pieces of an application you wish to keep separate, but have them deployed in the same container. I'll run with that assumption.
Option 1 is out, simply because the EAR is the fundamental deployment artifact. You can't deploy only a "piece" of an EAR. So if you want to keep, say, your WAR and EAR separate, you can't bundle them in the same EAR.
Option 2, using Web Services, and Option 3, using Remote EJB, are effectively identical, though there are a few distinctions.
The primary distinction is that if you use Remote EJB, you can easily move your domain objects "as is" from the EAR to the WAR. This differs from using a Web Service, as the Web Service, first off, can not send an object graph, but only an object tree. This is an issue if you have objects in a Parent-> Child relationship where the child points back to the parent. The standard Web Service code won't marshal that object, you need to sever the child->parent link.
And if you rely on the high level tools to creating your Web Service artifacts, the objects you get on the client are literally just shells to access the payload, rather than domain objects that may well have extra, more interesting logic.
Basically, Remote EJB makes working with your objects much more transparent compared to Web Services.
That said, I've found some performance and memory issues when sending large lists of objects via Remote EJB, and actually found Web Services to be faster in that case. In the end I stayed with Remote EJB, but I sent over a large byte array of the serialized and compressed list of objects, this was easier for me, and more consistent vs introducing an Web Service for a specific case.
As for referring to a Remote EJB, by default (in 3.0), you can look up the bean by its Remote Interface class name. Check the Glassfish EJB faq for details.
I do this all day long. I have a WAR independently deployed to the container referencing a local EAR, via Remote EJB. I do this to keep the WAR separately deployable from the EAR, and it works fine. As a side affect, WAR deploys are faster during development than EAR deploys, so my WAR development turn around is quite speedy.
I wish that GF would do the internal optimization of allow remote calls to be local calls when deployed in the same container, thus giving us the best of both worlds.
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=274623