Athabasca University Application Mashups in The

ATHABASCA UNIVERSITY

APPLICATION MASHUPS IN THE ENTERPRISE

DAVID COYNE

An essay submitted in partial fulfillment

Of the requirements for the degree of

MASTER OF SCIENCE in INFORMATION SYSTEMS

Athabasca, Alberta

January, 2010

DEDICATION

For past and future: to my Dad (whose values are so important to me, especially now) and my children (whose abilities I believe in with all my heart).

ABSTRACT

Mashups are composite web applications, combining data and processing from multiple underlying applications, and presenting it in new and sometimes innovative ways. The popularity of mashups on the Internet has increased in recent years, with improvements in enabling technologies and availability of usable data sources. Within enterprises, mashups have yet to take hold. The approach has the potential to make better use of an organization’s service- oriented investments, and allow users to create some of their own applications – thus helping IT to address any development backlog. It may also help address the need for specialized situational applications, providing more opportunity for enterprises to innovate. This essay summarizes current published research, and articles, white papers, and other documentation made available by companies active in promoting mashup products. In addition, an example of a currently available mashup platform for the enterprise – the IBM Mashup Center – is installed and used to solve a series of possible business problems. The literature outlines numerous areas for concern, including the performance and quality of the solutions produced, management of the environment and the applications, and significant issues of user motivation and competence. Testing the example product showed how some of these issues are being addressed, but also revealed first-hand the difficulties of producing useful mashup applications. The research shows that the technology and approach is not mature, but still offers some return on investment. It is also evident that IT’s workload would likely increase significantly, along with its responsibilities. Issues of business user

participation are discussed, and whether user-created mashups are a realistic goal. Finally, we contend that a paradigm shift is needed in how we provide solutions for enterprise application needs, if the mashup vision is ever to be fully realized.

iii

ACKNOWLEDGMENTS

I would not have been able to complete this essay without the help and support of many people at Athabasca University, especially Dr. Mahmoud Abaza, who acted as my essay supervisor, and the knowledgeable and always courteous administration staff – particularly Linda Gray (and Jackie Terrien in the early years of my program). My thanks go to them and numerous other professors and staff who have advised and guided me during my program. I would also like to thank my wife and children, for their tolerance and accommodation while I worked through the program – it affected them more than I ever anticipated, but they always allowed me the space I needed!

TABLE OF CONTENTS

CHAPTER I - INTRODUCTION...... 1

Statement of Purpose ...... 1

Research Problem ...... 2

Assumptions and Limitations...... 3

Organization of Remaining Chapters ...... 3

CHAPTER II – REVIEW OF RELATED LITERATURE ...... 5

Mashups...... 5

Definitions...... 5

Composite Applications ...... 6

Enablers...... 7

Rich Internet Applications...... 7

Ajax ...... 7

Web Feeds ...... 8

Web 2.0 ...... 8

Service-Oriented Architecture...... 9

Web Services ...... 11

REST...... 11

Enterprise Development Needs ...... 11

The Long Tail...... 11

Situational Applications...... 13

Mashup Platforms and Tooling...... 14

Projects...... 15

Runtime Structure...... 17

Development Structure and Roles...... 18

Issues and Challenges...... 20

Lack of Standardization ...... 20

Application Quality...... 20

Performance...... 21

Data Quality...... 22

Data Availability ...... 23

Management...... 24

Security and Sensitive Data...... 25

User Expectations ...... 26

User Tendencies and Abilities ...... 28

Enterprise Mashup Products...... 29

Summary...... 31

Mashups...... 31

Tooling...... 32

Issues ...... 32

CHAPTER III – PRODUCT AND INVESTIGATION METHODOLOGY .... 34

IBM Mashup Center ...... 34

InfoSphere MashupHub...... 34

MashupHub Feeds ...... 35

MashupHub Catalog...... 35

MashupHub Feed Mashups...... 36

Lotus Mashups ...... 37

Lotus Mashup Widgets ...... 38

Lotus Mashup Pages...... 40

Evaluation Approach ...... 40

Scope ...... 40

Exercises...... 41

CHAPTER IV – RESULTS AND ISSUES...... 44

Installation...... 44

Initial Impressions and Considerations...... 45

Interfaces and Facilities ...... 46

MashupHub ...... 46

vii

Feeds...... 48

Feed Mashups...... 49

Lotus Mashups ...... 51

Exercise 1 ...... 56

Objective...... 56

Steps Taken ...... 57

Issues and Observations ...... 58

Exercise 2 ...... 60

Objective...... 60

Steps Taken ...... 61

Issues and Observations – Lotus Mashups...... 63

Issues and Observations – MashupHub...... 64

Exercise 3 ...... 66

Objective...... 66

Steps Taken ...... 66

Issues and Observations ...... 69

Issues and Observations – Transform...... 71

Exercise 4 ...... 72

Objective...... 72

viii

Steps Taken ...... 73

Issues and Observations ...... 73

Summary...... 75

CHAPTER V – CONCLUSIONS AND RECOMMENDATIONS...... 77

Summary...... 77

Conclusions and Recommendations...... 79

User Participation ...... 79

The Role of IT...... 79

Approach and Tooling Maturity...... 81

Information Security...... 81

Paradigm Change...... 82

REFERENCES...... 83

LIST OF TABLES

Table I. MashupHub Operator Correspondence to SQL ...... 51

LIST OF FIGURES

Figure 1. The Long Tail...... 12

Figure 2. Mashup Layers...... 18

Figure 3. Mashup Component Stack and Roles...... 19

Figure 4. IBM MashupHub...... 36

Figure 5. Lotus Mashups...... 38

Figure 6. MashupHub Main Page...... 47

Figure 7. MashupHub Catalog List...... 48

Figure 8. Feed Mashup Canvas...... 49

Figure 9. Lotus Mashups Edit Mode...... 52

Figure 10. Lotus Mashups Wiring a Connection...... 55

Figure 11. Exercise 1 Mashup...... 58

Figure 12. Exercise 2 Mashup...... 63

Figure 13. Exercise 2 Mashup Widget Communication...... 65

Figure 14. Exercise 3 Feed Mashup Graph...... 68

Figure 15. Exercise 3 Mashup Output...... 69

Figure 16. Exercise 4 Data Modification Mashup Approach...... 74

CHAPTER I

INTRODUCTION

Mashups are composite web applications; they combine data and/or processing from two or more underlying applications, and present it to users in a new and sometimes innovative way (Wang, Chen, & Sha, 2008). The data or facility provided to the user is often something not available (or not conveniently available) before, even with access to the underlying applications. Although some of the concepts involved are not new, mashups are a very different approach to creating applications. The development processes are radically different from traditional development processes, and the developers themselves may not be seasoned programmers. Mashups often provide solutions in new and distinctive ways – often using visual representations (e.g. maps), and being highly interactive.

Statement of Purpose

This research essay analyses mashups and discusses the technologies, products and approaches used to create them, and the infrastructure needed to run them, in an enterprise environment. It also examines some of the reasons an organization may choose to use mashups, the benefits they may expect, and the issues they face.

Research Problem

The popularity of mashups has increased over the last few years. This may be due various factors, including advances in enabling technologies, and the expanding availability of accessible data sources (and interfaces to access them).

Still, most mashups are typically available on the Internet, rather than within organizations. Internet mashups range from potentially very useful (e.g. “Woozer”

(n.d.) – combining maps from Google with weather information from The Weather

Channel) to cute time-wasters (such as “The Sheep Market” (n.d.) – which allows purchase of virtual sheep).

Within enterprises, mashups are somewhat less popular (Makki &

Sangtani, 2008), even though the approach could be used to enable rapid and low-investment development of internal applications, building on an organization’s existing systems and data. Several vendors now supply products specifically aimed to help enterprises create and run mashups; examples include IBM’s Lotus

Mashups (“Lotus Mashups,” n.d.) and JackBe’s Presto (“PRESTO”, n.d.).

There are a myriad of issues and challenges around mashups and mashup culture. There is a lack of standards and experience, there are continual changes and developments (not just in mashups, but also in the technologies they use), and there are many issues with security, performance and reliability which all need to be resolved. Given these outstanding risks, and considering that mashups are a relatively new phenomenon on the Internet and that they are generally untried within enterprises, it is not clear whether mashups within an

enterprise should be considered a viable, long-term solution to providing application needs.

Assumptions and Limitations

This paper assumes that the reader is familiar with the Internet and World

Wide Web, web servers and browsers, web applications, and has an appreciation of traditional application development processes .

The essay does not present a thorough evaluation of all available products and options. The intent is to provide key information to enable sensible decisions to be made regarding the use of mashups and their associated technologies in the enterprise – not to recommend a particular product or approach. Therefore, only a single enterprise mashup product is explored in any detail; it is assumed that many of the experiences with this product will be relevant to other products as well.

Organization of Remaining Chapters

The following chapters of this essay are organized as follows:

• Chapter 2: Review of Existing Literature. Current papers and

articles with bearing on mashups and their related technologies

were reviewed. A description is given of the current state of the

subject, with reference to salient points from the literature.

• Chapter 3: Product and Investigation Methodology. An example of

an enterprise mashup creation product is described in detail, and a

series of exercises is defined to enable a lightweight investigation of

it.

• Chapter 4: Results and Issues. The results of the product

investigation are discussed, highlighting any issues found. Any

useful insights into the general difficulties of developing enterprise

mashups will be presented.

• Chapter 5: Conclusions and Recommendations. A summary is

given of what has been discovered from the review of current

literature and product investigation. Conclusions are presented and

recommendations given on the potential of enterprise mashups,

available tooling, and the supporting technologies.

CHAPTER II

REVIEW OF RELATED LITERATURE

Mashups

Definitions . The term mashup is still relatively new, and definitions can vary somewhat. Various published papers have used definitions such as these:

• “composite applications that combine views and data from two or more

data sources” (Makki & Sangtani, 2008).

• “software applications that merge separate APIs and data sources into one

integrated interface” (Zang, Rosson, & Nasser, 2008).

Hinchcliffe (2008), in a report sponsored by JackBe, an organization actively providing products in this area, has defined them as “a web application that combines data or functionality from one or more existing sources into a single integrated tool”. Microsoft have defined it loosely as “an application created by combining multiple sources of data and visualizations”, but have a more stringent definition for the enterprise environment: “an enterprise mashup is an application that results when a business user combines multiple sources of enterprise and public data with some visualization and interaction capabilities”

(Arredondo, 2008). IBM is also active in mashup tooling, and defines them as “a lightweight web application created by combining information or capabilities from

more than one existing source to deliver new functions and insights” (“Web 2.0”, n.d.).

These definitions all follow the theme of a software application combining data from multiple sources, with some specifying that it is a web application.

Microsoft differs on this, specifically including other client types (such as Excel spreadsheets), rather than just web browsers (Arredondo, 2008). Kongdenfha,

Benatalla, Vayssière, Saint-Paul, and Casati (2009) also describe an approach to using spreadsheets for combining and presenting web data. The primary reasons for doing this are that many users are familiar with spreadsheets (so may be comfortable and experienced with using them), and since they use them for their daily activities, it makes sense to present new tools and applications in that context. Most tooling, however, centers on the web and web browsers for delivery. Microsoft also specifically mentions that business users create the application. Even though not included in many other definitions, this appears to be a recurring theme across product vendors and published papers

Composite Applications . At the core of all these interpretations is the theme of combining information (or capability) from multiple sources or applications into a new application. This description could also be applied to the more general term composite application , and some articles and papers use the terms interchangeably.

However, a mashup is generally considered to be a particular variant of a composite application (Arredondo, 2008). The composite applications moniker also includes portal-type approaches where applications and data from different

sources are presented side by side. Although mashups vary, they tend to combine or integrate the sources in some fashion – in a way that provides added benefit (e.g. provides fresh insights, or is easier to use than the separate applications).

Enablers

To understand why mashups are now possible, we must realize that they are the culmination of several technologies and approaches.

Rich Internet Applications . Rich Internet Applications (RIAs) (Lawton,

2008) are web applications designed to operate as though they were desktop software. Although accessed via a web browser like traditional web sites, they are typically highly interactive and responsive. This “richness” means that web applications can be used in situations where, traditionally, they would have been considered too cumbersome. The benefits are that web applications do not need to be locally installed, like traditional desktop applications and tools – this is simpler for the user, and easier for IT to manage.

Ajax . RIAs are made possible by multiple technologies that allow developers to do such things such as locating some of the application logic locally in the browser, and also by loading data to individual controls or parts of the page as needed, rather than refreshing the entire page with each user interaction. One such technology stack (perhaps the most commonly known and used) is Ajax

(Asynchronous JavaScript and XML) (Garrett, 2005). Many of these technologies are not new – for example, browser support for the scripting language JavaScript has been available as way of embedding scripts in web pages for several years. 7

However, Ajax is a combining of these technologies to achieve something new.

