Mashup business scenarios and patterns: Part 2

This article is part 2 in a two-part series that discusses the relationship of usage and architectural patterns that can be used for deploying enterprise mashups to address business needs. This article addresses the solution architecture and the architectural patterns used to implement the business scenarios and usage patterns covered in the initial article, "Mashup business scenarios and patterns: Part 1."

Holt Adams, Executive IT Architect, IBM

Holt Adams is an Executive IT Architect in IBM software's Emerging Technology group, where he currently supports IBM's jStart Program and Customer Innovation Team. His skills allow him to play the roles of both solution architect and engagement manager to be an effective catalyst in customer adoption of emerging Internet technologies. He has experience as a practitioner in both the business and technical aspects of customer engagements from activities that include lead generation, business qualification, requirements management, solution architecture, solution design, and contract negotiations. As an IT Architect, Holt refines customer business needs to IT requirements that can be addressed with IT capabilities of emerging technologies in building leading-edge solutions. During his tenure in the jStart Program and other services-related jobs, his technology portfolio has included wireless/pervasive computing, Internet infrastructure, Java/J2EE, XML, Web services/SOA, open source, Web 2.0, social networking, and enterprise mashup technologies.



29 June 2009 (First published 03 February 2009)

Also available in Chinese Japanese

Editor's note: Know a lot about this topic? Want to share your expertise? Participate in the IBM Lotus software wiki program today.

Introduction

The use of mashups to address enterprise needs has progressed in the adoption curve, and its growth rate is becoming exponential. The technology is being leveraged in many industries to address unique business scenarios utilizing common usage and architectural patterns.

Often, a solution for one industry can be deployed horizontally to cover other industries with similar needs. The differences in the mashup solutions are the roles of the users and the data sets being aggregated to create unique value. In many cases, the usage patterns (for example, the capturing of search criteria, rendering of data within the user interface (UI), updating of secondary tables based on primary data selection, manipulating of data, and communicating with others) are similar, but the business goals and objectives being addressed are distinctive for each customer.

The design and architectural options of mashups are determined by the mashup platform chosen for implementation. Business scenarios that leverage a large set of common usage patterns can be implemented using a small set of design or architectural patterns (for example, the use of RSS and ATOM feeds, invocation of REST services, widget communications through the pub/sub model, aggregation of data sources through centralized hubs, and data filtering at data and service sources).


Introduction

The IBM® Emerging Technology team (jStart) has been working with more than 50 customers and business partners for the past few years to leverage mashup technologies (for example, QEDWiki and IBM Mashup Center) in proof-of-Concept environments to address business needs in validating the usefulness of the technology. As outlined in part 1 of this series, the jStart team’s experiences have resulted in common scenarios and solution implementations of the technologies and have been documented as formal work products. These artifacts are used with early adopters to promote the value proposition of enterprise mashups and are the basis for this series of articles.

As in all solution development disciplines, reuse of assets such as methodologies, design concepts, and components is common practice and is encouraged to promote efficiencies and to reduce development costs and schedules. When these assets are reused in common, repeatable ways they are often referred to as patterns. The term is generic and can be used to describe business scenarios individually or in combination, usage interactions, architectural designs, and implementations.


Business scenarios as opposed to usage and architectural patterns

Part 1 of this series covered business goals and scenarios that included customer service, resource management, personal dashboard, personal communications, consumer services, enterprise resource locator, field service support, and supply chain management scenarios used across multiple industries. The scenarios were described as high-level business activities that address specific business goals. The realization of the scenarios entails business users performing tasks through interactions with specific technology in common ways that are referenced in this series of articles as usage patterns. The usage patterns outlined in the earlier article included common steps exercised by individuals (for example, log into mashup, enter search criteria, select data from tables, mouse over images, add or update data records) while using features or controls of the mashup interfaces. When a user interacts with a control or data presented in a mashup, some of the actions performed result in processing by the mashup that changes the rendering of the UI itself (for example, navigation and visibility of the controls), invokes services or data sources acquired from another vendor, or displays additional information and images within the mashup.

Figure 1. Scenarios and patterns
Scenarios and patterns

The implementation of the supported behaviors and interactions by a mashup application is dictated by its underlying architecture. Mashup applications are constructed from components called widgets that are linked together to create a UI and model for aggregating data that a user can view and act upon. These widgets can be visible for rendering the user interface or hidden for performing background processing. Similarly, visible widgets can also perform or initiate background processing.

