Quelle architecture adopter pour créer les nouvelles applications traversant plusieurs entreprises, plusieurs systèmes d’informations et largement ouvert aux clients et aux partenaires ?

Cette problématique fut déjà posée aux architectes dans le passé, certes à moindre échelle qu’aujourd’hui. La réponse fut successivement DCE, CORBA et DCOM, EJB et enfin SOAP/WS-*.

DCE a introduit la transparence dans l’invocation de procédure à distance, aussi appelée RPC (Remote Procedure Call). Des efforts titanesques ont été déployés, en vain, pour rendre l’appel d’une procédure distante complètement transparente au développeur. Aucun autre acteur (utilisateur, réseau, exploitation, etc.) n’a tiré bénéfice de cette transparence.

CORBA a introduit la notion d’invocation polymorphe inter-galactique. Des efforts cyclopéens ont été déployés pour spécifier, sur papier, des mécanismes de propagation d’appels de méthodes entre objets distribués dans des langages hétérogènes. Aucune implémentation de CORBA n’a pu se mettre à la hauteur des ambitions folles spécifiées sur papier.

EJB, feu modèle de composants, est une initiative qui n’a pas tiré toutes les conséquences des erreurs du passé. En effet, EJB 1.0 et 2.0 furent des tentatives de réimplémenter « CORBA » en mono langage à savoir Java. L’échec fut patent. D’ailleurs, la nouvelle version des EJB, 3.0, est un reniement total des idées fondatrices des EJB 1.0 et 2.0. Les concepts de CORBA et DCE sont définitivement enterrées par toute une communauté.

SOAP est une envie faible, un sursaut d’orgueil de la génération des années 80 de spécifier à son tour une architecture technique qui reprenne tout de CORBA et DCE et aille plus loin en terme de couplage temporel des invocations. SOAP est un standard d’invocation de messages complètement indépendant du protocole de transport et des formats de description du message lui même. Pour autant, les seules implémentations opérationnelles se font sur HTTP, uniquement. Les tentatives de normalisation appelées WS-*, pour la gestion de la sécurité, la garantie de livraison, du transactionnel, et autres contraintes posées par les middlewares connectés, ne sont que les dernières extravagances d’une génération d’architectes, certes ingénieuse et intelligente, mais trop vieille pour faire la culbute culturelle nécessaire pour comprendre le WEB et éviter de faire du vieux avec du neuf.

Alors comment créer une architecture distribuée à même de s’interfacer avec des systèmes d’information complètement hétérogènes ?

En marge de ces tentatives, un modèle d’architecture peu porté par les éditeurs a evolué discrètement jusqu’à devenir l’architecture technique la plus massivement déployée à ce jour: le Web. Tandis qu’à l’arrière des firewalls des entreprises, le Web est toujours très peu représenté, les systèmes d’information s’appuyant toujours sur des modèles qui ont bien du mal à satisfaire leurs promesses.

Le Web, l’architecture technique universelle … et qui marche !

Le mouvement de la WOA (pour Web Oriented Architecture) définit les bases d’une architecture universelle reposant sur le Web. Mais comment parler de WOA alors que l’on est encore tout juste en train de comprendre ce qu’est la SOA ? En fait, la WOA se positionne directement dans l’esprit des architectures SOA, mais propose en plus un modèle d’implémentation technique basé sur le Web.

Concrètement, la WOA définit un modèle d’architecture technique distribuée et interopérable dans lequel :

• les fonctionnalités sont présentées sous forme de ressources, identifiées de manière unique par une URI (Uniform Resource Identifier, premier postulat du Web);
• les ressources sont manipulées grâce à une interface uniforme spécifiée par l’unique protocole sur lequel s’appuie la WOA : HTTP (HyperText Transfer Protocol, deuxième postulat);
• le contrat de service des ressources publiées, est implicite car défini par leur représentation échangée entre les différents acteurs. Cette représentation peut par exemple s’appuyer sur un langage XML ;
• enfin, la WOA intègre tous les principes essentiels des architectures SOA, même si certains peuvent apparaitre de manière détournée (notamment le fait de définir un contrat de service de manière implicite).

La WOA propose donc un modèle cohérent et complet s’appuyant sur un style architectural simple et ayant fait ses preuves : REST. D’une conception plus simple, il ne s’appuie sur aucune technologie particulière et offre une interopérabilité de fait : toutes les plate-formes offrent nativement un accès à HTTP.

HTTP, le protocole à tout faire

Il n’y a pas si longtemps, il semblait inimaginable à beaucoup d’entreprises d’offrir un accès à ses applications métier, souvent transactionnelles, par le Web. Et le point vraiment problématique était déjà à l’époque HTTP. Comment peut-t-on envisager de fournir un accès à une application métier transactionnelle à travers un protocole tout juste bon à transférer les documents hypertexte (HTML) simples ? Non connecté, non sécurisé, non fiable et surtout non transactionnel, HTTP semblait très loin de fournir les garanties nécessaires pour des applications d’entreprises.

Et pourtant, force est de constater aujourd’hui que la majorité des entreprises a terminé ou au moins engagé la migration des IHM de leurs applications critiques en mode Web. Ce qui est bon pour les IHM ne le serait donc pas pour le coeur du système d’information ? En réalité, ce que nous proposons et ce que propose la WOA est une généralisation du mode Web permettant d’exposer et de consommer les services métier. Finalement, pour uniformiser technologiquement et rendre réellement interopérables les services du système d’information et de les publier sur le réseau mondial, Internet.

Malgré ce que l’on peut penser, HTTP offre toutes les garanties nécessaires pour être utilisé comme protocole central d’un système d’information. Bien utilisé, il est fiable, totalement sécurisé et peut facilement être le support d’échanges transactionnels. HTTP est concrètement le protocole à tout faire, et pas seulement à transporter des fichiers HTML. Il peut par exemple générer des graphiques complexes, géocoder une adresse n’importe où sur la planète ou encore envoyer des emails.

Si vous êtes convaincus comme nous qu’il n’y a plus d’architecture technique à inventer, que le Web est la nouvelle architecture technique universelle et que vous souhaitez savoir comment aligner votre système d’information transactionnel existant sur le Web, alors n’hésitez pas, contactez-nous !

Cet article a été publié le Mardi 22 avril 2008 à 18:16 et est classé dans Position paper. Les commentaires sont fermés, mais vous pouvez faire un trackback depuis votre propre site.