1.3 WebSphere Portal

 < 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 concepts

The following are some definitions and descriptions of Portal concepts.

Portlet

A portlet is an application that displays page content.

Portlet application

Portlet 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.

Page

A 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.


Layout

The 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.

Roles

Each 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 :

  • Administrators are allowed to have unrestricted access on all portal resources

  • Security Administrators are allowed to grant access on a resource

  • Delegators are allowed to grant access to other principals

  • Managers are allowed to create, edit, and delete shared resources

  • Editors are allowed to create and edit shared resources

  • Privileged Users are allowed to create private resources

  • Users are allowed to view portal resources

Comparison of V4.x permission vs. V5.x roles

Permissions 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

V4.x Permissions

V5.0 Roles

View

User

Edit

Privileged User

Manage

Manager

Delegate

Security Administrator

View + Edit

Privileged User

View + Manage

Manager

View + Delegate

Security Administrator + User

Edit + Manage

Manager

Edit + Delegate

Security Administrator + Privileged User (Migration option: Security Administrator + Editor)

Manage + Delegate

Administrator

View + Edit + Manage

Manager

View + Edit + Delegate

Security Administrator + Privileged User (Migration option: Security Administrator + Editor)

View + Manage + Delegate

Administrator

View + Edit + Manage + Delegate

Administrator

Create

No longer necessary. In WebSphere Portal V5.0, principals with the Administrator, Manager, Editor, or Privileged User roles on a resource are automatically allowed to create new resources underneath that resource in the resource hierarchy.

Themes

Themes 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.

Skins

The 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 Portlets

The 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 pattern

The 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.

Intrinsic state

State stored in the object and independent of object's context. Thus the information is sharable across the objects. The more stateless and intrinsic information shared between objects in the flyweight, the better. This allows for greater savings in memory, since less context information needs to be passed around.

Extrinsic state

State that depends on a single request varies with the objects context and therefore cannot be shared. This information must be stateless and determined by context, having no stored values, but values that can be calculated on the spot. Client Objects are responsible for passing the extrinsic state to the object when the object needs it.

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 Flyweight: the shared object with intrinsic state. The flyweight declares an interface through which flyweights can receive and act on intrinsic data.

  • ConcreteFlyweight: implements the flyweight interface and adds storage for the intrinsic state.

  • UnsharedConcreteFlyweight: the flyweight interface enables sharing but does not enforce it. Not all flyweights are shared. It is common for UnsharedConcreteFlyweight objects to have ConcreteFlyweight objects as children at some level in the hierarchy.

  • FlyweightFactory: serves to dispense particular flyweights that are requested. When a Flyweight with certain properties is requested, it checks to see if one already exists, and if so, returns that flyweight. If the requested flyweight does not exist, it creates the requisite flyweight, stores and returns it.

  • Client: when creating an object, a client must assign a flyweight to it, so it asks the FlyweightFactory for a particular flyweight, receives that flyweight, and creates a reference to it in the object it is creating.

The parameterization of portlets is based on the flyweight pattern, the Portlet Container being the Flyweight Factory.

Portlets

Portlets 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

graphics/01fig07.gif

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

graphics/01fig08.gif

1.3.3 Portlet modes

Portlet 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:

View

Initial face of the portlet when created. The portlet normally functions with this face.

Help

If the portlet supports the help mode, a help page will be displayed for the user.

Edit

This mode allows the user to configure the portlet for their personal use, for example, specifying a city for a localized weather forecast.

Configure

If provided, this mode displays a face that allows the portal administrator to configure the portlet for a group of users or a single user.

1.3.4 Portlet states

Portlet 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:

Normal

The portlet is displayed in its initial state as defined when it was installed.

Maximized

The portlet view is maximized and takes over the entire body of the portal replacing all the other portal views.

Minimized

Only the portlet title bar is visible inside the portlet page.

1.3.5 Portlets and the model-view-controller (MVC) design pattern

