Usage scenarios for virtual portals


Overview

  1. Single or multiple business organizations?

    Will all of virtual portals be used within the same organization, or will you provide the portal as a service to other organizations and host them as tenants using virtual portals of installation ?

    Hosting other companies introduces a strong need for isolation and quality of service. The virtual portal approach shares a single JVM and the portal configuration database across all logical portals. The benefit of sharing a JVM is that the concept of virtual portals can be highly scaled, and you can host a large number of logical portals on a single installation. You can share portlet applications across virtual portals. If individual portlet configurations are required, portlet applications can be cloned for the use in a specific virtual portal. For this type of scenario, multiple virtual portals are the solution.

    If a shared JVM is not acceptable for usage scenario, consider using true portals and have multiple full portal installations on the same hardware unit.

  2. Common or separate virtual portal administration?

    Will each virtual portal be administered by its own group of administrators, or will you have a central administration group for the entire portal installation and all virtual portals ?

    You can select a specific group of subadministrators, who can manage the resources and users of a particular virtual portal. The master administrator of the portal installation can set up the privileges of the subadministrators individually for each virtual portal.

    If you do not require a specific subadministrator group for each virtual portal, the portal administrators can share the administrative work for all virtual portals.

  3. Single or separate user populations?

    Will a single user population for the entire installation be sufficient, or does each virtual portal need its separate user population?

    With multiple virtual portals you can have a dedicated user population for each virtual portal and ensure that only members of that population can access that virtual portal. To do this, use the realm concept provided by the Virtual Member Manager (VMM). VMM is available as a built in user registry in WAS. This security concept is known as Federated security.

    If a common user population for all virtual portals is sufficient, you can configure either of the following:

    • A WebSphere standalone LDAP as the security environment
    • Federated security with a single realm. This realm can contain users and groups from one or more repositories.


Usage scenarios for virtual portals

The following sections describe three typical usage scenarios for virtual portals:


Scenario 1: Multi-Portal Enterprise

In this scenario a single enterprise owns and operates multiple different virtual portals on a single portal installation. For example, this scenario can support virtual portals for different parts of the organization such as:

These are some of the typical features of such a virtual portal configuration:


Scenario 2: Workgroup Service Provider

In this scenario one central organization provides virtual portals for a large number of small, decentralized, and independent teams. For example, this can be teamrooms for project management in small work units. This scenario supports virtual portals for different parts of the organization as follows:


Scenario 3: Hosted Enterprises

In this scenario a service provider hosts and operates independent enterprises on the same portal installation. For example, this scenario can support virtual portals for different tenants or service customers, such as:

The requirements for this scenario include the following:

Parent: Multiple virtual portals
Plan for virtual portals

Related reference
Virtual portals reference

Related information
Administer virtual portals


+

Search Tips   |   Advanced Search