[CAnet - news] Mashups versus SOA: What's the difference?

For more information on this item please visit the CANARIE CA*net 4 Optical
Internet program web site at http://www.canarie.ca/canet4/library/list.html
-------------------------------------------




 [Some excellent comments on the differences between mashups and SOA and
IBM's new mashup announcements. As you know we have been big fans of mashup
and SOA for big science and industry applications especially user control
and management of networks.  Some excerpts--BSA]

http://blogs.zdnet.com/service-oriented/?p=647




Is IBM making enterprise mashups respectable?

Anatomy of Web Mashup Styles 

Despite all the attention in leading edge tech circles, there is still a
general lack of knowledge about what mashups are, never mind so-called
enterprise mashups.

One big difference? Composite applications - those supposedly elegant
marriages of the resources of a SOA into brand new software that is more an
assembly of existing components than "green field" development - don't have
to be Web-based.  Mashups do.  Then there is the increased formality of
composite applications, which are typically based on SOAP Web services and
frequently woven together with BPEL and developed by professional
programmers.  Composite applications also tend to use an older generation of
programming languages and technologies that have more overhead and ceremony.
And, almost certainly too much exposed plumbing and infrastructure.

Read IBM's analysis of claims of 10-to-1 productivity improvements for Ruby
on Rails over Java for developing Web-based software

On the other hand, mashups use almost remkarably simple, basic techniques
for connecting things together.  This includes guerilla-style development
techniques that deliver results in preference to formal, upfront
engineering.  This might mean using Javascript includes of another site's
software, straightforward Web services and feeds based directly on top of
HTTP, and JSON for data retrieval and remixing.  And with initiatives like
OpenAjax, we might get first real conventions for component interoperability
in the browser.

Like so many aspects of Web 2.0, the term "mashup" is poorly defined and a
generally accepted definition probably does not exist today.  The term
itself, as applied to the informal fusion of Web services and browser-side
Javascript, is so new that it only made it into Wikipedia in mid-September,
2005, less than a year ago.

A question of what's being mashed up

At the root of what a mashup is the the question of what's being "mashed"
together into something new.  Is it data?  Is it visual presentation? Is it
the underlying functionality (code)?

The answer of course is that a mashup could be all of these things, or just
one of them.  In the end, mashups are intentionally loosely defined because
of their very nature as ad hoc aggregations of whatever needs to be
aggregated. Whether that is visuals, information, or working software is
immaterial to the term's application. 

But this state of affairs seems to be sparking the imagination of
entrepreneurs. An increasing number of companies such as Bridgewerx, Kapow,
Worcsnet, and others are trying to solve (or partially solve) the problem of
requiring programming skills to create mashups.  This means mashups will
become much more end-user directed in the near future as facilitation
techniques become more sophisticated.  They will be created by almost anyone
for just-in-time situations and projects, and even thrown away when their
usefulness ends.  This is a new view of software that says that there is a
long tail of demand for situational applications that just don't warrant
large investment.  However, their cumulative value could be quite
considerable as they tap pent-up needs that could not be satisfied in a cost
effective way until now.

This leads us to a key definitional point.  Are mashups purely browser-based
or are they fundamentally Web-based and could reside as easily in a Web
browser or Web server? 

I would assert that this is manifestly the case; mashups can exist anywhere
on the Web, either primarily on the server as Zillow or diggdot.us are or
entirely on the client side like so many of the Google Maps mashups are.
Mashups connote a mindset of informal techniques that just work by virtual
of the concept of "small pieces, loosely joined

The 5 styles of mashups

Accepting that information, visuals, and software can be remixed and
combined at multiple levels in an application stack means that there are (at
least) five places that mashups can take place.  These five styles are:

    * Presentation Mashup: This is the shallowest form of mashup in the
sense that underlying data and functionality don't meet.  Information and
laout is retrieved and either remix or just placed next to each other.  Many
of the Ajax desktops today fall into this category and so do portals and
other presentation mashup techniques.
    * Client-Side Data Mashup: A slight deeper form of mashup is the data
mashup which takes information from remote Web services, feeds, or even just
plain HTML and combines it with data from another source. New information
that didn't exist before can result such as when addresses are geocoded and
display on a map to create a visualization that could exist without the
underlying combination of data.
    * Client-Side Software Mashup: This is where code is integrated in the
browser to result in a distinct new capability.  While a component model for
the browser is only now being hashed out as part of Open Ajax, there is
considerable potential in being able to easily wire together pieces of
browser-based software into brand new functionality.
    * Server-Side Software Mashup: Recombinant software is probably easier
right now on the server since Web services can more easily use other Web
services and there are less security restrictions and cross domain issues.
As a result, server-side mashups like those that in turn use things like
Amazon's Mechanical Turk or any of the hundreds of open Web APIs currently
available, are quite common.
    * Server-Side Data Mashup: Databases have been linking and connecting
data for decades, and as such, they have relatively powerful mechanisms to
join or mashup data under the covers, on the server-side.  While it's still
harder to mashup up data across databases from different vendors, products
like Microsoft SQL Server increasingly make it much easier to do.  This
points out that many applications we have today are early forms of mashups,
despite the term.  Of course, the more interesting and newer aspects of
mashups happen above this level.

Of course, the real potential in all of this is as IBM's Rod Smith says:

    [Mashups put] more capability into an individuals hands and gives them
more freedom to innovate - and because Web 2.0 technologies are based on
open standards, integrating them into an open business model is easy for end
users and developers alike.

And the reality is today that the infrastructure, both in terms of
organizations recognizing and support the value of this approach, as well as
real tools for creating, deploying, and managing enterprise mashups are
lacking.  Despite this, he Global SOA is happening right in front of us, the
question is how to deal with licensing, governance, and all the problems
that SOA in the small has already taught us.



-------------------------------------
To SUBSCRIBE:
send a blank e-mail message to
[email protected]

To UNSUBSCRIBE:
send a blank email message to
[email protected]
-------------------------------------

These news items and comments are mine alone and do not necessarily reflect
those  of the CANARIE board or management.
----------
[email protected]
www.canarie.ca/~bstarn
skype: pocketpro
SkypeIn: +1 614 441-9603


_______________________________________________
news mailing list
[email protected]
http://lists.canarie.ca/mailman/listinfo/news