Skip Headers
Oracle® Fusion Middleware Developer's Guide for Oracle Portal
11g Release 1 (11.1.1)

Part Number E10238-04
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

2 Portlet Technologies Matrix

This chapter describes portlet features, characteristics, technologies, and tools to help you decide which portlet building technology best suits your needs. It includes the following sections:

2.1 The Portlet Technologies Matrix

Table 2-1, "Portlet Building Technologies Comparison Matrix" summarizes the technologies and tools you can use with Oracle Portal on one axis, and the features and characteristics on the other. The matrix describes the tools and technologies that are covered in more detail in this guide: OmniPortlet, Web Clipping, the Java Portlets (PDK-Java) including Standards, Portlet Builder as an appendix, and PL/SQL Portlets (PDK-PL/SQL) (in the matrix only).

Note:

While these are the primary tools for building portlets, additional tools and technologies exist, such as other Oracle products, including Oracle Reports and Oracle Business Intelligence Discoverer. These other tools are not covered in this guide.

The other sections in this chapter provide further detail on the characteristics listed in Table 2-1. Use the table to quickly scan all the features and characteristics, then see the subsequent sections for more in-depth information.

Table 2-1 Portlet Building Technologies Comparison Matrix

Web Clipping OmniPortlet PDK-Java Standards Portlet Builder PDK-PL/SQL

General Suitability

         

A simple wizard-based tool that helps you retrieve and present Web content, originating from other Web sites, in your portal.

Wizard-based tool, accessible from the browser. Capable of retrieving and presenting data from a wide variety of data sources.

APIs for portlets built specifically for Oracle Portal.

Portlets that should work with portals of other vendors. Oracle supports both WSRP and JSR-168.

Wizard-based tool, accessible from the browser. Best suited for simple, DB-centric applications or portlets.

APIs for portlets built specifically for Oracle Portal.

Expertise Required

         

No expertise required.

Basic understanding of one or more supported data sources and the concepts of portlet and page parameters and events.

Java, Servlet, JSP knowledge.

Java, Servlet, JSP knowledge.

Basic understanding of relational DB concepts. Optionally SQL, PL/SQL.

SQL, PL/SQL, PL/SQL Web Toolkit.

Supported Data Sources (for details, see Section 2.3, "Expertise Required")

         

Any Web site accessible on the network over HTTP or HTTPS.

CSV, XML, Web Service, SAP, SQL, Web site, JCA.

No limitations.

No limitations.

SQL (local DB or remote DB through DB link)

SQL (local DB or remote DB through DB link)

Deployment Type

         

Web provider

Web provider

Web provider

WSRP

Database provider

Database provider

Caching Style

         

Expiry-based caching, invalidation-based caching (auto invalidate when personalized).

Expiry-based caching, invalidation-based caching (auto invalidate when personalized).

Expiry-based, validation, and invalidation caching, ESI.

Validation and expiry-based caching.

Expiry-based caching.

Expiry-based, validation, and invalidation caching.

Development Tool

         

Browser - wizard.

Browser - wizard.

Oracle JDeveloper - Java Portlet Wizard (or any other Java development environment - without the Wizard).

Oracle JDeveloper - Java Portlet Wizard (or any other Java development environment - without the Wizard).

Browser - optionally PL/SQL development environment.

PL/SQL development environment.

Portlet Creation Style

         

Develop in place.

Develop in place.

No in-place portlet building experience. Add portlet to page, edit defaults, and personalize.

No in-place portlet building experience. Add portlet to page, edit defaults, and personalize.

Develop first, then add and develop in place.

No in-place portlet building experience. Add portlet to page, edit defaults, and personalize.

User Interface Flexibility

         

N/A

Very flexible, by using the HTML layout.

Very flexible.

Very flexible.

Limited.

Very flexible.

Ability to Capture Content from Web Sites

         

Yes, by its nature.

Yes, by using the Web Data Source.

Yes, by using the java.net package.

Yes, by using the java.net package.

No

Yes, by using the UTIL_HTTP package.

Ability to Render Content Inline

         

Yes. (Supported by Web Clipping 9.0.4.0.2 or later.)

No URL rewriting support, but can be achieved by using public portlet parameters and events.

By using private portlet parameters.

Include servlets and JSPs (using the PortletContext.getRequestDispatcher() method).

Pagination in reports and charts is rendered inline.

By using private portlet parameters.

Charting Capability

         

N/A

Yes, 2D-3D charts.

By using BI Beans.

By using BI Beans.

HTML charts.

Programmatically, HTML charts.

Public Portlet Parameters Support

         

