| Oracle® WebCenter Framework Developer's Guide 10g (10.1.3.2.0) Part Number B31074-05 |
|
|
View PDF |
| Oracle® WebCenter Framework Developer's Guide 10g (10.1.3.2.0) Part Number B31074-05 |
|
|
View PDF |
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:
Table 15-1, "Portlet Building Technologies Comparison Matrix" summarizes the technologies and tools you can use with Oracle WebCenter Framework. The matrix describes the tools and technologies that are covered in more detail in this guide: OmniPortlet, Web Clipping portlet, and programmatic portlets, including standards-based (JSR 168) portlets and PDK-Java portlets. Additionally, it includes Oracle Portlet Factory.
Note:
While these are the primary tools for building portlets, additional tools and technologies exist, such as other Oracle products, including Oracle Reports, OracleBI Discoverer, and the JSF Portlet Bridge. These other tools are not covered in this guide.The other sections in this chapter provide further detail on the characteristics listed in Table 15-1. Use the table to quickly scan all the features and characteristics, then see the subsequent sections for more in-depth information.
Table 15-1 Portlet Building Technologies Comparison Matrix
| Web Clipping | OmniPortlet | Oracle Portlet Factory | Programmatic Portlets Standards-Based/PDK-Java |
|---|---|---|---|
|
A simple wizard-based tool, accessible from a browser, that assists in retrieving and presenting Web content that originates from other Web sites in a WebCenter application. |
Wizard-based tool, accessible from a browser, that assists in retrieving and presenting data from a wide variety of data sources. |
A portlet creation environment for the development, deployment, and maintenance of custom and composite portlets that interact with enterprise applications, such as SAP. |
PDK-Java offers Oracle-specific application programming interfaces (APIs) for building portlets for use in WebCenter applications and OracleAS Portal. Standards-based portlets additionally work with portals of other vendors. Oracle Oracle WebCenter Framework supports both WSRP and JSR-168 standards. |
|
No expertise required. |
Basic understanding of one or more supported data sources and the concepts of portlet and page parameters. |
Basic understanding of J2EE Portlet life cycle and basic coding knowledge without the need to know the Java language. The target audience for this tool is the business developer. |
Java, Servlet, JSP knowledge. |
|
(for details, see Section 15.3, "Expertise Required") |
|||
|
Any Web site accessible on the network over HTTP or HTTPS. |
CSV, XML, Web Service, SAP, SQL, Web site, JCA. |
Web Services, SQL, PeopleSoft, JDE, and SAP. |
No limitations. |
|
PDK-Java producers |
PDK-Java producers |
WSRP and PDK-Java producers |
PDK-Java uses PDK-Java producers. Standards-based portlets use WSRP producers. |
|
Expiry-based caching, validation-based caching (auto invalidate when personalized). |
Expiry-based caching, validation-based caching (auto invalidate when personalized). |
Cache Control builder enables caching of output related to an action within a model for a specified amount of time. |
Expiry-based, validation, and invalidation caching, Edge Side Includes. Note: JSR 168 does not support validation based caching. WSRP 1.0 does. If you use a pure WSRP portlet, then validation-based caching is also supported. If you host a JSR portlet on WSRP (as is done in Oracle Oracle WebCenter Framework) then validation-based caching is not supported. |
|
Browser - wizard. |
Browser - wizard. |
Portlet Factory tool (Builders and Models). |
Oracle JDeveloper Java Portlet wizard (or any other Java development environment). |
|
Design-time at run time. |
Develop first, add later. |
||
|
N/A |
Very flexible, by using the HTML layout. |
Flexible. Portlet code is generated based on the choices made in a Builder wizard. Developers can view generated code, but are never required to interact with it. |
Very flexible. |
|
Yes, by its nature. |
Yes, by using the Web Page Data Source. |
No. This is a tool for aggregating data, content, and processes from existing enterprise applications, such as SAP, and deploying them as custom portlets. |
Yes. For PDK-Java, use the For standards-based portlets, use the |
|
Yes |
No. However, inline rendering can be achieved through public portlet parameters. |
Yes, for multipage portlets. |
Yes. For PDK-Java, use private portlet parameters. Standards-based portlets include servlets and JSPs, using the method |
|
No |
Yes, 2D-3D charts. |
Out-of-the-box demonstration version of Greenpoint WebCharts builder for creation of charts and graphs. |
Yes, using BI Beans. |
|
Yes |
Yes |
Access public parameters through the |
Yes Note: In standards-based portlets, support is available for public parameters using WSRP 2.0's navigational parameter feature along with Oracle WebCenter Framework extensions to JSR 168. |
|
No |
No |
No, however, elements called variables function much the same as parameters within a family of Portlet Factory portlets. |
Yes |
|
No, though it is possible to apply security managers that are not exposed through the user interface (UI). |
No, though it is possible to apply security managers that are not exposed through the UI. |
No |
Yes. For PDK-Java, by using the Security managers. For standards-based portlets, the Servlet security model is supported by using methods such as |
|
N/A |
Yes |
Yes |
Yes |
|
N/A |
No |
Yes |
Yes, programmatically |
|
External application integration supported. |
Basic authentication support if the data source requires it. |
External application integration supported. |
For PDK-Java portlets, external application integration is supported. LDAP integration is supported when the portlet is running behind the same firewall as the LDAP server. For standards-based portlets, though not specifically supported, external application support is feasible through custom user attributes.) LDAP integration is supported. |
This section describes each portlet-building technology in terms of its usage characteristics (for example, wizard-based or programmatic).
Web Clipping is a simple wizard-based tool that assists with retrieving and presenting Web content that originates from other Web sites in a WebCenter application. Web Clipping does not require a technical background.
Examples of portlets you can build using Web Clipping
The examples of portlets that you can build by using Web Clipping are as follows:
Stock chart portlet
Web mail portlet
News portlet containing dynamic content from an existing Web site
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 page, click the Define link, and choose a data source and a presentation format. Select from a wide variety of data sources as follows:
Spreadsheet
SQL
XML
Web Service
Web page
OmniPortlet does not require the use of an additional development tool or a strong technical background. Even so, it can be used for building reusable, high-performing portlets.
Examples of portlets you can build using OmniPortlet
The examples of portlets that you can build by using OmniPortlet are as follows:
RSS news feed portlet
Sales chart portlet
SAP BAPI-based portlet
Oracle Portlet Factory assists the business developer in creating portlets that aggregate data, content, and processes from existing enterprise applications, such as SAP applications.
Developers rapidly build portlets by pulling together a sequence of highly-adaptive, reusable software components, called Builders. These builders perform specific application functions, such as querying a database, executing a business process within an application, or rendering an output UI. Developers assemble Builders into Models, similar to the way a spreadsheet model is created by snapping formulas together. Models are executed at run time to dynamically generate application code, including JSPs, Java classes, and XML documents, as well as all of the low-level artifacts that constitute the portlet application. Business developers can view the generated application code, but they are never required to work with it.
Both Oracle PDK-Java and JSR 168 portlet types are supported.
Examples of portlets you can build using Oracle Portlet Factory
The examples of portlets that you can build by using Oracle Portlet Factory are as follows:
SAP form portlet
SAP multipage portlet
SAP transaction portlet
If the wizard-based portlet building tools do not satisfy your needs, then 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, a tool available through the WebCenter Suite, assists with building 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
The examples of portlets that you can build by using Java are as follows:
Discussion forum portlet
E-mail portlet
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.
Web Clipping does not require a technical background. However, if you want to parameterize the Web page content that you clipped, then you must have an understanding of public portlet parameters and page parameters.
OmniPortlet requires a basic knowledge of the data source you want to leverage in your portlet. Table 15-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 15-2 OmniPortlet Data Sources
| Data Source | Required Information |
|---|---|
|
Spreadsheet |
The URL that points to the spreadsheet containing the data 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). |
Oracle Portlet Factory is aimed at the business developer looking for a tool that facilitates rapid development and does not require knowledge of Java or J2EE. Development consists of Builders (such as buttons, loops, actions, and so on) constructed inside of Models. Code is generated automatically. Developers can view generated code, but are not required to work with it in any way.
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.
Note:
Additional tools, such as Oracle Portlet Factory, are available for making Java portlet development easier.Before a portlet can be consumed by an application, you must first deploy it, then register the producer you've deployed the portlet to. As shown in Figure 15-1, portlets can be deployed through the following two producer types:
PDK-Java producers
WSRP producers
Within WSRP, both version 1.0 and 2.0 are supported.
PDK-Java portlets are deployed to a J2EE application server, which is often remote and communicates with the consumer through Simple Object Access Protocol (SOAP) over HTTP. JSR 168 portlets are deployed to a WSRP producer, which is also remote and communicates with the consumer through WSRP (Web Services for Remote Portlets).
PDK-Java producers use open standards, such as XML, SOAP, HTTP, or J2EE for deployment, definition, and communication with applications. Figure 15-2 shows how OracleAS Portal incorporates portlets from a PDK-Java producer and the PDK-Java producer communicates with WebCenter application using SOAP over HTTP.
There are several benefits to developing portlets and exposing them through PDK-Java producers as follows:
Deploy portlets remotely.
Leverage existing Web application code to create portlets.
Specify producers declaratively.
Use standard Java technologies (for example, servlets and JSPs) to develop portlets.
To expose your portlets using a PDK-Java producer, you must first create a producer that manages your portlets and communicates with Oracle WebCenter Framework using SOAP. To learn how to expose your portlets using a PDK-Java producer, see Section 18.5, "Building JPS-Compliant Portlets with Oracle JDeveloper".
Oracle WebCenter Suite supports Web Services for Remote Portlets (WSRP) versions 1.0 and 2.0. WSRP 2.0 support is for a preliminary (that is, preproduction) version of WSRP 2.0. This emerging standard provides support for inter-portlet communication and export or import of portlet customizations.
Use of WSRP 2.0 requires use of Oracle-specific extensions. For example, portlets produced by WSRP 2.0 producers must be deployed to Oracle's container (OC4J) to take advantage of the benefits this newer version provides. This is because standard portlet APIs (such as JSR 286) have not yet evolved to the level of the WSRP 2.0 communication protocol.
The Producer Registration wizard is the entry point for registering both WSRP 1.0 and 2.0 producers. The wizard automatically recognizes whether WSRP 1.0 or 2.0 is in play.
Architecturally, WSRP producers are very similar to PDK-Java producers. WSRP is a communication protocol between WebCenter application servers and portlet containers. WSRP is a standard that enables the plug-and-play of visual, user-facing Web services with 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 application that supports this standard.
Note:
For more information about the WSRP architecture, see "The Relationship Between WSRP and JPS" in Chapter 18, "Creating Java Portlets".To make standard portlets (such as JSR 168, .NET, Perl) available to a WebCenter application, you must package them in a portlet application and deploy them to a WSRP container. To learn more about WSRP, see the WSRP and JSR 168 Standards page on the Oracle Technology Network:
http://www.oracle.com/technology/products/ias/portal/standards.html
To learn how to package your portlets in a WSRP container, see Section 18.9, "Deploying Your Portlet to an Application Server". You can also test your WSRP producers online using the OracleAS Portal Verification Service:
http://portalstandards.oracle.com/portal/page/portal/OracleHostedWSRPPortal/Welcome
Figure 15-3 illustrates the basic architecture of portlet producers.
When users display a page in their Web browsers, the flow of the request works as follows:
The user requests a page from the Web browser by entering a URL in the browser's address field.
The browser transmits the request to the application over HTTP.
The application contacts the portlet producers that provide the portlets that display on the requested page.
The producers make the necessary calls to their portlets so that the portlets generate the portlet content in the form of HTML or XML code.
The producers return the portlet content back to the application using their relevant protocols:
JSR 168 portlets are initialized by WSRP producers, which communicate using the WSRP 1.0 or 2.0 protocol.
PDK-Java portlets are initialized by PDK-Java producers, which communicate using SOAP over HTTP.
Note:
For more information about the portlet and producer architecture, visit the Portlet Development page on Portal Center (
http://www.oracle.com/technology/products/ias/portal/index.html).Web Clipping, OmniPortlet, Oracle Portlet Factory portlets, and Java portlets communicate with Oracle WebCenter Framework through either WSRP or PDK-Java producers. You must register these producers with Oracle WebCenter Framework before you can use the portlets they produce in your WebCenter application.
The latest versions of Web Clipping and OmniPortlet are available through the preconfigured Oracle Containers for J2EE (OC4J). For more information, see Section 3.2, "Using the Preconfigured OC4J".
Portlet caching is key to rapid response to user requests. Portlets implement validation-based and expires-based caching using Java Object Cache. Invalidation-based caching continues to be implemented by a Web Cache that fronts the PDK-Java producer running the Web Clipping portlet and OmniPortlet.
Caching rules can be specified at a portlet's container level, encoded in the portlet's own logic, or, for JSR 168 portlets, established through the portlet wizard. Provided it is specified, container-level caching takes over when caching is not part of the portlet code.
At the application level, Oracle WebCenter Framework supports use of a Java cache for the establishment of application-level caching rules.
When not using caching, you may find accessing various data sources with Web Clipping and OmniPortlet to be time consuming. When you enable caching at the application level, you instruct the Java cache to maintain a copy of the portlet content. When data that was previously cached is requested, no time is lost in contacting the data source and regenerating its content. Instead, the previously cached portlet content is returned.
A portlet's content weighs heavily in determining the type of caching the portlet should use. For example:
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 cache content.
In addition to invalidation-based caching, expiry-based caching can be specified for the Web Clipping portlet and OmniPortlet. Additionally, these portlets are refreshed automatically when they are personalized.
This section describes the development tools you can use to build different types of portlets.
OmniPortlet and Web Clipping use a browser-based wizard as the development tool.
Oracle Portlet Factory runs inside the Eclipse Integrated Development Environment (IDE).
Although you can use any Java development environment to build Java portlets, it is highly recommended that you use Oracle JDeveloper, a professional IDE. While you can consider other IDEs, Oracle JDeveloper 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 OC4J. Also, Oracle JDeveloper helps you test your portlet producer. Oracle recommends that you use the preconfigured OC4J, provided through Oracle WebCenter Framework, as your development Java portlet run time environment. For more information, see Chapter 3, "Preparing Your Development Environment".
Oracle WebCenter Framework supports the following types of portlet creation (Figure 15-4):
Develop first, add later
Design-time at run time
Develop first, add later portlet creation is usually the task of the portlet developer; design-time at run time portlet creation is the application developer's responsibility.
OmniPortlet and Web Clipping both offer a "design-time at run time" portlet creation style. Register the portlet producers with the application that will consume the portlets, add the portlets to an application page, run the application, and then define the portlets in-place on the page.
Oracle Portlet Factory offers a "develop first, add later" portlet creation style. Developers use the Portlet Factory's UI to place Builders (such as buttons, loops, actions, and so on) inside Models. Code is generated automatically. Developers can view generated code, but are not required to work with it in any way. The development sequence for Oracle Portlet Factory is build the Model, deploy it to a producer, register the producer with the application that will consume the portlet, and then add the portlet to an application page.
Typically programmatic portlets offer a "develop first, add later" portlet creation style. Two wizards are available through Oracle WebCenter Framework 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 programmatic portlets is to create the portlet, deploy it to a producer, register the producer with the application that will consume the portlet, and then add the portlet to an application page.
Note:
With extensive coding, you can create "design-time at run time" Java portlets. For example, Web Clipping and OmniPortlet are both Java portlets.This section describes the portlet building tools in terms of the control you have over the user interface.
Because of its nature, Web Clipping always displays the remote Web site content, therefore UI flexibility is not a requirement for this portlet.
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.
Note:
When using JavaScript in portlets, developers must ensure that the JavaScript identifiers are qualified. That is, identifiers must be unique for each portlet instance and must not clash with the JavaScript on the page.With Oracle Portlet Factory, you interact with Models and Builders. Each Builder has a wizard that steps you through the construction of Model content. Portlet code is generated based on the choices you make in the wizard. Portlet Factory simplifies the task of creating tables. Many out-of-the-box UI templates and styles ease the task of giving portlets a distinct look and feel.
This section describes the portlet building tools in terms of their ability to include content from other sources.
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, then 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 user personalization of HTML form values.
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.
Active elements in portlets, such as links or form buttons, enable users to navigate to remote URLs. In a News portlet, for example, a user 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 application page, and lands on the news site.
You may have a requirement to keep your users within the context of the application 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.
This maintenance of context is what rendering content inline means .
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.
The following options are available:
Select not to rewrite the URLs within the portlet, in which case clicking the links takes users out of the WebCenter application 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, then 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 the WebCenter application, 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 page so that all browsing within the Web Clipping portlet remains within the WebCenter application. If the Web Clipping provider is registered with an External Application, then this will cause the Web Clipping provider to log itself in to the External Application. In this case, the navigation within the WebCenter application through the Web Clipping provider is authenticated in the External Application.
Rendering content inline is not supported, but you can achieve inline rendering using public portlet parameters.
Oracle Portlet Factory offers support for rendering a multipage portlet in the same portlet container, in other words, in line. Links to additional portlet pages are logical, rather than physical. That is, they map to a logical location rather than a physical address. This provides superior link integrity in instances where portlets are moved.
As you have full control over the links and buttons in Java portlets, you can easily implement the 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, then the PDK-Struts integration framework renders your content always in the same portlet container. Oracle recommends, however, that you use ADF Faces navigation for your new WebCenter application portlets.
If your portlet consists of multiple JSPs (for example, several steps in a survey or wizard), then your portlet can make use of a special parameter to specify at run time the JSP to use to render the content.
This section describes the portlet building tools in terms of their charting functionality.
Web Clipping clips pre-existing content. So, while it does not create charts, it can retrieve and present HTML content that contains charts.
OmniPortlet supports bar, line, and pie chart types. Charts are dynamically generated images, which can include hyperlinks.
Oracle Portlet Factory includes a demonstration version of the Greenpoint Web Chart builder. This builder enables the creation of sophisticated charts and graphs. A full license can be obtained from Greenpoint:
http://www.webcharts3d.com/
Typically, a portlet's state is opaque (private); however, in Oracle WebCenter Framework portlets can describe public inputs (parameters) so values can be coordinated by the consuming application with other constituents of that application.
Inputs can include, public portlet parameters and private portlet parameters. These can be described as follows:
Public portlet parameters: Use public portlet parameters to pass values to a portlet. Public parameters can assist with rendering portlet content that is specific to a particular page or user. Portlet parameters are created by the component developer and then exposed to the application developer through the user interface. After adding a portlet to a page, application developers can assign values to public portlet parameters to make the information displayed in the portlet specific to the page.
Assigned values can be specific (such as a constant), a system variable (for example, the user name), or a page parameter. At run time, the portlet receives the values from the sources specified.
Private portlet parameters: Use private portlet parameters to implement internal navigation in a portlet. Parameters are passed to the portlet 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.
Note:
A Refresh action is available for inclusion on the portlet's Actions menu (
isNormalModeAvailable). It refreshes the portlet without triggering a full page refresh. See Section 4.3.3, "Setting Attribute Values for the adfp:portlet Tag" for details about setting this action programmatically.Portlets supporting public portlet parameters enable application developers to tailor data input for each portlet instance. The component developer can focus on the portlet logic, while the application developer can address the interaction between the application page and its portlets.
All portlet building technologies discussed in this chapter (OmniPortlet, Web Clipping, Oracle Portlet Factory, and programmatic portlets) support public portlet parameters. OmniPortlet and Web Clipping provide complete support through their wizard interface. Oracle Portlet Factory supports public portlet parameters through the RequestInputs API. You can get the RequestInputs object from the WebAppAccess object. You can add public portlet parameter support to your programmatic portlets programmatically or with the Java Portlet wizard.
This section describes the portlet building tools in terms of their support for private parameters.
With the OmniPortlet and Web Clipping portlets, component developers do not have access to private portlet parameters.
This section describes the portlet building tools in terms of their support for authorization functionality.
Dynamically hide and show portlets built with Web Clipping and OmniPortlet by using security managers. Although Web Clipping and OmniPortlet do not expose security managers through the user interface, they make them available for editing through their XML provider definition files.
PDK-Java provides a number of security managers for Java portlets. For example:
Group security manager: The group security manager controls access to portlets based on group membership. For example, it shows the portlet to users who are members of a specified group, and hides the portlet from non-members.
Authentication level security manager: The authentication level security manager controls access to the portlets based on authentication level. For example, it shows the portlet to authenticated users, and hides it from public users.
JSR 168 portlets support the standard servlet mechanisms.
This section describes the portlet building tools in terms of their support for other languages.
Web Clipping, OmniPortlet, and Java portlets display textual information in the language selected by the end user. Oracle Portlet Factory supports localized content through the following two Builders:
Localized Resource
Imported Page
Support for pagination is useful when a portlet must display a relatively large set of records.
This section describes the portlet building tools in terms of authentication for external applications.
Web Clipping's integration with the external application framework provides a fully automated mechanism to store passwords to external Web sites. All you must do is provide an External Application ID when registering the Web Clipping producer.
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. Credentials are stored in a secured metadata services repository.
Access to external applications is supported through a Java class Builder that interacts with the PDK-Java API. In turn, the API communicates with the external application. After the initial login to the external application, the user's login credentials are saved in a credential store, from which they are subsequently retrieved.