Browsers were not, as originally conceived, intended to handle anything as complex as the requirements imposed on them by many of the techniques used by Ajax and similar technologies. Interactions were originally simple, one page at a time requests. Browser capabilities have been stretched somewhat, with numerous tricks and workarounds, to allow the technologies to be used in a fashion suitable for Ajax (and mashups in general) (Ashley, 2007). Although this situation is not ideal, the popularity of the approach is causing browsers to evolve and adapt to it.

Note that Ajax (despite the name) does not always use XML (eXtensible

Markup Language) for encoding transported data – it often uses JSON

(JavaScript Object Notation – described by Crockford (2006)), as this is a little less cumbersome and easier to parse in JavaScript.

Web Feeds . RSS (RSS Advisory Board, 2009) and Atom (Network

Working Group, 2005) are both common formats of web syndication feeds. These feeds make content available in a machine-readable (XML based) format, and are produced for many web sites and other information sources. For example, the

New York Times provides an RSS feed for much of its content (The New York

Times, n.d.), and weather updates and alerts can be obtained from The Weather

Channel (The Weather Channel, n.d.).

Web 2.0 . This term has been coined to refer to the characteristics of the latest generation of web applications. These applications engage their users in a much more interesting and interactive experience. This interactivity is not just in

the richer, more usable, and generally pleasing user interfaces, but also in the way it allows users to supply their own information for additional value. Web 2.0 implies a change in paradigms. Traditional web applications are remotely hosted systems, accessed via a browser; this is obvious to their users because of the limited performance, and mundane user interface. The shift in Web 2.0 is towards treating the web itself as the platform where the applications run. This means providing much richer user interfaces, as well as providing those interfaces on other devices – cell phones and other handheld devices, for instance – rather than just a Windows-based PC (O'Reilly, 2005). Many Web 2.0 applications also have a social aspect – if they are not directly involved in communication and collaboration, they often enable and encourage it. This can be between users, or between users and the providers of the application.

Service-Oriented Architecture . When we consider mashups specifically within enterprises, there is another enabler: to improve their agility and return on investment, the IT functions in many organizations have adopted Service-

Oriented Architecture (SOA) principles. This has enabled them to integrate applications more easily, increase reuse, and focus on solving business problems rather than technical issues. Additionally, they have been able to do this incrementally, by building on (leveraging) existing software assets, rather than replacing them (Datz, 2004). SOA is an architecture, not a set of technologies or products. Definitions for Service Oriented Architecture (SOA) abound, for example:

• “A set of components which can be invoked, and whose interface

descriptions can be published and discovered.” (“Service-Oriented

Architecture”, n.d.).

• “…an IT architectural style that supports the transformation of your

business into a set of linked services, or repeatable business tasks,

that can be accessed when needed over a network” (“New to SOA”,

n.d.).

• “Service-oriented architecture (SOA) is an emerging approach that

addresses the requirements of loosely coupled, standards-based,

and protocol independent distributed computing.” (Papazoglou &

Heuvel, 2007).

The essence of an SOA, for this paper, is an architecture where business tasks and logic are encapsulated and made available as services. These reusable services can be discovered and combined to form business applications as needed. Many of the ideas and principles in SOA are not new (for example, the benefits of encapsulation have been recognized for several decades).

However, SOA approaches have become more popular because the technology has improved, much experience has been gained, and standards have evolved considerably. This standardization and popularity is significant, especially in a connected (multi-enterprise) world. It has improved communication and interoperability, as well as enabling more sophisticated, stable, and popular tooling to be created

Web Services . A web service is an application interface designed to be called by other applications, over a network. The interface for the web service is described using WSDL (Web Service Definition Language), and is used by sending and receiving SOAP (Simple Object Access Protocol) messages (W3C

Working Group, 2004). Current SOAs generally implement their services as web services; however, web services may be used in non-SOA environments also.

REST . Representational State Transfer (REST) is an architectural style for distributed hypermedia systems (Representational State Transfer, n.d.). This can be used when building web services, and is gaining popularity as an alternative to traditional WSDL and SOAP based web services. This stateless approach is generally considered more intuitive, especially for non-programmers (Shi, 2006).

Enterprise Development Needs

Among other things, IT is charged with creating and supporting the organization’s applications. IT is expected to be knowledgeable and competent in this area, producing robust solutions to the most important requirements.

However, the mashup approach to development focuses on speed and ease – not quality, stability, and numerous other traits of well developed enterprise software. So how can mashups benefit the enterprise?

The Long Tail . Anderson (2004) wrote of “The Long Tail”, articulating that traditional retailers (to remain competitive) could only carry items that generated the most sales. The extra costs of including less popular (niche) items meant that those items were never stocked, so sales were lost. He goes on to describe a different business model (web retailers), where the costs of making niche items 11

available was reduced or eliminated. The net result was increased sales; in fact, because there were many more niche items, sales of these exceeded those of the popular items. This analogy has since been applied to describe user requirements (for new applications or other solutions) in the typical IT environment. IT is tasked with supplying (developing and supporting) applications for the enterprise, but it has finite, often quite limited, funding with which to do it.

This means that many requirements – some potentially very beneficial – are never addressed.

Graphing application requirements and their perceived benefit to the enterprise (“benefit” could represent several attributes – for example, number of users served, or cost saved), and sequencing by decreasing benefit, we typically end up with a power distribution like that in Fig. 1.

The Long Tail Benefit / Importance / Benefit

Requirements Cut-off

Figure 1. The Long Tail.

IT will have a cut-off point (the application with the least benefit to the organization that they still have the resources to address). Everything after this – 12

the “long tail” – are applications with little perceived value. However, most application requirements fall into this region, and although their individual solutions would not have contributed much, taken as a whole they can be significant. In addition, since potential benefit can be difficult to determine, it is conceivable that some of these undeveloped applications could actually have had a significant positive impact on the enterprise. Numerous improvements in technology and process have enabled IT to extend the cut-off point further out along the tail – but there is no silver bullet – it is likely IT will never be able to address all requirements. A better (and supplementary) solution is for business users themselves to address requirements, without needing IT to do it.

Situational Applications . Many of the requirements in the Long Tail are for situational applications – applications which have been created for a very specific need, and target a limited set of users (Watt, 2007). Shirky (2004) expounded the benefits of creating applications solely to service specific social groups, and the regular failure of traditional applications which have been

“properly” designed to be more generic and cater to more contexts and all possible users.

This type of application represents a paradigm shift. These applications need to be created quickly, and need only be good enough for the anticipated

(target) users. Focusing on traditionally important aspects (such as designing for performance or scalability, catering to all possible users, or more stringent quality standards) is a waste of effort. In addition to sacrificing some traditional qualities for rapid development, situational applications are developed with strong user

participation (sometimes they may even be developed by the users themselves).

It is expected that situational applications will need many changes, and will evolve rapidly. This agility is possible because of the limited diversity of target users, their availability for testing and feedback, and the limited adherence to traditional constraints (such as performance, scalability, or architectural and quality standards). Compared with traditional application development cycles, situational application development is less formal or planned, and new versions may be released in days rather than months or years (Cherbakov, Bravery, &

Pandya, 2007b). Situational applications can also address needs that are short- lived. Therefore, not only is constant application evolution and change the norm, but often these applications will be abandoned when the need expires. Expecting a positive return on investment with such a limited lifespan is only possible if the applications are developed rapidly and with minimal effort.

Mashup development uses a light and fast approach, and is a perfect fit for addressing situational application requirements. Indeed, Markl, Altinel, Simmen, and Singh (2008) speculate that the terms mashup and situational application may one day be considered synonymous. Perhaps a more realistic view is that mashups are a subset of situational applications (Watt, 2007). However, it is sufficient to realize that the primary reason for having enterprise mashups is to address these situational needs.

Mashup Platforms and Tooling

It is prudent to treat enterprise mashups as a slightly different beast than their public (Internet) counterparts – even though they use the same 14

technologies. Mashups within organizations address different needs, target a slightly different set of users, and face different challenges. Much of the tooling available for creating mashups tends to address one of these camps rather than both. The following focuses on enterprise solutions. According to IBM, a mashup platform “allows business users to create, deploy, modify, and share web applications by assembling information and capabilities from multiple sources - with no programming required.” (“Web 2.0”, n.d.).

It might appear that with appropriate mashup building tools, little would be needed to create mashups on top of an existing SOA environment. The reality is that SOA does not present its services in a convenient or friendly enough way, and can be lacking semantic and other information needed by builders – especially for those with no IT development experience (Lizcano, Soriano, Reyes,

& Hierro, 2008). Mashup platforms provide the extra information and capabilities needed, making use of a Web 2.0 community approach to create additional value.

Projects . Several research projects have targeted different aspects of enterprise mashup creation, among them FAST (“Fast”, n.d.) and ezWeb

(“Welcome to EzWeb”, n.d.). FAST is aimed at creation of the complex UI (User

Interface) elements (sometimes referred to as widgets , or gadgets in FAST terminology), and ezWeb is a reference implementation of a mashup construction and execution environment, allowing assembly of these gadgets. Lizcano et al.

(2008) describe a proof of concept based on these tools, and highlight FAST’s flexibility to storyboard gadgets into more complex multi-page gadgets. Also

interesting is Damia (Simmen, Altinel, Markl, Padmanabhan, & Singh, 2008), a web based integration platform. Its focus is on integrating data sources from a variety of sources, allowing filtering, merging, grouping and other manipulations and transformations of the data. Damia was used with QEDWiki and Mashup Hub from IBM’s alphaWorks Services (“alphaWorks Services”, n.d.). QEDWiki is a browser-based assembly tool for creating mashups from widgets and feeds.

Mashup Hub is a feed server, and provides a catalog of feeds and widgets that can be used in mashups.

Damia, Mashup Hub, and QEDWiki have all been integrated into the IBM

Mashup Center (“IBM Mashup Center”, n.d.), a full-featured product offering with additional functionality. JackBe Presto (“PRESTO”, n.d.) also offers enterprise- level mashup platform capabilities. These are offered as a collection of composers (for assembling mashups), connectors to access enterprise data sources, a mashup server, and other pieces.

All of the products and projects above allow visual assembly of mashups, using a wiring approach to make connections between components. This aligns with the user-centric development desired for these platforms, as this approach is considered easier for users. They also provide a catalog or repository mechanism to contain widgets, existing mashups, data source definitions and other information. In the spirit of Web 2.0, ideal mashup platforms also provide capabilities for users and assemblers of mashups to give feedback, tag items, and make comments on the items in the catalog.

A mashup platform differs from traditional application environments. Since there will be many mashups, and they have little pre-deployment testing, robust runtime partitioning (separation) is needed. Just like traditional applications, failure in one should not affect others; it becomes more important for mashups because of the increased likelihood of failure. Another consideration is ease of deployment (making the application available). Many mashups, changed often, mean frequent deployments. If IT needs to be involved, this would be a major bottleneck. Therefore, the platform has to make it easy for business users to do this themselves (Cherbakov, Bravery, Goodman, Pandya, & Baggett, 2007a).

Runtime Structure . The runtime structure of a mashup and the things it depends on can be viewed as three layers (Jhingran, 2006):

• An access or ingestion layer, which retrieves the resources and

services

• Combine/transform/augment – combine the data, filtering, joining

and changing as needed

• Presentation/publication – make the information available to other

systems or users

In publicly available (Internet) mashups accessed by people, all of this functionality is usually implemented in the user’s browser. This may require browser plugins to add capability, or may be based entirely on commonly supported browser features such as JavaScript. This works well with data sources in common formats, and when security is not a concern. However, within

the enterprise the security and governance requirements, and the need to access data in numerous internal formats and locations, means that a server-based approach is more prudent. In the enterprise scenario the user’s browser may only be responsible for rendering a rich user interface (the top layer in Fig. 2), and server-side mashup platform code handles the combine/augment and ingestion layers (Crupi & Warner, 2008).

other systems users RSS, Atom, XML, etc. HTML Presentation / Publication

Combine / Transform / Augment / Filter

Collect / Ingest

web pages RSS / Atom feeds other web resource services types

Figure 2. Mashup Layers.

Development Structure and Roles . Mashups are the top tier of a stack, with each built using the elements from below. Fig. 3 shows the relationship between mashups, the widgets they are built from, and the resources (data) used by widgets. Mashup assemblers (who wire together or connect widgets and possibly other elements) are generally expected to be business users (knowledge

workers). However, unless the task is particularly simple and the mashup assembly tools very easy to use, they would likely be very technically oriented users (“power users”). Those creating widgets may be IT developers, or technically competent users if the widget creation tools are sufficiently easy to use. Hoyer and Stanoevska-Slabeva (2009) define a reference model that differs slightly, with the resource definitions moved to a separate additional base layer.

Defining resources in this layer is considered fairly technical, and likely falls under the auspices of IT. However, other approaches expect that the community – probably technical users – would be able to create some of their own data source references (Bravery, Cherbakov, & Pandya, 2008).

Mashup

mashup users

Widget Widget Mashup mashup Widget assemblers

RSS RSS Web Widget widget creators and WS pages resource definers Atom WS

Figure 3. Mashup Component Stack and Roles.

Issues and Challenges

Mashups may show promise, but despite the recent advances, there are still many things to consider.

Lack of Standardization . Enterprises prefer choice, rather than being locked in to a single vendor. Ultimately, whether mashups become an integral part of the information systems landscape or not depends on there being a selection of tools and products available from multiple vendors. Fortunately, there are several vendors offering mashup tooling – many providing innovative approaches and advancing the technology. At this point, though, no vendor is clearly leading or dominating the enterprise mashup arena, and many companies are still evolving their portfolio to include mashup capability. This lack of maturity means there are no common standards for creation of widgets, or other artifacts generated when using the tooling (Hinchcliffe, 2008). This limits the possible interaction between different vendor solutions (Nestler, 2008). The OpenAjax

Alliance (OpenAjax Alliance, 2009) is currently doing some work on this, but the focus is on AJAX-based widgets. This would only be one piece of the puzzle for general interoperability, especially for server-based enterprise mashup platforms.

Application Quality . There are numerous reasons the quality (accuracy, reliability, usability, performance, etc.) of mashup solutions may be less than desirable. Mashups can be created by inexperienced developers, very quickly, to address very specific needs, and will not be rigorously tested before deployment.

Even if user expectations are managed, it is still preferable to encourage construction of high quality applications. One approach is to collect and return

feedback to the mashup creator. Those builders interested in making their application available to a larger audience can use this to improve the quality and scope of their work (Cherbakov et al., 2007a). A rating/comments system for mashups, should tend to steer new users to the more popular ones (i.e. those of better quality, and intended to be more robust and versatile in addressing user needs). However, the long-term effectiveness of these approaches is unknown.

Performance . The performance of any new application can be hard to predict, although potential bottlenecks will at least have been determined and considered during the design process of any well-crafted application. For rapidly conceived and constructed applications like mashups, this is not the case. This is understandable because mashup developers are often focused on providing a solution where none exists, rather than a better solution than one already given. It can also be difficult to determine the performance of any data feeds needed, and these are likely the main affecters of the overall mashup response time.

Once a mashup is created and it is evident that there are performance problems, there is often very little that can be done about it (Bravery et al., 2008).

The mashup builder may be able to use different data sources, eliminate some, or combine them in a different way. However, not only does this make the builders task more challenging, but the resultant application may not provide as good a solution as the original approach. If the problem is with a data source, this may be external and outside of the control of IT. If IT owns it, it may be a significant amount of work to correct – especially if it was never intended to be used that way. If the issues relate to scalability (perhaps a mashup’s popularity

has lead to a high number of users), there may be some technical solutions (such as caching in some way, or tweaking the underlying mashup platform). Such solutions, however, require involvement (and resources) of IT. Since it was not involved in the original situational application development, IT may not have planned and budgeted for these efforts.

Data Quality . There are two aspects of data quality to be considered: the quality of the data sources used by mashups, and the quality of information presented to users by mashups.

Like traditional applications (even in an SOA environment), data sources used by mashups may change, potentially breaking applications or invalidating their information. However, for traditional applications it is much less of a problem because IT generally controls the data sources and the applications, and has development controls and maintenance processes in place to address it

(Arredondo, 2008). Even if mashups use mostly internal enterprise resources

(which IT controls), IT may not understand how mashups are making use of that data. This may expose issues with the data that were previously irrelevant

(Cherbakov et al., 2007a). Mashups are also more likely to use sources of data not packaged as a service, or not intended to be used that way. For example, page scraping techniques may have been used to collect data. Such approaches are even more prone to failure from change (Cherbakov et al., 2007a).

Additionally, mashup creators may not be fully aware of the meaning of the data they are incorporating; names and abbreviated descriptions can be easily misinterpreted, even if the context is understood (Cherbakov et al., 2007a).

Many of these issues can be mitigated somewhat by incorporating a feedback or rating mechanism for data sources (Hinchcliffe, 2008), and by making sure provenance and other detailed information on data sources is made available in the mashup building environment (Cherbakov et al., 2007a). Still, it is prudent if users of the application are aware that the information may not have been vetted by IT (Cherbakov et al., 2007a). When data is available in multiple locations, there can be differences between the copies. Selection of the correct data sources for mashup use can be a problem, especially by those outside of IT, with less expertise and detailed knowledge of how the data is manipulated in the organization. The use of Master Data Management (MDM) tools, which help manage an enterprise’s reference data, can help address this. However, such tools and approaches are not used everywhere (Arredondo, 2008).

The other aspect of data quality is the correctness of the information presented by the application. Even if the data sources used were correct, accurate, and interpreted correctly, there is no guarantee that the mashup has not corrupted or misused it in some way prior to presentation. How effective the feedback and rating mechanisms would be in helping users detect and correct this (in lieu of IT’s involvement) is unknown.

Data Availability . Even though mashup tools allow use of many different types of data sources, much of an organization’s data is locked in relational databases and other types of data store (Arredondo, 2008; Hinchcliffe, 2008).

Even if the mashup tool allows connections to that type of store, the data may be protected, hidden, or not well described. This means that as enterprises adopt or

even try a mashup approach, substantial effort must be invested in making data easily accessible and optimized for mashup use (e.g. as REST services), and documenting semantic and other details where the mashup builders can find and use it (Cherbakov et al., 2007a).

Data external to the organization carries other challenges, in addition to the exposure of depending on something uncontrolled. For example, the organization may make available external data that it pays for. If this is a transaction-based fee, costs could quickly spiral out of control when mashups start using it (Cherbakov et al., 2007a). External data not available for programmed access may be made available using page-scraping techniques.

Apart from the inherent unreliability of this method, this means the data is being used in a manner that the page publisher did not intend. There could be legal or licensing implications when doing this, or the site may actively try to discourage it with technical tricks (e.g. regular page format changes) (Cherbakov et al., 2007a).

Management . Even though part of the mashup vision is to produce applications that are so easy to produce that there is no pain in discarding them, the reality is that some mashups will consume a lot of effort in their production. It is easy to conceive of mashups that undergo continuous feedback and refinement or enhancement, becoming more sophisticated and useful. Over time, business processes may come to depend upon them, even though they would not be easy to replace in short order. Since mashups are composed of components from various sources, the potential exists for breakage if components evolve in incompatible ways. Keeping track of which components (or

component versions) work with which mashups (or versions of mashups) could become an issue. Additionally, making available multiple versions of mashups could cause confusion (Arredondo, 2008; Hinchcliffe, 2008). Some kind of mashup and component lifecycle and dependencies management is needed; however, it needs to be as unintrusive as possible, so as not to inhibit innovation.

How easy this is to achieve will depend heavily on the platform and tooling chosen.

Security and Sensitive Data . Mashups outside of the enterprise generally do not have to consider security. They are usually made publicly available, and access data which itself is publicly available. Within the enterprise, security is often a significant concern. One aspect of this is controlling access to mashups created by users, another is enabling secure and controlled access by mashups to the underlying data sources they need. Much of the mashup tooling available does not seem to focus on addressing security, but this is something that must be considered for mashups to be accepted in the enterprise (Hinchcliffe, 2007).

Often data within an enterprise can be controlled quite tightly – access need only be given to the applications that use it. The applications themselves can provide a user authentication and access control mechanism – acting as gatekeeper to the underlying data. Still, to make much enterprise data usefully available to mashups, the processes and mechanisms for controlling access may need rethinking. It is desirable to allow mashups to have access to whatever they need – but without exposing sensitive data to unauthorized users. End-to-end

(database through to user) protection of data can be fully controlled by IT for

traditional applications, but this may not be easy for mashups (Arredondo, 2008).

An alternative to having the mashup (or widget) contain the credentials for accessing a data source, is to use the business user’s credentials. However, this may increase the management burden, and lead to some users encountering problems when accessing some mashups – leading to mashup breakage, confusion and user frustration.

Another aspect to consider is that making a related collection of data items available in one place may (often will) add additional information. The net result could be sensitive or private information, even though all of the data sources used were freely available. Warner and Chun (2008) discuss these issues in the context of publicly available government data, and propose a policy-based model that considers who is requesting the data and how it will be used. It may be necessary to develop equivalent approaches for enterprise data.

User Expectations . Bravery et al. (2008) and Cherbakov et al. (2007a) indicate that users of an enterprise application often do not know (or care) who built it, or the builder’s original intent. They use it because it appears to meet their needs. However, they may be using the application in a way or with a purpose not originally envisioned by its creator – making it more likely that issues and problems will be found. This can be mitigated somewhat by developers clearly indicating the intention and limitations of their application. On the positive side, users familiar with Web 2.0 applications outside of the enterprise may be more tolerant of bugs and other issues.

Still, users may assume that mashups are production ready - supported and maintained by IT, in the same manner and with the same controls and standards in place as the other applications they use. It may not be obvious to them that a mashup was developed by another user (not a professional developer), and has bypassed many of the normal checks, controls and balances that traditional applications are subjected to. Users may even come to depend on mashups for business critical processes. These issues are clearly difficult for IT to counter with its normal governance processes and development controls.

Managing user expectations is a key requirement to successful widespread use of mashups. There should be a clear difference in the minds of users between traditional applications (supported, trusted, accurate) and mashups (limited or no support, and cannot always be depended on). The mechanism by which the mashups are accessed may well make them distinct (e.g., they may all be available from the same server, or tend to follow an obvious presentation style).

However, a more explicit means will likely be needed, such as better documentation or education). More experience may help determine the best approach.

