Some concerns on remote EJBs with connections to a number of interfaces

[Gordon Pallado]

We currently have a bankng application that uses local EJBs. Its has the combined tier architecture (jsp,servlets and ejb in one ear file in one server). The EJB we use has a number of calls to three different mainframe web sevices in its methods. Now, there has been a drive to move our business layer into another server for more flexible load balancing or clustering. The EJBs would now be called remotely.

This is what worries me. Is it a bad idea to have ejbs calling different interfaces as remote ejbs?... I mean, this would only add more networks round trips and point of failures. First is remotely calling the ejb, then the ejb would call a web service. A lot of round trips before the caller receives the response. Do i really have to worry about this and disagree not to move the ejbs out? or do you think the benefits of this will outweigh the drawbacks?

thanks and good day to y'all :-)

[Ryan Tracy]

Java Enterprise Edition was created to be multi-tiered. I don't think that you will even notice any degradation in performance. In fact you should notice an improvement because of the separation. Generally networks are not the bottleneck in applications. Session beans are the ones that will be doing most of the work as far as your interfaces and they are fairly light. Really the only way to probably convince you that it will be fine to do this is to actually try it. Create a simple Remote App and a local one that has a timer as part of the functionality. Also, keep in mind the ability to scale tremendously as you tier out. Many people worry about things they don't really understand. I would ultimately say give it a chance. It is not really that hard to go back if it does not work out.