2 What are Federated Portals?

This chapter presents a brief introduction to federated portals and discusses the advantages of federated portals and the kinds of problems that federation solves. This chapter includes the following sections:

• Section 2.1, "Overview"

• Section 2.2, "Basic Terminology"

• Section 2.3, "Traditional Portals: Before Federation"

• Section 2.4, "Federated Portals: A New Paradigm"

• Section 2.5, "Advantages of Federation"

2.1 Overview

A federated portal is a portal that includes remotely distributed resources, including remote portlets, books, and pages. These remote resources are collected and brought together at runtime to a portal application called a consumer, which presents the federated portal to end users. Unlike a non-federated, entirely local portal, in most cases, the individual remote parts of a federated portal can be maintained, updated, and released independently without redeploying the consumer portal in which they are surfaced.

Federated portals are:

• Distributed – Portlets are deployed on remote systems across the enterprise.

• Decoupled – The portal and its portlets do not depend upon one another. In most cases, remote portlets can be maintained and deployed separately from the federated portal.

• Collaborative – Remote portlets can communicate and share data.

• Plug-and-Play – You can easily locate and use remote portlets. Programming is usually not required to consume remote portlets.

• Standards based – WebLogic Portal federated portals are built upon open standards, such as WSRP, SOAP, WSDL, SAML, and WS-Security. WLP supports all of the required features of the WSRP 2.0 standard.

Figure 2-1 illustrates the basic parts of a federated portal: producers and consumers. A producer is a portal web application that offers remote portlets to other portal web applications, called consumers. Both producers and consumers implement a web services layer that enable them to communicate. This web services layer allows producers to offer portlets to consumers on remote systems. Consumers bring these remote, distributed portlets together at runtime. The remote portlets themselves can be developed and maintained by different groups of people. If one remote portlet on a producer is changed, other portlets within a consumer that consumes the updated portlet are not typically affected. Furthermore, the look and feel of a remote portlet can be made to be consistent with the federated portal in which is resides. To end users of federated portals, the remote portlets are indistinguishable from local ones.

Figure 2-1 Federated Portals Consume Remote Portlets from a Producer

Description of "Figure 2-1 Federated Portals Consume Remote Portlets from a Producer"

Tip:

A federated portal reflects a true Service Oriented Architecture (SOA). An SOA strategy organizes discrete functions contained in enterprise applications into interoperable, standards-based services that can be combined and reused quickly to meet business needs. As you will see, this definition of SOA describes well the essence of a federated portal.

2.2 Basic Terminology

Throughout this guide, the term remote portlet refers to a portlet that is deployed in a consumer application and that references a portlet deployed in a producer application. Another term for a remote portlet is a proxy portlet. The term proxy portlet appears in some WebLogic Portal configuration files. Please note that remote portlet and proxy portlet are synonymous. In a federated environment, a producer hosts functioning portlets, while consumer applications host proxy portlets.

2.3 Traditional Portals: Before Federation

Before federation, all of a portal's portlets were deployed within the same web application. This model works well for a portal's initial deployment, but as the portal grows the maintenance effort grows proportionally, as illustrated in Figure 2-2.

Figure 2-2 Non-Federated Portal Maintenance

Description of "Figure 2-2 Non-Federated Portal Maintenance "

Typical portal maintenance includes bug fixes, enhancements, adding new portlets, testing, and propagating the portal from a development to a staging to a production environment. Larger portals simply contain more parts, more code, which must be bound within the same portal application, and which require the coordination of developers, quality assurance engineers, administrators, and others with each update. For many organizations, the cost of such maintenance is significant and can include portal downtime. Federation simplifies portal maintenance.

2.4 Federated Portals: A New Paradigm

With a federated portal architecture, separate development teams, perhaps in separate business units, operating in different geographical locations, can focus on and develop their respective portlets. These development teams can update, test, and release their portlets independently from one another. You do not need to redeploy a federated portal every time a portlet deployed in a producer changes. When a remote portlet is updated in a producer, all of the consumers of that portlet receive the change immediately and automatically. As illustrated in Figure 2-3, the most significant benefit of a federated portal architecture is that the maintenance effort for a portal is greatly reduced compared to a non-federated portal.

Figure 2-3 Federated Portal Maintenance

