Feature

Digg This!

Page 2 of 4   « previous page   next page »

Portlet, WSRP and JSR-168 Overview
Portals are comprised of portlets that get aggregated together onto a web page. A portlet, which functions as an application, occupies a rectangular region on a page. It is analogous to a desktop application. Portlets, like desktop applications, can be maximized or minimized. It runs inside of a portal server, which is used to manage the lifecycle of a portlet and invoke its methods. It can be written in many different languages, although Java and C# are the most common.

WSRP
Web Services for Remote Portlets (WSRP) defines a standard set of Web Service interfaces that allows a portal server to access interactive, presentation-oriented Web Services. That is, a portal server wraps one or more of its portlets using a Web Service interface and makes the interface available to other portal servers. This leads to federated portals, where a portal can consist of a combination of local and remote resources. One of the primary benefits of WSRP is that it reduces the cost of deployments, since changes to a portlet on a remote server are automatically picked up by a client server, without redeploying the client's portal application.

A WSRP Web Service isn't your garden variety Web Service, which is purely data-oriented. Normally, a client application invokes a Web Service operation and gets some data back. It's the responsibility of the client to render the data as it sees fit. On the other hand, a WSRP Web Service is presentation-oriented. This means the Web Service includes both application logic and business logic. Furthermore, it means that rendered data, representing a portlet, is returned as markup. Consequently, it's no longer the responsibility of the client to do the rendering. Hence, WSRP leads to a more plug-and-play solution than traditional Web Services.

WSRP Actors
WSRP defines three actors, two of which we normally use when describing the Web Service architecture: (See Figure 1)

• Producer - A provider of portlets that are to be shared
• Consumer - A user of a shared portlet. Aggregates the portlets from one or more Producers and serves them to an End User.
• End User - A portal user. Interacts with a Consumer.

It's important to mention that a single portal server can function as both a producer and a consumer. For example, a consumer can aggregate both producer portlets and locally deployed portlets (local portlet) onto the same page. What's great about WSRP is that an end user can't distinguish between a shared portlet and a local portlet.

Before we move on to the meat of this article, it's important to get our terminology straight. A portlet that is shared by a producer is referred to as a producer-offered portlet. Producer-offered portlets are pre-configured and can't be changed by a consumer.

The consumer uses proxy code to communicate with a producer. Vendors normally refer to the proxy code as a proxy or remote portlet. For those familiar with distributed object computing (e.g., CORBA, DCOM, RMI, EJB), a proxy portlet is analogous to a stub. The portlet referenced by the proxy portlet is analogous to a remote object. The stub serves as a proxy, or a fill-in, for the remote object.

WSRP Producer Interfaces
A producer provides a set of Web Service interfaces for the portlets it provides, two of which are mandatory and two of which are optional:

• Service Description - A required interface that allows a consumer to obtain metadata about the producer, including a description of all of the producer-offered portlets.
• Markup - A required interface used to request markup fragments for a producer-offered portlet and interact with that markup.
• Registration - An optional interface that lets a producer keep track of its consumers. If a producer supports this interface, a consumer must register with a producer first before it can discover and access any of its portlets. After registering a consumer, a provider supplies the consumer with a unique identifier (registration handle) that it must pass back to the producer for any subsequent requests. If a consumer is deregistered, the producer can remove all instances of the portlets used by that consumer, leading to better memory management.
• Portlet Management - An optional interface that provides the consumer with access to the lifecycle of the producer offered portlets and their persistent state. Specifically, it lets a consumer get portlet metadata, clone portlets for customization purposes, and retrieve/update the portlet's properties (e.g., modify portlet preferences).

JSR-168
As mentioned, WSRP is platform- and language-independent. Consequently, it can be used to integrate portlets using .NET, Java, or some other technology. In our case, we'll focus on portlets written using Java, specifically JSR-168.

Otherwise known as the Java Portlet Specification, JSR-168 allows for the creation of portable portlets. Portlets written to this specification are often referred to as standard portlets and can run inside of any JSR-168-compliant portal server. Both WebSphere Portal and WebLogic Portal support JSR-168 (this will soon be supplanted by JSR-286, which is essentially version 2.0 of JSR-168).

Integrating WebLogic and WebSphere Tutorial
Next, I'll demonstrate how to configure WebLogic Portal and WebSphere Portal, two popular portal server products, to communicate using WSRP. I'm using WebSphere Portal 6.0 and WebLogic Portal 9.2, although both vendors support WSRP 1.0 in prior versions of their products too. The latest version of WSRP is version 2.0.

Here I'll focus on the first of two scenarios:

• WebLogic Portal acts as a consumer and WebSphere Portal acts as a producer
• WebSphere Portal acts as a consumer and WebLogic Portal acts as a producer

I assume basic administration skills when it comes to using WebLogic Portal and WebSphere Portal. Both products offer a Web-based administration console that can be used to administer a portal, including configuring WSRP. The biggest difference between the two products is WebLogic has a separate administration console for every portal application, whereas WebSphere has only a single administration console for all portal applications.

Page 2 of 4   « previous page   next page »