Introduction
- Virtual Portals are logical portals that share the same WebSphere Portal Server hardware and software installation.
- All the Virtual Portals, including the default portal, run on and share the same JVM (Java Virtual Machine).
- Each Virtual Portals will have its own unique URI.
Sample Portal Architecture using an Virtual Portal
Advantages of VP feature
- Using the VP feature we can not only save costs by using the shared resources for multiple portals, but we also can enable a new portal application much faster as you don’t have to spend time installing and configuring new hardware and software for the new portal.
Portal resources that are scoped for virtual portals
- WebSphere Portal has the following portal resources scoped internally for virtual portals:
- Portal pages
- Portlet instances
- Portal Search Engine search services and search collections. This includes the search content sources.
- Scoping of these resources is managed by internal portal mechanisms.
- Scoped resources are only available for the virtual portal for which they are defined. They are well isolated from other virtual portals.
- Scoped resources cannot be shared with other virtual portals. They are not visible or accessible outside of the virtual portal for which they have been created. This behavior cannot be changed by any portal access control settings.
The rules applied on Virtual Portal
- Within each virtual portal you or a subadministrator can use Portal Access Control to grant individual users of that virtual portal specific access rights to the scoped portal resources. This works just like under a single portal installation.
- An administrator can give access rights to users who are members of the user population of a virtual portal only on the scoped resources of that same virtual portal. This implies that, vice versa, you can give access rights on the resources of a virtual portal only to those users who are members of the user population of that virtual portal.
- Users can only use these access rights when they access the specific virtual portal under which they have the access rights on the scoped resources. The same users cannot access the resources when logging in to a different virtual portal.
Portal resources that you can separate for virtual portals by using Portal Access Control
- There are some portal resources that are not scoped internally for a particular virtual portal. These resources are shared among all virtual portals of the entire installation. However, as a master administrator you can yourself separate such portal resources for the virtual portals. To do this, use Portal Access Control and the access rights portlets to set up the appropriate access rights for users on the resources of each virtual portal as required.
- You can separate the following portal resources by using Portal Access Control to give users of an individual virtual portal access right to the resources:
- Portlets
- Portlet applications
- Web modules
- URL mapping contexts
- Users and groups.
- You can separate these resources for individual virtual portals by using Portal Access Control. When you do this, apply special care. It can be of benefit to document the relationships between the users and the virtual portals.
Portal resources that cannot be separated for virtual portals
- There are some types of portal resources that are not scoped to a particular virtual portal, and you cannot separate them yourself by using Portal Access Control. The following list shows portal resources that you cannot separate for virtual portals:
- Themes and skins. If you do not want subadministrators to be able to manage themes and skins, restrict their access rights on them.
- Vault segments and vault slots. To avoid security problems, use private credentials only. They can be used by only one specific user.
- Supported clients and markups. The settings for these are configured in the corresponding portlets; therefore they apply to the entire portal installation.
- Composite applications and templates. There is one common application and template catalog per installation. Users see the applications and templates to which they have access, regardless of virtual portal assignments. For more information about applications and templates refer to Composite applications.
- Policies. Policy resources are not scoped to virtual portals. Users see the policy resources to which they have access, regardless of the virtual portal assignments.
- Examples:
- Themes and skins can be accessed by all subadministrators who have the access right to apply themes and skins to the pages that they can administer, regardless of which virtual portal the subadministrators are responsible for.
- If a subadministrator imports a new template into one virtual portal, this template will appear in the application template library of all virtual portals.
Content of a virtual portal
- When we create the virtual portal by using the Virtual Portal Manager portlet, the portlet invokes an XML configuration interface script that creates the initial content of the new virtual portal.
- Content (wps.content.root). This includes the following pages and portlets:
- Home (ibm.portal.Home). This includes the Welcome page.
- Welcome (ibm.portal.WebSphere Portal.Welcome). This includes the following portlet:
- Page Customizer (ibm.portal.Page Customizer)
- Page Properties (ibm.portal.Page Properties)
- Welcome (wps.p.Welcome)
- Organize Favorites (wps.p.Favorites)
- Login (wps.Login). This contains the following portlet:
- Login (wps.p.login)
- Search (wps.p.Search Center)
- Profile Management (wps.p.Selfcare)
- Documents (wps.Documents). This contains the following portlet:
- Document Manager (wps.p.Documents) and Document Picker (wps.p.DocPicker)
- Administration (ibm.portal.Administration). This includes the following portlets:
- Manage Pages (wps.p.Manage Pages)
- Users and Groups (wps.p.Manage Users and Groups)
- Resource Permissions (wps.p.Resource View)
- User and Group Permissions (wps.p.User Group Permissions)
- URL Mapping (wps.p.Url Mapping)
- Custom Unique names (wps.p.Unique Names)
- Manage Search (wps.p.Manage Search Admin)
- Manage Document Libraries (wps.p.MDL)
- Enable tracing (wps.p.Enable Tracing)
- Portlet Palette (wps.p.Content Palette)
- Personalization Picker (ibm.portal.Personalization.Picker.portlet)
- Applications (wps.p.App Catalog)
- Edit Layout (wps.p.Content Layout)
- Members (wps.p.App Membership)
- Roles (wps.p.App Roles)
- Properties (wps.p.App Properties)
- Parameters (wps.p.Template Parameters)
- Application Layout (wps.p.Application Layout)
- Application Template Library (wps.p.Template Library)
- Portlet Wiring Tool (wps.p.Wiring)
- Appearance portlet (wps.p.Appearance)
- Page Locks (wps.p.Permissions)
- Page Properties (wps.p.Properties)
- Information Portlet (wps.p.Information)
- Anonymous Information (wps.p.Information.Anonymous). Note: This portlet is hidden.
- Policy Editor (wps.p.PolicyEditor)
- Resource Policies (wps.p.PolicyExplorer)
By default the administration portlet Virtual Portal Manager is installed as part of the initial portal installation only. It is not part of the default content of virtual portals that you create. You can only use it in the initial portal installation.
Enjoy :-)
No comments:
Post a Comment