To Oracle9iAS Portal, a Web Provider is a server-side Web program that responds to a well defined set of requests. Some requests are for information, such as requesting the list of portlets managed by the provider, or the capabilities of a particular portlet. Other requests are directive, such as directing a portlet to render itself in a particular mode.
As we learned in the previous article, Understanding the Provider Adapter, PDK-Java removes the mechanics of processing the HTTP communication with Oracle9iAS Portal from the function of the provider. PDK-Java offers a Provider Adapter to process this HTTP communication. This allows the Web Provider to communicate entirely in Java. To allow the Provider Adapter to translate the information coming from the Web Provider, the provider must follow a set of specified functions. Specifying the functions required by a Web Provider is handled by the Web Provider Interfaces.
This article introduces you to the set of interfaces you will use as a guideline to implement your portlets and provider. Once you have finished this article, be sure to read the article Understanding the Provider Runtime. The Provider Runtime supplies a complete set of base classes that implement the interfaces described herein. In most circumstances they will be your starting point and greatly reduce the programming needed to develop your portlets.
ARCHITECTURE
Oracle9iAS Portal defines the provider model. A provider is the entity that manages a specific set of portlets. It is capable of responding to each of the Portal's requests. In a sense, the provider is a gateway between the Oracle9iAS Portal and the portlet. This relationship exists for two reasons. First, its allows the Portal architecture to separate its communication requirements from the implementation of the portlet. For example, a portlet should be free to be implemented in whatever component model deemed most appropriate. The provider translates between the Portal requests and the portlet's model. Secondly, the Portal relies on the provider to supply the shared functionality of its portlets. For example, the HTTP session is established and maintained by the provider on behalf of each of its portlets.
Oracle9iAS Portal sends two types of requests to the provider: query and directive. The query request asks for information about the provider and its portlets. The directive request instructs the provider to perform a specific operation. From a logical perspective the query request asks the provider to:
list portlets: return a description of all the portlets managed by this provider.
get portlet: return information about a specific portlet managed by this provider.
register and deregister the provider: informs the provider that it has been (newly) registered in a Portal or subsequently removed from the Portal. This occurs when the administrator uses the "Register a Portlet Provider" screen to add/remove a provider.
register and deregister a portlet: informs the provider that a new portlet instance has been created or subsequently removed. This occurs when a user adds a portlet to a page.
copy portlet: informs the provider to make a copy of a portlet instance
initialize session: informs the provider that it is about to be used in a new user session.
This was done to better articulate the various abstractions in the provider model, as well as to separate the pieces of the model into discrete components. This makes it easier for the PDK-Java Runtime to provide default implementations that can be easily used by the developer. In other words, this design allows you to only worry about the specifics of your application, usually just the portlet's rendering method.
The greatest separation occurs in the interfaces that model a portlet. Rather than one portlet interface there are eleven:
Note: these interfaces are defined in the package oracle.portal.provider.v1
ManagedRenderer: a controller used in conjunction with RenderManager to construct a correctly ordered response to a PortletRenderRequest.
MLString: MLString is a multi-language string.
MobilePortlet: aMobilePortlet has the ability to render contents for
MODE_LINKand control how its meta data information is requested.MutableMobilePortlet: a MutableMobilePortlet is a MobilePortlet which can be modified, either by direct calls or a suitably configured provider.xml.
MutablePortlet: defines a portlet whose meta-data values can be set.
PersonalizationObject: interface for data objects managed by a PortletPersonalizationManager
Portlet: represents the static (meta) data that describes a portlet and its capabilities.
PortletPersonalizationManager: implements creating, setting, and retrieving the customization data for portlet instances. It creates, sets, and retrieves the customization data for a PortletReference.
PortletRenderer: implements the rendering of this portlet's instances. It renders a PortletReference.
PortletRenderRequest: The PortletRenderRequest contains all the request details a renderer needs to process the request and output its rendition.
PortletSecurityManager: authorizes the current users accessibility to either the portlet as a whole, or a particular portlet instance.
This complexity of the interfaces exist because Oracle9iAS Portal doesn't distinguish between customized views of a particular portlet instance. When it assembles a page, the Portal can identify each portlet instance that is on the page as well as the current user. It relies on the provider and portlet to make the necessary association between the instance and the user to operate on a particular customized view.
This is further complicated by the current Oracle9iAS Portal convention that if a user doesn't have a customized view for a portlet instance, the user should receive the customized view of the default user. Said differently, the Portal currently supports two levels of customizations: user level and default level. The default customization (typically set by the page owner or administrator) is shown to all users.
To better support this model, the portlet API is represented using a controller model instead of an object model. In a controller model, a specific function is implemented by a single controller. The controllers operate on the behalf of an object. The object represents the identity of what is being operated on. In an object model, the object both represents the identity of what is being operated on as well as the operations itself.
For the portlet API, the PortletReference is the object that represents the identity of what should be operated on. The PortletRenderer, PortletPersonalizationManager, and PortletSecurityManager are the controllers that perform the function of rendering, managing user customizations, and authorization. The portlet interface groups the controllers together making them accessible to the provider and each other. It also maintains the static meta-data required by the Portal to properly present to the user.
The provider interface (oracle.portal.provider.v1.Provider) wraps portlets. The provider manages a set of portlets. Methods include:
Of the above, the getPortlet() method is the key. Only the provider is explicitly related to the Provider Adapter. When a Portal request is received by the adapter that targets a portlet (for example, requests a portlet instance to render), the adapter calls the getPortlet() method using the portlet identifier passed in the request. From the portlet, the adapter is able to acquire the specific controller it needs to direct (in this case a PortletRenderer). Using additional information in the Portal request, the adapter instantiates a PortletReference object representing the instance being operated on. It then calls the appropriate controller method to affect the desired behavior.
getPortlets: returns the set of portlets managed by this provider.
getPortlet: returns a specific portlet by reference.
initSession: allows the provider to initialize session state (that is maintained by cookies) on behalf of the portlets.
Register: indicates that this provider has just been registered with a Portal. One time initialization, including enabling subscription billing, is processed here.
- deregister: indicates that this provider has just been removed from a Portal. One time cleanup, including disabling subscription billing, is processed here.
Each of these interfaces is covered in more detail in their corresponding JavaDoc.
Revision History: