Federated Portals Guide

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Federated Portal Architecture

This chapter describes the key actors and logical parts of a federated portal and discusses how they interact. The information in this chapter informs many of the best practices recommended for developers of federated portals. It is helpful to review this chapter before reading Other Topics and Best Practices. In addition, this chapter discusses a key standard technology upon which federation relies: Web Services for Remote Portlets (WSRP).

This chapter includes these topics:


Key Actors in a Federated Portal

The key actors in a federated portal are producers, consumers, and end users, as illustrated in Figure 3-1.

Figure 3-1 Components of a Federated Portal

Components of a Federated Portal

A consumer is a web application that collects remote portlets and offers them in a unified portal to end users who use a browser to view and interact with the portal. In addition to federating portlets, WebLogic Portal lets you federate books and pages. See Federating Books and Pages for more information.

Typically, a consumer does not include the business logic, data, or user interface parts of a portlet: it simply collects user interface markup delivered from producers and presents that user interface to users.

Tip: Although most business logic processing occurs in producer applications, you can write consumer-side classes called interceptors that let you programmatically examine the content of a WSRP message and take specific action based on that content. Interceptors are discussed in The Interceptor Framework.

Consumers are administration-centric. This means that administrators, rather than developers, typically focus their time on consumers. Administrators locate and consume remote portlets, manage users, set up entitlements, and so on.

A producer is also a web application, typically running on a remote system from the consumer. The producer acts as a container for portlets that are offered to consumer portals. The producer is where the user interface, data, and business logic for remote portlets reside. While a consumer is administration centric, a producer is application centric. This means that developers write the actual portlet code and deploy those resources on producers.

Tip: All WebLogic Portal applications are, by default, both consumers and producers. This means that every WebLogic Portal application is capable of hosting remote portlets and consuming them.

For more information on producers and consumers, see Understanding Producers and Consumers.


Federating Books and Pages

WebLogic Portal has extended the WSRP protocol to include the ability to federate books and pages. This feature is useful if you have large numbers of portlets that you want to federate. You can group the portlets in books and pages in the producer application, and consume them as a group, rather than one at a time. For more information, see Creating Remote Portlets, Pages, and Books and Adding Remote Resources to the Library.


What is WSRP?

Web Services for Remote Portlets (WSRP) is a web services protocol for aggregating content and interactive web applications from remote sources. WSRP is a key standard that underlies federated portals. Essentially, WSRP allows remote, distributed portlets to be brought together at runtime into a unified portal page.

Web Services for Remote Portlets provide both application and presentation logic. This is different from standard web services, or data-oriented web services, which contain business logic but lack presentation logic and thus require that every client implement that logic on its own.

While the data-oriented approach works well in many implementations, it is not well suited for dynamically integrating business applications. For example, to integrate an order status web service into a commerce portal, you would need to write code to display the results of the status services into the portal. Using WSRP, with the presentation logic included in the web service, you can achieve the aggregation of applications and services dynamically. You no longer need to develop the presentation logic in order to do the integration; you can simply request the order status service to show up as a portlet inside the commerce portal at a predetermined location.

Tip: OASIS, the Organization for the Advancement of Structured Information Standards, is responsible for creating the WSRP standard. To read more about WSRP, including the full technical specification, go to:


One way to understand WSRP is to compare it with another web protocol, HTTP. The most familiar use of HTTP is viewing and interacting with remote web applications using a browser. Using HTTP, browsers communicate with remote HTTP servers to post data (for example, by submitting forms) and to retrieve markup (typically, HTML). WSRP is a similar protocol between server and client applications. In WSRP terminology, the server is called a producer. It hosts services, typically portlets, that clients, or consumers, communicate with.

Like a browser in the HTTP analogy, the consumer retrieves markup and submits user interactions to the producer. The producer hosts actual portlets while the consumer contains proxies for those portlets. Consumers use WSRP to collect and present markup from the remote portlets to end users who interact with that markup. To an end user, a remote or proxy portlet is indistinguishable from a local portlet.

