Peer-to-Peer Orchestration of Web Mashups

Introduction

The Web technology is under continuous evolution (Figure 1). In the beginning, every interaction between a user and a web application involves a round of HTTP messages between the web browser and the web server ( in Figure 1). This results in long delays and large amount of network communication. With browser-side scripting (Flanagan, 2011), a considerable amount of interaction can stay at the browser side ( in Figure 1).

Figure 1.

Evolution of the web technology

Meanwhile, an ever-growing large number of web applications provide open services, as data and operations, through published APIs. New web applications, called mashups, provide new web applications or services by combining the functionality and data from open web services (Di Lorenzo et al., 2009; Endrulli et al., 2012; Van Acker et al., 2011; Yu et al., 2008). ProgrammableWeb (www.programmableweb.com), for instance, lists thousands of open services and mashup applications.

Successful adoption of mashups requires both development-time and run-time support (Yu et al., 2008). Development-time support includes the tools for correct service invocation through open APIs and for extraction and conversion of data obtained from the external services. Run-time support, known as orchestration of mashups, is the conduct of the execution of mashups.

Current mashup applications are developed or orchestrated at the servers hosting the mashup application, or even at the browsers (Van Acker et al., 2011). That is, the application servers or web browsers call external services and provide composed services. Programmers have to deal with low-level details like data extraction and conversion, execution order, exception handling, and so on. Furthermore, every single interaction between a mashup application and an open external service involves a round of HTTP messages between the application server hosting the mashup (or the web browser) and the web server of the external service ( in Figure 1). An observation of the popular open services is that many operations return a list of data elements. These data elements are then processed in loops, which often further invoke the same or different open external services. These messages introduce long delays and large amount of network communication. It would therefore be preferable that a significant amount of interactions remain at or near the open external services ( in Figure 1).