< Day Day Up > |
WebSphere Portal takes the advantage of the WebSphere Application Server, making use of its J2EE services. WebSphere Portal itself installs as an Enterprise application in WebSphere Application Server. 1.3.1 Portal conceptsThe following are some definitions and descriptions of Portal concepts. PortletA portlet is an application that displays page content. Portlet applicationPortlet applications are collections of related portlets and resources that are packaged together. All portlets packaged together share the same context which contains all resources such as images, properties files and classes. Important also is the fact that portlets within a portlet application can exchange messages. PageA portal page displays content. A page can contain one or more portlets. For example, a World Market page might contain two portlets that displays stock tickers for popular stock exchanges and a third portlet that displays the current exchange rates for world currencies. To view a page in the portal, you select its page. Note WebSphere Portal V4.x uses the concept of Place for grouping pages. In WebSphere Portal V5, the concept of Place does not exist. Places are treated as top-level pages in WebSphere Portal V5. LayoutThe page layout defines the number of content areas within the page and the portlets displayed within each content area. In many cases, the portal administrator defines the page layout. The administrator can permit specified users or user groups to change the page layout to reflect individual preferences. If you have authority to change a page, use the configure icon (wrench icon) to alter the page layout. RolesEach portal page is subdivided into one or more content areas. Each content area can contain one or more portlets. The portal administrator or a user who has authority to manage a page can control whether others who have authority to edit the page can move, edit or delete the content areas and the portlets on the page. Portal V5 permission is role based. A role is a set of permissions. Roles can be assigned (or mapped) to individual principals granting those principals the corresponding permissions. If you have authority to make changes to a portal page, use the Resource Permissions page in Access under Administration to set the permissions for the page. By default, there are seven roles and they are as follows :
Comparison of V4.x permission vs. V5.x rolesPermissions that a principal (a user or group ) had in WebSphere Portal V4.x are mapped to the appropriate roles in WebSphere Portal V5.0. The following table illustrates this role mapping. Table 1-1. Role mapping
ThemesThemes represent the overall look and feel of the portal, including colors, images and fonts. There are several default themes provided with the standard installation of WebSphere Portal. Each page in the portal may have a different theme associated with it, thereby creating the appearance of virtual portals. Use the Themes and Skins under Portal User Interface to manage themes. SkinsThe term skin refers to the visual appearance of the area surrounding an individual portlet. Each portlet can have its own skin. The skins that are available for use with a portlet are defined by the portal theme that is associated with the place. The portal administrator or the designer determines the theme for places and the available skins for the theme. The administrator can permit specified users to change the skins to reflect individual preferences. If you have authority to make changes to a portal page, use the Themes and Skins under Portal User Interface to manage themes. 1.3.2 PortletsThe base building blocks of a Portal are the portlets. Portlets are complete applications following the Model-View-Controller design pattern. Portlets are developed, deployed, managed and displayed independent of all other portlets. Portlets may have multiple states and View modes along with event and messaging capabilities. Based on the J2EE container model, portlets run inside the Portlet Container of WebSphere Portal analogous to the way servlets run inside the Servlet Container of WebSphere Application Server. Portlets are a special subclass of HTTPServlet that includes properties and functionality that allows them to run inside the Portlet Container. Though portlets actually run as servlets under the WebSphere Application Server, they cannot send redirects or errors to the browser directly, forward requests or write arbitrary markup to the output stream. All communication back to the end user from a portlet is done via the aggregation modules. To understand the portlet model used by WebSphere Portal, let us take a step back and examine the Flyweight pattern. This pattern is used by WebSphere Portal as the design pattern for the portlet model. The Flyweight patternThe Flyweight pattern was originally presented by the GofF or Gang of Four (Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides) in E.Gamma, et al., Elements of Reusable Object-Oriented Software , Addison Wesley, 1995. Flyweight is a structural pattern used to support a large number of small objects efficiently . Several instances of an object may share some properties. Flyweight factors these common properties into a single object, thus saving considerable space and time otherwise consumed by the creation and maintenance of duplicate instances. Key to the Flyweight Design Pattern is the fact that the objects share some information. It is then possible to greatly reduce the overhead problem and make the presence of so many objects possible. The flyweight object is a shared object that can be used in multiple contexts at the same time; the object functions independently in each context. The state shared by the objects falls into two categories, intrinsic and extrinsic.
This separation into extrinsic and intrinsic information allows great numbers of similar objects to exist, differing only in the context in which they exist. The different components involved in the Flyweight Pattern are the Flyweight, the ConcreteFlyweight, the UnsharedConcreteFlyweight, the FlyweightFactory and the Client.
The parameterization of portlets is based on the flyweight pattern, the Portlet Container being the Flyweight Factory. PortletsPortlets are invoked by the portlet container. Every portlet has to inherit from the abstract org.apache.jetspeed.portlet.Portlet class, either by deriving directly from it, or by using one of the abstract portlet implementations . A portlet is a small Java program that runs within a portlet container. Portlets receive and respond to requests from the portlet container. There is only ever one portlet object instance per portlet configuration in the Web deployment descriptor. There may be many PortletSettings objects parameterizing the same portlet object according to the Flyweight pattern, provided on a per-request basis. When the portal administrator deploys a new portlet or copies an existing one, PortletSettings are created. A Portlet parameterized by its PortletSettings is referred to as a concrete portlet . The settings of concrete portlets may change at runtime since administrators modify the portlet settings by using the configuration mode of the portlet. The PortletSettings initially contain the elements defined in the deployment descriptor and are changeable by the portlet administrator. Figure 1-7. Portlet parameterization objects
Additionally, users can have personal views of concrete portlets. Therefore, the transient PortletSession and persistent concrete PortletData carries vital information for the portlet to create a personalized user experience. When a portlet is added to a page, PortletData is created to parameterize the portlet. The PortletData can only be accessed by the portlet itself, for example when changing a list of desired stocks to watch in a stock portlet. A concrete portlet in conjunction with portlet data creates a Concrete Portlet Instance . PortletData scope depends on the scope of the page. If the administrator places the portlet on a page, the portlet data contains data stored for the group of users associated with the page. If a user puts the portlet on the page, the portlet data contains data for that user. For more information on the portlet data object, refer to Chapter 2, "Portlet API" on page 53. Finally, when the user initially accesses a portlet, a PortletSession is created. The portlet session stores transient data associated with an individual use of the portlet. The concrete portlet instance parameterized by the PortletSession is referred to as the User Portlet Instance . Figure 1-8. The portlet parameterization
1.3.3 Portlet modesPortlet modes are a facet of the Portal display model. Modes allow the portlet to display a different "face" depending on its usage. There are four modes:
1.3.4 Portlet statesPortlet states determine how the portlet is displayed in the portal. The state of the portlet is stored in the PortletWindow.State object and can be queried for optimizing processing based on state. The three states of a portlet are:
1.3.5 Portlets and the model-view-controller (MVC) design patternBecause portlets must be capable of supporting multiple views for multiple devices, the key design pattern used for portlets is the model-view-controller (MVC) design pattern. This design pattern contains three entities:
For portlet development, the MVC pattern has the following characteristics:
In the MVC structure, there is a distinct separation of data from presentation along with a controller component for managing the interaction between the data (model) and the presentation or view. The controller knows the environment in which the application is invoked, gathers information from the data object to be displayed, and then applies the appropriate view to render the data using the markup language appropriate for the current device. A comprehensive discussion of the MVC pattern and how it is applied to portlets is provided in Chapter 2, "Portlet API" on page 53. See 2.3, "MVC architecture" on page 55 for details. 1.3.6 WebSphere Portal runtime: the portlet containerWebSphere Portal is a J2EE application based on the servlet technology. In fact, portlets inherit from HTTP Servlet in the Java hierarchy, providing the servlet functionality. The WebSphere Portal portlet container is not, however, a standalone container as is the servlet container. The portlet container is a thin layer implemented on top of the servlet container designed to reuse the functionality provided by the servlet container. The Portlet API provides the standard interfaces for accessing the services provided by the portlet container. The Portlet API is explored in detail in Chapter 2, "Portlet API" on page 53. As previously mentioned, the Portlet Container is implemented on top of the servlet container and thus the Portal API is similar to the servlet API. 1.3.7 Portlet life cycleMuch like the Servlet Container, the Portlet Container manages the portlet life cycle along with providing services to the portlets running in the container. The portlet container loads and instantiates the portlet class. This can happen during startup of the portal server or later, but no later then when the first request to the portlet has to be serviced. Also, if a portlet is taken out of service temporarily, for example while administrating it, the portlet container may finish the life cycle before taking the portlet out of service. When the administration is done, the portlet will be newly initialized . During the portlet life cycle, the portlet container invokes the following methods on the Portlet class (subclass of a the Portlet Adapter class) on behalf of user requests as seen in Figure 1-9. Figure 1-9. Portlet life cycle
The portlet container calls the following methods of the abstract portlet during the portlet's life cycle:
1.3.8 Portlet events and messagingMany portals today display static content in independent windows . The ability for portlets to interact within a portal is key to giving a portal a "live" feeling. In "live" portals, quite often the user is presented with one portlet on a page that presents a choice of data, a list of stocks for example, and choosing from the list causes another portlet to be updated with the details of the choice. This type of list-detail processing via multiple portlets is done with portlet events and messaging. This same type of process could be accomplished using a single portlet but consider the example of a stock list, stock details and news associated with the stock. Giving the user this function via three portlets allows the user to customize the portal experience by choosing which information about the chosen stock is displayed by simply adding the associated portlet to the page. In portlet messaging, one portlet typically detects a condition and formats a message as a result of that condition, then sends the message to the receiver. The receiving portlet receives the message from the event handler and processes the message as you would expect. Portlets can both send and receive messages. Portlets communicate using portlet actions and portlet messages. For example, an account portlet creates a portlet action and encodes it into the URL that is rendered for displaying transactions. When the link is clicked, the action listener is called, which then sends a portlet message to send the necessary data to the transaction detail portlet. There are some basic rules to portlet messaging:
Portlet events contain information about an event to which a portlet might need to respond. For example, when a user clicks a link or button, this generates an action event. To receive notification of the event, the portlet must have the appropriate event listener implemented within the portlet class. Action events : generated when an HTTP request is received by the portlet container that is associated with an action, such as when the user clicks a link. Message events : generated when another portlet within the portlet application sends a message. Window events : generated when the user changes the state of the portlet window. The portlet container delivers all events to the respective event listeners (and therefore the portlets) before generating any content to be returned to the portal page. Should a listener, while processing the event, find that another event needs to be generated, that event will be queued by the portlet container and delivered at a time point determined by the portlet container. It is only guaranteed that it will be delivered and that this will happen before the content generation phase. There is no guarantee for event ordering. Once the content generation phase has started, no further events will be delivered. For example, messages cannot be sent from within the service, doView or other content generation methods. Attempts to send a message during the content generation phase will result in an org.apache.jetspeed. portlet.AccessDeniedException. The event listener is implemented directly in the portlet class. The listener can access the PortletRequest. It is important to understand the underlying event handling and message processing to ensure delivery of all send messages. The portal event handling and message processing sees four steps executed in the following order.
Important It is important to note that events are not processed in the last step of the process, page rendering. If a message is sent by a portlet during rendering, the message will not be delivered or processed . This is a result of the fact that the event queue is help in the portlet request and at the time of rendering, the portlet request is no longer available. Therefore, if portlet interaction is desired, portlet messages must be sent during the first three steps of the event and aggregation process. 1.3.9 Page aggregationPortals allow users to choose sets of portlets they would like to work with and provides a framework for displaying those portlets in a consistent fashion. A defined set of applications, which should be presented in a common environment are referred to as a page . Page aggregation is the process that collects information about the user's choices, the device being used and the selected portlets, then takes that information and combines it to create a display that is appropriate for the device. The aggregation process involves three basic steps:
Once the active page is determined, the layout of this page is used to aggregate the content of the defined applications, arrange the output and integrate everything into a complete page. Basic Portal Page Layout can be seen in Figure 1-10 on page 34. Figure 1-10. Portal page layout
Rendering of page components is done using JSPs, images, style sheets, and other resources. These resources are located in the file system in a path -naming convention that the portal server uses to locate the correct resources for the client. WebSphere Portal provides dynamic aggregation of pages from page descriptors held in the portal database. Collecting user informationDuring the collection of user information, the following information is collected:
Selecting the active applicationsDuring this phase of aggregation, the portal determines the active applications or portlets to be displayed. When the portal receives a request, it determines the active place and the active page for the current user. Aggregation then continues with the rendering of the page. Aggregating the outputOnce the active page is determined, the portal uses the layout of the page to aggregate the content of the defined applications, to place the output and build the complete page. A page contains components such as row or column containers that contain other components or portlets. Figure 1-10 shows the layout of a portal page. A portal page is made up of the following elements.
Themes and skinsWindow and component layouts can be controlled by themes and skins. Themes refer to the window templates. Themes represent the look and feel of the portal, including background colors, images and fonts, and is also used to render to portal banner. Skins refer to the component templates. It defines the border, margins, and title bar of the portlets on a page. Skins use the theme name to select the graphics that match the theme colors. TemplatesAggregation uses the concept of templates to perform window, screen and component layout. When a corresponding part needs to be rendered, a template loader will load the requested template. If the requested template cannot be found, the default template will be used. A template consists of the template class that controls the rendering, the localization and the launch of the template JSP. The template JSP performs the actual rendering. There are three types of templates:
Page aggregation processingThe rendering process is a domino process starting with the root container. The root container triggers the rendering of all the child components in the page hierarchy as seen in Figure 1-11 on page 37. Figure 1-11. Page aggregation
Rendering the screen triggers the aggregation of a page and its portlets. The pageRender tag in the screen starts the rendering process. If no portlet is maximized, then the pageRender tag calls the RootContainer. The Root Container holds all the containers and controls for this page. The pageRender tag tells the Root Container to invoke the rendering of all its children. Since the Root Container is used only as a starting point for the aggregation, it does not render itself and therefore is not visible on the screen. Each child of the Root Container invokes its template which is responsible for rendering all the content of its child. If the child contains further child components the componentLoop and componentRender tags execute the rendering of all these components one at a time. Each component invokes its own template which in turn invokes more components until the leaf of each branch is reached. Thus, control moves between component classes and their respective JSPs. Each component writes its content to the servlet output stream. When a control is reached, it invokes the rendering of the portlet, which adds its output to the output stream via its rendering. When the entire tree has been traversed, the output stream is closed and the output is sent back to the requesting client. |
< Day Day Up > |