The linkage (programmatic coupling or communications) between widgets is the mechanism by which the mashup application provides an interactive and responsive experience to the user (for example, clicking a control of one widget resulting in data refresh within other widgets or the rendering of additional widgets within the UI). How the linkage is defined and implemented depends on the mashup application platform.

The platform also dictates how architectural patterns can be implemented; this topic is addressed in this article. Core infrastructure patterns include publish/subscribe messaging and security. Other architectural patterns define common ways of implementing data retrieval, aggregation, and filtering of data while still others outline designs for the integration of external systems (for example, user registries for authentication).

These architectural patterns provide the design by which the usage patterns discussed in part 1 of this series are implemented to enable the mashup’s behaviors and user interactions. In summary, the usage patterns from part 1 were categorized as follows to support the interaction model illustrated in figure 2:

  • Access control and personalization patterns
  • Rendering mashup UI and retrieval of data patterns
  • Review and manipulation of data patterns
  • Communication with other patterns
Figure 2. Early adopter interaction model
Early adopter interaction model

Most business scenarios, regardless of their business goals, user roles, data, or industry focus, can be represented in the interaction model shown in figure 2.


Architectural patterns

A mashup application is typically characterized as a lightweight integration of application widget components (for example, deployed as an HTML page with associated widgets packaged as WAR files) rendered within a browser. Architectural patterns provide the high-level designs for constructing mashup applications and show the flow of events between solution components. They are somewhat platform independent and offer a framework for implementing one or more business scenarios that are realized through the usage patterns covered in the previous sections.

IBM Mashup Center

IBM Mashup Center has been used to implement the business scenarios and usage patterns outlined previously. IBM Mashup Center consists of IBM Lotus® Mashups, IBM InfoSphere™ MashupHub, and IBM Lotus Widget Factory along with a shared repository (catalog) as illustrated in figure 3.

Figure 3. IBM Mashup Center
IBM Mashup Center

Both the Lotus Mashups and InfoSphere MashupHub offerings have browser-based tooling for the creation and management of mashup applications and their components. In addition, Lotus Widget Factory provides an environment for creating widgets that are deployed in Lotus Mashups and registered in InfoSphere MashupHub. The Lotus Mashups offering provides both a mashup assembler for creating mashup applications (widgets are mashed and wired together in a browser) and a lightweight mashup server for the deployment and operation of mashup applications. The mashup server loads a mashup enabler to the browser that provides a mashup runtime where the mashup components are executed and managed during their operation. InfoSphere MashupHub provides an environment to share Web, enterprise, departmental, and personal information for mashup applications. The hub provides the facilities to create feeds and feed mashups that are utilized by mashup applications. All three offerings use Web technologies such as HTTP, JSON, XML, Java™Script, Atom, and RSS to deliver relevant content to users.

Figure 4. IBM Mashup Center architecture
IBM Mashup Center architecture

In figure 4, the Feed Creation, Data Mashups, and Catalog components are provided by InfoSphere MashupHub and enable users to register widgets, mashup pages, and existing feeds accessible within the intranet or over the Internet. Similarly, the InfoSphere MashupHub enables the creation and registration of feeds and feed mashups built using a simple browser-based UI where operations and functions are defined graphically to aggregate and transform data extracted from enterprise, departmental, and personal data sources. The browser-based tooling also allows a mashup author to discover and share registered feeds and widgets to use in creating mashup applications with Lotus Mashups. After they are created, the mashup applications can also be stored in the catalog for discovery and use by others.

For deployment of mashup applications, Lotus Mashups includes a lightweight mashup server, while InfoSphere MashupHub includes a feed generation component and a transformation engine. The mashup server is the target of mashup URLs for accessing mashup applications and loads the page and its associated widgets to the browser. When widgets access feeds registered in the InfoSphere MashupHub, the catalog is accessed by the feed generator to retrieve metadata required to interface with the data source. The metadata is used by the feed generator to access the data sources and to invoke the transformation engine when data is aggregated or transformed from one or more of the sources.

jStart solution architecture

Figure 5 illustrates the logical solution components used by the jStart team to implement mashup solutions of their early adopters. The components shaded in green represent solution components that are in addition to those described previously and those discussed in the architectural patterns.

Figure 5. Solution architectural overview
Solution architectural overview

