Programming Portlets: From JSR 168 to IBM WebSphere Portal Extensions
524
Programming Portlets: From JSR 168 to IBM WebSphere Portal Extensions
524eBookSecond Edition, Second edition (Second Edition, Second edition)
Available on Compatible NOOK devices, the free NOOK App and in My Digital Library.
Related collections and offers
Overview
Product Details
| ISBN-13: | 9781931182386 |
|---|---|
| Publisher: | MC Press, LLC |
| Publication date: | 05/01/2012 |
| Sold by: | Barnes & Noble |
| Format: | eBook |
| Pages: | 524 |
| File size: | 10 MB |
About the Author
Read an Excerpt
Programming Portlets
By Ron Lynn, Joey Bernal, Peter Blinstrubas, Usman Memon, Cayce Marston, Tim Hanis Varadarajan Ramamoorthy, Stefan Hepper
IBM Press and MC Press
Copyright © 2009 International Business Machines CorporationAll rights reserved.
ISBN: 978-1-931182-38-6
CHAPTER 1
Portals and Portlets: The Basics
Without a portal to plug into, portlets by themselves are quite useless. Put another way, just as you put letters together to form words and put words together to create sentences, you put portlets together to create one portal page. To understand what portlets are and where they come into play, we must therefore look at what a portal is. To do otherwise would be like trying to explain why letters are such a great thing without mentioning that you can combine them together to create words and sentences.
In this chapter, we briefly consider the different types of portals that exist and how portlets fit into the picture. Then, we take a closer look at the runtime environment of portlets: the portlet container. Just as the servlet container provides the infrastructure for running servlet components in the servlet world, so the portlet container provides the infrastructure for running portlets.
To get started, let's first look at what a portal is and explore the key benefit portals offer to the user — namely, the integration of several independent applications on one screen.
WHAT IS A PORTAL?
Figure 1.1 depicts a typical portal page. This portal consists of several pages, including Welcome, My Workplace, and My Finances. The figure shows the My Finances page of the portal, on which five portlets interact with each other.
At the top of the portal page, a navigation bar lets the user move between portal pages. On the upper-right side, administration links let the user log in or out of the portal, access the user profile, and get help. Immediately below this upper bar, two finance-related portlets appear below:
• The CT Profile portlet displays details about a specific company.
• The CT Chart portlet displays charts and graphs relevant to the company.
These portlets, and the others you see in the figure, are placed on the page and represent applications with which the user can interact. These different applications are now integrated onto one page with one consistent API and are managed centrally. This approach offers advantages for the user, who now can access different applications consistently and in one place, and for the portal administrator, who can manage access to back-end services for a specific user in one place. If we examine this example more closely, you can see what a portal really offers. Portals enable users, even when they're using the Web, to work more as they do on their desktop, with different applications on one screen that can be interconnected and exchange data.
Most readers of this book probably have an understanding of what a portal is, and specifically of what WebSphere Portal Server is and how it generally works, but for completeness we should go over some obligatory information. If you're unfamiliar with WebSphere Portal, the references at the end of this chapter will point you to more information.
Types of Portals
We encounter the concept of portals throughout our daily lives. Newspapers, magazines, company bulletin boards, and car dashboards are all examples of portals we take for granted every day. Newspapers and magazines are general portals into world events, sports scores, stock market prices, and local happenings. Company bulletin boards are tailored, providing a look at the world through the eyes of the company — for example, by displaying the cafeteria's current lunch menu, clippings from the latest CEO memo, and workplace safety information. Each posting on the bulletin board is a view into the company. Automobile dashboards offer us a very specific portal into the inner workings of the different systems of our cars. The speedometer, oil pressure gauge, temperature gauge, and odometer all provide crucial information about the current condition of our vehicle's systems.
Web pages, too, provide a view of some type of information. With the rise of the World Wide Web, sites such as Yahoo and Excite started turning up as some of the first examples of portals on the Internet. These portals give users access to the latest news, weather, and stock reports. Some current Internet portals let you make stock trades or book flights and hotel rooms. They act as a single point of entry into applications and information on the Internet or your intranet. Today's portal combines applications and information into a consistent, single user interface (UI). It also supports user customization, personalization, and single sign-on.
IBM's WebSphere Portal product, shown in Figure 1.2, is essentially a framework for building portals. WebSphere Portal is capable of creating portals that are more general (like magazines and newspapers), tailored (like a company bulletin board), or very specific (like a car dashboard). You can use WebSphere Portal to create portals you can access from a desktop computer, your cell phone display, a PDA, or even your voice telephone. WebSphere Portal enables this functionality by combining portlets on a single Web page to give the end user access to information.
Although we tend to imagine a browser interface when we think of WebSphere Portal, the product is really a set of complementary products that all combine to provide a dizzying array of function. These individual products that combine to create the portal include IBM DB2 Universal Database, IBM Tivoli Directory Server, and IBM WebSphere Application Server, as well as development tools, collaboration components, and, of course, IBM WebSphere Portal Server. To learn more about the various options of the product, visit http://www.ibm.com/software/genservers/portal.
What Does the Specification Say About Portals?
So how shall we define a portal? Many of the definitions available center on aggregation and integration. We'll take the following definition from the Java Portlet Specification V1.0 (Reference 1):
"A portal is a web based application that — commonly — provides personalization, single sign on, content aggregation from different sources and hosts the presentation layer of Information Systems. Aggregation is the action of integrating content from different sources within a web page. A portal may have sophisticated personalization features to provide customized content to users. Portal pages may have different set of portlets creating content for different users."
In the next sections, we shed some more light on the different parts of the portal definition that all center on the main portal theme: application integration.
PORTAL APPLICATIONS AND PORTLETS
A portal application is a group of portlets that form a logically associated group. Portlets in an application are installed as a single package. When programmed appropriately, they're able to communicate with one another by sending and receiving messages.
Because WebSphere portal is the framework, you can think of portlets as the pieces of art we place into the frames created by WebSphere Portal. A portlet could be an article, as in a magazine. It could be column, as in a newspaper. A portlet could be the cafeteria menu or a speedometer. A portlet is one small piece of an overall portal. It is one element of many that could appear on the user's screen. In this book, we cover in detail how to create these portlets, and we look at various facilities WebSphere Portal offers for portlets. In addition, in the second half of the book, we discuss composite applications and some of the approaches for designing and developing them.
PORTAL ARCHITECTURE
Portlets are run by a component, called a portlet container, that provides the portlet with the required runtime environment. The portlet container manages the life cycle of all the portlets and provides persistent storage mechanisms for the portlet preferences, letting portlets produce user-dependent markup. The portlet container passes requests from the portal on to the hosted portlets. It doesn't aggregate the content produced by the portlets; that's the portal's job. Figure 1.3 depicts the overall portal architecture.
Here's how it works:
1. A registered user (client) opens the portal, and the portal application receives the client request and retrieves the current user's page data from the portal database.
2. The portal application then issues calls to the portlet container for all portlets on the current page.
3. The portlet container, which holds the user's preferences, calls the portlets via the portlet API, requesting the markup fragment from each portlet and returning the fragment to the portal.
4. The portal aggregates all markup fragments together into one page, which the portal finally returns to the client/user, giving the user the integrated, useful interface he or she is used to on the desktop.
You'll learn more details about the portal architecture in later portions of this book as we explain the components and their subcomponents in more detail. For now, it should be enough to keep in mind that there are the two major components: the portal itself and the portlet container. Now that you know this much about portals, let's take a closer look at what portlets really are and what their role is in the big picture.
And What Is a Portlet?
Now that you know how a portal functions, it's time to take a closer look at portlets and their role in this environment. Let's start with a definition.
A portlet is a Java-based Web component that processes requests from a portlet container and generates dynamic content. The content generated by a portlet is called a fragment, which is a piece of markup (e.g., HTML, WML, XHTML) adhering to certain rules. A fragment can be aggregated with other fragments to form a complete document, called the portal page.
One could ask why portlets were invented and specified in the Java Portlet Specification at all. Why were existing J2EE concepts (namely the servlet) not enough? As you've already seen, that would lead to challenges in creating a consistent user experience. But what else is there that justifies creating a new component? Table 1.1 lists the reasons we think portlets are a separate component.
All these requirements made it a cleaner choice to introduce a new component, portlets, instead of bending the servlet definition to also fulfill these requirements. However, the Java Portlet Specification is closely aligned with J2EE concepts to permit the reuse of as much of the existing J2EE infrastructure as possible. The following points reflect this close alignment:
• Portlet applications are packaged as WAR files, with an additional portlet deployment descriptor () for the portlet component, and can be deployed using the existing J2EE Web application infrastructure for WAR files.
• Portlet applications reuse the standard HttpSession; thus, portlets can share data via the session with other J2EE artifacts, such as servlets and JavaServer Pages (JSPs).
• Portlets can access the Web application context via the portlet API and share data with other J2EE artifacts on the context level.
• Portlets can access Web application initialization parameters defined in the web.xml file via the portlet context.
• Portlets can include servlets and JSPs via a request dispatcher.
• Portlet J2EE roles defined in the portlet.xml file can reference J2EE roles defined in web.xml, enabling a unified role mapping between portlets and servlets.
To leverage the existing J2EE infrastructure for portlets today, we can wrap them as servlets and deploy them in the Web container with the portlet container running on top of the Web container (see Figure 1.4). The Pluto Java Specification Request (JSR) 168 portlet reference implementation as well as the Jetspeed portal both take this approach.
Today, while using as many J2EE concepts as possible, portlets aren't an integral part of J2EE. Thus the portlet container is running on top of the servlet container.
The plan is to keep future portlet specification aligned with the next J2EE versions. The goal is to integrate the Portlet Specification into J2EE in the future. This integration would permit treating portlets as first-class J2EE citizens, and the whole J2EE infrastructure, including application management, monitoring, deployment, and authorization, would support them. When this happens, a portlet container will be part of the application server and leverage the server's entire infrastructure, including administration and performance tuning. Portals will then be Web applications running on the application server and leveraging the different containers provided by the application server. Figure 1.5 shows the portlet container as an independent container beside the servlet and Enterprise JavaBeans (EJB) container. For more information about the J2EE specification, consult Reference 2.
The Java Portlet Specification is also aligned with another upcoming important J2EE technology, JavaServer Faces (JSF), which enables server-side user interfaces for Web components. For more information about JSF and portlets, see Chapter 6.
Portlets in Practice
What does our definition of portlets mean in practice? You've already seen a real-life portal page in Figure 1.1. Figure 1.6 depicts the basic structure of such a portal page.
The markup fragments produced by portlets are embedded into a portlet window as portlet content. Portlet windows on a page have several basic elements. In addition to the portlet content, the portlet window has a decoration area that can include the portlet title and controls to influence the window state and the mode. The user can control the size of the portlet window via the portlet window controls, from minimized (only the title is displayed) to normal to maximized (only portlet on the page). The portlet mode influences the requested function of the portlet. A portlet may offer help in a help mode or allow customizing the behavior in an edit mode.
The portal may aggregate several portlet windows to produce a complete portal page. This means that each portlet produces only the portlet content and the portal produces everything else visible on the portal page, such as the portlet window, the portlet window controls, and the layout of the page.
Until now, all our examples have been HTML-based, but portlets aren't restricted to HTML. Figure 1.7 shows an example of a portlet that can produce different markups for different devices. For desktop browsers, it produces HTML markup; for Wireless Markup Language (WML) devices (e.g., mobile phones), it produces WML markup. This multidevice support offered by portlets lets users access the same applications regardless of the device they use.
CREATING PORTLETS
Thus far, you've learned a lot about what portals and portlets are. In this section, we start looking at how to make portlets. There are three main scenarios:
• creating a new portlet-based application project
• migrating a portlet-based application from a proprietary portlet API to the standard portlet API (Java Portlet Specification)
• transforming an existing Web application into a portlet-based application
We'll cover all of these scenarios, beginning with creating new portlet applications from scratch.
Creating Portlet Applications from Scratch
Why would someone write portlet-based applications? That's a good question and one we'll answer in this section.
Previously, we defined a portlet as a Java-based Web component that processes requests and generates dynamic content. Thus our question should have been more precisely: Why would someone write portlet-based Web applications? In the days before portlets appeared, the Web programming model consisted of servlets and JavaServer Pages. We explain this programming model in more detail later, but for now we can concentrate on its major characteristics:
• Adherence to a request/response paradigm: Web applications communicate with the Web client by having the client send a request, and the Web application responds back to the client.
• Self-contained application: A Web application comes with all needed components and doesn't interact with other applications installed on the server running the Web application. This means you get one monolithic, consistent application that solves a specific problem, such as an Internet store.
(Continues...)
Excerpted from Programming Portlets by Ron Lynn, Joey Bernal, Peter Blinstrubas, Usman Memon, Cayce Marston, Tim Hanis Varadarajan Ramamoorthy, Stefan Hepper. Copyright © 2009 International Business Machines Corporation. Excerpted by permission of IBM Press and MC Press.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
Table of Contents
Contents
Title Page,Copyright Page,
Acknowledgements,
Foreword,
Introduction to Part I,
JSR 168 PORTLET PROGRAMMING,
WHY TWO PARTS?,
Chapter One - Portals and Portlets: The Basics,
Chapter Two - Writing Your First Portlet,
Chapter Three - Java Portlet API Fundamentals,
Chapter Four - Java Portlet API Code Patterns and Best Practices,
Chapter Five - Languages and Markups,
Chapter Six - Using JavaServer Faces in Your Portlets,
Introduction to Part II,
BUILDING ON THE JAVA PORTLET API,
BOOK SCENARIOS,
Chapter Seven - Application Architecture and SOA,
Chapter Eight - Fundamentals of Portlet Factory,
Chapter Nine - Advanced Concepts in Portlet Factory,
Chapter Ten - Inter-Portlet Communication,
Chapter Eleven - Security and the Credential Vault,
Chapter Twelve - Workplace Forms Fundamentals,
Chapter Thirteen - Next Steps with Workplace Forms,
Chapter Fourteen - Enhancing the User Experience with Ajax,
Appendix A - Looking Toward V2.0 of the Java Portlet Specification,
Appendix B - Setting Up the Data Components,