Portals became popular in the early years of this decade. They promise easier and more standardized aggregation of web applications under a common framework. If you have the need to do such a thing, which is often the case for company intranets, web sites that service customers, or partners etc. portals are very useful.
There are portals that are built on Java technology. There are open source portals such as Pluto, Liferay, eXo Platform (RedHat GateIn), Open Portal, and commercial ones such as Oracle WebLogic Portal, Oracle Web Center (old ALI), Vignette (Open Text) Application Portal, etc.
There are not many public resources, examples and books and tools on how to build generic portlets so I decided to keep a series of blog entries to highlight the fundamentals.
Web Applications, Portals and Portlets
These concepts can be confusing sometimes; For example, lets say we have developed a really nice Java web application for blogging. Other than its obviously amazing features, it is just another web application. It runs on the server, displays in a web browser. When you need for it to do anything, a request is submitted from the client browser to the server. The web application on the server renders a new page and send it back with an http response . The following figure demonstrates this. The web application owns the browser window. It receives the complete http request, and prepares the complete response.
Simple Web Application
In contrast, when we use a portal, our blog application is one of many that will be displayed in the browser. The portal, which is a web application very much like the above, owns the screen real estate. It manages a group of other applications called portlets. Our blog becomes one of these applications. The portal receives the http requests. It partitions this request into many small pieces for each portlet. It receives their responses and includes them in its own response. Our portlet is not in full control. It must learn to co-exist with other portlets.
Portal and the Portlets
Portlets
There are many portals, and therefore as many different APIs and ways to create these portal components, called portlets. Portlets are supposed to be potentially reusable components between many portals. However, the incompatible APIs is a constant problem developers. As a result, IBM and Sun started to define a portlet specification. JSR-168 is a set of APIs for defining portlets for interoperability between portlets and portals. This initial version had some deficiencies suc as inter-portlet communications so it was followed by JSR 286.
The Portlet Package
Every portlet and all the resources it needs are packaged into a standard web application archive (WAR). A war may contain multiple portlets. As usual, the web.xml file specifies things about the web application and a new file named the portlet.xml specifies portlet resources.
Portlet Modes and Window States
A portlet has one mandatory and other optional modes. These are:
- VIEW (Mandatory)
- Display the Portlet
- EDIT
- Customize Portlet properties and preferences
- HELP
- Provide help
Windows states determine how a portlet is displayed on a portal page among other portlets:
- NORMAL
- Sharing the page with other Portlets, the output size shoule be restricted
- MAXIMIZED
- Portlet rendered as the only portlet on the portal page, the output can be richer
- MINIMIZED
- Portlet should display minimal out put or no output
0 comments:
Post a Comment