WSRP consumers are more sophisticated than browsers, however. Unlike browsers, consumers can:

In summary, the WSRP protocol defines a set of web services that WSRP producers implement. Consumers view and interact with these web services; they retrieve user interface fragments from the producer, display the fragments, and allow users to interact with them. The WSRP protocol allows consumers to act as clients for applications hosted by producers.


Understanding Producers and Consumers

This section focuses on the producer and consumer implementations for WebLogic Portal. This section includes these topics:


A producer is a container web application that hosts portlets. Through proxy portlets (called “remote portlets” in WLP), consumers collect and present portlets hosted on producers to users. All application code (page flows, backing files, Java classes, controls, EJBs, and so on) resides on the producer. Consumers only receive fragments of markup from producers which are collected and presented to users.

Figure 3-2 illustrates the components of a federated portal. Note that the WebLogic Portal WSRP implementation allows the addition of typical WebLogic Portal services, such as personalization, customization, and user management. This means that remote portlets are given the same look and feel and the same levels of portal security as local portlets.

Figure 3-2 Web Services Between Producer and Consumer

Web Services Between Producer and Consumer

Tip: Every WebLogic Portal contains both producer and consumer implementations. That is, all WebLogic Portals can function as producers and consumers. For an in-depth technical explanation of the WebLogic Portal producer and consumer implementations, refer to the technical white paper, Inside WSRP on the Oracle Technology Network web site.

WebLogic Portal Producers

WebLogic Portal supports two kinds of producers: simple and complex. Before describing these two kinds of producers, it is helpful to understand the parts of the WSRP protocol and which operations must be implemented in a producer (required operations) and which are optional.

Table 3-1 lists the set of required and optional operations defined by the WSRP protocol. Note that the minimum requirement for a WSRP-compliant producer is to implement the required service description and markup operations. As you will see, WebLogic Portal simple and complex producers differ in the kinds of operations they support.

Table 3-1 Required and Optional WSRP Operations
WSRP Protocol
Implemented Methods
Required for WSRP
1. Service description operations
2. Markup operations
Optional for WSRP
3. Registration
4. Portlet Management
(Add new operations to the WSRP protocol.)
5. Event Handling
6. Render Dependencies

Simple Producers

A simple producer supports only some basic features of the WSRP protocol. These basic features do not require the producer to be deployed in a full WebLogic Portal domain. You can, for example, deploy a simple producer in a basic WebLogic Server domain.

Tip: For detailed information on configuring a simple producer in a WebLogic Server domain, see Configuring a WebLogic Server Producer.

A simple producer:

Despite these limitations, you might want to use a simple producer for the following reasons:

The section Using WSRP in a Basic WebLogic Server Domain describes how to configure a (non-portal) WebLogic Server environment as a WSRP producer so that you can expose portlets based on Struts or Java Page Flows. The exposed portlets can then be consumed as remote portlets running in a regular WebLogic Portal Domain.

Complex Producers

A complex producer supports the complete WSRP 1.0 protocol plus some extensions for interportlet communication, portlet look and feel, and other features. A complex producer also lets you take advantage of other WebLogic Portal features, such as personalization, customization, and user management security features. By contrast, simple producers cannot take advantage of these WebLogic Portal features.

By default, all WebLogic Portal applications are complex producers. Portlets that are exposed in a complex producer can use the APIs and features that are available in any WebLogic Portal application.

Tip: In some cases, it is inappropriate to use API calls in portlets deployed on a producer. This is because a producer does not have access to portal artifacts, such as books and pages, in that are deployed in consumer applications. See Other Topics and Best Practices for information on best programming practices for portlet development in producers.

Typically, a complex producer:

Summary of Complex and Simple Producers

