Web Oriented Architecture

Toujours Dion Hinchcliffe sur son blog qui montre l’&volution comparée deq différents termes utilisées sur le web :
http://web2.wsj2.com/is_web_20_emerging_from_adolescence.htm

je vais y ajouter ce graphique :

php java .net webservice

Que peut-on constater ? que les webservices interessent finalement peu les développeurs et que Java a des problèmes …

Pour ceux qui se demandent ce qu’est l’architecture du Web, voici le lien http://www.w3.org/TR/webarch/

C’est un document très bref du W3C (donc ceux qui normalisent le web !) sur comment l’architecture du web a été pensé.

Comme vous pourrez le constaté, peut d’applications d’éditeurs ou de systèmes d’informations respectent ces préconisations. ca explique pourquoi ce n’est pas performant, peu ergonomique…
Cela est du au respect (plus ou moins vrai d’ailleurs) des normes mais pas du syle décrit par ce document du W3C. Cela revient in fine a essayer d’appliquer un style de construction roman a un batiment gothique. Même si le style roman a son charme il serait dangereux de faire des mélanges (l’effondrement n’est jamais très loin !). Les editeurs et informatitiens sont généralement dans le style VB.
Ils pensent avec des ecrans du type vb ou powerbuilder et essayent de l’appliquer au Web.
Aujourd’hui se sont les mêmes qui s’emparent d’Ajax car ca leur permet de reproduire des ecrans VB facilement en mode web. Regardez hotmail,yahoo mail.. c’est pensé comme les applications client lourd

C’est bien entendu exactement ce qu’il ne faut pas faire.

• D’un point de vue d’utilisateur ca m’interesse peu car les applications en client lourd fonctionnent mieux que leur pure reproduction en mode ajax (plus rapides, plus de fonctions, mode deconnecté). Le besoin multi poste n’est pas encore important a part chez les fous d’informatique.
• parce que techniquement ca amenera a la meme médiocrité : Applications non intégrables ! On n’oubli que l’uri a permis a des millions d’applications d’être intégrées entre elles grâces a des uri et en couplage lache. L’intégration entre application en client lourd reste une tache au mieux delicate, souvent impossible, et rarement maintenable. Je vais prendre un exemple fort simple : générer des documents word pour chaque client dont le score est supérieur a 100 (la liste des clients est dans excel) et ensuite mettre a jour un indicateur sur le client dans peoplesoft CRM (prennons une ancienne version en client lourd …) et bien sur ajouter une tache dans mon agenda outlook pour relancer dans 15j si je n’ai pas de reponses… opérations qui semblent assez simples, il vous faudra au mieux des heures en connaissance les outils et API pour y arriver ! c’est très loin d’etre simple et sensible aux evolutions de versions (changement de signatures des méthodes des activex !).
  Prennons le même exemple car les gens qui font du web proprement :
• je peux utiliser les sites comme fournisseurs de services (mon agenda fournit des fils Atom, iCal et permet des mises a jour via Http-xml-Atom).
• Je peux aussi pointer directement vers des éléments (un mail, une tache de mon agenda)
• Ces mêmes applications ont des liens vers les autres (google calendar pointe vers google maps …). Toutes les pages peuvent être facilement redirigez des unes aux autres. Ceux qui font du vb vont creer des sessions … il sera donc impossible d’accéder directement aux pages que l’on veut utiliser (comment pointer sur mon mail s’il faut d’abord passer un ecran de portail ?). C’est la même chose avec les applications métiers. La réutilisation n’est possible qu’avec des URI et l’absence de sessions.

Ajax ne doit en ancun cas etre vu comme un moyen de faire du Web car il tue toute reutilisation !

Le darwinisme d’applique a l’informatique. Les tilisateurs selectionnent les meilleures applications. Hors c’est l’architecture du Web qui a gagnée ! Pourquoi ne pas la suivre plutot que de dépenser une energie considérable a faire du style roman dans du gothique (avec les problèmes pour mettre des vitraux sur des murs roman, …).
Pourquoi ne pas choisir la facilité ? pour une fois !
Le metier, les contraintes juridiques… sont déjà assez compliqués comme ca !

un manager chez microsoft a fait un papier très interessant sur le developpement de vista : http://blogs.msdn.com/philipsu/archive/2006/06/14/631438.aspx

Quels éléments peut-on en tirer ?

• mauvaise organisation du code
• mauvaise organisation des équipes

Les 2 sont d’ailleurs liés dans 99% des cas…

mais revenons sur le code. Les remarques faites sont trop d’API difficiles a connaitre et utiliser.
Tous les composants sont dépendants les uns des autres par des couplages forts. Les gens de Microsoft ont fait preuve d’une compétence incroyable pour arriver a produire des OS dans ses conditions.

Quelles sont les erreurs ?