The logical runtime components that are utilized in the architecture patterns are described as follows:

  • Browser Mashup Runtime (realized through the mashup enabler). The mashup runtime in the browser provides a JavaScript framework for rendering the mashup UI that consists of widgets and for managing the interactions and linkage between the widgets, data sources (enterprise or public), and services acquired from another vendor. After widgets are loaded and rendered within the browser, they are considered part of the Browser Mashup Runtime component.
  • Mashup Server (realized through the Lotus Mashups lightweight mashup server). The Mashup Server component provides the runtime infrastructure for deploying and hosting mashup applications. After invocation of a mashup application from a browser to the server, the Mashup Server component loads server-side components and sends the Browser Mashup Runtime component and associated widgets components to the browser.

    Two subcomponents that are part of the mashup server are a Virtual Member Manager subcomponent and an AJAX HTTP Proxy subcomponent. For the jStart implementations, these two components are actually provided by the WebSphere® Application Server on which Lotus Mashups is deployed.

    • Virtual Member Manager. This subcomponent adds a layer of abstraction and delegates the authentication of users to a security system (for example, WebSphere Application Server security) where a virtual member management database, local operating system, LDAP, or custom user registry can be used for the authentication of user credentials.
    • AJAX HTTP Proxy. This subcomponent enables widgets running in the Browser Mashup Runtime component to access domains other than the one from which the mashup application was loaded. Browsers enforce a "same origin" policy that prevents client-side scripts such as JavaScript (which widgets are based on) from loading content from an origin that has a different protocol, domain name, or port. This logical component is realized using the WebSphere Application Server HTTP proxy.
  • Feed Data Source. A system that provides XML data that supports RSS or Atom formats is considered a Feed Data Source component. The formats and associated protocols are used to syndicate content that is updated frequently.
  • Enterprise Data Source. Enterprise systems that do not support syndication feeds are considered existing systems in this article to distinguish them from syndication data sources. These systems, used across lines of business or within departments, are vital sources of information that are integrated into mashup applications. Examples of these systems include Microsoft® Access, IBM DB2®, LDAP, IBM Lotus Domino®, IMS, and SAP. In addition, files formatted in XML, CSV, and Microsoft Excel are also sources of vital information to be used within mashups.
  • Mashup Hub (realized through InfoSphere MashupHub). The Mashup Hub component provides an information management environment for IT and business professionals to unlock and share enterprise data, including Web, departmental, personal, and enterprise information for use in Web 2.0 applications and mashups. The Mashup Hub component interfaces with these data sources (for example, RSS, Microsoft Access, IBM DB2 XML, LDAP, Lotus Domino, IMS, SAP, CSV, XML, and Microsoft Excel) to create Atom feeds. Similarly, the hub can aggregate, transform (that is, apply operators and functions to filter or reconstruct), or sort data from one or more of the data sources to create a consolidated Atom feed, which is referred to as a feed mashup.
  • User Registry. This component is a repository for persisting user account information such as user ID and password, permissions, and roles for providing authentication and authorization of Web resources.
  • Servlet. This component is a Java server-side component that enables widgets running in the browser to access the Java APIs of components and applications (for example, IBM Lotus Sametime® server) deployed on a Web server to extend the capabilities of mashup applications.

The following architectural patterns have been used to support the business scenarios and usage patterns outlined in this article:

  • Pattern 1: User login (authentication and authorization)
  • Pattern 2: Simple inquiry with secondary data views
  • Pattern 3: Inquiry with aggregated secondary data views
  • Pattern 4: Inquiry with service aggregation acquired from another vendor
  • Pattern 5: Inquiry with data updates to data sources
  • Pattern 6: Team collaboration

One pattern that is not explicitly covered in this article but is referenced in the sequence diagrams that follow is the pub / sub messaging between widgets. This low-level pattern is implemented within the Mashup Browser Runtime component to allow widgets to publish and subscribe to events to provide linkage between widgets. It is important to strive for fewer event types with common shared parameters rather than many events with unique parameters to minimize or eliminate cascading events among widgets (for example, event storms). It’s also advantageous to develop detailed sequence diagrams of event flows between widgets to optimize an event’s use and posting of common data.

Pattern 1: Login (authentication and authorization)

As the entry point for mashup applications, the mashup server is responsible for the authentication and authorization of each user. This step can be done either directly by the mashup server or the infrastructure on which the Mashup Server is deployed as shown in figure 6. For Lotus Mashups, the Virtual Member Management (VMM) component of IBM WebSphere Application Server can be used to define users and groups of users in a VMM database. Similarly, the local operating system registry, LDAP directories, or custom user registries supported by WebSphere Application Server can also be leveraged for authentications and authorization by Lotus Mashups.

Figure 6. Pattern 1 sequence diagram
Pattern 1 sequence diagram

If multiple user registries need to be leveraged to secure the mashup application, the federated repositories functionality of WebSphere Application Server can be used to take advantage of the user and group management capabilities.