Yes. (Supported by Web Clipping 9.0.4.0.2 or later.)

Yes

Yes

No

Yes

Yes

Private Portlet Parameter Support

         

N/A

N/A

Yes

Yes

No

Yes

Event Support

         

Yes

Yes

Yes

Portlet private events (actions).

No

No

Ability to Hide and Show Portlets Based on User Privileges

         

No, though it is possible to apply security managers that are not exposed through the UI.

No, though it is possible to apply security managers that are not exposed through the UI.

Yes, by using the Security managers.

Yes, the Servlet security model is supported by using methods such as PortletRequest.isUserInRole() and PortletRequest.getUserPrincipal().

Yes

Yes, by using the Security APIs.

Multilingual Support

         

N/A

Yes

Yes

Yes

No

Yes

Pagination Support

         

N/A

No

Programmatically

Programmatically

Yes

Programmatically

Single Sign-On and External Application Integration

         

Web Clipping 9.0.4.0.2 and higher supports external application integration.

Basic authentication support if the data source requires it.

External application integration supported. LDAP integration is supported when the portlet is running behind the same firewall as the LDAP server.

No. (Feasible through custom user attributes.) LDAP integration is supported.

No. (It runs in the Oracle Portal repository; it does not require SSO integration.)

SSO is enabled by using mod_oso.


2.2 General Suitability

This section describes each portlet-building technology in terms of its usage characteristics (for example, wizard-based or programmatic).

2.2.1 Web Clipping

Web Clipping is a simple wizard-based tool that helps you retrieve and present Web content, originating from other Web sites, in your portal. Web Clipping does not require you to have any technical background.

Examples of portlets you can build using Web Clipping

You can build the following portlets using Web Clipping:

  • Stock chart portlet

  • Personalized weather portlet

  • Web mail portlet

2.2.2 OmniPortlet

OmniPortlet is an easy-to-use, wizard-based tool for presenting information from a wide variety of data sources in a variety of formats. OmniPortlet runs completely in the browser. Drop OmniPortlet on a portal page, click the Define link, and choose a data source and presentation format. Select from a wide variety of data sources including the following:

  • Spreadsheet

  • SQL

  • XML

  • Web Service

  • Web page

OmniPortlet does not require you to use an additional development tool or have a strong technical background. Even so, you can use it to build reusable and high-performing portlets.

Examples of portlets you can create with OmniPortlet

You can create the following portlets using OmniPortlet:

  • RSS news feed portlet

  • Sales chart portlet

  • SAP Business Suite portlet

2.2.3 Java Portlets

If the wizard-based portlet building tools do not satisfy your needs, you can build your portlets programmatically using Java. The Java Community Process standardized the Java portlet APIs in 2003. Portlets built against the Java Specification Request (JSR) 168 standard are interoperable across different portal platforms. The Java Portlet Wizard, an Oracle JDeveloper plug-in, helps you get started with your Java portlets.

Note:

When building portlets in Java, you have full control over your portlet's functionality. For example, you can control what it looks like and how it behaves.

Examples of portlets you can build using Java

You can build the following portlets in Java:

  • Discussion forum portlet

  • E-mail portlet

2.2.4 Portlet Builder

Portlet Builder is a wizard-based tool to create data-driven portlets, where the data resides in an Oracle database. You can build interactive forms to insert, update, and delete database records. You can create flexible reports and HTML bar charts to display information from the database. Portlet Builder also enables you to pass parameters and navigate between your data-driven portlets by using dynamic links.

Examples of portlets you can build using the Portlet Builder

You can build the following portlets using Portlet Builder:

  • Data entry portlet

  • Dynamic list of partners portlet

  • Sales results portlet

2.2.5 PL/SQL Portlets

Similar to Java portlets, PL/SQL portlets provide a flexible approach to build Web applications that cannot be satisfied by built-in portlets. For example, your application may require implementation of special business rules or logic or meet custom-designed authorization requirements. PL/SQL portlets are commonly used when you need to perform data intensive operations by using SQL and PL/SQL. Oracle Portal offers a rich set of PL/SQL APIs, such as programmatic provider registration, object level privilege management, user interface control, or multilingual support.

For example, any information provider can create custom portlets to display an application to users through Oracle Portal. Developers simply build their portlets according to Oracle Portal Developer Kit (PDK) specifications and register the provider with Oracle Portal. Developers can use the Oracle PDK to develop portlets to suit their needs.

Examples of portlets you can build using PL/SQL

You can build the following portlets using PL/SQL:

  • Content upload portlet

  • Site map portlet

  • Sophisticated data entry and report portlet

