This is an excerpt of Chapter 1 from the new book, Mashup Patterns: Designs and Examples for the Modern Enterprise, authored by Michael Ogrinz, published by Addison-Wesley Professional, ISBN 032157947x, March 2009 Copyright 2009 Pearson Education, Inc. For more info, please visit InformIT. Safari Books Online subscribers can access the book here.
Download Chapter 1: Understanding Mashup Patterns
Chapter Excerpt
The Birth of Mashups
You can have it "good," "fast," or "cheap." Pick any two of the three.
—Classic programmer's adage
Quick, easy, and affordable application development has always been a goal of software engineering. Reusing something that's already been built, tested, and paid for is one of the quickest ways to achieve this objective. From subroutines, to external libraries, to object orientation, to templates, to Web Services, each great advance in programming has been born from the desire to reuse material instead of starting from scratch. The limitation inherent in each of these milestones is that they were created by developers for the sole use by others in their profession.
It seemed inevitable that with the vast amount of new material being placed on the Web 2.0 every second, it could somehow evolve into raw material for software development. Tim Berners-Lee envisioned this leap in Web reusability in what he termed "the semantic Web," which describes a platform for the universal exchange of data, knowledge, and meaning. And while work continues to define new languages and protocols to realize Sir Tim's dream, mashups are making this vision a reality now.
Mashups are an empowering technology. In the past, resources had to be designed for reuse. Application program interfaces (APIs) had to be created, packages compiled, documentation written. The application developers and solution architects who recycled resources were subject to the whims of the original designers. With mashups, you aren't limited to reusing an existing API; you can impose your own if none exists. So if an application or site offers no API, or if you don't like the access methods that are already in place, you can design and implement your own (see the API Enabler pattern in Chapter 4 for several examples). The promise of achieving programmatic access to almost unlimited data is intoxicating. Even more exciting is the notion that the tools for constructing mashups have begun to reach a level of usability where even nontechnical users can build their own solutions.
