Using WebSphere Everyplace Mobile Portal, Part 1: Extending WebSphere Portal to a Mobile Audience

This article, the first in a series on WebSphere® Everyplace® Mobile Portal, provides an overview of Mobile Portal, and shows how you can use it to satisfy your mobile device requirements. This article focuses on XML Device-Independent Markup Extensions (XDIME) and the integration of Multi Channel Server (MCS) into WebSphere Portal Server. After reading the article and checking out the sample, you should have a basic understanding of XDIME and how it can be used by a portlet application.


Thomas Burke (, Advisory Software Engineer, IBM

Thomas BurkeThomas Burke is a software engineer on IBM Pervasive Computing's WebSphere Everyplace Mobile Portal development team in Research Triangle Park, NC. When he's not working, Thomas enjoys attending Solo II events in his 1988 RX-7 and performing miscellaneous home improvement projects.

Kristen Balhoff (, Software Engineer, IBM

Kristen BalhoffKristen Balhoff is a Software Engineer on IBM Pervasive Computing's WebSphere Everyplace Mobile Portal development team in Research Triangle Park, NC. Along with her work, she enjoys training for triathlons.

24 October 2005 (First published 10 November 2004)


WebSphere Everyplace Mobile Portal (hereafter called Mobile Portal) is an extension of WebSphere Portal Server (hereafter called Portal). Mobile Portal provides several extensions that enable Portal to support rich content on a wide variety of mobile devices at minimal cost. The list below offers a quick summary of the features provided by Mobile Portal:

  • Integration of the Multi Channel Server (MCS) into WebSphere Portal to add support for XDIME
  • An XDIME aggregator, which manages the presentation of portlets
  • Preload notice support, which is a page that may be inserted "in front of" a resource based on a set of rules. For example, a user may request a portlet that would cause additional charges to appear on his or her account. A preload notice could be used to warn the user, based on a set of rules defined for the preload notice, that this will cause an extra charge on their bill. A preload notice can be set up to appear the first time a user accesses the portlet, once a day, each time they access the portlet, and so on
  • Content filtering based on device capabilities
  • A Manage Mobile Pages portlet, which is used to manage portal navigation, as well as the aforementioned Preload Notice, Content Filtering, and Metadata support.
  • Metadata support for navigation nodes. The Manage Mobile Pages portlet can be extended to allow metadata configuration for objects in Portal. This metadata may be used by a customized aggregator to provide certain specialized functions, such as icons to represent navigation nodes, alternate titles for mobile devices
  • An MCS API to access device characteristics
  • WebSphere Everyplace Mobile Device Update, a subscription service
  • A toolkit to support XDIME portlet development

This article focuses on XDIME and the integration of MCS into Portal. Future articles in this series will go into more detail about some of the other features in the list. For more information about WebSphere Everyplace Mobile Device Update, refer to the Mobile Portal Information Center.

What is XDIME?

XDIME is an abstract, device-independent, markup language that can be processed and converted into a wide variety of markup languages, such as WML 1.1, WML 1.3, XTHML Basic, XHTML-MP, HTML 3.2, HTML 4.0, and others. Using XDIME, an application can generate one markup to support a vast array of devices. If the devices don't support the same markup language, XDIME can be transformed into the appropriate language for each device. This frees developers to focus on the business logic and content of their applications, rather than the tedious details of accommodating the nuances of each markup language. The business logic becomes the deliverable, rather than the multi-device support. For example, a developer can write a single version of an application in XDIME that can be converted into HTML for a PDA, WML for a mobile phone, or XHTML for a smart phone.

MCS is a Mobile Portal component that processes XDIME to render the various markup languages. As shown in Figure 1, MCS accepts XDIME as input and produces the markup language suitable for the device making the request.

Figure 1. MCS processes XDIME to produce a device's preferred markup
Simplified View: MCS processes XDIME to produce a device's preferred markup

At this point in the explanation, it seems like MCS magically converts XDIME into WML, XHTML, or whatever markup the device wants, but in reality MCS alone doesn't have enough information to determine what markup to send back to the device. The accept header isn't reliable because devices are often inaccurate about what content they accept. This is where the MCS policy repository comes in. This repository, at the core of MCS, contains descriptions of hundreds of devices, with each description containing hundreds of attributes. Each of these descriptions, called a device policy, is associated either with a class of devices (for example, Mobile, Handset, Clamshell, and so on) or with a specific device (for example, a specific model number from a specific manufacturer). Since new devices are frequently introduced, the device repository is updated regularly to keep it current. Customers can keep up to date with the latest version of the device repository by way of a Mobile Device Update subscription

MCS employs a specific-to-general hierarchical approach for matching policies from the device repository to a device. Starting with the most precise definition of a device, such as the specific model and manufacturer, MCS traverses the device hierarchy towards more generic definitions until it finds a matching policy. For example, MCS can search for a certain model of device, then the manufacturer, then the type of device, and so on, until it finds a suitable match. This is why certain policies described later in the article, such as layout, component, and theme policies, can be defined at any level of the hierarchy of the device tree. It is also why it is always a good practice to have a top-level generic policy as last resort, catch-all policy.

Along with the many physical characteristics of each device, the device repository also stores each device's preferred markup language. Armed with this information, MCS is a step closer to converting XDIME into device-specific markup, but more flexibility is added by introducing the concept of a layout.

Adding flexibility with layouts

Devices targeted by an XDIME application may have significantly different screen sizes, which makes it difficult to code a single page that would render appropriately on any device. For example, assume you have two devices where one has four to eight times more pixels than the other. How do you present the right amount of relevant information on each device? Normally a developer would accommodate these differences by hard-coding the JSP to produce different markups (usually a "lowest common denominator" approach for each markup language), and prune the content based on the device making the request. If a wide range of devices is to be supported, this becomes a problem with numerous screen size, markup, and device capability combinations to support. Managing device-specific presentation can quickly become very messy. MCS solves this problem with device layout policies that manage presentation and tailor content to suit the screen sizes and capabilities of various devices.

For example. let's assume you're creating a stock quote application that must render nicely on a PDA, XHTML handset, and WML handset. Also assume that the requirements state that if the page is displayed on a PDA it should contain the company name, ticker symbol logo, current stock price, a graph of the stock's performance over the last three months, and additional company info. The XHTML handset must display the company name, ticker symbol, current price, and company logo. The WML requirements specify that the company's name, ticker symbol, and price should appear.

Company NameYesYesYes
Company TickerYesYesYes
Current PriceYesYesYes
Company LogoYesYesNo
Additional Corp. InfoYesNoNo
Stock ChartYesNoNo

This example is a good use case for device layouts, because the content is different for each of the device classes that we mention.

After inspecting the requirements table above, you probably assume that the portlet's view JSP will need to contain logic that can prune out information that must be omitted for the XHTML and WML devices, but with XDIME, that's not the case. The JSP code that is invoked for any of the devices can actually emit the exact same markup, the data pruning will take place when the markup is applied to the layout of each device.

Consider the XDIME sample listed below:

Listing 1. XDIME emitted by portlet
<canvas layoutName="/stockLayout.mlyt" type="portlet" class="body">
    <pane name="Name">
        <b>JK Telecom</b>
    <pane name="Ticker">
    <pane name="Price">
        192.73 +0.25
    <pane name="Logo">
        <img src="/logo.mimg" />
    <pane name="Chart">
        <img src="/chart.mimg" />
    <pane name="Additional">
        JK Telecom is a industry leading communication services provider. 

As mentioned above, this XDIME markup is applicable for all of the devices and the pruning takes place when the markup is applied to the layout. Since device layouts are defined in association with device policies, you can have a policy defined for the Handset class, which will be used for the XHTML devices, one for WAP Handset, which will be used for WML devices, and one for Master, which will be used for the PDA and any other devices that don't meet the criteria of the first two classes. The figure below shows the first panel of the layout creation wizard, demonstrating the hierarchical nature of the device repository.

Figure 2. Creating a device-specific layout
Creating a device-specific layout

With the device layout approach, the layout determines what information is sent to the device and where it appears, relative to other information, on the screen. As you can see by the layouts shown below, the layouts for the XHTML and WML devices omit panes that are present in the Master layout; this causes the layout to omit the information contained within the pane. It is also okay for a layout to contain a pane that is never referenced by the XDIME document. These conditions are common practice when using XDIME and will not cause MCS to generate an error.

You may notice that the panes appear in different locations in each of the layouts. This demonstrates some of the additional flexibility provided by MCS. Layouts may change drastically between different device classes, but that doesn't mean that the content provided within the XDIME has to change at all. As you can see by inspecting the layouts created for the PDA, the content will likely be much richer than content presented on either of the other devices.

Figure 3. Device Layouts for Stock Sample Portlet
Device Layouts for Stock Sample Portlet

An XDIME document and a device layout are the most basic requirements that you must have to create a Mobile Portal portlet. But what if you want to jazz your portlet up with an image? You may remember the stock quote example above referenced images, but did you notice that the <img> tags looked a little strange? That's because MCS adds even more flexibility by introducing the concept of component policies.

Jazzing it up with components

Images are one of the many types of component policies that MCS uses. A component policy describes content, such as an image, but provides the flexibility of referencing the content in an abstract manner (hence the src="/logo.mimg" attribute in the <img> tag above). With this approach, you can reference a single abstract component name (for example, /logo.mimg) and have it map to several image assets.

For example, you may want to display an image that is 80x80 pixels on a PDA (logo80x80.jpg), but consider that too large for an XHTML handset, so you decide 40x40 (logo40x40.jpg and logo40x40.gif) works best for that type of device. Also, if a WML device supports WBMP images, you may want to render a 20x20 WBMP (logo20x20.wbmp). The image policy you create could associate logo80x80.jpg with the Tablet class of devices (a PDA is a subclass of Tablet in the device repository), logo20x20.wbmp with the WAP Handset class of devices, and the logo40x40 images as generic images. That way, MCS will pass the image URL to the appropriate device.

You should always create a couple of generic images, one JPEG and one GIF, because some devices will accept JPEG images, and some will accept GIF, but not both. Therefore, an image component with both assets defined can be rendered on a broader range of devices. Also, because the images are generic and may render on a wide range of devices, they serve as a catch-all for devices that do not map to other device-specific image assets.

MCS also has similar capabilities with other components. Mobile Portal supports Audio, Chart, Dynamic Visual, Image, Link, Rollover Image, Script, and Text components.

Adding style with themes

After considering the XDIME markup, layouts, and components, the next logical step is to apply style information to the content targeted for a device, similar to CSS for HTML. MCS provides this capability by introducing the concept of a theme policy (not to be confused with a Portal Theme). Themes may be defined against any level in the device hierarchy and get converted into the appropriate style information when the target markup is sent to a device. For example, the style may be in the form of a CSS, or inline, as appropriate. This capability allows a developer to specify different font weights, colors, alignment, and so on, for elements when they are sent to different devices. For example, a PDA may use a larger font than an XHTML handset, since it has a larger screen.

A default theme is specified by the XDIME aggregator, but the portlet developer may override the theme by creating one and specifying it in the canvas tag for the portlet. However, we recommend that portlet developers use the aggregator's default theme and make changes to it as needed, to prevent excessive style information from being passed to the device and consuming much of the device's input buffer.

Putting it all together: How is MCS used in Mobile Portal?

The MCS component of Mobile Portal is implemented in the form of a portal filter. If you study the diagram below closely, you'll notice that WebSphere Application Server is the first to receive the HTTP request from a device. Application Server creates a request object and passes it to Portal. At this point, Portal needs to determine which aggregator it should route the request to, so it traverses a list of client profiles (Supported clients Portal admininstration page) and compares the user agent string in the request to regular expressions in the client profiles until it finds a match. In our case, we assume a match was found and the XDIME aggregator gets invoked. Since MCS is configured as a Portal filter for the XDIME markup, it is inserted in front of the XDIME aggregator and is invoked with the ServletRequest and ServletResponse objects. The filter, after doing some preliminary processing, invokes the XDIME aggregator with a wrappered request and wrapped response. After the XDIME aggregator finishes its job with the response (including the contribution of portlet markup to the XDIME document) it returns to MCS. At this point the response contains a complete XDIME document that is ready for processing.

Figure 4. The MCS run-time in Mobile Portal
Figure 4. The MCS run-time in Mobile Portal

During the lifecycle of the request, MCS uses the device's user agent to look up its characteristics in the device repository. It then takes the XDIME from the response, and converts it into the device's preferred markup by running a transform on the XDIME. Inputs into this transform include the layout defined for the device, any component policies that are included in the XDIME that are defined for the device, and theme information specified for the device. Once the transform is complete, the generated markup is placed into the response and sent to the device.

By applying the layout, component, and theme policies for the target device, the resulting response from Mobile Portal is device-specific, presentation-aware markup. Although the application developer only had to create one XDIME version of the content and any policies referenced by that XDIME, Mobile Portal provided a rendering of the portlet application tailored to any type of device. Putting it all together, here is the final result showing the display of the sample stock quote application on a variety of device simulators:

Figure 5. Portlet rendered on simulators for three devices
Figure 5. Portlet rendered on simulators for three devices


As you've learned in this article, Mobile Portal provides extended features to WebSphere Portal to enable the delivery of device-independent content mobile devices. This functionality is achieved by developing content in XDIME, which can be processed into many supported markup languages. XDIME is converted to the appropriate markup according to the device policy for a client.

Besides generating suitable markup, Mobile Portal applies device-specific layout policies that provide the flexibility to present device-relevant content. Content in XDIME is associated with a specific region or pane, which can be displayed or omitted according to the layout policy. Mobile Portal also uses component policies to associate the appropriate version of a digital asset, such as an image, to the target device. In addition, theme policies can customize the look and feel for different types of devices.

Finally, Mobile Portal takes advantage of WebSphere Portal to recognize mobile devices, generates device-specific content, and achieves a write-once, render-many programming model.

Future articles in this series will include an article that demonstrates how to create a simple portlet using WebSphere Studio Application Developer and an article presenting all of the component policies provided by Mobile Portal and demonstrating how to use them.





developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into WebSphere on developerWorks

ArticleTitle=Using WebSphere Everyplace Mobile Portal, Part 1: Extending WebSphere Portal to a Mobile Audience