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!
7 comments:
@Stephen - interesting thoughts. Surely one thing to consider is the benefit that the WAS Plugin brings to the party in terms of providing load balancing between IHS and WAS.
Therefore, my view is that WebSEAL can load balance into IHS, and IHS can load balance into WAS, with (perhaps) a "real" load balancer handling the LB into WebSEAL ?
The WAS Plugin does bring load balancing. But let us not forget that WebSEAL is a fairly adept balancer in its own right. Having WebSEAL load balance App Servers is very straightforward - staying sticky or performing round-robin "spraying" isn't an issue either.
But, for short running sessions using non mission-critical applications, the IHS seems to provide very little added value above and beyond what the WebSEAL can do.
Remember, the apps I'm talking about are Tivoli Identity Manager, a bit of self-registration, a password reset tool, etc. These are apps that people will use for a minute or two then be done.
If we were talking about Portal, Connections or Quickr... I'd say get that IHS bad boy in place!
Having said all that, I think my ranting last night was ignited by a frustration with architectural best-practice out of context and fuelled by Malbec - LOL!
@Steven - fair enough. I guess it's a case of "Choose the right tool for the job" and "Let the requirements drive the problem drive the solution".
Final plug for IHS or, in fact, for ANY web server. Web Servers are far cheaper ways to funnel workload into more costly Application Server and Database layers.
@Stephen
For the IdM projects I've worked on I've always advocated that IHS be deployed in between WebSEAL and WAS, principally because I came to understand that this is the only manner that IBM supports. This may turn out to be an IdM myth, however I have personally found some more clear cut reasons for using IHS.
When WebSEAL is talking to WAS directly you are exercising an in-built HTTP server that comes with WAS. This mini web server does not implement the full HTTP standard and therefore can throw up some funnies from time to time.
I have found issues with cookies in the past, and I'm sure that it wouldn't be able to handle services such as content caching and compression when fully exercised.
Thanks, Steve.
I think you are right about the myth - and I got that confirmed last week from IBM. The IHS is not a requirement.
I'm also guessing that your other findings (HTTP standards and caching) don't affect me because of the simplicity of the applications and the fact that they are so short running and images are cached upstream anyway.
Ultimately, what I want to get to is a point whereby IHS isn't deployed just because we've always done that. I'd rather the reasons for doing so were relevant and I suspect that the relevancy will be dictated by the complexity and behaviour of the hosted applications.
Thanks for your input guys.
Hi Stephen,
Thanks for the analysis.. I am in a similar situation and trying to understand pros and cons of using IHS inbetween WEBSEAL and WAS.
But I did not understand why you recommended IHS for long-running applications like e-commerce applications and NOT for short-sessioned applications.. Can you please throw some more light on that aspect?? .. Thanks
Post a Comment