This series of articles focuses on demystifying the frameworks embedded in the BEA WebLogic Portal. The first framework that will be discussed in-depth is the Advisor Framework, followed in future articles by the Event Framework and the Portal Framework.

The Advisor Framework is designed to be an adaptable engine with plug-in points for extending WebLogic Portal's personalization functionality. The main components in the Advisor Framework are the Advisor, AdvisletRegistry, and Advislet classes; the JSP tags; and the Advislet XML Registry. This article will discuss each component, take you through the framework execution scenario, and explain how to implement and configure a custom Advislet.

Advisor Framework
The key Java components in the Advisor Framework are the Advisor stateless session EJB, the AdvisletRegistry static class, and the different types of Advislet objects (see Figures 1 and 2). At a high level, the personalization JSP tags or a fat Java client would invoke the Advisor with a personalization request; the Advisor would then request the appropriate Advislet from the AdvisletRegistry. After receiving the Advislet, the Advisor would validate the minimal existence and correctness of the request information to ensure that the required data is available to the Advislet. The knowledge concerning what data the Advislet requires is contained within the Advislet itself and is requested by the Advisor during the data validation check. After validating that sufficient data is available, the Advisor requests that the Advislet perform its specific personalization task and return an Advice object that contains the results of the processing. To accomplish the appropriate functionality, the executing Advislet would make use of the different portal services such as the Rules Manager, User Profile Management, and Content Manager.

Advisor
The Advisor is a stateless session EJB that implements the Session Facade J2EE pattern. The Advisor's main responsibility is to encapsulate the business processing required to implement the behavior requested by the personalization JSP tag or fat Java client. As shown in Figure 2, the Advisor gets the Advislet from the AdvisletRegistry, validates the minimal existence and correctness of the request data, and executes the Advislet. After successful completion of the process, an Advice object is returned to the calling client.

AdvisletRegistry
The AdvisletRegistry is a static class that contains the knowledge of how to parse the URI string being sent by the client and which AdvisletChainElement type to retrieve from its collection. The AdvisletRegistry class also performs the registering and unregistering of the Advislet and AdviceTransform types specified in the "advislet-registry.xml" file into its internal store. The registry pattern used here provides the flexibility of modifying personalization behavior assigned to specific "tags" without requiring the redevelopment of existing code.

Advislet
Advislets are command objects responsible for interacting with the appropriate services to perform the required personalization task. Out of the box, there are Advislets to classify users, perform documentation searches, and do rules-based matching of user profile information and tagged content. Custom Advislets can also be written to perform specific value-added actions. To write a custom Advislet, you have to implement the Advislet interface and provide implementations for the getAdvice, getRequiredAttributes, and validateAdviceRequest methods (see Figure 3). An abstract class, AbstractAdvislet, is provided to help in the development of custom Advislets. To use the AbstractAdvislet class, simply extend the class, override the getAdvice method, and implement a constructor that takes both the Advisor and metadata objects as arguments. The Advisor argument is a reference to the Advisor creating this Advislet, and the metadata argument is a reference to an object containing the Advislet's name, description, and version information as specified in the Advislet XML Registry.

CompoundAdvislet
Although the CompoundAdvislet interface is shown in Figure 3, you shouldn't implement this interface or extend the provided CompoundAdvislet implementation. This aspect of the Advislet hierarchy is included simply to inform you that Advislets and AdviceTransforms can be chained together to form a sequence of interlinking components. If executed, the CompoundAdvislet implementation would request the AdvisletRegistry for each Advislet and AdviceTransform, in the sequence specified in the "advislet-registry.xml" file. The pipe-and-filter pattern used here allows you to develop Advislet and AdviceTransform classes that are independent of each other and link them together to provide a complex personalization process. Additionally, this pattern increases the potential for reuse and adaptability.

