"The Portlet 1.0 specification has serious limitations when it comes to inter-portlet communication, but not everyone is ready to jump to Portlet 2.0. In this addition to the JavaWorld Portlet Packet, author Sandeep Tol shows you how to use the Dojo toolkit to enhance communication between portlets based on Portlet 1.0. Level: Intermediate"
"Enterprise portal vendors use pluggable user-interface components, known as portlets, to provide a presentation layer to information systems. Unfortunately, in the past each vendor defined its own portlet API, producing incompatibilities across the industry. To standardize the process, the Java community launched Java Specification Request (JSR) 168: the Portlet Specification."
"Jetspeed lets you focus on building connections to outside resources, such as Web services, databases, and content feeds. It features built-in services for user interface customization, caching, persistence, and user authentication. As a portal developer, you don't have to build any of those services yourself; instead, you can concentrate on retrieving external data and displaying it. Jetspeed doesn't place any restrictions on what resources portlets may access."
"This article is about the new inter-portlet communication facilities found in Portlet 2.0. See these other articles in the JavaWorld Portlet Packet to round out your education -- and look for future articles, too!"
"Interested in building small bits of browser-based functionality for public or internal consumption? Portlets could be the answer. Portal Zone blogger Navaneeth Krishnan discusses the qualities that define a portlet application, then walks you through a short development example that will get you started with the new Portlet 2.0 spec. Level: Beginner"
"With the emergence of an increasing number of enterprise portals, various vendors have created different APIs for portal components, called portlets. This variety of incompatible interfaces generates problems for application providers, portal customers, and portal server vendors. To overcome these problems, JSR (Java Specification Request) 168, the Portlet Specification, was started to provide interoperability between portlets and portals."
"German software vendor SAP offers an excellent place to start. The SAP offering includes a comprehensive development, deployment, and runtime environment—all of which fit on a modest-sized computer. All of the necessary software is free to download, either from open source projects or directly from SAP. In addition to its ready availability and no-cost startup, SAP has also produced a robust API and development framework for dynamic portlets, which SAP calls iViews."
"The Portlet specification defines a portlet as a "Java-technology-based web component, managed by a portlet container that processes requests and generates dynamic content." That's not the easiest thing to understand, is it? This article will explain what portlets are and what they do."
"TSS has excerpted a sample chapter from the 'Building Portals with the Java Portlet API' book, by Jeff Linwood and David Minter. The chapter discusses how a portlet interacts with a portal, from initialization to removal and provides an example that walks you through the stages of the portlet life cycle, and one that illustrates the issues of multithreaded portlet applications."
"JSR-168 Portlet applications represent a special challenge when it comes to clustering within Tomcat (or any other servlet container, for that matter). In order to effectively cluster web applications, session data must be replicated or shared between the nodes in the cluster. Otherwise, the user experiences a complete loss of context during a node failover. While Tomcat has provided session replication for quite some time, it has not supported replication of session changes resulting from a cross-context call from one webapp to another."
"The core features of any Internet portal are content aggregation from different information sources, web-page personalization and single sign-on. Java portlets act as the building blocks of any J2EE based portal implementation. Java portlets are very similar to Java servlets in many ways. They too are web components, managed by a container, that generate dynamic content. Java Portlet Specification v1.0 (JSR 168) defines the portlet API, container-portlet contract and packaging requirements for Java portlets. The recent Java Portlet Specification 2.0 final draft (JSR 286) facilitates implementing portlets with more advanced capabilities. This article illustrates the use of action scoped request attributes runtime option, which facilitates Java objects created during action phase being accessible during render phase in the form of request attributes."
"To illustrate the portlet development process, we consider the steps involved in creating the FAQ portlet included in MVCPortlet distribution. Figure 3 shows the home page for the FAQ portlet in VIEW mode. The home page shows a list of FAQ categories. When the user clicks on a category, questions and answers belonging to the category are displayed, as shown in Figure 4."
"Right-click or Control-click to download this MP3 file. You can also subscribe to the Java Mobility Podcast Feed to get the latest podcast automatically. If you use iTunes you can open iTunes and subscribe with this link: Java Mobility Podcast in iTunes."
"This article describes the Portlet Container 1.0 Beta software that ships with the Java Application Platform SDK Update 2, including the deployment and undeployment of portlets using the Portlet Container."
"This article describes the new features that are available in Portlet Container 2.1 software along with a sample application to demonstrate how to write portlets with these features. The steps to deploy portlets are the same as in Portlet Container 1.0. To know more about how to deploy portlets, see Understanding the Portlet Container 1.0 Software and Deploying Portlets."
"This article describes the new features that are available in Portlet Container 2.0 Beta along with a sample application to demonstrate how to write portlets with these features. The steps to deploy portlets are the same as in Portlet Container 1.0. To know more about how to deploy portlets, see Understanding the Portlet Container 1.0 Beta Software and Deploying Portlets."
"This article describes the Portlet Container 1.0.2 software that ships with the Java Application Platform SDK Update 4, including the deployment and undeployment of portlets using the Portlet Container. This article applies to both Portlet Container 1.0 (FCS - final release) and Portlet Container 1.0.2."
"This article describes the new features that are available in Portlet Container 2.0 along with a sample application to demonstrate how to write portlets with these features. The steps to deploy portlets are the same as in Portlet Container 1.0. To know more about how to deploy portlets, see Understanding the Portlet Container 1.0 Software and Deploying Portlets."
"Chan mentions, for instance, that the use-cases for portlets have evolved, and that many original shortcomings of portlets, such as the use of undecipherable URLs, have been addressed by various portlet frameworks:"
"Although Apache Pluto comes as a Web application built on J2EE standards, it can't be directly deployed as is. Also, any Pluto portal application you develop can't be directly installed in the Pluto portal container. Developers typically deploy Pluto in the Apache Tomcat Web container, but that approach isn't your only choice. Geronimo can also host Pluto applications. This article shows how to use the Pluto portal server with Geronimo to provide a completely open source testing and deployment environment for portal applications with a popular and feature-rich application server in the background."
"Portal technology can provide a cost-effective means to deploy and administer rich communication channels tailored to the consumer and CSR. To meet today's demanding business needs, portal applications must be designed to ensure a high-quality user experience. One way you can improve the quality of a user's experience with a portal application is to integrate rich-client features."
"Portlets and FacesClient Components are a winning combination. FacesClient Components can significantly enhance the user's experience with portlet applications since portals serve as a simple, unified access point to Web applications. With FacesClient Components, you can make portlets more responsive, interactive, and attractive."
"In this article, we introduce the technology underlying FacesClient Components and describe how to build FacesClient Components-enabled portlet applications using the beta 1 version of the JSL (JavaScript Library) Emitter layer of the programming model. To help align the development group with the customer, we employ a scenario-based design approach to drive FacesClient Components technology development and features. To demonstrate the advantages of FacesClient Components-enabled applications compared to typical Web applications, we present the IBM® Software Group (SWG) System House Customer Loyalty (CL) scenario."
"The next step is to write a Geronimo deployment plan for the Pluto portal driver, which is the Web application used to run portlets. Plans are XML documents that describe additional Geronimo-specific properties; they replace Java EE deployment descriptors."
"Stefan Hepper is the responsible architect for the WebSphere Portal and Workplace programming model and public APIs. He co-led the Java Portlet Specification V1.0 (JSR 168) and is now leading the V2.0 (JSR 286) effort. Stefan received a Diploma of Computer Science from the University of Karlsruhe, Germany, and in 1998 he joined the IBM Böblingen Development Laboratory."
"Before getting into the example, let's take a quick look at the cooperative tools for JSR 168 portlets available in Rational Application Developer V7."
"With the emergence of an increasing number of enterprise portals, a variety of APIs for portal components, which are called portlets, has been created by different vendors. Having multiple, incompatible interfaces creates problems for application providers, portal customers, and portal server vendors. The Java Portlet Specification, JSR 168, which is being defined by the Java Community Process (JCP), provides a standard for interoperability between portlets and portals. In time, it will help to overcome these problems."
"Your goal here is to fill the portal page with an IFrame, and all of the extra markup from the gridlayout, placeholder, and window (you dropped the titlebar in your portlet properties) is what makes it hard to do what you want. The solution is to create a theme that only uses the page. The theme requires all of the skeleton files listed above, that make up a page for compilation purposes, even though you won't be using them. All but page.jsp should be empty files. page.jsp will look like this:"
"In WLP 9.2, the process of placing your remote portlets must be repeated manually for each environment (typically, with varying names and number of environments, Test, Staging, and Production). Beginning in WLP 10.0, WSRP portlets can be included in propagation as other portal configurations are in earlier versions of WSRP (see "Propagating Weblogic 8.x Portals" for an introduction to portal propagation)."
"All portal frameworks either include a content management system (CMS) or provide an interface to popular CMS applications (or both). CMS is an important topic of its own, and in some case the CMS approach will be all that you need. Or, you may have an external content provider, many of which provide presentation capabilities as well. RSS feeds, blogging, and wiki frameworks are also sources of content. Each of these content sources generally provides some method of presentation that can be used out-of-the-box (OOTB)."
"In this article, I want to share a few solutions I have discovered outside of the standard documentation. Some you can find on BEA's Dev2Dev (though it might take a long time), some came from trial and error, and one came from days of pain following the recommended path to later try almost the total opposite approach and cut my work time by two-thirds. And, I am sure there are dozens (if not hundreds) of other little helpful hints, but these are the ones that I remember the most in almost three years of building many BEA Portal solutions."
"Suppose that Company X has more than 15,000 employees all around the world, and has about a dozen applications ranging from a benefits application for all its employees to an inventory system that tracks inventory data from its suppliers. All of these applications were application-server based and worked as expected. As the company grew larger, so did the need for a single sign-on system to the various applications, and access to SAP as well as mail-based systems over the Web. Although many applications were Web-enabled, they were developed by different development teams using a variety of technologies. This led to proliferation of many URLs and, of course, multiple identity systems. The solution to the problem was to use a portal and aggregate all the applications into a single user interface with integrated identity."
"There's nothing like the feeling of the first production release of a new portal. After weeks or months of hard work and long hours, the application you and your team have put their heart, soul, and talent into is being accessed by real users. E-mails fly around the network with congratulations and the textual equivalents of oohs and ahhs. Your audience is applauding and thanking you for putting many disparate enterprise pieces into one place for easy access and integration. And what makes this euphoria so wonderful is that it only lasts until the first person asks the inevitable portal questions "Can we add this?" And you know they're right to ask for it. Back to work."
"In recent years, many organizations have implemented an enterprise portal to host internal and external applications. There are numerous J2EE portal vendors offering products in this lucrative market. In the past, each of these portal offerings defined their own proprietary APIs for building portlets, application components that run inside portals. Unfortunately, coding to these various APIs translated into vendor lock-in for portlet developers. The Java Portlet Specification (JSR 168) changes this."
"Although the disclaimers usually start later, this article merits one up front: These are not the only solutions to creating workflows in WLP. For example, you're not even going to touch on JSF, or consider the possibility of special considerations in a federated portal architecture. So, don't let yourself be limited by the scope of this article or author's experiences and prejudices. What you will examine is some solutions that are known to work and should give you enough of the basics to implement any set of workflow requirements on WLP."
"Software factories simplify development by defining the people, processes, and platforms to build systems that are in the same product line, such as web applications, from common assets. A portal development factory utilizes a portal framework to accelerate factory setup with its many out-of-the-box components for integrating the architectural elements related to user experience."
"First, you need to put the tool where you can use it. Copy propagation.war from <WEBLOGIC_HOME>weblogic81portallib to the root of your Staging domain (or Integration, if you are moving to Staging). To make sure you put it in the right place, make sure that adminPortal.war is already in the same path you are copying to."
"The basics of portlet development are very similar to those of servlet development. Web application developers who are aware of the basics of portlet development, including the generation of fragments and the separation of action and render requests, should find portlet development fairly familiar. In my next article, I will address the deployment of portlets within Apache Pluto (the reference implementation of the Java Portlet Specification) and show how using Pluto as a lightweight development environment can increase productivity."
"I've found that many of my business and IT partners fail to understand the value of using a portal framework to create consumer, partner, and employee facing web applications. They often ask me "Why portal?""
"Almost every time I think "This doesn't need to be brought up; it is obvious to everyone" during the planning stages of a portal project, I end up bringing it up during the QA or production stage shortly after mentally kicking myself for doing it again. I bring this up now because there are (hopefully) going to be many points in this article you will be saying to yourself (or out loud, if you have my silly habit) "I already knew that". When this happens, you may shake your head in amazement of the obvious, but please read on. If there is only one new performance tip you learn from this article, it will be worth it to not have to work some weekend trying to figure out what you missed. This is no guarantee that you won't be fixing some pitfall not covered here, but at least then you can be mad at me instead of yourself. What else are consultants for?"
"There are many ways to share data between portlets. Oftentimes, portal developers never explore the IPC tools provided by the WebLogic Portal, either because they haven't needed to or did not have the time explore the documentation thoroughly enough. Those with more time on their hands have been able to discover that there are many robust APIs that facilitate developing a loosely coupled portal application. Even though the advantages to doing so are very clear when demonstrated in the WSRP context, they are of benefit even without WSRP."
"In addition to the Container, Portal Driver, and Portal subprojects, Apache Pluto project has developed various utilities that can ease the development of portlets."
"This key stage in a successful project can (and usually should) be run in parallel with building the clickable demo. If a feature is identified as impractical prior to presenting it with a look and feel, it will save a lot of frustration to all by removing it from the demo before someone sees it and thinks it's cool. Although the cool factor can lead to success, with your key success criteria as ROI, cool may be a limitation to success."
"Although portals always consist of multiple pages with multiple styles, many portal implementations have all of the JS and CSS imports defined at a global level. This is incredibly wasteful from a performance perspective. I've seen project teams spend weeks working on how to improve the performance of how their infrastructure loaded a few JS files that were slowing the page load down because a security component was checking certain calls. Both of these files were used by single portlets yet were loaded on every call. Simply scoping them to the portlet that required them would have isolated the load time issue. One was for the login portlet (a necessary security annoyance ... the script, not the portlet) and the other was for a rarely used profile portlet."
"There are two portal standards that enable reuse of portlets in the catalog. The first is a Java Community Process standard called JSR 168 that enables component level reuse of portlets. The second is an OASIS standard called WSRP (Web Services for Remote Portlets) that enables service level reuse of portlets."
"In conclusion, once you have federated your first portlet, you will probably be asked to federate more portlets, then pages of portlets, and possibly books of portlets. Once you start consuming pages and books, you have essentially created a portal within a portal, and someone will want it to act that way, such as sharing data between remote portlets."
"In my last article, "Understanding the Java Portlet Specification," I introduced to the main concepts behind the Java Portlet Specification, JSR-168. This article will walk through the development of a simple portlet application to demonstrate the inner workings of a compliant portlet. The application will highlight only the more important areas of the specification. We will review terminology as it comes up. However, if you are new to the specification, I recommend you read the introductory article first."
"One of the principles I follow as a front-end architect is to always begin with the end user and then work backwards toward the solution. I decided to put this principle into action and start peeling away the layers, beginning with what the end user sees. Through this "outside in" approach, I found that an onion was the simplest way to explain what portal reuse was all about."
"The early portals that succeeded all share one common evolutionary path. They began with a small number (usually one) of services that were well designed and highly desirable to users. Many new portal projects start with the goal of aggregating everything from one common point of access. This may be a goal with a high probability of success if there is a binding theme to "everything," such as the audience (customers, employees, vendors). Trying to go from zero to goal will generally lead to a crash. Contributing factors to this common failure strategy include poor site structure, user-vicious applications, performance issues, and manageability failures. It only takes one of these factors the make a portal a failure and a single release containing a large number of features will almost always lead to at least one of these issues."
"Security is part of every project plan where authentication is required. What isn't often planned for is testing the implementation of security. Does it unnecessarily impact usability? Is there a way around it? Is it implemented everywhere it must be? Often these things are covered very thoroughly in a document describing what should be done, but rarely is it verified that it was done. Once you have planned what you need to secure and how you are going to secure it, be sure to also plan on how you will test that the security solutions are implemented properly and function as needed. Then look at it again and see if you missed something. Even the best planned solutions can be improved on once they have been implemented and reviewed."
