In last month's article, I provided an in-depth description of the Advisor Framework that is embedded in WebLogic Portal. This month, I'll focus on describing the components, capabilities, and extensions of the Event Framework. Next month I'll look at the Portal Framework

The Event Framework is the run-time engine and framework in WebLogic Portal that provides the capability to enable Web sites to react intelligently to user interaction, to capture business relevant interaction information, and to add customized business event agents. Incorporated into the framework are the EventHandlers, EventListeners, EventService, Events, and custom JSP tags.

Business Scenarios
The main purpose in using the Event Framework is to provide business value through the intelligent use of captured user interaction information. Some of the benefits of user interaction information include initiating business-defined campaigns as the user traverses the Web site, and analyzing user interaction behavior. Each is meant to help the business understand its users and to increase the potential of online revenue.

Event Framework
The Event Framework is a configurable framework that implements J2EE design patterns, and allows the easy incorporation of custom components via XML configuration files. The main components in the Event Framework architecture are the EventService EJB, EventHandler types, EventListener types, asynchronous delivery mechanism, Event types, and JSP tag library (see Figure 1).

At a high level, the event JSP tags or a servlet life cycle event would invoke the EventService with an Event notification; the EventService would then dispatch the Event to the EventHandler; the EventHandler would request the registered EventListeners to handle the Event; the EventListeners would perform some business processing and may request additional help from the EventProcessors; and finally, the EventProcessors may perform additional processing, including calling services and frameworks that are part of WebLogic Portal (see Figure 2).

EventService
The EventService is a Stateless Session EJB that implements the "Session Facade" J2EE design pattern. The main responsibility for the EventService is to encapsulate the business processing required to implement the behavior requested by an event JSP tag call or a servlet lifecycle event. As shown in Figure 2, the EventService receives the Event from the Event JSP Tag, and requests the synchronous and asynchronous EventHandlers to dispatch the Event to the registered synchronous and asynchronous Event Listeners. No return value is returned during and after the dispatching of each event type, so exceptions will need to be thrown and caught in order to handle any business processing errors.

Standard Events
Events are Java classes that implement the "State" J2EE design pattern. The main responsibility for the Event object is to encapsulate the event information that is specific to each event type. The different types of Events that are part of WebLogic Portal include Session, User Registration, Product, Content, Cart, Buy, Rules, and Campaign Events (see Figure 3). At a minimum, each of the provided events contain information that describe the name of the application that generated the event, the time of the event, the type of the event, the Session ID, the User ID, and any other Event type-specific information.

Standard EventHandlers
EventHandlers are Java classes that implement the "Subject" participant of the "Observer" J2EE design pattern. The main responsibilities for the EventHandlers (synchronous and asynchronous) are to manage the registration of all the EventListeners and to dispatch Events to each registered EventListener. The EventHandler class manages events that are to be delivered synchronously to a registered EventListener, while the AsynchronousEventHandler manages events that are to be delivered asynchronously to a registered asynchronous EventListener.

Standard EventListeners
EventListeners are Java classes that implement the "Observer" participant of the "Observer" J2EE design pattern. The main responsibility for the EventListeners is to execute the appropriate business processing for any events that they are responsible for handling. EventListeners can either be synchronous or asynchronous. Synchronous EventListeners are registered with synchronous EventHandlers, while asynchronous EventListeners are registered with asynchronous EventHandlers. The different types of event listeners that come with the product include the BehaviorTrackingListener, DebugEventListener, CampaignEventListener, AsynchronousCampaignEventListener, and SessionEventListener (see Figure 4).

Custom Events and EventListeners
Because the Event Framework was designed to be extendable, hooks are provided for customers who wish to add their own custom Event and EventListener classes. For example, a custom event can be created to determine how often a quote tab is selected on a trading portal. Capturing this information would provide value, as the business can decide to improve the "stickiness" factor of their Web site by combining frequently used functionality onto one page or grouping commonly used functionality together.

To write a custom Event, a developer would have to extend the Event class (see Figure 3); add an event type attribute; add event attributes to be passed along to the event listener; and provide a constructor that takes in the event attributes in the argument, passes the event type to the Event class, and adds the Event attributes to the attribute list. The Event class that is being extended provides helper methods to retrieve the event's timestamp and type, and provides setter and getter methods for the event's custom attributes.

To write a custom EventListener, a developer would have to implement the EventListener interface (see Figure 4), provide a default constructor, implement the getTypes and handleEvent methods, and provide a list of Events that the EventListener is expected to react to. The Event Framework also provides the ability to dynamically determine, during the deployment and runtime stages, the events an event listener should respond to. This dynamic linkage between the many different types of Events and EventListeners provides the ability to adapt the application, via configuration changes, to meet the changing needs of the business.

