Hi Could you elaborate more ? We use remote interface when we have some consumer outside of the server Apps or we have a clustered environemt. in many case we implement both local and remote interfaces to achieve better performace , use local interface when you are caling ejb methods from same JVM and use remote interface when you call it from an outside jvm.
First of all in my opinion there are very few reasons to use remote interfaces with entity. Good application design should avoid that. On the other hand I�m not very convinced that the answer is always that simple when deciding how to access the SLSB fa�ade: remotely or not. Apparently if the clients to your SLSBs are collocated (the Web server and the EJB container are collocated and you access the SLSBs from within JSPs or servlets), then there would be very few reasons to use remote interfaces. However there is one more exception from this rule: if the application that accesses the bean and the bean itself are not packed together within the same ear (like a war and ejb.jar deployed separately), then you cannot use the local interfaces. Arguable though, this could be fixed by simply re-packing the application and it represents the exception and not the rule. Performance wise local interfaces should provide (at least in theory) the best results. In practice though I�m not very convinced that this is true for every application. The reason is this: If the web server and the ejb container are collocated, the box hosting them could be much busier than it should. Bea for example estimates that the overhead for a box hosting both the web proxy and the ejb container will increase between 25-50% more than a box hosting only the ejb container. One other thing to consider is that bea�s web proxy is less performant then other web servers like IPlanet for example. Hence for very business processing applications, having the web server and the ejb container running on separate boxes, might actually provide better performances then collocating them. In other words, the fast server process gain will overcome the RMI overhead. In that case, using remote interfaces should be the way to go. Another very important point to consider is that remote ejb clients will benefit from better clustering optimizations than local clients (which by the way will get no clustering benefits. However this is another long story and I�m not going into many details). Of course appropriate capacity planning, application tuning and early load testing should decide whether to collocate the servers or not. Just to finish my plea, I�d like to mention that for small and not very server intensive processing applications, it will probably always be more efficient to have collocated servers and entirely use the local interfaces. And to add one more thing for such applications is little point in using EJBs anyway. Having Spring & Hibernate and preferring AOP for implementing middleware services over the EJB specific configuration settings it�s definitely the way to go these days. Regards.
Originally posted by Masoud Kalali: Hi Could you elaborate more ? We use remote interface when we have some consumer outside of the server Apps or we have a clustered environemt. in many case we implement both local and remote interfaces to achieve better performace , use local interface when you are caling ejb methods from same JVM and use remote interface when you call it from an outside jvm.
I have an ear with an war and ejb jar files.My web app access an remote session facade for business menthods.I have all my objects in the same JVM (App server).
1.In this case should session facade be remote or local.
2.But the app server is in a clutered mode.Will local session facade fail in cluster mode.
He repaced his skull with glass. So you can see his brain. Kinda like this tiny ad:
free, earth-friendly heat - a kickstarter for putting coin in your pocket while saving the earth