I don’t envy the IBM labs’ job of deciding which versions of their products to test together and support. There are lots of combinations, lots of odd permutations possible and you almost certainly can’t please everyone. This isn’t usually a problem when you’re just dealing with a single product – WebSphere Portal, say – but when you start having several products in the mix, things get complicated pretty quickly.
The most complicated case of this I’ve seen recently came from one of our customers who already uses WebSphere Portal, Lotus Connections and Tivoli Directory Server. They wanted to bring portal up to version 6.1 and start using Tivoli Access Manager, preferably 6.1. Oh, and everything should be at the latest possible level and there should be a single database server. Ouch.
So how to work it out? Can we really get to a totally supported configuration or are we going to have live with a compromise somewhere along the line?
One of the common gripes that I hear from portal customers is that it’s very expensive to scale portal. This can be true especially if the portlets suffer from ‘bloat’ and carry out more processing than they should. I know of one organisation here in the UK that was seriously considering abandoning WebSphere Portal to return to straightforward servlet development because of this.
So it was with great interest that I attended a presentation today by Andreas Brunnert from the Boebligen lab about the portlet container that’s now part of WAS 6.1 and, soon, WAS 7. This offers an interesting solution to the above problem. The portlet container in WAS could be used to distribute load from (expensive) portal servers to (inexpensive) application servers.
Another interesting consequence of having the portlet container in WAS is that stand-alone web applications can now be developed against the portlet API. That means that developers who don’t want portal can have their cake and eat it – all of the richness of Portlets’ state and context plus not having to worry about where the application will be deployed – portal, WSRP or stand-alone.
I’m generally pretty sceptical about any product pitch that begins “all you have to do is…”. Usually, it skates over a whole bunch of set-up that the demonstrator has done beforehand. So, knowing that it’s hard to integrate existing applications into a portal, I’ve been left pretty cold by the hype around Portal Web Application Integrator.
So I’ve been umm-ing and aah-ing for some time about whether to add my tuppence-worth to the blogosphere. Everything you could ever want to read is already out there, surely. It probably is, so I’m not fool enough to think there’s anyone out there reading this. But just maybe…
My day-job involves building software systems out of IBM products and many many days of consultancy. I’m an architect responsible for selecting products and putting the overall solution together. As we go along we learn lessons and find out what’s behind the hype. Sometimes, very rarely, products even live up to the marketing.
So this blog is about my experiences doing all that, in the hope that someone out there finds it handy.