Model-Driven Mashup Personal Learning Environments ... - CiteSeerX

Int. J. Technology Enhanced Learning, Vol. 3, No. 1, 2011

Model-Driven Mashup Personal Learning Environments 1 Mohamed Amine Chatti* and Matthias Jarke Informatik 5 (Information Systems) RWTH Aachen University Ahornstr. 55, 52056 Aachen, Germany E-mail: [email protected] E-mail: [email protected] *Corresponding author

Marcus Specht CELSTEC Open University of the Netherlands PO Box 2960 6401 DL Heerlen, The Netherlands E-mail: [email protected]

Ulrik Schroeder Informatik 9 (Computer-Supported Learning) RWTH Aachen University Ahornstr. 55, 52056 Aachen, Germany E-mail: [email protected]

Daniel Dahl Bayer Business Services GmbH Schanzenstraße 41, 51063 Cologne, Germany E-mail: [email protected]

Abstract: Mashups have become the driving force behind the development of Personal Learning Environments (PLE). Creating mashups in an ad hoc manner is, however, for end users with little or no programming background not an easy task. Various tools and platforms have been built in an attempt to

support mashup creation. These platforms, however, are still considered complex and do not address crucial challenges in mashup development today, such as scalability, interoperability, reuse, and automatic service invocation and mediation. In this paper, we leverage the possibility to use the concept of Model-Driven Mashup Development (MDMD) as an approach that can drastically tackle the aforementioned issues and drive the rapid and userfriendly creation of mashups. We then present the conceptual and technical details of PLEF-Ext as a flexible framework for end-user, model-driven development of mashup PLEs.

Copyright © 2011 Inderscience Enterprises Ltd.

1

M.A. Chatti et al. Keywords: Personal Engineering.

Learning

Environment;

Mashups;

Model-Driven

Reference to this paper should be made as follows: Chatti, M. A., Jarke, M., Specht, M., Schroeder, U. and Dahl, D. (2011) ‘Model-Driven Mashup Personal Learning Environments‘, Int. J. Technology Enhanced Learning. Biographical notes: Mohamed Amine Chatti has a diploma degree in Computer Science from the Technical University of Kaiserslautern, Germany. He is currently working as a research assistant and PhD student at the Chair of Computer Science 5 - Information Systems, RWTH Aachen University, Germany. His research interests include Web information systems, technology enhanced learning, professional learning, knowledge management, personal learning environments, and knowledge ecologies. Matthias Jarke is professor of Information Systems at RWTH Aachen University and Director of the Fraunhofer FIT Institute of Applied IT in Sankt Augustin, Germany. In his research, he investigates IS support for knowledgeintensive cooperative processes in business, engineering, and culture. As president of the German computer society (GI), he was responsible for the definition of Germany's IT accreditation guidelines. Both his university group and Fraunhofer FIT have been involved in numerous eLearning activities, ranging from the high school level to entrepreneurship training. Jarke serves on a number of national and international advisory boards. Marcus Specht is Professor for Advanced Learning Technologies at the Open University of the Netherlands and is currently involved in several national and international research projects on competence based life long learning, personalized information support and contextualized learning. From 2005 he was Associated Professor at the Open University of the Netherlands and working on competence-based education, learning content engineering and management, and personalization for learning. Currently he is working on Mobile and Contextualized Learning Technologies, Learning Network Services, and Social and Immersive Media for Learning. Ulrik Schroeder is professor of Computer Science at RWTH Aachen University. He heads the research group Computer-supported Learning and Didactics in Computer Science (http://eLearn.rwth-aachen.de/) as well as the CiL (Center for integrative teaching and learning Of RWTH Aachen University: http://www.cil.rwth-aachen.de/). His research interests include assessment and intelligent feedback with a focus on learning processes, Web 2.0 applications and social software in education, mobile Internet and learning, gender mainstreaming in education, and Computer Science didactics. Daniel Dahl holds a Diploma in Computer Science and a Master of Science in Media Informatics, both from the University of Applied Sciences, Cologne. In 2008 he received his PhD in Computer Science at the University of Muenster for his research on Web 2.0 and its implications on technology enhanced learning. Following he joined Bayer where he is leading international projects in the area of workplace collaboration and Web 2.0.

Model-Driven Mashup Personal Learning Environments

1

Introduction

