Vivek Agarwal’s Portal/Java Blog

An IBM Gold Consultant’s weblog about IBM, Lotus, WebSphere, J2EE, IT Processes, and other IT technologies

WebSphere Portal v6 Global Deployment – 1

Posted by Vivek Agarwal on April 3, 2007

We are again working on a project to set up a client with a multi-master WebSphere Portal deployment scenario, but this time with v6.0.0.x. This is a scenario where the two sites need to be identical in functionality while being independently available even if connectivity between the two sites is down for some reason. An additional requirement is that the two sites stay in sync automatically without portal users needing to know what site they are hitting. We achieve this sync using a combination of database, LDAP, and file system replication. Implementing this complex deployment is a challenging experience as you may have gathered from my previous posts. Trying to repeat success with a multi-master deployment (or global deployment as IBM sometimes calls it or portal mirror as we call it) with WP6 has proved to be an interesting experience so far and I hope to share some of my experiences with you.

This post highlights a couple of key changes in WP6 in terms of database storage that have significant implications for this kind of global deployment –

  • The config split (aka database domains) is a new concept in v6. Essentially, WP data has been split into separate database schemas based on its usage pattern. There is a release schema which stores Portal-wide configuration such as administrator defined pages, portlets, access control, et cetera. Then there is a customization schema which stores user specific customizations such as private portal pages or portlet configuration data. Next you have a community schema that is supposed to contain data that is not Portal-wide nor is it user-specific. The key benefits of the config split are supposed to be around the fact that there are weak references across database domains, thereby enabling community/customization domains to be offline without taking down the complete portal. From a global deployment perspective, this is supposed to simplify life. However one key issue from our perspective was that IBM recommends that the release schema not be replicated as they expect you to never perform administrative actions on production! All administrative actions are expected to be done on a staging environment and then migrated to production using xmlaccess. While this is ideal, I do not believe it to be totally practical. Certainly not for this client for whom we are implementing a WP6 Portal Mirror.
  • The Portal Document Manager (PDM) and Web Content Management (WCM) data has been combined to be saved in a single database schema – the JCR schema. In WPv5.1, the PDM data was stored in a separate schema from the WCM data. As a result, we could use database replication for the PDM data to keep the 2 sites in sync from a PDM perspective while using WCM syndication to keep the 2 sites in sync from a WCM perspective. Using database replication for WCM was not recommended by IBM in v5.1, and WCM syndication worked fine for us once we installed a bunch of syndication related fixes. And PDM database replication worked for us in v5.1 once we jumped through some major hoops – determining what tables need to be replicated and which ones should not, determining primary keys for tables without primary keys, handling trigger firing, and replicating dynamically generated views. However, with the WCM/PDM data residing in a single schema in v6, we were very concerned about whether we could simply replicate the JCR schema and achieve WCM/PDM data synchronization. Or if we would need to configure WCM syndication as well, and if we did that, what would be the interaction between JCR database replication and WCM syndication.

I have more to follow on this relatively obscure topic in future posts!


4 Responses to “WebSphere Portal v6 Global Deployment – 1”

  1. Venkat said

    Thanks for the post.

  2. Anshul Saxena said


    Right now we are doing some POCs to test how the WCM can fit into our project. A brief insight is:
    Earlier we used to use Teamsite as our content management system, and the xml definition of the portal page was stored in the TS, from where the portal pages were deployed to the Live envirionments. Now we have thought of doing away with the TS, and to use WCM .I would like to know how the portal pages will get stored in the WCM?, i guess the WCM library is used only to store the static contents i.e. to say my jsp’s, images, pdf .And once these portal pages are saved in the WCM how can we deploy these to our live environments. Does syndication works for portal pages too ?

    Please if possible reply to my above mentioned queries.

    thanks in advance

  3. Vivek Agarwal said

    Anshul, portal pages are NOT WCM artifacts and hence are not stored in WCM. They are WebSphere Portal artifacts and stored in either release or community or customization schemas of WebSphere Portal. WCM syndication does NOT replicate portal pages – you would need to do that using Release Builder or xmlaccess.

  4. Anshul Saxena said

    Hey Vivek

    Thanks for replying the queries.

Sorry, the comment form is closed at this time.

%d bloggers like this: