Originally posted by Kaydell Leavitt:
Thanks.
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?
-- Kaydell
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.