Recently, the mashup concept has emerged as a core technology of the Web 2.0 and social software movement. A mashup indicates a way to create new (Web) applications by combining existing data and services from several sources. In the past few years, Web mashups have become a popular approach towards creating a new generation of customizable Web applications. The popularity of Web mashups has mainly been driven by the increasing popularity of lightweight RESTful Web services, AJAX, and JSON that build core technologies in the Web 2.0 movement. Besides receiving more and more attention for example, in enterprise context, mashup development has also become a very popular research topic in TEL. Many TEL researchers recognized the value of mashups and have already adopted the mashup concept for Personal Learning Environment (PLE) development. The idea behind mashup PLEs is to let learners create their very own learning mashups that leverage components and content generated by learning service providers and other learners around the Web. Yet, most of the proposed mashup PLE approaches are based on widgets. In this paper, we go a step further toward supporting the mashup of RESTful services and the use of a model-driven mashup development (MDMD) approach to deal with scalability, interoperability, reuse, and automatic service invocation and mediation within mashup PLEs. We propose a mashup PLE framework, called PLEF-Ext, that enables a userfriendly creation, management, sharing, and reuse of learning mashups, following a MDMD methodology. The remainder of this paper is organised as follows: Section 2 explores the mashup concept, looks at the different components of a mashup, provides an overview of some popular and representative mashup development tools and frameworks, and summarizes the main problems in mashup development today. Section 3 proposes model-driven mashup development (MDMD) as an alternative approach for mashup creation. In Section 4, we discuss how mashups can provide a powerful tool to build PLEs. We follow in Section 5 with the conceptual and technical details of PLEF-Ext as a mashup PLE framework that can help learners share, find, integrate, reuse, and easily remix learning services based on the MDMD approach. And finally, we summarize our findings in Section 6.

2

Web Mashups

With the rapid growth of the tools of production on the Web, there is a tremendous amount of information that is distributed across different platforms. Thus, how to combine the information to meet the end-users'

M.A. Chatti et al.

need becomes a highly challenging task. The rise of Web mashups provides a promising solution for this challenge, following a small pieces, loosely joined approach. A Web mashup is defined in Wikipedia as a “Web page or application that combines data or functionality from two or more external sources to create a new service”. The Internet and its related technologies have created an interconnected world in which we can easily exchange and reuse information in unforeseen, unexpected ways. Web services are emerging as a major technology for deploying automated interactions between distributed and heterogeneous applications (Benslimane, Dustdar, and Sheth, 2008). In the Web 2.0, services based on the representational state transfer (REST) paradigm (Fielding, 2000) are increasingly popular for Web development. RESTful services often take the form of RSS/Atom feeds and AJAX based lightweight services, which explains their greater success compared to heavyweight services, which are based on the Web Services Description Language (WSDL) and SOAP. The output formats of RESTful services, often in the form of Extensible Markup Language (XML) or the more lightweight form JavaScript Object Notation (JSON), make RESTful services ideal for AJAX-based mashups.

2.1 Mashup Types We can differentiate between two types of mashups: Mashups by Aggregation and Mashups by Integration (Chatti, Jarke, and Specht, 2009).  Mashups by Aggregation simply assemble sets of information from different sources side by side within a single interface. Mashups by aggregation do not require advanced programming skills and are often a matter of cutting and pasting from one site to another. Personalized start pages, which are individualized assemblages of feeds and widgets, fall into this category.  Mashups by Integration create more complex applications that integrate different application programming interfaces (APIs) in order to combine data from different sources. Unlike mashups by aggregation, the development of mashups by integration needs considerable programming expertise (cf. Section 2.4 Mashup Development).

2.2 Mashup Styles The two primary mashup styles are server-side mashups and client-side mashups, depending on where the mashup logic is executed (Ort, Brydon,


and Basler, 2007a;2007b). Figure 1 illustrates the difference between server-side and clien-side mashups.  Server-side mashups integrate services and content on the server. A server-side mashup is also called a proxy-style mashup because a component in the server acts as a proxy to the mashup service. In a server-side mashup, all the requests from the client go to the proxy server, which then makes calls to the remote mashup service, receives the response, may transform it to an appropriate data format for the client or cache the response for future request processing, and finally returns the response to the client.  Client-side mashups, by contrast, integrate services and content directly on the client, which is typically a Web browser. In a clientside mashup, the client might make requests directly to the remote mashup service, without the need to go through a proxy server. The remote mashup service processes the request and returns data in the requested format. The response data is then loaded within a dynamic script tag on the client side. Client-side mashups offer several advantages compared to the server-side mashup style (Ort, Brydon, and Basler, 2007b): a. They are easier to implement. b. There is no need to provide a server side component. c. Can yield a better performance than server-side mashups since a service request and response are passed directly between the browser and the mashup server, so receiving a response typically takes less time. d. Can reduce processing load on the server because a service request and response is not passed through a server-side proxy. Figure 1

Server-side vs. Client-side Mashups

M.A. Chatti et al.

