I heard one advantage of using EJB is it utilizes RMI type protocol that allows people to make remote calls from different JVM. But in most cases, people pack .jar(EJB codes), .war (servlet/jsp code) into a single .ear and deploy this .ear to application server.
1. Does this mean the servlet/EJB are in the same JVM ?? Then what advantage are we taking of ?
2. I see in some books' code sample, when they create "value object", they implement "Serializable" to make it able to pass via network. But if the value object is packed in the .ear deployed to a server, is it still necessary to implement "Serializable" ?
If your application is being deployed only on a single server in that way, then yes, it's all running in the same JVM, and isn't actually serialized over a network at all.
However, if that's the only deployment scenario you're using, you really aren't in the class of applications that are EJBs are designed to solve. As your application scales to support more users, or even just to provide fault tolerance, you'll want to deploy to a cluster. That is, multiple machines running the same application, sharing state between them, and appearing to the external clients as a single processing unit. Once you get into this scenario, you are sending the objects over the network, between nodes, and even your HttpSession is being replicated between the servers, to support failover.
It is this sort of environment that EJBs are meant to address. If you can tolerate hours of downtime due to a blown drive or NIC card, and only deploy to a single server, then you really don't need EJBs. If you need a recovery plan that includes guaranteed uptime, then you need a system with automatic failover, which is one of the services that EJBs provide for you.
The other area that EJBs really shine in, is when the system has to manage distributed transactions, but that could, at least in theory, be done with just JTA and any JTA-aware persistence implementation if you aren't deployed to multiple nodes.