A complex producer includes the required WSRP interfaces, optional interfaces, and some extended interfaces. A simple producer implements the required interfaces. A complex producer requires WebLogic Portal, but a simple producer can be deployed in a basic WebLogic Server domain. Figure 3-3 illustrates these relationships.

Figure 3-3 Simple and Complex Producers

Simple and Complex Producers

Table 3-2 compares the capabilities of standard and complex producers.

Table 3-2 Comparison of Producer Features
Complex Producer
Simple Producer
Java portlets
Page flow portlets
Not Supported
Support for URL rewriting (producer and consumer)
Support for portal administration
Support for JSP portlets
Support for backing files
Support for JSF portlets
Support for Struts portlets

WebLogic Portal Consumers

As previously noted, all WebLogic portals are, by default, able to consume portlets hosted on producers. The WebLogic Portal consumer implementation is closely integrated into the WebLogic Portal framework.

To consume a remote portlet hosted on a producer, a consumer must ask a producer for information about the portlets it offers. The consumer first contacts a producer using the producer’s WSDL URL. This initial contact verifies the availability of the producer and its services. Next, the consumer asks the producer for a description of the portlets it offers. The producer responds to the consumer with a SOAP message that describes the portlets and associated metadata that are offered by the producer. This communication is illustrated in Figure 3-4.

Figure 3-4 Getting the Service Description for a Producer

Getting the Service Description for a Producer

You don’t necessarily have to know a WSDL URL to find portlets, books, and pages deployed on a producer. WebLogic Portal includes a search feature that lets you locate portlets in producers using metadata keywords. The technology that underlies these searches is called a Universal Description, Discovery and Integration (UDDI) registry. UDDI is a widely recognized standard technology. The Administration Portal provides lets you search for portlets in a producer by name, shown in Figure 3-5.

Figure 3-5 Locating Portlets Deployed on Producers

Locating Portlets Deployed on Producers

Using this search tool, you can search for and locate producers and the portlets they offer.

After a consumer receives a producer’s metadata, the metadata is added to the consumer enabling you to create remote portlets. A remote portlet is a proxy to a portlet hosted on a producer. When a remote portlet is added to a portal or desktop, the WebLogic Portal framework uses the WSRP protocol to present the portlet to portal users. To users, remote portlets look and feel just like local portlets; users are not aware that a given portlet is hosted remotely. Furthermore, remote portlets inherit the particular styles, layouts, and themes from the portal in which they reside. To the user, this integration is seamless.

Tip: As noted previously, WebLogic Portal lets you create consumer-side classes called interceptors. Interceptors let you programmatically examine the content of a WSRP message and take specific action based on that content. Interceptors are discussed in The Interceptor Framework.

Cookie Handling

WebLogic Portal consumers handle cookies by following the prescriptions of RFC2109:

  1. A Set-Cookie response header whose NAME is the same as a previous cookie, and whose Domain and Path attribute values exactly (string) match those of the previous cookie, will replace the old cookie with the new one.
  2. If the Set-Cookie has a value for Max-Age of zero, the (old and new) cookie is discarded.
  3. Otherwise cookies accumulate until they expire (resources permitting), at which time they are discarded.
  4. Cookies are sent based on the specified request-host (including request-URI) and should be sent until they expire.
  5. In WSRP, cookies are specific to the portletHandle and the end user on whose behalf the consumer is invoking the producer and may only be resupplied for this specific pair (the portletHandle is relaxed to one from a group for cookies returned from initCookie() when ServiceDescription.requiresInitCookie=perGroup.)


Life Cycle of a Remote Portlet

A remote portlet goes through a well defined life cycle. The steps of this life cycle that are executed depend on which of the following scenarios is requested:

It is important to realize that these life cycle phases are decoupled from one another. As explained later in this section, this decoupling has implications for developers writing portlets hosted on producers. For example, you cannot expect a portal to receive the same HTTP response or request for the render phase as it receives for an interaction.

