Mixup: A Development and Runtime Environment for Integration at the - - PDF document

See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/220940105

Mixup: A Development and Runtime Environment for Integration at the Presentation Layer

Conference Paper · July 2007

DOI: 10.1007/978-3-540-73597-7_40 · Source: DBLP

CITATIONS

15

READS

52

6 authors, including: Some of the authors of this publication are also working on these related projects: Crowdsourcing View project Smart Ecosystems and Children View project Jin Yu UNSW Sydney

6 PUBLICATIONS 673 CITATIONS

SEE PROFILE

Boualem Benatallah UNSW Sydney

309 PUBLICATIONS 12,927 CITATIONS

SEE PROFILE

Florian Daniel Politecnico di Milano

218 PUBLICATIONS 3,330 CITATIONS

SEE PROFILE

Maristella Matera Politecnico di Milano

209 PUBLICATIONS 3,237 CITATIONS

SEE PROFILE

All content following this page was uploaded by Jin Yu on 02 June 2014.

The user has requested enhancement of the downloaded file.

Mixup: a Development and Runtime Environment for Integration at the Presentation Layer

Jin Yu1, Boualem Benatallah1, Fabio Casati2, Florian Daniel3, Maristella Matera3 and Regis Saint-Paul1

1 University of New South Wales, Sydney NSW 2052, Australia

{jyu,boualem,regiss}@cse.unsw.edu.au

2 University of Trento, Via Sommarive, 14/I-38050, Trento, Italy

casati@dit.unitn.it

3 Politecnico di Milano, Via Ponzio, 34/5-20133, Milano, Italy

{daniel,matera}@elet.polimi.it

• Abstract. In this paper we present a development and runtime environment for

creating composite applications by reusing existing presentation components. The granularity of components is that of stand-alone modules encapsulating re- usable functionalities. The goal is to allow developers to easily create compos- ite applications by combining the components' individual user interfaces.

1 Introduction

User interface (UI) development is one of the most time-consuming tasks in the appli- cation development process [3]. As a result, reusing UI components is critical in this

• process. There is a large body of research in areas such as component-based systems,

enterprise application integration and service composition [1], but little work has been done to facilitate integration at the presentation or UI level. While UI development today is facilitated by frameworks (such as Java Swing) providing pre-packaged UI classes such as buttons, menus and the likes, high-level presentation components encapsulating reusable application functionalities have received little attention. This demo presents a development and runtime environment, called Mixup, for in- tegration at the presentation level, that is, integration of components by combining their presentation front-ends, rather than their application logic or data. The goal is to be able to quickly build complex user interfaces – and in particular web interfaces – by dragging and dropping existing web UIs (called components) on a canvas and by specifying how components should synchronize based on user and application events. As an example, consider building a US National Park Guide application that includes a park listing, an image displayer showing images given a point of interest and a map displaying the location of a given point of interest. The application can be built out of presentation front-ends such as Google Maps and Flickr.NET1. Once integrated, the components should present information in an orchestrated fashion, so that for exam- ple when a user selects a national park from the park listing, the image displayer shows an image of the selected park, while the map displays its location (Fig. 1).

1 The .NET version of Flickr.

• Fig. 1. The National Park Guide

In this demo we show how composite applications can be created by combining the front-ends of existing applications, how to define the orchestration logic among them as well as their layout, and how all these can be done quickly via a visual editor. Details on the motivations, rationale, challenges and the proposed approach are provided in [4]. A slideshow of the demo scenario is available on the web2.

2 The Conceptual Framework

Borrowing lessons from application integration, we argue that integration at the pres- entation layer needs the definition of four basic elements: component model, compo- sition model, specification language, and runtime environment. For the component model, we argue that presentation components are centered around the notion of presentation state, which is a conceptual, application-specific description of what the component is showing. For example, for a map component, the state may describe the location currently being shown. In addition, a component exposes events to notify state changes (e.g. due to user interaction with the compo- nent’s UI) and operations to allow other components to request state changes. Finally, a component has properties to represent appearance characteristics (e.g. text color) and customization parameters. Note that the Mixup component model is abstract; that is, it is independent of the technologies used for native component implementations. The composition model allows the specification of event-based integration logics, as we argue that presentation integration is mostly event-based for synchronizing UIs. The integration logics are specified via a set of event listeners, each linking an event in one component to an operation in another component. For example, the park listing component fires a park selection changed event when the user selects a different park; this causes the invocation of an operation on the map component to show a map of the newly selected park and the invocation of an operation on the image displayer to show an image of the new park.

2 http://www.cse.unsw.edu.au/~jyu/icwe07/demo.pdf

To model components and compositions, Mixup includes the Extensible Presen- tation Integration Language (XPIL), which contains a set of XML elements for describing the component model (i.e. component descriptor), similarly to WSDL for Web services, and a set of XML elements for specifying the composition model. Finally, a runtime middleware executes the resulting composite application by interpreting the specifications in XPIL. In addition, the middleware includes a com- ponent adapter framework that allows bindings from the abstract component model to a concrete (native) component implementation. A component adapter thus facilitates the communication between the runtime middleware and the native component im- plemented in a particular component technology (e.g. ActiveX, Java Applet, etc.).

