Web Oriented Architecture

Un article sur ce qu’est le Web 2 aujourd’hui

Plutot que de donner de simples exemples, voici quelques pointeurs vers les API qui servent de modèles :

API REST :

• de Yahoo
• de Ebay
• de Amazon (exemple S3)
  
• de google

A ceux qui repondent que ces sociétés ne sont pas des éditeurs … je dirais :

• est-ce que vous ne devriez justement pas vous demander pourquoi ceux qui y arrivent n’utilisent pas les recommandations des éditeurs ?
• est-ce que le Web 2 a été poussé par un éditeur ?
• est-ce que justement les plus en avant en terme de technologie sont encore les editeurs ou les sites web ?
• les bons développeurs ont révé d’aller chez IBM, puis Microsoft, … et maintenant c’est google. On se deplace de l’édition de logiciel a l’édition de services. Ce changement de paradigme est violent car les questions ne se posent plus de la même manière. La question n’est pas comment vendre de nouveaux produits rendant le client toujours plus dépendant mais comment le rendre dépendants de services. Il faut donc que les services soient :
• simples a utiliser (oubliez les webservices et les schemas xml de 2000 elements),
• disponibles aux internautes (c’est eux qui font le marché et non les entreprises !, on en reparlera…),
• performants,
• taux de disponibilité élevé (vous avez déjà vu google planté ?)
• dépendants entre eux pour le bénéfice de l’utilisateur (par exemple gmail, calander et google maps sont liés, si vous m’envoyez un mail avec ‘lunch at 34 rue des exemples’ et bien ca va ajouter un rendez vous dans mon calendrier et un lien vers google maps sur le lieu !). La plupart des bons sites font des liens vers d’autres services. Ca rend plus dépendant l’utilisateur et ca permet de lui fournir de nombreux services plus rapidement. Comme il est difficile de fournir tous les services nécessaires, les éditeurs de services multiplient les liens entre eux (netvibes qui passe par writer pour la saisie de texte…). D’ou une autre conclusion, si vous voulez que vos services soient consommés par d’autres sociétés, faites les simples !
• Une version gratuite doit etre disponible (il faut pouvoir essayer sans trop de contraintes !)

Luis Nauges (qui a inventé le terme bureautique) avait fait un premier article assez soft sur sa vison SOA vs Mashup :

L’une des recommandations les plus fortes proposées dans le “dialoblog®”(1) ci-dessus est de … court-circuiter les DSI et d’aller vendre des solutions MashUp simples directement aux managers opérationnels ! C’est un signal fort, et inquiétant.
Il me rappelle des souvenirs, au début des années 90, de DSI, bien sur minoritaires, qui ne voulaient pas entendre parler de PC dans leur entreprise, objets tout juste bon pour s’amuser chez soi.

Encore une fois il faut noter un écart qui se creuse entre les utilisateurs et les DSI. Le choc sera plus violent cette fois car les français ont accès au haut débit et peuvent donc facilement constater l’écart entre leurs applications et ce qu’ils ont sur le web, la facilité avec laquelle ils réalisent des blogs riches, la richesse de google mail et calendar intégrés a google maps, des moteurs de recherches efficaces…

il recidive après être allé au symposium SOA organisé par l’Oasis que je ne peux que vous inviter à lire en entier !

Pour ceux qui se demandent quelles sont les servives WOA les plus utilisées :

Un coup d’oeil sur les programmations web

Rendons au gartner ce qui appartient au gartner !

Whoa! We’ve got WOA

Posted By: Whit Andrews, Vice President, Gartner Research

After emerging from the research cave, Nick presented the newest acronym from the acronymizer: WOA. Web-Oriented Architectures represents SOA plus the Web plus Representational State Transfer, often called REST. We don’t turn on the acronymizer any more often than we absolutely must. It’s loud, and it catches entire analysts in its jaws and crunches them up like Mars bars. WOA is necessary, Nick and his colleagues argued, because:

It’s a descriptive term for a subset of SOA. (People who are doing WOA are doing SOA. People doing SOA may or may not be doing WOA.)

It’s simple.
[...]

Un bon developpeur (qui ecrit un livre de référence sur le thème ) a essayé de lancer un défi sur internet consistant a développer en java des appels a des webservices disponibles sur internet en utilisant des outils appropriés (JAX-WS). Pour que se soit facile, il faudra faire appel aux webservices d’Amazon, Google, Ebay … donc bien documentés et fait par des professionnels.

Facile n’est ce pas ?

Lisez d’abord ce compte rendu avant d’y aller les yeux fermés.
Le service qui marche a généré a lui tout seul pret de 700 classes java ! Donc avant de faire des appels en masse et d’augmenter le réseau, il faudra penser a optimiser un peu tout ca…
pour les autres, il a laissé tombé. Laisserez vous des débutants faire ?