In addition to securing access to the mashup application itself, specific data sources or services used by the mashup application can have controlled access. When a mashup application integrates protected data sources or services acquired from another vendor, credentials are required to access these systems. To avoid having to authenticate the user for each data source, single sign-on techniques can be leveraged. For WebSphere Application Server , a security token (LTPA token) is generated during the initial authentication and returned to the browser and used for follow-on widget requests to server-side data sources and services. The LTPA token enables WebSphere Application Server to perform authorization for the users in controlling access to any Web resource (for example, RSS, Atom, Servlet, REST service, or Web service) protected by WebSphere Application Server.

For cases where a data source or service is outside a WebSphere Application Server security domain, the security credentials (for example, user ID and password) can be captured in the Mashup Hub by registering an existing feed or by creating a new feed for non-syndication data sources. In both cases, metadata is created for the feeds that includes the necessary credentials. When a widget in a mashup application invokes the feed through the Mashup Hub, the proper credentials are added to the request, allowing authentication and authorization to be performed by the back-end systems hosting the data source or service. This level of security is illustrated later in other pattern diagrams.

Pattern 2: Simple inquiry with secondary data views

The architectural pattern shown in figure 7 is the most basic in that it enables a simple query for multiple data sets. After a user logs into the mashup server (detailed interactions not shown), the mashup server returns the required widgets that render the UI of the mashup application that includes a search form. After the search criteria are captured (keywords, radio buttons, check boxes, or menu selections), the user submits the search request, and both a primary and a secondary data set are retrieved from one or more Atom/RSS feed data sources. This approach is advantageous if the amount of data to be retrieved is relatively small. The user is then able to navigate the data sets by selecting specific primary data records and having more detailed data populated in secondary tables or graphs, or reflected in images or maps for their review without the delays of follow-on requests. Selecting data rendered in one widget (for example, in a table) automatically initiates an event publication within the Browser Mashup Runtime component that notifies other widgets listening for the event, allowing them to coordinate their processing in rendering additional information in the user interface.

Figure 7. Pattern 2 sequence diagram
Pattern 2 sequence diagram

For the simplest cases when access needs to be controlled, the creator of the mashup application can identify users or groups of users that are permitted to utilize the mashup applications. Thus, when it is deployed, the mashup server is easily able to control access through the integration of the WebSphere Application Server VMM capability. The pattern shown in figure 7 assumes that the user credentials captured during login are sufficient for accessing the systems that host both the primary and secondary data and thus can provide single sign-on for the user. The security token (LTPA) created during the login is passed with data requests to back-end systems to enable them to perform authorization in providing controlled access to the data. Also note the requests to data sources following through the AJAX HTTP Proxy to enable the access of systems outside of the mashup server origin.

This pattern and a few that follow focus on the use of syndication feeds as many of the ready-to-use widgets of mashup maker tools leverage feeds that allow mashup applications to be easily created without the development of customized widgets. Patterns 4 and 5, though, cover other options for accessing data in nonsyndication format.

Pattern 3: Inquiry with aggregated secondary data views

This pattern, shown in figure 8, extends pattern 2 by aggregating two existing syndication feeds into a feed mashup in retrieving a combined set of secondary data. After a data record is selected from the initial primary data set, a feed mashup is invoked from the mashup hub, resulting in two separate requests to independent feed data sources (RSS or Atom). The mashup hub can be used to transform (filter, restructure, sort) the data in creating an aggregated feed that is returned to the mashup application as an Atom feed.

Figure 8. Pattern 3 sequence diagram
Pattern 3 sequence diagram

By having the mashup hub perform the transformation of the data, the work is offloaded from the browser to an operational back-end component that can be configured to provide optimum performance. Similarly, if a protected data feed (not deployed on WebSphere Application Server) inside or outside of the enterprise or a pay-for-use feed on the Internet, needs to be accessed, the login and security credentials can be captured by registering the feeds in the mashup hub. The mashup application accesses the protected feeds through the mashup hub, which acts as a proxy providing the appropriate credentials to systems to enable the data source to be accessed. It is the responsibility of the mashup application creator or author, who registers the protected feeds and their credentials, to ensure that users of the mashup application are authorized to gain access to the protected feeds.

The preceding pattern assumes that the mashup server and mashup hub are installed on the same system and thus that the AJAX HTTP Proxy isn’t required. Also, this pattern can be used to aggregate more than two data sources, providing the mashup application with a highly relevant set of data from diverse sources.

Pattern 4: Inquiry with nonsyndication data sources and service aggregation acquired from other vendors

