Service Mashups Understanding Mashup Development Web mashups are Web applications developed using contents and services available online. Despite rapidly increasing interest in mashups over the past two years, comprehensive development tools and frameworks are lacking, and in most cases mashing up a new application implies a signiicant manual programming effort. This article overviews current tools, frameworks, and trends that aim to facilitate mashup development. The authors use a set of characteristic dimensions to highlight the strengths and weaknesses of some representative approaches. Jin Yu and Boualem Benatallah University of New South Wales Fabio Casati and Florian Daniel University of Trento 44 Published by the IEEE Computer Society eb mashups1 are Web applications generated by combining content, presentation, or application functionality from disparate Web sources. They aim to combine these sources to create useful new applications or services. Content and presentation elements typically come in the form of RSS or Atom feeds, various XML formats, or as HTML, ShockWave Flash (SWF), or other graphical elements. Publicly available APIs (in JavaScript, for example) typically provide application functionality. Content, functionality, and presentation are then glued together in disparate ways: via JavaScript in the browser, server-side scripting languages such as Hypertext Preprocessor (PHP) or Ruby, or traditional languages such as Java or C#. W 1089-7801/08/$25.00 © 2008 IEEE “Mashup” has become one of the hottest buzzwords in the Web applications area, and many companies and institutions are rushing to provide mashup solutions (or to relabel existing integration solutions as mashup tools). Amidst this frenzy, it’s dificult to distinguish between mashups and traditional integration efforts. This article aims to provide some clarity in regard to • what a mashup is (and isn’t); • how mashups resemble or differ from traditional forms of integration, such as application, data, and presentation integration; • what fundamental characteristics and dimensions mashup approaches share; and IEEE INTERNET COMPUTING Understanding Mashup Development • how current tools compare with respect to these characteristics and dimensions. Speciically, we overview some of the popular mashup tools and show how they facilitate the development of rich Internet applications. Our aim isn’t to identify the kinds of available support in terms of mashup development but rather to understand and identify emerging characteristics and dimensions under which we can compare and analyze the tools and approaches. Mashup Development Approaches Mashup development differs from traditional component-based application development mainly in that mashups typically serve a speciic situational (short-lived) need and are composed of the latest, easy-to-use Web technologies (such as Representational State Transfer [RESTful] Web services or RSS/Atom feeds). As such, the Web is their natural environment. The HousingMaps (www.housingmaps.com) application in Figure 1 is an example of a successful mashup. It combines property listings from Craigslist with map data from Google Maps to assist people moving from one city to another and searching for housing. Typically, when people are browsing through a list of properties, a property’s address doesn’t give them enough information if they aren’t yet familiar with the new city. HousingMaps gives users a list of properties and plots the respective locations and property information on the map upon selection (using the popup cloud visible in Figure 1). We could manually develop such a mashup application using conventional Web programming technologies. However, dedicated mashup tools could beneit such development, eventually letting even end users compose their own mashups. Manual Mashup Development Generally, integrating enterprise data and applications into a coherent and value-adding application requires programming skills and intimate knowledge about the schemes and semantics of data sources or the business protocol conventions for message exchange. Fortunately, new technologies, such as Ajax and RESTful services, and microformats, such as RSS and Atom, have simpliied mashup development. In addition, intelligent source components largely SEPTEMBER/OCTOBER 2008 Figure 1. The HousingMaps application. HousingMaps integrates Craigslist housing offers with Google Maps into a homogeneous user interface. assist the integration of contents, application logic, and user interfaces. Nevertheless, manual mashup development is still a prerogative of skilled developers. Assuming you have no speciic development tools, what’s involved in manually developing an application like HousingMaps? First, you must become familiar with the two source applications (Craigslist and Google Maps) and identify how you will reuse or extract data from the two sites. Whereas Google Maps offers a publicly available JavaScript API that you can leverage, Craigslist provides its listings via RSS. Therefore, to extract property and address data, you must parse and interpret the RSS feed from Craigslist. To conigure the clickable markers that will display the property information in a popup cloud window upon a click, you must interact with the Google Maps JavaScript API. Enabling the automatic popup of this cloud requires a speciic JavaScript function that listens for the property selection and reacts by invoking the Google Maps API to select the respective marker. Although Google Maps has its own user interface, letting users select properties wrapped from Craigslist requires that you ill and appropriately format a suitable table. Finally, you must lay out the two components properly to form the composite application’s user interface. Such intricate and time-consuming tasks prevent average users from programming their own mashups. 45 Service Mashups Tool-Assisted Mashup Development To speed the overall mashup development process, but also to enable even inexperienced end users to mash up their own Web applications, numerous mashup-speciic development tools and frameworks have recently emerged. These instruments typically come with a variety of features and a mixture of composition approaches. A close look at them lets us identify the open issues and research challenges characterizing the mashup phenomenon. For presentation purposes, we selected the most popular or representative approaches of end-user mashup tools and show how they can support the HousingMaps application’s development. We discuss a few alternative or complimentary approaches in the “Related Work in Reusable Components” sidebar. Yahoo Pipes. Yahoo Pipes (http://pipes.yahoo. com) lets you mix popular data feeds to create data mashups via a visual editor. A pipe is a dataprocessing pipeline consisting of one or more data sources (for example, RSS/Atom feeds or XML sources) and a set of interconnecting operators, each of which performs a speciic task. It includes operators for manipulating data feeds (for example, sorting or iltering) and operators for features such as looping, regular expressions, or counting. It also supports more advanced features, such as location extraction (for example, geocoordinates identiied and converted from location information found in text fragments) or term extraction (for example, keywords). Yahoo Pipes aims to let users design data-processing pipelines that ilter, transform, enrich, and combine data feeds and are again exposed as RSS feeds. Consider how Yahoo Pipes could aid the development of the HousingMaps example. Because Pipes doesn’t provide user interfaces — that is, it outputs an RSS feed — we can’t implement the user interface shown in Figure 1. Instead, we could use Pipes to process the Craigslist feed and identify location information (geocodes) by leveraging the pipes’ location extractor. We could use the identiied location information to augment the Craigslist feed with a link that lets users display the property’s address on the map by passing the geocodes to Google Maps. Google Mashup Editor. GME (http://editor.google mashups.com) provides a template-based envi46 www.computer.org/internet/ ronment for mashup development. It offers a set of standard modules that lets users encapsulate and lay out external data. For example, the list module represents an RSS/Atom feed as a list, whereas the item module represents a single item in a feed. Modules can ire predeined events, which other modules can capture and act on accordingly. Creating mashups involves developing user interface templates that contain a mixture of XML control tags and HTML/CSS layout elements with embedded JavaScript code. At runtime, GME ills the user interface templates and presents them as Web pages. For the HousingMaps application, we could integrate the Craigslist feed using a list module and use the item module to show a particular property’s details. GME’s map module natively supports Google Maps. When the user clicks on a property in the Craigslist module, the module emits a “select” event, which the map module can capture to pop up the cloud window on top of the marker and display information about the selected property. We must embed the Craigslist module and Google Maps into the user interface template that speciies the actual mashup application’s layout. Microsoft Poply. Poply (www.poply.ms) offers a component-based, visual environment for developing mashups. In Poply, reusable components, or blocks, can act as middlemen between externally provisioned services, such as Web services,2 or implement a useful function (in JavaScript) — for example, a function that calculates a circle’s area given a radius. Blocks have operations with inputs and outputs, which are speciied in a dedicated XML descriptor. A block might also act as a display surface — that is, a piece of user interface that takes data from other blocks and displays them, letting the user interact with them and enabling the mashup developer to lay out the mashup application. To build the HousingMaps application, we need three blocks: • an RSS feed block for the Craigslist feed, • a map block, and • a table block. If we use Virtual Earth (http://microsoft.com/ virtualearth) instead of Google Maps, the three blocks are already available. We must therefore IEEE INTERNET COMPUTING Understanding Mashup Development drag the blocks onto the mashup design surface and then connect the output of the RSS block’s getItems operation to the two display blocks for the RSS and Virtual Earth. Correctly coniguring the initial set of markers might require extending the RSS block with a suitable JavaScript operation. Intel Mash Maker. Mash Maker (http://mash maker.intel.com) provides an environment for integrating data from annotated source Web pages based on a powerful, dedicated browser plug-in. Rather than taking input from structured data sources such as RSS or Atom, Mash Maker lets users annotate Web pages’ structure while browsing and use such annotations to scrap contents from annotated pages. Advanced users can leverage the integrated structure editor to input XPath expressions using FireBug’s DOM Inspector (a plug-in for the Firefox Web browser). Composing mashups with Mash Maker occurs via a copy-and-paste paradigm, based on two modes of merging contents: • whole page merging, in which the user inserts one page’s content as a header into another page; and • item-wise merging, in which the user combines contents from two pages at row level, based on additional user annotations. You can use the two techniques to merge more than two pages. For the HousingMaps example, we irst annotate the appropriate Craigslist page’s structure because Mash Maker operates on regular HTML content rather than on RSS. Next, we merge the Craigslist page with the Google Maps page using the copy-and-paste mechanism. Speciically, we adopt item-wise merging because we plot each item from the Craigslist page as an individual marker on the map. Quick and Easily Done Wiki. QedWiki (http:// services.alphaworks.ibm.com/qedwiki) is IBM’s proposal for a wiki-based “mashup maker,” fully running inside the client browser and allowing access to IBM’s Mashup Hub (http:// services.alphaworks.ibm.com/mashuphub). The Hub supports the creation of data feeds and user interface widgets and incorporates Data Mashup Fabric for Intranet Applications (Damia)3 for data assembly and manipulation. As SEPTEMBER/OCTOBER 2008 a wiki environment, it lets users edit, immediately view, and easily share mashups. Mashups are assembled from JavaScript- or PHP-based widgets, whose wiring determines the mashup’s behavior. Widgets represent application components and might or might not have their own user interface. To assemble a mashup, a user selects a page layout (an HTML template) and then drags and drops widgets onto the page grid and interactively conigures them. To develop the HousingMaps application with QedWiki, we irst create a new wiki page and select a grid layout. In our case, we opt for a layout that lets us place Google Maps and the housing offers side by side (in two columns). We then search for the GoogleMap widget in the widget palette, drag it over the grid layout, and drop it over the left column. We use the LoadFeed widget to access the Craigslist RSS feed and populate a ShowData widget with the housing offers (by telling the ShowData widget that it should source data from the LoadFeed widget). To locate properties on the map, we can now simply drag addresses from the ShowData widget at runtime and drop them onto the GoogleMap widget. Characterizing Mashup Approaches As you’ll have noticed, the tools we’ve described differ in two complementary aspects: • the mashup paradigm at the basis of the approach and • the software instrument that implements the chosen paradigm. Much like in data and application integration, we characterize the mashup paradigm by looking at the objects of integration (the components) and how such objects are glued together (the composition logic). As for the software instrument, it’s important to separately look at the design-time support (the development environment) and the runtime support (the runtime environment) provided. Component Model The component model determines the nature of components and inluences how they can be glued together — that is, how they can be composed. A well-deined component interface, for instance, facilitates reusability, whereas a lexible component interface ensures extensibil47 Service Mashups ity. We characterize a component model using three properties. The irst property is type. A component can be a data (DA), application logic (AL), or user interface (UI) type, depending on whether it acts as a pure data source, a component providing access to application logic, or a component that also provides a GUI to users. Second, we look at the model’s interface. A component might expose a create-readupdate-delete (CRUD) interface, APIs in speciic programming languages or in IDL/WSDL, XML/ HTML markup, or it might only expose GUI elements to the end users. A component might also expose a combination of these elements. Finally, the extensibility property explains whether the user can create new components or extend the component model to accommodate speciic application requirements, such as new operations. Yahoo Pipes supports DA and AL components through operators that provide access to RSS/Atom feeds and external Web services. DA components have a read-only interface, and external Web services have a RESTful interface based on JavaScript Object Notation (JSON) or RSS. Yahoo Pipes component models are ixed. GME supports DA, AL, and UI components. DA components are typically interfaced via markup, AL components via JavaScript, and UI components via both markup and JavaScript. GME component models are lexible. Poply also supports DA, AL, and UI components. In Poply, all components are interfaced using JavaScript, and component models are extensible. Intel Mash Maker supports DA components extracted from annotated Web pages (for example, table and map). Their interface can be interpreted as XML markup, and the component models are ixed. QedWiki focuses mainly on UI components (the Mashup Hub supports DA and AL components). Components are equipped with a JavaScript interface and can be extended. In traditional integration, extensible application-level components with application-speciic APIs would characterize Web services. Data integration4 applications are instead characterized by data-driven components that are often ixed or have limited extensibility. For example, extract, transform, load (ETL) applications have a large set of built-in modules that perform join 48 www.computer.org/internet/ or lookup operations on relational database or XML documents. Custom behavior is typically supported through a generic SQL component. Composition Model The composition model determines how components are integrated to form the mashup, assuming components are readily available. To facilitate end-user compositions, the composition model should be as simple as possible. A composition model has several distinct characteristics. First, we distinguish the model’s output type. As with components in input, composition output can be of type DA, AL, or UI, depending on whether the composition provides data, programmable APIs, or applications with a user interface. The second characteristic is orchestration style. Orchestrating components implies specifying how you’ll deine and synchronize the components’ execution. Three main approaches exist: • Flow-based styles deine orchestration as sequencing or partial order among tasks or components and are expressed through low chart-like formalisms. • Event-based approaches use publish– subscribe models. They’re particularly powerful for maintaining synchronized behavior among components. • In the layout-based style, components (with or without user interfaces) are arranged in the composite application’s common layout. Each component’s behavior is speciied individually by accounting for the other components’ reactions to user interactions. Third, we look at the model’s data-passing style. We deine two data-passing approaches: • a datalow approach, in which data lows from component to component; and • a blackboard approach, in which data is written to variables, which serve as the source and target of operation invocation on components, much like in programming languages. In addition, a composition can be instancebased or continuous. An instance-based model is the traditional service composition model, in which a certain kind of message’s arrival activates a new instance of the composition, and the system executes the instance within the IEEE INTERNET COMPUTING Understanding Mashup Development same main thread and context (much like a program run). Conceptually, the continuous model has one instance per component in the composition model. Each component works as a thread, processing the input data feed and transforming or iltering it to generate the output. Another property relates to exceptions and transactions. A composition model might or might not support exception and transaction handling. If supported, exception handling can follow the throw-and-catch approach (Java style) or can be rule based (using event-condition-action [ECA] rules coupled to the composition). Transactions, if supported, always follow some variation of the Saga model.5 Yahoo Pipes is probably the best representative of DA output (pipes are RSS feeds). Its graphical modeling language is low-based; accordingly, data is also passed via data lows. Pipes is instance-based; it doesn’t provide exception handling or support transactions. GME produces UI output. GME is eventbased and achieves data passing through event parameters in a datalow fashion. In addition, UI components are continuous. Finally, GME doesn’t support exceptions and transactions. Poply produces UI output. It uses an eventbased orchestration style and a datalow approach for data passing. Components are continuous. Like GME, Poply doesn’t support exceptions and transactions. Intel Mash Maker focuses on UI output. In Mash Maker, contents are glued together in a layout-based style (whole page merging) or in a low-like style (item-wise merging). It uses data extracted from annotated Web pages in a blackboard style. Mash Maker’s instance model is most similar to the instance-based one, and it doesn’t support exceptions and transactions. Like GME, Poply, and Mash Maker, QedWiki produces UI output. It proposes a layout-based orchestration style and components pass data in a blackboard fashion. Widgets are continuous. QedWiki doesn’t support exceptions or transactions. Traditional integration is typically lowbased (think of the Business Process Execution Language [BPEL] and most ETL processes), with an XML-based data model following a blackboard approach for service-oriented architectures (SOA) and a relational data model with data low for ETL. Both use an instance-based instantiation model. However, in SOA, an inSEPTEMBER/OCTOBER 2008 stance is created with the arrival of a certain message (such as a purchase order), whereas in ETL, an instance is created periodically (for each data extraction). Traditional integration produces DA or AL output, whereas mashups typically include some form of integration at the UI level. In terms of exception and transaction, traditional integration offers Java-like exception handling and Saga-like transaction support, with predeined but extensible exception types (for example, SOAP faults in BPEL or DB errors in ETL). Development Environment The characteristics of the mashup tools’ development environments affect mashup development eficiency and determine the tools’ success. Mashup tools vary greatly in the level of support Mashups are about simplicity, usability, and ease of access. This simplicity has the upper hand over feature completeness or full extensibility. they provide to their users. Some tools are strictly for developers, whereas others are more oriented toward end users. Several properties characterize mashup development environments. The irst property is the environment’s interface paradigm and target users. Mashup tools can support design via different interface/ modeling paradigms, such as visual drag-anddrop features, textual editors, or a combination of the two. The interface can target average Web users, advanced (tech-savvy) users, or programmers. The interface’s ease of use is the key factor in bringing mashup capability to average and advanced Internet users. A development environment is also characterized by system requirements. The mashup tool’s execution might require speciic additional modules, plug-ins, or browser features, whose absence might prevent the instrument’s use. Yahoo Pipes provides a pure visual dragand-drop Ajax editor targeted at users with basic programming skills. The editor is executed in a standard Web browser with support for the XMLHttpRequest JavaScript object. 49 Service Mashups GME’s browser-based textual Ajax editor with syntax highlighting and automatic tag completion is targeted at programmers. It can be fully executed in a standard Web browser. Microsoft Poply offers a graphical and textual editor with drag-and-drop support for Web users. Poply is based on Microsoft’s Silverlight (www.microsoft.com/silverlight) technology, a mandatory browser plug-in. Similarly, Intel Mash Maker supports a pointand-click user interface that lets advanced users and programmers annotate pages and nonexpert Web users extract and merge data via copy-andpaste. Mash Maker requires a dedicated plug-in that extends the browser with mashup features. QedWiki comes with an easy-to-use dragand-drop interface for advanced users. In this interface, components are immediately visualized. QedWiki runs in a standard Web browser and doesn’t require any plug-ins. Unlike these mashup tools, traditional integration technologies typically offer desktop development applications rather than browser-based ones. In addition, they require a steeper learning curve because they’re more sophisticated and feature-rich. Traditional approaches, which always target programmers, offer neither end-user data integration nor application integration. Runtime Environment Typically, each mashup tool also provides a separate runtime environment that enables the execution of the tool’s mashups and determines how it will deliver the mashups to its users. Possible system requirements imposed by the runtime environment might affect the adoption of mashups developed with the respective tools. We distinguish four properties in the runtime environment. The irst property is the deployment style. As with conventional Web applications, you can deploy a mashup application in a standalone fashion on any Web server managed by the mashup developer, or through a third-party Web server (typically belonging to the mashup development environment provider). Another property is the runtime location. You can assemble mashups at the server side (for example, via PHP or Ruby), the client side (for example, inside a Web browser via JavaScript), or both. If the integration occurs at the server side, the browser merely displays the resulting composite application. Server-side approaches 50 www.computer.org/internet/ can use an engine-based or Webapp-based implementation style. The engine-based approach implies that a mechanism analogous to a process engine executes the mashup (for example, collects and processes the feeds). In the Webappbased approach, the mashup is implemented as a Web application, so the Web and application servers execute the mashup. The third property of a runtime environment is system requirements. Similar to the development environments, a mashup’s execution can depend on the availability of additional browser plug-ins or extensions. Finally, we look at the environment’s scalability. We can consider scalability from three perspectives: • the number of data sources, • the number of models (compositions), or • the number of users. In general, client-side approaches don’t suffer from scalability problems. The mashup is executed on the client, so no bottleneck exists (except from the overload on the data sources themselves, but this is outside the mashup’s control). Here, the scalability problems relate to the number of instances and, hence, the number of users and the mashup’s complexity (which is related to the number of sources and the related data processing). In all cases, client-side approaches use the same scalability techniques as do traditional integration or Web applications, relying on worklow scalability techniques for engine-based runtimes and on Web application scalability for Web-application-based runtimes. Yahoo Pipes compositions are hosted on a Yahoo server. The system computes and assembles pipes at the server side (apparently enginebased), so executing a pipe doesn’t pose any particular system requirements on the client. However, the server-side engine that executes the pipes might suffer if many pipes are run, if numerous users access the same pipe, or if the pipe consists of hundreds of sources. GME mashups are hosted on a Google server. Mashups are executed at the server side and have no particular system requirements. The system compiles mashups into conventional Web applications. Poply mashups are hosted on a Microsoft server. Execution of a Poply application, however, occurs at the client side and typically reIEEE INTERNET COMPUTING Understanding Mashup Development Related Work in Reusable Components T he tools we describe in the main text effectively let end users easily compose data and application logic starting from reusable components. E. Michael Maximilien and his colleagues propose a programming language that’s speciic to mashups of Web services (for example, Representational State Transfer [REST], SOAP, RSS, or Atom services);1 however, the language is more oriented toward developers. Nonetheless, the approach is in line with the “approachable programming model” that characterizes mashups in general. 2 Portals focus on the integration of components with their own user interface (portlets3). They represent an afirmed solution in the development of large-scale Web applications but generally offer weak support for intercomponent communication and end-user-oriented development.4 Integrating portlets sourced from the Web is still hard, but work is ongoing. 5 Tools such as Dapper (www.dapper.net) and Openkapow (http://openkapow.com), instead, are popular for developing components. They provide powerful support for data or user interface extraction (wrapping) from existing Web sources. The OpenAjax Alliance (www.openajax.org) aims to develop quires the availability of the Silverlight plug-in. The client-side execution facilitates scalability because the integration of multiple sources occurs mostly at the client side. Intel Mash Maker mashups are stored on the client PC and are executed inside the Web browser using the Mash Maker plug-in. Although it seems unlikely that large numbers of sources will be mashed up, Mash Maker should be able to scale adequately. QedWiki pages are hosted on an IBM server. Mashups are executed mostly on the client side, and a standard Web browser can execute QedWiki pages. The wiki engine might encounter dificulties if it must integrate numerous sources. SOA or ETL deployments typically have a centralized engine server that runs the process deinition by invoking services or data storages. Distributing the workload over multiple engines guarantees scalability. Going Forward Many of the differences between mashups and traditional forms of integration descend from the basic observation that mashups focus mainly on opportunistic integration occurring on the Web for an end user’s personal use and for nonbusiness-critical applications. Traditional composition (for example, BPEL-like), on the other hand, focuses on systematic and repeatable enSEPTEMBER/OCTOBER 2008 a standardized client-side hub for a publish–subscribe-based event communication among Ajax components, which are increasingly becoming the natural environment for mashup components. Component development, however, is out of this article’s scope. References 1. E.M. Maximilien et al., “A Domain-Speciic Language for Web APIs and Services Mashups,” Service-Oriented Computing (ICSOC 07), LNCS 4749, Springer, 2007, pp. 13–26. 2. S. Watt, “Mashups — The Evolution of the SOA, Part 2: Situational Applications and the Mashup Ecosystem,” IBM DeveloperWorks, 2007; www.ibm. com/developerworks/webservices/library/ws-soa-mashups2. 3. A. Abdelnur and S. Hepper, Java Portlet Speciication, 2003; http://jcp.org/en/ jsr/detail?id=168. 4. F. Daniel et al., “Understanding User Interface Integration: A Survey of Problems, Technologies, and Opportunities,” IEEE Internet Computing, vol. 11, no. 3, 2007, pp. 59–66. 5. OASIS Web Services for Remote Portlets (WSRP) technical committee, www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrp. terprise processes. Enterprise processes also have a wide set of nonfunctional requirements, such as security and reliability, that few mashups share and that make languages, tools, and the overall development fairly complex. Also, unlike conventional Web applications, many of today’s mashups still have a limited audience (such as individuals or small user groups) so scalability isn’t a big issue. This might become a problem if and when a “killer mashup” appears. In general, mashups are about simplicity, usability, and ease of access. This simplicity has the upper hand over feature completeness or full extensibility (as in SOA or BPEL). With improved tool support (such as a better user interface) and the abundance of components or modules, end users will be able to compose their own mashups. In this context, we also see a need for end-user-oriented integration paradigms for allowing easy and simple exploration, organization, search, and integration of mashups. This will help move mashup development from manual and time-consuming scripting to a set of easy-to-ind and extensible parameterized patterns that characterize most of the heterogeneities among mashup services. Mashup component search is also likely to improve over time, not only because of Google-like search mechanisms but also because of an emerging trend toward online communities of mashup 51 Service Mashups taggers and bloggers, following the style of the social Web. Therefore, mashups can learn useful lessons from traditional integration. Speciically, to simplify mashup development, we need a user interface component model, so mashup developers can abstract and reuse a user interface as in traditional services. A user interface component model will likely have aspects similar to traditional components in addition to user interfacespeciic items. It should also be fundamentally simpler, consistent with the Web’s philosophy. In addition, we need middleware for user interface integration. Today’s middleware is essentially the Web, which offers no mashup-speciic support. Perhaps the Web is suficient, but middleware paradigms, such as publish–subscribe, which have been extremely successful in EAI, are also well-suited to mashups. This suitability is due to the nature of mashups, which are strongly event-based (they’re essentially reactive applications sensitive to events from sources such as news feed content or user interactions). Finally, we must bridge user interface integration with traditional forms of integration. Mashups are evolving toward components that are a mix of user interface aspects and traditional application logic. The challenge here is identifying component and composition models that can cater to the needs of both kinds of integration. One is more event-driven and useroriented, the other is more orchestrational and enterprise-oriented. Without these elements, mashup development will largely be an ad hoc effort requiring programming skills that typical Web users don’t possess, or it will be restricted to speciic technologies or domains. e’ve begun to investigate these issues in a framework called Mixup.6,7 However, we’ve just scratched the surface of these research problems. Mixup is an instance of a trend that brings together the different forms of integration (user interface, application, and data) while ensuring ease of development and maintenance with minimum learning curves. W References 1. D. Merrill, “Mashups: The New Breed of Web Application,” IBM DeveloperWorks, 2006, www-128. ibm.com/developerworks/librar y/x-mashups.html?ca 52 www.computer.org/internet/ =dgr-lnxw16MashupChallenges. 2. G. Alonso et al., Web Services: Concepts, Architectures, and Applications, Springer, 2004. 3. M. Altinel et al., “Damia: A Data Mashup Fabric for Intranet Applications,” Proc. Very Large Databases Conf. (VLDB 07), VLDB Endowment, 2007, pp. 1370–1373. 4. M. Lenzerini, “Data Integration: A Theoretical Perspective,” Proc. Symp. Principles of Database Systems (PODS 02), ACM Press, 2002, pp. 233–246. 5. H. Garcia-Molina and K. Salem, “Sagas,” Proc. ACM Special Interest Group on Management of Data 1987 Ann. Conf. (SIGMOD 87), ACM Press, 1987, pp. 249–259. 6. J. Yu et al., “A Framework for Rapid Integration of Presentation Components,” Proc. Int’l World Wide Web Conf. (WWW 07), ACM Press, 2007, pp. 923–932. 7. J. Yu et al., “Mixup: A Development and Runtime Environment for Integration at the Presentation Layer,” Proc. Web Eng. (ICWE 07), LNCS 4607, Springer, 2007, pp. 479–484. Jin Yu is a PhD candidate at the School of Computer Science and Engineering, University of New South Wales, Sydney. He also serves as the VP of Engineering at Martsoft Corporation. His research focuses on rich Internet applications and user interface integration. He is a member of the IEEE and the ACM. Contact him at jyu@cse.unsw.edu.au. Boualem Benatallah is a professor in the School of Computer Science and Engineering at the University of New South Wales, Sydney. His research interests lie in the areas of Web services, business processes, and data integration. Benatallah has a PhD in computer science from Grenoble University, France. He is member of the IEEE and the ACM. Contact him at boualem@cse.unsw.edu.au. Fabio Casati is a professor of computer science at the University of Trento. He has a PhD in computer science from Politecnico di Milano, Italy. Casati is coauthor of a book on Web services, a member of the editorial board of ACM Transactions on the Web, and a member of the steering committee of the international conferences on service-oriented computing and business process management. Contact him at casati@dit.unitn.it. Florian Daniel is a postdoctoral researcher at the University of Trento. His research interests include Web engineering, mashups, and business intelligence applications. He has a PhD in information technology from Politecnico di Milano. He is a member of the organizing committee of the Adaptation and Evolution in Web Systems Engineering Workshop and the WebML research group. Contact him at daniel@disi.unitn.it. IEEE INTERNET COMPUTING