XML

Enterprise portals provide a single interface to aggregated and componentized information. They significantly reduce the navigational issues inherent with Web sites and make it easier to publish information from disparate sources. The basic building blocks of enterprise portals are portlets, which are reusable, personalized Web components displaying content from various data sources.

One data source, XML, has become a widely used tool in enterprise portals. The work needed to integrate XML with a portal is often considered a highly technical and time-consuming task. For example, to publish XML into a portal, developers usually think that programming is their only option. They go through the entire process of using Beans, compiling XML Schemas, and processing and binding XML instance documents. Developers go through this process without considering the level of complexity needed to publish the content.

This article covers the options available to both page designers and developers to simplify XML publishing. These options range from using portlet building tools that are highly productive and geared toward page designers, to coding using the Java portlet standard Java Specification Request (JSR) 168, which offers developers complete control over the portlet application.

Portlet Building Tools Ease Portal Development
Today, creating portal pages does not require you to be highly technical. It is a natural and important step in the evolution of portals to give nontechnical users, such as page designers, the power of presenting information declaratively from complex sources. The use of wizard-based tools in developing portal pages, running in the browser or an integrated development environment (IDE), is the first step along this path. These graphical tools are built with the page designer in mind and provide fairly simple, but effective publishing mechanisms. These tools often rely on abstracted, reusable data sources, such as XML, Web Services, CSV, or SQL. XML, one of the newest reusable data sources for portals, originally designed for large-scale publishing, plays an important role in integrating data into an enterprise portal.

A few of the most important characteristics and capabilities of portlet building tools include:

• Leveraging existing XML and Web services feeds and rendering directly into the portal
• Accessing XML and Web services feed through parameterized URLs
• Creating reusable portlets with events
• Accessing protected URLs
• Caching portlets
• Supporting filtering and layout formatting
• Accessing XML through the Java Portlet Standard JSR 168

Portlet building tools play an essential role in developing enterprise portals as manually implementing some or all of the functionality in the list would require extensive coding. Also, programming requirements for enterprise portals tend to exclude the page designer from the portlet building process.

Leveraging existing XML feeds and rendering directly into your portal
When integrating XML data or any other type of data source into an enterprise portal, portlet building tools offer choices for page designers. Many companies offer XML feeds for viewing the latest product information or for providing up-to-the minute news feeds. Portals can leverage these XML feeds and integrate the content as a portlet and publish it directly onto a portal page without coding. Often these tools or utilities automatically process the content from the XML feed and offer many different types of layouts to display the content.

The feed from XML-Journal shown in Listing 1 is an example that provides the latest news information relating to XML.

Using the wizard, a page designer provides the URL to this RSS feed (www.sys-con.com/story/category.cfm?id=1080&rss=1 ) and an optional XSL filter to transform the data. The portlet tool consumes the XML, applies any necessary filters, and maps any parameters if necessary (see Figure 1).

Once the XML has been consumed by the tool and the page designer selects a layout appropriate for this feed, the tool creates the portlets, which are added to the portal page. To the end user, this news feed is just another portlet on the portal page (see Figure 2).

Accessing XML and Web services feeds
There is often a need to access XML and Web services feeds through parameterized URLs. This need is derived by a requirement to provide end-users with dynamic content or to filter content rendered on a page based on the user currently logged-in. Portal features enable page designers and end-users to drive content through a URL in the form of page parameters or private portlet parameters. The page parameter drives content to all portlets receiving this parameter and private portlet parameters target a specific portlet on a page. The parameter that needs to be passed along with the URL, should often be a portal system variable, such as the name of the portal user.

At other times the parameter is a personalization parameter. Let's suppose the portlet retrieves weather information from the following URL: myweatherinfo.com/rss_weather_info.xml. To be able to retrieve personalized weather information, the requested URL must contain a parameter indicating the ZIP or area code: myweatherinfo.com/rss_weather_info.xml?zip=94065.

In this scenario the portlet should support user-level personalization, so that users can specify the geographical location in which they are interested. Let's consider another scenario. When the URL of the portal page is invoked, a parameter called zipcode is passed to it indicating that the page should display information relevant to that particular ZIP code. In this case it is not the portal user, but the calling environment, that specifies the value of the parameter and passes it to the portal page: myportal.com/page?zipcode=94065 (see Figure 3). The parameter that is passed to the portal page has to be passed further to the portlet. The task of mapping the page parameter, zipcode, to the portlet parameter, zip, needs to be performed by the page designer.

