Facing Interaction-Rich RIAs: the Orchestration Model

Facing Interaction-Rich RIAs: the Orchestration Model

Sandy Pérez1, Oscar Díaz1, Santiago Meliá2 and Jaime Gómez2

1ONEKIN Research Group 2IWAD GroupUniversity of the Basque Country University of AlicanteSan Sebastián (Spain) Alicante (Spain)

The 8th International Conference on Web EngineeringJuly 16th, 2008

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


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


Sample case. Conceptual model

Indicates the main entities and relationships found in the application domain.


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.


Sample case. Presentation model


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


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).


Sample case. Orchestration model


The process using SPEM notation

OO-H Designer Model2ModelTransformer

UI DesignerOrchestration

Designer

Define OO-H Conceptual Model

Define OO-H Navigational

Model

<<PIMToPSM>>Nav2Pres Presentation

Model skeleton

OM skeleton

OO-H Conceptual

Model

<<PIMToPSM>> Pres&Nav2Orch

PresentationModel

OM + IDAdd interaction dependencies

DefineComplete

Presentation Model

OO-H Navigation

Model

Model2TextTransformer

Rich Internet application

<<PSMToCode>>GWT Client side

<<PIMToCode>>GWT Server side

<<WorkDefinition>>“Model-Driven Development Process for RIA”

Add pagesOM + ID + pages

Validate Orchestration

Model

Orchestration model

AutomaticManual

Orchestration model


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.


The curtain rises!



Designer



Model


Model skeleton

OM skeleton

OO-H Conceptual

Model


PresentationModel


DefineComplete

Presentation Model

OO-H Navigation

Model








Model

Orchestration model

AutomaticManual

Orchestration model

What does this model-to-model transformation do?




The curtain rises!



Designer



Model


Model skeleton

OM skeleton

OO-H Conceptual

Model


PresentationModel


DefineComplete

Presentation Model

OO-H Navigation

Model








Model

Orchestration model

AutomaticManual

Orchestration model

What does this activity involve?


Sample case

‘MailList’ Widget

‘MailDetails’ Widget


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


Capturing the ID

if an e-mail in the MailList is selected then


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


• 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


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.


The curtain rises!



Designer



Model


Model skeleton

OM skeleton

OO-H Conceptual

Model


PresentationModel


DefineComplete

Presentation Model

OO-H Navigation

Model








Model

Orchestration model

AutomaticManual

Orchestration model



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.


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


Guidelines principles?

Single-page style gives better results…• more interactive and responsive web

applications• better user satisfaction

but…• harder development.


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


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


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


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.


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.


Back to the process…



Designer



Model


Model skeleton

OM skeleton

OO-H Conceptual

Model


PresentationModel


DefineComplete

Presentation Model

OO-H Navigation

Model








Model

Orchestration model

AutomaticManual

Orchestration model

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


Sample case

Orchestration model


The curtain rises!



Designer



Model


Model skeleton

OM skeleton

OO-H Conceptual

Model


PresentationModel


DefineComplete

Presentation Model

OO-H Navigation

Model








Model

Orchestration model

AutomaticManual

Orchestration model

Finally, the Orchestration Designer validates the Orchestration Model.


Down to code



Designer



Model


Model skeleton

OM skeleton

OO-H Conceptual

Model


PresentationModel


DefineComplete

Presentation Model

OO-H Navigation

Model








Model

Orchestration model

AutomaticManual

Orchestration model



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


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.


dfdIf 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.


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


The end

Thanks for your attention!

Questions?

Documents

Facing Interaction-Rich RIAs: the Orchestration Model