Posts Tagged RIA

What’s RIA anyway ?

Posted by Olivier Gérardin in RIA on 2009-04-01

RIA or Rich Internet Applications have been a buzzword for a while now, but it’s hard to find two persons who agree on what it means. It appears the word was coined by Macromedia, now Adobe, when defining the requirements for the new version of their successful browser plug-in (Flash).

Let’s break it down:

  • Application: a RIA is an Application, which doesn’t mean much except that it’s not system software. In short, it helps the user do something useful.
  • Internet: a RIA uses the Internet. Actually, not necessarily the internet, but more generally speaking a network. What this really means is that the application’s responsibilities are distributed between the user interface and one ore more servers. Exactly what is distributed, how and when is all the difference between various kinds of RIAs. What we are talking about here is presentation, validation, business logic, persistence, etc.
  • Rich: a RIA is Rich. This is probably in contrast with web 1.0 page-based applications where the interaction was limited to filling in a form and pressing submit. A RIA is Rich UI-wise, which means it has widgets that are similar to those found in desktop applications: formatted text fields, combo boxes, drop down-menus, tables with sorting and column re-ordering, to name a few.

To sum it up, a RIA is an application, with a near-desktop user interface, that requires a network to one (or more) servers for some (or all) of its functionality. This definition is voluntarily very vague, because many combinations of technology and architecture qualify as RIA.

Based on this definition however, we can refute some ideas that commonly surround RIA:

  • RIA applications require  a browser plugin: WRONG! It is true that some vendors (Adobe, Microsoft) have chosen to bypass the challenges of browser incompatibilities and poorness of native widgets by providing a plugin (Flash, Silverlight) that gives a uniform look on all (supported) platforms. But the current level of JavaScript implementation in major browsers makes it possible to implement a full-blown RIA in native JavaScript without the use of any plugin. This is even more true now that GWT is there, because GWT will take care of platform differences and let you concentrate on the programming itself. This will be even more true in the future with HTML5.
  • RIA applications are necessarily JavaScript-based: WRONG! see above…
  • A RIA application is an application that runs in a browser: WRONG! If most RIA applications run in a browser, be it in a plugin or as JavaScript, a Swing-based application launched through JNLP (WebStart) also qualifies as a RIA. And even applications that normally run in a browser can be packaged in such a way that they appear not to (see Prism for example)
  • A RIA application only works online: WRONG! This might be true for most RIAs, but it is not a requirement. A RIA application can have an online mode where it communicates with a server, and an offline mode where you work locally, and your work is later synchronized with the server as soon as it becomes available. Google Gears is one of the ways this can be accomplished. And Google Docs is one of the examples of an online/offline RIA.
  • A RIA application cannot be integrated into the OS like a native application: WRONG! Tools exist to make any web application (not even necessarily RIA) look like a native application to the user. For example, Prism from Mozilla will let you create an icon for any web page and launch it in its own window, without any browser decoration. Google Chrome will let you do the same right from the browser itself. Adobe Air goes further and provides all the missing “glue” between RIAs (Flex and JavaScript) and the OS, including creating a native shortcut, but also letting the application interact with the OS in ways usually reserved for native apps like drag&drop, access to local storage, etc.
  • RIA applications are difficult to develop and debug: WRONG! plugin-based RIAs rely on vendor IDEs that let you develop just like you would develop a desktop app. For JavaScript-based RIAs, GWT lets you develop and debug your application in pure Java, and takes care of translating it to JavaScript for deployment.

All this points to a direction: the line between RIAs and classic desktop application is getting thinner every day. Technologies used for one can now be used for the other, thanks to frameworks such as Adobe Air or GWT. And as a consequence, the user eventually will not be able to tell one from the other. And probably he won’t even care.

, , , , , , , , , ,

No Comments

TheServerSide Java Symposium – jour 1

Posted by Olivier Gérardin in Java on 2008-06-18

