< Day Day Up > |
In this section, we present general information about Portal V5. 1.4.1 Portal installWhile 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.4.2 General infrastructureSupport for WebSphere Application Server V5 EnterpriseWebSphere 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 sharingThe 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:
Enabling for CommunitiesWebSphere Portal 5.0 through its WebSphere Member Manager Component provides support for Communities as special groups with additional meta-information . 1.4.3 Event brokerWebSphere 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
1.4.4 Member subsystemWebSphere 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 AuthenticationJ2EE SecurityThe 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 functionalityIn 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 AuthorizationEnhancing access control for roles and inheritanceWebSphere 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:
1.4.7 URL generation, processing and mappingsWebSphere 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 URLsWebSphere 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 URLsIn 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 mappingsTo 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 SearchWebSphere 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 SummariesWebSphere Portal Server 5.0 provides function for automatic categorization of documents as well as automatic generation of document summaries. Eureka! categorizerThe 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 SummarizerThe Summarizer is configurable to run in three client-selectable modes:
Document filter technologyWebSphere Portal 5.x integrates the Outside-In document filters from Stellent. This technology allows the portal to search over 225 document types. Web crawlerThe 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 managementPortal Document ManagerPortal 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:
1.4.10 Content publishingWebSphere 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 TranscodingTranscoding 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 FrameworkStruts 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 interfaceWebSphere 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 supplyThe 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. AdministrationThe 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:
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 C2AEnhancements 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 toolThe 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 ToolkitThe 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:
|
< Day Day Up > |