3 Mixup Demo Flow

In this section we demonstrate how the National Park example can be developed and executed using our framework. To create the composite application, the developer follows these steps: i) creating abstract component descriptors (if not yet available)

• ut of UI front-ends of existing applications and save them in a component registry;

ii) creating the composite application by specifying its components, their interactions and their layout information; iii) generating the XPIL documents and deploy the com- posite application to the runtime environment. Creating Component Descriptors. The abstract component descriptors for the three components in our National Park example can be created either semi-automatically or manually via the component editor (Fig. 2).

• Fig. 2. Development environment

First, if a particular component technology supports abstract descriptions (e.g. WSRP) or meta-language facilities such as refection (e.g. Java Applet), the compo- nent editor may call a suitable component inspector to find out the component's native events, operations and properties and then generate the component model descriptor with the appropriate bindings to the native implementation (this is similar to auto- matically generating a WSDL document from a Java class). The component developer may take the automatically generated component de- scriptor and directly deposit it into the registry. However, typically not all events,

• perations and properties are needed for the integration. The developer may choose to

filter them and to keep only the relevant ones, possibly renamed for better readability.

In cases where meta-language facilities are unavailable, the component editor al- lows the developer to manually create component descriptors. For the Google Maps component (as well as other AJAX components), the developer can create an abstract

• peration and specify its binding by pointing to the appropriate JavaScript function.

As depicted in Fig. 3, the editing panel (left hand side of the editor) shows the three components in our National Park example. The yellow flash icon denotes events, and the red rhombus icon denotes operations. Note that the label under the operation or event contains the name of the corresponding native method (e.g. JavaScript function, .NET method) in the component implementation. Creating Composite Application. To build the National Park example, the developer needs to specify both composition logic and layout information via the composition editor (Fig. 2). First, the developer must select the appropriate components from the registry win- dow (upper right corner of Mixup Editor in Fig. 3) and places them in the editing panel (left hand side of the editor). She then defines event listeners by drawing arrows that link events of one component to operations of other components. For example, the arrow from the "ParkSelectionChanged" event of the park listing component to "showPOI" operation of Google Maps implies that once the park selection is changed by the user, the "showPOI" operation should be called to display the map of the newly selected park. Similarly, the arrow to the "search" operation of Flickr specifies that Flickr should display an image of the park newly selected by the user.

• Fig. 3. Mixup Editor

If the event parameters and operation inputs do not match (e.g. number of parame- ters, data types), the editor will request additional input from the developer, such as XSLT or XQuery statements that can transform the event parameters to operation

• inputs. In addition, the developer may also specify additional integration and/or trans-

formation logics in the form of scripts or references to external code.

In Fig. 3, the registry window contains several additional components. Specifically, we could use Yahoo Maps instead of Google Maps as the map component in our National Park example. All we need to do is to select Yahoo Maps and drop it into the editing panel and then link the "ParkSelectionChanged" event of the park listing com- ponent to the appropriate operation of Yahoo Maps. Similarly, we could also use PBase image service instead of Flickr. Conversely, presentation components can be reused in a variety of composite applications. For example, the Google Maps compo- nent defined as per our framework can be also used in real estate applications and wherever maps are needed as part of the UI functionality. Finally, the editor includes a layout view for specifying layout information. Non- markup based components (e.g. Java applets, ActiveX controls) are represented by boxes corresponding to their location and size; the developer can move and resize the boxes to define the components' layout information. For markup-based components (e.g. AJAX components), the developer can provide additional CSS statements so that the components can have non-rectangular shapes and can be mixed and overlapped. Deployment and Runtime. Once the component descriptors are created and the composition logic and layout information are fully specified, an XPIL document can be generated and deployed to the runtime middleware. Our development environment includes a testing runtime, which consists of a browser and a web server running in the local development machine (Fig. 2). Finally, the demo shows the integrated UI at work – when the user interacts with

• ne component, the other related components will change in a synchronized fashion

according to the specifications in the composition model. The result of executing the composite application, US National Park Guide, is shown in Fig. 1.

4 Related Work

There are numerous web application frameworks for building composite GUI applica- tions from reusable modules; for example, Java Portlet, ASP.NET Web Parts, and

• WSRP. These frameworks all require the components to be built using their specific

interfaces or APIs. On the other hand, our framework is at a higher level - our com- ponent model provides an abstract layer on top of any existing component interfaces; and we do not require or enforce any specific APIs. Furthermore, our component model is generic enough to model existing presentation components developed in these frameworks (as a matter of fact, we plan to provide component adapters for the frameworks mentioned above). Detailed discussions on related work in this area can be found in [2].

References

• 1. Alonso, G., et al. Web Services: concepts, architectures, and applications. Springer, 2004.
• 2. Daniel, F., et al. Understanding UI integration: a survey of problems, technologies, and
• pportunities. IEEE Internet Computing. May/June, 2007.
• 3. Myers, B. A., Rosson, M. B. Survey on user interface programming. In the Proceedings of

SIGCHI'92, Monterey, California, May 1992.

• 4. Yu, J., et al. A framework for rapid integration of presentation components. In the Proceed-

ings of WWW'07, Banff, Canada, May 2007.

View publication stats View publication stats