Le TSSJS Europe se tient à Prague cette année, du 18 au 20 juin. Les thèmes majeurs proposés sont assez alléchants, jugez-en:

  • les frameworks web (spring, struts, JSF)
  • les nouveaux langages de l’écosystème java (groovy/grails, scala, jruby)
  • les nouvelles versions de spécs (JEE 6, EJB 3.1, JPA 2.0)
  • concurrence, performance, scalabilité
  • SOA

A part quelques événements communs (keynotes, etc) il y a en général 3 sessions simultanées, ce qui rend parfois le choix cruel…

Le premier keynote “Supporting RIA space” est délivré par Stephan Janssen, le fondateur et président du BeJUG, fondateur de JavaPolis et de parleys.com, un site qui met en ligne des conférences filmées avec les slides synchronisées. C’est ce site qui lui servira de support pour tester différentes technologies RIA dont il nous fera part…

Premier point délicat: définir une application RIA… Pour la petite histoire le mot a parait-il été inventé par Macromedia, et donc absorbé par Adobe. Mais ça ne nous avance pas. Un application RIA c’est une application Riche (mais pas tout à fait comme une application desktop), et qui utilise Internet (mais pas forcément tout le temps)…

Bref l’éventail est grand, RIA encore mal cerné, et les technologies qui permettent de faire du RIA innombrables. Stephan en a retenu quelques unes et a expérimenté le portage du site parleys.com sur ces technos.

  1. le site original, HTML, rien à dire
  2. refactoring en DHTML/JavaScript avec Scriptaculous. Conclusion: il faut un doctorat en JavaScript, et la compatibilité cross-platform est un enfer… (quelle surprise!)
  3. GWT: développement et debugging agréable en Java avec les outils Java, support du bouton back, et “99% cross platform” ( un seul if/then dans tout le code). Un seul point noir est relevé par Stephan: le site n’est pas indexé correctement par Google!
  4. Flex: le résultat est extrêmement semblable à GWT, avec un peu plus d’”eye candy”, transitions animées et choses similaires. Techno mature, mais l’indexation Google est inexistante, sauf à utiliser des artifices (redirections)
  5. JavaFX: résultat sexy style Flex, avec en plus la possibilité d’utiliser le Java existant. Pas de support Mac…

Au final le site actuel est la version Flex, avec intégration AIR, mais on note bien que GWT n’a reçu que des éloges…

Deuxième conf, là il faut choisir… JSF? qui utilise encore JSF… JPA/Hibernate? déjà fait… Je reste donc dans la salle principale pour entendre Costin Leau (SpringSource) parler de “Spring Dynamic Modules“.

On le sait, Java ne gère pas les versions des classes ou le remplacement dynamique, et il est impossible à deux versions d’une même classe de coexister. OSGi fournit une solution, en définissant une notion de “module” ou “bundle”, qui est simplement un ensemble de classes, auquel s’appliquent les notions de

  • cycle de vie
  • “class space”
  • règles de visibilité
  • versionnage

Un service au sens OSGi c’est simplement une classe, un POJO qui exporte des méthodes au travers de la visibilité. Le reste est caché de l’extérieur, ce qui permet à plusieurs versions de cohabiter sans conflit. Spring 2.5 sera OSGi-compliant et intègrera la notion de bundle. On pourra également réagir aux événements qui affectent le cycle de vie des services (création, suppression, etc). Les dépendences OSGi sont localisées dans le contexte Spring, et non dans le code.

Au final cela semble très prometteur, reste à voir dans quelle mesure cela s’appliquera à nos développements. Annoncé également, la sortie du futur S2AP, SpringSource Application Platform… Pas plus de détails là-dessus.

Deuxième session de la matinée: monitoring, management sur la plateforme Java 6, par J-F Denise, responsable JSR 262 chez Sun.

Beaucoup de rappels sur JMX et les MBeans, l’agent JMX, l’agent remote… Depuis Java 5, l’outil JConsole est fourni avec le JDK et permet d’interroger une JVM qui tourne, y compris des MBeans. C’est une bonne chose de le rappeler, car le JDK est fourni avec beaucoup d’outils trop peu connus, car pour beaucoup l’IDE est la seule interface qui existe avec Java.

