Mashups -- The evolution of the SOA, Part 2: Situational applications and the mashup ecosystem

In this article, the second in a
three-part series,
you explore situational applications, the mashup ecosystem, and how they relate to
the current state of software development in the IT industry and Service-Oriented
Architectures (SOAs). The
first article
in the series defined the characteristics and technologies that pertain to Web 2.0.
The final article describes the IBM® Mashup Starter Kit and how you
can use it to develop situational applications.

Stephen Watt is a software architect working on emerging technologies within
the IBM Software Group strategy organization at the lab in Austin, Texas. Prior to
working for IBM, Steve spent several years consulting in the Middle East and
working for startups in the U.S. and his native South Africa. Steve has published a number of technical books and articles available from Wrox Press and IBM developerWorks.

Situational
applications and social networks

A social network is a model of the relationships in a group of individuals
that are tied together by a specific common trait. An individual can also belong
to more than one social network. For example, Joe Soap belongs to a social network
of graduates from the University of Texas, a social network of individuals who
enjoy mountain biking in Austin, a social network of individuals who shop for
groceries exclusively at Whole Foods, and the list goes on. Joe Soap belongs to a
wide variety of social networks.

Knowledge of the traits of a specific social network is a valuable tool that
application developers can use to intimately examine the needs and requirements of
the social network and tailor the application appropriately. For example, you can
add features that are useful and remove features that aren't. This makes the
application more engaging to the specific community for which it's targeted. In
addition, you can work closely with the same community by soliciting and
incorporating feedback over multiple revisions of the application. This exhibits
the tight feedback loop with the community mentioned in the
first article.
This approach is in contrast with designing software for a broader audience, which
requires you to add various features that may or may not be used.

An article by Clay Shirky (see Resources for a link) has
several compelling examples of how students at New York University designed useful
and popular applications by crafting them for a specific (if not niche) target
audience. He goes on to say how these applications would have lost their value and
popularity had they been positioned for a wider audience. So, to sum up, a
situational application is an application that has been created for a
specific situational need, designed for and developed in collaboration with a
specific social network.

Another interesting factor to be aware of is that, due to rapidly changing market
dynamics, a significant amount of business collaborations tend to last less than
12 months. With the average application integration effort taking from three to
six months, there's little room left for a return on investment (ROI). The
industry needs solutions that can be built rapidly and cost effectively
(in lieu of the total time frame of the collaboration) to solve immediate and
specific business problems, yet be considered disposable (when the market moves
on). Because situational needs often necessitate that the application be
short lived, situational applications have another trait -- that the end result can be informal and
just good enough, as they don't need to exhibit features and traits that
give them product-level quality.

How do you create situated software?

If SOAs can evolve and be improved to empower users by
freeing up information and making it more accessible, a mashup ecosystem can be
put into place that leverages these SOAs to let users rapidly create
situational software. While this is very interesting, these are indeed difficult
goals to achieve. The following sections explain this approach in more detail.

Evolving the SOA

The IT industry has made great strides decomposing
IT infrastructures into modular, reusable services. While this has provided value
in other areas, it still takes the skill of a developer to be able to integrate
and build applications with these services. Because IT exists to fulfill the needs
of the business, it stands to reason that the next evolution of the SOA will
be to put these services in the hands of the users (nondevelopers) so they can
build solutions in a manner that can overcome the issues with ROI
that were described in the previous section.

Furthermore, to achieve the requirements of a situational application,
development needs to become significantly more affordable and expedient. You
need a new way of accessing and leveraging the current services in the SOA and
empowering the end or business user to quickly integrate the services
together. This approach would allow them to rapidly create applications
that meet their situational needs.

To effect such a model, the services need to have a visual element to
them. A face, or visual representation, for each service can provide access to
the properties and features of the service as well as the ability to reflect
relationships (wiring) between services. After this has been achieved, a service
catalog can be created to contain visual representations of services
and content that can be dragged from a palette and used on a canvas. If the
properties of the services can be made visually accessible, then the wiring phase
can be completed without programmatic intervention. Considering the fact that
business users are already familiar with the capabilities of the services and
content, this allows for extremely rapid application creation.

If business users are the ones using the services, they can provide useful feedback on the granularity of the information provided by the
service. Previously, the granularity of information provided in services has often
been decided by factors such as performance and maintaining the status quo of the
old legacy interface. If business users are able to build applications using
these services, they can provide valuable feedback on information
granularity based on how they were actually using the information in their
applications.

Figure 1 lays out the framework for how SOA is used as the infrastructure
of a situational application.

Figure 1. The face on the SOA

A more broad example of a social network than those found in Shirky's paper is
the social network of the modern business end user or power user. This particular
network of individuals is categorized by their good understanding of the Web,
the technologies used within it, and basic programming skills (such as the ability
to create Microsoft® PowerPoint® automations and Microsoft Excel® macros). These
users know their audience intimately (usually a much smaller social network) and
can use this knowledge to avoid spending time adding features they know not to be
intrinsic. To empower these users, these skills need to be put to use to leverage
their knowledge of content sources (inside the enterprise and on the Web),
tools, products, and services to enable them to build
situational applications that can drive their parts of the business. This can be
achieved by the adoption of the mashup ecosystem, illustrated in
Figure 2.

The mashup ecosystem

The diagram in Figure 3 displays the mashup ecosystem vertical stack. Each element
builds on the one below it until the end result is that a mashup can be created.
The mashup is at the top of the ecosystem but is only attainable if the
other elements of the ecosystem are in place.

Figure 3. The vertical mashup
ecosystem stack