2.3 Mashup Levels According to Maximilien et al. (2007), the three major levels of a Mashup application are data level, process level, and presentation level.  Data level: mainly concerns data mediation and integration, and involves converting, transforming, and combining data from one or multiple services to meet the needs of the operations of another.  Process level: at this level the process mediation between the involved services is defined. This includes, for instance, invoking the various service methods, waiting for asynchronous messages, and sending any necessary confirmation messages.  Presentation level: used to elicit user information as well as to display intermittent and final process information to the user.

2.4 Mashup Development In the next sections, we discuss the current status of mashup development with a focus on ‘Mashups by Integration’. Developing mashups by integration is not an easy task. In general, mashup development is still very much an ad hoc activity. Mashups are often generated manually using normal Web development technologies such as HTML, CSS and JavaScript (Taivalsaari and Mikkonen, 2008). Creating a mashup in a manual manner is a very time consuming task and impossible for the typical Web user (Lathem, Gomadam, and Sheth, 2007). A key difficulty in creating mashups is data mediation between the


services to be mashed up. Typically, in order to create a mashup, the user would need to understand not only how to write code but also the APIs and descriptions of data formats of all the services that need to be included in the mashup (Sheth, Gomadam, and Lathem, 2007). To lower the barrier of creating a Web mashup, leading companies are now actively developing different mashup building tools and platforms, that require little to no programming knowledge from the user. Yahoo! Pipes2, Microsofts Popfly3 and Google Mashup Editor4 are some wellknown examples of mashup platforms that users have largely adopted. In general, these platforms provide a higher level of abstraction and use visual programming techniques to facilitate the creation of mashups. For instance, Yahoo! Pipes provides a visual editor to wire different graphical elements to each other, based on different kinds of data processing operations such as regular expressions, filters, sorting or looping instructions. Similarly, Microsoft Popfly provides a Web-based GUI, where the user can connect different Web services to each other by dragging the blocks representing them into the main display and drawing wires to connect those services. Google Mashup Editor (GME) provides a higher level JavaScript API for manipulating data programmatically. A detailed description and comparison of these and other mashup development tools is provided in (Di Lorenzo, Hacid, and Paik, 2009) and (Taivalsaari, 2009). Google Mashup Editor has not been designed to be used by end users without background in programming. It is more suitable for amateur and professional mashup programmers. And, other mashup editors, such as Yahoo! Pipes and Microsoft Popfly, that already try to be more intended for non-professional mashup developers suffer from two main limitations. First, most of the mashup tools are restricted to services that have standard types of outputs, such as RSS or ATOM. These mashup tools are particularly capable at processing and creating new feeds. A common feature is (1) pull data from external RSS and Atom feeds, (2) filter, sort, and combine many feeds into one, (3) grab the output as RSS, JSON, KML, and other formats, and (4) include the result as a widget in other Web sites. Second, the usage scope of these mashups tools is often limited to services that are internal to the company where the mashup tool was developed (Yahoo! Pipes, for example, adds Yahoo! Maps to any pipe containing GeoData). And, in most cases these mashup tools are restricted to a set of few of popular services such as Flickr, Digg, or popular map, traffic or weather services. As a consequence, a plethora of existing (RESTful) services cannot be used by these mashup tools. If one of the companies behind the aforementioned mashup tools, for some reason, would be willing to add a

M.A. Chatti et al.

new external service to their supported service pool, it would be necessary to implement a new wrapper in order to accommodate the new service. This is, however, not a scalable solution due to the rate at which new services are coming online (Sheth, Gomadam, and Lathem, 2007). Moreover, it would be extremely difficult to work with a service whose inputs and outputs are in a different format. This makes it difficult to address issues related to data interoperability, integration, and mediation (Lathem, Gomadam, and Sheth, 2007). The concept of Semantic Mashups (SMashups) (Sheth, Verma, and Gomadam, 2006) addresses these limitations by proposing the semantic annotation of Web services as a solution to the service integration and mediation challenges.

2.5

Semantic Mashups (SMashups)

The challenges of service interoperability, reuse, integration, and mediation have led to several proposals for Semantic Web services. Several research projects have looked at semantics for traditional (WSDL or SOAP) Web services to help address heterogeneity, reuse, and mediation challenges, and the community took a step toward supporting semantics for Web services by adopting Semantic Annotation for WSDL (SAWSDL)5 as a W3C recommendation in 2007. The SAWSDL specification enables semantic annotations for Web services using and building on the existing extensibility framework of WSDL (Benslimane, Dustdar, and Sheth, 2008; Verma and Sheth, 2007). In SAWSDL, semantic annotations describing inputs, outputs, operation, interfaces, and faults, are embedded as properties in the WSDL (Lathem, Gomadam, and Sheth, 2007). Recently, driven primarily by the popularity of lightweight RESTful Web services, AJAX, and JSON that build core technologies in the Web 2.0 movement, attention has shifted to using semantics to annotate RESTful Services. For instance, (Lathem, Gomadam, and Sheth, 2007; Sheth, Gomadam, and Lathem, 2007) proposed a framework called Semantic Annotation of REST (SA-REST) to add semantics to RESTful services. SA-REST builds upon the authors' original ideas in WSDL-S (Akkiraju et al., 2005), which was the primary input of the W3C recommendation SAWSDL. The key difference between SAWSDL and SA-REST is that unlike SAWSDL, where annotations are added directly in the WSDL of the service, SA-REST annotations have to be embedded into the HTML page that describes the service. Consequently, SA-REST uses microformatbased approaches such as RDFa6 and Gleaning Resource Descriptions


