File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes EJB and other Java EE Technologies and the fly likes basic ejb question Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "basic ejb question" Watch "basic ejb question" New topic
Author

basic ejb question

Steve Mutonshi
Greenhorn

Joined: Jun 13, 2008
Posts: 13
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" ?
Tim Kutz
Greenhorn

Joined: Jul 07, 2008
Posts: 2
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: basic ejb question