Mashups
A mashup is a type of situational application that's comprised of two or
more disparate components that have been connected to create a new integrated
experience. An example of this is
zillow.com (see Resources for a link), which integrates county
tax information on real estate for a given location (component A) with a map for
the same location (component B) to allow you to view the assessed tax value for
all real estate within a particular vicinity on a map (the new integrated
experience). The original situational applications were mainly shell and Perl
scripts, which, as a situational need arose, were used by developers to quickly
and cheaply address them. Unfortunately, these technologies require the skill of a
developer and are not amenable to leveraging the skills of business users. However,
now that there's an approach to evolving the SOA and enabling services to have a
facade, the foundation has been laid to employ a mashup ecosystem that will allow
users to visually develop situational applications in the form of mashups. A
mashup is just one form of a situation application much like a SOAP Web service is
just one way an SOA can be implemented. Mashups are by
far the most popular approach to creating situational applications as dictated by
their prevalence on the Web today.

Mashup makers
A mashup maker is an assembly environment for running and creating
mashups. It gives users an efficient way to visually assemble mashups
by blending publicly available information and services with a company's internal
private information and services. The user can then visually manipulate and
integrate that content, whether it's static content, such as a Web page, with
dynamic content, such as a SOAP or Representational State Transfer (REST) service, or RSS feed. QEDWiki is a mashup
maker contained within the IBM Mashup Starter Kit (see the Resources section for a link to download the kit).

A mashup maker allows rapid visual assembly of mashups, because it provides a
collection of widgets, which are software components that provide
access (normally coarse grained) to one or more services or content (in this
article, content is synonymous with information). Widgets tend to be designed with
a focus on consumption and customization to ensure they are extremely flexible, as
one of the basic tenets of Web 2.0 is that you can't anticipate how your content
will be used. Widgets can be both visual (in that they render visual content, such
as a chart) or nonvisual (in that they provide some form of
discrete function or access to a service). Via the mashup maker, a widget can be
dragged from a palette onto a canvas, where the widget properties can be visually
accessed and used to connect the inputs and outputs between various widgets, with
the end result being the creation of a mashup.

For there to be a sufficient number of widgets available to make the
assembly of mashups a reality, there needs to be a widespread availability of
data service interfaces for the widgets to represent. A data service
interface is a generic term used to describe the technological means—usually via
feeds, REST, SOAP/Web Services Description Language (WSDL), Asynchronous
JavaScript + XML (Ajax), or XML Remote
Procedure Calls (XML-RPC)—that a service provider makes available
to access its content (the information you want to use or make available
in your mashup). Mashup Hub is a feed-management server that provides many
powerful ways to make content accessible to mashups. Mashup Hub is contained
within the IBM Mashup Starter Kit (see Resources for a
link to download the kit).

Build situational applications within
the mashup ecosystem

After the mashup ecosystem is in place, you can use the model of assemble, wire, and
share to build situational applications via a mashup maker. Let's break this down
into each action:

Assemble: An enterprise can create a widget catalog that's accessible
to the mashup maker. This catalog contains all the internally created
widgets and externally available widgets that might be used in a given area of
the business. This provides a way for users to quickly find and employ the
services and content they need in the process of a building a mashup.

Wire: The assembler employs the services made available in the service
catalog and connects them together via the mashup maker to rapidly, visually
build mashups. For example, a form widget can be placed on a page, allowing a
user to enter data. This data entered can be connected to the input of a widget
that provides a Web service invocation, and the output of the Web service
response can be connected to a widget that renders a visual display.

Share: The assembler then shares the mashup to make it publicly
accessible so it can be used by the knowledge worker, and the community
mechanisms can be employed.

There are three distinct roles in this process:

Mashup enabler: The mashup enabler writes the widgets and adds them to
the catalog. They dialogue with the assemblers to anticipate their needs and add
the appropriate services both retroactively and proactively. This is usually an
individual from the IT department or someone with sufficient technical skills to
write software.

Mashup assembler: This is typically a nonprogrammer that's a
line-of-business user or subject matter expert. The mashup assembler builds mashups by
wiring together the mashup consumables that have been created by the mashup
enabler.

Knowledge workers: This is the community that uses the application for
its intended purpose and employs community mechanisms on the application, such as
ratings and comments, to provide feedback so the application can be improved on
the next iteration.

The responsibilities of the roles in the various phases of the model are
displayed in the diagram below.

Figure 4. The assemble, wire, and
share model

What makes the mashup
ecosystem so effective?

First, because of the strides the industry has made in standardizing key
technologies, such as SOAP, REST, and Ajax, we've seen an explosion in the
adoption of SOAs, both on the Web and inside the
enterprise. This has led to the technologies reaching a critical mass whereby
there is a proliferation of reusable Web-based APIs and mashups that are just a
URL away. In this, there's an unparalleled
ever expanding set of content, data, and services available for people who wish to
develop applications using this model. The time is ripe.

Second, this is an extremely approachable programming model. It has a very low
barrier to entry due to the broad base of business and power users that are
familiar with Internet-based applications (and simple scripting languages like
PHP) and can do tasks, such as write Excel macros.

Last, the collaborative mechanisms that are already popular on the Internet
today serve to facilitate faster application development using this model.

Conclusion

In this article, you learned that using existing application development processes
and methods leads to a low ROI due to the situational nature of
business collaborations. Furthermore, you saw that the domain-specific and
technology-related skills of business and power users can be leveraged within the
context of a mashup ecosystem to let users rapidly, visually assemble
situational applications, providing a better ROI. The next
article in this series covers the IBM Mashup Starter Kit and how
it you can use it to build mashups.

Acknowledgements

My thanks go out to Stew Nickolas and Dan Gisolfi for reviewing and contributing
to this article.

The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.