|
That is a rather big question. EJBs are all about tradeoff. The portability, standardization and (with the bigger vendors) failover that comes with EJB definitely comes at a price. First of all, is the financial overhead. If you need a fully supported EJB implementation with distributed transactions, failover and clustering, you are looking at a $8-10,000 per processor license cost.
Additionally, there is performance overhead incurred by the EJB life-cycle, particularly in entity beans. Some of this overhead can be mitigated by vendor-specific bean caching options, but these performance enhancements often hamper the servers capability to give you up-to-the-second data.
Of course, any time you are using RMI or CORBA, you are incurring network overhead, but that is true of any distributed application. It really depends on the scale of your application. If each node requires distributed transactions, failover, etc, EJB could be the way to go. There is no reason that all your nodes have to be running an EJB server. For the simpler ones, you could simply use Java objects that are exposed via an transport or RPC mechanism of some kind.
I think the most important question in a big cross-continent app like yours is the transport. What model is most appropriate between nodes: RPC or asynchronous messaging, an XML API? How can you make that communication secure and robust enough for your business requirements? Once you figure that question out, you can handle the implementation of each node individually.
|
