For Remote calls it uses RMI over IIOP. So yes. You can also create local EJBs which are running in the same JVM that will not use RMI or a remote call. This is like when you have a Servlet that needs to use an EJB in the same App Server, and you have created an ear file that holds both the servlets and ejbs.
I've been reading up on Java EE and I have read in several places that the parameters and the return types that are used with remote beans must be RMI compatible types. Which types are RMI compatible? Serializable objects? Are primitives not RMI compatible types, except that with Java 5.0's autoboxing if this was a problem before, is it not a problem with 5.0?
Do I understand correctly that sockets uses TCP and that RMI uses sockets and that EJB uses RMI? Then where do JAX-RPC and JMS fit in?
Originally EJB used straight RMI. RMI-IIOP is a more CORBA-friendly (that is, non-Java clients) protocol that came in around EJB 2.0. Last time I looked, you could actually select which protoocol you wanted. Straight RMI is faster, but not portable like RMI-IIOP.
Yes, you're correct. RMI is normally done over TCP/IP, which used sockets.
JMS is a protocol for message passing. Message-driven EJBs use JMS unless I'm mistaken. Entity and Session EJBs are not message-driven, so they don't.
JAX-RPC is an XML-based RPC protocol. I don't know of an EJB implementation using it. XML is best used when primary considerations are portability and self-descriptive capabilities. There's a non-trivial penalty involved in outputting and parsing XML, and usually in the size of the payload. Though for the cost of some good text compression that can be minimized.
Auto-boxing is an implicit conversion mechanism. It shouldn't have any impact on serializability other than possible confusion as to whether you're transmitting a primitive or one of the primitive wrapper classes such as java.lang.Integer. If there's a primitive wrapper that isn't serializable, I can't think of it.
Just as a comment. Classes are serializable. Interfaces are not. Many are those who thought that they could stash away their JDBC Connection objects into a J2EE session. Which generally only works if the session wasn't serialized out and back again.
An IDE is no substitute for an Intelligent Developer.