1.4 Highlights in WebSphere Portal V5

 < Day Day Up > 

In this section, we present general information about Portal V5.

1.4.1 Portal install

While WebSphere 4.x has an install procedure that tried to address all needs and adapt virtually all portal settings to the specific customer environment which resulted in a complex install procedure that required systems administrators to know and specify many things at install time, WebSphere Portal 5.0 has a redesigned install that follows a more modular approach, consisting of the following steps:

  1. Installation-This step lays down the required files and only asks for some basic configuration settings. By default, the portal installation installs WebSphere Application Server 5.0.1 EE and the Cloudscape database, plus the portal software on top of those. Alternatively, the install can be done on a preexisting installation of WebSphere Application Server 5.0.1 EE optionally using a preexisting database (for example Cloudscape, DB2, Oracle, SQL Server, Informix). Installation of the portal is quick and simple, using common defaults.

  2. Configuration-This step allows tailoring a portal installation fit the specific customer environment by running configuration scripts to change the database being used by the portal, switch from using the WMM database as a user registry to using one of the supported LDAP directories, enabling use of a proxy for access of remote content through the portal, etc.

1.4.2 General infrastructure

Support for WebSphere Application Server V5 Enterprise

WebSphere Portal 5.0 runs on WebSphere Application Server 5.01 Enterprise to take advantage of better performance and scalability.

Property Broker incorporating C2A and Cooperative Portlet Data sharing

The Property Broker is intended to support brokering of properties between independently developed portlets. It is intended to support the collaborative requirements of both the Click-to-Action and Dynamic Workplaces features. The main runtime pieces are as follows:

  • A property broker service (an instance of PortletService), which provides public and private APIs for using or implementing the property brokering function.

  • A property match broker, which maintains a repository of property matching rules and carries out matches as required.

  • Portlets which use the public APIs on the property broker service to enable the sharing of properties and inform it of changes in shared properties. Portlets may use the existing action mechanism for receiving notification of changes to shared properties, or may implement a new property provider interface, through which such notifications are delivered.

  • A property broker portlet filter (an instance of PortletFilter), which filters all calls to portlets.

  • The portlet container, which invokes callbacks on the portlets to indicate the start and end of the event processing phase, and which provides an API to the portlet service to invoke selected methods on portlets.

Enabling for Communities

WebSphere Portal 5.0 through its WebSphere Member Manager Component provides support for Communities as special groups with additional meta-information .

1.4.3 Event broker

WebSphere Portal 5.0 has a portal event broker to which portal components can fire typed events which the broker dispatched to the listeners previously registered for those events. The portal event broker is used to deliver portal internal events across portal components as well as for producing events for event listeners for BEI and site analyzer integration.

Figure 1-12. Event broker

graphics/01fig12.gif

1.4.4 Member subsystem

WebSphere Portal Server 5.0 uses WebSphere Member Manager instead of WMS.

WebSphere Member Manager can access user information in different types of repositories using WMM Repository Adapters which implement the WMM Member Repository Interface. WMM provides repository adapters for LDAP user profile repositories and the WMM Database user profile repository (supporting the same set of databases as WebSphere Portal). It is also possible to connect custom repositories by implementing a custom profile repository adapter, for example, in service projects.

1.4.5 Authentication

J2EE Security

The authentication function in WebSphere Portal Server 5.x uses the J2EE Security calls to authenticate users instead of the SSO Authenticator calls that had been used in WebSphere Portal 4.x.

Deprecating old SSO functionality

In WebSphere Portal Server 5.x, the old JAAS-based SSO functionality allowing portlets to take user ID and password from the JAAS Subject for the special case that no authentication proxy is used is no longer supported. Instead, portlets have to use the Credential Vault that also works in the general case.

1.4.6 Authorization

Enhancing access control for roles and inheritance

WebSphere Portal uses a role-based approach to manage user authorization for accessing portal resources such as portlets and pages. Access control administration can be performed using corresponding portlets within the running portal or via the XMLAccess scripting interface.

Portal access control (PAC) is the single access control decision point within the portal. It controls access to all sensitive portal resources, like for example pages and portlets. PAC is used by various components including the customizer, the different aggregation modules, and the SOAP RPI router that allows for remote invocation of portlets. All these components will allow actions on particular portal resources only if these actions are allowed by PAC.

PAC directly supports access control configuration of hierarchical resource topologies through the concept of permission inheritance. This concept reduces the administration overhead for an administrator when controlling access to a large number of portal resources. Inherited permissions are automatically assembled into roles that can be assigned to individual users and user groups, granting them access to whole sets of logically related portal resources. The "user-to-role-assignments" can be managed within the portal or within external authorization systems (for example Tivoli Access Manager).

