The first thing you need to do to enable your loose coupling is to really lock down your interfaces and their granularity. If you change the interface at all, both servers and clients will need to be redeployed. I believe this is true even with web services, it's definitely true with Remote EJBs.
That said, I've had decent luck (without really formally testing it) with Remote EJBs being stable across deploys (in that I've not had to redeploy the client if the interface remain unchanged). But I don't use the @EJB injection, I look it up via JNDI.
Are you doing WAR -> EJB? or EJB -> EJB?
Anyway, doesn't really matter.
I believe that EJB references (ala @EJB) can be cached, and that may well be what is happening for you. So, one thing that you can do to mitigate that problem is rely on your own lookup mechanism rather than @EJB. You can cache them in a singleton, and then when you do a lookup for a new instance, you can add a "ping" do nothing method, check that, and if it fails just look it up again to get a "new" one. Or you can have a "reset" option to reload you cache and tickle that when you redeploy. Or you can not cache them at all and always look it up (that's what I do, mostly because I simply haven't had the need to put that much thought in to it to make it more performant.)
So, those are some ideas on how you can get around the Remote EJB connection issues.
Regarding the web services, while the NB generated code DOES "hard code" the URLs, and it uses those default methods when you use the "call web service" wizard, you can readily specify your own URL when getting the port for the web service. If you look at the generated code (notably the default constructor for the service class), you can see where this is done -- it's really simple, and we do it all the time.
Here, again, you'd be best off writing a "Web service factory" class to handle that problem for you and reference that in your code.
Finally, between using Remote EJB and Web Services, I've found in some specific cases that the Remote EJB is SLOWER than Web Services (it was a lot of data), but overall Remote EJB is EASIER to use (since it's Just Java). For example, you can't pass and return Interfaces in Web Services, and your domain objects are richer (since with WS you mostly use generated, stupid skeletons on the client -- which can be no fun).
Finally, there's a setting, though it escapes me, that lets Remote EJBs adopt reference passing semantics, but I don't know if that can work only for components in the same EAR or just within the same container, I've not tried it.
But clearly, if you can use reference mechanics, you'll get much better performance than either Remote EJBs or Web Services.
I would try out some of these suggestions and do some tests to see if its workable for what you're trying to do.
And let us know what you find out!
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=308283