Who’s On Phirst

In the first part of this two part post, I discussed how scripts are terrible at eliminating errors. In fact, scripts simply replace typos with system errors. A rather poor trade-off, I think.

The second problem with scripts is the burden they place on employees to maintain them and the decrease in productivity they can cause. This maintenance burden and productivity sinkhole are the two areas scripts were supposed to fix!

Frankly, I hold the tools architecture responsible. Scripts conflate the Data with the Mechanism because of the enforced procedural nature of the tools (think wsadmin). Please note that I don't mean to pick on WebSphere, but I just have a *ton* of experience with that application server. I could have just easily singled out WebLogic, OAS, JBoss or Glassfish. The architecture problem is common to them all.

To see an example of conflation, navigate to your WAS 6.1 directory and look at samples\bin\PlantsByWebSphere\install.jacl. You will see the following:

  createJ2CResourceAdapter $nodeName $serverName

That's a good start as both resources are provided at the command line when executing the script. However, the script immediately falls apart on the next directive:

  #--------------------------------------------------------------------

  # Setup security cell

  #--------------------------------------------------------------------

  set secAuthAlias "$cellName/samples"

  set secDescript  "JAAS Alias for WebSphere Samples"

  set secUserID    "samples"

  set secPassword  "$samplepwName"

  createJAASAuthenticationAlias $cellName $secAuthAlias $secDescript $secUserID $secPassword

Don't see it the problem? I don't blame you. The problem is a hardcoded secUserId. This will fail if there is another JAASAuthData that uses the same secUserId as "samples". Now, that's a simple mistake; but it's one that will require a very specific use case to find it. So, we have actually created a maintenance headache for ourselves. This script may save me time in my Dev or QA environments. But, once it gets to Production where they use entirely different usernames for the database, I will have an error I simply cannot afford to have.

But, finding the specific JAASAuthData configuration problem is just the first headache. In my Production environment, imagine that this script fails on the duplicate secUserId value. Well, that's easy to fix, right. Let's just add another argument to pass in when the script is run.

So, I'm only into the second call of my script, and already I'm required to make the script more complicated. Furthermore, since my script is not wrapped in a transaction, I'll have to manually delete the J2CResourceAdapter to completely roll back. Or, at least, I *think* that's all I need to roll back my script's changes. After all, the best thing that can happen when I run a wsadmin script is nothing. Because if I see anything on STDOUT, that's normally a bad thing.

Ideally, I would have my Data described in a simple format that defines the System Resource (or MBean) I am trying to create and its associated attributes. Then, my script would read that data structure and create the MBeans necessary. Finally, at the end, it would generate a report that details what was changed in my environment. And, of course, if any failure's occur, all changes up to the failure are automatically rolled back.

Of course, I would love to see you purchase Phurnace Deliver which can do all of that and then some. However, you can create this yourself. The tools to do so are readily available and most Application Servers provide some sort of API to manage those configuration changes. Just remember to separate the Data from the Mechanism, and you should be much better off.