from Dialects of Languages (GRDDL)7 to add and capture annotations via properties of HTML elements (Sheth, Gomadam, and Lathem, 2007). The major drawbacks of an SA-REST approach to add semantic annotations to RESTful services are threefold: First, semantic annotation with SA-REST requires the use of microformats. Microformats, however, come in many different competing forms. And, even the process of adding semantics with standardized microformats such as RDFa or GRDDL is not straightforward. For instance, to annotate a HTML page with GRDDL the service provider needs (1) to embed the annotations in any, not necessarily standardized, microformat, (2) add the URL of the GRDDL profile to the head element in the HTML document, and (3) add to the head element a link tag that contains the URL of an XSLT that translates the GRDDL profile into SAREST specific RDF triples (Lathem, Gomadam, and Sheth, 2007). The complexity of these microformats makes it hard for SA-REST to be adopted by service providers for the semantic annotation of their RESTful services. Second, the annotation of a concept (e.g. input, output, operation) in SA-REST is a way to tie together the concept to a class that exists in an ontology (Lathem, Gomadam, and Sheth, 2007). SA-REST, thus, presumes an agreement among all service providers on a common ontology. This is however not realistic, since it would be impossible to get all service providers to agree on a single ontology to describe their concepts. Third, besides linking a concept to an ontology class, data mediation in SA-REST requires the specification of a lifting and lowering schemas, that is mapping of the data structure that represents the input and output of a given service to the data structure of the ontology. The use of lifting and lowering schemas means, on the one hand, extra complicated work for the service provider to work with XSLTs or XQueries to specify and keep upto-date its lifting and lowering schemas, and, on the other hand, higher server workload and additional server-side code in order to deal with parsing and applying the lifting and lowering mappings between the services to be mashed up and the ontology. In Sum, the complexity of the SMashup approach makes it hard to be adopted for Web mashups. In the next section, we propose a more lightweight and standards-based approach to creating mashup, based on the model-driven mashup development concept.

3

Model-Driven Mashup Development

M.A. Chatti et al.

As discussed above, challenges for mashup development today include scalability, interoperability, reuse, and automatic service invocation and mediation. In the next sections, we argue that the concept of ModelDriven Mashup Development (MDMD) can provide a potential solution to these challenges.

3.1 Model-Driven Development Model-Driven Development (MDD) (a.k.a Model-Driven Engineering; MDE) is a term typically used to describe "software development approaches in which abstract models of software systems are created and systematically transformed to concrete implementations" (France and Rumpe, 2007, p. 38). Domain Specific Modelling (DSM) and Model Driven Architecture (MDA) are the two modelling paradigms primarily used for MDD. According to the DSM Forum8, DSM refers to a software engineering methodology that "raises the level of abstraction beyond programming by specifying the solution directly using domain concepts". DSM models are specified using a Domain Specific Language (DSL). Mernik at al. (2005) define DSLs are “languages tailored to a specific application domain. They offer substantial gains in expressiveness and ease of use compared with general-purpose programming languages in their domain of application" (p. 316). DSM objective is to automatically generate the implementation from these models with domain-specific code generators. MDA is a similar approach to the development of software systems fostered by the Object Management Group (OMG)9 that separates the specification of the system functionality from its implementation on a on a specific technology platform. A common pattern of MDA development is to define a platform-independent model (PIM) of a system, and to apply transformations to this PIM to obtain one or more platform-specific models (PSMs) that include technology specific details, using different DSLs or a General Purpose Language (GPL) like Java, C#, Python, etc. Figure 2

Model-Driven Mashup Development


3.2 MDMD In analogy to model-driven development (MDD) as used in software engineering, model-driven mashup development (MDMD) focuses on mashup specification (i.e. creating mashup models) rather than mashup implementation. Figure 2 depicts how a model-driven approach to mashup development works. Following an MDMD approach, mashup creation is performed in four steps: 1. Mashup Modelling 2. Mashup Transformation / Generation 3. Mashup Execution 4. Mashup Visualisation