2.3 Expertise Required

While some of the portlet building tools do not require portlet development skills, others assume a strong technical background. This section describes each tool in terms of the level of knowledge required to use it effectively.

2.3.1 Web Clipping

Web Clipping is a tool that does not require any technical background at all. However, if you want to parameterize the Web page content that you clipped, you need to have an understanding of public portlet parameters and page parameters.

2.3.2 OmniPortlet

OmniPortlet requires you to have basic knowledge of the data source you want to leverage in your portlet. Table 2-2 lists the types of data sources that can be used with OmniPortlet and describes the type of information required to work with each type.

Table 2-2 OmniPortlet Data Sources

Data Source Required Information

Spreadsheet

The URL that points to the spreadsheet containing the data that you want to display in the portlet.

SQL

The connection information to the data source and the SQL query that retrieves the data from the database.

XML

The location of the XML source and optionally the address of the XSL filter and the XML schema.

Web Service

The Web Services Description Language (WSDL) URL, the method of the Web service, and optionally the XSL filter URL and the XML schema URL.

Web page

The Web page data source uses the same environment as Web Clipping. No technical background is required.

J2EE Connector Architecture

Although not displayed on the OmniPortlet Wizard's Type page, a J2EE Connector Architecture (JCA) 1.0 adapter is also available. JCA provides a mechanism to store and retrieve enterprise data such as that held in ERP systems (Oracle Financials, SAP, PeopleSoft, and so on).


2.3.3 Java Portlets

To build Java portlets, you must know at least a subset of J2EE. Knowing HTML, Java servlets, and XML is a must, and JSP experience is recommended. Additional Java knowledge is optional, depending on the task you want to perform. Using Java portlets you can access any data source (supported by the Java language).

2.3.4 Portlet Builder

If you want to use Portlet Builder, you must have a good understanding of relational database concepts. Depending on what you want to achieve, SQL and PL/SQL knowledge may be required, as well. Using Portlet Builder, you can consume data from the local (Oracle Application Server infrastructure) database or remote databases using database links.

2.3.5 PL/SQL Portlets

To build PL/SQL portlets, you must know how to write SQL statements, code and debug PL/SQL program units using SQL*Plus or similar development tool that enables you to connect to the Oracle database. You should also know HTML and PL/SQL Web Toolkit to generate the portlet content. Experience of coding the PL/SQL Server Pages (PSP) is optional.

2.4 Deployment Type

Before a portlet can be consumed by an application, you must first deploy it, then register the provider you have deployed the portlet to. As shown in Figure 2-1, portlets can be deployed to Oracle Portal through three provider types:

Web providers are deployed to a J2EE application server, which is often remote and communicates with Oracle Portal through Simple Object Access Protocol (SOAP) over HTTP. Web Services for Remote Portlets (WSRP), an OASIS standard, is supported in the Developer's Preview of Oracle Portal. Database providers are implemented in PL/SQL and deployed in the Oracle database where Oracle Portal is installed.

Figure 2-1 Portlet Provider Overview

Shows portlet providers.
Description of "Figure 2-1 Portlet Provider Overview"

2.4.1 Web Providers

Web providers are the most commonly used and flexible type of provider. They may reside on the same application server as Oracle Portal, on a remote application server, or anywhere on the network (Figure 2-2). A Web provider could be implemented using virtually any Web technology. However, the Oracle Portal Developer Kit provides a Java framework that simplifies the task of building Web providers.

Web providers use open standards, such as XML, SOAP, HTTP, or J2EE for deployment, definition, and communication with Oracle Portal. Also, because Web providers can be deployed to a J2EE container, they do not put an additional load on the Oracle Portal Repository database.

There are several benefits when developing portlets and exposing them as Web providers. You can perform the following tasks:

  • Deploy portlets remotely.

  • Leverage existing Web application code to create portlets.

  • Specify providers declaratively.

  • Take advantage of more functionality than that with database providers.

  • Use standard Java technologies (for example, servlets and JSPs) to develop portlets of Web providers.

To expose your portlets using a Web provider, you must create a provider that manages your portlets and can communicate with Oracle Portal using SOAP. To learn how to expose your portlets using a Web provider, see Section 6.3, "Building JPS-Compliant Portlets with Oracle JDeveloper."

2.4.2 WSRP Producers

Web Services for Remote Portlets (WSRP) is a Web services standard that enables the plug-and-play of visual, user-facing Web services with portals or other intermediary Web applications. Being a standard, WSRP enables interoperability between a standards-enabled container based on a particular language (such as JSR 168, .NET, Perl) and any WSRP portal. So, a portlet (regardless of language) deployed to a WSRP-enabled container can be rendered on any portal that supports this standard. From an architecture perspective, WSRP producers are very similar to Web providers. For more information on the WSRP portal architecture, see "The Relationship Between WSRP and JPS".

