In each column, "WebSphere contrarian investors" will answer questions, provide guidance and discuss the underlying topics associated with WebSphere products, often giving proven recommendations that contradict popular perceptions.
A gift for you
It's also a holiday, which means that everyone is busy finishing the year's projects, shopping, and a variety of traditional year-end tasks. All of these activities may mean that you will welcome any time-saving tips, because you may have too many things to deal with, but only too little time to complete. To help you improve your productivity by doing your part, I will spend some time in this month's column to provide some tips for speeding up application deployment in IBM WebSphere Application Server, which also applies to such things as IBM WebSphere Portal, Products such as IBM Process Server and other products based on WebSphere application server.
Application Deployment Flow
Before discussing some options for improving the efficiency of your application deployment, it's a good idea to know exactly what happened during application deployment. The process can be divided as follows:
Connect to the WebSphere application Server from a remote client through a console or wsadmin.
Copy the application EAR from a remote client to the Management node (WebSphere Application Server "Basic" version of "was" Application Server or WebSphere Application Server network The temporary directory on the deployment Deployment Manager.
Open the EAR in read/write mode.
Collects bindings in the Deployer.
Save the temporary EAR.
Upload the temporary EAR to the application server node.
Expand the EAR on the Application server node.
Stop and start the application server.
If you look further at the application deployment stream, you will notice that there are two replication operations. Copying files (especially over the network) can be time-consuming, so the first consideration is to eliminate or minimize the number of replication operations. This can be done in a number of ways:
The EAR is stored on the local file system of the management node, not on the client node's file system. This eliminates the copying of files from the node to which the browser client or the Wsadmin client is connected (item 2nd above).
Distribute the binaries to all application nodes and use the WebSphere application Server earexpander to expand the EAR (which can also be decompressed, and so on), and then use the Wadmin AdminApp with the –nodistributeapp option to Deploy the application, or uncheck the Distribute Application option in the administrative console when the installation is performed. Doing so eliminates another application replication from the admin node to the Application server node (item 6th above), and the EAR expansion operation (item 7th above).
By eliminating the two of ear file copies and the ear file expansion, you may notice a significant reduction in application deployment time, but I only know that some of you may also want to further improve application installation efficiency. Before discussing the options to support concurrent application deployments, I want to introduce some of the other time-saving tips for using wsadmin:
Use RMI instead of SOAP (the default protocol) to establish a wsadmin connection. The SOAP over HTTP protocol does not have a built-in request/response mechanism, so there is a (very short) delay before the response is streamed back to the Wsadmin client from the server. On the other hand, the RMI/IIOP protocol has a request/response mechanism, so the equivalent request to use RMI/IIOP is quicker to respond than the request running on Soap/http.
Unlike running multiple WSADMIN–C commands from a file or from a command line, you should use a single wsadmin–f command and place multiple commands in the destination file. For example, instead of using:
wsadmin -c "$AdminApp install c:\\myApps\\App1.ear {-appname myapp}"
wsadmin -c "$AdminApp install c:\\myApps\\App1.ear {-appname yourapp)"
Instead, create a file named My.jacl (or a Jython file if you like), which contains the following commands:
"$AdminApp install c:\\myApps\\App1.ear {-appname myapp}"
"$AdminApp install c:\\myApps\\App1.ear {-appname yourapp)"
and use a single command to invoke the file:
Wsadmin–f My.jacl
In each column, "WebSphere contrarian investors" will answer questions, provide guidance and discuss the underlying topics associated with WebSphere products, often giving proven recommendations that contradict popular perceptions.
A gift for you
It's also a holiday, which means that everyone is busy finishing the year's projects, shopping, and a variety of traditional year-end tasks. All of these activities may mean that you will welcome any time-saving tips, because you may have too many things to deal with, but only too little time to complete. To help you improve your productivity by doing your part, I will spend some time in this month's column to provide some tips for speeding up application deployment in IBM WebSphere Application Server, which also applies to such things as IBM WebSphere Portal, Products such as IBM Process Server and other products based on WebSphere application server.
Application Deployment Flow
Before discussing some options for improving the efficiency of your application deployment, it's a good idea to know exactly what happened during application deployment. The process can be divided as follows:
Connect to the WebSphere application Server from a remote client through a console or wsadmin.
Copy the application EAR from a remote client to the Management node (WebSphere Application Server "Basic" version of "was" Application Server or WebSphere Application Server network The temporary directory on the deployment Deployment Manager.
Open the EAR in read/write mode.
Collects bindings in the Deployer.
Save the temporary EAR.
Upload the temporary EAR to the application server node.
Expand the EAR on the Application server node.
Stop and start the application server.
If you look further at the application deployment stream, you will notice that there are two replication operations. Copying files (especially over the network) can be time-consuming, so the first consideration is to eliminate or minimize the number of replication operations. This can be done in a number of ways: