Table of Contents
Advertisement
In addition, WebSphere Portal Server leverages the foundation capabilities provided by
WebSphere Application Server or WebSphere Process Server (certain restrictions apply).
5.1.2 Portal foundation and framework
Although it is usual to refer to WebSphere Portal Server as a single J2EE Enterprise
Application, the architecture actually consists of a number of J2EE Enterprise Applications
(EAs). It is, however, through the WebSphere Portal application server context, that these
EAs cooperate to provide the total Portal experience and application platform.
At the heart of the WebSphere Portal application server is the Portal Servlet, which registers
the secure and anonymous context paths (for example, /wps/myportal and /wps/portal, by
default). This Servlet receives the browser requests and dispatches specific JSPs to build the
Portal page being requested. The JSPs are the same for every page (usually). The layout
differs by the configuration for the "page" being requested by the client, as identified by the
URI. The actual layout depends on who you are and what access you have to the resources
represented by the page's configuration.
The JSPs do nothing but issue includes for the Portlet Web modules, which are then invoked
as servlets, whose service method is translated to the correct render method based on the
current mode of the portlet (doView() versus doEdit(), for example).
The following J2EE Enterprise Applications (EAs) constitute the most significant components
of WebSphere Portal Server:
Primary Portal Web application
The WPS.ear is the primary Portal Web application. It contains the majority of the JSPs
responsible for providing the overall Portal look and feel.
WebSphere Member Manager
WebSphere Member Manager (WMM) is the component of WebSphere Portal Server that
manages data for users and groups. Users and groups are referred to as "members" in
WMM. WMM keeps track of the overall attribute set of the users and groups within the
system and the values of those attributes for individual users and groups. WMM does not
assign particular roles to its members. Members can take on different roles depending on
the activities in which they participate.
Programmatically, WMM presents a Java object view of users and groups to Portal Server,
including to all installed Portlets. Details of the actual underlying data storage layouts are
abstracted and hidden from Portal Server by WMM. WebSphere Portal Server V6.0.x still
uses the Portal User Management Architecture (PUMA) code on top of WMM. This
implementation detail should not be important as you begin implementing a custom user
store under WMM, but will be important if you need to make use of user profile information
in custom-written Portlets or Portal code.
As the Portal and Portlets make PUMA calls to do searches and get and set attributes on
the User object, PUMA passes these function requests to the correct methods on the
WMM. WMM then passes the function requests to the correct MemberRepository
implementation. Every user managed by WMM requires a unique identifier. A unique
identifier allows a member profile to be easily retrieved.
Personalization Engine
The Personalization component of WebSphere Portal Server can personalize Portlet
content for a specific user. A business user would simply create a rule such as "if the user
is a manager, then display management content; if the user is an engineer, then display
engineer content."
Chapter 5. WebSphere Portal runtime and services
139
Advertisement
Table of Contents
Troubleshooting