3.2.1 Mashup Modelling The MDMD approach starts with a mashup modelling step, which occurs in a mashup environment neutral manner, and gives a high level abstraction to describe service mashups. In this crucial step, mashups are expressed as models. These models define the mashup functionality using an extensible Mashup Modeling Language (MML). An MML would be used to describe how to call the mashup services (service invocation),

M.A. Chatti et al.

what parameters are expected (service input), what parameters are needed for mediation (service mediation), and what to expect in return (service/mashup output). The result of this step are mashup models that are portable, reusable, interoperable, and user interface framework independent. In this paper, we propose the Mashup Mapping Description (MMD) as an example of an MML. MMD is a lightweight Domain Specific Language (DSL), modelling a RESTful mashup domain. The reason is that the majority of the currently available APIs are REST based. MMD leverages the Service Mapping Description (SMD) proposed by Zyp (2008). SMD is a flexible and simple JSON representation describing lightweight Web services. A wide array of web services can be described with SMD including RESTful services and JSON-RPC services. SMD uses JSON Schema to provide a definition for a variety of available services, and document how to call the services, what parameters are expected, and what to expect in return (Zyp, 2008). Figure 3 shows the Yahoo! search service annotated with SMD. SMD facilitates data mediation between the services to be mashed up, since it provides a thorough description of how a service can be invoked, the type of data that should be passed to the service and what will be returned from it. MMD builds on SMD to model RESTful mashups (i.e. mashups of RESTful Web services). Figure 4 shows a model for the mashup of two popular services, namely Geonames and Google Video Search, based on MMD. It's also possible to think about other mashup modelling languages that are based on other well-established service description specifications, such as WADL10 and WSDL 2.011 (both are XML-based and are used to describe HTTP-based services). The main advantage of MMD, as compared to a WADL or WSDL 2.0-based MML, is that it uses JSON. JSON is a lightweight data interchange format whose simplicity has resulted in widespread use among Web developers. JSON offers two major advantages over XML. First, JSON-encoded data is less verbose than the equivalent data in XML. XML uses duplicate start and end tags to wrap data values. A JSON object, by contrast, is simply a series of comma-separated name:value pairs wrapped in curly braces. This yields better performance of the JSON-based Web applications because JSON data downloads more quickly than XML data. JSON's second benefit is that it's easy to parse using any programming language, and its structures map more directly onto the data structures used in modern programming languages. Because it is essentially a string representation of a JavaScript object (hence the name), browsers can parse JSON data simply by calling the JavaScript "eval" function. Any field of the JSON object can then be directly accessed by name.


JSON is also the basis of a very powerful technique for building clientbased (in-browser) mashups, namely JSON with Padding (JSONP), which was created as a workaround to the Same-Origin Policy (SOP) problem. In Web 2.0, Asynchronous JavaScript and XML (AJAX) is becoming the driving force behind mashups. In AJAX, data is retrieved using the XMLHttpRequest function, which is an API that lets client-side JavaScript make HTTP connections to a server. The SOP, however, prevents the AJAX code from making an XMLHttpRequest call to a URL that is not on the same domain as the current page, because of the cross-domain attacks that could result. The normal way around SOP is to have the Web server behave as a proxy. The Web page then requests data from the Web server it originates from, and the Web server handles making the remote call to the third-party server and returning the results to the Web page. Although widely used, this technique isn't scalable. Another way to overcome the SOP limitation is to insert a dynamic script element in the Web page, one whose source is pointing to the service URL in the other domain and gets the data in the script itself. It works because the same-origin policy doesn't prevent the insertion of dynamic script elements into the Web page and treats the scripts as if they were loaded from the domain that provided the Web page. This is actually how JSONP works: load the JSON response within a tag. In order to do this, the name of a callback function is specified as an input argument of the call itself. The remote server will then wrap the JSON response in a call to that function. When the browser finishes downloading the new contents of the tag, the callback function executes. This approach requires the remote Web service to behave as a JSONP service; that is a Web service with the additional capability of accepting a callback function name as a request parameter and supporting the wrapping of the returned JSON data in a user-specified function call (Ozses and Ergul, 2009). Popular service providers such as Google and Yahoo! already support this technique. Figure 3

Annotation of RESTful Web Services with SMD

M.A. Chatti et al.

Figure 4

Mashup Modelling with MMD

The simplicity of JSON as a lightweight data interchange format and the power of JSONP as a flexible technique for client-based (in-browser) mashups, make MMD much better suited to modelling RESTful mashups than a WADL or WSDL 2.0-based MML. In order to support the mashup modeling step, mashup modeling tools (e.g. Visual Mashup Model Composer) are required to help users build


mashup models in an easy and visual manner without the need to get familiar with the MML.

