Chapter 15. Web Services for Remote Portlets (WSRP)

This chapter covers

• WSRP concepts
• Publishing portlets as a service
• Consuming remote portlets as a service

Just as you’d expect, a web service is a service that’s accessible over the web. HTTP and XML form the backbone of web services, which fact makes them platform and language independent. Web services provide the means to achieve SOA (service-oriented architecture)—an architectural approach in which systems are composed of loosely coupled services.

In the context of SOA, a service refers to a functionality of value to the consumer of the web service. Amazon’s Fulfillment Web Service (Amazon FWS) is a good example of this concept. This feature allows merchants to request Amazon to physically fulfill customer orders on their behalf: Amazon does the work for a small fee, and you reap the benefits of not having to lug your stuff to the post office and fulfill orders on your own. Web services are data-oriented services—they process requests and return data. This puts the burden on web service consumers to provide presentation logic for the web service.

Web Services for Remote Portlets (WSRP) is an OASIS specification that defines presentation-oriented web services that not only provide data but also the presentation logic. This makes WSRP ideal for incorporating content from different data sources without writing a single line of code. Because WSRP is an extension of data-oriented web services, this chapter assumes that you’re conversant with web service concepts.

What does all this have to do with portlets? Let’s say that an online seller allows merchants to sell their products by publishing product details on the seller’s website. This seller provides a Sales web service to its merchants that can be used to add, view, and modify product details. The merchant is responsible for creating a user interface to interact with the Sales web service, allowing its users to add, view, and modify the product details. Figure 15.1 shows the role played by a web service and its client in a scenario where the web service provides only the business logic, and the client is responsible for providing the user interface and presentation logic for interacting with the web service.

Figure 15.1. The web service provides the business logic, and the web service client provides the user interface and presentation logic.

The downside of this approach is that the merchant is able to use the business logic provided by the Sales web service, but they need to write the presentation logic and user interface to present the data returned by the web service. Instead of providing a Sales web service, if the seller provides a WSRP-compliant portlet, the merchants would simply need to add these portlets, as they would any other locally developed portlet, to their web portal.

Figure 15.2 shows the scenario in which a WSRP-compliant Merchant portlet is provided by the seller. In this figure, the seller publishes a Merchant portlet via a WSRP producer, and the portlet is consumed by a WSRP consumer of the merchant’s portal server. The merchant adds the Merchant portlet to their web portal as if it were locally deployed. The WSRP consumer retrieves markup and data for the Merchant portlet from seller’s portal server by interacting with the WSRP producer. Also, when users interact with the Merchant portlet, the user interaction is dispatched to the WSRP producer by the WSRP consumer for processing. We’ll discuss WSRP producers and consumers in detail in the next section.

Figure 15.2. The seller publishes a Merchant portlet that merchants add to their web portal. The WSRP producer and WSRP consumer act as publisher and consumer of the Merchant portlet, respectively.

You can think of WSRP as a standard that lets you publish a portlet as a service. In this chapter, we’ll discuss WSRP and look at how portal servers’ WSRP administration features simplify both publishing and consuming portlets. We’ll also look at how you can use the WSRP administration features available in Liferay Portal to publish and consume some of the portlets that we developed in previous chapters. The OpenPortal WSRP implementation is also covered in the context of WSRP’s registration and leasing concepts.

 

Note

OASIS released two WSRP specifications: WSRP v1.0 and v2.0. WSRP v2.0 introduced features like inter-portlet communication, caching, and resource serving, which are aligned with the Portlet 2.0 specification. In this chapter, we’ll focus on WSRP 2.0 because it complements the features supported by Portlet 2.0–compliant portlet containers.

 

Let’s begin by looking at how WSRP works behind the scenes to publish a portlet installed in a portal server as a web service, and to consume this web service to access the portlet.

15.1. What makes remote portlets a reality?

WSRP defines two key actors—producers and consumers. A producer is part of the portal server that wants to publish its portlets to the external world as presentation-oriented web services. The portlets published by a producer are referred to as remote portlets. A consumer is part of a portal server that intends to use remote portlets (portlets published by producers). You can think of a producer as a web service endpoint and a consumer as a web service client. We’ll shortly see that producers expose multiple web services, which are used by consumers to interact with remote portlets.

 

Note

The intent of the Portlet specification is to build portlets that behave consistently across compliant portlet containers, and WSRP deals with publishing and consuming portlets, irrespective of the technology used to develop them. WSRP isn’t specific to a particular technology; you can have a WSRP-compliant consumer written in Java for consuming portlets published by a WSRP-compliant producer written in .NET.

 