To expose your portlets as a WSRP producer, you must create a producer that manages your portlets. To learn more about WSRP, see the WSRP and JSR 168 Standards page on the Oracle Technology Network. To learn how to expose your portlets as a WSRP producer, see Section 6.3.3, "Deploying Your JSR 168 Portlet to the Oracle WebLogic Server." You can also test your WSRP producers online using the Oracle Portal Verification Service:

http://portalstandards.oracle.com/portal/page/portal/OracleHostedWSRPPortal/Welcome

By default, the Portal session store maintains the user's profile information, which is obtained from Oracle Internet Directory, for the duration of a Portal session.

However, in some scenarios, WSRP producers require updates to the WSRP UserContext information sent to them. This information changes during the course of the session. In this scenario, to clear out the cached user information and obtain new information from Oracle Internet Directory when the target page is generated, the application or portlet producer redirects the browser to the following URL:

http(s)://server.domain.com:port/portal/pls/portal/portal.wwsec_app_user_info.flush_cache?p_requested_url=<url-encoded-target-page> 

2.4.3 Database Providers

You can also create a database provider that owns one or more PL/SQL portlets. Database providers and their PL/SQL portlets reside in the Oracle Metadata Repository database and are implemented as PL/SQL packages. To access database providers on remote servers, you can use the Federated Portal Adapter (Figure 2-3). For more information about the Federated Portal Adapter, see Oracle Fusion Middleware Administrator's Guide for Oracle Portal.

Figure 2-3 Database Providers

Shows database providers.
Description of "Figure 2-3 Database Providers"

Database providers are ideal when you need to perform data-intensive operations using PL/SQL. An example of this is when you are building forms or charts with the Oracle Portal user interface or the PL/SQL APIs provided in the PDK.

To learn how to expose your PL/SQL portlets using a database provider, refer to Section 8.13, "Registering Providers Programmatically".

2.4.4 Provider Architecture

Figure 2-4 illustrates the basic architecture of portlet providers.

Figure 2-4 Provider Architecture

Shows provider architecture.
Description of "Figure 2-4 Provider Architecture"

When users display the portal page in their Web browsers, the flow of the request works as follows:

  1. The user requests a portal page from the Web browser by entering a URL in the browser's address field.

  2. The Parallel Page Engine (PPE), which resides in the Oracle Application Server's middle tier, retrieves the portal page layout, portlet, and provider information (also called the page metadata) from the Oracle Portal Repository.

    Note:

    The PPE is responsible for constructing the requested portal page based on the page metadata.

  3. The PPE contacts all the providers for the portlet content.

  4. The providers make the necessary calls to their portlets so that the portlets generate the portlet content in the form of HTML or XML code.

  5. The providers return the portlet content back to the PPE.

  6. The PPE assembles the portal page, and the Oracle Application Server returns the page to the Web browser.

More on OTN

For more information about the portlet and provider architecture, visit the Portlet Development page on Portal Center:

http://portalcenter.oracle.com

Web Clipping, OmniPortlet, and Java portlets communicate with Oracle Portal through Web providers. After you install Oracle Portal, Web Clipping and OmniPortlet are ready to use; their providers are registered with Oracle Portal out of the box. You have to register the provider of your Java portlets explicitly.

Note:

Web Clipping and OmniPortlet are developing very rapidly. The most recent versions of these portlets are available for download on OTN. If you decide to go with the downloaded version of these tools, you must deploy them to Oracle WebLogic Server and register them with Oracle Portal as Web providers. For more information, see Oracle Fusion Middleware Administrator's Guide for Oracle Portal.

Data-driven portlets, built with Portlet Builder, communicate with Oracle Portal through database providers. You do not need to register the Portlet Builder providers with Oracle Portal explicitly; they are automatically registered for you.

PL/SQL portlets communicate with Oracle Portal through a database provider. You have to register the database provider explicitly.

2.4.5 Provider Registration

Oracle Portal includes a provider registration wizard, accessible from the Providers tab in the Navigator. The registration screen contains the following sections:

  • Provider Information: Contains the provider name, time out details, and the implementation style.

  • User/Session Information: Contains information on how session information is communicated to the providers.

  • Database Providers: Contains information specific to database providers, such as the implementation owner and name.

  • Web Providers: Contains information specific to Web providers, such as the URL of the provider, the user's identity communicated to the provider, and proxy information.

  • WSRP Producers: Contains information specific to WSRP producers, such as the WSDL URL and the session handling information supplied by the producer.