3.2.2 Mashup Transformation / Generation In a second step, the mashup model is translated to one or more platform/UI framework specific mashup implementations. The mashup implementation can be a mashup code using a particular declarative mashup Domain Specific Language (DSL) (e.g. EMML12) or a mashup UI based on a specific UI framework (e.g. HTML/JavaScript/CSS, Flash/Flex, Android). This step should be well supported through generic tools that can process the mashup models written in MML and generate human or programmatic interfaces.

3.2.3 Mashup Execution Once the mashup code/interface is generated and the mashup property values are assigned (in the code/interface), the mashup can then be executed inside a compliant mashup runtime that serves as a mashup demonstration environment (e.g. EMML Reference Runtime Engine, Flash Player Runtime, Android Runtime).

3.2.4 Mashup Visualization After a mashup has been created, it should be possible to provide a view of the mashup in a portable and embeddable mashup widget (aka mashlet). Mashlets are defined as "user-oriented micro-applications ... providing the visualization, or “face”, of a mashup to be embedded in a web page" (Kemsley, 2008, para. 4). Once a fully functioning mashlet is developed, it can be published, shared, and reused anywhere. It can for instance be embedded into any HTML page, blog, wiki, portal, widget/gadget container (e.g. iGoogle, Apache Shindig13), CMS/LMS, social networking platform, enterprise mashup platform, or mobile device.

4

Mashup Personal Learning Environments

Personal Learning Environment (PLE) is a learner's gate to knowledge. From a technical point of view, a PLE can be viewed as a self-defined collection of services, tools, and devices that help learners build their Personal Knowledge Networks (PKN), encompassing tacit knowledge nodes (i.e. people) and explicit knowledge nodes (i.e. information). Thus, mechanisms that support learners in building their PLEs become crucial.

M.A. Chatti et al.

Mashups provide an interesting solution to developing PLEs. Most of the state-of-the-art mashup PLE solutions only focus on mashups by aggregation. These solutions mainly support learners in juxtaposing content from different sources (mainly feeds and widgets) into a single interface. Examples include PLEF14, MUPPLE15, and - although not designed as educational technology - Personalized Start Pages such as iGoogle16 and Netvibes17. As outlined in Section 2, unlike mashups by aggregation, creating mashups by integration is a time consuming task and impossible for a typical learner with no programming knowledge. Moreover, in order to create mashups by integration, it is difficult to address issues related to scalability, interoperability, reuse, and automatic service invocation and mediation. The MDMD concept discussed in Section 3 addresses these issues by proposing the modelling of services and mashups as a solution. In the next section, we present the conceptual and technical details of PLEF-Ext as a flexible framework for end-user building of mashup PLEs, following the MDMD approach.

5.

Model-Driven Mashup PLEs with PLEF-Ext

PLEF-Ext provides a flexible framework that can help learners easily extend their PLEs with new learning services. PLEF-Ext supports learners in sharing, finding, integrating, managing, reusing, and remixing annotated RESTful learning services with minimum effort. PLEF-Ext uses SMD for the description of the services and MMD for the modelling of services mashups.

5.1 PLEF-Ext Architecture An abstract architecture of PLEF-Ext is depicted in Figure 5. PLEF-Ext encompasses five main modules:  The Service Discovery Module (iSearch) provides a tag-based search mechanism that enables learners to locate learning services remixed and shared by peers within PLEF-Ext.  The Service Integration Module (iPull) makes it possible for the learner to easily plug in a new SMD-annotated external learning service into her PLE, by just specifying the URLs of the service and its SMD.  The Service Adaptation Module (iAdapt) enables the learner to adapt a service to her needs, by just specifying the parameters and return values of the service.  The Service Aggregation Module (iMix) lets learners compose a




Figure 5

mashup model in a drag-and-drop fashion. This model is then used to generate, execute, and visualize the real mashup. The Service Management Module (MyStuff) supports the learner in managing (i.e. add, remove, edit, tag) her learning services within PLEF-Ext. PLEF-Ext Abstract Architecture

PLEF-Ext is built upon a client-server architecture. However, in contrast to traditional mashup environments, where the majority of computation-intensive processing will occur on the server (mashups are created using server-side proxies), the client in PLEF-Ext is much fatter. That is, the mashups will be built and run on the client-side, using the computing power of the client device. Coupled with JSONP services that expose their data in JSON and wrap it in function call, the client (browser) can make requests for data from the different services and use the fetched data to build in-browser mashups. In order to achieve this, the client in PLEF-Ext is assisted with an extensive user interface library of widgets and panels provided by SmartGWT18 and powerful GWT19 libraries to perform a wide range of actions, such as parsing of the fetched JSON data and asynchronous server communication through HTTP or remote procedure calls (RPCs). In the next sections, we discuss in more details the functionalities of the PLEF-Ext module iMix. Figure 6 depicts iMix in action. iMix supports the

M.A. Chatti et al.