Even if users recognize that they are using a mashup, and accept that its characteristics may be different from traditional applications, they generally will not comprehend the underlying complexities that may cause poor performance.

Thus, even if they can cope with usability or accuracy issues, they may still have complaints about poor performance (Bravery et al., 2008; Cherbakov et al.,

2007a).

User Tendencies and Abilities . There is much emphasis on empowering users, enabling them to self-serve. However, the reality is that many users are not motivated to develop their own applications, let alone build them in a way that may make them useful to other users. Arredondo (2008) considers a spectrum of users, with “typical” at one end, and “power” at the other. Power users are more inclined to use tools and spend the time devising more sophisticated and technical solutions, whereas typical users focus more on their own individual problems and tend not to invest the time learning new techniques. Zang and

Rosson (2008) surveyed this in more detail, and analyzed various traits of non- programmers against their likelihood of developing mashups, and the types of mashups they might develop. Although this targeted non-enterprise users, it was clear that there were significant differences in their motivation as well as their abilities. If we were to consider these factors in an enterprise context, we may well find that time constraints and pressures may make curious users even less likely to explore mashup alternatives.

Use of mashups may hold the promise of gaining market advantage by innovation, but to do this in any significant way will require the creation of many mashups, by many people. This could require some culture changes and guidance, and it does require that there be a sufficient number of widgets, data sources, and other required components available (Cherbakov et al., 2007a;

Bravery et al., 2008). To make the tools useful to a broad range of users and situations, most tools use a widget and wiring approach and supply some initial widgets. However, there can be problems if the number of widgets offered is too

substantial, as increasing the number of widgets can make selecting a widget more time-consuming, tedious and difficult. Additionally, use of many tools needs some understanding of programming concepts, meaning that they are not that easy to use for the average user (Tuchinda, Szekely, & Knoblock, 2008).

Enterprise Mashup Products

The software landscape is constantly evolving, and the mashup platform and tooling area is no exception; many of the products available only a couple of years ago (Hinchcliffe, 2007) appear to have vanished or be destined for oblivion.

However, some are still vibrant and seem to be actively marketed. Apart from

JackBe’s Presto and the IBM Mashup Center (mentioned previously), these offerings include several others:

• Serena’s Business Mashups is a platform for running mashups

created with their Mashup Composer product. Serena emphasize

ease of development by business analysts, if they can “draw a

process in PowerPoint or Visio, or are comfortable with an Excel

macro” (“Business Mashups”, n.d.). Serena also offer an On

Demand service, allowing you to deploy your mashups to a Serena

hosted and maintained environment, rather than running on your

own servers.

• InetSoft focuses on BI (Business Intelligence) solutions. However,

they have been moving towards web-based rather than desktop

client solutions, and towards direct access to data rather than

feeding from an intermediate repository or database. Their Style

Intelligence product (“Style Intelligence”, n.d.), promoted as a BI

dashboard and reporting product, allows users to create their own

mashups.

• Kapow’s Web Data Server (“Kapow Web Data Server”, n.d.) is well

established, and boasts extensive capabilities for data collection

(advanced “page scraping”) from other web sites. It allows for

collections, reformatting and storage/transmittal of the data in other,

more easily consumable formats such as HTML. Its focus seems

more on data capture, rather than on interactive mashup creation by

users.

• Oracle acquired BEA in 2008 (“Oracle Completes Acquisition”,

2008), rebranding and incorporating BEA’s AquaLogic products into