Figure 15.3 shows the role played by producers and consumers in WSRP. Obviously, there’s a lot going on in this figure. Let’s walk through it together. Portal server A aggregates content from portal servers B and C. Because portal server A consumes portlets from B and C, it hosts the consumer. Because portal servers B and C publish portlets for use by portal server A, they host the producers. The producers act as containers for portals B and C’s portlets and are responsible for managing their lifecycles.

Figure 15.3. Producers and consumers communicate with each other to make remote portlets a reality. A consumer communicates with remote portlets using portlet handles.

 

Note

It’s possible for a portal server to act both as a publisher and consumer of portlets, in which case, it contains both consumer and producer applications.

 

In Figure 15.3, the web portal (hosted by portal server A) shows remote portlets B1 (from portal server B) and C1 (from portal server C) and the local portlet A1. To use remote portlets, the consumer registers (if required) with the producers and holds references to the remote portlets, also referred to as portlet handles. Remote portlets C1 and B1 are registered with portal server A with local names X and Y, respectively. When the user interacts with portlet X or Y, the interaction is passed to remote portlet B1 or C1 via the portlet handle.

You can think of a producer as a bank, with portlets published by producers being bank accounts, portlet handles being ATM cards issued by the bank, consumers being ATM machines, web portals being the user interfaces presented by ATM machines, and web portal users being bank customers. In Figure 15.3, the web portal user (bank customer) interacts with portlet X or Y displayed by the web portal (ATM machine’s user interface). The consumer (ATM machine) makes use of the portlet handle (ATM card) to interact with the producer (bank) to invoke remote portlet B1 or C1 (bank account) for processing a user interaction.

Figure 15.3 also shows that portal server A has a local portlet A1 that communicates with the consumer. The consumer is responsible for mediating communication between the local portlet A1 and locally registered remote portlets B1 and C1, making it look like the remote portlets B1 and C1 are also local to portal server A. As in the case of local portlets, you can use portlet events or public render parameters for communicating between remote portlets and local portlets or between remote portlets from the same or different producers.

The WSRP specification defines multiple web service interfaces that a producer implements to allow consumers to interact with portlets published by the producer. Table 15.1 describes both the mandatory and optional web service interfaces that a WSRP producer implements.

Table 15.1. Web service interfaces implemented by WSRP producers

Web service interface	Description
Service Description	A mandatory interface that allows WSRP consumers to discover information about the portlets hosted by the producer. Additionally, it provides information on how consumers can register with the producer and interact with the portlets hosted by the producer.
Markup	A mandatory interface that allows WSRP consumers to interact with the portlets hosted by WSRP producers.
Registration	A WSRP producer may require WSRP consumers to register with it to interact with the portlets it contains. The Registration interface is an optional interface that allows WSRP consumers to register with WSRP producers that implement it.
Portlet Management	As the name suggests, this interface allows WSRP consumers to manage the life-cycles of portlets hosted by WSRP producers that implement the Portlet Management interface. This is an optional interface.

Let’s now look at how WSRP is typically used in web portals and what setup we need to try out the WSRP features described in the rest of this chapter.

15.2. Getting started with WSRP using Liferay Portal

Portal servers simplify using WSRP by providing administration screens for managing producers and consumers. The typical process for publishing portlets consists of using the portal server’s administration screens to do the following:

• Create a producer by specifying a unique name for it. At the same time, you can also provide information on how consumers can register with the producer to use the published portlets. You may want to create multiple producers if the producers’ registration requirements vary or if they expose different sets of portlets. Successful creation of a producer generates a unique web service URL for accessing the producer’s functionality.
• Add portlets to the producer that need to be published to the external world.

The process of consuming remote portlets involves using the portal server’s administration screens to perform the following steps:

• Create a consumer by specifying both a unique name for it and the web service URL of the producer with which the consumer interacts. A consumer can’t be associated with more than one producer at any given time.
• Register the consumer. If the producer requires consumers to register, the registration information must be supplied to the producer. If the registration information is found to be valid by the producer, the producer’s published portlets are made available to the consumer. (Section 15.6 discusses the registration approaches defined in the WSRP specification.)
• Locally register any portlets that are published by the producer and associated with the consumer. You can locally register some or all of the portlets published by the producer—doing so makes the portlets published by the producer available to your portal server like any other portlet. During local registration, you specify a local name for the remote portlet—the title with which it’s registered with the portal server.

 

Warning

Local registration of remote portlets means that a local portlet is created by the WSRP consumer to show the markup received from the remote portlet. Any interaction with the markup is forwarded by the WSRP consumer to the corresponding WSRP producer.

 