mashup modelling, mashup generation, and mashup execution steps required in a mashup creation process, based on the MDMD approach. Figure 6

iMix in Action

5.2 Mashup Modelling with iMix iMix provides a visual mashup model composer to support learners in creating and editing a mashup model described in MMD. Figure 7 demonstrates the mashup modelling process in iMix. We suppose that the services to be mashed up are JSONP services. Their SMDs, however, are available on remote servers that return pure JSON data without wrapping it in a function call. Since SMD is a relatively new concept, it is not supported yet by third-party service providers. For this work we are using SMDs that we created for popular JSONP services such as Google data APIs, Yahoo! search, geonames, delicious, and flickr. In this case, in order to work around the SOP security problem, we need to create a proxy on our local server. To note that if third-party service providers would in the future adopt SMD and would be able to return the SMD data via JSONP, the proxy server can be omitted and interaction with remote resources will be done from the client-side, solely via JSONP. This would then make the architecture of iMix much simpler.


In order to mashup two RESTful Web services with iMix, a learner first needs to select the services to be mashed up. The client then makes HTTP calls (XMLHttpRequests) to the local server (proxy server) and have it go fetch the SMD data from the remote servers (step 1 in Figure 7). This can be achieved in GWT either with GWT RPC or direct HTTP using GWT RequestBuilder. The local server downloads the JSON-encoded SMDs from the remote servers (step 2) and passes it back to the client (step 3). When the client retrieves the SMDs from the local server, a JSON parser (GWT JSONParser) is applied to extract the descriptions of the services from their SMDs (i.e. service inputs, outputs, and request type) and display the descriptions to the learner in the Mashup Model Editor (step 4). The Mashup Model Editor is the key component of iMix. As mentioned earlier, a key difficulty in creating mashups is data mediation between the services to be mashed up. The main role of the Mashup Model Editor is to use the SMD annotations of the services to be mashed up to enable semi-automatic data mediation without any programming knowledge from the learner side. The learner would only need to perform drag-and-drop actions using the Mashup Model Editor to define the mashup steps: (1) construct the query URL at which to invoke service 1, (2) construct the query URL at which to invoke service 2 and specify the mashup parameters (e.g. the outputs of service 1 that should be inputs for service 2), and (3) specify the outputs of service 2 (i.e. mashup result). The result of these steps is a mashup model represented in MMD, which contains all necessary information for describing the services mashup at both data and process mediation levels (step 5).

5.3 Mashup Generation and Execution with iMix Figure 8 illustrates the mashup generation and executions steps in iMix. The local server loads the mashup model represented in MMD (step 1) and passes it to the client (step 2). The client applies a GWT JSONParser to process the mashup model and then generates a mashup user interface based on the AJAX widget library provided by GWT and SmartGWT (step 3). The learner can then define the mashup property values and start the execution of the real mashup. At this point, the client invokes service 1 via JSONP to gather the data that are needed for the mashup (step 4 and 5) and invokes service 2 via JSONP to get the final result of the mashup (step 6 and 7), which will be shown to the learner in the mashup viewer (step 8). Figure 7

Mashup Modelling with iMix

M.A. Chatti et al.

Figure 8

Mashup Generation and Execution with iMix


6.

Conclusion

In this paper, we discussed the challenge of PLE extensibility and how mashups can provide a powerful tool to achieve this challenge. We outlined the limitations in current mashup development platforms and tools to deal with crucial challenges in mashup development today, namely scalability, interoperability, reuse, and automatic service invocation and mediation. We discussed the model-driven mashup development (MDMD) methodology as an alternative approach that guides in a systematic way the rapid and efficient creation of mashups. We finally presented the conceptual and technical details of PLEF-Ext as a mashup PLE framework that leverages MDMD for user-friendly learning mashups. All of these efforts have been made available on the PLEF-Ext project homepage20. The main contributions of this paper are twofold. Firstly, a model-driven development (MDD) approach is used, for the first time to the best of our knowledge, to support the mashup creation process. Secondly, based on MDMD, a framework is presented, which can help learners build mashup PLEs.

