IBM Mashup Center

Niral Jhaveri, User Experience Practice Manager

The Web 2.0 world has evolved, and has evolved considerably. It’s no longer about getting data from the universe of information -- but collaborating, publishing, sharing and deriving business intelligence from the data. The landscape of information now consists of smaller fragments of relevant data commonly known as mashups.

So when a bank searches its database for a customer, it no longer expects to get the name of the customer. But instead expects to get back a data grid of all the accounts linked to the customer, a pie chart showing all the different asset holdings (equities, loans etc), a Google map showing the address of the customer and any relevant alerts on the customer account. And that’s not it -- all the information should be seen on a single unified page! Think it’s difficult? With IBM® Mashup Center, you can access the components that you need to create Web 2.0 mashup and application solutions.

What is a Mashup?
Mashups are situational applications which aggregate disparate data. Mashups add a lot of value by associating data elements that are relevant for the users.

With Mashup Center, you can

• Create situational apps which are reusable assets
• Facilitate rapid development of dynamic web applications (widgets)
• Create feeds from numerable data sources
• Empower business users to create and share mashup applications, widgets, feeds, and services
• Provide business intelligence by associating the data elements.
  

The Architecture



Key Components

Catalog: The catalog is a repository. All feed, feed mashup, and widget information is kept in the catalog.

Widget: A widget is a miniature application that is embedded within an HTML page. With a widget, dynamic content is displayed on the page.

Feed: A feed contains XML data. RSS, Atom and XML feeds are available on the Internet. An example of an RSS feed is the top news stories from Yahoo!, available at http://rss.news.yahoo.com/rss/topstories. Feeds in MashupHub can be created using different data sources and then accessed via a URL.

Page: A page is a collection of widgets and other HTML markup that can be displayed in a Web browser. A page can be a mashup application or a regular Web page.

Why should your business use Mashup Center?

Mashup Center is a great tool for rapid assembly of dynamic web applications. The Mashup pages provide a lightweight web solution that combine application and information to solve many different business needs. Around the inter-web there is a fair amount of interest in mashups and many perceive it as better medium.

Mashups provide a user interface to data from variable sources (or feeds) like Web services, enterprise databases, spreadsheets, even BI warehouses like Cognos. Portability is a valuable add-on provided by Mashup Center. Development and product teams can build mashup pages/widgets and easily expose it to any intranet, internet or enterprise portals (even to Microsoft Share point).

With IBM Mashup Center business stakeholders get the freedom to assemble applications that cater to their requirements. Business users can combine, transform and reuse the mashups to create visualizations and provide real-time collaboration.

Mashup wiring enables you to collaborate data for a more unique, dynamic interface. So let’s say for example, a map widget can be wired to several feeds like real estate listing, company address, customer listing, hotels and restaurants. You can also wire the customer listing to its stock prices, relevant market news for the customer etc. You get the idea. Wiring widgets is extremely intuitive and easy to use.

Mashups and WebSphere Portal
Mashups are usually meant for creating applications which are developed in a very short time to target a very specific business problem. It is generally recommended to develop mashups when flexibility and time-to-develop applications is more important than governance and traditional development model provided by WebSphere Portal.

Pre built widgets (like graphs, reports, Google Gadgets) make Mashups more suitable for visualization and aggregation of data from different data sources on a single screen. However for a more transactional based enterprise system, WebSphere Portal is much better suited.

Style of development for portlets and mashups is also different. Widgets can be developed using different tools and have a relatively small and a generic code base. Feeds can be developed visually or by writing native SQL. Developing portlets require a more structured model by incorporating one or more design patterns and/or frameworks (Struts, JSF etc).

WebSphere Portal provides a much broader set of features like Virtual Portal, SSO, Content Management, Collaboration, advanced security model on Pages, Portlets and resources, Portal search, impersonation. These set of features are key differentiators between the WebSphere Portal and Mashup Center.

Mashup applications can run along side or within the portal framework, it all depends on the solution designed. WebSphere Portal 6.1.5 provides the ability to render Mashup Pages and widgets within the portal container. At the same time, Mashup Center can render any Portal page by providing the appropriate URL for that page.

An Example of a Customer Dashboard Mashup

Niral Jhaveri was most recently a Senior Consultant at Prolifics and has extensive expertise in the IBM Lotus, WebSphere and Rational family of products. He has played a key role at several strategic clients by providing technical leadership. Niral has an extensive background in the design and development of IBM WebSphere Portal, SOA and Web 2.0 applications with a proven track record of consulting and architecting solutions for several industry verticals like Finance, Retail, Insurance and Technology.

Mobile Portal – Overview, Architecture and Development - Part II

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.