The preceding process is generic and is followed in almost all portal servers. In the rest of this chapter, we’ll look at the producer and consumer administration portlets provided by OpenPortal Portlet Container and Liferay Portal to demonstrate this process. If you’re using any other portal server that supports WSRP, like WebSphere Portal and GateIn Portal, you can refer to their documentation to find out how to create producers and consumers and how to publish and consume portlets.

 

Note

The WSRP implementation has always been an integral part of Liferay Portal Enterprise Edition (EE) and it is supported in the Community Edition (CE) starting with Liferay Portal 6.x.

 

In real-world scenarios, WSRP consumers and producers are part of portal server instances installed on remotely located systems, and you only need to know the URL of the WSRP producer web service endpoint. For the purposes of this chapter, we’ll install two different instances of Liferay portal server on the same machine to mimic a real-world situation.

To create two different instances of Liferay Portal on the same machine, you need to do the following:

1.  Unzip the Liferay-Tomcat bundle into two different folders on your machine.

2.  Modify the {TOMCAT_HOME}/conf/server.xml file on one of the instances to use different port numbers. A simple approach is to increase all port numbers for one of the Tomcat instances by 100. With this approach, the HTTP port number of one of the instances will become 8180, so you’ll be able to access that Liferay Portal instance using the following URL: http://localhost:8180/.

In the rest of this chapter, we’ll assume that the Liferay Portal instance using HTTP port 8080 is the WSRP producer (referred to as instance P1 in the rest of the chapter) and the instance using HTTP port 8180 is the WSRP consumer (referred to as instance C1 in the rest of the chapter).

 

Warning

You can have both the WSRP producer and the corresponding WSRP consumer on the same portal server instance. In such a scenario, the web portal accesses local portlets through the WSRP consumer. This approach will result in reduced web portal performance because of the overhead involved in accessing local portlets as remote portlets. For this reason, it’s recommended that local portlets should always be accessed directly, and not through a WSRP consumer.

 

In the rest of this chapter, you’ll learn how to do the following with Liferay Portal 6.x:

• Create a WSRP producer and add portlets to it
• Create a WSRP consumer
• Locally register remote portlets
• Register WSRP consumers with WSRP producers

15.3. Creating a WSRP producer and adding portlets to it

In Liferay Portal, a portal administrator can create a WSRP producer. In this section, we’ll look at how to do that and then add portlets to it.