Because 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:

  • The model , the data source to be retrieved for the portlet

    Model data for a portlet is typically retrieved from an external data source and loaded into Java display beans, or arrives formatted in an XML document.

  • The view or views, the output mechanism used to display the data of the portlet

    Display views are typically implemented as either JSPs, more typically used when the data model is implemented in Java beans, or XSLT style sheets when the incoming data is formatted in an XML document.

  • The controller , which joins the selected view to the data and conducts the operation of the portlet.

    The controller selects the view for display based on the target device or browser, and then passes the data model to the view. The view extracts the specific display data, formats the data for the browser and renders its output to the browser as part of the portal aggregation of portlet outputs.

For portlet development, the MVC pattern has the following characteristics:

  • The portlet is only responsible for calling the right controller, depending on the markup supported by the client.

  • Connectors are responsible for accessing content sources. Typically, there is one connector per content source type, for example, one connector for POP3 access and one for file-based cache.

  • Models represent the content as retrieved through the connector. A model is independent of the presentation.

  • Controllers can be used to provide markup-specific content (HTML, cHTML, or WML).

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 container

WebSphere 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 cycle

Much 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

graphics/01fig09.gif

  • init()

  • initConcrete()

  • login()

  • service()

    - doView()

    - doEdit()

    - doHelp()

    - doConfigure()

  • logout()

  • destroyConcrete()

  • destroy()

The portlet container calls the following methods of the abstract portlet during the portlet's life cycle:

  • init()

    The portlet is constructed after portal initialization and initialized with the init() method. The portal always instantiates only a single instance of the portlet, and this instance is shared among all users, exactly the same way a servlet is shared among all users of an application server.

  • initConcrete()

    After constructing the portlet and before the portlet is accessed for the first time, the portlet is initialized with the PortletSettings. This is known as the concrete portlet.

  • service()

    The portal calls the service() method when the portlet is required to render its content. During the life cycle of the portlet, the service() method is typically called many times. For each portlet on the page, the service() method is not called in a guaranteed order and may even be called in a different order for each request.

  • destroyConcrete()

    The concrete portlet is taken out of service with the destroyConcrete() method. This can happen when an administrator deletes a concrete portlet during runtime on the portal server.

  • destroy()

    When the portal is terminating, portlets are taken out of service, then destroyed with the destroy() method. Finally, the portlet is garbage collected and finalized.

1.3.8 Portlet events and messaging

Many 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:

  • Portlets in different applications can only communicate through default portlet message objects. Default portlet message objects can only carry strings.

  • In order for portlets to communicate through custom messages, they must be part of the same portlet application. WebSphere Portal uses a unique class loader for each portlet application to provide security between applications. The message is typically a custom Java object unique to the application. Since messaging portlets must share this message object, they must share the same class loader and therefore they must be part of the same portlet application.

  • For performance reasons, portlets that communicate through messaging must reside on the same page. Since only one page is displayed at a time, there is little need to send messages to portlets not currently displayed.

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.

  1. Processing all action events

    The user makes a request of the portal, the portal receives the request and decodes the action URI sent by the client and propagates an action event to the appropriate portlet. The receiving portlet's action listener is called to process an action event. An appropriate time to send messages to other portlets is during the processing of the action event.

  2. Processing all message events

    If a message is sent to a portlet, the portlet's message listener is called to process the message. Since portlets can send multiple messages and send messages as a result of receiving a message, this process continues until there are no more messaging events pending. Cyclical messaging is prevented by the WebSphere Portal architecture.

  3. Processing all window events

    Sizing operations such as maximize, minimize and restore, along with the portlet's ability to request a specific size , causes multiple window events to be sent to all portlets affected by the sizing activity. This processing of window events continues until there are no more window events pending.

  4. Portlet rendering process

    Upon completing the event processing in the order specified above, the portal aggregator begins calling each container on the page being displayed, causing its contents to be rendered. The rendering process is explored in detail in 1.3.9, "Page aggregation" on page 32. When aggregation is complete, the page is returned to the user.

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 aggregation

