Oracle9iAS
Portal Developer Kit
A Primer on the
PDK Provider Framework
PDK Release 2 (9.0.2 and later)
In the portal architecture, a provider is an entity that owns and manages a collection of portlets. Whenever the portal needs information about a portlet or needs to render a portlet on a portal page, it contacts the provider. In this respect, the provider acts as the link between a portal and a portlet. Providers are broadly split into two groups based on the implementation style. The implementation styles are Database and Web.
A database provider is implemented as a PL/SQL stored procedure and is installed in a portal database. The portal communicates with the provider by calling a set of well-defined procedures and functions that form the database provider interface.
A Web provider is Web-based application that communicates with the portal using the HTTP or HTTPS protocol. Since the Web provider communicates using HTTP, it can be installed on any Web application server that the portal can contact.
Because they are Web applications, Web providers are good for integrating external information sources (e.g. internet news / business information), legacy applications, and in development shops with Web development backgrounds. They eliminate the need to re-create Web sites and allow portlets to be developed using JSPs, servlets, and static files. Web providers also offer the same features as the database providers such as customization, security, etc.
One benefit of basing Web provider communication on industry standard HTTP is that you can potentially develop a Web provider using any language supported by your HTTP server. For example, a Web provider can be implemented as a cgi-bin program, a PERL script, a Java servlet, a JSP, or a Microsoft ASP. This is possible because Web providers communicate with the portal using a well defined set of APIs. All of the APIs (except rendering a portlet) are implemented using SOAP remote procedure calls (or RPCs). An RPC is similar to a normal procedure call - the primary difference being the location of the caller and callee. Rendering a portlet currently uses a standard HTTP request/response.
The drawback of this increased flexibility is increased complexity because the developer of a Web provider needs to understand how the portal "talks" to the Web provider and how it expects the Web provider to respond. The Oracle9iAS Portal Developer Kit (PDK) hides the complexity and simplifies development of Java portlets. This article describes the PDK Framework, its architecture, and how it is used to develop Java portlets.
ARCHITECTURE
The PDK has 2 primary goals:
If, for example, you have an existing Web site that comprises JSP or HTML pages, you will probably not want to create a database provider that requires PL/SQL development skills. Instead, you would rather leverage your existing JSPs, HTML pages and development skills to implement a Web provider using the PDK.
The PDK Framework can logically be split into the following areas:
Provider Adapter insulates the developer from the HTTP syntax defined by the Oracle9iAS Portal for communicating to Web providers. It translates the information passed between Oracle9iAS Portal and your Java Web provider. Without an adapter, your provider would not only manage portlets, but would also be required to communicate this information directly to Oracle9iAS Portal in the language that the portal understands. The adapter eliminates the need for your Web provider to understand the portal language and vice-versa.
Provider Interface define the APIs (functions) required by your Java implementation to integrate with the Provider Adapter. The Provider Adapter receives messages from the portal, translates them into calls to the Provider Interface and then takes the provider's response and translates the response into a format that the portal can understand. Using Java terminology, the Provider Interface is defined by a set of abstract classes. These classes define the methods your provider needs to implement and in many cases provide a standard implementation. Some of the primary classes are:
ProviderDefinition (oracle.portal.provider.v2.ProviderDefinition)
ProviderInstance (oracle.portal.provider.v2.ProviderInstance)
PortletDefinition (oracle.portal.provider.v2.PortletDefinition)
PortletInstance (oracle.portal.provider.v2.PortletInstance)
ParameterDefinition (oracle.portal.provider.v2.ParameterDefinition)
EventDefinition (oracle.portal.provider.v2.EventDefinition)
Provider Runtime provides a base implementation that follows the specification of the Web Provider Interfaces. The Provider Runtime includes a set of default classes that implement each one of the Web Provider Interfaces and allow you to leverage the rendering, personalization and security frameworks provided with the PDK. These classes and the associated frameworks simplify the development of a Provider by implementing the common functions associated with a particular Portal request and providing a declarative mechanism for configuring the provider. Using the Provider Runtime, you can focus your development efforts on the portlets themselves rather than the infrastructure needed to communicate with the portal. If the standard behavior of the Provider Runtime does not meet your requirements you can easily extend or override specific behaviors. The Provider Runtime includes a class file that corresponds to each of the Web Provider interfaces. Some of the primary classes are:
DefaultProviderDefinition (oracle.portal.provider.v2.DefaultProviderDefinition)
DefaultProviderInstance (oracle.portal.provider.v2.DefaultProviderInstance)
DefaultPortletDefinition (oracle.portal.provider.v2.DefaultPortletDefinition)
DefaultPortletInstance (oracle.portal.provider.v2.DefaultPortletInstance)
PortletRenderer (oracle.portal.provider.v2.render.PortletRenderer)
PortletPersonalizationManager (oracle.portal.provider.v2.personalize.PortletPersonalizationManager)
PortletSecurityManager: oracle.portal.provider.v1.http.DefaultSecurityManager
Provider Utilities provide methods for simplifying the rendering of portlets. The utilities include methods for constructing valid links (hrefs), rendering the portlet's container (including title bar), rendering HTML forms that work within a portal page, and supporting portlet caching.
Revision History:
November 20, 2001 created.
April 24, 2002.