• tout mettre dans l’OS avec coupage. Integrer IE est une erreur mais c’est loin d’etre la seule application !
• de pas mettre en oeuvre d’API plus simples. Vista aurrait pu permettre aux developpeurs d’utiliser des URI a la place des API pour acceder au registre, bureau … comme le suggère Jean-Pau Figer sur son site. Par exemple pour afficher une cle du registre on devrait pouvoir faire http://localhost/register/computer/os/desktop/backgroundcolor ou au pire register:// … ca permet a minima de permettre de faire des renvoi depuis des mails a tout element du systeme. Combien de doc decrivent un processus pour aller cocher une case (cliquer sur …). Il faut penser quelques crans plus loin cet exemple pour que cette remarque prenne tout son sens. Sur les URI sur le registre renvoient directement du xml … quel serait l’interet de l’API d’acces au registre ? même un simple utilisateur pourrait aller lire des elements du registre et faire facilement des pages pour le mettre a jour. Un script du type wput http://localhost/register/computer/os/desktop/backgroundcolor blue devrait suffire pour mettre a jour un element du registre par script. Si tous les elements étaient accessibles par service, seuls microsoft et les editeurs d’outils systemes aurraient besoin de connaitre les API internes (pour faire des defragmenteurs de disques…) mais pas les developpeurs d’applicatiions. Donnons quelques autres exemples, http://localhost/process/ pourrait renvoyer la liste des processus en xml (avec un stylesheet pour que l’utilisateur ait une page html). Ca devient facile a une application d’obtenir la liste des processus, n’est ce pas ?

Le couplage serait ainsi beaucoup plus lache entre les divers composants. Plus fort, ils pourraient même developper des morceaux importants d’applications sans que les composants nécessaires soient disponibles (il n’est pas très dur de fiare un bouchon d’un service REST, mettre un fichier xml derriere un serveur web suffit la plupart du temps). S’y prendre de cette manière c’est permettre a des equipes d’etre nettement moins dépendances les unes et des autres et donc de diminuer la synchronisation et donc le management.
Bien sur tout n’est pas reductible facilement a des URI … mais le faire permet de faire de grands pas en avant en matière de découplage et d’évolutivité, de prise en main des API (si vous comprennez qu’une URI qui affiche quelque chose du système et que systématiquement vous savez que le conteun de la page est en xml, vous devenez capable d’utiliser des centaines, milliers ? de services. Ce n’est pas le cas des API actuelles…).

Le systeme ainsi plus évolutif.

• En effet rajouter un champ optionnel a une API necessite souvent de créer une nouvelle fonction (et microsoft doit continuer de maintenir l’ancienne) car la signature change (il faut aussi changer le code des appelants… autant dire que vous maintenez les fonctions longtemps !*)). Au contraire de REST ou pour rajouter un champ, il suffit de le traiter comme optionnel. La signature du service ne change pas. Bien entendu des restructurations profondent peuvent necessité des ruptures, mais en attendant rajouter un champ ne necessite pas de lancer un programme d’evolution des API sur 5 ans.
• La sécurité sera probablement plus simple car traitée dés le serveur Web. Il suffit de filtrer http://localhost/computer/ nécessite d’avoir les droits administrateur pour les verbes http get,put,post,delete (par exemple). Simple a faire ! Qui a déjà essayé de jouer avec les ACL dans du code ? normal, c’est d’une telle complexité que personne ne s’en sert.

Le remplacant de Bill a encore du boulot !

Dion Hinchcliffe est intarissable : http://blogs.zdnet.com/Hinchcliffe/?p=49

ZDNet blog colleague Joe McKendrick beat me to the punch earlier this week with an excellent analysis of the fascinating ramifications of IBM’s recent statements at the New York PHP Conference aimed at mainstreaming mashup and Web 2.0 technologies.

IBM a un atout important : sa capacité a récupérer toute technologie qui emerge ! S’ils s’interessent au style WOA, au mash-up c’est que ca a toute les chances d’etre un mouvement de fond. Sa faiblesse c’est que le résultat reste de l’informatique ‘lourde’. Tout le contraire de WOA et mash-up. Seront-ils faire leur révolution ?

http://www.la-grange.net/2005/05/rest/index.html

Dans plusieurs papiers j’avais parlé du Gartner mais sans documents (leurs etudes sont payantes). Un document existe maintenant.

The Principles of Web-Oriented Architecture

dans le 01 de cette semaine (numéro 1863) :

Internet aime la simplicité. Trop complexes et inadaptés aux aléas du Web, les services SOAP, conçus pour les échanges entre applications, sont boudés par les entreprises. Qui leur préfèrent Rest plus facile à mettre en œuvre. ‘l’architecture Rest existe depuis des années’, constate Patrick Chanezon, expert chez Google. ‘Mais elle avait du mal à décoller car aucun standard ne précisait jusqu’à présent comment utiliser les verbes http pour échanger des données’. Atom pourrait jouer ce rôle. Pressenti comme le successeur de RSS , ce format d’échange est soutenu par Google, Microsoft, SAP et d’autres grands noms de l’informatique.

le style REST/WOA débarque dans la presse… mais c’est finalement assez normal.
Quel est le type de service le plus utilisé aujourd’hui par des millions d’utilisateurs et des centaines de milliers de sites ? le style REST avec Atom …
Le même résultat était possible avec des webservices mais la simplicité c’est imposée auprès des utilisateurs qui n’entendent rien aux débats des éditeurs…