To allow for pluggable implementations , the authorization component defines a Service Provider Interface (SPI). WebSphere Portal Server 5.x has a built-in authorization component implementation that plugs into the SPI so that it can be replaced by other implementations easily.

The summarized access control facilities provided by PAC include:

  • Instance-level access control for the complete set of portal resources

  • Granting/revoking of permissions based on roles

  • Support for predefined action sets for convenient creation of roles based on the intrinsic portal resource topology

  • Flexible blocking of permission inheritance on a per resource/per action set basis

  • Notion of Private Resources to reduce the number of defined roles within the portal for high volume personalized resources

  • Delegated administration concept supporting an unlimited number of delegation levels

  • Leveraging a sophisticated caching infrastructure for high performance access control decisions

  • SPI plug-point for external access control components like, for example, Tivoli Access Manager

  • First alignment towards upcoming JSR 115 based authorization facilities that will be provided by WebSphere in the future

1.4.7 URL generation, processing and mappings

WebSphere Portal 5.0 has mechanisms for generating URLs to be embedded in portal or portlet markup and for analyzing the URLs in incoming requests to determine what actions to process and what to display.

Canonical Portal URLs

WebSphere Portal 5.0 supports a canonical URL format that consists of the server name plus one or more GUIDs or Unique Names of URL addressable resources within the portal such as places, pages, and portlet instances.

User-friendly Portal URLs

In addition to canonical URLs, WebSphere Portal 5 can support arbitrary user-friendly URLs defined by administrators explicitly for selected portal resources. To define user-friendly URLs, the portal administrator defines URL contexts organized as trees which have context names as their nodes. The user-friendly URLs result from traversals from the root to a leaf of such a tree.

URL mappings