This section does not address the ways in which interceptors can influence the remote portlet life cycle. Interceptors are consumer-side classes that intercept WSRP messages and allow you to programatically take specific actions based on the content of those messages. Interceptors are discussed in The Interceptor Framework.

Tip: The information in this section informs many of the best practices for developers discussed in Other Topics and Best Practices. It is particularly important for developers creating portlets in a producer to understand the life cycle of a remote portlet. By understanding this life cycle, you will avoid making unwarranted assumptions and avoid common mistakes.

This section includes the following topics:

Tip: This section provides an overview of the remote portlet life cycle phases. For an in-depth technical review of this subject, refer to the white paper, Inside WSRP on the Oracle Technology Network Website.

Rendering a Remote Portlet

A well defined series of steps occurs whenever a remote portlet is rendered in a consumer portal. Anytime a portlet needs to be re-rendered in exactly the same state (for example, if the user simply refreshes a page), the rendering phase is executed. If a user directly interacts with a remote portlet, then a different phase, called the interaction phase is triggered. The interaction phase is discussed in the next section.

With a typical (non-federated) web application, when you send a request to a JSP, for instance, you receive back the markup for the requested page. In a federated portal, the user is viewing a page that consists of markup fragments received from portlets hosted on producers (or, possibly a mix of local portlets and portlets deployed on producers). The consumer’s job is to contact the producers, retrieve their markup, and render it in a unified portal page.

In Figure 3-6 a portlet exists on a producer, and a proxy for that portlet (a remote portlet) has been created in a consumer portal. The sequence of steps needed to render the portlet in the consumer are listed, and discussed in the following sections.

Figure 3-6 Rendering a Remote Portlet

Rendering a Remote Portlet

Initial Steps on the Consumer

To render a remote portlet, a consumer must first compose a SOAP message to send to the producer. These initial steps include:

  1. Find producer metadata.
  2. The consumer’s first job is to find the metadata for a producer. When a developer or administrator creates a remote portlet, metadata about each producer is received and stored internally by WebLogic Portal (on the consumer).

  3. Collect the portlet state. The state consists of a view state and a navigational state:
    • View state – This includes the mode (view mode or edit mode) and the state (minimized or maximized).
    • Navigational state – For example, if a user has already filled in a form and submitted it, the navigational state reflects the fact that the user has moved from page one to page two of the portlet. Knowledge of this state allows remote portlets to be re-rendered correctly any number of times.
  4. Collect all cookies.
  5. Just as a browser acts as a client to a web server, a consumer acts as a client to a producer. For example, a browser maintains cookies that keep track of sessions on the server. In the same way, a consumer maintains cookies that keep track of the producer sessions for each user of the portal. For each user interacting with a consumer, the consumer maintains one session with each producer.

  6. Create a SOAP message.
  7. All of the information gathered by the consumer must be formed into a SOAP message and sent to the producer.

Initial Steps on the Producer

After the producer receives the SOAP message from the consumer, the producer must take the following steps to render the requested portlet and return the portlet’s markup to the consumer.

  1. Set up servlet request and response objects.
  2. Establish a session.
  3. Establish the portlet state.
  4. In steps 1, 2, and 3, the producer creates an HTTP environment for the portlet. Because the producer receives a SOAP request, and not an HTTP request, the producer must take the information in the SOAP request and recreate the appropriate HTTP environment for the portlet, including such things as the servlet request and response objects, the session, and the portlet state.

  5. Enable portal API support (optional).
  6. The producer must decide whether or not to offer complex features. WebLogic Portal has implemented WSRP extensions and optional interfaces. These extensions and options allow WebLogic Portal producers to offer features such as user management, entitlements, portlet preferences, and event handling. In some cases, you may want to deploy a producer portal without these extra capabilities; therefore, the producer must determine whether or not to enable them. For more information on simple versus complex producers, see Understanding Producers and Consumers.

  7. Create a URL rewriter.
  8. In a traditional web application, URLs in, for instance, JSP pages, always point to the web server hosting the JSP page. In a federated portlet, URLs must always point back to the consumer, not to the producer. This is because the producer might, in fact, be inaccessible to the user clients. The producer may be located behind a firewall, for instance. To properly manage URLs, the producer contains URL rewriters that know how to create URLs that are consumer oriented.

    Tip: If you are developing portlets in a producer, always be sure to use WebLogic Portal APIs and tags to create URLs. These APIs and tags know how to generate URLs so that they function properly in a federated environment. For more information, see Avoid Coupling by URL.
  9. Generate markup for the portlet.
  10. At this stage, the producer renders the portlet. The producer may have created a new session for the portlet or added new cookies. The producer collects all this information and generates a response to the consumer.

  11. Collect markup and the session ID (if one was created), and send this data back to the consumer.

