Portal, Express Beta Version 6.1 Operating systems: i5/OS, Linux,Windows

Shared database domains

You can choose to transfer a single domain or multiple domains. To maximize availability, data may be distributed across multiple databases and shared between multiple lines of production.

You can transfer data from any supported database type to any supported database type. Data cannot be transferred to an Apache^® Derby database, or from a IBM DB2 Universal Database™ for z/OS^® database.

Domains are the database or schema objects that can be transferred in parts, such as Release, Community, Customization, Feedback, LikeMinds, and IBM Java Content Repository (JCR). Separating your data allows you to share domains across multiple portals. You can also spread the different domains across different database types. For example, you can choose to leave LikeMinds data on your default database and move all other data to another database.

Configuration data

This data defines the portal server setup, such as database connection, object factories, and deployment descriptors. This type of data typically is constant during the time a server node is running. Configuration data is typically kept in property files and is either protected by file system security or application server administration rights.

Release data

This data includes all portal content definitions, rules, and rights that are designed externally then brought into the portal by a staging process, such as Page Hierarchy, available Portlets and Themes, Templates, Credential Slots, Personalization Rules, and Policies. These resources are typically not modified during production and need administrative rights to do so. Administrators typically create release data on an integration server and stage it to the production system. Release data are protected by access control and contain only data, not code. In an environment that consists of multiple lines of production, one copy of the release data exists per cluster.

Customization data

This data is associated with a particular user only and cannot be shared across users or user groups. Typical examples are PortletData or Implicitly Derived Pages. Because this data is scoped to a single user only, access control protection is simplified.

In an environment that consists of multiple lines of production, customization data is kept in a database that is shared across the lines of production. Therefore the data is automatically in synchronization across the lines of production.

Community data

This data includes all resources that are typically modified during production, such as shared documents or application resources. Typically users and groups are allowed to modify or delete shared resources. Community Resources are protected by access control. Because documents are a preferred class of shared resources supported with its own storage mechanism, this type of resource has two subcategories:

JCR data

This data includes all the documents using this storage mechanism.

Application data

This data includes all the other shared application data, which are not documents.

In an environment that consists of multiple lines of production, community data is kept in a database that is shared across the lines of production. Therefore the data is automatically in synchronization across the lines of production.

Separation of the portal data lets you store each category in its own set of database tables or the file system. The set of databases tables for one of these resources are called database domains. These database domains can now be moved into different databases, which can even be shared with other portal installations.

The separation of the domains can be used to support production environments, where the production nodes are split into separate clusters. They can run independently, but share the same JCR, Community, and Customization database domains. Each of these clusters is called a line of production.

For maintenance and staging purposes you can take a single line of production out of service while another line is still serving requests with the old data. After the first production line is updated and back in service again, the second line is updated using the same approach. Updates of data in the shared domain are critical because they influence the other production line.

The capacity of the entire environment should be greater than the intended use so that individual servers can be taken out of production without affecting application availability. To ensure that all of the system resources are available for the portal, production systems should be dedicated to the portal and should not run any other server software that is not related to the portal.

Consult the WebSphere Portal Express Performance Tuning Guide when scaling a system for optimum performance.