their WebCenter series, along with existing Oracle products

(“Oracle WebCenter Interaction”, n.d.). This has resulted in a

somewhat dizzying array of sub-products, with some overlap in

capability. Still, Oracle appears committed to evolving mashups,

along with other Web 2.0 capability within the enterprise (Hauser,

2009).

• Microsoft’s SharePoint provides content management, collaboration

facilities, and other services. Microsoft is promoting this as a social

computing platform for enterprise mashups, and provides tools for

web development of mashups, as well as supporting other client

types (e.g. spreadsheets) (Arredondo, 2008).

Summary

Mashups . A mashup is a composite application which combines data from multiple sources, and presents it in an integrated and more useful fashion. These data sources are often in the form of RSS and Atom web feeds, and REST based web services. Mashups are generally web based, and make use of technologies such as those in the Ajax stack to provide rich and interesting user interfaces.

They exhibit Web 2.0 characteristics, such as treating the web as a platform, and encouraging user communication and collaboration. Within enterprises, SOA is a major enabler for the mashup approach.

Enterprise mashups usually address situational application needs – tackling a very specific problem, for a limited set of users. They may offer a solution to the “long tail” of user requirements that IT cannot address, by allowing users themselves to provide their own solutions. Of course, the reality is that not all users will have the technical ability to self-serve, and many will not have the interest to explore or try it. Mashups consist of ingestion (collection), combine/transform, and presentation layers. Within the enterprise mashup platforms, presentation is usually done on the client (within the web browser), with the rest executed on a server.

Tooling . There are several enterprise mashup tools available, but they are still evolving – the area is still immature and there is a lack of standardization.

These tools generally provide facilities for the visual creation of mashups and their components, and allow users to deploy their own applications. Mashups are created (assembled) by combining (e.g. “wiring”) widgets together. These widgets access or transform data, or present it to the user. With the proper tooling, this can be done by technically competent (and interested) business users. Creation of widgets and defining of data sources can be more complex, and is often done by IT personnel. However, in some cases (with appropriate tooling), technical business users may be able to do it themselves.

Issues . IT’s role is to act as an enabler for mashup creation and use – facilitating by creating and supporting a mashup ecosystem, and encouraging by providing guidance and support. However, there are still a significant number of management issues, especially related to the quality of data sources, and the lifecycle of mashups. There can also be a significant amount of work to make enterprise data available for mashup use. Security is an area which has not received too much attention in research or in the available tooling. Although not an issue for public (Internet) mashups, securing access to mashups and the underlying data sources is paramount within the enterprise. Any security mechanism and processes must be reliable, manageable and effective – but must also be convenient and not inhibit mashup development or use. Additionally, it is not clear how to manage the potential problem of sensitive information sometimes being created by mashing together non-sensitive sources. Another

important area is managing user expectations – they may not recognize that mashups are a different beast. The quality and performance of mashups may not be tolerable when most user experience is with traditionally developed applications.

CHAPTER III

PRODUCT AND INVESTIGATION METHODOLOGY

As an example of many of the approaches and techniques shared amongst enterprise mashup platforms and tools, we will examine the IBM

Mashup Center and related products in more detail.

IBM Mashup Center

Singh (2008) and Adams (2009) describe the IBM Mashup Center and its components in detail. Except where other specific references are given, the information in this section is derived from those documents, and the articles and documentation in the Mashup Center’s wiki (“IBM Mashup Center wiki”, n.d.). The

IBM Mashup Center is actually comprised of two separate products from IBM:

InfoSphere MashupHub and Lotus Mashups.

InfoSphere MashupHub . MashupHub provides an infrastructure and tools for making enterprise and other data available in more easily consumed formats.

It has a catalog for storing data feeds, widgets, and other related objects, and allows users to tag and rate them (“IBM InfoSphere MashupHub Overview”, n.d.).

It consists of client-side components that execute in a web browser, and server- side components that execute in a Java EE (Enterprise Edition) environment provided by the IBM WebSphere Application Server (“WebSphere Application

Server”, n.d.). It also makes use of a relational database for its catalog. The client

components present a rich (AJAX-based) browser interface to users. Requests

(e.g. to retrieve something from the catalog) are made using a REST-style web services interface exposed by the server components. This REST request interface is used by the client MashupHub components and can also be used by other clients (such as Lotus Mashups).

MashupHub Feeds . MashupHub accesses data in a variety of formats, transforms and filters it according to specified rules, and combines it with data from other sources. The resultant feed is made available to consumers as RSS,

Atom, or generic XML over an HTTP (or HTTPS) connection. Private feeds are protected by using SSL and HTTP basic authentication. MashupHub also supports the registration of existing RSS and Atom feeds. This approach of

‘remixing’ feeds unburdens mashups themselves from some of the work, simplifies mashup creation by removing the need to understand the intricacies of the data sources throughout the enterprise, and provides a focal point for controlling access to that data. It also caches data, reducing load on the enterprise data sources, and potentially improving performance.

It should be noted that mashups (or an environment running them, such as

Lotus Mashups), would normally consume the feeds exposed by MashupHub.

However, since the data is presented in standardized formats, other tools (such as a web browser, which can be useful for testing and debugging) can read it.

MashupHub Catalog . The catalog functions as a shareable repository for feed definitions, feed mashups, widgets, and mashup pages. Individual objects can be private (owner only), public, or can have finer-grained access control. It is

also possible, with appropriate customization, to store other types of objects. It has a community aspect, which allows users to rate objects and add comments for others to see. It also allows objects to be tagged and categorized, to help group them and assist users when searching.

Web Browser MashupHub Client mashup Feed (and feed mashup) definers, assemblers Widget importers

Lotus Mashups REST calls Search, retrieve, or other tools and responses store, tag, rate over HTTPS etc. Catalog Atom, RSS and XML feeds

MashupHub Feed Catalog Mashup Services Engine

Cache WebSphere Application Feed Generation Plugin Server Plugin Plugin Plugin Plug in

Atom, Database, Web Service, spreadsheets, LDAP, RSS etc. Internet and enterprise data sources

Figure 4. IBM MashupHub.

MashupHub Feed Mashups . MashupHub allows for the creation of “feed mashups” (sometimes known as “data mashups” in the DAMIA project that was used in creating MashupHub (“IBM DAMIA”, n.d.)). These are best thought of as feeds created by “mashing” (manipulating/filtering etc.) other feeds (and the feeds

it mashes could themselves be feed mashups). These are created using the feed mashup builder (with its browser-based graphical client interface). Like other feeds they can be saved in the catalog, for use in other feed mashups or for display by regular (visual, or web) mashups.

Lotus Mashups . Lotus Mashups (“Lotus Mashups,” n.d.) is an environment for developing and running web mashups. It presents a graphical interface to assemblers allowing drag and drop construction of mashups from a palette of widgets. Like MashupHub, it consists of client-side components that execute in a web browser, and server-side components, which execute within WebSphere

Application Server. The client components provide a runtime environment for the mashup pages, including facilities for communication between widgets, and making requests of the server. Assembling or modifying of mashup pages is enabled by switching to ‘Edit’ mode; this provides additional options on the page, and renders the widgets differently (so they can be moved and configured). As part of the server-side component, an AJAX proxy (an HTTP proxy service for use by AJAX controls in the client) is included. Accessing feeds and other web resources via this proxy allows the mashup’s widgets to bypass the same origin restrictions normally imposed by the browser (which limits scripts to only accessing content from where they were loaded from). This architecture allows administrators to exercise some control over what content is made available.

Web Browser

Mashup Client mashup mashup assemblers users

feed definitions, saved pages, HTTP feed pages, widgets requests data via proxy

Data HTTP feeds Store Mashup Server Proxy from other domains WebSphere Application Server Imported widgets, page s Published/shared pages and feed definitions

MashubHub

Figure 5. Lotus Mashups.

Lotus Mashups uses its own data store, separate from the MashupHub catalog, for persisting configuration details and other items it needs. By default, the regular file system is used for this data store; however, a database can also be used.

Lotus Mashup Widgets . Lotus Mashups ships with a few visual and non- visual widgets. Visual widgets are included for things such as displaying the contents of a feed in a multi-page table, displaying a web page, or displaying a chart. Non-visual widgets are included for things such as modifying data (as it is transferred between widgets on the page) and causing timed events (such as a page data refresh). Additional widgets can be imported from the MashupHub

catalog. Feeds can be also imported, although they are not manifested as feeds, but as widgets connected to feeds.

Since the number of widgets supplied by default is quite limited, an enterprise will certainly want to develop some of their own. Widgets used by

Lotus Mashups must confirm to IBM’s iWidget specification (“iWidget

Specification”, n.d.), which purports to be both simple and extensible. Widgets can be created without specialized tooling according to the “Widget Programming

Guide” (n.d.), but the recommended approach is to use IBM’s Lotus Widget

Factory product, sometimes bundled with the IBM Mashup Center. Another product, IBM’s WebSphere sMash (“WebSphere sMash”, n.d.), can also be used for creating iWidgets; however, its primary goal is to offer an alternative, programmer-oriented environment and approach for quickly developing situational web applications.

There are large numbers of widgets available from other sources such as