Final Steps on the Consumer

The consumer receives from the producer markup fragments from the producer. The consumer must take these fragments and compose them into a portal page that can be displayed to the user. To do this, the consumer takes these final steps:

  1. Collect cookies sent from the producer.
  2. Collect the session ID for each portlet.
  3. Rewrite markup (optional).
  4. Write markup to the response.

This cycle repeats each time the portlet is rendered, as long as caching is not enabled on the consumer.

Interacting With a Remote Portlet

Just as with the rendering life cycle described in the previous section, interaction with a remote portlet follows a well-defined series of steps. Interaction occurs, for example, when a user submits a form through a page flow portlet. Typically, a JSP on the producer performs some background action, such as executing business logic, and prepares a response.

As you will see, the steps taken for remote portlet interaction are similar to those taken for simple rendering. The differences are highlighted in Figure 3-7 and described in this section.

Tip: It is crucial to understand that the rendering and interaction phases of the remote portlet life cycle are decoupled. This decoupling has important consequences on how you develop portlets in a producer. You cannot expect a portal to receive the same HTTP response or request for the render phase as it receives after an interaction. For more information on this and other practical advice, see Other Topics and Best Practices.
Figure 3-7 Remote Portlet Interaction Life Cycle

Remote Portlet Interaction Life Cycle

Initial Steps on the Consumer

When a user interacts with a remote portlet, the consumer must first compose a SOAP message to send to the producer. These initial steps include the following. Steps highlighted in bold differ from the render phase described previously.

  1. Find producer metadata.
  2. Collect the portlet state.
  3. Collect all cookies.
  4. Collect request parameters.
  5. Because the user is interacting with the portlet, the request parameters must be collected and returned to the producer.

  6. Create a SOAP message.
  7. All of the information gathered by the consumer must be formed into a SOAP message and sent to the producer.

Initial Steps on the Producer

After the producer receives the SOAP message from the consumer, the producer must take the following steps to invoke the portlets action, generate markup for the requested portlet, and return the portlet’s markup to the consumer. Steps highlighted in bold differ from the render phase described previously.

  1. Receive the SOAP request from the consumer.
  2. Create an HTTP environment for the portlet.
  3. Decide whether or not to offer extended features.
  4. Create a URL rewriter.
  5. Invoke the portlet’s action.
  6. In this step, the actions submitted by the consumer must be replayed on the producer. The producer is not directly aware of where the request for this action comes from. After the business logic is executed, a page must be prepared that displays the results of the logic. For instance, if the user submitted a login form, after a successful login, the portlet must return another page that tells the user that the login was successful.

  7. Collect changes to the portlet state.
  8. After the request is processed, the producer must collect changes to the portlet’s state. This state is returned to the consumer in the form of a markup fragment that can be collected and displayed for the end user.

  9. Collect the session ID, if a new session was created.
  10. Sends the markup back to the consumer.
  11. These steps are the same as for the render phase described previously.

Final Consumer Steps