Un nouvel article de Dion Hinchcliffe “Does Java EE 5 getting REST mean WOA will break out?” il explique pourquoi REST est plus interessant que SOAP.

The bottom line, if my job was to make sure the Web services for my Enterprise Web 2.0 app were usable by the most number of people (especially without knowing their toolset in advance), had to highly maintainable, be easy as possible to consume, scalable, and took advantage of existing infrastructure investment, then REST/WOA is at the top of my list.

La pression sur les éditeurs monte petit à petit, vous trouverez d’ailleurs ici l’annonce du support du style REST pour les services dans Java 5 ici :

Sometimes seen as an alternative to the more common SOAP and WSDL Web services, REST offers a simpler, albeit not as heavy-duty, method for ad hoc Web services, according to Sun officials at the JavaOne conference in San Francisco on Thursday afternoon.

It simplifies the way in which a developer has to work with calls back and forth between remote systems,” said Dan Roberts, Sun director of developer tools marketing.

HP arrive dans ses labos aux mêmes conclusions, cette synthèse explique bien tous les problèmes concrets que pose l’approche SOAP :

This may seem somewhat ruthless: to deny the right to
write web services to developers who are and wish to remain
ignorant of XML. However, we have to ask: if they do not
want to know XML, why are they writing web services? If the
developers want to use a less portable, more brittle, remote
method invocation system, they would be better off using a
stable technology such as Java RMI or CORBA.

N’ayez plus peur de faire du REST ou du WOA ! Les éditeurs le disent que c’est plus simple !

J’ai trouvé sur l’execellent blog d’Aurelien Pelletier un texte sur la norme WSI.
Il s’agit d’une norme qui doit facilier l’intégration de WebServices.

Premier problème, je croyais naivement que justement les webservices permettaient de faire l’intégration sans soucis. Pourquoi donc une norme sur le sujet ?

Maintenant heureusement pour moi, les éditeurs toujours prets a m’aider ont planché une une nouvelle norme pour assurer l’interopérabilité entre webservices (travail facile vu que ca devrait déjà marcher tout seul, n’est-ce pas ?).
Comme moi vous n’allez pas avoir le temps de tout lire, on se limitera donc aux principes chapitre 1.1 :

No guarantee of interoperability

It is impossible to completely guarantee the interoperability of a particular service. However, the Profile does address the most common problems that implementation experience has revealed to date.

Future compatibility

When possible, the Profile aligns its requirements with in-progress revisions to the specifications it references (e.g., SOAP 1.2, WSDL 1.2). This aids implementers by enabling a graceful transition, and assures that WS-I does not ‘fork’ from these efforts. When the Profile cannot address an issue in a specification it references, this information is communicated to the appropriate body to assure its consideration.

Compatibility with deployed services

Backwards compatibility with deployed Web services is not a goal for the Profile, but due consideration is given to it; the Profile does not introduce a change to the requirements of a referenced specification unless doing so addresses specific interoperability issues.

Focus on interoperability

Although there are potentially a number of inconsistencies and design flaws in the referenced specifications, the Profile only addresses those that affect interoperability.

Avouez que c’est fort. C’est la première fois qu’un protocole ne marche pas avec les versions précédantes, essaye de marcher avec les courrantes et peut etre avec les suivantes… Si vous trouvez des équivalents qui ont fonctionné, prevennez !

Quel est l’interet d’une norme :

• Qui nécessite d’avoir les dernières versions d’outils pour communiquer (et impose donc de mettre a jour de nombreuses applications pour faire de l’interopérable …) ou bien sur d’avoir un ESB pour gérer cette complexitée qui elle est gratuite
• Qui est difficile a utiliser pour des particuliers (qui ne sont pas payer pour utiliser des outils de développements lourds) et donc qui font des choses simples ou ne les font pas. Vu la complexité, ils ne s’envent pas (90% des services utilisés chez Amazon sont REST et non Webservices)
• Qui oblige ceux qui fournissent des services a avoir des logiciels qui gèrent toutes les piles et versions pour permettre a leurs clients de les consommer ?

Il s’agit la de limites importantes a ces normes, est-ce bien raisonnable ?
Il faut rappeler que xml/http suffisent et en plus ca fonctionne et sécurisable (https) et on peut même avoir un annuaire logique (URI).

Qu’il y a-t-il derrière WOA ?

Le style d’architecture REST bien sur !

Vous trouverez une synthèse du style REST sur le site de Jean-Paul Figer ou sur wikipedia

La référence sur REST étant le site de son créateur, architecte d’Apache : Roy fieldings.