From the home page of your P1 Liferay Portal instance (http://localhost:8080/), select the Login as Bruno hyperlink to log in as the administrator of the Liferay Portal. Now you can go to the dockbar and select Manage > Control Panel to view a list of options reflecting the tasks that a Liferay Portal administrator can perform.

Click the Plugins Installation option under the Server category. This will show the list of portlets installed in your Liferay Portal instance. Click the Install More Portlets button, as shown in Figure 15.4, to view and install portlets that are not yet installed.

Figure 15.4. Clicking the Install More Portlets button shows the list of portlets that aren’t yet installed in the Liferay Portal instance. You can also search and install portlets.

Now, you can search for WSRP portlet, as shown in the Figure 15.5.

Figure 15.5. Search for WSRP portlet by entering wsrp in Keywords field and click the Search button. Search result will show a WSRP plugin portlet.

The above figure shows that you need to enter wsrp in Keywords field and click the Search button. The search result consists of only a single entry – WSRP 6.0.5.1. This search result represents the WSRP plugin portlet of Liferay Portal that you need to install in your Liferay Portal instance to start using WSRP. Click the WSRP 6.0.5.1 hyperlink to view the details of the WSRP plugin portlet. It’ll also show the option to install it, as shown in Figure 15.6. This figure shows that WSRP plugin portlet is supported for Liferay Portal 6.0.5 and above versions. Click the Install button to install the WSRP plugin portlet. A successful installation will result in showing a WSRP option under the Portal Category in the Control Panel.

Figure 15.6. Details of WSRP plugin portlet. Clicking the Install button installs the WSRP plugin portlet in Liferay Portal instance.

To add a WSRP producer or consumer, you first need to select the WSRP option (under the Portal category) from the list of available options, as shown in Figure 15.7.

Figure 15.7. The WSRP option allows the portal administrator to manage WSRP consumers and producers configured for the Liferay Portal instance.

The WSRP option allows Liferay Portal administrators to view, add, edit, and remove WSRP producers and consumers configured for the Liferay Portal instance. As you’re currently using the P1 Liferay Portal instance, you’re only interested in adding a new WSRP producer to it. Click the Producers hyperlink from the screen that shows up after you select the WSRP option, as shown in Figure 15.8.

Figure 15.8. Clicking the Producers option allows the Liferay Portal administrator to manage WSRP producers for the Liferay Portal instance.

Figure 15.8 shows two tabs, Consumers and Producers, which lets administrators manage WSRP consumers and producers. Figure 15.9 shows the screen that’s displayed when the administrator selects the Producers option.

Figure 15.9. The Producers tab displays a list of WSRP producers configured in Liferay Portal, and it allows the administrator to add new WSRP producers or make changes to existing WSRP producers.

Figure 15.9 shows that the Producers tab displays a list of WSRP producers configured in the Liferay Portal instance. The Add Producer button lets you add new WSRP producers to the Liferay Portal instance. The Actions button corresponding to existing WSRP producers allows you to make changes to the producer, such as adding portlets to or removing them from the producer, or removing the producer from Liferay Portal.

 

Note

At this point, you should build the ch2_UserRegistration, ch11_BookCatalog_event, ch11_RecentBook_event, ch12_DateTime, ch12_SpringPortletDateTime, and ch12_ResourceServing projects and install the portlets in the P1 Liferay Portal instance. The portlets contained in these portlet applications will be added to the WSRP producer that we’ll create in this section, for use by the WSRP consumer of the C1 Liferay Portal instance.

 

Let’s now add a new WSRP producer to our P1 portal instance by clicking the Add Producer button. Figure 15.10 shows the form that’s displayed for adding a new WSRP producer in Liferay Portal.

Figure 15.10. The Add Producer form allows the administrator to add a new WSRP producer. It also allows one or more installed portlets to be added to the WSRP producer.

 

Warning

As of Liferay Portal 6.0, you must specify the value for the <remoteable> element in liferay-portlet.xml as true to expose a locally installed portlet through a WSRP producer.

 

The Name text field is for entering the name of the WSRP producer that you want to create. The Current list shows the portlets that are currently hosted by the WSRP producer, whereas the Available list shows portlets that are currently installed in the Liferay Portal instance . The left and right arrows allow you to add portlets to and remove them from the list of portlets hosted by the WSRP producer. The Save button allows you to save the WSRP producer’s details.

 

Warning

In Figure 15.10 you may have noticed that the Available portlet list only displays portlet titles, which may confuse you if you have multiple portlets installed with the same title. If you have multiple portlets (under different categories) with the same portlet title, it’s recommended that you modify the titles to make them unique in the Liferay Portal instance before adding the portlets to a WSRP producer.

 

Figure 15.10 shows that you can add a WSRP producer along with the portlets that you want to be hosted by your WSRP producer. To set up a producer to match the examples that will follow in this chapter, enter My Producer as the name of the WSRP producer, add portlets to the producer from the Available list, and click Save. Select the following portlets from the Available portlet list:

• Book Catalog (from ch11_BookCatalog_event)
• Recently Added Book (from ch11_RecentlyBook_event)
• Date/Time Portlet (from ch12_DateTime)
• Book Catalog—Rich Portlet (from ch12_ResourceServing)
• Spring Portlet MVC Date/Time Portlet (from ch12_SpringPortletDateTime)
• User Registration (from ch2_UserRegistration)

Once the WSRP producer is successfully created, it’s displayed in the list of WSRP producers configured for the Liferay Portal instance, as shown in Figure 15.9.

You might wonder why we’re adding multiple portlets to the My Producer WSRP producer when we could have tested the WSRP functionality by simply adding one portlet. The intent is to demonstrate that remote portlets behave just like local portlets; they can communicate using portlet events, respond to Ajax requests, and be developed using a portlet framework like Spring Portlet MVC.

 

Tip

The portlets that you’ve added to the My Producer provider will let you test inter-portlet communication between remote portlets using portlet events, the Ajax functionality of remote portlets, and that a portlet developed using the Spring Portlet MVC framework can also be published as a remote portlet. This book is accompanied by many example portlets that can help you test your portal server’s WSRP implementation. For instance, if you want to check whether inter-portlet communication is supported between remote portlets using PortletSession or public render parameters, you can try out the examples from chapter 11; if you want to test whether you can personalize a remote portlet or not, you can try out examples from chapter 10.

 

After successfully creating a WSRP producer, you need to find the WSRP producer’s web service endpoint URL, which will be used by the WSRP consumer. The web service endpoint URL is autogenerated by Liferay Portal when you create a WSRP producer.

To obtain the web service endpoint of the newly created My Producer provider, select the Actions > Edit option corresponding to My Producer, as shown in Figure 15.11. Figure 15.12 shows the information that’s displayed when you select Edit.

Figure 15.11. The Edit option allows the administrator to modify the details of a WSRP producer, and it also displays the URL of the producer’s web service endpoint.

Figure 15.12. The URL field shows the WSRP producer’s web service endpoint URL. The WSRP consumer uses the producer’s web service endpoint URL to interact with the portlets hosted by the producer.

Figure 15.12 shows that when you go about editing the details of the My Producer WSRP producer, the URL of the web service endpoint is also displayed. This is the URL a WSRP consumer needs to access the portlets hosted by My Producer. It’s recommended that you copy the URL of My Producer so that it’s accessible when you need to add a WSRP consumer in the C1 Liferay Portal instance, which uses portlets hosted by My Producer.

 

Note

The web service endpoint URL of a producer is autogenerated by Liferay Portal and it can’t be modified by the portal administrator.

 

You’ve now finished creating a WSRP producer. Next, we’ll look at how to create a WSRP consumer that makes portlets hosted by My Producer available to the C1 Liferay Portal instance.

 

Tip

To better understand the methods and interfaces exposed by the My Producer WSRP producer, you can use a web service tool like soapUI (http://www.eviware.com/) to investigate the My Producer WSRP producer’s web service.

 

15.4. Creating a WSRP consumer

In Liferay Portal, a portal administrator can create a WSRP consumer. From the home page of your C1 Liferay Portal instance (http://localhost:8180/), click the Login as Bruno hyperlink to log in as the administrator of Liferay Portal.

Once you’re signed in, you can go to the dockbar and select Manage > Control Panel to view a list of options reflecting the tasks that a Liferay Portal administrator can perform. To add a WSRP consumer, you first need to select the WSRP option (under the Portal category) from the list of available options, as shown earlier in Figure 15.7. Next, click the Add Consumer button to add a new WSRP consumer to the C1 Liferay Portal instance, as shown in Figure 15.13.

Figure 15.13. The Consumers tab displays a list of WSRP consumers configured for the Liferay Portal instance and also provides the option to add new WSRP consumers.

The Consumers tab shown in Figure 15.13 displays a list of WSRP consumers that are configured for the Liferay Portal instance. Click the Add Consumer button to open the form for adding a new WSRP consumer to the C1 instance, as shown in Figure 15.14.

Figure 15.14. Add a WSRP consumer by specifying a name for it and the URL of the WSRP producer web service endpoint for which it acts as a consumer.

Figure 15.14 shows that to add a WSRP consumer, you need to enter the WSRP producer’s web service endpoint URL for which you’re creating the consumer. Because you’re creating a consumer for My Producer in this example, you need to enter the URL of the My Producer web service. Enter My Consumer as the name of your WSRP consumer and the web service URL of My Producer, and click Save to create a new WSRP consumer corresponding to My Producer.

 

Note

A WSRP consumer can only refer to a single WSRP producer. If you need to access portlets from multiple WSRP producers, from the same or different remote systems, you’ll need to create a WSRP consumer for each WSRP producer.

 

Once the WSRP consumer is successfully created, it’s displayed in the list of WSRP consumers configured for the Liferay Portal instance, as shown in Figure 15.15. In this figure, the Consumers tab displays My Consumer as one of the WSRP consumers configured for the C1 Liferay Portal instance. The Actions button corresponding to each consumer shows additional options for editing and deleting the consumer and for managing remote portlets that the WSRP consumer makes available to the C1 Liferay Portal instance.

Figure 15.15. The Consumers tab shows the list of WSRP consumers. The Actions button allows you to manage remote portlets made available to the local Liferay Portal instance by each WSRP consumer.

Table 15.2 describes the additional options that are displayed when you click the Actions button.

Table 15.2. Options displayed when the Actions button is clicked

Option	Description
Edit	Allows you to modify WSRP consumer information, such as its name and the web service URL of the corresponding WSRP producer whose portlets it locally registers.
Manage Portlets	Allows you to manage remote portlets that are locally registered by the WSRP consumer.
Update Service Description	Retrieves updated service description information from the corresponding WSRP producer. These details include, among other things, the latest list of portlets published by the producer and any registration requirements.
Delete	Deletes the WSRP consumer from the Liferay Portal instance.
Edit Registration	This option is only displayed if the WSRP producer requires a WSRP consumer to register with the producer before locally registering portlets published by the producer.

Now that you’ve successfully created the My Consumer WSRP consumer, let’s look at how you can locally register remote portlets published by the My Producer WSRP producer.

15.5. Locally registering remote portlets

In the previous section, you saw how to create a WSRP consumer in Liferay Portal. When you created the My Consumer WSRP consumer in the C1 Liferay Portal instance, you simply associated it with the My Producer WSRP producer of the P1 Liferay Portal instance. To use a remote portlet in a web portal hosted by the C1 Liferay Portal instance, the My Consumer WSRP consumer must also specify the published portlets of My Producer that it wants to make available to the C1 Liferay Portal instance.

As mentioned in table 15.2, the Manage Portlets option allows you to manage the remote portlets that are locally registered by a WSRP consumer. As shown in Figure 15.16, when you select the Manage Portlets option for My Consumer, the Add Portlet option for locally registering remote portlets is displayed, along with the list of locally registered portlets by My Consumer. Because the My Consumer WSRP consumer doesn’t yet have any remote portlets locally registered, no portlets are listed in Figure 15.16.

Figure 15.16. The Manage Portlets screen shows the list of portlets that have been locally registered by the WSRP consumer. The Add Portlet option allows the WSRP consumer to locally register remote portlets.

If you click the Add Portlet button in Figure 15.16, you’ll be able to select portlets that you want to register locally, as shown in Figure 15.17.

Figure 15.17. The Add Portlet screen allows you to locally register remote portlets.

In Figure 15.17, the Remote Portlet combo box lists the portlets that are published by the corresponding WSRP producer. Because My Consumer is associated with My Producer, the combo box shows the portlets published by My Producer. The Name field allows you to assign a local name (or title) to the remote portlet for the local installation.

For this example, select the User Registration Portlet from the combo box, enter “Register Me !!” as the name for the portlet, and click Save. This will register the remote User Registration portlet locally with the name “Register Me !!”. After locally registering a remote portlet, you can view it in the Manage Portlet screen shown in Figure 15.16.

Now, how do you go about adding this locally registered remote portlet as a local portlet in a web portal? Like any other portlet, a locally registered remote portlet is available in the list of portlets displayed when you select the Add > More option from the dockbar, as shown in Figure 15.18. As you can see, the User Registration portlet is registered locally with the title “Register Me !!” and is available under the WSRP category. You can go ahead and use the Register Me !! portlet like any other local portlet.

Figure 15.18. The User Registration portlet is displayed with the title “Register Me !!” under the WSRP category.

You can follow the same approach to locally register all the portlets published by My Producer and check out how they behave. Table 15.3 describes the behavior of each of the locally registered portlets published by the My Producer WSRP producer.

Table 15.3. Behavior of locally registered remote portlets

Portlet	Observed behavior
Book Catalog (ch11_BookCatalog_event)	The action and render requests are handled correctly. The CSS and JS files are included from the remote portal server instance that hosts the My Producer WSRP producer. When a book is added, it’s reflected in the Recently Added Book portlet.
Recently Added Book (ch11_RecentlyBook_event)	Works fine. The CSS file is included from the remote portal server instance that hosts the My Producer WSRP producer.
Book Catalog–Rich Portlet (ch12_ResourceServing)	Doesn’t work. A little investigation will reveal that the issue is the use of Reverse Ajax. The polling request that’s sent out every 60 seconds by DWR uses this URL:
	http://localhost:8180/ch12_ResourceServing/dwr/call/plaincall/__System.pageLoaded.dwr
	It should instead use this URL:
	http://localhost:8180/wsrp-portlet/proxy?url=http://local-host:8080/ch12_ResourceServing/dwr/call/plaincall/ __System.pageLoaded.dwr.
	We’ll soon discuss how the first URL is different from the second.
Date/Time Portlet (ch12_DateTime)	This portlet doesn’t work because it sends an Ajax request to the DateTimeServlet servlet. If it had used the portlet’s resource URL to address Ajax use cases, it would have worked.
Spring Portlet MVC Date/Time Portlet (ch12_SpringPortletDateTime)	When you click the Refresh button, the portlet displays the message “You are not authorized to view server date/time.” This means that the Ajax request was successfully sent to the remote portlet, but it was not in the User role.
	The Ajax request was successful because the portlet made use of the portlet’s resource URL to send the Ajax request. The failure to identify the correct role of the user suggests that if the remote portlet makes use of role-based security, you should configure your WSRP consumer (C1) and WSRP producer (P1) portal instances to use single sign-on.
User Registration Portlet (ch2_UserRegistration)	Works fine. The action and render requests are handled correctly.

Table 15.3 suggests that if your WSRP producer and consumer are hosted by Liferay Portal instances, the following challenges with using remote portlets are automatically taken care of:

• CSS and JavaScript files defined in the liferay-portlet.xml file of the remote portlet are included. Because the liferay-portlet.xml file is specific to Liferay Portal, the CSS and JavaScript files won’t be included if the WSRP consumer is configured in a different portal server.
• Ajax requests that are sent using the portlet’s resource URL are transparently dispatched to the remote portlet for processing.
• Inter-portlet communication between locally registered remote portlets is mediated by the WSRP consumer via portlet events.

In table 15.3, you saw that Reverse Ajax didn’t work when the remote Book Catalog–Rich Portlet was locally registered. The reason for this is that the URL that DWR generated for sending polling requests doesn’t fit in the context of WSRP. Let’s look at how a WSRP consumer in Liferay Portal generates URLs referring to the CSS and JavaScript files of the remote portlet.

URL for Remote CSS and Javascript Files

If you view the source of the portal page that contains a locally registered remote portlet, you’ll notice that the CSS and JavaScript references defined in the remote portlet’s liferay-portlet.xml file are passed through a local wsrpportlet servlet. For instance, consider the following liferay-portlet.xml file for the Book Catalog portlet defined in the ch11_BookCatalog_event portlet application project:

<liferay-portlet-app>
  <portlet>
    <portlet-name>bookCatalog</portlet-name>
       <instanceable>true</instanceable>
       <header-portlet-css>/css/bookCatalog.css</header-portlet-css>
       <header-portlet-javascript>
           /js/bookCatalog.js
       </header-portlet-javascript>
  </portlet>
</liferay-portlet-app>

The preceding liferay-portlet.xml file includes the bookCatalog.js and bookCatalog.css files. If you add the Book Catalog portlet on a portal page of the P1 Liferay Portal instance and view the source of the portal page in your browser, you’ll find that the URLs used by the <link> or <script> elements for including the CSS and JavaScript files look like these:

/ch11_BookCatalog_event/css/bookCatalog.css
/ch11_BookCatalog_event/js/bookCatalog.js

Now, when you add the Book Catalog portlet on a portal page of the C1 Liferay Portal instance and view the source of the portal page in your browser, you’ll find that the URLs used by the <link> or <script> elements look like these:

/wsrp-portlet/proxy?url=
http://localhost:8080/ch11_BookCatalog_event/css/bookCatalog.css

/wsrp-portlet/proxy?url=
http://localhost:8080/ch11_BookCatalog_event/js/bookCatalog.js

As you can guess from the generated URLs, the <link> and <script> tags make use of a servlet mapped to a wsrp-portlet/proxy URL that accepts a url parameter identifying the location of the CSS or JavaScript file on the portal instance that hosts the remote portlet.

This means that if you specify references to CSS or JavaScript files in the liferay-portlet.xml file, the WSRP consumer takes care of transforming these URLs to point to the WSRP producer that published the portlet. But this is a Liferay Portal–specific feature, so how do we refer to CSS and JavaScript files when not using Liferay Portal? In table 15.3, you saw that the portlet’s resource URL can be successfully used to send Ajax requests to a remote portlet. Similarly, you can use a portlet’s resource URL to refer to CSS and JavaScript files that are used by the portlet. For instance, you saw in chapter 3 that Jetspeed 2.2 supports MARKUP_HEAD_ELEMENT, so you can use a portlet’s resource URL to add CSS and JavaScript files.

Now back to why DWR generated a URL that doesn’t refer to the wsrp-portlet/ proxy servlet. The DWR Java library generates a URL that identifies where the pooling request is to be sent. Because this URL wasn’t defined in the liferay-portlet.xml file, the URL isn’t transformed by the WSRP consumer to refer to the wsrp-portlet/ proxy servlet.

Let’s now look at how the WSRP 2.0 registration feature works.

15.6. Registering WSRP consumers with WSRP producers

Registration is the process by which the consumer provides information about itself to the producer. In this section, we’ll look at the in-band and out-of-band registration approaches that are followed by consumers to register with producers, and we’ll also look at some examples. Toward the end of this section, we’ll also look at the concept of leasing that was introduced in WSRP 2.0.

15.6.1. Out-of-band registration

In the out-of-band registration approach, the registration process isn’t automated. You need to manually generate a registration handle using a WSRP producer and provide it to the businesses that want to access the published portlets. A registration handle uniquely identifies the consumer-producer relationship, and it’s passed to the producer every time the consumer accesses the producer.

Suppose you create a Stock Watch portlet that you publish to the external world using WSRP. Only those businesses who have been granted access should be able to access your Stock Watch portlet. To gain access to the Stock Watch portlet, the businesses send an email request to you containing all the necessary information you require to register them. You manually enter the details and generate a unique registration handle—a string value that uniquely identifies the relationship between you and the business. You send the registration handle to the business, which is used by the business to create and register a WSRP consumer with your WSRP producer. The WSRP producer validates the registration handle and allows the business to access the Stock Watch portlet.

Let’s now look at how in-band registration is different from out-of-band registration.

15.6.2. In-band registration

In in-band registration, the WSRP consumer is responsible for registering with the WSRP producer. The information that’s required for registering with the WSRP producer is exposed using the Registration web service interface (see table 15.1), and it’s entered using the WSRP consumer’s user interface. The registration handle is generated during the registration process and is returned to the WSRP consumer.

The WSRP producer in Liferay Portal 6.x doesn’t provide an option to enforce WSRP consumer registration, but Liferay Portal 6.x does let WSRP consumers register with a WSRP producer that supports in-band or out-of-band registration.

Let’s now look at examples of using in-band and out-of-band registration.

15.6.3. In-band and out-of-band registration examples

As mentioned earlier in table 15.2, Liferay Portal’s WSRP consumer displays the Edit Registration option only when the corresponding WSRP producer requires consumers to register. That means, to demonstrate registration, the first thing we need to do is find a WSRP producer that requires its consumers to register with the WSRP producer.

The OpenPortal WSRP producer does require consumers to register using either in-band or out-of-band registration. Figure 15.19 shows the WSRP producer from the OpenPortal WSRP implementation, which supports in-band registration.

Figure 15.19. The OpenPortal WSRP producer portlet allows consumers to register using in-band or out-of-band registration. The Registration Property Descriptions section defines properties that are required for registering using the in-band approach.

In Figure 15.19, the Registration option lets you chose whether you want WSRP consumers to register with the WSRP producer to use the published portlets or not. The Inband Registration option lets you chose whether you want to allow in-band registration or limit WSRP consumers to using out-of-band registration. The Registration Property Descriptions section defines the properties that must be supplied by the WSRP consumer during in-band registration.

Figure 15.20 shows that the Edit Registration option is available when a WSRP consumer is created in Liferay Portal, and it’s associated with the WSRP producer in Figure 15.19.

Figure 15.20. The Edit Registration option is available when the corresponding WSRP producer requires consumers to register.

If you select the Edit Registration option shown in Figure 15.20, it will display the screen in which you need to enter the registration information, as shown in Figure 15.21.

Figure 15.21. The Registration screen allows you to enter the WSRP consumer’s registration information so it can register with a WSRP producer. Registration can be in-band or out-of-band.

In Figure 15.21, the Registration Type combo box shows Inband and Outband options. You might wonder why it shows Outband as an option, when we saw in Figure 15.19 that the WSRP producer supports in-band registration. Just because a WSRP producer supports in-band registration doesn’t mean that WSRP consumers can’t register using the out-of-and approach. The out-of-band option is always available to WSRP consumers, irrespective of whether the WSRP producer supports in-band registration or not. The Registration Properties section shows the information that must be supplied to the WSRP producer to register the WSRP consumer.

If you select the Outband value from the Registration Type combo box, you only need to enter the registration handle that you received from the owner of the WSRP producer, as shown in Figure 15.22. The registration properties aren’t displayed; instead, the Registration Handle field is displayed.

Figure 15.22. Out-of-band registration only requires you to enter the registration handle.

Now that you know how to register a WSRP consumer with a WSRP producer, let’s look at how the leasing feature in WSRP 2.0 works.

15.6.4. Leasing

The concept of registration in WSRP 2.0 was extended to include the concept of leasing, wherein registrations are valid only for a predefined amount of time. With leasing, the consumer specifies the time period for which the registration is valid. When the registration time period expires, the portlet and registration handles are destroyed.

Leasing is an optional feature that isn’t supported by WSRP consumers in Liferay Portal 6.0, but the OpenPortal WSRP consumer supports leasing. Figure 15.23 shows the OpenPortal WSRP consumer creation screen that specifies the lifetime of the registration with the corresponding WSRP producer.

Figure 15.23. The Lifetime Supplied option allows you to enter a specified time period for the registration.

In Figure 15.23, the WSRP consumer displays a check box labeled Lifetime Supplied, which lets you enter the time period for which the registration with the corresponding WSRP producer is valid. The feature is particularly useful when you want the remote portlet to be available only for a specified time period and for that connection to be destroyed once the registration time period expires. This saves the effort needed to manage locally registered remote portlets that aren’t supposed to be used after a specified time period.

This is all you need to know about WSRP to start using it in your real-world portal projects.

15.7. Summary

In this chapter, we looked at the basics of WSRP and at how it simplifies using remote portlets. WSRP saves you the effort of deploying all your portlets on the same portal server, which results in optimal utilization of system resources.

We looked at how portlet examples from the previous chapters behave when they’re used as remote portlets. The source code examples that accompany this book include loads of sample portlets that you can use to understand the behavior of your portal server’s WSRP implementation.

By now you should know all that you need to know to create, manage, and experiment with portlets. Use this book as a reference when you need to fine-tune your skills and remind yourself about all that you’ve learned. But for now, the world of portlets awaits!