Steps highlighted in bold differ from the render phase described previously.

  1. Collect cookies.
  2. Collect the session ID for each portlet.
  3. Save portlet state changes.
  4. Portlet state information is maintained on the consumer.

  5. Rewrite markup (optional)
  6. Write markup to the response.

This cycle repeats each time the portlet is rendered, as long as caching is not enabled on the consumer.

Rendering Versus Interaction

Both the rendering and interaction phases are available to any remote portlet. The render phase is required in cases where the user does not directly interact with a portlet, but the portlet needs to be refreshed anyway. For instance, if a user interacts with one portlet on a page, she doesn’t want the other portlets on the page to change or disappear.

Because the render phase is not always driven by a user’s interaction, it is idempotent (the producer returns the same portlet state that the consumer submits). This makes sense, because if you simply refresh a page, you do not want to regenerate data from a database. Likewise, in the render phase, mode and state changes are not allowed.

Tip: Separate rendering and interaction phases are not unique to remote portlets; local portlets incorporate a rendering and interaction phase as well.

Table 3-3 summarizes the characteristics of these two phases. These two phases are decoupled so that a portlet’s state can only change if you interact with it. If, for instance, you submit a form from Portlet A, and then interact with Portlet B in the same portal page, you do not want the state or view of Portlet A to change when it is refreshed. A portlet’s state must only change if you interact with it directly. The interaction phase is always driven by user interaction, while the render phase can happen any number of times and is driven arbitrarily.

Table 3-3 Render Versus Interaction for Remote Portlets
Render Phase
Interaction Phase
Focus on presentation (view)
Focus on business logic (controller)
May be replayed several times
Driven by user interaction
  • No state/mode changes
  • No changes to portlet preferences
  • Cannot redirect the user
  • Can ask for mode/state changes
  • Can change portlet preferences
  • Can redirect users
Generates markup
Optionally generates markup.

Interportlet Communication with Events

To facilitate interportlet communication with events, WebLogic Portal extended the WSRP protocol to add a third phase in the remote portlet life cycle. This extension allows a portlet to fire an event during its interaction phase. You can register events with remote portlets; however, when a proxy portlet receives an event, it cannot process it locally because it is a proxy. The remote portlet must send the event to the producer for processing. The portlet on the producer then fires the event and the producer handles it as appropriate.

Note: The WebLogic Portal IPC framework is location independent. This means that the framework is not concerned with where an event originated. Portlets in consumers and producers can both listen for and fire events.
Figure 3-8 Event Handling Phase

Event Handling Phase

This phase is similar to the interaction phase. The primary difference is that in the interaction phase, the portlet gets the user interaction data and in response it changes the navigational state of the portlet. The portlet can also fire events.

In the event processing phase, the portlet does not receive a user interaction; rather, it always gets an event fired by another component. In response to the event, the producer can change the state of the portlet and can generate more events, which are stored in an event chain. If it generates events, then the cycle repeats.

Retrieving Render Dependencies

WebLogic Portal allows you to specify certain dependencies associated with individual portlets. Dependencies typically include Cascading Style Sheets (CSS files) and script files, such as JavaScript (JS) files. Portlet dependencies are configured in an XML file that is referenced in a .portlet file. The dependencies file explicitly lists the CSS and script files upon which the portlet depends.

WebLogic Portal has extended the WSRP protocol to allow remote portlets to retrieve render dependencies from producers.


Summary of Federated Portal Architecture

In summary, WebLogic Portal applications can act as consumers and/or producers. WebLogic Portals are configured to handle:

Figure 3-9 shows a sequence diagram depicting the flow of actions between end users, consumers, and producers. This diagram highlights the notion that a consumer acts as an intermediary between a producer and an end user.

Figure 3-9 WSRP Sequence Diagram

WSRP Sequence Diagram


For More Technical Details

If you are interested in learning more about the technical details of the WebLogic Portal implementation of WSRP, you can refer to the following:

  Back to Top       Previous  Next