This section describes the Portal Server Desktop, Search, and authentication APIs for extending your portal.
The Desktop APIs allow you to create new providers for delivering portal content to users. Conceptually, the Desktop APIs consist of Java interfaces in a “stack” as shown in the following figure:.
At the bottom of Desktop APIs, is the Provider Application Programming Interface (PAPI), a foundation that contains the interfaces, base classes, provider context, and exception classes.
As a developer, use the PAPI and extend the base classes to create new providers. For more information, see Chapters 2 to 4.
The PAPI defines the interface for implementing the provider. A provider is the programmatic entity responsible for generating channels on the Desktop at runtime. The channel properties are read from the display profile by the provider code to dynamically generate the channel content.
There is not necessarily a one-to-one mapping between providers and channels; a single provider can generate one or more channels depending on how you configure it.
The Portlet API version 1.0 is based on the Java 2.0 Platform Enterprise Edition (J2EE) version 1.3. Portlet containers and Portlets meet the requirements, described in the J2EE Specification, for executing in a J2EE environment. The Portlet interface is the main abstraction of the Portlet API.
All Portlets implement this interface either directly or, more commonly, by extending a class that implements the interface. The Portlet API includes a GenericPortlet class that implements the Portlet interface and provides default functionality. If you develop Portlets, you should extend directly or indirectly, the GenericPortlet class to implement their Portlets.
The Portlet API defines the PortletURL interface. Portlets must create Portlet URLs using PortletURL objects. A Portlet creates PortletURL objects invoking the createActionURL and the createRenderURL methods of the RenderResponse interface. The createActionURL method creates action URLs. The createRenderURL method creates render URLs.
At the next level of Desktop APIs, are the building block providers. Building block providers are those providers that are public and that you can extend to create new providers. The other providers, such as bookmark and mailcheck, are not public and are not extensible.
The building block providers in the figure are all the specific content providers (leaves) and specific container (presentation) providers that Portal Server supplies. All these public building block classes are based upon the base PAPI classes.
As a developer, you can extend the Java classes for some of the building block providers. An administrator can then use your extended classes to define channels for end user consumption.
At the top of Desktop APIs, is the Desktop servlet, which routes client requests for content and processing and passes them on to the specific provider object. The Desktop servlet processes the following actions:
Gets the named channel’s main content
Gets the named channel’s edit content
Allows the named channel to process form data
Ends the user’s session
The action is performed on the channel (for the content, edit, and process actions). The following request parameter names are reserved by the portal Desktop.
action
provider
last
containerName
targetprovider
page
error
container
selected
editChannelName
You cannot extend the Desktop Servlet.
The Provider API furnishes architectural separation from the Access Manager; but the PAPI is implemented in terms of specific Access Manager APIs within the Portal Server framework.
Typically, to create a provider, you will need to access various software services for provider development. For example, this might include attribute (property) access, session services, and client-based property retrieval. In the PAPI, these services are accessible through the ProviderContext and ContainerProviderContext interfaces. The implementation of these interfaces connects to Access Manager services in an implementation independent manner. The actual implementation of software services, for the most part, is located in another layer; the context interfaces simply pull these features together into a common interface to simplify provider development.
The Portal Server Search service provides:
C API for customizing the way the robot crawls URLs and generates resource descriptions.
Java APIs for searching the database, for submitting data, and for manipulating Search objects, such as RDs (RDM and Search APIs). C versions of these APIs are also available.
Search provider taglib and helper beans to write customized search JSPs.
The robot examines a set of selected URLs and searches for documents. For each found document, the robot then creates a resource description (RD) of the document using a predefined schema. The schema defines what pieces of information about the document are put in the RD. For example, the RD could contain a date, the author, the title, the URL, and an abstract about the document. These RDs can be grouped together or classified according to a given hierarchical taxonomy.
You can configure the robot through the Portal Server administration console.
The robot has many customizeable parameters, including the following configuration parameters:
The URLs that it starts crawling from
Server access delays
Passwords
User agent string
Certificates for SSL
Proxy setup
In addition, the robot API enables you to write custom content parsers and summarizers for special URL handling requirements. You can also use the robot API to remove advertisements, generate alerts when certain pages are found, and perform specialized logging.
The Search database consists of Summary Object Interchange Format (Search) objects. The search API creates, reads, modifies, and writes the Search database entries. Assisting APIs create buffers, set and get attribute value pairs (used to define content and metadata for the objects in the database), handle exceptions, create a Search output stream, and read a Search input stream.
Normally, the Search database can be accessed by using the Search API, but the database can also be accessed through command-line utilities. You can also add RDs that you create, or import RDs from another database.
An RD is a description of some object to include into the system. Search is the format used to represent RDs.
The Portal Server uses the Access Manager APIs for authentication, single sign-on, session, profile, and logging.
In general, most development work for a portal developer in the Access Manager area will be to customize the authentication interfaces. The following table explains the authentication development tasks and where to go for the information.
Table 1–1 Authentication Development Tasks
If you want to |
Go to |
---|---|
Change the look and feel of the authentication screen |
Sun Java System Access Manager 7 2005Q4 Developer’s Guide |
Enable or disable authentication modules |
Sun Java System Access Manager 7 2005Q4 Developer’s Guide |
Add a custom authentication module |
Sun Java System Access Manager 7 2005Q4 Developer’s Guide. By default, the Access Manager supplies authentication modules for the following types of logins: Anonymous, Certificate, LDAP, Membership, RADIUS, SafeWord, SecureID, and UNIX. |