Samuel Sharaf, Solution Director, West Coast
In the first part of this blog series we covered the high level overview of the IBM Mobile Portal Accelerator offering. In this part, we will review the architecture of the IBM Mobile Portal Accelerator, hereafter, called MPA; and explore its key components, their functionality and how the individual components interact in servicing a typical mobile device request.
Let’s dive right into the architecture: figure 1.0 illustrates the key components of MPA. Note that since MPA installs and runs on top of the IBM Websphere Portal Server, I have illustrated MPA components in conjunction with Portal Server key components.
Figure 1.0 – Simplified MPA Architecture
At the heart of MPA architecture is the Multi-Channel Server, hereafter referred to as MCS. The MCS is the runtime component that transforms XML-based Device Independent Markup Extensions (XDIME) into native markup languages for individual devices. MCS uses the built-in MCS Policy Repository to manage a large number of devices such as PDAs, cell phones, smart phones, and other devices.
The MCS Policy Repository is not a single database or a single file; rather, it is a set of policy files managed by MCS. These MCS policy files define the presentation characteristics (layout, component and theme, and so on) of a device. There are a number of policies defined in MCS. Device, layout, theme, and component policies are the most commonly used.
With the combination of these policy sets defined in MCS repository, MPA can support displaying Portlets in varied types of devices, with flexibility to adapt to various layouts and present with different looks and feels, etc.
If you think about it, it’s a very powerful feature. MPA enables you to write once and use these policy sets to display your Portlets in various mobile devices. Compare it to writing mobile specific applications for iPhone, Blackberry, Nokia etc. Time to market for mobile enabling your Portal application is amazingly short.
Another key component of MPA is XDIME aggregator, which extends the existing portal aggregation support to XDIME/XDIME 2. In Part 1, we discussed that XDIME (XML device independent markup extensions) is an extension of XML for mobile devices and is of course device independent.
Having discussed the key architectural components of MPA let’s switch to the run time interaction model, illustrating how these components interact to service a mobile device request.
Figure 2.0 below illustrates MPA run time interaction model:
Figure 2.0 – Run time interaction Model
The numbers in the figure correspond to key steps in a typical MPA scenario:
1. Write the XDIME Portlet or add XDIME JSPs to an existing Portlet.
2. The resulting navigation hierarchy defines nodes (pages, labels, URLs, and Portlets) and extended attributes that specify required device capabilities and type for each node. Navigation nodes and attributes are stored in the Portal Model.
3. When the Portal receives a request from a mobile device, the appropriate markup is determined by comparing the User-Agent string to configured Portal clients. MPA clients are configured with XDIME support, so the portal passes the request to the XDIME Portal Filter. The filter then invokes the XDIME Aggregator to process the request.
4. The XDIME Aggregator queries the Portal model to determine navigation and Portlet availability based on the user and the extended attributes of each node. If the request is for a Portlet node, a PortletRequest object, containing request-specific data, is passed to the Portlet.
5. The Portlet Container invokes the Portlet with the PortletRequest. XDIME Portlets render their content in XDIME and return the content to the aggregator via a PortletResponse object.
6. Aggregated XDIME markup for the requested navigation or Portlet is returned to the Portal Filter, which passes it to the Multi-Channel Server. MCS transforms the XDIME content to device-specific markup by matching it with policies in the repository of Mobile Device Profiles.
7. The Portal Filter inserts the device-specific content in the ServletResponse object for delivery to the mobile device.
The above defined interaction model is simplified and doesn’t go into intricate details. If you would like to read more about it, please refer to the IBM Mobile Portal Accelerator info center (http://publib.boulder.ibm.com/infocenter/mpadoc/v6r1m0/index.jsp).
In the next part of this blog series, we will use the MPA toolkit to create a simple Portlet. Get ready to put your developer’s hat on!
Samuel Sharaf is a Solution Director at Prolifics on the West coast with real world customer expertise with Portal implementations, Dashboard, Forms and Content Management. Sam also has expertise with migrating applications from non-IBM platforms to IBM WebSphere Application and Portal Servers.
In the first part of this blog series we covered the high level overview of the IBM Mobile Portal Accelerator offering. In this part, we will review the architecture of the IBM Mobile Portal Accelerator, hereafter, called MPA; and explore its key components, their functionality and how the individual components interact in servicing a typical mobile device request.
Let’s dive right into the architecture: figure 1.0 illustrates the key components of MPA. Note that since MPA installs and runs on top of the IBM Websphere Portal Server, I have illustrated MPA components in conjunction with Portal Server key components.
Figure 1.0 – Simplified MPA Architecture
At the heart of MPA architecture is the Multi-Channel Server, hereafter referred to as MCS. The MCS is the runtime component that transforms XML-based Device Independent Markup Extensions (XDIME) into native markup languages for individual devices. MCS uses the built-in MCS Policy Repository to manage a large number of devices such as PDAs, cell phones, smart phones, and other devices.
The MCS Policy Repository is not a single database or a single file; rather, it is a set of policy files managed by MCS. These MCS policy files define the presentation characteristics (layout, component and theme, and so on) of a device. There are a number of policies defined in MCS. Device, layout, theme, and component policies are the most commonly used.
With the combination of these policy sets defined in MCS repository, MPA can support displaying Portlets in varied types of devices, with flexibility to adapt to various layouts and present with different looks and feels, etc.
If you think about it, it’s a very powerful feature. MPA enables you to write once and use these policy sets to display your Portlets in various mobile devices. Compare it to writing mobile specific applications for iPhone, Blackberry, Nokia etc. Time to market for mobile enabling your Portal application is amazingly short.
Another key component of MPA is XDIME aggregator, which extends the existing portal aggregation support to XDIME/XDIME 2. In Part 1, we discussed that XDIME (XML device independent markup extensions) is an extension of XML for mobile devices and is of course device independent.
Having discussed the key architectural components of MPA let’s switch to the run time interaction model, illustrating how these components interact to service a mobile device request.
Figure 2.0 below illustrates MPA run time interaction model:
Figure 2.0 – Run time interaction Model
The numbers in the figure correspond to key steps in a typical MPA scenario:
1. Write the XDIME Portlet or add XDIME JSPs to an existing Portlet.
2. The resulting navigation hierarchy defines nodes (pages, labels, URLs, and Portlets) and extended attributes that specify required device capabilities and type for each node. Navigation nodes and attributes are stored in the Portal Model.
3. When the Portal receives a request from a mobile device, the appropriate markup is determined by comparing the User-Agent string to configured Portal clients. MPA clients are configured with XDIME support, so the portal passes the request to the XDIME Portal Filter. The filter then invokes the XDIME Aggregator to process the request.
4. The XDIME Aggregator queries the Portal model to determine navigation and Portlet availability based on the user and the extended attributes of each node. If the request is for a Portlet node, a PortletRequest object, containing request-specific data, is passed to the Portlet.
5. The Portlet Container invokes the Portlet with the PortletRequest. XDIME Portlets render their content in XDIME and return the content to the aggregator via a PortletResponse object.
6. Aggregated XDIME markup for the requested navigation or Portlet is returned to the Portal Filter, which passes it to the Multi-Channel Server. MCS transforms the XDIME content to device-specific markup by matching it with policies in the repository of Mobile Device Profiles.
7. The Portal Filter inserts the device-specific content in the ServletResponse object for delivery to the mobile device.
The above defined interaction model is simplified and doesn’t go into intricate details. If you would like to read more about it, please refer to the IBM Mobile Portal Accelerator info center (http://publib.boulder.ibm.com/infocenter/mpadoc/v6r1m0/index.jsp).
In the next part of this blog series, we will use the MPA toolkit to create a simple Portlet. Get ready to put your developer’s hat on!
Samuel Sharaf is a Solution Director at Prolifics on the West coast with real world customer expertise with Portal implementations, Dashboard, Forms and Content Management. Sam also has expertise with migrating applications from non-IBM platforms to IBM WebSphere Application and Portal Servers.