Portals 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:

  • Collecting user information

  • Selecting the active applications

  • Aggregating the output

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

graphics/01fig10.gif

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 information

During the collection of user information, the following information is collected:

User

The user is authenticated at login and the user identification is available throughout the session.

Client

The user's device is determined by information contained in the request header. Once determined, this information is also stored in the session.

Markup

The markup is associated with the device category. There are currently three markups defined, HTML, cHTML and WML. New markup scan be added via the Markup Manager Portlet.

Markup version

The version for the supported markup. For example, ie5 for the Internet Explorer family of browsers, ns for the Netscape family of browsers.

Language

The portal determines the language to be displayed via the following algorithm.

 

If the user is logged in, the portal user interface is displayed in the preferred language of the user.

 

If no preferred language is set, the portal UI is displayed in the language set by the client browser if available.

 

If no browser language is available, the portal UI is displayed in the default language set for the portal.

 

Portlets not supporting any of the above scenarios display their UI in the portlet's default language.

Page

The access control list determines which pages and labels a user has access to.

Theme

The name of the active theme is taken from the currently active page.

Screen

Depending on the interactions of the user with the portal, different screens are presented. The screen holds the output of the portlets on a page.

Selecting the active applications

During 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 output

Once 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.

Portal window

The content inside the displayed window. It is made up of the banner and the portal page.

Banner

The top area of the window that holds the company information, the greeting, a page selection box, tabs to select the current page in the page group being displayed and some additional controls for interacting with the portal such as logging in, logging out and help.

Screen

Hold the output of the portlets on the currently selected page. The layout is determined by its row and column containers.

Node

Node is a level of hierarchy in the portal. Nodes include pages, labels, or URLs, and are used to navigate the portal structure. The portal has a tree structure that is used to organize the portal into branch nodes, which belong to other nodes that are higher in the tree. The single highest node in the portal is called the content root. Nodes are represented and accessed from the portal navigation menu.

Page

Page is a type of node that provides portal content, similar to a page on any Web site. However, portal pages display content in the form of portlets, which are arranged on the page by row and column containers. Each page displays content that has been customized for the portal user.

Label

Label is a type of node that has a name and is used to hold other nodes.

URL

URL is a type of node that can open locations within the portal or external Web sites.

Container

A container is an area on a page that contains content. A container can be structured as a row, column, or cell in a table. That is, when you are arranging content on the page, the content can be placed in a container that spans the width of the page (row) or the height of a page (column).

Row

A container inside a page that allows portlets to be arranged in a horizontal format.

Column

A container inside a page that allows portlets to be arranged in a vertical format.

Control

The frame around the portlet is constructed by the frame. It builds the bar above the portlet output including buttons to control the state and view of the portlet.

Portlet

A portlet is a type of application that can be accessed through a small box or window in a portal page. Portlets provide access to specific services or information, for example, a calendar or news feed.

Themes and skins

Window 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.

Templates

Aggregation 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:

  • Window templates

    The Window template is responsible for the layout of the parts of the banner area and the placement of the screen. You can change, for example, the navigation tab location via the window template.

  • Screen templates

    The Screen template is responsible for the layout and the content of the screen, the portion of the portal page containing the output of the portlets.

  • Component templates

    Component templates are responsible for rendering the component itself and for starting the rendering of its children components. The children of container components (row and column) may be other containers or controls. The child of a control will always be a single portlet.

Page aggregation processing

The 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

graphics/01fig11.gif

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 > 


IBM WebSphere Portal V5 A Guide for Portlet Application Development
IBM Websphere Portal V5: A Guide for Portlet Application Development
ISBN: 0738498513
EAN: 2147483647
Year: 2004
Pages: 148

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net