Optimizing EJBs for WebSphere Application Server
We are working on developing a Java EE based application. Our application is Java 1.5 compliant and will be deployed to WAS ND 6.1.0.21 with EBJ 3.0 and Web Services feature packs. The configuration is currently one cell with two clusters. Each cluster will have two nodes.
Our application, or our system, as I would say, falls into two or three parts.
Part 1: Damage deployed to a single cluster containing 3rd party vendor code combined with customization code. Their code is EJB 2.0 compliant and has many remote home interfaces.
Part 2: The ear is deployed in the same cluster as the first ear. This ear contains EBJ 3, which makes calls to EJB 2 supplied by vendor and custom code. These EJBs 3 are used by a JSF frontend also packaged with an EAR, and some are also exposed as web services (JAX-WS 2.0 with SOAP 1.2 compliance) to other clients.
Part 3: There may be other services that are independent of our provider app / custom code. These services will be EJB 3.0 and web services that are deployed in a different cluster.
As recommended by some of the IBM staff on the site here, communication between nodes in a cluster may be EJB RMI. But if we go through clusters and / or other cells, then the message should be web services.
However, some of us are wondering about performance and communication optimization for the speed of our applications that will use our web services and EJBs. Most EJBs now appear as remote. (and our vendor set them up that way rather than exposing local home interfaces). We are wondering if WAS does any optimizations between applications in the same node / cluster node space. If two applications are installed in the same area and they are calling each other through the remote home interface, is the WAS smart enough to make it a local call to the home interface?
Are their other optimization techniques? Should we consider them? Shouldn't we? What are the costs / benefits? Here's a question from one of our team members via email:
Q: Suppose we are developing our EJBs as remote EJBs where our UI controller code talks to our EXT java services via EJB3 ... what are our performance optimization options when both the EJB server and client are running in the same container?
As one point of reference, Google has provided me with some oooooold web application performance tuning documentation since 2000 that explains the tuning configuration you can tune to enable Call By Reference for EJB exchange when they are in the same application server JVM. It states the following:
Since EJBs are inherently location independent, they use the remote programming model. Method parameters and return values are serialized to RMI-IIOP and returned by value. This is the internal RMI "Call By Value" model.
WebSphere provides "No local copies" performance optimizations for running EJBs and clients (usually servlets) on the same application server JVM. "No Local Copies" uses "Call By Reference" and does not create local proxies for called objects when both the client and the remote object are in the same process. depending on your workload, this can lead to significant overhead savings.
Configure No Local Copies by adding the following two command line parameters: JVM Application Server:
* -Djavax.rmi.CORBA.UtilClass=com.ibm.CORBA.iiop.Util
* -Dcom.ibm.CORBA.iiop.noLocalCopies=true
CAUTION: The No Local Copies configuration option improves performance by changing Call By Value to Call By Reference for clients and EJBs in the same JVM. One side effect of this is that the parameters of a Java method (not primitive) can actually be changed by the bean being called. Consider Figure 16a:
In addition, we will also be using Process Server 6.2 and WESB 6.2 as well in the future. Any ideas? recommendations?
thank
source to share
The only automatic optimization that can really be done for remote EJBs is if they are hosted (accessible from the same JVM). In this case, the ORB would short-circuit some of the work that would otherwise be required if the request were to go through the wire. There will still be some necessary ORB overhead, including object serialization (unless you include noLocalCopies with all the caveats it brings).
Alternatively, if you know the UI controller is hosted, method calls do not depend on copying parameters or return value, and your interface does not rely on differences in differences between local and remote views, then you can create and expose a local subinterface that will much faster than remote access via ORB.
source to share
I also found this link very helpful: http://fixunix.com/websphere/344774-local-interfaces-same-jvm-but-different-ear-issue.html
source to share