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 READS 15 52 6 authors , including: Jin Yu Boualem Benatallah UNSW Sydney UNSW Sydney 6 PUBLICATIONS 673 CITATIONS 309 PUBLICATIONS 12,927 CITATIONS SEE PROFILE SEE PROFILE Florian Daniel Maristella Matera Politecnico di Milano Politecnico di Milano 218 PUBLICATIONS 3,330 CITATIONS 209 PUBLICATIONS 3,237 CITATIONS SEE PROFILE SEE PROFILE Some of the authors of this publication are also working on these related projects: Crowdsourcing View project Smart Ecosystems and Children View project 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 Yu 1 , Boualem Benatallah 1 , Fabio Casati 2 , Florian Daniel 3 , Maristella Matera 3 and Regis Saint-Paul 1 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.NET 1 . 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 web 2 . 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) out 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, operations 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.