Widgetbox ( http://www.widgetbox.com ) and Google (“Gadgets”, n.d.). Some have limited interaction capabilities (e.g. a widget may just display the time of day in an attractive format), and others are more sophisticated (e.g. calculators, miniature games). However, they are generally not intended for widget-to-widget communication. These are designed primarily for inclusion in web pages, and do not adhere to the iWidget format. However, it is sometimes possible to use them because IBM has specifically included “wrapper” widgets. For example, the

“Google Gadget” widget can be added to a mashup, and configured to use a particular gadget of Google’s. The HTML Markup widget (which can be

configured to render chunks of HTML) can be used to include widgets from other sources, such as Widgetbox.

Lotus Mashup Pages . Mashup pages created in Lotus Mashups can be

‘published’ to the MashupHub catalog, to be made available for other users.

Within Lotus Mashups, users have their own tree of mashup pages they can access. These could be pages they created themselves, or pages imported from the MashupHub catalog.

Evaluation Approach

We will evaluate the IBM Mashup Center to determine how well it should meet an enterprise’s needs. To do this, we will perform a series of exercises actually using the product. This will provide a greater level of familiarity, beyond that provided by a simple literature review. IBM has a publicly available (with registration) testing environment for the IBM Mashup Center at the Lotus

Greenhouse site ( https://greenhouse.lotus.com ). As well as allowing you to try the products without having to install them, this site has many other useful resources for those interested in the product, including additional documentation, widgets, and sample mashups. However, our exercises will be done using a locally installed trial copy of the product, because of the control and flexibility offered by a local test environment. Once installed, some (minimal) effort will be made to get familiar with the functionality of the product’s user interface, and any introductory tutorials offered will be completed prior to starting the exercises.

Scope . One of the touted benefits of mashup creation is that general business (non-programmer) users can accomplish it. For this reason, the 40

exercises (except perhaps for the last one) are intentionally biased towards that which should be achievable by these users.

Availability of a wide selection of widgets is obviously desirable, but evaluating the process for creating them is not covered in our examination. It is assumed that this will require a high level of technical expertise (if not actually programming expertise) for any mashup tool. Therefore, no testing will be done with Lotus Widget Factory or WebSphere sMash.

Exercises . For each of the exercises, significant issues will be noted and an evaluation made of how successful the tooling was in creating a mashup which met the objectives. Other observations deemed relevant (e.g. if any steps were particularly difficult or time consuming) will be reported. Although somewhat subjective, if particular steps are deemed too difficult or complicated for a technically oriented business (non-programmer) user, this will be noted.

The following exercises will be attempted:

1. The initial effort is akin to a “Hello World” programming example, in that

we are not attempting anything deep or complex, but merely want to

confirm that creation of a simple mashup can be created without

following a script (as would have been done in the tutorials). Since

many (non-enterprise) mashups are visually interesting, involving such

things as maps, the intent is to produce a simple address list to map

location mashup. In a real business scenario, this could be showing

customer or supplier locations.

2. The second attempt will try to focus more on whether the tooling is

actually appropriate for accessing enterprise data. Information from a

variety of different types of sources will be made available. Types of

sources will include at least a relational database and a web service.

The test may be expanded to include other types if the tooling supports

them.

3. Thirdly, rudimentary “data mashup” capabilities will be tested. A feed

will be created which involves some filtering and transformation. It is

anticipated that this capability would be particularly important in an

enterprise because of the typical mismatches between the way data is

stored in the enterprise and the way users (who may be building visual

mashups) envision it.

4. The ability to update or inject data into a system is key in many

enterprise applications. An attempt will be made to create a mashup

will which will allow data to be entered into some form of data store

(e.g. a relational database). This is atypical of traditional mashups,

which are ‘view only’; however, the scenario is common in enterprises,

so it will be interesting to see how (or even if) it can be done.

Obviously the exercises are a very limited subset of what many organizations would want to achieve. It can be difficult to gauge all of the capabilities of a product from its documentation alone; actually using it to achieve some specific goals can provide a better exposure to its intricacies, and it is intended that the exercises will help with this. Therefore, along with the results,

any potentially useful additional features discovered (but not used in the exercises) will be examined and discussed in more detail.

CHAPTER IV

RESULTS AND ISSUES

Installation

The test environment consists of a small (2 gigabytes of RAM) machine running Windows XP Professional, with networked access to DB2 databases,

LDAP directories and Web Services.

Version 1.1 of the IBM Mashup Center was installed for the evaluation.

Although the IBM Mashup Center normally requires Windows Server 2003 or

Linux, the downloadable trial version runs on Windows XP Professional. The trial code installs with very little configuration required – the install location and a user name and password need to be selected. Installation completed with no problems. An instance of the WebSphere Application Server version 6.1 was installed with the trial, and this hosts the MashupHub and Lotus Mashups products, along with additional servlets used by some of the specialized widgets.

The install added choices to the Windows “Start” menu to start and stop

WebSphere Application Server, as well as access its administration console (a web interface, only available while the server is started). Additional menu choices were added to access the Lotus Mashups and MashupHub user interfaces, and to invoke a “First Steps” application. First Steps offered links to some additional

documentation, including a tutorial (irritatingly, selecting these links launched the

Internet Explorer browser, rather than the system default browser).

Initial Impressions and Considerations

There is an extensive tutorial included in MashupHub that focuses specifically on MashupHub. The IBM Mashup Center wiki has several other tutorials, including an introductory one that focuses more on Lotus Mashups.

Approximately one day was spent completing these two tutorials and becoming familiar with the product. The tutorials were reasonably clear, but some of the material would likely be beyond most non-programmers (for example, use of regular expressions). Completing the tutorials only provided enough knowledge to tackle simple mashups; a substantial amount of exploration and experimentation was needed to capture additional subtleties (some of which may be hard for business users, such as casting of values so that comparisons work as expected).

Not all browsers are currently supported. Firefox version 3, Internet

Explorer version 7, and Apple Safari version 3 are supported; however, all of these browsers have newer versions that, along with Google Chrome, are not explicitly supported. The latest Firefox (version 3.5) is known to cause problems, so it was necessary to revert to version 3 for testing. This was a little disappointing, but is likely because of two things: the relative immaturity of the product, and the heavy dependence on sophisticated browser capabilities such as style sheets and JavaScript.

There were numerous cases where the tutorials and other pieces of documentation were inaccurate. This could get a little confusing sometimes, but caused no significant issues. This is likely a consequence of the speed of evolution of the product. Documentation (available via the wiki) was a little sparse

– perhaps depending too much on community involvement.

Only two bugs were discovered during the tutorials: the option to pull widgets into Lotus Mashups from the MashupHub was not always available, and the Google Gadget widget was not always displaying gadgets properly. The first was worked around (by ‘pushing’ the widgets into Lotus Mashups via the

MashupHub), but the second required a new version of the Google Gadget to be installed, to adapt to interface changes made by Google. Such dependence on external interfaces could be a stumbling block for enterprises, but likely something they cannot avoid.

Interfaces and Facilities

MashupHub . The main page of the MashupHub is shown in Fig. 6. It highlights the major facilities available: searching the catalog (“Catalog” and

“Community” sections), creating feeds and feed mashups and adding items to the catalog (“Create” section). “Getting Started” provides some basic educational material for using the MashupHub. In addition, most of the pages in MashupHub have specific help available, either from the ‘Help’ link in the masthead or from page-specific help links.

Figure 6. MashupHub Main Page.

The Catalog section provides basic catalog lists. The Community section includes searches based on user ratings, comments and other activity. It is a reflection of the Web 2.0 approach of involving users in the growth and enrichment of the environment. Individual entries (e.g. a feed or a widget) can have comments and tags added, and ratings applied. An example catalog list

(“Most Popular”, based on user rating) is shown in Fig. 7.

The Create section covers catalog object creation. When objects are created, basic information such as name and description is collected, and tagging and categorization information can be added. By default, catalog objects are

created “Public”, but for more security this can be changed to “Private” (only the creator can access it) or “Custom” (which allows you to specify users and/or groups). Without appropriate permission, objects are invisible (do not appear on catalog searches or lists).

Widgets are imported from expressly structured “.war” files containing the iWidget details (which may have been created by tools such as Lotus Widget

Factory). Mashup pages are imported from XML files with a specific schema (that may have been exported from another MashupHub). We are most interested in the creation of feeds and feed mashups.

Figure 7. MashupHub Catalog List.

Feeds . There are two basic types of feed that can be added to the catalog:

• Existing Atom and RSS feeds, already available (on the intranet or

Internet).

• Atom feeds which are actually generated by MashupHub, based on

data in another format (e.g. relational database, Web Service).

Regardless of type, feed creation is done using a similar series of pages prompting for required details. Some feed sources (for example, a Web Service) may require parameters to signify which subset of the possible data is returned in the feed. Performance is addressed minimally with some caching options. The standard catalog security options (Public, Private, Custom) also apply.

Feed Mashups . Feed mashups are created in the MashupHub using a special edit page (shown in Fig. 8). Operators are dragged from the left column on to the canvas, and wired together.

Figure 8. Feed Mashup Canvas.

Feed mashups consist of one or more Source operators (representing feeds) that are wired, via various other operators, to a Publish operator. There is always exactly one instance of the Publish operator; its output defines what is actually presented when this feed mashup is invoked. Source operators have no inputs and one output; the Publish operator has one input and no output. All other 49

operators produce a single output stream, and have one or more inputs

(depending on the operator). The other available operators are:

• Combine – combines entries from two or more feeds into a single

feed. Individual entries are not changed or joined, but the resulting

feed contains all entries from all of the inputs.

• Filter – drops entries from the feed, based on configurable selection

criteria.

• For Each – connects two input feeds, a primary and a secondary.

The secondary should be a feed which uses selection parameters in

its URL. For each entry in the primary feed, selected values are

extracted and plugged into the secondary feed URL. Essentially a

lookup is done, and the data fetched from the secondary feed is

combined with the primary in the output entries.

• Group – squeezes multiple entries with common values in specified

elements into a single entry. For example, a feed containing

transactions for customers could be converted to a feed with a

single entry per customer (with multiple sets of transaction data in

each entry).

• Merge – joins the entries from two source feeds or operators based

on a join column or condition. The final result is similar to the For

Each operator: each output entry contains data from both inputs.

• Sort – sequences the data stream according to certain columns.

• Transform – restructures (changes elements) and manipulates

values in feeds. Elements can be added or removed, and values

changed (based on formulas or hard-coded values).

The feed mashup capabilities of MashupHub allow manipulation of feeds in various ways, similar in some ways to the SQL used with relational databases.

Table I shows the correspondence.

Table I. MashupHub Operator Correspondence to SQL

MashupHub operator Similar SQL functionality

For Each and Merge Inner join of two tables

Combine UNION ALL

Filter WHERE clause

Sort ORDER BY

Group GROUP BY

Transform Columns and expressions in SELECT clause.

Lotus Mashups . The Lotus Mashups interface is fairly lightweight. Within the browser window it displays a single mashup page, and has a minimal number of operations available from the masthead, essentially:

• Select a different page.

• Perform operations on the current page (publish, share, delete,

edit).

• Open the MashupHub catalog (this opens a separate MashupHub

window).

• Logout.

• Help.

Clicking ‘Help’ opens a new window on the IBM Mashup Center wiki; there is no help text built directly into the interface.

Switching to ‘Edit’ mode presents a tool bar offering additional options – primarily a list of widgets that can be dragged from their category drop-down onto the page canvas. Fig. 9 shows a page in edit mode.

Figure 9. Lotus Mashups Edit Mode.

Out of the box, Lotus Mashups does not offer many widgets. However, additional widgets – home-grown or from other sources – can be imported. The widgets supplied can be broadly grouped as follows:

1. Example feeds. These are actually Data Viewer widgets configured to use

specific feeds.

2. Specialized examples of what can be done with widgets. This includes

widgets for displaying weather conditions, interactive maps, slide shows,

and news feeds.

3. General purpose and utility widgets. These are flexible widgets providing a

variety of useful and necessary capabilities.

These general/utility widgets include an assortment for displaying data as a table or a chart, and for presenting images, snippets of HTML, and complete web pages. They also include several simple but unusual widgets providing an assortment of capabilities needed in many mashups:

• Action Timer – Signals events based on a timer.

• Data Editor – can display data in a tabular view (like Data Viewer),

but its primary function is to filter or modify the data and pass it to

other widgets via an event.

• Event Explorer – handy debugging/learning tool which displays

details of events and data received from other widgets.

• Google Gadget – a ‘wrapper’ widget that allow Google Gadgets to

be used.

• JavaScript Adapter – runs user JavaScript instructions to modify

event data.

• Regular Expression – searches and modifies event data using

regular expressions.

• URL Customizer – collects parameter values from event data and

plugs them into a URL as parameters.

• User Input – allows data to be input (typed) by a user.

Lotus Mashups doesn’t actually have ‘feed’ widgets. When a feed is added to Lotus Mashups it is added as an instance of one of the common widgets, but pre-configured with the feed URL. By default, the widget used is the standard tabular data displayer – the Data Viewer widget.

The widgets themselves have a common appearance, or ‘skin’. This can be changed, but by default includes a sizeable but unnecessary blue border.

When in edit mode, widgets can be repositioned and resized by dragging. When the mouse is positioned over a widget, options appear to allow changes to it. This includes options to change the skin, delete the widget, or configure its settings.

The settings vary by widget type, but include, for example, the URL of a feed or the elements to display.

Positioning the mouse pointer over the widget also offers the chance to make connections (event wiring) to other widgets. This can be done from the widget sending the event or from the widget receiving the event. Wiring two widgets together is relatively simple: apart from specifying the sending and receiving widget, you need only specify what data item is sent with the event, and in what format (as a string, a URL etc.). When making the connection, the supported items and their types are listed. The wiring menu changes as it steps you through the choices. An example is shown in Fig. 10. Note that when wiring two widgets together you can only select one data item to be sent or received 54

with the event (although this could be a compound item, such as a row or a table). In cases were the receiving widget needs to take multiple items and use them in different ways, the sending/receiving item correspondence needs to be determined (for example, OpenStreetMap receives an address, an icon to display, and an icon size). This needs to be specified in the widget settings, but perhaps more sophisticated wiring support would have been a better approach.

Figure 10. Lotus Mashups Wiring a Connection.

Users can make their pages available to other users in a number of ways.

Sharing the page makes it available to other (specifically selected) users in Lotus

Mashups. Publishing the page puts it into the MashupHub catalog where other users can search for it (assuming it is not published as private). Pages may be published either as a URL, or as the artifacts which make up the page, which is likely more useful when moving them to different MashupHub instances. Mashup pages can also be embedded in other, traditional web pages. When this choice is

selected, Lotus Mashups provides the appropriate HTML which must be pasted into the target page.

There appear to be limited options for tailoring the interface to match an enterprise’s standards (colors, fonts, layout etc.). It is possible to change some of the style sheets and skins, and mashup pages could be embedded in standard pages – but this likely will not achieve all that is needed. Still, this may not be all bad – as we indicated earlier, the different look may be beneficial to users, letting them know they are not using an application developed and tested in the ‘normal’ way.

It was confusing sometimes when the mashup page widgets took a long time to refresh. This was made worse because the browser’s normal ‘loading’ icon (which shows when a page is part way through loading) does not show when the AJAX widgets are still loading data.

Overall, however, the interface is attractive and easy to become familiar with and use.

Exercise 1

Objective . The main point of this exercise was to determine how hard it is to create a simple mashup without following a detailed script (as in the various tutorials), armed only with limited exposure to the tool and some ideas about what needs to be achieved – in other words, at the level of a relatively new user.

The mashup should display a list of addresses from a spreadsheet, and an interactive (can slide and zoom) map such as those available from Google

(http://maps.google.com ) or MapQuest ( http://www.mapquest.com ). Selecting one of the addresses in the list is to cause the location to be shown on the map; the map should have been zoomed and positioned appropriately (i.e. it should be a usable rendering).

Steps Taken . A test (Microsoft Excel) spreadsheet containing Canadian university names and addresses was added to MashupHub as a new public feed.

The feed was added to Lotus Mashups, as a new Data Viewer widget (this is the default widget for new feeds).

In Lotus Mashups, a new mashup page was created and the new widget dragged on to it.

Lotus Mashups includes an OpenStreetMap widget. This is an interactive map widget, and seemed ideal for the mashup. An instance of this widget was dragged to the page, alongside the Data Viewer widget. OpenStreetMap can support single or multiple locations, and has various options (such as whether to show balloon text next to plotted locations, and whether to clear existing markers when new locations are supplied). Initially, the ‘address’ from the Data Viewer was wired to the ‘location’ of the OpenStreetMap. As an improvement on this, it was discovered that the entire selected row could be passed (i.e. the Name as well as the Address fields). OpenStreetMap had options to map elements to different functions, so ‘Name’ was associated with the balloon popup text, and

‘Address’ (as before) with the location.

The resulting mashup is shown in Fig. 11.

Issues and Observations . The mashup did achieve what we wanted. An initial version actually only took a few minutes to create. However, refinement was needed not just in arranging layouts and picking ‘skins’ for the widgets, but to set appropriate options on the widgets. For example, the OpenStreetMap widget has an option to clear previous markers when new locations are posted to it. This was not selected by default, and in combination with some other issues resulted in some confusing behavior from the widget (such as incorrect zoom, or no response at all). It was necessary to spend some time studying the widget options and the (limited) documentation available for the widget in the wiki. Far more time was spent on refinement and exploration/testing than was spent on the initial creation.

Figure 11. Exercise 1 Mashup.

Initially, the OpenStreetMap widget did not appear to be responding, and searching the IBM Mashup wiki revealed that there was an updated version of the widget available for download. Apparently, the underlying interface to the

OpenStreetMap data had changed recently, and corresponding changes were

needed to the widget. Application of this update required administrator access to the underlying WebSphere Application Server platform, so was certainly beyond a typical user. This adds weight to the idea that IT will need to play a key role in providing and supporting the infrastructure for users. It also highlights the problems of depending on external interfaces, over which there is no control.

OpenStreetMap makes use of the several free services (from http://www.openstreetmap.org and http://www.geonames.org ) for maps and geocoding. However, There were some limits to its accuracy; some of the addresses tested did not display properly, if at all. Another interactive mapping widget, NavTeq, was also tried. This has similar functionality to OpenStreetMap, and resolved all addresses fairly accurately. However, it does have more stringent usage conditions, requiring purchase of a license for production use.

Determining need for, and procuring, licenses is one more area which will need to be organized – one more responsibility for IT.

As indicated earlier, Google Gadgets can be incorporated into mashups, using the Google Gadget ‘wrapper’ widget. There are numerous gadgets written by third parties which provide access to Google’s mapping services, and these could (theoretically) be used; however, experimentation with several of them failed to provide a working mashup. The reasons for the issues are unknown, but the complexity of the solution (wrapper widget using a third part gadget using

Google interfaces) provides a greater potential for problems.

A fourth mapping option was to use the Web Site Displayer widget (which simply displays a web page for a given URL) to display a map from a public

mapping web site such as Google Maps. With the appropriate URL parameters, displaying a properly zoomed map with a location marker is not that difficult.

Lotus Mashups provides a URL Customizer widget to simplify insertion of data sent from a widget into a URL’s parameters, which is then sent to another widget

(Data Viewer widget is wired to the URL Customizer widget which is then wired to the Web Page Displayer). However, this may be too technical for many users, and depends on the constancy of the URL parameters.

Exercise 2

Objective . This exercise focuses more on the enterprise environment: we want to make sure that we can access data in a variety of typical enterprise formats. We are looking at capabilities and limits, as well as ease of access.

Much enterprise data is held in relational databases, and Web Services are also frequently used, so our mashup will include both. LDAP (Lightweight

Directory Access Protocol) directory sources are popular, but unfortunately, we cannot test them because our trial version of IBM Mashup Center does not support it (although the fully licensed version of the product does, plus some additional source types). Since we have already tried spreadsheet data in the previous exercise, we will use CSV (comma-separated value) and XML in this one. These are particularly relevant because one or both of these are used in a variety of tools, as an export (data interchange) format.

The mashup should display a list of hostnames from the CSV feed. When an entry is selected, the host’s internal system identifier will be retrieved from the

DB2 (relational database) feed. This internal system identifier will be passed to 60

the Web Service feed to retrieve the systems details, including the system’s security classification. The classification is then passed to the XML feed to retrieve the matching textual description, which should then be displayed.

Steps Taken . Well over one day of effort was expended to create the mashup; the objective was achieved, but there is still much room for improvement in presentation and performance.

Feeds for the CSV, XML, SQL and Web Service feeds were created in the

MashupHub, and added to Lotus Mashups as Data Viewer widgets (the default).

This was somewhat trivial for the CSV and XML feeds. The Web Service and

SQL feeds were a little more complex, as they return a subset of the underlying data, based parameters supplied at run time. For the Web Service feed, this parameter was the internal system identifier, and for the SQL feed, it was the hostname.

We created a new page in Lotus Mashups, and added the CSV and SQL feeds (represented with Data Viewer widgets) to it. We wanted to wire the widgets so that selecting a row in the CSV widget (a list of hostnames) would cause the SQL widget to display the associated internal identifier. To achieve this we had to communicate the variable value – the hostname – to the SQL widget.

This value would then be communicated in the feed request (as part of the URL) when the SQL widget retrieves its feed data.

The Data Viewer widget allows for its feed URL to be received from another widget, so we made use of the URL Customizer widget. URL Customizer receives event values and inserts them as parameters into a configured URL. It 61

then immediately sends this URL to another widget. Thus, we wired the CSV

Data Viewer widget to the URL Customizer widget, which itself was wired to the

SQL Data Viewer widget. This achieved the desired result of displaying the internal system identifier for the selected hostname.

Next, we added the Web Service Data Viewer widget, and wired the SQL widget to it, via another URL Customizer. This was not difficult, and with appropriate customization, selecting the single internal identifier row in the SQL widget resulted in the display of the corresponding system details in the Web

Service widget. Of course, this is not ideal: we need two mouse clicks before we see the system details. If we continued to follow this pattern, we would need three mouse clicks when we added the fourth feed widget.

To rectify this, the SQL Data Viewer widget was replaced with a Data

Editor widget (using the same receive/send event wires). The Data Editor is similar to the Data Viewer except that it allows for modification of the data (such as filtering rows) and it sends its event data when it receives event data – it does not need to be ‘clicked’. This solved the problem, and the same change was made to the Web Service widget.

Continuing our event chain, the XML widget was added. However, since the XML feed has no inherent filtering (no parameters), and we only want the data for a specific security classification, the MashupHub was used to create a feed mashup based on the XML feed. Feed mashups have extensive manipulation capabilities, including the ability to filter based on a parameter

value. This feed mashup was then used in our mashup instead of the original

XML feed.

The final hurdle was to display the security description in a readable format. The default Data View widget presents a tabular view, showing the long textual description as a single, long line. Since this was not a desirable rendering, we wrapped appropriate HTML formatting tags around the text, and displayed it using an HTML Markup widget (which can display snippets of HTML). This text manipulation was done using a JavaScript Adapter widget, which allows incoming event data to be manipulated using a script, then immediately sent on to the next widget.

Lotus Mashups allows widgets to be hidden, and this was done for most of the widgets in our mashup (since they were only for data manipulation). The resulting mashup is shown in Fig. 12.

Figure 12. Exercise 2 Mashup.

Issues and Observations – Lotus Mashups . Some minor bugs were encountered when creating the mashup. Specifically: some HTML tags were ignored when used in the HTML Markup widget, and the Data Editor widget had

problems with how spaces were specified in URLs. This last issue necessitated the addition of the Regular Expression widget (which modifies strings) in our mashup, to ‘fix’ the URL before it was passed to the Data Editor.

Focusing on the user interface of the mashup, most users would be uncomfortable with the level of complexity of this exercise. When viewing all of the mashup widgets (including those normally hidden), the mashup page is quite crowded, and does not show the wiring between widgets. Wiring can be examined for individual widgets, but it can be hard to keep track. Fig. 13 shows the mashup with all of its widgets exposed, and how they communicate. Some of the convoluted wiring could have been avoided with a greater selection of standard widgets in Lotus Mashups. For example, widgets to display values as lists or flowing text rather than just in a tabular fashion would have helped avoid using the JavaScript Adapter (which is likely too difficult for non-programmers to use). In addition, it would have been useful if the Data Viewer (or Data Editor) widget had the option to receive incoming event values and use them as parameters for its associated feed URL. With such an option, we could wire two

Data Viewer widgets directly, without a URL Customizer acting as an intermediary.

Issues and Observations – MashupHub . The various types of data sources supported as MashupHub feeds each need their own special treatment. Some require restructuring or additional information to be useful.

Figure 13. Exercise 2 Mashup Widget Communication

When creating the Web Service feed for the exercise, the MashupHub read the associated WSDL (Web Service Definition Language) file, and determined that the Web Service needs a single parameter (the internal system identifier). When testing (viewing) the feed, it prompts for this value, and retrieves only the data satisfying it. When specifying the URL for the feed, the value must be passed as a parameter in the query string.

SQL feeds can be created with no knowledge of SQL, as MashupHub prompts for which table and columns to query. However, it does not prompt for

(or automatically provide) join columns when selecting multiple tables. This may not be intuitive behavior for most users. It does allow you to specify your own

SQL ‘select’ statement for the query; it also allows you to generate the statement from the selected tables, and then modify it (e.g. by adding a join column). Using this advanced form of query specification provides another useful feature: use of

‘variables’ in the statement. These variables are populated from parameters passed on the feed URL (as they are for the Web Service feeds). This allows for filtering/limiting the rows returned – for example, you could retrieve only the row with a particular employee number, rather than for all employees. For our exercise, the query selected the row with a specific hostname, and a variable was used for the value.

Exercise 3

Objective . For this exercise we are examining the MashupHub, its web interface, and the capabilities provided.

The feed mashup should essentially do the work of the mashup we created in exercise 2, presenting the four basic feeds (from CSV, SQL, Web

Service and XML sources) as a single feed. Since this new feed would contain all of the original data (joined appropriately), it could then be used in Lotus Mashups to create the mashup from exercise 2, but with far fewer widgets.

Steps Taken . Using the MashupHub web interface, a new feed mashup was created. Source operators were dragged onto the canvas for all four original 66

feeds from exercise 2. The properties for each Source were updated to use the feed type as a name (rather than the default of “Source”, which gets a little confusing when there are multiple).

A For Each operator was added to join the CSV Source to the SQL

Source. For Each makes a call to the second feed for each entry in the first feed, using a key value (in this case the hostname, as this was common to both feeds).

The second feed must be defined with selection query parameters in its URL. The resulting entries contain elements from both Sources.

The output of the For Each was then wired to a second For Each operator, which was used to join to the Web Service source (this time, using the internal host identifier as the join key).

To join to the final Source, a For Each operator could not be used, because the final (XML) feed does not allow for any selection criteria. We could have used the small feed mashup we created in exercise 2, instead of the original

XML feed, as our Source. That small feed mashup essentially allowed us to specify a selection column (the security classification, such as ’Production

Server’) to pull a subset of the XML entries. However, we stayed with the original

XML feed and instead used a Merge operator. This is similar to the For Each operator in that it ‘joins’ entries (equivalent to an ‘inner join’ between two tables in SQL). However, the internal mechanism is different, so it does not require either of the Sources to be based on a feed that takes selection parameters in its

URL.

The result from the Merge was then wired to a Transform operator, which allows us to specify which values to include in the output, and how to structure them. This was then wired to the final Publish operator.

Upon reviewing the output, it became apparent that the hostname value was duplicated (displaying the data in a Data Viewer widget in Lotus Mashups showed a ‘hostname’ and a ‘hostname_1’ column). This was remedied by adding a Transform operator immediately after the SQL Source, to ‘rename’ the column to something unique and allow for it to be excluded in the final Transform

(immediately before Publish).

Figure 14. Exercise 3 Feed Mashup Graph.

Fig. 14 shows the feed mashup graph. Fig. 15 shows a Lotus Mashups

Data Viewer widget displaying the feed.

Figure 15. Exercise 3 Mashup Output.

Issues and Observations . Ultimately, the feed mashup did achieve the objective. Piecing the operators together and producing a feed containing what we wanted took less than an hour. However, that feed was not easily usable in

Lotus Mashups, and there were several more hours spent adjusting operator properties.

It is troubling that creating a feed mashup demands that you to be familiar with XML, and ideally the Atom format. Setting the properties for many of the operators requires that you select elements within an XML hierarchy, meaning you typically have to expand and search through many nodes. This can get a little tedious - It would have been nice to be able to expand a node and its entire tree with one click (instead of having to expand each node and subordinate node individually). Also, finding the correct elements can quickly become challenging as more Sources are connected, and compounding this is the similarity and duplication across feeds. For example, Atom feed entries always include ‘id’,

‘updated’, ‘title’, and usually ‘content’ tags, so you can end up with multiple instances of them.

MashupHub makes its simple feeds available as Atom feeds, and some

Lotus Mashups widgets expect this. Therefore, it is natural to want to produce

Atom output from feed mashups (as opposed to the less controlled structure that

XML output allows). However, the onus is on the developer to make sure the output conforms to Atom; it would have been useful if there were more support for automatic handling of Atom elements.

Another consideration is that feed mashup creators may be more comfortable thinking of data in tabular forms (relational database tables, spreadsheets), rather than a hierarchical form (XML). This is further emphasized by the Data Viewer and Data Editor widgets in Lotus Mashups which present and process as a table.

Earlier, we compared feed mashup operators with SQL. Given the acceptance of SQL and its long history for manipulating sets of data, it is a good sign that the MashupHub operators mirror some of its major capabilities.

However, it is difficult to know if MashupHub will be able to handle most scenarios (SQL, which has had far more time to adapt to requirements, is much more extensive). Continuing the SQL comparison, there is another area for concern: performance. Relational databases (even those providing federated access to different types of data stores, under the covers) are designed to perform well. MashupHub is unlikely to be able to offer anything even close, especially as its focus is more on simplicity and flexibility rather than optimization of data access. If it is used to construct complex feed mashups, it could become quite cumbersome (e.g. making repetitive Web Service calls). In this exercise,

performance was quite poor (could take several seconds to process the feed mashup and present it); however, this was likely more because of the limited test environment (it should be noted that the performance was no better in exercise

2).

It appears that using the feed mashup approach to do most of the data mashing (rather than using the on-the-glass widget approach of exercise 2) is more appropriate. It leaves the Lotus Mashups environment to handle the presentation end of things, for which it is more suited.

Issues and Observations – Transform . The Transform operator deserves special mention. It is incredibly useful because of the very detailed manipulations it can perform on the feed stream. It allows for moving, deleting and adding of individual elements. This turns out to be necessary on all but the simplest feed mashups, because several of the other operators make changes to the stream that may need to be corrected. For example, the Merge and For Each operators combine two inputs producing a single output, where each output entry contains data elements from both inputs. If the inputs were Atom feeds, then each had their various data elements contained within a single ‘content’ node within each entry. The output would contain two content nodes (each corresponding to one of the inputs) in each entry. If this is simply published as is, it can produce unexpected results. If it is added to Lotus Mashups using the standard Data

Viewer widget, this widget will only display the elements from one of the content nodes (i.e. from only one of the original feeds). Essentially, we took in two Atom feeds and produced something that was not a valid Atom feed. Using the

Transform operator, we can map the individual elements from the two content nodes into a single content node, thus retaining our Atom feed integrity.

Transform itself is not without issues. When listing the available input elements, it tends to combine duplicates into one element. For example, if both inputs contain an ‘abc’ node, these are shown as a single abc node, containing all of the elements from each input’s abc node. If you copy this abc node to the output, the resulting output stream contains both abc elements – there was no obvious way to select just one of them. It was unclear whether this was by design, but it proved to be inconvenient. In this exercise, the element names between the different feeds were (except in one case) unique, even when referring to the same value. For example, the XML feed uses ‘name’ to refer to the security classification, but the Web Service feed uses ‘use’. The one exception was the ‘hostname’, used in the CSV and SQL feeds. Obviously these would contain the same value in our published feed, so there is no need to have both. The pre-Publish Transform, unfortunately, forced us to copy both

‘hostname’ values (or neither).

To get around this, a Transform was added immediately after the SQL

Source, solely to rename this element (actually, there is no ‘rename’, but you can copy an element’s contents to a new element with a different name). Once it was uniquely identified, it was possible to selectively drop it in the final Transform.

Exercise 4

Objective . This exercise is aimed at exploring the facilities (if any) which

IBM Mashup Center has for building mashups which can modify (add, delete, 72

update) data in an enterprise data store. Although this scenario is probably an unlikely requirement for the typical business user, it is a possibility. In addition, if mashup technologies do find a home in enterprises, technical IT developers may want to make use of it for more advanced situational applications that would need the capability.

To keep it as simple as possible, the mashup should collect data (typed in by the user) and insert this into a relational database table.

Steps Taken . None of the tutorials touched on data modification in any way, so a search was made of the wiki and any other relevant documentation about how to approach this. Only a few references were found to mashup applications providing this kind of capability (Adams, 2009; Pandya, Cherbakov,

& Bravery, 2008), with no detailed instructions on how to achieve it using only

Lotus Mashups and MashupHub – so nothing further was done.

Issues and Observations . The objective couldn’t be achieved using only the IBM Mashup Center. However, some of the documentation did provide some insight on how this type of application could be constructed.

Obviously display of existing data from an enterprise database is not an issue, as this is a typical use of mashups. Collection of data form the user is also not an issue as there are widgets for this (e.g. the User Input widget which provides input boxes and a ‘submit’ button) and new widgets could also be created. The problem is the communication of the modification request to the underlying database. MashupHub is designed to accept requests and return feeds. Technically, it could be configured to actually make a modification to a 73

back-end database when a request is made, but this is something of a confusing trick, and an abuse of the architecture.

A suggested approach is to create widgets which communicate with a secondary interface – one which provides the data modification services. This could be, for example, a specialized servlet (created for that particular widget), or a more general service (perhaps providing a REST-style interface). Note that if this facility is on a separate server, requests would likely have to go through the

Lotus Mashups HTTP proxy. Fig. 16 shows this arrangement.

Web Browser Widgets

HTTP Proxy (if needed)

Fe ed Fetch/updates MashupHub REST-style update request interface

Enterprise Data Store

Figure 16. Exercise 4 Data Modification Mashup Approach.

Obviously developing specialized Servlets is labor intensive and limited, so using a more generic facility is desirable. To help with this there are several products available which can be used to simplify creation of REST services to access enterprise databases. This includes IBM Data Studio (“IBM Data Studio”, 74

n.d.; Bommireddipalli, 2007) and WebSphere sMash (“WebSphere sMash”, n.d.).

Note that sMash includes iWidget development capabilities as well, and may be a better option for developing these types of situational applications in their entirety.

Summary

We installed a trial version of the IBM Mashup Center with no problems.

Basic tutorials and the product’s wiki were used to get familiar with it.

Documentation was a little sparse (with a few mistakes), some product bugs were encountered, and browser support was lacking – but these issues are expected, given the product’s level of maturity.

MashupHub provides a clear interface for creating feeds and feed mashups, as well as searching and adding objects to the catalog. It provided basic Web 2.0 capabilities for community assessment and rating of objects.

MashupHub’s feed mashup editor is easy to use, and provides a full pallet of operators for manipulating and merging feeds. Unfortunately, it seems to require significant understanding of XML and Atom formats, and its XML-oriented approach may be difficult for users more familiar with a table-oriented view of data.

Lotus Mashups is a lightweight and easy to use visual mashup development environment, despite its limited help facilities. However, creating large mashups can quickly lead to a crowded and complex page. Some improvements in the interface could address this – for example: less bulky widget skins, adjustable page widths, better display of wiring. There are options

for changing the look of the interface, but these are probably not sufficient to make mashups match an enterprise’s regular web applications.

The first three exercises were completed successfully. The final exercise – which involved updating of enterprise data – was beyond the product’s capabilities. This may not be an obstacle for organizations intending to use the product primarily for user developed query or dashboard applications. Data modifying applications could likely be developed using IBM Mashup Center in conjunction with other products. The exercises did demonstrate that a variety of typical enterprise data sources could be accessed, and that mashups could be created quickly. In all cases, however, trying to achieve exactly what we wanted took much longer. They also highlighted the need for a much larger selection of basic widgets in Lotus Mashups, especially for displaying data in different layouts.

IBM states that the IBM Mashup Center provides a complete platform for rapid development and deployment of dynamic web applications (“IBM Mashup

Center”, n.d.). This seems to be the case, except for applications that need to modify data. They have included management, security and governance capabilities, although our investigation cannot show whether these would be adequate for most IT environments. In addition, Lotus Mashups is supposed to provide an environment where technically oriented business users can create their own applications for their own needs, and share them with other users

(“Lotus Mashups,” n.d.). The product certainly enables this, although only experience will tell whether a significant number of business users will have sufficient competence and inclination to use it effectively.

CHAPTER V

CONCLUSIONS AND RECOMMENDATIONS

Summary

Within enterprises, different challenges have produced different requirements for mashup platforms and tooling. Enterprise mashup environments are server-based, considering various factors including security requirements and

IT’s need to control and manage. The development tooling is generally web based, and allows business users to create their own mashup applications by wiring widgets, feeds, and other objects together using a visual interface. They usually include a searchable repository of these objects, ideally making this available with features for community involvement (such as being able to rate objects).

With less focus on quality or control, this light and fast development approach is not appropriate for all applications. However, enterprise mashups are seen as a way to address the “long tail” of application development requirements, freeing IT from much of the work required to develop and maintain situational applications. Despite these reductions, IT still has a sizeable burden, including support and promotion of the mashup environment, guiding users, managing expectations, creating new widgets, and making enterprise data sources available.

As well as helping with IT’s workload, addressing these situational applications should provide additional benefits to the enterprise, enabling more innovation and gaining competitive advantage. Moreover, they provide another avenue to leverage an organization’s investment in SOA.

Several research projects have looked at mashup technologies and techniques, and several commercial products are available for developing, running and managing mashups. As an example of an enterprise mashup product currently available and being promoted, we examined the IBM Mashup Center in detail. Our investigation revealed a product that met the criteria for a mashup platform, but with some rough edges. The IBM Mashup Center demonstrated that information can be retrieved from disparate enterprise data sources, and that data and visual mashups can be created easily. However, the effort required increased dramatically when trying to refine the mashup to achieve something very specific. It was also apparent that certain types of applications (such as those which need to update data) either cannot be done or are not a good fit for the product. Furthermore, the level of technical knowledge required for creating sophisticated mashups is beyond that of most non-programmers.

Comparing mashups with traditional applications, research has identified numerous areas for concern, including performance, the quality of applications and data, and how to manage the user’s expectations. In addition, being able to manage the environment (including application lifecycle and dependencies), and provide adequate security without crippling innovation, are important areas. The mashup platforms help somewhat with some of these issues, but there is still a

lack of maturity and standardization in the tools and technologies used.

Additionally, assuming that users will be able to develop their own applications is a grey area. There are numerous unknowns and variables, including how well the tooling can reach the user’s level of technical ability, and what affects the user’s motivation to create.

Conclusions and Recommendations

User Participation . Despite the tooling, creating mashups is still a technically challenging proposition for many business users. It is unlikely that most (perhaps any) users will be able to assume full responsibility for applications without substantial guidance and assistance from IT. Even for users with the requisite technical expertise, we do not know how many will have the inclination and time to develop their own mashups. The level of participation will depend on several factors, including time constraints, corporate culture, and how or if the capability is promoted. Also unknown are the long-term trends for user involvement – will participation shrink over time (perhaps with boredom or frustration), or grow, as the approach catches on. Further research on this could be useful, but the reality is that user motivation (and how it may vary) will depend on many factors and be difficult to predict within a given organization. The community involvement will have a major impact on the overall effectiveness of the mashup approach. This means that committing to mashups – with the intent of depending on a significant, active user population – is a high-risk proposition.

The Role of IT . Even though they may be able to offload some of the development and maintenance of mashup applications to technical users, IT will 79

still have a considerable set of responsibilities – in fact, they will have the bulk of the work. Aside from the setup and support of the mashup servers, their mission will be to promote and encourage the use of mashups, and to guide, support and assist users where needed. IT will also be the main source of new widgets, and have to enable access to useful data sources in a consumable format. In addition,

IT will be charged with enforcing any standards imposed by the organization, and generally managing the environment.

Obviously, creating a mashup infrastructure within an organization is a major project. Although trying the technologies and products can be completed on a small scale, a productive and successful environment – especially one that fosters innovation – requires considerable user involvement. Moreover, to gain the real benefits of feedback, sharing, and other interactions, a large community is needed – the larger the better. Thus, the investment must be made on a serious scale. This will be an obstacle for many organizations, especially given the unpredictability of user participation. Another possible option for many organizations is to abandon the idea of heavy user involvement, and focus on using the products and technologies to improve IT’s ability to deliver applications

– essentially, IT would develop the mashups, instead of depending on users. This reduces our mashup concept to being a simpler (faster and easier) way to build composite applications. Although this throws away many of the potential benefits of mashups, it does offer a way for some organizations to gain familiarity and some benefits, with substantially reduced risk.

Even in an environment fully committed to the mashup vision of heavy user involvement, it may be more appropriate for IT to handle certain types of development (for example, data mashups). Application artifacts like this would form the building blocks for user created visual mashups. At this point, the idea of users doing most of their own application development seems to be something of a pipe dream; however, mashups still provide the potential for innovation and some productivity improvements, if enabled properly.

Approach and Tooling Maturity . The products available for creating and running enterprise mashups, and the technologies they are based on, are still evolving. Given the current level of immaturity and the vendor commitment in place, we can expect to see improvements, especially with regard to scalability, reliability, usability, capability, and compatibility. However, given the multitude of web browsers and browser levels in use, client incompatibilities may continue to be an irritant.

Tool interoperability is still limited – mashup-related standardization is occurring, but has not progressed significantly. Until larger strides are made on this front, there will continue to be a high degree of vendor lock-in associated with an enterprise’s platform choice, thus limiting mashup application portability.

Information Security . The current mashup platforms have features for addressing security – something that is crucial to the enterprise. However, whether these will be adequate in a culture of user created applications was not determined by our examination. For example, in the IBM Mashup Center, credentials are stored along with the data source definitions in the catalog –

maintaining these could be an issue. In addition, IT managed systems must often adhere to stringent security standards regarding access control, but there is probably no easy way to implement similar constraints on the myriad of user owned objects, on which users will be maintaining the permissions. Indeed, doing so may require substantial effort, and act as an inhibitor to mashup use.

We should also note that user-created artifacts are already available in most environments, typically as documents or other collections of data. However, mashups bring this to another level; mashups are interactive, and can create information – presenting protection difficulties or other unforeseen problems.

Paradigm Change . Mashups could be thought of as a simplification of composite applications: easier and cheaper to develop, but less controlled and less maintainable. However, perhaps the most important, far-reaching differences are not technical, but involve culture and expectations – the move away from a rigid systems environment to a more community-driven evolution of solutions.

This requires cultural changes by the organization to not just tolerate, but also embrace, the creation and use of systems that are less than perfect.

This would be quite a feat for most organizations; however, there are still advantages to using the technologies and tools now, in a more limited fashion – until they have evolved enough to soften the impact of a major change.

REFERENCES

Adams, H. (2009). Mashup business scenarios and patterns: Part 2 . Retrieved

September 20, 2009, from

https://www.ibm.com/developerworks/lotus/library/mashups-patterns-pt2/ alphaWorks services. (n.d.). Retrieved June 30, 2009, from

http://services.alphaworks.ibm.com/services.html

Anderson, C. (2004). The long tail. Wired Magazine, (12.10).

Arredondo, J.R. (2008). SharePoint: A platform for enterprise mashups. Retrieved

from http://www.microsoft.com/mashups

Ashley, B. (2007). Shaping the future of secure Ajax mashups. Retrieved from

http://www.ibm.com/developerworks/library/x-securemashups/

Bommireddipalli, V. (2007). Data Web Services: Build web services the new way

to access IBM database servers . Retrieved from

http://www.ibm.com/developerworks/data/library/techarticle/dm-

0712bommireddipalli/

Bravery, A. J. F., Cherbakov, L., & Pandya, A. (2008). SOA meets situational

applications, Part 2: Building the IBM Situational Applications Environment.

Retrieved from

http://www.ibm.com/developerworks/webservices/library/ws-soa-

situational2/

Business Mashups. (n.d.). Retrieved September 20, 2009, from

http://www.serena.com/products/business-mashups/

Cherbakov, L., Bravery, A. J. F., & Pandya, A. (2007b). IBM2 SOA meets

situational applications, Part 1: Changing computing in the enterprise.

Retrieved from

http://www.ibm.com/developerworks/webservices/library/ws-soa-

situational1/index.html?S_TACT=105AGX04&S_CMP=EDU

Cherbakov, L., Bravery, A., Goodman, B. D., Pandya, A., & Baggett, J. (2007a).

Changing the corporate IT development model: Tapping the power of

grassroots computing. IBM Systems Journal, 46 (4), 743-762.

Crockford, D. (2006). The application/json media type for JavaScript object

notation (JSON). Retrieved from http://www.ietf.org/rfc/rfc4627.txt

Crupi, J., & Warner, C. (2008). Enterprise mashups part I: Bringing SOA to the

people. The SOA Magazine, (XVIII). Retrieved from

http://www.soamag.com/I18/0508-1.asp

Datz, T. (2004). What you need to know about service-oriented architecture.

Retrieved from

http://www.cio.com/article/32060/What_You_Need_to_Know_About_Servi

ce_Oriented_Architecture

Fast and advanced storyboard tools (FAST) project. (n.d.). Retrieved June 10,

2009, from http://fast.morfeo-project.eu/

Gadgets. (n.d.). Retrieved September 27, 2009, from

http://www.google.com/webmasters/gadgets/

Garrett, J. J. (2005). Ajax: A new approach to web applications. Retrieved from

http://www.adaptivepath.com/ideas/essays/archives/000385.php

Hauser, C. (2009). Oracle WebCenter 11g technical white paper . Retrieved

September 27, 2009, from

http://www.oracle.com/technology/products/webcenter/pdf/owcs_r11_tech

_wp.pdf

Hinchcliffe, D. (2007). A bumper crop of new mashup platforms. Retrieved from

http://blogs.zdnet.com/Hinchcliffe/?p=111

Hinchcliffe, D. (2008). An executive guide to mashups in the enterprise. Retrieved

from http://www.jackbe.com/

Hoyer, V., & Stanoevska-Slabeva, K. (2009). Towards a reference model for

grassroots enterprise mashup environments. 17th European Conference

on Information Systems (ECIS 2009). Retrieved from

http://www.alexandria.unisg.ch/auswerten/Publications/52071/L-en

IBM DAMIA. (n.d.). Retrieved September 20, 2009, from

http://services.alphaworks.ibm.com/graduated/damia.html?lang=en_US

IBM Data Studio. (n.d.). Retrieved October 31, 2009, from http://www-

01.ibm.com/software/data/optim/data-studio/

IBM InfoSphere MashupHub overview. (n.d.). Retrieved September 20, 2009,

from http://www-01.ibm.com/software/data/info20/overview.html 85

IBM Mashup Center. (n.d.). Retrieved June 20, 2009, from http://www-

306.ibm.com/software/info/mashup-center/

IBM Mashup Center wiki. (n.d.). Retrieved September 20, 2009, from http://www-

10.lotus.com/ldd/mashupswiki.nsf iWidget specification v1.0. (n.d.). Retrieved September 20, 2009, from

http://www-10.lotus.com/ldd/mashupswiki.nsf/dx/iwidget-spec-

v1.0.pdf/$file/iwidget-spec-v1.0.pdf

Jhingran, A. (2006). Enterprise information mashups: integrating information,

simply. Proceedings of the 32nd international Conference on Very Large

Data Bases, 3-4.

Kapow Web Data Server. (n.d.). Retrieved September 20, 2009, from

http://kapowtech.com/index.php/products/kapow-web-data-server

Kongdenfha, W., Benatallah, B., Vayssière, J., Saint-Paul, R., & Casati, F.

(2009). Rapid development of spreadsheet-based web mashups.

Proceedings of the 18th international Conference on World Wide Web,

851-860.

Lawton, G. (2008). New Ways to Build Rich Internet Applications. IEEE

Computer, 41 (8), 10-12.

Lizcano, D., Soriano, J., Reyes, M., & Hierro, J. J. (2008). EzWeb/FAST:

reporting on a successful mashup-based solution for developing and

deploying composite applications in the upcoming web of services.

Proceedings of the 10th international Conference on information

integration and Web-Based Applications & Services, 15-24.

Lotus Mashups. (n.d.). Retrieved March 22, 2009 from http://www-

01.ibm.com/software/lotus/products/mashups/

Makki, S. K., & Sangtani, J. (2008). Data mashups & their applications in

enterprises. Third International Conference on Internet and Web

Applications and Services, 445-450.

Markl, V., Altinel, M., Simmen, D., & Singh, A. (2008). Data mashups for

situational applications. First International Workshop on Model-Based

Software and Data Integration 2008, 12-18.

New to SOA and web services. (n.d.). Retrieved May 20, 2009, from

http://www.ibm.com/developerworks/webservices/newto/

Nestler, T. (2008). Towards a mashup-driven end-user programming of SOA-

based applications. Proceedings of the 10th international Conference on

information integration and Web-Based Applications & Services, 551-554.

Network Working Group. (2005). The Atom syndication format. Retrieved June 1,

2009, from http://www.ietf.org/rfc/rfc4287.txt?number=4287

O'Reilly, T. (2005). What is Web 2.0. Retrieved from

http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-

20.html

OpenAjax Alliance. (2009). OpenAjax metadata 1.0 specification. Retrieved June

20, 2009, from

http://www.openajax.org/member/wiki/OpenAjax_Metadata_Specification

Oracle completes acquisition of BEA Systems. (2008). Retrieved September 27,

2009, from http://www.oracle.com/corporate/press/2008_apr/bea-closes-

rls.html

Oracle WebCenter Interaction. (n.d.). Retrieved September 27, 2009, from

http://www.oracle.com/technology/products/webcenter/interaction/index.ht

Pandya, A., Cherbakov, L., & Bravery, A. J. F. (2008). SOA meets situational

applications, Part 3: Examples and lessons learned. Retrieved from

http://www.ibm.com/developerworks/webservices/library/ws-soa-

situational3/

Papazoglou, M. P., & Heuvel, W. (2007). Service oriented architectures:

approaches, technologies and research issues. The VLDB Journal — The

International Journal on Very Large Data Bases, 16 (3), 389-415.

PRESTO: An enterprise-ready mashup solution. (n.d.). Retrieved March 22, 2009

from http://www.jackbe.com/products/

Representational State Transfer. (n.d.). Retrieved June 1, 2009, from Wikipedia:

http://en.wikipedia.org/wiki/Representational_State_Transfer

RSS Advisory Board. (2009). RSS 2.0 specification. Retrieved June 1, 2009, from

http://www.rssboard.org/rss-specification

Service-oriented architecture. (n.d.). In W3C Glossary and Dictionary. Retrieved

June 10, 2009, from http://www.w3.org/2003/glossary/

Shi, X. (2006). Sharing service semantics using SOAP-based and REST web

services. IT Professional, 8 (2), 18-24.

Shirky, C. (2004). Situated software. Retrieved from

http://www.shirky.com/writings/situated_software.html

Simmen, D. E., Altinel, M., Markl, V., Padmanabhan, S., & Singh, A. (2008).

Damia: data mashups for intranet applications. Proceedings of the 2008

ACM SIGMOD international Conference on Management of Data , 1171-

1182.

Singh, H. (2008). IBM Mashup Center and the InfoSphere MashupHub, Part 1:

Get started with InfoSphere MashupHub . Retrieved September 20, 2009,

from http://www.ibm.com/developerworks/data/library/techarticle/dm-

0806singh/index.html

Style Intelligence - business intelligence software. (n.d.). Retrieved September

20, 2009, from http://www.inetsoft.com/products/StyleIntelligence/

The New York Times. (n.d.). RSS. Retrieved July 1, 2009, from

http://www.nytimes.com/services/xml/rss/index.html

The Sheep Market. (n.d.). Programmable Web . Retrieved March 22, 2009 from

http://www.programmableweb.com/mashup/the-sheep-market

The Weather Channel. (n.d.). RSS feeds from The Weather Channel. Retrieved

July 1, 2009, from http://www.weather.com/weather/rss/subscription 89

Tuchinda, R., Szekely, P., & Knoblock, C. A. (2008). Building Mashups by

example. Proceedings of the 13th international Conference on intelligent

User interfaces, 139-148.

W3C Working Group. (2004). Web services architecture. Retrieved June 30,

2009, from http://www.w3.org/TR/ws-arch/

Wang, X., Chen, Y., Sha, J. (2008). The development model of web applications

based on mashups. IEEE International Conference on Service Operations

and Logistics, and Informatics, 2008 , 1059-1062

Warner, J., & Chun, S. A. (2008). A citizen privacy protection model for e-

government mashup services. Proceedings of the 2008 international

Conference on Digital Government Research , 188-196.

Watt, S. (2007). Mashups -- The evolution of the SOA, Part 2: Situational

applications and the mashup ecosystem. Retrieved from

http://www.ibm.com/developerworks/webservices/library/ws-soa-

mashups2/

Web 2.0 Goes to Work for Business. (n.d.). Retrieved May 20, 2009, from

http://www-01.ibm.com/software/info/web20/mashups-rias/index.html

WebSphere Application Server. (n.d.). Retrieved September 20, 2009, from

http://www-01.ibm.com/software/webservers/appserv/was/

WebSphere sMash. (n.d.). Retrieved September 20, 2009, from http://www-

01.ibm.com/software/webservers/smash/

Welcome to EzWeb project (FIT-340503-2007-2). (n.d.). Retrieved June 10,

2009, from http://ezweb.morfeo-project.org/

Widget programming guide, Revision 1.0. (n.d.). Retrieved September 20, 2009,

from

http://download.boulder.ibm.com/ibmdl/pub/software/dw/lotus/mashups/de

veloper/iWidgetProgrammingGuide_20081020.pdf

Woozer. (n.d.). Mashup Awards . Retrieved March 22, 2009 from

http://mashupawards.com/woozor/

Zang, N., & Rosson, M. B. (2008). What's in a mashup? And why? Studying the

perceptions of web-active end users. 2008 IEEE Symposium on Visual

Languages and Human-Centric Computing, 31-38.

Zang, N., Rosson, M., & Nasser, V. (2008). Mashups: who? what? why?. CHI '08

Extended Abstracts on Human Factors in Computing Systems, 3171-3176.