 | |
Part 1 of this series introduces the open-source portal initiative at Sun. This segment, part 2, defines portlets and portals and discusses the Open Source Portlet Repository (Portlet Repository for short), a new See also part 3: Portlet Container and part 4: Web Services for Remote Portlets. Contents
Portlets
Portlets are the reusable Web components for building portals. Classic examples are My Yahoo! and, more recently, Google's IG customized home-page service. The "windows" you see on those pages are portlets. Figure 1 shows the portlets on Sun Java System Portal Server.
Java Specification Request (JSR) 168 is version 1.0 of the portlet specification, the standard that enables portlet portability. Before JSR 168 came into play, there were numerous noninteroperating definitions of a portlet. The term portlet had only a conceptual meaning. JSR 168, developed by an expert group with representatives from many industry and open-source leaders, including Apache, BEA, IBM, Oracle, and Sun Microsystems, defines a set of Java APIs for portal development and standardizes portlet preferences, user information, and life cycle. In the rest of this article, portlet means a JSR 168 portlet. Version 2.0 of the portlet specification, called JSR 286, is now available for early draft review. By definition, portlets generate markup fragments, not a complete page—one of the significant factors that differentiate portlets from servlets. A portlet is one of many components on a page. A large part of JSR 168 focuses on accommodating this definition. Authoring a portlet is similar to authoring a servlet: You implement a simple Java interface or extend a base class and then package it into a Web application archive (WAR) file. Physically, portlets are extended Web applications. Any portlet Web application is also a Web application on the Java Platform, Enterprise Edition (Java EE platform). The difference is that a portlet application additionally contains one or more portlet implementation classes and a portlet descriptor. It might, of course, also contain any number of other nonportlet Java EE artifacts, such as servlets, JavaServer Pages (JSP) pages, Web services, static content, and so forth. The Web Services for Remote Portlets (WSRP) specification enables portlets to be exposed as Web services and consumed by remote portals. Even though WSRP does not assume or depend on a portlet container, WSRP and the portlet container complement each other as a result of close alignment between their specifications. Portals
The heart of a portal is a portlet container, which is to portlets what a servlet container is to servlets. Portlet containers execute portlets and manage their life cycle. Additionally, portals offer an aggregation metaphor—a mechanism with which you can arrange multiple portlets on a single page. Beyond that, the definition of a portal blurs. Portals might provide other services, including but not limited to single sign-on, content management, search, and collaboration. Again, to execute portlets, you need a portal—or at least a stand-alone portlet container. To learn how to obtain a portal container, see "Setting Up a Portlet Container." Many sophisticated portal platforms include portlet containers. See these examples:
Portlet Repository
The Portlet Repository forms a portlet library, where portal developers can choose from a wide variety of content and services for their portals. Goals The Portlet Repository has two simple goals:
The Portlet Repository is a library of ready-to-run applications that you can download and deploy directly into your portal with, in most cases, no additional setups or configurations. Therefore, the Portlet Repository hosts only deployable portlet applications, and you should host portlet-related libraries or other developer utilities and tools in other Content The Portlet Repository started with four portlets:
In the works are four additional portlets:
Process This section walks you through the details of setup, builds, and deployment of the Portlet Repository portlets. To run a portlet, first set up a portlet container. A simple way to start is to download Apache Pluto, the JSR 168 reference implementation with which you can deploy and execute portlets. Be aware that Pluto does not support portal development. Also of interest is Acquiring the Code
The Portlet Repository uses Concurrent Versions System (CVS) for version control and will switch to Subversion in the near future. You can browse the source files with
For details, including how to access the CVS repository on the WinCVS client for Windows, see the Portlet Repository's CVS access page. Note that write access to the CVS repository requires that you have the developer role—have become a committer—in the Portlet Repository. To find out more, see "Guidelines for Contributors" later in this article. Building the Portlets
The Portlet Repository uses Apache Maven 2 for project builds. If you're accustomed to building your Java projects with Apache Ant instead, be assured that Maven is a vast improvement. Just look at the For details on Maven, download the free e-book, Better Builds With Maven, from Mergere. You need not be an expert with Maven to build the Portlet Repository. For example:
Alternatively, you can build the Portlet Repository portlets with the NetBeans IDE and the Mevenide NetBeans Module. In particular, you can open and build Maven projects just like standard NetBeans Ant-based projects on Mevenide. Figure 2 shows the GUI.
The first time you build a portlet, Maven downloads all the necessary dependencies, a process that might take awhile. When the build is complete, each portlet subproject contains a WAR file in the Deploying the Portlets
The deployment process for a portlet application depends on the portlet container of your choice. For details, see the documentation of your portlet container or portal. Pluto includes administration portlets for deployment from a Web user interface. You can deploy Portlet Repository portlets by means of the Deploy War Admin Portlet. See Figure 3.
Figure 4 shows the deployment of a Portlet Repository portlet into Pluto.
Figure 5 shows the deployed portlet.
Guidelines for Contributors
The Portlet Repository needs contributors! Whether in the form of new portlets, enhancements, or bug fixes, your contributions are welcome. Contributors to the Portlet Repository assume either of two roles:
The Portlet Repository guidelines ask that those interested in contributing to the repository start with the observer role. The process of then becoming a developer is simple: Act like one. If observers repeatedly demonstrate that they can function as developers, they can be nominated by a developer and voted in by other developers. For details, see the Portlet Repository contributor guidelines. Before contributors can have code accepted into the project, they must sign and return a contributor agreement. In brief, the agreement is their consent to share the rights to the code they contribute. Contributors should carefully read the details of the agreement. Other Portlet-Sharing Sites
Let a thousand flowers bloom! As the popularity of portlets and portals continues to grow, other noteworthy portlet-sharing sites are popping up. Here are a few examples:
The Portlet Repository contributors are committed to a free and open exchange with other portlet sites. No doubt portlets from one site will show up on another in a different form. Ultimately, which site hosts the portlets is immaterial. Success of the Portlet Repository hinges on whether it has helped build a robust portlet library for the community. References
|
| ||||||||||||||||||||||||||||||||||||||||||||||||
| |
| ||||||||||||
Print-friendly Version
