Mashup Styles, Techniques, and Technologies
In this chapter, I point out some of the most widely used styles, techniques, and technologies to build mashups for each of the three primary categories or items.
Determining the Technological Domain for a Mashup
Along with determining what is to be mashed, you must also determine the sources from which the mashup items will be accessed; the style, technologies, and techniques your staff needs to build the mashup; and what services you need to build or access to retrieve the necessary artifacts for your mashup.
Mashups rely on the ability to mix loosely coupled artifacts within a given technological domain. The requirements of the application determine what artifacts (UI, data, and/or functionality) will be needed to build the mashup.
From a high-level perspective, the technological domain as applied to mashups can be viewed as presentation-oriented, data-oriented, and process-oriented. Different languages, methodologies, and programming techniques apply to each technological domain.
As shown in Figure 1.1, mashup categories can be divided according to presentation artifacts, data, and application functionality/processes. Each of these categories requires specific skills and programming technologies, as discussed next.
Figure 1.1 Three primary mashup technological domains
A presentation-oriented mashup mixes different user interface (UI) artifacts together to create a new application or page. Typically, this type of mashup aims to create an application or page displaying UI artifacts in a manner similar to a conventional portal. That is, each artifact is to be displayed in a separate small area on an application pane or page in a segregated manner in relation to the other artifacts. Very little or no interaction takes place between the UI artifacts in a presentation-oriented mashup.
Technologies used in a presentation-oriented mashup can include
- Gadgets and widgets—User interface components that can be placed on an application pane or page independent of other items on the application pane or page. Legacy definitions of widgets referred to them in a more fine-grained manner as applied to desktop components, for example, buttons, scrollbars, sliders, and toolbars. The definition has been expanded in relation to web pages and mashups to include components comprised of more complex and self-contained functionality such as a clock, calculator, weather information, and so on. Gadgets and widgets may or may not retrieve data from an external site.
- CSS/HTML/XHTML—Snippets that can be inserted to create segregated user interface components that can be reused without regard to the application domain.
- Flash components/Java applets/ActiveX controls—Self-contained user interface components that rely on proprietary container technologies such as a virtual machine or runtime that is embedded within the application pane or browser page.
A presentation-oriented mashup is usually the easiest and quickest type of mashup to build. Since there is little or no interaction between the mashed items, the mashup developer can simply worry about placing the items on the application pane or page in the desired location with the desired UI theme.
In-Process Data-Oriented Mashups
Out-of-Process Data-Oriented Mashups
Out-of-process data-oriented mashups rely on data being mixed together using technologies such as Java, Python, Perl, C++, XML, and XSLT, to name a few. In this style of mashup data is retrieved from one or more sites/servers and used as values or configuration settings to create new data models within a server-side process or separate client-side process.
Process-oriented mashups (out-of-process) involve combining functionality together in one or more external processes using programming languages such as Java, PHP, Python, and C++. Mashups built for enterprise applications or web applications can involve frameworks such as JEE, .NET, and Ruby on Rails.
In a process-oriented mashup, functionality is combined using interprocess/interthread communication techniques such as shared memory, message queues/buses, remote procedure calls (RPC), and so on. Even though data is exchanged between processes and threads in a process-oriented mashup, the end result differs from a data-oriented mashup in that the data-oriented mashup seeks to derive new data models, whereas a process-oriented mashup seeks to derive new processes and/or services.
More often than not, enterprises require a hybrid approach when building a mashup. This is due to the number of disparate sources from which functionality and data are retrieved such as geocoding sites, RSS feeds, and corporate data stores.
So, when preparing to build a mashup you must first determine what is to be mashed, the technological domain in which to build the mashup, and the sources from which the mashup artifacts will be accessed. With this information in hand you can then determine whether your development staff possess the skills to employ the techniques and technologies needed to build the mashup. The skills of your staff have a big impact on the decision of which mashup style you choose. The following section discusses the reasons for choosing different mashup styles and/or domains.