Facing Interaction-Rich RIAs: the Orchestration Model

1
Facing Interaction-Rich RIAs the Orchestration
Model
The 8th International Conference on Web
Engineering July 16th, 2008

• 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
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
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?
13
(No Transcript)
14
(No Transcript)
15
The curtain rises!
What does this activity involve?
16
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 users 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. Googles 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_appfragment_identifie
  r

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
Supporting IDs in GWTThe 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
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.
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 signals 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?