Because RSS is such a popular and straightforward technique for syndicating content, it has been supported by most Web-based applications written over the past several years. The simple answer is, "Yes, enterprise mashups can make use of this preexisting resource." But a more thorough explanation is required in order to understand the "How" and "To what end?"
Let's delve into the constituent parts that make up a mashup first. Consider the prototypical consumer mashup, "Restaurants near my House". The visual output of the mashup is provided by Google. The underlying data might be provided by a public SOAP API that lists restaurants for a zip code you provide. Without the SOAP data, the mashup is just an empty map.
Are mashups restricted to leveraging SOAP APIs for their content? Not at all. If you are coding the mashup yourself, then you can pull content from almost everywhere. As you investigate enterprise mashup products (e.g., Convertigo, JackBe, Kapow, OpenSpan, etc) you will encounter different levels of support for a variety of protocols and standards including SOAP, REST, RSS, and XML. Some tools even support for screen-scraping or including binary artifacts like Excel or Word documents.
Most of the raw materials used by an enterprise mashup do not have an implicitt display style. A SOAP API typically returns raw data. The visualization of this information is completely the responsibility of the consumer. Our Restaurant mashup leveraged Google Maps, but the output of a mashup could be almost anything: a bar chart, a calendar, image, etc.
RSS is unique in that there is a standard for both structuring and displaying a feed. It's usually some combination of Publication Date, Title, and Excerpt. When we discuss mashing up RSS feeds, there is going to be a strong inclination to have the output follow this convention. Yahoo! Pipes is the classic tool in this space. RSS goes in, RSS comes out. Some of you might be thinking, "My RSS reader already combines multiple feeds on my desktop." True, but a mashup has the potential to do much more than this simple aggregation. In the process of combining feeds, you can mash-in other APIs or data to apply a lot more customization.
This flexibility lets you visualize RSS data in new and creative ways: Let's assume Monica works for a grocery store chain called FoodCo and is responsible for inventory planning at various locations. FoodCo has built a number of internal systems: Customer Relationship Management (CRM), Order Management, and Salesperson Performance Tracking. Each of these systems may have been built with basic RSS feeds that show the activity of the day. But they don't give Monica any real insight into how FoodCo is operating. She needs an executive dashboard, but all she can do now is sift through a list of status items published to her desktop reader.
Mashups can take these existing RSS feeds and make the information much more usable. A mashup could pull in a local weather feed and match it to the Order Management feed by store location. This data could be mashed with the historical weather and ordering trends per region. The output could be a simple chart showing how stores have over or under-ordered given a pending weather event like a tornado or snowstorm. Meanwhile, the salesperson feed could be mashed with the CRM feed to provide a better indication of employee performance. In both of these examples, the source data comes from RSS, but the output is something completely new.
Could these examples have been created by hitting the application databases directly? Yes, but that would involve getting access to the right tables and a certain amount of development skill. Thanks to the RSS feeds, the data needed was already publicly available. And RSS-powered mashups are among the easiest kind to create (If you can connect two boxes in Visio, you'll soon have the hang of tools like Pipes or Intel Mash Maker). Mashups aren't always the only solution to a problem—but they are often the quickest one.
Allow me to mention something that sometimes confuses people: Some mashup tools let you take RSS feeds and output custom APIs against them. That's right—you can create a SOAP API that lets you query a feed as if it was a read-only data store. Or maybe you'd prefer a REST API that returns JSON.
RSS is essentially "SOA-light" in many organizations. What it lacks in rich functionality it makes up for in its ubiquity. At its core it's a simple vehicle for data output, but that doesn't mean that it can't be enriched to create some very useful dashboards, widgets, or fresh APIs. The challenge is to recognize how the content in the feed can be enriched by other public and private resources available to you.
Michael Ogrinz (@mogrinz) is the author of Mashup Patterns: Designs and Examples for the Modern Enterprise. He is also Principal Architect for global markets at one of the world's largest financial institutions.
Dig Deeper on Service-oriented architecture (SOA)
Related Q&A from Michael Ogrinz
There are scenarios where HTML5 is better than native applications. Expert Michael Ogrinz discusses best uses for each. Continue Reading
Mike Ogrinz says risk-taking is part of software innovation. There should be 'potential for failure,' a key ingredient to innovation. Continue Reading
Before building out a new enterprise portal application, you should probably examine existing systems to make sure they don't need to be ... Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.