EJB design: EJB vs Web Services for Distributed JavaBeans
We are looking at starting a large scale J2EE development using EJB 2 and want to have the busines logic beans (middle tier) distributed across various servers for scalability/failover. Im fairly new to EJB and want to make sure what we decide isnt blinded by the EJB buzz/FUD
- Posted by: Paul Nearn
- Posted on: March 03 2003 06:35 EST
The way I see it we have 3 design options
1. Use EJB remote interfaces for the distributed architecture as in EJB 1.0. Pros, easy to do, Container managed service. Cons Slow RMI
2. Use Web Services ( XML, SOAP, UDDI etc) to allow the distributed components to interact (again using RMI?). Pros ?? Cons ???
3. Use EJB's with local interfaces and use Server Clustering to provide the performance and high end availabilty. Is this even feasible for EJB containers?
Im really after peoples thoughts here. I'd like the thing to perform and scale but dont want to reinvent the EJB wheel if I dont have too. Im not sure how the Web Services stuff works in practice with J2EE ( are there API's, will it perform as bad as EJB's using RMI etc) and will it become industry standard? Im leaning towards option 3 and letting the server manage the failover but will EJB containers still manage this in terms of passivation/reacvtivation, trans.mgt and failover when the interfaces are local and not remote and clustering is used
Anyone got any practical project experience to bring to bear to help me make my mind up here ?
1. Use EJB remote interfaces for the distributed architecture as in EJB 1.0.
> Pros, easy to do, Container managed service. Cons Slow RMI
Easy to do, yes. Slow RMI, not really. RMI is pretty darn fast when compared to XML over HTTP (which is what Web Services mostly are).
> 2. Use Web Services ( XML, SOAP, UDDI etc) to allow the distributed
> components to interact (again using RMI?). Pros ?? Cons ???
Web Services and RMI don't go together. The primary protocol used to transport Web Services (SOAP) messages is HTTP. Another option is SMTP, which is used in maybe 1 out of 100 cases...
Pros are the independence of underlying platforms and programming languages. Cons are slower performance due to the XML overhead and the fact that you'll have a hard time implementing a better replication/failover system using Web Services than the one provided by your application server of choice...
I'd say go with the EJBs.
So if we use EJB's over RMI can we use built in container features to manage failover, load balancing etc or should we let the server do that ?