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:
-
Section 2.15, "Ability to Hide and Show Portlets Based on User Privileges"
-
Section 2.18, "Single Sign-On and External Application Integration"
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 |
|---|---|---|---|---|---|
|
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. |
|
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) |
|
Web provider |
Web provider |
Web provider |
WSRP |
Database provider |
Database provider |
|
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. |
|
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. |
|
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. |
|
|
N/A |
Very flexible, by using the HTML layout. |
Very flexible. |
Very flexible. |
Limited. |
Very flexible. |
|
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. |
|
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. |
|
N/A |
Yes, 2D-3D charts. |
By using BI Beans. |
By using BI Beans. |
HTML charts. |
Programmatically, HTML charts. |
|
Yes. (Supported by Web Clipping 9.0.4.0.2 or later.) |
Yes |
Yes |
No |
Yes |
Yes |
|
N/A |
N/A |
Yes |
Yes |
No |
Yes |
|
Yes |
Yes |
Yes |
Portlet private events (actions). |
No |
No |
|
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. |
|
N/A |
Yes |
Yes |
Yes |
No |
Yes |
|
N/A |
No |
Programmatically |
Programmatically |
Yes |
Programmatically |
|
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
-
WSRP producers
-
Database providers.
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.
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."
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.
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.
When users display the portal page in their Web browsers, the flow of the request works as follows:
-
The user requests a portal page from the Web browser by entering a URL in the browser's address field.
-
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.
-
The PPE contacts all the providers for the portlet content.
-
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.
-
The providers return the portlet content back to the PPE.
-
The PPE assembles the portal page, and the Oracle Application Server returns the page to the Web browser.
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).
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:
-
User-level caching is for a specific user; the cache entries stored are unique for that user and cannot be accessed by other users. Good candidates for user-level caching are portlets supporting personalization, such as e-mail or stock ticker portlets.
-
System-level caching enables users to share a single cache entry and, therefore, there is no need to cache a copy of the object for every user. Examples of content that might be suitable for system-level caching are news portlets that are not personalizable, or custom-built navigation portlets.
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:
-
Expiry-based caching: Consider using expiry-based caching when the portlet content is static or when it is not critical that the most up-to-date content be displayed. When using expiry-based caching, you must specify the caching period.
-
Validation-based caching: Consider using validation-based caching for portlets with dynamic content that changes frequently or unpredictably. The portlet associates its content with a caching key and returns the key value along with the content. When the portlet content is requested, the portlet decides, based on the caching key, if the current content is valid. If the portlet content is valid, then it returns a response indicating that the cached content can be used (that is, the content is valid) or generates the new portlet content and returns it along with a new caching key for that content.
-
Invalidation-based caching: Invalidation-based caching is the most complex, but also the most flexible, form of caching. Consider using invalidation-based caching when you require the efficiency of expiry-based caching with the ability to invalidate the cache content any time. Objects in Oracle Web Cache are considered valid until they are invalidated explicitly.
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.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.
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.
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.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.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.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:
-
Page parameters: You can use a page parameter to pass a value to a page. Using page parameters, the information that is displayed on a page can vary depending on where the page is called from and who is viewing the page. Using page parameters, page designers can synchronize the portlets on a page by passing them the same values. This provides the ability to reuse and tailor portlets on pages by merely integrating them with page parameters. Without this functionality, you would have to code portlets individually to use different parameter values.
-
Public portlet parameters: You can use a public portlet parameter to pass a value to a portlet. Using portlet parameters, the information that is displayed in a portlet can be specific to a particular page or a user. Portlet parameters are created by the portlet developer and are exposed to the page designer, through the user interface. After adding a portlet to a page, page designers can assign values to the public portlet parameters to make the information displayed in the portlet specific to the page.
Page designers can assign values to public portlet parameters by providing a specific value (constant), a system variable (for example, the portal user name), or a page parameter. At run time, the portlet receives the values from the sources specified. In this way, page designers have complete control over the source of the parameter, whereas you have complete control over how the data is used after it is transmitted to the portlet.
-
Private portlet parameters: You can use private portlet parameters to implement internal navigation in your portlet. You can pass parameters to your portlets every time the page is requested. Private portlet parameters can be passed exclusively from the portlet instance to the same portlet instance.
Private portlet parameters do not require a full page refresh. You can create a link in a portlet that can be used to refresh the portlet only, without triggering a full portal page refresh. By doing this, only the content of the affected portlet is updated and the rest of the page is not. Refer to "Partial Page Refresh" in Chapter 7, "Enhancing Java Portlets" for details about setting this programmatically.
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.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.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.17 Pagination Support
Support for pagination is useful when a portlet must display a relatively large set of records.
2.17.3 Java Portlets and PL/SQL Portlets
You can implement pagination in your Java portlets and PL/SQL portlets programmatically.
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.