Webshere Portal Server 4.1 virtualization

MoReese

We were told by Interwoven that TeamTurbo virtualization would not work with the latest version of WebSphere portal server 4.1. Since we can not use TeamTurbo, can anyone direct me to any information/documents on how we might go about virtualizing dynamic content? I can't seem to find anything!

Jay

Migrateduser

Turbo/TeamTurbo never supported virtualization of WebSphere portal applications. In order to provide virtualization in an automatic fashion aka TeamTurbo, a lot of things need to be in place on the portal server which are not yet available on WP. From our investigation here's a few things we found that may help you:

The reason why it is hard to virtualize portlets on IBM is because the only way to deploy portlets programmatically is using their XML config utility, for which documentation is not available.
The steps in virtualizing a portlet looks like the following:
* Configure the development WPS instance - in particular - turn off request ID counting (You can't do any URL addressing within WPS if request counting is done)
* Packaging the portlet up in a WAR file with some special extensions (does not conform to the Sun WAR spec)
* Deploying the portlet to the portal server with admin rights
* Assigning view/edit/manage privileges to the user for the portlet.
* Have the user decide which portal page the portlet should be deployed to. (This involves somehow getting to a Page ID, although we couldn't find any way to do this). The user should have view/edit/manage privileges on the page
* Getting the page for the page ID
* Adding the portlet to the portal page. (Option: scrape out a portlet, specified by the user, and place this portlet in the location of that portlet). Edit the layout of the page to conform to what the developer wants the site to look like
* Transparently log the user into the portal server and redirect to the portal page that contains the now-virtualized portlet.
* Make sure that all cookies that need to be set are sent back to Websphere with each page view request (or the user will get logged out)
* Note that every time the java code underlying the portlet changes, the whole portlet needs to be redeployed. If only a JSP/HTML or static content piece changes, you can just copy that content over to the expanded war directory in websphere, but you need to determin where the WAR was expanded. You can probably do this given the NAME of the portal application and the ID that was assigned to it when it was deployed.

This is all conceptual. We could not get stable APIs to do this transparently and hence had to abandon our research into portlet virtualization on WPS.

Darren K - Interwoven