In the portal architecture, the portal never talks to a portlet directly. It uses an interface to an entity we call a provider that represents and manages the portlets. A provider is an entity that owns portlets. Oracle9iAS Portal uses the provider to "provide" all the information for owned portlets and drive portlet operations. The provider is the communication link between the Oracle9iAS Portal and portlets.
There are two main types of provider interfaces - Database or Web. The provider interface refers to the Implementation Style. When registering a provider, you select either "Database" or "Web" as the Implementation Style. A database provider is one that is written as a stored procedure. It is installed in the Portal. Oracle9iAS Portal communicates to the database provider by making local procedure calls.
A Web provider is one that is written as a application. It is installed and hosted in a Web server and is remote from the Oracle9iAS Portal. The Portal communicates to the Web Provider using the HTTP protocol.
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 extensive Web development backgrounds. They eliminate the need to re-create Web sites and allow development in JSP, 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 HTTP is that the provider implementer can develop in any HTTP server supported Web application language or runtime. For example, a Web Provider can be implemented as a cgi-bin program, a Perl script, a Java servlet or JSP, or a Microsoft ASP. The drawback of this increased flexibility is increased complexity. Except when the Oracle9iAS Portal requests a portlet to render itself into a page, prtal communication is primarily procedural (call/return).
To support Web Providers, Oracle9iAS Portal has had to define a syntax for representing the calls and returns that can be represented in an HTTP message. As this syntax is different from the normal request and response made by browsers to retrieve content, the above named (language) runtimes provide little support for processing the requests. To simplify developing Java Web Providers, the Oracle9iAS Portal Developer Kit includes PDK-Java ( JPDK). This article describes the PDK-Java, its architecture, and how it is used to develop Java-based portlets.
ARCHITECTURE
The Provider is the primary communication link between the Oracle9iAS Portal framework and portlets. The Web provider is a reference that Oracle9iAS Portal uses to locate and gather information on portlets stored externally.If, for example, you have a Website that is comprised of Java Server Pages (JSP) or HTML, you may not want to write a database provider to mediate between Oracle9iAS and these "Web" portlets. Instead it will commonly be more convenient to implement this provider using the same runtime as the portlets. For Java developers, the PDK-Java (JPDK) simplify the process.
The main purpose of the JPDK is to provide a framework that simplifies implementation while
representing the Provider architecture in a natural way to the Java developer. The
JPDK is composed
of four functional areas:
Provider Adapter (oracle.portal.provider.v1.http.HttpProvider) 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 Interfaces define the APIs (functions) required by your Java implementation to properly operate as part of the Oracle9iAS Portal. It defines the implementation required, but does not provide that implementation. For example, these interfaces define the Provider abstraction in Java. Each interface is a class file that defines the API requirements. The classes are:
Provider interface (oracle.portal.provider.v1.Provider)
Portlet interface (oracle.portal.provider.v1.Portlet)
PortletRenderer interface (oracle.portal.provider.v1.PortletRenderer)
PortletPersonalizationManager interface (oracle.portal.provider.v1.PortletPersonalizationManager)
PortletSecurityManager interface (oracle.portal.provider.v1.PortletSecurityManager)
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. These classes reduce the development work for a Provider by implementing the common functions associated with a particular Portal request. Used along with a declarative programming mechanism called provider.xml, the developer works by sub classing and overriding only those behaviors that need to be extended or implemented differently. The Provider Runtime includes a class file that corresponds to each of the Web Provider interfaces. These class files are:
Provider: oracle.portal.provider.v1.http.DefaultProvider
Portlet: oracle.portal.provider.v1.http.DefaultPortlet
PortletRenderer: oracle.portal.provider.v1.http.RenderManager
RenderManager has the following pluggable renderers.
oracle.portal.provider.v1.http.JspRenderer
oracle.portal.provider.v1.http.FileRenderer
oracle.portal.provider.v1.http.Servlet20Renderer
oracle.portal.provider.v1.http.JavaRenderer
PortletPersonalizationManager: oracle.portal.provider.v1.FilePersonalizationManager
oracle.portal.provider.v1.DBPersonalizationManager
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.
HttpPortletRendererUtil: oracle.portal.provider.v1.http.HttpPortletRendererUtil
For more information and in-depth descriptions of these pieces refer to the following articles:
Revision History:
June 29, 2001