The sections that impact session handling are the User/Session Information section and the cookie domain check box on the Web provider registration page of the wizard. For more information on using the same cookie domain, refer to the "Sharing Session Cookies Not Allowed in PDK-Java Release 2" article, which can be accessed from the Portlet Development page on Portal Center (http://www.oracle.com/technology/products/ias/portal/portlet_development_10gr2.html).

User/Session Information

In the User/Session Information section, you can choose one of two options, depending on the session-related information you want the providers to receive from Oracle Portal. The options are as follows:

  • Public: Choosing this option sets the name of the user to Public. The providers will not receive any session-related information like the session ID or the time the user logged in. This option is the equivalent of the LOGIN_FREQUENCY_PUBLIC in the provider registration API (see Section 8.13, "Registering Providers Programmatically").

  • User: Choosing this option sends the name of the Oracle Portal user to the providers. This section contains the following two options:

    • Login Frequency: Here, you can select one of three options (always, once for each user session, and never) to determine how often the session information must be sent to the provider, and thus how often the user needs to log in.

    • Require Portal user-specific session information: Here, you can specify whether the session information will be sent in the provider calls.

2.5 Caching Style

Caching plays an essential role in ensuring that your portal is highly performant. Oracle Portal supports caching on various levels, such as caching pages, portlets, styles, and page metadata. Caching portlets is key to delivering accurate information in a timely manner to your users. All portlet building technologies, available with Oracle Portal, support caching.

As Oracle Portal supports user personalization of pages and portlets, the view of a page can vary from user to user. Oracle Portal's caching is designed to allow content to vary for each user. Therefore, portal objects, including portlets, can be cached at two levels, user level and system level, and can be described as follows:

When not using caching, you may find accessing various data sources with Web Clipping, OmniPortlet, and Portlet Builder to be time consuming. When you enable caching, you instruct Oracle Portal or Oracle Web Cache to maintain a copy of the portlet content. If the portlet is requested and the content was cached previously, the portlet does not have to spend time contacting the data source and regenerating its content again. Simply, the previously cached portlet content is returned. Different types of caching are as follows:

2.5.1 Web Clipping, OmniPortlet, and Portlet Builder

For portlets built with Web Clipping, OmniPortlet, and Portlet Builder you can specify a period of time for which they are cached (expiry-based caching). In addition to this, portlets built with Web Clipping and OmniPortlet are refreshed automatically when the end user personalizes them.

2.5.2 Java Portlets

Java portlets support three types of caching: expiry-, validation-, and invalidation-based caching. With Java portlets, you can combine invalidation-based caching with either expiry-based or validation-based caching.

In addition to caching all your portlet's content, you can also cache fragments of your portlets by using Edge Side Includes (ESI).

2.5.3 PL/SQL Portlets

Similar to Java portlets, PL/SQL portlets also support three types of caching: expiry-, validation-, and invalidation-based caching.

2.6 Development Tool

This section describes development tools you can use to build different types of portlets.

2.6.1 Web Clipping, OmniPortlet, and Portlet Builder

OmniPortlet, Web Clipping, and Portlet Builder use a browser-based wizard as the development tool.

2.6.2 Java Portlets

Although you can use any Java development environment to build Java portlets, it is highly recommended that you use Oracle JDeveloper, a professional, integrated development environment (IDE). While you can consider other IDEs, the PDK contains an Oracle JDeveloper plug-in that includes the Java Portlet Wizard, to minimize your Java portlet development efforts.

The Java Portlet Wizard generates a starting skeleton and file structure for both JSR 168 and PDK-Java portlets. You need to add only your own business logic to the skeleton. Oracle JDeveloper can also package and deploy your applications to your J2EE container, such as Oracle WebLogic Server. Also, Oracle JDeveloper helps you test your portlet provider. Oracle recommends that you use the preconfigured Oracle WebLogic Server that is shipped withOracle JDeveloper as your development Java portlet runtime environment, if the version matches that of the platform on which you plan to deploy.

2.6.3 PL/SQL Portlets

When developing a PL/SQL portlet, you create PL/SQL program units that access Oracle Portal by calling Oracle Portal PL/SQL APIs. To enable this access, you create a schema, the provider schema, to store the provider and portlet PL/SQL packages in the same database in which Oracle Portal is installed. The provider schema must be granted execute privileges on the Oracle Portal PL/SQL APIs.

To facilitate the development of database providers and PL/SQL portlets, you can use the PL/SQL Generator, a hosted utility that creates installable PL/SQL code for a database provider and its PL/SQL portlets. The PL/SQL Generator is a Web application that receives the provider and portlet definitions in the form of an XML file. The syntax of the XML tags that are used for the provider and portlet definition is a subset of the XML tags that are used for defining Web providers with the PDK-Java. The output of the PL/SQL Generator is a SQL script that can be run from SQL*Plus. The script contains SQL commands for installing the provider and portlet packages.

More on OTN

The hosted PL/SQL Generator is available on the Oracle Portal Developer Kit page of OTN:

http://www.oracle.com/technology/products/ias/portal/pdk.html

2.7 Portlet Creation Style

Oracle Portal supports the following two types of portlet creation as shown in Figure 2-5:

The figure also indicates that the develop first, add later portlet creation is usually the task of the portlet developer, while the develop in-place portlet creation is the page designer's responsibility.

Figure 2-5 Portlet Creation Style

Shows portlet creation style.
Description of "Figure 2-5 Portlet Creation Style"

2.7.1 OmniPortlet and Web Clipping

OmniPortlet and Web Clipping both offer a develop in-place portlet creation style. First you add the portlets to a portal page and then you define them in place on the page.

2.7.2 Java Portlets

Typically Java portlets offer a develop first, add later portlet creation style. Two wizards are available through Oracle JDeveloper to assist with the creation of Oracle PDK-Java and JSR 168 portlets. The wizards generate the basic files required for portlet creation. The developer hand-codes the portlet logic. The development sequence for Java portlets is to create the portlet, deploy it to a provider, register the provider with Oracle Portal, and then add the portlet to a page.

Note:

With extensive coding, you can create develop in-place Java portlets. For example, Web Clipping and OmniPortlet are both Java portlets.

2.7.3 Portlet Builder

With Portlet Builder you define the portlets first. The previously defined portlets are then made available to you in the Portlet Repository so you can add them to your pages. For simple portlets, though, Portlet Builder offers you the develop in-place experience, similar to OmniPortlet and Web Clipping.

Note:

Portlets built with Portlet Builder's develop in-place technology are somewhat limited as compared to those built using the Navigator.

2.7.4 PL/SQL Portlets

Similar to the Java portlets, PL/SQL portlets typically follow the develop first, add later creation path. Extensive coding is required to develop in-place PL/SQL portlets. For example, simple in-place portlets that are offered by Portlet Builder are written in PL/SQL.

2.8 User Interface Flexibility

This section describes the portlet building tools in terms of the control you have over the user interface.

2.8.1 Web Clipping

Because of its nature, Web Clipping always displays the remote Web site content, therefore UI flexibility is not a requirement for this portlet.

2.8.2 OmniPortlet

OmniPortlet enables you to use a number of different prebuilt layouts, such as scrolling news, tabular, and chart. You can also use the built-in HTML layout to personalize the look and feel of your portlet using HTML and JavaScript.

2.8.3 Java Portlets and PL/SQL Portlets

In Java portlets and PL/SQL portlets, you have full control over your portlet's user interface. Your portlet is free to generate any HTML content that conforms the rendering rules for Oracle Portal pages.

2.8.4 Portlet Builder

While you can be very productive in building portlets with Portlet Builder, it is somewhat limiting with respect to the user interface.

2.9 Ability to Capture Content from Web Sites

This section describes the portlet building tools in terms of their ability to include content from other sources.

2.9.1 Web Clipping

For portlets that display content from a remote Web site as it is presented at the source location, the best tool to use is Web Clipping. Web Clipping can tolerate the changes of the source HTML page to some extent. If a clipped table moves from one place to another in the source page, the Web Clipping engine can find the table again using the internal "fuzzy match" algorithm. Portlets built with Web Clipping can also maintain sessions to the remote Web sites. Web Clipping also supports end user personalization of HTML form values.

2.9.2 OmniPortlet

For portlets using the data but not the layout from a remote Web site, the best choice is OmniPortlet. Use OmniPortlet to retrieve the data, process the data (format, filter, and so on), and present it in a portlet in a tabular, chart, or news format. OmniPortlet is a powerful tool that extracts data from Web pages by using its Web page data source.

2.9.3 Java Portlets

Java portlets can take advantage of the low-level Java networking APIs to retrieve and process content from remote Web sites. To avoid unnecessary development efforts, before choosing Java always make sure that Web Clipping or OmniPortlet are not viable options.

2.9.4 PL/SQL Portlets

PL/SQL portlets can communicate with Web servers to access data on the Internet by using procedures and functions from the UTL_HTTP package. The package makes HTTP callouts from SQL and PL/SQL. The package also supports HTTP over the Secured Socket Layer protocol (SSL), also known as HTTPS, directly or through an HTTP proxy. Other Internet-related data-access protocols (such as the File Transfer Protocol (FTP) or the Gopher protocol) are also supported using an HTTP proxy server that supports those protocols.

2.10 Ability to Render Content Inline

Active elements in your portlets, such as links or form buttons, enable your users to navigate to remote URLs. In a News portlet, for example, you can click a hyperlink to navigate to a news site with detailed information about news of interest. For example, a user clicks a news summary link in a News portlet, leaves the page, and lands on the news site.

You may have a requirement to keep your users within the context of the portal page by rendering the requested content within the same portlet container. For example, a user clicks a news summary link in a News portlet, and the portlet refreshes with the detailed news article.

2.10.1 Web Clipping

The Web Clipping portlet supports URL rewriting for achieving inline content rendering. It can process the links originating from the source Web site and rewrite them to achieve the desired functionality.

You can choose from the following three options:

  • Select not to rewrite the URLS within the portlet, in which case clicking the links takes users out of the portal to the Web site that provides the clipping. Whenever the link brings the user to a place that requires authentication, the user must enter login information before the link target is displayed.

  • If the Web Clipping provider is registered with an External Application and the clipping requires authentication, you can instruct Web Clipping to rewrite all URLs within the portlet to point to the Login Server. In this case, navigation will cause the user to leave Oracle Portal, while also using the Login Server to log the browser into the External Application.

  • Select to rewrite all URLS within the portlet (inline rendering) to point back to the portal page so that all browsing within the Web Clipping portlet remains within Oracle Portal. If the Web Clipping provider is registered with an External Application, this will cause the Web Clipping provider to log itself into the External Application. In this case, the navigation within the portal through the Web Clipping provider is authenticated in the External Application.

2.10.2 OmniPortlet

OmniPortlet does not offer URL rewriting directly, but you can achieve inline rendering functionality by using public portlet parameters and events. Then you have to map the events to the same portal page where your OmniPortlet resides.

2.10.3 Java Portlets

Since you have full control over the links and buttons in Java portlets, you can easily implement inline rendering functionality. To achieve inline rendering, you must append the private portlet parameters to the page URL.

If you use Struts in your portlet, the PDK-Struts integration framework renders your content always in the same portlet container.

If your portlet consists of multiple JSPs (for example, several steps in a survey or wizard), your portlet can make use of a special parameter to specify at run time the JSP to use to render the content.

2.10.4 Portlet Builder

Portlets built with Portlet Builder do not have inherent inline rendering support. You can, however, construct your links in SQL-based reports and charts so that they point to specific portal pages. If required, you can also pass parameters to portal pages, which in turn can be mapped to portlet parameters.

2.10.5 PL/SQL Portlets

Similar to Java portlets, you have full control over the active elements in PL/SQL portlets and, therefore, you can achieve the inline rendering functionality programmatically by implementing private portlet parameters.

2.11 Charting Capability

This section describes the portlet building tools in terms of their charting functionality.

2.11.1 Web Clipping

Web Clipping clips pre-existing content. So, while it does not create charts, it can retrieve and present HTML content that contains charts.

2.11.2 OmniPortlet

OmniPortlet supports bar, line, and pie charts. Charts in OmniPortlet are dynamically generated images, which can include hyperlinks.

2.11.3 Java Portlets

You can create sophisticated chart portlets programmatically in your Java portlets using Oracle's Business Intelligence (BI) Beans.

Note:

Oracle Reports and Oracle BI Discoverer portlets use BI Beans to create professional graphs.

2.11.4 Portlet Builder

With Portlet Builder, you can build HTML-based bar chart portlets. Among other features, you can specify the color and orientation of the bars.

2.11.5 PL/SQL Portlets

In PL/SQL portlets, HTML-based charting can be achieved by extensive coding.

2.12 Public Portlet Parameters Support

There are three types of parameters in Oracle Portal: page parameters, public portlet parameters, and private portlet parameters. These parameters can be described as follows:

Portlets supporting public portlet parameters enable page designers to tailor the portlets' data input for each portlet instance. In this case, the portlet developer can focus on the portlet logic, while page designers can easily reuse portlets and address the interaction between the page and the portlets.

All five portlet building technologies discussed in this chapter (OmniPortlet, Web Clipping, Java portlets, Portlet Builder, and PL/SQL portlets) support public portlet parameters. OmniPortlet, Web Clipping, and Portlet Builder provide complete support through their wizard interface. You can add public portlet parameter support to your Java portlets programmatically or with the Java Portlet Wizard. PL/SQL portlets support public parameters only programmatically.

Note:

The JSR 168 standard does not cover the notion of public portlet parameters. If you want to utilize public portlet parameters in your Java portlets, you have to use PDK-Java.

2.13 Private Portlet Parameter Support

This section describes the portlet building tools in terms of their support for private parameters.

2.13.1 OmniPortlet, Web Clipping, and Portlet Builder

OmniPortlet, Web Clipping, and Portlet Builder do not provide access to the portlet developer to private portlet parameters.

2.13.2 Java Portlets and PL/SQL Portlets

In your Java portlets and PL/SQL portlets, you can implement internal navigation by using private portlet parameters.

Note:

PL/SQL portlets do not support private and public parameters simultaneously. You need to decide which parameter type to support before coding your PL/SQL portlet.

2.14 Event Support

An event is a user action that you define to display a Portal page. User actions include clicking a link or a button in a portlet. Page designers specify what to do when an event occurs in a portlet on a page. When an event occurs, page designers can either redisplay the current page or navigate the user to another portal page, optionally passing values to that page's parameters.

2.14.1 Web Clipping, OmniPortlet, and Java Portlets

Web Clipping, OmniPortlet, and Java portlets support events.

2.14.2 Portlet Builder and PL/SQL Portlets

Portlet Builder and PL/SQL portlets do not support events.

2.15 Ability to Hide and Show Portlets Based on User Privileges

This section describes the portlet building tools in terms of their support for authorization functionality.

2.15.1 Web Clipping and OmniPortlet

You can hide and show portlets built with Web Clipping and OmniPortlet on portal pages dynamically by using security managers. Although Web Clipping and OmniPortlet do not expose security managers through the user interface, you can apply them by editing their XML provider definition file.

2.15.2 Java Portlets

The PDK provides a number of security managers for Java portlets. Following are two examples:

  • Group security manager: The group security manager makes the portlet appear to users who are members of a specified group, while hiding it from those who are not members.

  • Authentication level security manager: You can use the authentication level security manager to control access to the portlets based on the user's authentication level. For example you may hide the portlet from public users but display it to authenticated users.

JSR 168 portlets support the standard servlet mechanisms.

2.15.3 Portlet Builder

Portlet Builder provides a declarative user interface to control access to portlets.

2.15.4 PL/SQL Portlets

The PDK provides security APIs to implement hiding and showing content in PL/SQL portlets.

2.16 Multilingual Support

This section describes the portlet building tools in terms of their support for other languages.

2.16.1 Web Clipping, OmniPortlet, Java Portlets, and PL/SQL Portlets

Web Clipping, OmniPortlet, Java portlets, and PL/SQL portlets display textual information in the language selected by the portal user.

2.16.2 Portlet Builder

Portlets built with Portlet Builder support English only.

2.17 Pagination Support

Support for pagination is useful when a portlet must display a relatively large set of records.

2.17.1 Web Clipping

Pagination support is not applicable to Web Clipping.

2.17.2 OmniPortlet

OmniPortlet does not support pagination.

2.17.3 Java Portlets and PL/SQL Portlets

You can implement pagination in your Java portlets and PL/SQL portlets programmatically.

2.17.4 Portlet Builder

Portlet Builder has built-in support for pagination.

2.18 Single Sign-On and External Application Integration

This section describes the portlet building tools in terms of authentication for external application.

2.18.1 Web Clipping

Web Clipping's integration with the external application framework provides a fully automated mechanism to store passwords to external Web sites. All you have to do is to associate an External Application ID to the Web Clipping provider when registering the provider.

2.18.2 OmniPortlet

OmniPortlet enables you to store connection information when the data source is password protected. The credentials to access the data source can either be shared across all users, or saved individually for each user. OmniPortlet is capable of storing database credentials, as well as HTTP basic authentication user name-password pairs. The credentials are stored in the secured data repository of OmniPortlet, in an Oracle database.

2.18.3 Java Portlets

Java portlets support programmatic integration with the external application framework as well as any LDAP server, such as Oracle Internet Directory.

2.18.4 PL/SQL Portlets

You can build PL/SQL portlets that enable single sign-on by using mod_osso, an authentication module on the Oracle HTTP Server. mod_osso is a simple alternative to the single sign-on SDK, used in earlier releases to integrate partner applications. mod_osso simplifies the authentication process by serving as the sole partner application to the Single Sign-On server.

PL/SQL portlets can integrate with the external application framework programmatically.