Description of "Figure 2-3 Federated Portal Maintenance "

The next section further discusses the advantages of using a federated portal architecture.

2.5 Advantages of Federation

As explained in the previous section, federation offers significant benefits in portal deployment and maintenance. This section looks more closely at these and other benefits, and includes these topics:

• Section 2.5.1, "Overview"

• Section 2.5.2, "Reducing the Cost of Portal Deployment"

• Section 2.5.3, "Plug and Play SOA"

• Section 2.5.4, "Increasing the Flexibility of Release Schedules"

• Section 2.5.5, "Reducing the Cost of Testing Your Portal"

• Section 2.5.6, "Decreasing Dependencies Among Software Components"

• Section 2.5.7, "Promoting Reuse of Portal Components"

• Section 2.5.8, "Interoperability"

2.5.1 Overview

Federation represents more than just a new WebLogic Portal feature. Federation represents a new paradigm for developers and administrators of portal web applications, particularly moderate to large-scale portal web applications. Central to this new paradigm are standards, such as Web Services for Remote Portlets (WSRP), that allow portlets to be decoupled from portals. For more information on WSRP, see Section 3.3, "What is WSRP?".

Rather than bundling all of a portal's portlets into a single application, you can deploy portlets in separate web applications running on remote systems while the federated portal consumes them using WSRP. Because the federated portal is decoupled from its portlets, you do not need to redeploy the portal every time a portlet changes. For most WebLogic Portal projects, this decoupling represents an immediate and significant savings in time and money.

2.5.2 Reducing the Cost of Portal Deployment

Perhaps the most significant benefit of portal federation is this: Federated portals do not have to be redeployed when their remote portlets are updated.

In a standard portal, all portlets are part of a monolithic enterprise application. If you want to change a portlet, even make a trivial change, the entire enterprise application must be redeployed. Likewise, adding new portlets requires redeployment. Usually, portal redeployment, particularly of large-scale enterprise portals, involves expensive testing and potential downtime.

In a federated portal, remote portlets are not part of a single enterprise application. Remote portlets are deployed in separate web applications, typically, on remote systems called producers. The federated portal consumes these portlets using standard Web Services for Remote Portlet (WSRP) and Web Services Description Language (WSDL). When you change a portlet, such as by adding or removing a feature or fixing a bug, the remote portlets that reference it automatically reflect the change. You do not have to redeploy your enterprise portal application.

2.5.3 Plug and Play SOA

A federated portal is a true example of a plug and play Service Oriented Architecture. In most cases, a portal administrator can locate a remote portlet and incorporate it into a portal without enlisting the help of a developer.

2.5.4 Increasing the Flexibility of Release Schedules

Because the portlets and other services in federated portals are distributed, multiple teams can work on and deploy new features independently of one another. Before federation, different teams had to synchronize their deployment schedules and their software configurations, such as service pack releases and software library versions. With federation, independent teams can focus on producing the best possible software solutions without such tight coupling. Through the mechanism of web services, developers of federated portals simply consume the software resources produced by these independent development teams.

2.5.5 Reducing the Cost of Testing Your Portal

Portal administrators can incorporate new remote portlets into a portal by locating a producer and picking the desired portlets. From the administrator's standpoint, these remote portlets are fully tested and ready for use. No coding, testing, or complex configuration is required by the developers or administrators of the consumer portal.

2.5.6 Decreasing Dependencies Among Software Components

If a portlet relies on specific software libraries, a strong dependency exists that must be managed. Changes to either the portlet or the library version can create incompatibilities with existing code. Because remote portlets are developed, tested, deployed, and run on remote systems, a federated portal that uses remote portlets is isolated from such dependencies.

2.5.7 Promoting Reuse of Portal Components

A portlet that is exposed through a producer can be reused by any number of consumers with minimal work and no additional coding. As mentioned previously, with federation, this reuse can be accomplished without the overhead of integration, deployment, configuration, and testing that would be required otherwise.

2.5.8 Interoperability

Because federated portals are loosely coupled and standards based, it is possible for a WebLogic Portal to consume portlets from third-party vendors. Likewise, it is possible for third-party portals to consume portlets hosted in WebLogic Portal. WLP fully supports the WSRP 2.0 standard.