Presentation is loading. Please wait.

Presentation is loading. Please wait.

Facing Interaction-Rich RIAs: the Orchestration Model Sandy Pérez 1, Oscar Díaz 1, Santiago Meliá 2 and Jaime Gómez 2 1 ONEKIN Research Group 2 IWAD Group.

Similar presentations


Presentation on theme: "Facing Interaction-Rich RIAs: the Orchestration Model Sandy Pérez 1, Oscar Díaz 1, Santiago Meliá 2 and Jaime Gómez 2 1 ONEKIN Research Group 2 IWAD Group."— Presentation transcript:

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

2 S. Pérez, O. Díaz, S. Meliá & J. Gómez 2 Outline  An MDD process for RIAs  Obtaining the Orchestration Model  Down to code  Conclusions

3 S. Pérez, O. Díaz, S. Meliá & J. Gómez 3 An MDD process for RIAs  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

4 S. Pérez, O. Díaz, S. Meliá & J. Gómez 4 Sample case. Conceptual model  Indicates the main entities and relationships found in the application domain.

5 S. Pérez, O. Díaz, S. Meliá & J. Gómez 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 S. Pérez, O. Díaz, S. Meliá & J. Gómez 6 Sample case. Presentation model

7 S. Pérez, O. Díaz, S. Meliá & J. Gómez 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 S. Pérez, O. Díaz, S. Meliá & J. Gómez 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 S. Pérez, O. Díaz, S. Meliá & J. Gómez 9 Sample case. Orchestration model

10 S. Pérez, O. Díaz, S. Meliá & J. Gómez 10 The process using SPEM notation

11 S. Pérez, O. Díaz, S. Meliá & J. Gómez 11 Obtaining the orchestration model 1.A skeleton is first automatically obtained from  the navigational model  the presentation model 2.Interaction dependencies are manually added to this skeleton. 3.Next, the Orchestration Model is heuristically enriched with pages. 4.And finally, it is validated by the Orchestration Designer.

12 S. Pérez, O. Díaz, S. Meliá & J. Gómez 12 The curtain rises! What does this model-to-model transformation do?

13 S. Pérez, O. Díaz, S. Meliá & J. Gómez 13

14 S. Pérez, O. Díaz, S. Meliá & J. Gómez 14

15 S. Pérez, O. Díaz, S. Meliá & J. Gómez 15 The curtain rises! What does this activity involve?

16 S. Pérez, O. Díaz, S. Meliá & J. Gómez 16 Sample case ‘MailList’ Widget ‘MailDetails’ Widget

17 S. Pérez, O. Díaz, S. Meliá & J. Gómez 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 S. Pérez, O. Díaz, S. Meliá & J. Gómez 18 Capturing the ID  if an e-mail in the MailList is selected then

19 S. Pérez, O. Díaz, S. Meliá & J. Gómez 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 S. Pérez, O. Díaz, S. Meliá & J. Gómez 20 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. Orchestral states

21 S. Pérez, O. Díaz, S. Meliá & J. Gómez 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 S. Pérez, O. Díaz, S. Meliá & J. Gómez 22 The curtain rises! What does this activity involve?

23 S. Pérez, O. Díaz, S. Meliá & J. Gómez 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 S. Pérez, O. Díaz, S. Meliá & J. Gómez 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 S. Pérez, O. Díaz, S. Meliá & J. Gómez 25 Guidelines principles?  Single-page style gives better results… more interactive and responsive web applications better user satisfaction  but… harder development.

26 S. Pérez, O. Díaz, S. Meliá & J. Gómez 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 S. Pérez, O. Díaz, S. Meliá & J. Gómez 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 S. Pérez, O. Díaz, S. Meliá & J. Gómez 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 S. Pérez, O. Díaz, S. Meliá & J. Gómez 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 S. Pérez, O. Díaz, S. Meliá & J. Gómez 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 S. Pérez, O. Díaz, S. Meliá & J. Gómez 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 S. Pérez, O. Díaz, S. Meliá & J. Gómez 32 Sample case

33 S. Pérez, O. Díaz, S. Meliá & J. Gómez 33 The curtain rises! Finally, the Orchestration Designer validates the Orchestration Model.

34 S. Pérez, O. Díaz, S. Meliá & J. Gómez 34 Down to code What does this activity involve?

35 S. Pérez, O. Díaz, S. Meliá & J. Gómez 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 S. Pérez, O. Díaz, S. Meliá & J. Gómez 36 Supporting IDs in GWT The Message Broker pattern receives events notifications, determines the correct destinations, and routes the events to the correct destinations. By introducing the Subscriber role, widgets can be notified of events. The role Publisher allows widgets to propagate events.

37 S. Pérez, O. Díaz, S. Meliá & J. Gómez 37 dfd 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. The transition guard becomes an “if” statement inside the corresponding method. If the signal does not exist, the transition action is mapped to a Java class that implements the interface Signal. In order to propagate the signal, the Message Broker instance is obtained. A signal instance is created. Values are given to signal’s attributes. And finally, the signal is published.

38 S. Pérez, O. Díaz, S. Meliá & J. Gómez 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 S. Pérez, O. Díaz, S. Meliá & J. Gómez 39 The end Thanks for your attention! Questions?


Download ppt "Facing Interaction-Rich RIAs: the Orchestration Model Sandy Pérez 1, Oscar Díaz 1, Santiago Meliá 2 and Jaime Gómez 2 1 ONEKIN Research Group 2 IWAD Group."

Similar presentations


Ads by Google