Thursday, February 03, 2011

WebSphere And IHS - What Gives

As regular readers will be aware, the majority of my professional work is in the field of Identity and Access Management. Indeed, it is with IBM Tivoli products that I play with day-in and day-out.

IBM Tivoli Identity Manager (ITIM) is a J2EE application which runs within a WebSphere Application Server instance or cluster and I often-times develop mini Java apps as either a helper for ITIM or as an extended authentication service for Tivoli Access Manager for e-business. The curious thing about ALL of these Java applications, however, is that from a user session perspective, they are short-running (typically) and don't really require any state to be maintained during that short interaction with the user.

In the WebSphere world, it seems to be good practice to deploy the IBM HTTP Server (which is a hybrid of the Apache HTTP Server). There are a number of reasons as to why this is a good idea including:
  • it adds a layer in front of your application server
  • it can perform load balancing
  • it can provide caching services
  • it can provide port translation
  • it can help maintain state within a clustered environment

All of this is fine and well, but remember... I work in a field where I typically have a WebSEAL reverse-proxy in place which can provide almost all of the above. Where it might fall down, is when session state becomes crucial.

That said, in a world where the applications purring away inside that WebSphere cluster will only ever see short running sessions (ie. log in, change password or log in, approve a request) then state isn't an issue.

In effect, surely it is quite acceptable to build your infrastructure without the added overhead of the IHS (where WebSEAL is already in place).

I've had this conversation a number of times down the years and the conclusion I've always come to is that the IHS in my configuration is pretty superfluous. However, it is "good practice" and sometimes it is easier to deploy it than have the political bun-fight with the powers that be who point at these architectural best-practices and tell me I can't deviate from the infrastructure design.

So this begs the question. Who writes these best practices/guidelines and can they please word them in such a way that allows those out in the field a certain amount of flexibility when the occasion demands?

NOTE: Should the application hosted within the application server be a long-running enterprise-scale application that is mission critical... please, please, please deploy the IHS. In other words... make sure you deploy components for the right reasons and not just out of fear because of some design pattern dreamt up in some lab by someone who has never deployed this stuff in a production environment!
Post a Comment