Implémenter un MBean est simple (juste une interface), mais peut poser des problèmes: si le MBean retourne un type composite sous forme d’une classe maison, il faut que le client JMX dispose de cette classe aussi dans son classpath !! Pour relaxer cette contrainte, Sun introduit les MXBeans, qui permettent de faire cela, et via un mécanisme interne, transforment les objets complexes sérialisés en des classes standard qui peuvent être lues par le client sans modification de son classpath.

Autres outils fournis avec le JDK 6: jps, jmap, jhat, jinfo… Et un nouvel outil qui ne fait pas à proprement parler du JDK: jvisualvm. C’est un outil intégré et extensible de troubleshooting, fonctionant avec des plugins, et qui regroupe les fonctionnalités éclatées dans divers outils… La RC1 est disponible depuis le 6 mai.

Avant de manger, un keynote par Nati Shalom de GigaSpaces “Getting ready for the cloud“. Il s’agit en fait de 40 minutes de marketing pendant lesquelles le message est martelé sur tous les tons: vos applications ne sont pas scalables, parce que bâties sur des silos. La solution: remplacer les silos par un “cloud”, une plateforme qui virtualise les 3 tiers habituels (middleware virtualization) et qui est la seule à pouvoir assurer le “scaling on-demand”. Et comme par hasard, GigaSpaces a un framework qui le permet. OK, le message est passé.

Déjeuner avec un lance-pierre, pas le temps de digérer on attaque l’après-midi. Eh non, après avoir erré dans les coursives, je me rends compte que la conf qui m’intéressait (Comparing Dependancy Frameworks) est annulée… J’assiste sans conviction à un case study “Using JSR-272 and Spring for a Monetary System”.

Ensuite, encore un dilemme: Holly Cummins, spécialiste des outils de diagnostic chez IBM (au style capillaire improbable), présente “Java Performance Tooling”, mais je choisis “Simplifying JEE Development with Grails” par Guillaume Laforge, project manager de Groovy.

L’idée de Grails c’est d’appliquer les principes de productivité de Ruby et Groovy, tout en s’appuyant sur les bibliothèques et infrastructures existantes (Java, Spring, Hibernate, servlet containers, etc.). Par exemple, Grails génère un WAR, qui peut être déployé tel quel sur un serveur d’applications. Grails utilise GORM, un ORM bâti sur Hibernate, WebFlow, domain-specific languages, GSP (un équivalent de JSP), supporte des plugins, et nécessite aussi peu de fichiers de configuration que possible grâce à des conventions de nommage.

La démo est impressionnante, en quelques lignes et en live Guillaume crée deux classes, les relations entre elles, les tables correspondantes, les mappings relationnels, les finders, les controleurs, l’interface web… et redéploie sans redémarrer quoi que ce soit! Est-ce que ce serait Ruby on rails, avec la scalabilité et la puissance en plus??

Conf suivante, je choisis une prés de GlassFish, par Antonio Goncalves (Paris JUG). Pas grand chose à retenir, Glassfish est prêt pour la production, scalable, clusterisable, avec une belle interface d’administration (bon tous les gouts sont dans la nature). C’est l’implémentation de référence pour Java EE 5 et 6 et il est open source.

Plus intéressant, mais on ne s’étendra pas dessus, ce qui est annoncé pour la v3: un noyau ultra léger et ultra rapide (HK2: Hundred Kbyte Kernel), modulaire, avec des modules web, EJB, JRuby, PHP, JavaScript, etc. et le support OSGi! Bref, on reviendra.

Ouf, c’est fini, une bière, remise des prix du concours GigaSpaces/OpenSpaces… je discute avec le gagnant, un Brésilien qui a réalisé un projet pour la distribution des surplus alimentaires au Brésil (avec GWT en front!), l’occasion de pratiquer mon portugais :)

Demain la suite…

, , , , , ,

No Comments