This pattern, shown in figure 9, is similar to pattern 3 with the exception that the data sources are not necessarily RSS or ATOM syndication feeds but are enterprise data sources or services acquired from other vendors (for example, Microsoft Access, DB2 XML, LDAP, Lotus Domino, IMS, LDAP, SAP, CSV, XML, Microsoft Excel, and existing feeds).

In this pattern, the mashup hub plays a critical role in interfacing with existing systems that do not support syndication formats so that they can be easily exploited by mashup applications. The mashup hub has adapters and plugins for each existing system supported that are configured by the mashup creator providing login credentials, parameters, and other metadata necessary for the existing systems’ APIs to be utilized. The existing systems can be accessed individually, creating separate feeds for each data stream, or multiple systems can be interfaced, combining their data streams into an aggregated feed.

Figure 9. Pattern 4 sequence diagram
Pattern 4 sequence diagram

As in pattern 3, the mashup hub can be used to transform the data (filter, restructure, or sort) and to enable access control of protective data sources. Because the mashup hub acts as a gateway doing protocol conversion between the existing system and the mashup application and because it can be also be configured to perform data transformation, it is crucial that performance implications be considered when designing the navigation of the mashup application to minimize UI delays. Example considerations include initiating interactions with existing systems in advance to download data before it is rendered, leveraging existing system APIs that filter at the data source, migrating data to common existing systems to minimize the number of systems to be integrated, and invoking coarse-grain services to maximize existing system processing power.

Pattern 5: Inquiry with data updates to data sources

The initial phase of most mashup applications implements the search and review interactions and behaviors to improve decision making, optimize productivity, and help locate expertise and content. Without the ability to update or create new data records, however, the value offered for improving informal business processes or collaboration among team members is greatly hindered. This pattern, shown in figure 10, extends the other patterns by enabling a user to update primary and secondary data sets or to create new records that are persisted on back-end systems.

Because the patterns up to this point have shown only the Browser Mashup Runtime component (that is, widgets) using syndication feeds for accessing data sources, widgets that are ready to use without modification could be used in creating the mashup applications expeditiously. It should be noted, though, that widgets can be developed to interface with server-side components (for example, servlets) to extract information in the format that is necessary or available.

Figure 10. Pattern 5 sequence diagram
Pattern 5 sequence diagram

Because widgets are the primary building blocks in mashup applications, widgets can be developed that support the appropriate protocols and APIs of system-side components to interface directly with resources hosted by those systems. These interfaces include the Atom Publishing Protocol for syndication feed resources, REST or Web Services Description Language (WSDL) services, or invocation of Java components such as servlets that enable access to Java APIs on Java Platform, Enterprise Edition (Java EE). To support the update and collaboration interactions and behaviors, dependences are placed on IT resources for widget development. Similarly, any information that can be extracted from these interfaces can be retrieved by a widget for use in populating primary and secondary data views (for example, presence information about individuals in a contact list).

Pattern 6: Team collaboration

In addition to updating and creating new data records for use by others in performing business processes, team members can be benefited by enabling easy communications among the team. Communication options and tools are available today for use by IT professionals; however, integrating them into the mashup application adds value when the primary or secondary data sets contain contact information (for example, name, phone number, and email address). By providing communications options in the mashup application, the user can initiate messaging or voice calls without having to switch to an application, copying the user contact information, and entering it in the application (the email client, instant messaging client, or telephone key pad). See figure 11.

Figure 11. Pattern 6 sequence diagram
Pattern 6 sequence diagram

For simplicity, the AJAX HTTP Proxy has been omitted from this flow, but all invocations for widgets to data sources or systems other than the mashup server from which they were loaded flow through the AJAX HTTP Proxy.


Conclusion

Today’s mashup applications can be described using a simple interaction model that supports search, review, collaborate, and update behaviors. Mashups can be used for business scenarios providing support for common interactions where a user takes an action and the mashup application provides one or more responses. The user roles and data for each industry where mashups are being used today are different and provide unique value to address the industry’s business requirements. The usage and architectural patterns, though, are similar as the underlining IT requirements are basically the same. Business scenarios are realized through common usage patterns that can be implemented using a small set of architectural patterns.

This series of articles touches on a small set of possibilities afforded by mashup technology based on the use of early adopters. Enabling business users to create their own situational applications to address their own needs or to solve their own problems is the value proposition that is starting to be realized with mashup technology and the IBM Mashup Center product offering.

Resources

Comments

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 IBM collaboration and social software on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Lotus, Sample IT projects
ArticleID=367835
ArticleTitle=Mashup business scenarios and patterns: Part 2
publish-date=06292009