WebSphere Virtual Portal as equivalent to Vignette Portal Site:
Vignette has site defintion for both Vignette content management and Vignette Portal, it is easy to manage and deliver content with site as an logic unit, it provides capability of seperating admin permission between site and sharing content/portlet instance across site, and violates site coordinator/admin's view, make content management / portal system easy to authorized and managed. DPM originally designed for Vignette portal, it support the site idea and easyly deliver content on different logic units at same portal.
But when we come DPM for WebSphere Portal, a slight different change is there is no site in WebSphere portal, when you can find site management in WPS 6.1, you could find all it talk about is syncronizing content from one WPS to another, it is equal Vignette term "Stage".
WPS does has same structure for Vignette portal site, a slight difference with terms and functions. WPS has virtural portal as a logic unit across same physical portal, each virtual portal can be accessed at different URLs such as
http://localhost:10040/wps/portal/vp1 , http://localhost:10040/wps/portal/vp2,..etc and you can configure different pages, configured to display different portlets on each of these virtual portal.
Process sequence of creating virtual portal:
With the information that the administrator enters in Manage Virtual portal when creating the new virtual portal, the portlet triggers a sequence of processes to actually establish the new virtual portal. These processes include the following:
1. Creating a new root content node for the virtual portal.
2. Creating the new URL mapping to point to the new root content node.
3. Assigning the selected theme to the new root content node.
4. Granting the specified administrator group the action set for the Administrator role on the new root content node, and thereby, on the new virtual portal.
5. Calling the XML configuration interface script to create the initial content tree. This includes virtual portal–specific instances of the following portal resources: Favorites,Administration, Home, Manage Portlets, and Page Customizer with the corresponding concrete portlets. To change the content globally and before creating a virtual portal, modify the XML script that specifies the initial content for virtual portals.
6. Assigning default roles and access rights to subadministrators and users on the created resources.
Resource are not copied to Virtual Portal by default:
1. Not all resources can be scoped to individual virtual portals. For example, all themes and skins are available to all virtual portals without restrictions. Credential vault, portlet services, and portal services are also common for an entire portal installation. They cannot be scoped to an individual virtual portal.
2. The settings which are defined in the portal property files apply for the entire portal installation. You cannot specify separate settings for individual virtual portals.
3. If you want to make use of the single signon feature that is provided by WebSphere Application Server, you have to use the same common domain suffix for all virtual portals.
4. Portal search, personalization, and templates, are not aware of virtual portals.
5. There are no virtual portal specific enhancements to the published portal commands and application programming interfaces.
6. A URL mapping that is defined for a resource in a particular virtual portal must use the same URL context as the friendly URL context for that virtual portal itself. Example: In a virtual portal that uses the friendly URL mapping wps/portal/vp_1, all URL mappings for portal resources must start with wps/portal/vp_1, for example wps/portal/vp_1/url_1 and wps/portal/vp_1/url_2. Within this virtual portal a URL mapping such as wps/portal/url_1 is not valid, as the portion vp_1 of the URL Context is missing.
7. All virtual portals on a portal installation share a common logging and tracing.
8. You cannot create custom url in one virtual portal that address portal resource in another virtual portal. The reason is that both object IDs and unique names relate to resources of the local virtual portal. For details about how to create URLs refer to Creating custom links to portlets and pages.
IBM New Site Wizard
The New Site Wizard feature provides the ability to quickly and easily create virtual portals based on selecting a site template, an initial look and feel style, and optional features. The wizard is designed to be used by administrators and business users alike, to aid in building new sites to support a multi-tenancy portal. The wizard encapsulates many administrative tasks, such as user enrollment, virtual portal creation, and content library creation. Once the portal is created, site owners can easily customize the layout and look and feel.
Portal developers can enhance the New Site Wizard by creating custom site templates and then adding them to the wizard. After the custom site templates are added to the wizard, users can select them when they use the wizard to create their sites
By default, the New Site Wizard creates new sites as virtual portals. Administrators or developers can extend the New Site Wizard to create any type of portal site, such as a composite application instance or a unique set of common pages, by providing their own custom site creation task implementation and set of site templates that use it.
The IBM New Site Wizard portlet is available for download from IBM Solution Catalog.