A tous ceux qui repondent que ce style d’architecture est confidentiel alors que SOA est partout, je repondrais : allez sur le Web ! Google, Amazon, ebay, Paypal c’est a dire les principaux sites d’internet se rapprochent du style REST. Donc des millions d’utilisateurs utilisent le style REST sans le savoir.

Pourquoi le protocole qui remplace progressivement tous les autres est-il http ? l’informatique a crée de nombreux protocoles alors pourquoi celui la en particulier ?
Il y a pourtant quelques différences :

1. la notion d’URI, ou comment rendre inteligible les adresses permettant de designer des ressources ou qu’elles soient (adressage réseau via les DNS), et dans un arbre logique extensible.
2. simple et comprehensible : essayer de lire des trames, vous verez que c’est du texte lisible … cette simplicité l’a rendu universel car facilement implémentable (un serveur web peut d’ailleurs s’ecrire en quelques dizaines de lignes de code en java…)
3. utilise la capacité des clients (browsers web…) a mettre en cache les éléments qui ne varient pas (très peu de protocole ont en natif cette capacité, se sont les applications qui les developpement et en général plutot mal !).
4. peut véhiculer tout type d’information : pages html,xhtml, images, video, flah…

Ces différences ont assurer un succes important au protocole Http car ses caractéristiques l’ont rendu performant (et c’était vital au départ lorsque les communications avaient des débits faibles et maintenant car le nombre d’utilisateur est vertigineux !).

Tous les sites majeurs d’internet exploient au maximum ces possibilités en particulier les caches des browsers Web.

Maintenant prennons la plupart des applications web situés dans les systèmes d’informations …
Elles sont lentes, peu ergonomiques, peu souples.
Pourquoi donc ?

• Les uri ne sont pas utilisées

• elles sont même souvent masquées aux utilisateurs tellement elles peuvent faire peur). Elles n’apportent généralement aucunes informations car elles sont laissées au mains des informatitiens. Cette url est inutile : http://66.serveur.net/TYG/servletload?id=23&sessid=kij alors que celle -ci http://achats.entreprise.net/DemandeAchat/CR43/ permet a l’utilisateur de savoir ou il est, d’aller directement sur les documents lorsqu’il peut intuiter le chemin et peut être même se faire des petits outils pour se faciliter la tâche et l’amencer directement sur les bonnes pages.
• Les developpeurs pourraient également en tirer partie en permettant de faire des liens entre applications dans les couches IHM via des URI logiques. Comme les uri sont des principes incompris, il est souvent interdit de faire des liens entre applications car les liens entre IHM sont interdits ! L’essence même du Web !

• Complexité à tous les étages.La plupart du temps il n’y a pas de services qui puissent être consommé par de simples utilisateurs. Seuls les développeurs le peuvent. C’est fort dommage car avec des services simples et des outils simples il est possible de se faciliter la vie. Par exemple une url qui a comme résultat des données xml peut être consommée directement dans Excel … il suffit de faire Fichier-Ouvrir- mettre l’url. C’est simple et ca peut leur eviter des resaisies… Les utilisateurs avancés pourront faire des usages encore plus interessants ! Par exemple sur ce site parlant pétrole, un utilisateur très avancé a mis a disposition une petite application pour afficher en presque temps réel le cours du pétrole dans la barre windows. Il ne faut pas sous estimer les capacités des utilisateurs !

• la contre performance s’explique par la complexité … mais aussi par l’absence de l’utilisation des caches. Il est exeptionnel de trouver une application qui en fasse usage hormis pour les logos ou les fichiers javascript. Pourtant il est possible d’améliorer drastiquement les performances. Et contrairement a ce que pensent habituellement les développeurs et architectes, cache ne veut pas dire information potentiellement non a jour car elles ne se mettraient a jour que toutes les 5 minutes… non, il est possible de ne générer une page et de la renvoyer au browser que si l’information a changée… Cela necessite juste un peu de connaissance sur le fonctionnement du protocole.

Le web reste mal intégré dans le mode de pensée des informatitiens qui continuent d’utiliser de vieux reflexes, ces applications ne profitent pas du Web. C’est pourquoi in fine elles coutent souvent plus cheres que les anciennes.
D’ailleurs savez vous comment reperer un site d’une entreprise institutionnelle sur le Web automatiquement ? se sont les sites qui ne contiennent pas de liens vers d’autres sites…

I recently had the pleasure of watching Nick Gall give his take on
something he describes as Web-Oriented Architecture or WOA. There are a lot of ways to view Service-Oriented Architecture (SOA) and this particular lightweight version of SOA is well worth watching. This is because WOA is more of an emerging best practice from the battle-hardened folks building software on the Web than it is from ivory tower architects or the analyst group notebook. This always lends an idea more credence in my book.

La suite est ici