Facing Interaction-Rich RIAs: the Orchestration Model

1. The 8th International Conference on Web Engineering July 16th, 2008 Facing Interaction-Rich RIAs: the Orchestration Model Sandy Pérez1, Oscar Díaz1, Santiago Meliá2 and Jaime Gómez2 1ONEKIN Research Group 2IWAD Group University of the Basque Country University of Alicante San Sebastián (Spain) Alicante (Spain)

2. Outline • An MDD process for RIAs • Obtaining the Orchestration Model • Down to code • Conclusions

3. Artefacts: Conceptual model Navigational model Presentation model Orchestration model Actors: OO-H Designer UI Designer Orchestration designer Model-to-model transformer Model-to-text transformer An MDD process for RIAs

4. Sample case. Conceptual model • Indicates the main entities and relationships found in the application domain.

5. Sample case. Navigation model • Specifies the data to be presented (as a view on the Conceptual Model) and the order in which this data is to be presented.

6. Sample case. Presentation model

7. Interaction dependency (ID) • RIAs are characterised by a rich-interaction setting that surpasses the boundaries of a single widget to spread along distinct widgets. • This allows widgets to react to actions not directly related to a user interaction with this widget • Interactions on a widget A can also affect a nearby widget B

8. Presentation vs. Orchestration • The Presentation Model is • a static representation of the widgets as structural components of a screenShot • The Orchestration Model captures • interaction dependencies (ID) among widgets • distribution of screenShots into pages • Orchestration is then an orthogonal concern from widgets themselves: distinct orchestration templates can be provided from the very same Presentation Model (where widgets are defined).

9. Sample case. Orchestration model

10. The process using SPEM notation

11. Obtaining the orchestration model • A skeleton is first automatically obtained from • the navigational model • the presentation model • Interaction dependencies are manually added to this skeleton. • Next, the Orchestration Model is heuristically enriched with pages. • And finally, it is validated by the Orchestration Designer.

12. The curtain rises! What does this model-to-model transformation do?

15. The curtain rises! What does this activity involve?

16. ‘MailList’ Widget ‘MailDetails’ Widget Sample case

17. Cont. • if an e-mail in the MailList is selected then • if e-mail is not spam then • the MailDetails widget should be refreshed with the contents of this e-mail. • else • a confirmation from the user is required

18. Capturing the ID • if an e-mail in the MailList is selected then

19. Cont. • if e-mail is not spam • then • the MailDetails • widget should be • refreshed with the • contents of this • e-mail. • else • a confirmation from • the user is required

20. Orchestral states • Synchronization is not • always automatic. • Sometimes additional • user interaction can • be required for • orchestration sake. • This leads to • orchestral states. • States whose • rationales rest on • some orchestrational • purposes.

21. Orchestral state typology • Confirm • serves to verify acceptance from the user. • Alert • helps when we want to make sure that the information is passed to the user. • Prompt • is used when a user’s input value is required. • SelectFromRange • uses when there are several options and only one is permitted.

22. The curtain rises! What does this activity involve?

23. Pages vs. screenShots • RIAs detach • the unit of delivery from • the unit of presentation • The unit of delivery: a page, which is the result of an HTTP request with an addressable URL • The unit of presentation: set of widgets simultaneously available or screenShot.

24. How many screenshots are supported by a page? • page = screenShot • Multi-page style (the traditional approach) • one page containing all screenShots • Single-page style • e.g. Google’s Mail • something in between • e.g. a9.com

25. Guidelines principles? • Single-page style gives better results… • more interactive and responsive web applications • better user satisfaction • but… • harder development.

26. Criteria: initial download • Multi-page • Only the content to be shown is downloaded. • Single-page • The whole application is downloaded. • Drawbacks • Content can be time-consuming to load (especially when it contains rich images) • JavaScript code takes up some size and loading time at the client. • There are some techniques aimed to reduce the initial download in single-page application: • Multi-Stage Download • Code Compression • On-Demand JavaScript • But this makes maintenance harder

27. Criteria: URL addressability • In Ajax, most server communication occurs through XMLHttpRequest which does not affect the page URL. • Hence, the application sticks with the same URL no matter how many transfers occur. • This causes some problems when developing single-page applications • History support • Bookmark support • Deep linking support

28. Criteria: URL addressability • Normally, in a single-page application, the behaviour of browser history is simulated by updating the URL on the fly. • URL are updated by adding a fragment identifier, it ensures that the new URL does not redirect us to a new page. • http://www.mydomain.com/ria_app#fragment_identifier

29. Criteria: Indexing by search engines • Search engines point "robot" scripts to a website and have them accumulate a collection of pages. • However, robots probably won't distinguish among fragment identifiers.

30. Single-page vs Multi-page • The best route for you will depend on what you are trying to do. • Normally, there is a reduced-page option that keeps the advantages of automatic history and bookmarking, but adds some of the advantages of a single page design.

31. Back to the process… In order to make the developer life easier, we introduce a heuristic which helps the developer while partitioning the web application into pages.

32. Sample case

33. The curtain rises! Finally, the Orchestration Designer validates the Orchestration Model.

34. Down to code What does this activity involve?

35. Google Web Toolkit (GWT) • GWT is an open source Java software development framework • Main features: • Ajax applications can be thoroughly coded in Java without resorting to JavaScript. • When the application is deployed, the GWT compiler translates the Java application to browser compliant JavaScript and HTML

36. receives events notifications, • determines the correct destinations, • and routes the events to the correct destinations. Supporting IDs in GWTThe Message Broker pattern By introducing the Subscriber role, widgets can be notified of events. The role Publisher allows widgets to propagate events.

37. If the Orchestral Widget has outgoing transitions stereotype as “SignalBroadcast” then the corresponding class implements the interface “Publisher”. The transition trigger involves the corresponding Java class has to implement a certain listener. dfd If the signal does not exist, the transition action is mapped to a Java class that implements the interface Signal. The transition guard becomes an “if” statement inside the corresponding method. A signal instance is created. In order to propagate the signal, the Message Broker instance is obtained. Values are given to signal’s attributes. And finally, the signal is published.

38. Conclusions • Desktop-like interaction support is one of the hallmarks of RIA • This paper proposes the introduction of the Orchestration Model in existing web methods to face interactive-rich RIA. • Interactions are captured through Interaction Dependencies (IDs) • State machines are used to formalise IDs • GWT is used as Ajax platform • Process wise, web development is supported as an MDD process • Ecore and UML for meta-models • QVT and MOFScript as the transformation languages

39. The end Thanks for your attention! Questions?