After compiling the custom Event and EventListener classes, the developer should make sure to place the resulting files in the enterprise application classpath. This will insure that the custom Events and EventListeners are made available to all the Web applications in the enterprise application. More information about creating and registering custom Events and EventListeners can be found on the BEA Systems online documentation site for BEA WebLogic Portal (http://edocs.bea.com/wlp/docs70/dev/evnttrak.htm#998994).

JSP Tags
The Event Framework works in conjunction with events that are initiated during the manipulation of the Web site by the end-user. To help with the development of JSP pages that make use of the Event Framework, BEA has included custom JSP tags that instantiate Events and invoke the Event Framework. These JSP tags can be used to track user behavior, and to start promotions and campaigns.

<tr:clickContentEvent>
The <tr:clickContentEvent> JSP tag will generate a ClickContentEvent when the user clicks on an ad impression. This tag will return a URL query string that contains event parameters, which can be used to form a complete URL. This would mean that there is a two-step process when adding an ad click event JSP tag to a JSP page.

As shown below, the first step to adding an ad click event would be to execute the JSP tag in order to create the URL query string.

<%@ taglibs URI=" tracking.tld" prefix="tr" %>
.
.
.

<tr:clickContentEvent id="urlQuery"
documentId="<%=documentId %>"
documentType="<%=documentType %>"
userId="<%=request.getRemoteUser() %>"
/>

The second step would be to add the URL query string to the hyperlink that would execute the event. The example below adds the URL query string to the hyperlink.

<% finalURL = "www.bea.com/specials" + "&" + urlQuery; %>
<A HREF="<%= finalURL %>">

The "id" tag attribute contains the URL query string that is returned by the custom JSP tag and is used during the construction of the final URL string.

<tr:displayContentEvent>
The <tr:displayContentEvent> JSP tag will generate a DisplayContentEvent event when an ad impression is displayed to the end-user. As shown below, the developer would simply include the custom JSP tag when displaying the content to the end-user.

<%@ taglibs URI=" tracking.tld" prefix="tr" %>
<%@ taglibs URI=" es.tld" prefix="es" %>

.
.
.
<es:forEachInArray id="nextRow"
array="<%=ads %>"
type="com.bea.p13n.content.Content">
.
.
.
<tr:displayContentEvent
documentId="<%=documentId %>"
documentType="<%=documentType %>"
/>
.
.
.
</es:forEachInArray>

<tr:clickProductEvent>
The <tr:clickProductEvent> JSP tag will generate a ClickProductEvent event when the user clicks on a product impression. This tag will return a URL query string that contains event parameters, which can be used to form a complete URL. As with the <tr:clickContentEvent> custom JSP tag, the <tr:clickProductEvent> tag also employs a two-step process when adding a product click event JSP tag to a JSP page.

As shown below, the first step to adding a product click event would be to execute the JSP tag in order to create the URL query string.

<%@ taglibs URI=" productTracking.tld" prefix="trp" %>
.
.
.

<trp:clickProductEvent id="urlQuery"
documentId="<%=productId %>"
sku="<%=productSKU %>"
userId="<%=request.getRemoteUser()%>"
/>

The second step would be to add the URL query string to the hyperlink that would execute the event. The example below does just that:

<% finalURL = "www.bea.com/productDetails/" + "&" + urlQuery; %>

<A HREF="<%= finalURL %>">

The "id" tag attribute contains the URL query string that is returned by the custom JSP tag and is used during the construction of the final URL string.

<tr:displayProductEvent>
The <tr:displayProductEvent> JSP tag will generate a DisplayProductEvent event when a product impression is displayed to the end-user. As shown below, the developer would simply include the custom JSP tag when displaying the content to the end-user.

<%@ taglibs URI=" productTracking.tld" prefix="trp" %>
<%@ taglibs URI=" es.tld" prefix="es" %>

.
.
.
<es:forEachInArray id="nextRow"
array="<%=ads %>"
type="com.bea.p13n.content.Content">
.
.
.
<trp:displayProductEvent
documentId="<%=productId %>"
documentType="<%=documentType %>"
sku="<%=productSKU %>"
/>
.
.
.
</es:forEachInArray>

Conclusion
The Event Framework enables the creation of applications that track customer behavior and dynamically execute business campaigns. The out-of-the-box Event Framework components include event JSP tags, a runtime engine, and an extendible interface that allows the easy inclusion of custom Event and EventListener components.

The business value gained from capturing user interaction information ranges from enabling the system to intelligently react to customer interaction in order to increase the potential of a sale to providing valuable information that can be used to identify how to increase a portal site's usability and user satisfaction. The Event Framework contained in BEA WebLogic Portal provides the capabilities that enable businesses to achieve greater value from their portal implementations.