WebSphere Portal Server

     

WebSphere Portal Server (WPS) provides common services such as application connectivity, integration, administration, and presentation that are required across portal environments. It is installed as another application within WebSphere Application Server, with its own Web and Enterprise Java Bean (EJB) container. Since it is part of the Application Server, it provides the same benefits of management, cloning, and scaling. The main components running in the Portal Server's Web container are portlets and portlet applications.

Installing the WebSphere Portal Server

The WPS Server is installed on the WebSphere Application Server (WAS). However, if you want to install the WPS and you don't have a WAS server, then the installation procedure can still be quite straightforward since you can choose to have WPS, WAS, and IBM HTTP Server (IHS) all installed together, as is indicated in Figure E-1.

Figure E-1. Installing the WebSphere Portal Server.
graphics/ap05fig01.gif

Portlets

A portlet is a small portal application that is displayed in a rectangular area on a Web page. This rectangular area is akin to a miniature browsing area. Portlets are the heart of a portal. They are independent, reusable components that provide access to applications, Web-based content, and other resources. Web pages, services, applications, and syndicated-content feeds can be accessed through portlets.

Portlets are written in Java utilizing a portlet API. They are developed, deployed, managed, and displayed independent of other portlets. Portlets are becoming prevalent in the IT world. Enterprises can create their own portlets or select from a portlet catalog available from IBM and other third-party vendors . Until the portlet API gets adopted as a standard, however, a portlet written for one portal server cannot be used in another vendor's portal server without modifications.

The IBM portlet catalog is available at http://www.ibm.com/websphere/portal/portlet/catalog. There are well over 250 portlets available for download. Most of these are free, but some are written by third-party software vendors and require a usage/license fee. Each portlet is design for a certain version of WebSphere Portal Server ”so keep that in mind when you are downloading.

Portlet Applications

Portlets are actually complete applications. A portlet application can contain one or more portlets and follow the model-view-controller (MVC) design. Portlet applications are packaged as Web Archive (.war) files, per the J2EE specifications.

Like servlets, portlets run inside a Web container that is part of the portal server. As in the case of servlets, the Web container provides a runtime environment in which portlets are instantiated , used, and finally destroyed . Portlets rely on the portal infrastructure to access user profile information, participate in window and action events, communicate with other portlets, access remote content, look up credentials, and to store persistent data. Portlets, however, are administered more dynamically than servlets. For example, portlet applications consisting of several portlets can be installed or removed while the server is running. An existing portlet can even be dynamically updated with a newer version.

The Portlet API

Portlets are assembled into a larger portal page, with multiple instances of the same portlet displaying different data for each user. Portlets rely on the portal infrastructure for their functionality. Since they are very similar to servlets, it makes sense that portlets are a special subclass of HttpServlet, with properties that allow them to easily plug into and run in the portal server. The portlet Application Programming Interface (API) provides standard interfaces for the portlets' functionality. The portlet API defines a common base class and interfaces for portlets in order to cleanly separate a portlet from the portal infrastructure. In most respects, the portlet API is an extension of the servlet API, except that it restricts certain functions to a subset. This makes sense for portlets running in the context of a portal. For example, unlike servlets, portlets may not send errors or redirects as a response. This is only done by the portal itself, which controls the overall response page.

Normally, one or more portlets are invoked in the course of handling a single request, each one contributing its content to the overall page display. Some portlets can be rendered in parallel so that the portal servers assemble all the markup fragments when all the portlets finish or time-out. Portlets that are not considered thread-safe will be rendered sequentially. The markup fragments that portlets produce may contain links, actions, and other content. The portlet API defines URL-rewriting methods that allow portlets to transparently create links without needing to know how URLs are structured in the particular portal.

WebSphere Portal Architecture

The WebSphere Portal is a third-generation portal server with a lot of components, offering one of the most comprehensive portal solutions. This is possible because WebSphere Portal server mirrors the proven architecture of the WebSphere Application Server. With its own portlet API and the standardized J2EE API, WebSphere Portal not only integrates well with existing back-end components but also is easily extendable. Enterprises can use exiting security systems by using Trust Association Interceptors to achieve portal authentication. If enterprises already have content-management systems, WebSphere Portal toolkits are available to interface with them. WebSphere Portal gets installed as a Web application in WAS. Like every other application, it is comprised of Enterprise Applications. The four major Enterprise Applications in WebSphere Portal server are as follows :

  1. WebSphere Member Subsystem (WMS)

  2. WebSphere Portal Server (WPS) Enterprise Application

  3. WebSphere Content Manager (WCM) Publish Webapp

  4. WebSphere Proxy

In addition to these, approximately 26 portlets get installed as Enterprise Applications. When you view the WebSphere Application Server Administrative Console, you will see numerous Enterprise Applications, all running on one or more nodes of the WebSphere Application Server. Keep in mind that companies can start with the WebSphere Portal Extend Edition and then add components in the future to move up to the Enterprise architecture.



IBM WebSphere and Lotus Implementing Collaborative Solutions
IBM(R) WebSphere(R) and Lotus: Implementing Collaborative Solutions
ISBN: 0131443305
EAN: 2147483647
Year: 2003
Pages: 169

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