| Creation Date: | July 12, 2002 |
| Status: | Draft (1.0) |
| Version: | PDK Release 2 (9.0.2 and later) |
If you have a favorite news channel on TV, you may have also wondered if your television could track your preferences and switch to the right news channel based on who's watching it. Well, if not the television, Oracle9iAS Portal has different ways to store your preferences and other information and show you exactly what you want to see.
While building interactive portal solutions, you often need to store and retrieve different pieces of information. These may be for various purposes, for example:
Oracle9iAS Portal provides an open framework that supports different types of storage mechanisms for these needs to store information and you need to make an informed decision for choosing the optimum design for your information storage requirements. These storage mechanisms include the preference store, the session store and other application data stores.
This document will cover a design level overview about the different alternatives you have to store information using Oracle9iAS Portal:
We will also discuss some sample applications, and what kind of solution works best under each scenario.
A preference store is a mechanism for storing information like user preference data, portlet/provider settings or even portlet data, while using Oracle9iAS Portal. The information stored in the preference store is persistent in the sense that even if you logout and log back in later, you could still access previously saved preferences. The preference store maintains the user preference information and invokes the user preferences whenever the user logs in again. Apart from preferences, the preference store can be used to save other information too.
The Oracle9iAS Portal Developer Kit (PDK) provides two implementations for the preference store - one for web providers through PDK-Java, and the other for database providers through PDK-PL/SQL. The preference store implementations included with the PDK-Java allow you to save your preference data to either a file system or a database, while the PDK-PL/SQL allows you to save preferences to the database alone. Irrespective of the underlying storage mechanism, the API you use to access the preference store is similar.
The preferences stored in the Portal can be scoped at different levels. For example, the developer has an option to scope preferences at the user level (applicable to the specified user only), at the portlet level (applicable to all users of the portlet), at the provider level (applicable across the portlets of the provider) using PDK-Java. You can also choose to implement your preferences such that they are retrieved through a hierarchy of preference-scoping levels. For example consider a scenario where the user has defined a preference called 'Default Number of Records in the portlet' for an Email portlet using PDK-PL/SQL, and it is set with default values at the system and group levels. If a particular user has not defined this preference value at the user level, then the group level preference value would be used. If the group level value was also not defined, then it would default to the value from the system level preferences.
The PDK also provides a personalization framework that utilizes the functionality of a preference store to persist the data associated with the personalization functions of your portlets. Personalization is a feature of portlets that allows page designers or end users to "personalize" the information displayed in portlets. At its simplest level, personalization might let you change the title of a portlet. More complex portlets might use personalization to control how information is displayed or even what information is displayed. You can configure or personalize portlets at two levels:
Page level personalizations are established by the page designer by clicking on the Edit Defaults that is displayed next to a portlet when editing a portal page. This is commonly referred to as "Edit Defaults" because the configuration that is established is the default view of the portlet that will be seen by all users that have not established their own user level personalization for the portlet. You can prevent end user customization of the default settings by turning off end user personalization at the page region level.
User level personalizations are established by end users of the portal. Each user can click on the "Customize" link of a portlet and override the default settings with their own.
For more information on personalization, read:
To utilize the session store, you need to understand what a portal session is. When a user accesses any portal page, Oracle9iAS Portal maintains a cookie to track information about the session, across requests to the portal. A public unauthenticated session is initially created, when the user first accesses the portal. When the user logs in, this session becomes an authenticated session of the logged in user. This portal session terminates when the browser session terminates (i.e. the user closes all the browser windows), specifically logs out or or does not access the portal for a specific period of time. The timeout period is configurable. A portal session exists between the time you first accessed the portal to the time your session ends, based on any of the three possibilities mentioned above.
The session store is a mechanism that the providers can utilize to store and retrieve information that is as persistent as the portal session. This information is only available, and useful, to you during the lifetime of that session. In a similar manner, application developers may use the session store to save their own information related to the current user session. Only temporary information should be stored by application developers in the session store. Also, data in the session store can be shared across portlets.
The information stored in the session store is as persistent as the Oracle9iAS Portal session is, which is mostly the period between the login and logout by the user. If there is a need to store persistent information it should not be done in the session store; the preference store may be a better solution.
The session storage is intended for storing temporary information that is useful to the current session. For example, some common applications that you may use the session store for, are:
One thing to remember while using the session store with Web Providers is that by doing so, one creates a stateful application that needs to track state information in memory. Similarly one creates a stateful application, if one uses the file-system implementation of preference store.
If scalability is an important concern, stateful applications may have an impact on the load-balancing and fail-over mechanism for the portal configuration. This is because, even though you may deploy multiple middle-tiers accessing the same Portal instance, you would have to implement sticky routing ( where the same node is used for subsequent requests in the same session) to be able to track state. This sticky routing may result in lopsided load-balancing or loss of session data in case a node crashes, impacting fail-over. This is one reason why many developers prefer to build stateless applications. However if scalability is not a concern, then this is not an issue for you.
For more information on Session Store, read:
When you need to store information for the long term, that may also be accessed, analyzed or re-purposed by other applications, you may also choose to save such application data to your own store, possibly a database store, file system store or even an LDAP store. Alternatively, you may need to find ways of handling transient data through application-specific parameter passing.
Database Storage is flexible, since you can design your schema to make data accessible in many different ways depending on the application requirements. A single source of data can be shared by applications running on different machines, which makes it easier to load-balance. It also scales better than file system storage, but requires database access as a pre-requisite. Some issues that you need to play close attention to while designing your system include connection pooling, commits and rollbacks, avoiding hard-coded connection strings and so on.
File System Storage does not require a database. It requires a shared file system, however these generally do not scale well for large data sets. Also the data structure and data access path are fixed and inflexible. In this case file and directory privileges, flushing the buffer, overwrites etc. are issues you need to carefully consider.
LDAP Storage is not really suitable for application data. Some level of structuring is available, but is limited to hierarchical structures. It is better suited to store preferences, if the volume of data is small.
When you need to just use information that is transient, the purpose of which is solely to pass on some information to another entity, you need to consider application-specific implementations using parameters that can be passed between portlets, or within a portlet itself. Sometimes you may find yourself wondering whether you need to publish a parameter (say, by adding a name-value pair to the URL) or use a session store value to communicate transient information.
Guidelines for Parameter Passing in portlets
You may also find yourself wondering when to use the preference store, the session store or other application data stores. The following sample applications walk you through some scenarios and provide some guidelines for such decisions.
In this section we discuss some application scenarios and provide guidelines for choosing the most suitable type of information storage mechanism for that purpose.
Take the case of a News portlet that provides content from some specific URL. There are two News portlets, which are packaged as part of Oracle9iAS Portal, one that delivers product news to the Welcome page, and the other that delivers developer news to the Builder page. Similarly, If you want to build a URL portlet that can be customized by end-users to point to any URL to deliver its content, you could implement end-user personalization by using the preference store. The users' favorite news URL will be saved to the preference store, and they will view their favorite news every time they log in. If their preference changes to another news site, they can just customize their portlet accordingly.
You will observe that the same News portlet is capable of displaying different types of news. This portlet can be personalized both at the page level and the end user level. For example, this portlet could be placed on three different pages:
Oracle9iAS Portal provides two special show modes to deal with portlet personalization - the Edit mode, and the Edit Defaults mode.
A portlet uses edit defaults mode to allow administrators to customize the default behavior of a particular portlet instance. Edit defaults mode provides a list of default customization settings that can be modified to change the appearance and content of that individual portlet for all users.
Page administrators access Edit Defaults from the Edit Page screen. The link is labeled "Edit Defaults" on the banner of the wire frame diagram of that portlet. If you are end-user and you have customize page privileges, then you can add new portlets to the page and access Edit Defaults for the portlets you add. You cannot access Edit Defaults for portlets that were already part of the page. The users are taken to a new page in the same browser window when they click on this link. The portlet typically creates a page representing a dialog box where you specify the default settings for the portlet instance. Once the settings are applied, the users are then automatically returned to the page from which they came.
The configuration that is established is the default view of the portlet that will be seen by all users that have not established their own user level personalization for the portlet. You can also prevent end user customization of the default settings by turning off end user personalization at the page region level.
Guidelines for Portlets in Edit Defaults Mode
Portal users typically access a portlet's edit mode by clicking the Customize link on the portlet banner. The users are taken to a new page in the same browser window when they click on this link. The portlet typically creates a web page representing a dialog box where the portlet settings can be customized. Once the settings are applied, the users are then automatically returned to the page from which they came. Should the portlet banners be turned off, you can also access edit mode from the Customize Page screen when you click the Customize link. The link is labeled "Customize" on the banner of the wire frame diagram of that portlet.
User level personalizations are established by end users of the portal. Each user can override the default settings with their own.
With both the Edit and the Edit Defaults mode, it is preferable that you use the preference store to save user preferences in the portal repository, since the preference store is tightly linked with the provider infrastructure. However you may also choose to implement your own version of the preference store, by using other types of application data stores for saving user preferences. Issues that you would need to consider include preference scoping at different levels, duplicating preference data, when users try to copy the portlet ( say by copying the page through the Portal wizards), or packaging such data so that they can be easily exported/imported along with portlets they are associated with.
Guidelines
for Portlets in Edit Mode
Take the case of any application that lets users configure some setting for the current session. For example, if you were building a shopping cart portlet that allows a user to buy some items and put them on the shopping cart, you may want to use the session store to keep track of all the current items on the cart.
You need to understand the requirements in detail to decide whether to use session or preference store. In the above stated example, if you think that the users may need the flexibility to put items on their shopping cart across multiple sessions, and finally check out their purchases, you may choose to use the preference store for tracking the items on the cart. You may also decide that your shopping cart is a complex data structure that needs a more specific application data store, instead of using the preference store's set of name-value pairs.
Suppose you need to collect feedback from your users and analyze that feedback, you may consider storing that information to your own database tables. If you're building a Java or JSP portlet, you can make JDBC calls to access your database and save/retrieve information. Once the information is in your own tables, you have permanent access to all the information on which you can run reports, and even use Oracle9iAS Portal's reporting capabilities to analyze that information.
The PDK provides a feedback sample that makes use of JDBC calls to save information to the database.
In this type of scenario, using the preference store or the session store, may not be appropriate.
You may need to develop a portlet that takes the user through multiple paths depending on their inputs. Suppose you're building an application for selling apparel online, your portlet may need to take inputs for the user's name, age, sex, and waist size, and accordingly render items from different categories (men's, women's, kids', plus size etc.). In this case, you may choose to implement this as a multi-screen JSP portlet, with a Next button on each JSP that links to the next JSP based on the user's inputs. In such a case, your user's inputs may be saved to the preference store or session store (based on your requirements), and the next JSP would render content based on the saved information.
Another way to go about this is to pass the user's inputs as parameters to the next screen. Using parameters is preferable in the case you do not need to keep the users input for any future use, and if it is solely for communicating transient information. For example in this shopping cart sample, parameters are used to pass on information from the check out screen to the shipment confirmation screen.
 |
Another type of application may require one master portlet to drive other portlets that render details for the master key. In such a case, you would just use parameter passing between the portlets and not bother about saving that information to the preference or session store at all.
One thing to remember is that while using parameters, since the caching key includes the URL (which in turn includes the parameter), a new cache key is created for every new parameter value. This causes more cache versions than necessary. Another aspect is that you need to watch out for parameters that may continue to stick (the name-value pair appears on the URL, even after it has been processed), sometimes due to incorrect resetting of the parameter values. For example, while using parameters to choose tabs on a page, which are also interlinked in other ways, the values may not get properly reset based on user's actions. This might happen when you navigate between the tabs using the links, instead of by clicking on the tabs themselves. Your application must take these possibilities into account while considering the most suitable form of information storage. Sometimes, you may also decide to use the session store instead of using parameter passing to bypass such complications.
Ultimately, your choice of the type of information storage depends on the nuances of your specific application. Oracle9iAS Portal provides support for all these different types of storages so you can build an optimum solution.
| Revision History: |
|
| Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065, USA http://www.oracle.com/ |
Worldwide Inquiries: 1-800-ORACLE1 Fax 650.506.7200 |
Copyright and Corporate Info |