Facing Interaction-Rich RIAs: the Orchestration Model Sandy Pérez, Oscar Díaz Santiago Meliá, Jaime Gómez ONEKIN Group, University of the Basque Country IWAD Group, University of Alicante San Sebastián, Spain Alicante, Spain [email protected], [email protected] {santi,jgomez}@dlsi.ua.es Abstract driven approaches to abstract away from the plethora of RIA platforms currently competing to find their way. In Promptness, efficiency and stickiness are among the ad- this context, this paper focuses on the interactivity wealth vantages exhibited by the new crop of Rich Internet Appli- brought by RIAs. Specifically, we strive to find systematic cations (RIAs). These advantages came at the cost of in- engineering principles to (1) define interaction dependen- creasing the complexity of development. Additionally, the cies among the GUI widgets and (2) grouping of widgets plethora of RIA frameworks can lock this code into a spe- into Ajax pages. Other main concerns such as data replica- cific platform. This scenario advises for using model-driven tion [7] are outside the scope of this work. development (MDD). This paper focuses on interaction- Interaction Dependencies. Traditional GUI method- rich RIAs by addressing two issues: (1) interaction depen- ologies advise to begin with a mock-up of the interfaces dencies among widgets, and (2) grouping of widgets into to be presented to the user. IDEs such as Visual Studio and Ajax pages. These concerns are captured in the Orches- JDeveloper follow such approach providing first a design of tration Model. MDD wise, OO-H metamodels accounts the pages which are next enriched with the supported func- for the PIMs whereas Google Web Toolkit is the selected tionality and content. Model-driven web methods tend to PSM. During transformation, a “message broker” pattern use a similar manner where a first draft of the presentation is introduced to decouple widgets from their dependencies. is generated after the navigation model. This draft is then When Ajax pages are generated, heuristics are introduced enriched with presentation concerns. However, describing to find a balance between communication overhead, presen- such mock-ups for RIAs is a more demanding process. The tation readiness and maintainability. A running example is wealth of an Ajax page can not be captured by just a GUI used throughout. mock-up as those generated by Visual Studio and the like. Grouping of widgets. The page is traditionally both the unit of delivery and the unit of presentation. However, this 1. Introduction is no longer so in RIAs. The fat-client approach that charac- terises RIAs permits a single page to convey the interactiv- Rich Internet Applications (RIAs) strive to leverage the ity that would have required multiple pages in a traditional Web with the engaging interactivity found in traditional setting. This recommends to distinguish between “page” as desktop applications. Combined with the Software-as-a- the unit of delivery from “screenShot” as the unit of render- Service (SaaS) delivery model, web applications are em- ing (i.e. the set of artefacts being simultaneously rendered). powered to compete with desktop interfaces [3]. Moreover, This defines a spectrum on the way presentation is deliv- RIAs provide a new client-server architecture that reduces ered. At one end of the spectrum is to equate page and significantly the network traffic using more intelligent asyn- screenShot (i.e. the traditional approach). The other end chronous requests. Faster performance, readiness and en- is the single-page approach where all screenShots are em- gaging interactivity are the hallmarks of this new crop of bodied in a unique page (e.g. Google’s GMail, Reader or applications such as Google’s GMail, Google’s Docs or Ya- Maps follow this pattern). However, something in between hoo!’s Mail. is also possible. For instance, the website www.a9.com is The web engineering community is well-aware that RIA distributed among distinct Ajax pages. development imposes new stringent demands to traditional This paper addresses how existing model-based web methods [21]. On one hand, it must introduce/enrich mod- methods can account for these two issues. Basically, the els that account for the new concerns raised by RIAs. On Presentation Model specifies the application screenShots. the other hand, the youth of the area advises to use model- This model is then complemented with an Orchestration 1 Model that captures the interaction dependencies among • the Orchestration Model, which addresses widget co- presentation widgets. In turn, such relationships guide the ordination. It introduces the notion of orchestral wid- designer to distribute the screenShots among Ajax pages. get, SignalBroadcast, SignalHandler and page. Although the approach is illustrated for the OO-H method [13], the insights can be easily extrapolated to other meth- • the Google Web Toolkit (GWT), which is a PSM for ods. RIAs. Within this framework, a message-broker archi- As an additional contribution, an MDD approach is tecture is generated through transformation from the followed. OO-H metamodels accounts for the Platform previous models. Independent Models (PIM) whereas Google Web Toolkit The GWT code is obtained through transformation. Indeed, (GWT) [14] is the selected Ajax platform (i.e. the Platform MDD conceives development as transformation chains Specific Model or PSM). During transformation, a “mes- where the artefacts that result from each phase must be sage broker” pattern is introduced to decouple widgets from models. SPEM (Software Process Engineering Metamodel) their dependencies and in so doing, bringing the advantages is a notation for defining processes and their components of “separation of concerns”. Furthermore, distribution of whose constructs are described in UML notation [19]. widgets among Ajax pages is addressed through heuristics Hereafter, SPEM terminology is used to specify the mile- that attempt to find a balance between communication over- stone, roles and dataflow that go with producing a RIA us- head, presentation readiness and maintainability. A running ing OO-H. Stereotypes are introduced to account for MDD example is used throughout. specificities. Specifically, The paper begins with an outline of the whole process to better frame the role of the Orchestration Model. • actor stereotypes are introduced to account for the manner a transformation can be conducted: automatic 2. An MDD process for RIAs (< <gear> > stereotype) or manual (< <hand> > stereotype), The attractive interactions exhibited by RIAs came at • activity stereotypes are supported to model different the cost of increasing the complexity of development. Fur- types of transformations: PIMToPIM, PIMToPSM, thermore, the plethora of RIA frameworks can lock this PIMToCode, PSMToCode, etc. code into a specific platform and to make things worse, this framework is likely to evolve due to the youth of the tech- Figure 1 outlines the OO-H process. First, the OO-H De- nology. This advocates for MDD. signer defines the Conceptual Model which serves as in- MDD achieves decoupling by creating distinct (meta) put to obtain the Navigation Model. The latter in turn models of a system at different levels of abstraction. Then, serves to generate a first skeleton of the Presentation Model. transformations are applied that eventually produce code. This draft is then completed by the UI Designer using Hence, direct code programming is substituted by first mod- VisualStudio-like tooling (i.e. conceiving the page as a elling, next transforming. This permits facing development screenShot). complexity by distributing concerns among distinct models RIAs detach the unit of delivery (i.e. a page as the result and different abstraction layers while decoupling from tech- of an HTTP request with an addressable URL) from the unit nological subtleties. of presentation (i.e. a set of widgets simultaneously avail- MDD focuses on the construction of models, specifica- able or screenShot). In so doing, allows different ways of tion of transformation patterns, and automatic generation of distributing the widgets into a single page or different pages. code. For our case, the main models include: Some Ajax applications have only one page (e.g. Google’s Mail) whereas other Ajax applications go for several pages • the Conceptual Model, which indicates the main enti- (e.g. a9.com). However, additional information about wid- ties and relationships found in the application domain. get dependencies is required to assess how screenShots will It addresses which data is to be handled. be finally grouped into pages. This is the matter of the Or- chestration Model. • the Navigation Model, which specifies the data to be The Orchestration Model captures interaction dependen- presented (as a view on the Conceptual Model) and the cies among presentation widgets. Using state machines, order in which this data is to be presented. It considers widgets are modelled as states. These widgets can react to sequencing and data flow. events raised directly by the user. Additionally, some wid- gets can be affected by operations conducted in other wid- • the Presentation Model, which considers data render- gets leading to interaction dependencies. This provides the ing and layout. It introduces the notion of widget and desktop-like interactivity that characterises most RIA. No- screenShot. tice however, that the Orchestration Model is not defined Figure 1. An MDD Process for RIA (OM stands for Orchestration Model). from scratch (see Figure 1). A transformation model-to- model (i.e. Pres&Nav2Orch) obtains a first skeleton which is later enriched by the Orchestration Designer with the in- teraction dependencies. Once interaction dependencies are manually specified, an automatic transformation takes this information to gen- erate a new Orchestration Model but now, enhanced with pages. The tag value “pageTag” is used to mark those screenShot states that are going to be packaged into a single Figure 2. Mail’s Conceptual Model Ajax page. The transformer provides a first packaging that is later validated/extended by the Orchestration Designer. 3. A running example The validation of the Orchestration Model completes the specification of all models.