AdviceTransform
AdviceTransforms are data-mapping objects responsible for mapping the output results from one Advislet to the input parameters for the next Advislet in the sequence. To write a custom AdviceTransform, a developer would have to implement the AdviceTransform interface and provide an implementation for the transform method (see Figure 3). An abstract class, AbstractAdviceTransform, is provided to help in the development of custom AdviceTransform implementations. To use the AbstractAdviceTransform class, simply extend the class, override the transform method, and implement a constructor that takes both the Advisor and metadata objects as arguments. The Advisor argument is a reference to the Advisor creating this AdviceTransform, and the metadata argument is a reference to an object containing the AdviceTransform's name, description, and version information as specified in the Advislet XML Registry. Out of the box, there are AdviceTransform types to transform standard objects into input objects for the rules engine, the output of the rules engine into the input object for content query, and the results of a classification into the input object for content selection.

Advislet XML Registry
The Advislet XML Registry contains a listing of all the required Advislet and AdviceTransform elements, their descriptive and configuration information, and the sequence logic for CompoundAdvislets. The information contained in the Advislet XML Registry file is the same information that's loaded in the local store of the AdvisletRegistry class and is scoped to the containing application. To register a custom Advislet in the XML file, simply open the "advislet-registry.xml" file found in the "ejbadvisor.jar" file and add the appropriate lines, making sure to follow the XML Schema provided. The example shown in Listing 1 adds a custom Advislet called MyAdvislet to the registry file.

To register a custom CompoundAdvislet in the XML file, open the same "advislet-registry.xml" file and add the appropriate lines, again making sure to follow the XML Schema provided. The example shown in Listing 2 first adds a custom AdviceTransform called MyAdviceTransform before adding a CompoundAdvislet called MyCompoundAdvislet to the registry file. Notice that the sequence elements of the CompoundAdvislet group list the Advislet and AdviceTransform classes to call and the sequence in which to execute them.

JSP Tag Library
Three JSP tags are pertinent to the Advisor Framework: <pz: div>, <pz:contentQuery>, and <pz:contentSelector>. These tags allow JSP developers to access the personalization features of WebLogic Portal without having to write EJB client code. (For more information on the parameters for each JSP tag and for the entire WebLogic Portal JSP tag library, visit the BEA online documentation Web site: http://edocs.bea.com.)

<pz:div>
The <pz:div> JSP tag provides the functionality to wrap JSP code segments within a business rule that is dependent upon profile information. That is, a business rule can be called to allow the execution of a JSP code segment within a JSP file only when the profile information matches the business rule requirements. In the example below, the JSP contents contained within the opening (i.e., <pz:div>) and closing (i.e., </pz:div>) tags will be executed only if the rule evaluates to TRUE.

<%@ taglibs URI="pz.tld" prefix="pz" %>
.
.
.

<pz:div rule="JavaDeveloper">
<p>This section will be displayed if the
user's profile has developer=java </p>
</pz:div>

This personalization feature allows the runtime dynamic determination of static content and functionality to be displayed to the user.

<pz:contentQuery>
The <pz:contentQuery> JSP tag provides the functionality to search for tagged content stored in the third-party content management system, which has been integrated into WebLogic Portal using a published content management system SPI. In the example shown in Listing 3, a result set of content objects will be returned that contains information matching the query string "title='WebLogic Developers Journal'"

This feature provides JSP developers with the ability to dynamically retrieve content contained within the integrated content management system.

<pz:contentSelector>
The <pz:contentSelector> JSP tag combines the functionality of the <pz:div> JSP tag with a content query rule. That is, two actions will occur in sequence when this JSP tag is used, where the second action is dependent upon the first action evaluating as TRUE. In the first action, the Advisor Framework will execute a classification rule that will determine if the profile requirements are met. In the second action, the Advisor Framework will execute a content query rule that will return a result set of content objects that match the query string contained within the rule. In the example shown in Listing 4, a result set of content objects will be returned if the personalization rule evaluates that the profile requirements have been met and that there is tagged content in the content management system that matches the rule's content query string.

This feature provides the ability to decouple the personalized content query logic from the JSP UI development layer. JSP developers can focus on developing UI logic, while the underlying Advisor Framework can focus on performing the required content personalization aspects.

Conclusion
The Advisor Framework enables the creation of an application that allows business rules to drive the presentation of content and functionality to the right person at the right time. The out-of-the-box Advisor Framework components include personalization JSP tags, a runtime engine, an XML Advislet configuration file, and components that classify users, enable documentation searches, and perform rules-based matching of user profile information and tagged content. In addition, the framework also provides an extendable interface that allows the easy inclusion of custom personalization components.