To translate user-friendly URLs (which in general have an arbitrary structure and do not contain GUIDS or unique names that can be understood by the portal's URL processing) into canonical portal URLs (which contain the correct GUIDs or unique names for portal resources), URL mappings are required.

WebSphere Portal allows administrators to define URL mappings for the parts of URL spaces for which they have the appropriate access rights in two ways: They select a node in the URL spaces and may map it to a URL addressable portal resources they start by selecting a URL addressable portal resource and then selecting the node(s) in the user-friendly URL space which should map to the resource.

Administrators may only define URL mappings for those friendly URL contexts for which they have been granted the appropriate access rights.

1.4.8 Search

WebSphere Portal 5.0 introduces major improvements in its search functionality, adding categorization, summarization and support of more than 225 document formats through document filters.

Document Categories and Summaries

WebSphere Portal Server 5.0 provides function for automatic categorization of documents as well as automatic generation of document summaries.

Eureka! categorizer

The Eureka! categorizer is a high-accuracy system for categorizing text documents, including those from highly heterogeneous sources such as the Web. Currently, it is used by ibm.com to categorize IBM's Web pages with 80% accuracy (relative to humans categorizing to the same taxonomy) and 80% coverage. The system consists of two major components, a taxonomy creation system and a categorizer. It is the use of the categorization system which produces the high accuracy of Eureka!

The Eureka! categorizer and associated data can be viewed as a black box that accepts text in either HTML, XML, or flat text, and outputs a list of one or more categories into which the text has been categorized, and a score for each. Optionally, it may also detect the presence of one or more phrases or terms that are then mapped to a specific category. The categorizer is available in multiple languages; however, each language requires a separate invocation of the categorizer.

The categorizer requires that the calling application fetch the text to be categorized and handle the resulting output of categories from the categorizer. In a multilingual application, it may also be necessary for the calling application to determine the language of the text in order to dispatch it to the appropriate categorizer. The categorizer will operate as a server within the UIM Architecture framework.

The Eureka! data consists of a language-specific dictionary of words (stemmed words in English); a language-specific hierarchy of categories; and a set of definitions for each category. The category definitions are produced by the Eureka! "back-end" system, which will remain at HAW. However, the Eureka! system currently consists only of categories in the following areas: computers (excluding computer science), financial markets, and telecommunications. Additional effort is included in the scope of work to expand this set of category definitions to other areas

Summarizer

The Summarizer is configurable to run in three client-selectable modes:

  • For certain types of news articles, it will return the initial 255 characters of the text document.

  • For documents which have certain narrative quality, it will return N (client-settable) most salient sentences. Additionally, the computation of salience can be made sensitive to a query or to a user profile, presented as a parameter to Summarizer, thus enabling query-biased and profile- biased summaries.

  • For applications where it makes sense to define/assume a "domain" and where a domain dictionary/glossary is provided, it will 'highlight' occurrences of domain-specific terms in documents. This mode may also produce "keyword summaries" which list important domain terms in the documents.

Document filter technology

WebSphere Portal 5.x integrates the Outside-In document filters from Stellent. This technology allows the portal to search over 225 document types.

Web crawler

The system is a collection of crawlers, folders, index and filters and build in categorizers/summarizers, which allow the user to build a fixed taxonomy documents (either Web pages or manually uploaded) via a rule-based categorizer or the Eureka! categorizer.

1.4.9 Content management

Portal Document Manager

Portal Document Manager (PDM) is a portlet application which provides a simple, real-time document viewing and contribution solution for Portal users. It is built according to the WebSphere Portal 5.0 portlet style and architecture guidelines and uses the new WPCP Portal Content Management (PCM) API to provide the necessary folder, document and user management functions needed for the PDM solution. PDM will be shipped in all versions of WebSphere Portal V5.0 (including Express). One of PDM's major usability objectives is to provide a simple interface, one that can be used without training, often referred to as a "walk up and use" interface. PDM's target audience includes business professionals, and content contributors who demand a nontechnical interface.

This release of PDM provides the following functions:

  • Document Management : Navigate a hierarchy of documents organized into user-defined folders; Authorized users can add, view, modify and delete folders and documents.

  • Access Control : Portal users/user groups used for access control; assign access control rights for folders and documents using Portal access control interface.

  • Search : PDM documents and folders are searchable using Portal search engine.

  • Workflow Process : Using built-in workflow, assign approvers for workflow process during PDM configuration. Approvers must approve new and changed documents before they are made public. Work items show up in the Tasks folder.

  • Subscription : Allows subscription to documents and folders. Subscription folder shows subscribed documents.

  • Integration with On-Demand Client (ODC) components : DC editors (RichTextEditor, Presentation Editor and Spreadsheet Editor) can be used to edit PDM documents. ODC Mailbox portlet can save attachments as PDM documents or attach PDM documents to e-mail. ODC document conversion services are used when needed to change PDM document formats.

  • Versioning : The user can create new versions of documents. The user can view and retrieve document versions. PDM provides built-in versioning support but can be configured to support CVS, IBM CM, and ClearCase.

1.4.10 Content publishing

WebSphere Portal content publishing (WPCP) provides a Web content management solution that gives nontechnical users greater control over content published to portals and other Web sites. Users benefit from the combined power of having one place to manage content for their Portal environment or other Web sites and an easy-to-use Web interface. This interface puts content management back into the hands of nontechnical business users and provides them with tools such as personalization rules, templates, workflow, and versioning, that make the content creation process simple, yet controlled. WPCP decreases Web maintenance and administration costs, increases sales and profits by deploying timely and personalized content, and improves efficiency by getting all content produced in an enterprise to the Web.

1.4.11 Transcoding

Transcoding technology was incorporated into WebSphere Portal 4.1. As transcoding technology serves different market through various IBM offerings, including WebSphere Portal, number of markup language transformation were not enabled in WebSphere Portal.

Starting with WebSphere Portal V5, plug-ins for WML and cHTML markup transformation are enabled. WebSphere Transcoding Publisher will be bundled as part of the portal server core install package. This will alleviate the need to have a separate installation for WebSphere Transcoding Publisher and Portal.

The aim is to simplify the installation process and reducing the chance of an error during installation of portal and later during migration. In an effort to do this, now transcoding is installed inside the portal directory; this includes moving transcoding classes to the shared app directory. Configuration steps are also simplified by pre-configuring portal property files with transcoding information.

1.4.12 Struts Portlet Framework

Struts is a very popular framework for Web applications using a mode-view-controller design pattern. The Struts framework can be used to effectively design Web applications and support development teams of different sizes and organization.

For WebSphere Portal 4.2, the Struts Portlet Framework was updated to include the Struts 1.1 Beta 3 release and support for Tiles and File upload was added.

The Struts Portlet Framework in the WebSphere Portal 4.2 implementation is closely tied to Portal Core API, so changes there will effect the Struts Portlet framework and require changes to function in the WebSphere Portal version 5 product. There are also WebSphere Application Server V5 dependencies that need to be addressed. The new functions that end users will see again are supported for newer releases of Struts.

1.4.13 User interface

WebSphere Portal V5 implemented a new containment model.The functions of the containment model can be grouped into two parts: information supply and administration.

The next two sections deal with these aspects, a further section explains the structure of the containment model.

Information supply

The containment model provides the information needed to perform tasks such as content aggregation or building navigation to browse the aggregated content. The information supplied can be dependent on a specific user; it would be a user-specific view on the containment model.

Administration

The information in the containment model must be changeable , of course. This can only be done via the Command API. The commands can manipulate information on the content, navigation, derivation and any other information stored in the containment model. Elements can be managed via PAC to enable the permission concept of the portal, this means each element of the containment model is a resource which can be protected in regards to what action can be performed on it for a specific user.

The administration of the containment model allows you to:

  • Add and delete root nodes

  • Add, move, reorder and delete child nodes of a node

  • Modify a node, including:

    - Changing associated information

    - Implicitly or explicitly deriving a content node (a page)

1.4.14 Cooperative portlets (Click-To-Action)

One of the most significant advantages of the Portlet architecture is the portlets' ability to communicate with one another to create dynamic, interactive applications. Portlets can use messages to share information, notify each other of a user's actions or simply help better manage screen real estate.

Messages can be sent to all portlets on a page, to a specific named portlet or to all portlets in a single portlet application.

User-Driven Process Integration extensions to C2A

Enhancements to C2A which would contribute to the realization of the User-Driven Process Integration (UDPI) idea would be remembering the user choice for each step (so that only that choice is presented or automatically executed during subsequent interactions), supporting cross-page data transfer, so that the next step in the task is automatically surfaced to the user, supporting the notion of "sticky notes" which the user can attach to chosen sources (as reminders in a partially completed process of what he intends to do next), etc.

Also, a user with special privileges should be able to save his choices (which in effect will define a particular process connecting a set of diverse applications) for import and use by other users or all users in a group or organization.

Property wiring tool

The wiring tool may be invoked as part of editing a page. It provides the capability to view sharable properties on each portlet instance and create wirings between them. It also provides the capability to view the existing set of wiring rules for the current page.

In order to obtain information about the sharable properties, the tool invokes listProperties on the property broker. In order to obtain information about the existing rules, it invokes getMatchRules on the PropertyBrokerServiceInternal interface. This allows the user to pairwise choose compatible properties on two portlet instances and wire them up, or to specify that type-based matching be used for a specified property on a portlet.

After the user has created the matching rules using this tool, the tool will invoke setMatchRules on the PropertyBrokerServiceInternal interface. The property broker service will store the rules persistently and cause the property match broker to update its in-memory data structures to add the new rules.

The Portlet Wiring Tool is not provided with the WebSphere Portal V5 product package but it can be downloaded from the Portlet Catalog at http://www.ibm.com/websphere/portal/portlet/catalog and search for IBM Portlet Wiring Tool V5.0. The Navigation code is 1WP10004E. This portlet should be placed on a page called Wires under the Page Customizer.

1.4.15 Portal Toolkit

The Portal Toolkit for WebSphere Portal is an add-on component that installs into WebSphere Studio Site Developer and adds portlet development and debug functionality. The toolkit includes two primary components and a set of example portlets which demonstrate portlet programming techniques.

The Portlet Wizard components allows a developer to begin development of a new portlet application. The developer specifies the portlet application name, portlet name, Java class name for the portlet, and the markups to be supported by the portlet. The wizard then generates a skeleton portlet application as a project in WebSphere Studio Site Developer. This project includes a Java source file that represents the portlet controller, a Java class that implements a Java bean to transfer display data from the controller class to the display JSPs, and sample display JSPs for all supported portlet modes and display markups . The project also includes properly completed web.xml and portlet.xml documents.

The Portlet Application debug components allow the developer to source debug a portlet. The developer defines a server instance for local debug, with WebSphere Portal running inside WebSphere Studio Site Developer, remote debug, with WebSphere Portal running on a remote instance of WebSphere Application Server, and remote attach, which allows the developer to debug a portal within a full portal production runtime stack.

The toolkit also includes interactive, dialog driven editors for the portlet.xml and web.xml documents. As the developer changes Java files or JSPs, these resources are automatically recompiled and validated .

A portlet application project may be packaged as a standard portal WAR file and exported to a portal server at any time.

In Portal Toolkit V5.0, the following enhancements are included:

  • WebSphere Portal 5.0 Currency / Portlet API support

  • Updated portlet wizard

  • Additional portlet examples

 < 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