Skip to main content

Web 2.0 for Dummies – Part 5: Mashups

This post is the 5th post in the "Web 2.0 for dummies" posts, based on my Web 2.0 presentation in a conference. After tasting Web 2.0 (part 2) and understanding what it is (part 4) we will drill down to more specific Web 2.0 principles and implementations.



The origin of Mashups is in Music: Creating a new song by combining songs. In information technology Mashups are applications build by non-IT Professionals by combining together data or applications from different sources, which were not planned for integration together.
The User assembles and links services to create an application
The services could be data services or could include Business Logic functionality
The user publishes the application in the Web so other users may use it or expand it as another Mashup.
Technologies used for building a Mashup based on simple published APIs include HTML, XML, simple Web Services and Representational State Transfer (REST).
By using JavaScript or other scripting languages the API enables connecting applications or services.

The usage of mapping application especially Google Maps as a basic service for a Mashup is very common.
To the mapping service the user adds other information such as: weather forecast, banking services, restaurant, apartments for rent or for sale etc. or locations for hobbies, traveling: flights, cars to rent and landscapes.

The frequency of using a service in a Mashup is depicted in Web 2.0 API Directory
As can be seen in this page Google Maps is the most frequently used.

The architecture of Mashups looks like SOA in a Social Web 2.0 context instead of Organizational context, but are Mashups really the SOA of Web 2.0?

Are Mashups Service Oriented Business Applications (SOBAs)? No
Do SOBAs and Mashups share common attributes? Yes

Drilling down into Mashups and SOBAs characteristics we can find the following common characteristics:
Applications composition by assembling Services
Innovation – By creating a new application of assembled Services
The Innovation in SOA is extended to Processes.
Simple interfaces for enabling integration between Services
This is true for Mashups and in some cases for SOA services, however in many cases SOA interfaces would be more complex and Metadata related.
A Non-IT people are the ultimate application creators
For Mashups this vision is a reality. For SOA Services in most cases still Information Technology experts are assembling Services to applications. However, vendors are developing tools for enabling Non-IT staff applications composition.

The differentiating characteristics are the need for Robustness and management of SOA Services. This includes Configuration Management and Versioning, Quality of Service (QOS), Performance and Security.
Unlike Service builder in an Organization, a Mashup builder is not responsible for the continuous operation of it in case of infrastructure changes, additional features or any change made to one of the services which are part if it. As a matter of fact he is not responsible for anything.

Another difference is that integration between Services is preplanned for New SOA Services (unlike Wrapped Services or Composite Services), while no such planning takes place for Mashups Services.

Note that the following Web 2.0 issues and principles are applicable to Mashups:

  • The Web as a Platform
    The Services and the composition are implemented in the Web platform.
  • Trust
    When using the Mashup, you trust its parts builders and its composer.
    Surely, someone can misuse this trust and insert a biased or unreliable service,
    For example a Car Rental agency can build a Service including only his company service as part of a Traveling Mashup including flights, car rental and other services based on Google Maps.
  • Participation
    Community members are contributing linkage between Services, so they form a unique application. They also contribute by ranking Mashups, by using Mashups, by adding data which supplement the Service (e.g. an expert in Fishing classified and map fishing sites based on Google Maps).
  • LongTail
    Anyone can build a unique application based on Mashups, therefore the mashups could address specific needs, unlike the traditional software model of creating a one size fits all (or few sizes feet all mainstream users).
  • Usage of Mashups is free of charge

    Despite of the limitations cited above, Mashups as an easy to use technology enabling any Web 2.0 community member to create applications is a promise for valuable variety of innovative applications adaptable not only for Mainstream applications for mass usage, but also for idiosyncratic applications of the Long Tail of Web 2.0.
Labels:

Comments

Post a Comment

Popular posts from this blog

The mainframe: still alive and kicking

Recently, I was interviewed by  Pcon   (unfortunately the link points to an Hebrew only site) as part of debriefing on Legacy Systems.  Pcon is an Israeli company investigating IT topics by quoting professional articles and interviewing experts. They publish the results of the investigations including practical recommendations. This post is mainly about topics raised by me during the interview, but not included in the debriefing, which will be published.    What are Legacy Systems? The term Legacy Systems refers to old application systems and/or veteran technologies still in use.  Usually, the term Legacy Systems is associated with: 1. Mainframe Hardware e.g. IBM System z and its Operating Systems or Proprietary Servers and Operating Systems such as HP Alpha and OpenVMS Operating System, IBM AS/400 and OS/400   Operating System. 2. Development and Production Environments, e.g. COBOL , Natural and DBMS systems such as Adabas  ...
16 comments
Read more

Will Business and IT Aligned?

For decades we are talking about closing the gap between business and IT , but the gap is still as wide as it was. In the beginning of the ERP era, we focused on aligning Business Processes and Core Systems, but in most enterprises we failed. SOA was the next alignment promise: defining the SOA Services in Business boundaries instead of Technical boundaries, should narrow the gap. However, despite of SOA Business Value ( Agility and Reuse )  in most enterprises,  the large Business-IT Gap remained as large as it was.  The IT Community aimed at the next alignment attempt: SOA is technical and BPM is its Business related complement.  Will the current BPM based alignment attempt succeed? I do not know, but Nick Heath's article  titled: Stop doing what the vendors tell you, CIOs told , published in  Tech Republic , suggests that the root of the problem is not Technological .   Stop Doing What the vendors Tell You Nick Heath's article is based ...
11 comments
Read more

Vendors Survival: Will Software AG Survive until 2019?

This post is another post in the Vendors Survival series following posts on Microsoft , Google , HP , Sun and EMC . On July 14 th Software AG and IDS Scheer announced that Software AG is going to take over IDS Scheer . The intended acquisition is an opportunity to add another post in my Vendors Survival posts series. A brief history of Software AG Mainframe products Software AG is larger than any German software company except SAP . It was established in the Mainframe age (in 1969). I worked with many customers, who used and some of them are still using, its two flagship products Adabas and Natural . Although these products support many platforms, their main platform is IBM Mainframe. Adabas is a database and Natural is a development environment. Like other pairs of Database and Development Environment in the mainframe environment (e.g. Ideal and Datacom , Mantis and Supra) build by the same vendor, they are tied together. As a result, although it is possible t...
8 comments
Read more