References Akkiraju R., Farrell, J., Miller, J., Nagarajan, M., Schmidt, M., Sheth, A. and Verma, K. (2005). Web Service Semantics - WSDL-S, http://www.w3.org/Submission/WSDL-S/, (visited 28.12.2009). Benslimane, D., Dustdar, S. and Sheth, A.P. (2008) ‘Services Mashups: The New Generation of Web Applications’, IEEE Internet Computing, Vol. 12, No. 5, pp.13-15. Chatti, M.A., Jarke, M. and Specht, M. (2009) ‘PLEF: A Conceptual Framework for Mashup Personal Learning Environments’, IEEE Technical Committee on Learning Technology (TCLT), Vol. 11, No. 3, July 2009. Di Lorenzo, G., Hacid, H. and Paik, H. (2009) ‘Data Integration in Mashups’, SIGMOD Record, Vol. 38, No. 1, pp.59-66. Fielding, R.T. (2000) Architectural Styles and the Design of Network-based Software Architectures, Chapter 5: Representational State Transfer (REST). PhD thesis. University of California, Irvine. France, R. and Rumpe, B. (2007) ‘Model-Driven Development of Complex Software: A Research Roadmap’. In: Future of Software Engineering 2007 at ICSE, Minneapolis, pp.37-54. Kemsley, S. (2008): JackBe Enterprise Mashlets, http://www.column2.com/tag/jackbe/, (visited 5.1.2010). Lathem, J., Gomadam, K. and Sheth, A.P. (2007): ‘SA-REST and (S)mashups : Adding Semantics to RESTful Services’. In: Proceedings of the First IEEE International Conference on Semantic Computing (ICSC 2007), September 17-19, 2007, Irvine, California, USA. pp.469476. Maximilien E.M., Wilkinson, H., Desai, N. and Tai, S. (2007). A Domain-Specific Language for Web APIs and Services Mashups. In ICSOC’07, LNCS 4749, pp.13-26. Mernik, M., Heering, J. and Sloane, A.M. (2005) ‘When and How to Develop Domain-Specific Languages’, ACM Computing Surveys, Vol. 37, No. 4, pp.316-344.

M.A. Chatti et al. Ort, E., Brydon, S. and Basler, M. (2007a): Mashups Styles, Part 1: Server-Side Mashups. Sun Microsystems, http://java.sun.com/developer/technicalArticles/J2EE/mashup_1/, (visited 28.12.2009). Ort, E., Brydon, S. and Basler, M. (2007b): Mashups Styles, Part 2: Client-Side Mashups. Sun Microsystems, http://java.sun.com/developer/technicalArticles/J2EE/mashup_2/, (visited 28.12.2009). Ozses, S. and Erg ul, S. (2009): Cross-domain communications with JSONP, http://www.ibm.com/developerworks/library/wa-aj-jsonp1/, (visited 28.12.2009). Sheth, A.P., Gomadam, K. and Lathem, J. (2007) ‘SA-REST: Semantically Interoperable and Easier-to-Use Services and Mashups’, IEEE Internet Computing, Vol. 11, No. 6, pp.91-94. Sheth, A.P., Verma, K. and Gomadam, K. (2006) ‘Semantics to energize the full services spectrum’, Commun. ACM, Vol. 49, No. 7, pp.55-61. Taivalsaari, A. (2009) ‘Mashware: The Future of Web Applications’. Technical report, Sun Microsystems Laboratories, http://research.sun.com/techrep/2009/smli_tr-2009-181.pdf, (visited 28.12.2009). Taivalsaari, A. and Mikkonen, T. (2008) ‘Mashups and Modularity: Towards Secure and Reusable Web Applications’. In: 23rd IEEE/ACM International Conference on Automated Software Engineering - Workshop Proceedings (ASE Workshops 2008), 15-16 September 2008, L'Aquila, Italy, pp.25-33. Verma, K. and Sheth, A.P. (2007) ‘Semantically Annotating a Web Service’, IEEE Internet Computing, Vol. 11, No. 2, pp.83-85. Zyp, K. (2008). Service Mapping Description Proposal, http://groups.google.com/group/jsonschema/web/service-mapping-description-proposal?pli=1, (visited 28.12.2009).

Notes 1

This is a revised and extended version of the paper ‘SMashup Personal Learning Environments’ originally presented at the 2nd Workshop on Mash-Up Personal Learning Environments (MUPPLE’09), September, 29, 2009, Nice, France. 2 http://pipes.yahoo.com/ 3 http://www.popfly.com/ (discontinued while this article was written) 4 http://code.google.com/gme/ 5 http://www.w3.org/2002/ws/sawsdl/ 6 http://www.w3.org/TR/xhtml-rdfa-primer/ 7 http://www.w3.org/TR/grddl/ 8 http://www.dsmforum.org/ 9 http://www.omg.org/mda/) 10 http://www.w3.org/Submission/wadl/ 11 http://www.w3.org/TR/wsdl20/ 12 http://www.openmashup.org/omadocs/v1.0/index.html 13 http://incubator.apache.org/shindig/ 14 http://eiche.informatik.rwth-aachen.de:3333/PLEF/index.jsp 15 http://mupple.org 16 http://www.google.com/ig

Model-Driven Mashup Personal Learning Environments 17

http://www.netvibes.com/ http://code.google.com/p/smartgwt/ 19 http://code.google.com/webtoolkit/ 20 http://eiche.informatik.rwth-aachen.de:3333/PLEF-Ext/ 18