Within Jetspeed, Turbine handles user authentication and page layout as well as scheduling. Portlets can interact with Turbine services with the provided RunData object. Pluggable templating systems, including JavaServer Pages, Cocoon, Velocity and Web Macro provide for dynamic web applications through layouts, XML/XSLT, and XSP for Cocoon. Castor handles progmatic XML manipulation. It is a very handy way to think of XML as a set of Java objects instead of dealing with SAX or DOM.
Jetspeed | Portlet API | Turbine | JServ/Jakarta( or JSDK 2.2 Servlet Engine) | Apache HTTPD (Any HTTP server than supports above)
PortletController <-> PortletControl <-> Portlet relationship | -------------------- Turbine Screen ---------------------- | |------------------ PortletController ------------------ | |---- PortletControl ---- | |---- PortletControl ---- | |-- Portlet --| |-- Portlet --|
Early on it became apparent that a standard way of subscribing to content and managing its presentation was needed.
A example of portlet could be a small little control that runs within a web page and allows the user to query an LDAP server for a set of phone numbers. This could be developed outside of Jetspeed and snapped into the framework by modifying an XML file to point in its direction. Developing your own Portlets is easy and is really just a matter of implementing the "Portlet" interface, providing custom implementations of the Portlet's methods.
A Portlet may also be setup so that it is a Web Applications. Portlets that are configured as applications (getApplication() == true) only run as full screen. You can't have multiple "Portlications" (Portlet Applications) on screen at once. They can be accessed by the user at any time though via the navigation features of Jetspeed.
Portles are provided with a PortletConfig that can be used from within a Portlet to determine runtime configuration information. The Portlet can get parameters it was given to modify its behavior. All the normal Servlet parameters ServletRequest, ServletResponse, or Turbine RunData.
Jetspeed ships with a few Portlet implementations:
Jetspeed can be setup to work with content from all over the Internet. Due to the fact that performance conditions may change on the Internet from minute to minute a high performance cache was needed to keep identical copies of remote documents local. This is the DiskCach. When Jetspeed developers need access to a remote URL they use the DiskCache object to request the document. The DiskCache fetches the URL for them and also stores a copy on the disk. The next time the user triggers a remote document fetch the DiskCache object sees that there is already a copy on the local disk and just returns this version. This is similar in operation to the disk cache that Netscape Navigator/Mozilla and Internet Explorer use.
The only problem with the above scenario is that eventually the content will become out of date. This is where the DiskCacheDaemon comes in. Based on an interval that the Jetspeed Administrator specifies the DiskCacheDaemon(DCD) looks at every URL that is in the cache. If it has been updated remotely the DCD brings down the latest copy so that users always see fresh content.
The FeedDaemon is similar to the DiskCacheDaemon. However instead of fetching URLs from the cache it fetches remote copies of Jetspeed document feeds. Usually updated OCS channels.
Jetspeed is setup so that it can receive and publish XML information. XML input feeds are setup to use Open Content Syndication (OCS). OCS allows developers to markup a list of remote XML documents and their format/namespaces. Jetspeed should be able to except OCS feeds from multiple content providers (XMLTree, Moreover, etc). In the future Jetspeed will republish content through OCS so that 3rd parties can replicate data from Jetspeed implementations.
On top of a Portlet content is rendered by a PortletControl and a PortletController.
A PortletControl provides a "box" (usually an HTML table) that the portlet runs in. The PortletControl handles rendering the title and body of the the Portlet. It is possible for a PortletControl to allow configuration by the end user
A PortletController combines multiple PortletControls (and thus Portlets) to provide an entire Page of information. The PortletController is configured via XML and has almost every option exposed to the user.
Under Jetspeed Portlets are able to take advantage of an advanced caching mechanism. In order to develop more advanced Portlets it is important to understand how this functions.
Portlets are placed within the cache with a handle that is determined via the classname and some of its PortletConfig information including parameters, URL, etc.
More advanced Portlets, ones that are essentially full blown web apps may want to turn off caching. The Portlet interface extends the Cacheable interface. With this you can provide your own isCacheable() method and return false. Jetspeed will not cache your Portlet at this point.
From time to time it may be necessary for a Portlet to request that it be removed from the cache. If this is needed you should provide your own exipire() method that can determine when to expire itself. The org.apache.jetspeed.portal.portlets.RSSPortlet provides a good example of doing this.