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:


Revision History: