Yes. For remote calls (different JVM instances), you need not have the actual implementation in your classpath. You only need the stubs (i.e. ejb-jar containing interfaces) so that you can make a call against that interface. You don't make a call against the implementation because you don't have direct access to the implementation - even through JNDI.
If you deploy your EJB without specifying the name or mappedName(vendor specific, not portable) then the application server will assume a default global JNDI name. The default global JNDI name is dependent on the application server.
I would recommend reading EJB 3 in Action. The answers to your questions can be found there.
Based on your configuration, the glassfish app server is on the same machine as the tomcat. If not, then please change it to the actual IP.
Given that all jars are present, then if the configuration of the host and port are incorrect then you would only get NamingException. Other exceptions would point to configuration and environment problems.
Whenever a business method is called on a session bean, the container creates a transaction for you if no transaction exists or joins the parent transaction when a transaction exists. This is the default behaviour unless you declare a specific transaction attribute type in the method level.
So if methodA has a default transaction attribute type, and it invokes methodB, methodB will inherit the transaction from methodA. If methodB fails, then methodA also fails.
You can play around with the transaction attribute types to control the transaction for each method.
This will depend on the application and provider that binds session beans in the RMI registry.
Try the following -
1. Make a servlet
2. Declare the session bean as a instance variable of the servlet
3. Mark it with @EJB annotation
4. Package the WEB and EJB component into an EAR
5. Remove the <ejb-ref> element in web.xml
In glassfish, you can use the appclient <jar-name> that simply runs the application in the environment of the application server. That is why DI works there.
However, for the said code above, it won't work because you are running the client as a stand alone application. For stand alone application, you need to create a Context supplying the
parameters for the provider(i.e. ORB host, port, provider url). DI on application client will only work if you packaged it within an EAR. I am not sure how to do this in JBoss though.
I suggest creating a new EAR and test the DI functionality in a servlet if the sole purpose is to test the DI functionality.