Choosing between mashups and traditional Web applications

Considerations for leveraging IBM Mashup Center

This article compares and contrasts traditional Web applications with the evolving platforms for creating mashups as viable business tools.


Holt Adams (, Senior Consulting IT Architect, IBM jStart

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.

John Gerken (, Senior Architect, IBM

John Gerken is a Senior Architect for IBM, where he is responsible for recognizing, promoting, and developing prototypes of software technologies and trends that could positively affect IBM's customers. He is a recognized thought leader in the area of situational applications, widgets, and mashup ecosystems and is a principle evangelist for these technologies to IBM customers. John is a member of the North Carolina Technical Experts Council (NC TEC), which is an IBM Academy affiliated, technical advisory and vitality organization serving the Research Triangle Park, NC area. While his Masters degree is in Software Engineering, he also holds a Bachelor's of Science degree in Jazz Performance and plays at every opportunity.

15 July 2008

Also available in Chinese Japanese

Mashups are new and exciting aspects of Web 2.0. As is often the case with new technologies or approaches the industry often gets caught up in promoting the value proposition of what’s emerging. The hype often muddies the water between the value of what can be created with the new technology and the value of what exists today. With mashups, it's often unclear to IT professionals how their existing Web applications might be different from the proposed innovative approach to mashing-up data with a browser.

One of the first questions that customers often ask is "What’s the difference between a mashup and the Web applications that we currently use in our enterprise today?" The difference has little to do with technology or the integration of systems. Instead, it reflects the ease with which the application can be created by users, how the application is intended to be used, and the lack of nonfunctional requirements (for example, reliability, availability, and performance) that need to be addressed after the mashup or Web application is deployed.

In this article, we compare Web applications with a newer style of mashups, often referred to as enterprise situational applications, that are used for business purposes. The mashups are created for specific situations and are often utilized only for short periods of time while the situation exists. To appreciate the differences between mashups and traditional Web applications, let’s first review what they have in common.

With the recent announcement of the IBM® Mashup Center offering, which consists of Lotus® Mashups and InfoSphere™ MashupHub, IT architects and business analysts can consider how to leverage the product’s components and features to better address their situational needs and to improve their company’s competitiveness in today’s market place.

What do mashups and Web applications have in common?

Both mashups and Web applications generally use a browser as the client-side solution component that provides a user interface (UI) to a given application. Both mashups and Web applications are centrally managed from a server in the enterprise, and both are deployed to the user’s browser when a URL is used to access a Web resource on the server (for example, an HTML, JSP, Java™ Servlet, ASP, CGI, or PHP resource). For both mashups and Web applications, business logic can be executed on enterprise systems and data can be retrieved from enterprise databases, public data sources, or external services. In both cases, code that defines and makes up the UI and information extracted from internal or external business systems are rendered within the browser, providing users with the means to view and act on the data. In addition, the content sent to the browser can include JavaScript™ and scripting libraries that execute in the browser’s runtime to allow custom logic to be run locally in the browser. In many cases, the JavaScript and scripting libraries are used for simple field validation or the implementation of complex UI controls to provide an interactive and rich user interface.

Traditional Web applications: It’s all relative

Now let’s look at the differences between the two types of applications. The reference to traditional Web applications is loosely applied with many subjective criteria; in some respects, the reference is relative to how a given Web application is developed today. In general, the classification of traditional has more to do with the use of formal development and deployment methodologies models. Classifications of traditional Web applications are also meant to include applications that dynamically generate content based on user interactions (for example, submitting a form or clicking a link), but where the aggregation of information within the UI and the linkage of UI controls are done on the server. Thus, applications based on Java Server Pages (JSP), Active Server Pages (ASP), or IBM WebSphere® Portal technologies are considered traditional Web applications. Web-based applications that support page-based navigation are also considered traditional Web applications as they limit a user’s ability to view and act on data efficiently. Even Web applications that utilize Adobe® Flash technology with highly interactive interfaces can be considered traditional Web applications when you look at how they are constructed and deployed.

Web applications that are deployed in the enterprise for lines of business customarily require formal development teams and operational support. First, the costs of development and support can be justified only if the number of users who benefit is large or if the application is mission-critical. In either case, a formal process is required to ensure the highest rate of return on the investment.

Second, unique skills are typically aligned with the organizations of a business to optimize the use of resources. In many cases, the people with development and deployment skills are not the same people as those with knowledge about the business domain. Typically, a line of business has a set of requirements that needs to be addressed to support business processes or customer-related sales and services initiatives. These requirements are addressed through the design and development of UIs, control logic that manages how an application functions, and code that utilizes and manipulates business data.

The development effort for an enterprise Web application is typically very formal with requirements definition, design, development, functional and system testing, and deployment stages. Combined, the end-to-end solution process can take months, if not over a year, to complete. In this approach, line-of-business organizations are dependent on the IT and programming departments within their company. When the formal processes are followed, though, the result is more likely a comprehensive and stable solution that is optimized for a target set of users. Similarly, the trade-offs are the amount of time it takes to develop and deploy the Web application and the overall costs of delivering and maintaining the application. In some cases, the business need for the application might change or become superfluous if the cycle time to create the Web application is long.

Mashups: A Web 2.0 child

As noted earlier, mashups utilize many of the same technologies as traditional Web applications both in the enterprise servers and in the browser. The concept of mashups is not new, as businesses and Web developers have been aggregating and integrating data for the past decade using the Web as a platform. To minimize confusion, let’s clarify a few points about mashups. For many, mashup is considered a technical term regarding the mashing of disparate data to produce something new and interesting. A situational application is considered a tactical application, one that is often temporary and built by the people who use it. In this respect, a mashup can be a situational application, and a situational application can be a mashup. For this article, mashup means a situational application that is implemented as a mashup. See figure 1 for an overview.

Figure 1. Characteristics of mashups and situational applications
Characteristics of mashups and situational applications

A primary difference between mashups and traditional Web applications concerns the mashup application life cycle and the tendency of mashups to join seemingly unrelated data from public sources in meaningful ways with little or no formal agreements with the data providers.

Mashups can be considered a special genre of Web application for several reasons. They are created by the user or business analyst in relatively short periods of time with little or no additional costs to cover IT resources. Similarly, mashups used in an enterprise are often associated with data aggregation of both enterprise data and data from public sources. They create value by virtue of integrating data from multiple sources (most often leveraging public sources of seemingly disparate data) in a meaningful way that addresses a business or personal need. The aggregated data becomes relevant information when placed in the right context; producing something new and interesting is the trick of creating a successful mashup.

For instance, consider a supply chain management example in which a regional operations manager constructs a Web page (mashup) containing a weather feed, a Yahoo! map, and enterprise inventory data to aid in the logistical management of merchandise in response to a natural disaster such as a hurricane. For another example that shows value to an individual consider a Web-savvy employee (sales representative) who is relocating for business purposes and is shopping for residential property. The employee creates a Web page using a Google map and integrates into the map real estate listings with images, public tax records, public records of criminal incidences, and a list of his or her customers. The employee accomplishes this task by dragging each list of data from a palette and dropping it on top of the map, which causes each entry with address information to display as a pin mark on the map. The resulting mashup aggregates the disparate data from the multiple sources into a common view, which offers value to the employee by helping him or her make a decision on a house purchase that is reasonably priced, is near customers, and is in a safe neighborhood.

A traditional Web application (for example, a portal) can aggregate data too. Typically, though, a mission-critical application does not rely on public data sources because of concerns about availability and data validity. Similarly, a business analyst does not possess the skills to build such an application.

One of the implementation differences is that a mashup, as a Web 2.0 child, implements an Ajax application model, which asynchronously loads and presents content, that minimizes server requests and their inherent delays in UI interactions. Similarly, mashup widgets that leverage JavaScript and scripting libraries can aggregate data in the browser, in addition to the server. As a result, mashups can provide more natural and responsive user interactions than the full-page refresh model of many traditional Web applications.

To enable business users to create mashup applications, a mashup maker, editor, or assembler is often used (for example, Lotus Mashup editor, IBM Lotus Widget Factory). The mashup maker itself can be a simplified browser-based development environment. The user simply selects widgets from a palette in the mashup maker, arranges them on a workspace, and performs a few steps to customize the widgets and to link them to create a simple Web application: a mashup or, more specifically, a situational application mashup. Likewise, a mashup feed can be created with similar tooling (for example, InfoSphere MashupHub client) that merges, filters and transforms a set of existing feeds in creating a new feed to be consumed by widgets. The widgets themselves are independent application components with formal interfaces and customizable properties that often provide UI views of the data, UI controls, and background processing of data (for example, invocations of server-side services, database CRUD operations, screen scraping, or transcoding and mapping of data between widgets). The creation of mashups and their deployment for use by others are performed in the mashup maker without any reliance on formal IT operational teams. Some initial dependencies still exist between the line of business and the IT organization to deploy the tooling, setup, and enablement of the mashup system and to make the tooling available to the business user to create a mashup style of Web application.

IT must still set up and configure systems in the production environment or internally behind the firewall, as is also required for traditional Web applications. Specific mashup system components need to be deployed on servers, similar to how a portal engine is required for portal-based Web applications. In addition, if business data isn’t accessible using standardized syndication feeds (RSS or ATOM), Representational State Transfer (REST) APIs, or simple Web services APIs, then the IT organization needs to create such interfaces.

One simple alternative for creating syndication feeds to enterprise data sources is to leverage a mashup hub component (for example, InfoSphere MashupHub) that interfaces with the enterprise systems on the back end while presenting individual syndication feeds for each system or an aggregated set of syndication feeds for the systems that can be use in mashup applications. Similarly, if views of data need to be customized beyond what a widget’s properties allow or if the user interactions require custom widgets, then the IT organization can choose to create new widgets or customize existing widgets from the existing inventory. After the business data and logic are externalized through standardized APIs and after customized widgets are added to the inventory of widgets, the dependency on IT is greatly reduced. IT might be needed only to ensure that the systems are maintained with the appropriate middleware and that monitoring and support are provided to ensure system availability. Because the widgets are reusable application components that are assembled together in an ad-hoc fashion to provide business capabilities, trade-offs do occur. The trade-offs can include reduced customization of the UI, less tuning ability for performance, and little or no formal support for the aggregated set of widgets that make up the mashup application itself.

What approach is better for you?

With so many similarities, yet with some distinct differences, you might not see a clear advantage to adopting one approach over the other. Consider these points to determine whether using a traditional Web application development and deployment model is your best choice:

  • The application is necessary to the success of the business.
  • A large community of users requires the application to be highly available with formal support.
  • The application needs to address a comprehensive set of requirements that mandate a highly integrated and customizable UI.
  • Complex document workflow or process workflow needs to be managed.

If these considerations do not point you to a traditional Web application approach, consider the following points to determine whether a situational application mashup is your best choice:

  • The business needs are immediate and short-lived.
  • Users or business analysts are web-savvy.
  • Business data can be associated in meaningful ways with content from multiple sources (internal or external to the enterprise).
  • Rapid prototyping is required to demonstrate business needs to the IT organization.
  • Productivity increases can be gained within the user community by enabling self-service aggregation and integration of business data.
  • "Good enough" solutions are sufficient to address business and personal needs.
  • Data sources support syndication feeds.
  • Data services support REST-style interfaces or simple Web services interfaces.
  • Many business users need access to the same data, but for different reasons.


The value proposition of situational application mashups is that after your enterprise has enabled access to business logic and data through standardize interfaces, applications can readily be created by the users themselves. The applications are constructed using a set of widgets that can display and enable actions on the enterprise data, allowing the users to directly leverage a company’s investment in SOA and other standards and to implement a self-service style of behavior to address their own needs to optimize their productivity. These productivity gains by individuals and by their teams require and that of their team with little reliance on IT organizations; thus, these benefits are not offset by IT resource costs.



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

Zone=Lotus, WebSphere
ArticleTitle=Choosing between mashups and traditional Web applications