Note: The ability to map page parameters to portlet parameters declaratively is a portal feature. As a result of this, the portlet can contact the data source and pass the required parameter to it: myweatherinfo.com/rss_weather_info.xml?zip=94065. As this example illustrates, portlet building tools can empower non-technical page designers to map portal page parameters to portlet parameters, ensuring the seamless information flow.

Creating reusable portlets with events
Making hyperlinks more dynamic than they are in the HTML world helps enterprise portals elevate interactivity and reusability to a higher level. Let's take a news portlet that uses an XML feed as its data source as an example. The portlet contains a hard-coded hyperlink that takes the users to another portal page. Upon realizing how useful your portlet is, you may want to add another instance of it to a portal page. It works fine as long as you don't want to navigate your users from the two portlets to two different portal pages. Different portal vendors provide slightly different solutions to this problem. A typical solution for making portlets interactive and reusable is to use portlet building tools to create events.

Any user action performed in a portlet, such as a clicking on a hyperlink or a button, may trigger an event in the portal. Page designers then have the ability to map events to actual links: portal pages or physical URLs. When the portal receives the event, it navigates the user to the page as specified by the page designer (see Figure 4).

Access to protected URLs
The XML data source you may want to use in your portlet is often not publicly accessible. The ideal wizard-based tool should provide support for XML data sources that require basic, or form-based, authentication.

Since the same data source could be accessed by a number of portal users, authentication on a per user basis should also be possible. The user dependent authentication information may be stored in the portlet's preference store or in the repository (usually LDAP repository), where the portal user information is being stored.

Caching portlets
The ability to cache XML-based portlets is key to serving portal pages in a timely manner. It is especially true as the slowest portlet usually slows down the entire page. The simplest form of caching is expiry-based caching. Let's suppose you have to display weather or news information in your portlet. Although this type of data changes rapidly, the performance gained by caching the portlet content can result in an approximately 10-minute latency, which is probably acceptable to your users.

The importance of portlet caching increases dramatically when the data source itself (e.g., the provider of the XML feed) has performance issues. As long as the cached portlet content is displayed on the portal page to the end users, the delay that users would experience by accessing the news feed directly is eliminated.

Supporting filtering and layout formatting
Options such as filtering and layout capabilities provide a more productive experience when publishing XML content. Some filtering capabilities include the ability to define conditions, ordering, and limiting the size of the result set.

Wizard-based portlet building tools tend to be limiting on the user interface front. They are expected to offer a wide variety of flexible views (e.g., tabular, chart, tree, scrolling news) and pagination support. Some may also provide APIs to create custom layouts.

Accessing XML through Java using the Portal Standard JSR 168
Occasionally, there is a need to extend the functionality provided by portlet building tools so that developers can have more control over the integration with the application or Web service. Programming provides developers with more control to publish with XML or to use XML to manipulate Web services. Developers can either extend the portlet already created by the wizard-based tool or they can program the portlet from the beginning and have total control over the application. Extending the portlet created by the wizard-based tool offers developers with a more productive solution instead of programming from the start. The page designer can initially create the content and then send additional requirements to the development team to extend the layout of the portlet.

When creating portlets using XML where full control is needed and where the portlets will be rendered on multiple portals, developers can program portlets using the portlet standard, Java Specification Request (JSR) 168.

JSR 168 is a specification that defines a set of APIs to enable interoperability between portlets and portals, addressing the areas of aggregation, personalization, presentation, and security. JSR 168 defines:

• The portlet API (portlet container) provides a runtime environment to invoke portlets. Developers use this API to program portlets that render on compliant portals.
• URL-rewriting mechanism for creating user interaction within a portlet container.
• Security and personalization of portlets.
• A common API for interoperability and portability of Java portlets between portal vendors.
• Access to a variety of XML registries.

Since JSR 168 is a standard for building Java portlets, developers have access to all of the APIs of Java 2 Enterprise Edition (J2EE). Java provides the building blocks for XML publishing, developing Web services, and applications that access Web services. Using JSR 168 and J2EE, developers can write interoperable Java portlets that access and display data in an XML document or parse and transform XML documents. These portlets can be rendered on any portal platform that supports JSR 168.

Some available APIs include:

• Java API for XML Processing (JAXP)
• Java Architecture for XML Binding (JAXB)
• Java API for XML Registries (JAXR)
• Java API for XML-based RPC (Jax-RPC)

Conclusion
As this article has described, XML publishing into a portal can be a fairly easy process. Page designers can use portlet building tools that are very productive and simplify the process of integrating applications and content that could normally take weeks to code. For developers, Java offers a viable solution to XML publishing into a portal with the portal standard, JSR 168. JSR 168 provides all the APIs for publishing XML with Java as well as the APIs to render that Java application as a portlet into the portal.