My experience with WebSphere Application Server started when IBM acquired Rational Software some 11(?) years ago. WebSphere Studio Application Developer fell under the Rational umbrella and I was one that tried to tackle its capabilities. And for the longest time dealing with WebSphere Application Server meant no more than “right-mouse-click -> Run on Server.”
I will admit that I am not a WAS admin. It is a career unto itself and those that are good at it are worth keeping. But over the years Rational continued to challenge me in the WebSphere arena with the release of Rational Automation Framework for WebSphere (RAFW). RAFW codified 100s of common WebSphere “gestures” that could be rolled together into hard working jobs that did much of the heavy lifting in managing and maintaining WebSphere Application Servers. It also had the ability to auto-discover WebSphere configurations and push those configurations to other servers that even may be running different versions of WAS.
Then along comes UrbanCode Deploy and we now have a deployment engine that could sure use some if not all of the capabilities of RAFW. We are now beginning to see some being rolled into UrbanCode Deploy. This post is the first in a series examining the Middleware Configuration for WebSphere Application Server (MCWAS) plugin for UrbanCode Deploy.
To begin, there are actually two plugins that come into play. The MCWAS plugin has commands that are all about capturing, comparing, and using WebSphere configurations. Some of the RAFW capabilities are captured in the MCWAS plugin (but not all. Stay tuned to future UCD releases for improvements). A pdf file also exists in the plugin zip file that has details about how to accomplish what we are doing in this post. The Application Deployment for WebSphere plugin contains 64 commands (as of version 71) that do the bulk of the work in updating and tweaking WebSphere configuration items. The number is not even close to what RAFW supported, but it is getting there. By the way, you can always get up-to-date plugins from IBM here. Both of these plugins need to be installed into your UCD server.
Next, let’s examine my test environment. First, I have a UCD server and agent running on my laptop. And like I said before, I am not a WAS admin, so I simply have WAS 8.5 running on my laptop with the Plants By WebSphere sample application installed and running. I can follow directions so I got that app up and running pretty quickly. Our use case is that I want to capture the configuration of that WAS instance and re-use it to deploy to another server. We will use the MCWAS capabilities in UCD to do that.
1. First we need to do some setup in UCD. We need to setup our agent so that it can auto-discover WebSphere. If WebSphere is installed in its default location, we don’t have to do anything. If not, then we need to make sure UCD knows how to find WebSphere. We add a wsadmin.path property to the agent with its value the path to the wsadmin.bat (or wsadmin.sh) file. Also, we need a MCWAS component that will be used to hold the configuration. I created a new component and based it on the Middleware Configuration for WebSphere template. This component is the center of the deployment process.
2. Next we create our resources. You are free to create your own resource tree to represent whatever environment you have, but mine is simple.
3. Next we add the agent to the resource. If we wait for a few seconds and refresh, we see that we our agent has auto-discovered WebSphere and we get an additional resource below that agent that represents our WebSphere cell. Magic!!! We didn’t have to do anything to tell UCD, it just went out and found it for us. Cool.
4. The cell resource also has a bunch of role properties defined. We need to fill those in to help UCD auto-discover what is underneath that cell. If we look at the properties of the WebSphereCell resource, we see this list. Actually in my case all I need to fill in is the WebSphere profile path. This tells the UCD which profile I am interested in (there is a way to auto-discover multiple cells but we will keep it simple here). We can leave the rest blank, especially the cell name. We will have auto-discovery get that for us.
5. Back to the resource tree, I can now tell UCD to auto-configure the cell. In the Actions menu of the cell resource, select Auto Configure.
6. A dialog pops up asking us to specify the auto-configure steps. We don’t have any steps configured yet, so click on the “No auto configure steps for resource” link (yes it is a link. UCD needs a bit of user interface improvement here).
7. A new dialog is presented that let’s us pick an auto-configure step. Lo and behold there is currently only 1 choice. Select WebSphere Topology Discovery and click OK.
8. Back to the Auto Configure dialog, we now have 1 step defined. Click Save.
9. If we wait a few seconds (in my case it was about 15. I am sure in more complicated environments it might be a minute or so) and refresh our resources, more magic happens!!! UCD has now interrogated our WAS cell and found the node name and server name below it. You can also go back into the cell properties and see that the cell name property has been filled in.
This structure should represent your true WAS configuration. For those of you out there that are real WAS admins and have some real servers running with real configurations, try this and see if UCD gets it right.
Our next post in this series will now take advantage of what we have auto-discovered and use it in a deployment. Stay tuned.