Simply put, using nothing but a /bin/bash script and wget we scrape the latest version of the relevant artefacts from the Artifactory Maven repository. These artefacts are deployed (published) into the repository by the Hudson continuous integration build.

As they say, a picture tells a thousand words and I’ve included a schematic of the environment we have created below (image links to PDF).

I’ve worked on a successful (JSR168) portal implementation, just last year. I truly don’t see what the concept of ‘portal’ brings to a web application beyond what could be simply programmed into a customised web application. We used Spring MVC Portal running under Websphere Portal and calling back-end services deployed on a BEA Weblogic server using Spring remoting (note: not WSRP which would have probably massively increased complexity). The reason this mix of platforms (Websphere and Weblogic) was used was political, not technical. I believe the whole use of portals in general tends to follow organisation’s political and not technical needs.

Despite all that, overall the custom portlets and the project as a whole was quite successful and the customer satisfied with the result. However I felt the most difficult aspects of the project were the parts of the deployment that were left to the portal container to provide. These are the things that are touted as the ‘advantage’ using a portal container over a simple custom-built web application. Content management features caused the team members delivering these enormous headaches (and late nights) and the same can be said of the authentication and authorisation mechanisms employed. I felt we could have easily delivered these components using known JEE development APIs with all the customisation required by the customer in at least an equal amount of time.

As a contrast, we used Tapestry 5 to develop (actually, completely rewrite from an earlier phase one version in dire need of improvement) an administration component as a straight web application deployed into the Weblogic server. This took a pair of us less than two weeks to write using a functional-test-driven approach and delivered a very nice web app.

The issue of portal containers and standards being a political rather than a technical concern is particularly pertinent to me at the moment because it looks likely in the near future I’ll be working on another portal implementation for another client. I can’t be more specific regarding this but this particular client had already bought the portal server from a vendor and then approached consultants in order to get an actual implementation completed. Of course, no requirements gathering or analysis was done to determine if the portal solution was indeed the right one – the vendor’s sales team effectively provided the assurances of product suitability. Because the money is already spent and reputations already staked on the portal platform there’s no possible way a better solution can be suggested by any technical expert at this stage.

In my view, that’s the “relevance” of portal servers in the Java world. Vendor sales teams love to sell them.

Update

Jakub Holý makes an excellent observation about validity of the concept of a portal server:

It’s a pity that portals and portlets aren’t easier to use and haven’t made it into the mainstream, the abilities of content aggregation, personalization, uniform security etc. are promising and as we can see in the rise of personal mashups like iGoogle, the fundamental ideas behind portals are still valid and extremely attractive. I hope that some mashup technology will soon provide a viable, light-weight alternative to portals.

That’s an important point: iGoogle is the most widely used example of a “portal” architecture. The modern trend towards the “mashup” (especially in social software) also shows the idea to aggregate different web applications under a common view, with security and other features is a valid one: it’s just the bloated, slow specification process, and predatory vendor sales departments that are stopping real innovation in this space in the Java area. Hopefully some light weight technology will soon emerge from among something like Spring, Tapestry, and GWT to produce a “portal” server that delivers actual value, and ease of development, deployment and usage, in a corporate context.