Portal Federation with WebLogic Portal WRSP: Advanced Techniques
In Part 1 of this series, you created your first federated portal utilizing WSRP. When the first WSRP spec was released, simply being able to render a portlet from one portal inside another with little or no additional development seemed really exciting. Like all new, cool technologies, once everyone had their gee-whiz moment, they started thinking about what else they wanted. As usual, they wanted a whole lot more, some of which is being addressed by the recently released WSRP 2.0 spec and the next Java portlet spec, JSR-286. Also as usual, neither development groups nor the WebLogic Portal product team waited for the next specification to start delivering the next generation of functionality. The over-arching theme of post-WSRP 1.0 requirements is how to go beyond sharing individual portlets, and begin integrating whole sections of portals together. Starting with version 9.2, the WebLogic Portal (WLP) began including both references on how to leverage existing capabilities as well as new APIs to allow enterprises to fully federate their portal assets. In this installment, you'll examine two of the major features that you can use to meet the expanding requirements you are bound to face once you get that first portlet reused through WSRP.
Federating Pages and Books
Because all readers of developer.com are extremely intelligent, I am certain that you have already concluded that if you can place one WSRP portlet in your portal, you can also place a whole page full of them in your portal. Although this may be adequate for some portals, there are two scenarios that come immediately to mind (though there are bound to be others) where it would be better to have these portlets already grouped in the producer before integrating them into the consumer portal. One scenario is the division of labor provided wholesale importing of pages and books. Some portals are huge, containing hundreds of pages and thousands of portlets. Adding one or more pages to a portal administrator's duties may simply not be practical. The other scenario is where the owners of the producer portal want to maintain a greater degree of control in how their portlets are combined no matter where they are rendered. Federated pages and books fulfill these needs easily.
WLP has made basic page and book federation extremely simple. In fact, it's so simple that you can just walk through the steps and understand why you are doing what you are doing.
In this walkthrough, you will use a simple taxonomy, keeping in mind that the more well-planned your taxonomy of portal assets is the easier your portal application will be to maintain. Once you have determined where your first federate page should reside, select the Portal perspective in Workshop, highlight the folder where you want your new page to live, and either select File > New > Other, or use the CTRL+N shortcut to start the Workshop Wizard. In the first dialog, expand WebLogic Portal and select Page.
Figure 1: New Page Wizard
The wizard will have your highlighted path pre-selected for you and prompt you for a name for your page. Enter a name and click Finish; you now have a remote-able page where you can add your portlets. Even though it may seem odd at first to have a page with no book above it in Workshop, it will function the same as pages in the library of your Portal Administration Tool (PAT).
Figure 2: Page Layout
One nice improvement in WLP 9.2 is that the wizards generate the Definition Label of portal assets based on what you named them, rather than the old scheme of portlet_1, portlet_2, and so forth. Even though the portlet wizard prompts you for a title, the page wizard does not. With federated portals, some thought should be given to the value to use in the Title field of your remote pages (also for portlets and books). Unlike a Definition Label, the Title does not need to be unique as required by the API. However, consumer portal administrators will have no way of knowing the difference between three pages (or portlets or books) with the same name because they will not have the graphical view of them you do in Workshop or on your desktop. Consumer administrators can, however, change the Title field of a remote portal asset in the consumer portal library. Ah, but didn't I say that one reason for federating pages was to leave the control with the producer? Like many areas of enterprise design and development, the approach needs to fit the situation. Deciding such trivial matters as portal asset titles in a in the early planning stages of a federated portal architecture will save time during the QA stage.
Adding a remote book to your producer portal starts with almost the exact same steps, the only difference being that you select the Book wizard rather than the Page wizard. Once your remote book is created, you then add pages as you would in a non-remote-able book. Although it is somewhat counter-intuitive, remote pages cannot be used in remote books laid out in Workshop. Attempting to do so results in the remote page looking wrong in Workshop (the path to the page prints out where you would expect to see a layout). Even though this invalid configuration will build and deploy, the book with the remote page is not included in the published portal. If you have a remote page that you want to be in a remote book, you will need to let the administrator of the consumer portal know. As with standard books, pages created in the book will be available in the PAT individually and there the administrator can assemble the way you could not in Workshop.
Note: If a portlet is consumed individually and later included in a remote page (or multiple remote pages are consumed containing the same portlet), a separate instance of the portlet is created on the consumer. If you know in advance that you will consume a portlet both individually and as part of a book or page, it is easiest to maintain your consumer portal by first placing the individual portlet before adding the remote page to your library.