Web Oriented Architecture

The big thing about GData for Google is that it’s extremely simple to build into the server-side, so they can offer APIs very easily. This is important as they offer APIs for lots and lots of new stuff. Atom is quietly becoming the standard for reading and writing to Google (RSS for reading as well). They’re not saying that in public, but it’s happening. Atom is becoming the standard RESTian web services envelope.

Source

WS-* (Webservices & co). La fause bonne idée mais vraie castastrophe …

Ce sujet est tabou car le marketing a frappé. Cependant quelques voies s’élèvent :

• Le Gartner (WOA !)
• Le remplacant de Bill sur son blog (mais n’ecoutez pas la partie sur le copié/collé)
• Don Box (une tête pensante proche de Microsoft)
• la R&D d’HP explique pourquoi ca ne marche pas et que ca ne marchera pas mieux demain
• SUN ajoute une couche REST dans Java 5
• Un des concepteurs des normes WS-* et developpeur de la première pile SOAP de apache (devenue Axis)

Ils ne sont pas connus mais resument bien les problèmes :

• Les problèmes d’interopérabilité
• Redeemed! JAX-WS still sucks!

Pourquoi en vouloir aux WS-* ?

Les raison sont nombreuses. 2 approches sont possibles pour contester les WS-*.

1 – L’approche scientifique

Le rasoir d’Ockam est un principe de raisonnement de la science fondamental, il correspond au principe de simplicité.

“Le principe du rasoir d’Ockham consiste à ne pas utiliser de nouvelles hypothèses tant que celles déjà énoncées suffisent, à utiliser à fond les hypothèses qu’on a déjà faites, avant d’introduire de nouvelles hypothèses, ou autrement dit à ne pas apporter aux problèmes une réponse spécifique, ad hoc, avant d’être (pratiquement) certain que c’est indispensable (sinon on risque d’escamoter le problème, et de passer à côté d’un théorème ou d’une loi physique).”
(Wikipedia)

De quoi part-on avant les webservices ?

• du protocole http qui fonctionne dans le monde entier, normalisé, millions d’utilisateurs
• du protcole xml et de ses dérivés comme xhtml : millions d’utilisateurs également, normalisés…

Quels sont les objectifs des WebServices ?

• faciliter l’intégration avec une approche service
• faire de l’objet reparti

Dans le premier cas, il faut constater que le protocole http et comme format xml (eventuellement xhtml) fonctionnent déjà et sont très simples et bien normalisés et stables (la dernière mise a jour d’Xml c’est pour gérer les derniers ajouts d’Unicode qu concernait quelques langues asiatiques disparues depuis quelques sciècles… ).
Il n’existe pas de raison particulière de rajouter des protocoles au dessus en dehors de couches applicatives (schema de format de tansfert de fond, commande…).
Les couches WS-* n’apportient rien de probant en matière d’échange de documents, il s’agit même de reculs par rapport au simple http/xml. Prennons pour exemple la sécurité, avec http il suffit de certificats pour passer en https, avec les web services il faut plusieurs protocoles qui sont rarement gérés par les produits qui gèrent les webservices.

Cette approche pourrait être quantifiée avec une utilisation des théories de Kolmogorov.
Les 2 plus petit programme permettant un échange de documents entre systèmes seront plus petits avec http/xml qui WS-*. Cela peut se voir en pratique grâce a amazon qui a implémenté des services de stockage avec les 2 appoches, il suffit de comparer ce qui passe sur le réseau dans les 2 cas.

l’approche REST c’est :
- les URI pour annuaire
- le protocole applicatif Http avec ses verbes (put,get,post, delete,head). Ne pensez pas que c’est simple, le célèbre sql a les mêmes (select,update,delete,insert).
- sécurité X.509.
Les spécificateurs ont tenté de reinventer les choses :
- annuaire UDDI : les serveurs sur internet ont d’ailleurs été arretés, personne ne s’en servait
- pas de verbes strandards. C’est selon le bon vouloir des développeurs.
- sécurité très difficile a implementer.
Pourquoi ont-ils du mal ? car ils cherchent a faire des protocoles applicatifs au dessus de protocoles applicatifs (http, smtp…). Http n’est pas un protocole de transport ! Leur approche n’aurrait de sens d’un point de vue protocoles que s’ils étaient au dessus de TCP/IP. Vouloir faire des protocoles applicatifs au dessus de protocoles applicatifs n’a pas de sens et mene a l’impasse car on pourrait également considérer SOAP comme un protocole de transport et rajouter une couche au dessus (tiens, c’est ce qu’ils font…) et ainsi de suite a l’infini… c’es ce qui se passe tous les jours, le nombre de normes croit sans fin. Il y a tellement de normes qu’il est nécessaire de rajouter le concept d’ESB pour faire parler tous ses dialectes d’XML.

L’aute objectif de WS-* c’est de refaire de l’object réparti. Vous avez entendu parler de Corba ? cette merveille technologique normalisée avec annuaire, decouverte des objets sur le réseau, multi plateforme, multi languages et multi echecs ? et oui, ca n’a pas marché. Quelles sont les raisons qui font que ca peut marcher mieux maintenant ? aucunes, par contre Corba avait l’avantage d’être plus simple.
Quelles sont les difficultées de ce type d’approche ?
- Etre multi langage aligne tout le monde sur un minimum commun ce qui ne satisfait personne. Qui voudrait developper en java sans profiter des améliorations ? donc les normes vont evoluer pour prendre en compte les ajouts des langages. Il ne peut donc pas il y avoir retro compatibilité et tous les langages ne suivent pas. Comme tous les langages ne progressent pas dans les mêmes directions ca devient la tour de babel rapidement. Donnons un exemple pratique, les templates ne sont gérés que par C# et java 1.5 avec des différences… comment faire communiquer ces langages avec ruby ? et serait-il pertinent d’ajouter tous ces concepts complexes à tous les langages pour interopérer ? est ce que ca ne rendrait pas tous les langages comples ? Ce couplage est-il lache ?
Comme les réponses sont non, non et non vous en conclurez la même chose que la recherche d’H.P.
De plus, comme l’a avoué un des concepteurs des web services, vouloir sérialiser les objets dans du xml est bien plus complexe que l’on ne croit ! (article ici)

Libre a vous de penser que toutes ces normes sont utiles !

2 – L’approche par l’expérience

Est-ce que l’experience montre une facilité certaine qui deconcerterait la théorie ?
Pas vraiement. 90% des services d’amazon sont appelées en mode REST et si vous lisez les commentaires a cet article , vous decouvrirez qu’a piori les web services d’amazon sont construits au dessus des services REST.
Les Web services fonctionnent bien lorsque l’environnement des très homogène (Webshere du développement à l’execution, ou visual studio…). Dés que vous mélangez ca se corse ! C’est etonnant d’arriver a se constat alors que l’objectif était justement de faciliter l’interopérabilité… Les éditeurs tiennent décidement bien a leur client, ils les fidelisent … Voici un petit article du MSDN de Microsoft pour expliquer comment faire. Notez bien les prerequis au départ (en version … ). Notez que c’est le cas simple dans lequel les utilisateurs se mettent souvent (SOAP 1.1). Si vous voulez utiliser le messaging, la reliability… ca devient tout un poème que d’arriver a faire communiquer 2 applications ! (quel recul !).

3 – pourquoi certains en font ?

• parce que dans les outils de developpement il est simple de transformer un objet en web services. en Dotnet il suffit de rajouter [webmethod] devant une méthode ! Ces services sont ensuite très facilement utilisables depuis le même outil de développement, c’est comme si on utilisait la classe directement (je n’ai pas contre pas bien compris pourquoi on se compliquait la tâche en instanciant pas directement cette classe…)
• parce que c’est a la mode, les editeurs mettent ca en avant partout dans le moindre produit. Si vous ne faites pas de Webservices vous etes dépassé …
• ca permet de vendre de nombreux produits (pour faire et utiliser des webservices il faut des produits lours et payants), pour interopérerer il faut des ESB, bref du bonheur pour les éditeurs.

Résumé

• dans les meilleures pratiques sur les Web services, il y a la nécessité de concevoir la structure des données echangées avant de coder ce qui revient a echanger des documents xml a la structure formalisée.
• Le principal protocole utilisé pour les webservices est http, il n’y a pas de reel besoin de faire des webservices au dessus d’autres protocoles a part pour l’approche demo
• il n’y a pas de moyen d’adresser les resosurces car l’annuaire UDDI a échoué

REST de son coté c’est :

• un moyen d’adressage simple, universel et en place chez des millions de personnes (URI)
• permet des échanges que se soit en xml et schema xml mais il est également possible d’échanger des video en streaming, des images, documents word …
• ca marche depuis longtemps !

Sur la base de ses bonnes pratiques, et pour respecter un principe scientifique (application simple du principe d’ockam), il faut respecter le style REST. Sortir du style REST c’est sortir des principes scientifiques. et la vous pouvez faire ce que vous voulez (Webservices over X.400 encapsulant du TCP.IP… )

(En cours)

Les références

Le document de référence sur le sujet est incontestablement celui du W3C

Synthèses en cours de construction

• Protocole Http
• Web 2
• REST
• Architecture de Web
• L’echec passé et futur des Web Services

Retour a la page d’acceuil

Ce page sera complétée regulièrement pour décrire le protocole http

Liens de références

W3C : norme Http 1.1

• La page sur les caches du protocole http doit être lue avec attention ici.

Introduction

vous trouverez ici une systhèse du protocole http. Ca donne un bon aperçu des fonctions du protocole.

Zoom sur les URI

Les documents de références sur les Uri sont disponibles sur cette page du W3C.
L’idée principale est que toute ressource doit disposer d’une adresse unique et comprehensible (format texte) et invariantes (vous trouverez ici un document d’explication du W3C)

Prennons des exemples :

1. adresses email : mailto:bill.gates@microsoft.com -> Correct
2. Serveur Web : http://www.materiel.net/browse_ordi.html -> Correct (mais on peut faire mieux)
3. Adresse email : mailto:stagiare1@nimportnawak.com -> incorrect
4. Serveur Web : http://unserveur:80/appv3/arcg3.jsp?sessionid=23543234322&c=45455 ->Incorrect

Pourquoi ?

Les urls correctes sont stables dans le temps, lisibles, peuvent être transmises et fonctionner (si vous avez les droits), elles mènent toujours au même endroit. Dans le cas 2 c’est toujours la liste des ordinateurs mis en avant par matériel.net par exemple. Les incorrectent violent ces règles.

Dans un système d’information respectant le style d’architecture du Web, il faudrait retrouver des liens du type http://clients.societe.com/Client/33/ pour afficher directement la vue du client 33. il est possible d’en imaginer pleins d’autres /Client/33/Contrats/ pour afficher la liste des contrats du client 33, http://contrats.societe.com/Contrat/55/ pour afficher le contrat 55. …
Ces liens doivent être logiques et découplés de l’infrastructure physique. Comment s’appellent les serveurs de google ? combien ont-ils de serveurs ? vous ne le savez pas et ca ne vous interesse pas. Alors pourquoi avoir des urls de ce type dans les sociétés : http://peuplemou/itmrzze/servletloader?id=4335643 pour acceder a la page d’acceuil d’un progiciel ? Avec un peu d’administration des serveurs Web, il est possible de simplifier la vie des utilisateurs.
Les liens doivent être fonctionnels, independants de l’évolution de l’infrastructure et fonctionnellement les plus invariants.

Zoom sur les caches

Http est un protocole et ne gère pas lui même de caches. Par contre il fournit des mécanismes très puissants pour faciliter leur mise en place. Ils sont malheureusement très mal exploités.

Le moyen classique de penser et voir les caches est probabiliste.
L’idée est qu’une information a une durée de vie (quelques minutes ou quelques heures) pendant laquelle elle peut être considérée comme valide.
C’est utiliser assez souvent pour les images sur interne. Le logo de la société ne change probablement pas toutes les heures dont on peut lui attribuer une durée de vie d’une heure (par exemple).

1. Lorsque le browser web fait pour la première fois une requete sur le site il faut une demande du type http get /logo.jpg.
2. Le serveur lui repond alors avec dans l’entête des champs (Cache-control…) qui indiquent jusqu’a quand le l’image est sencée être valide et bien entendu l’image.
3. Le browser met alors dans son cache l’image. Si vous allez sur une autre page du site affichant le même logo, le browser ne fait pas de requete pour celui-ci et prend directement l’image qui est dans le cache.

Si le logo a été modifé entre temps les pages risques de ne pas bien s’afficher. Le problème peut être bien plus sérieux si les ressources en cache sont les fichiers javascript, css, pages html …
J’ai dit qu’il était probabiliste car on considère qu’il est peut probable que le logo soit modifié mais en fait on ne le sait pas et quelles valeurs peut-on mettre comme durée du vie ? Ce mode de gestion n’est donc efficace que pour des données dont on connait a l’avance la durée de vie.

La ou le protocole http peut montrer toute son efficacité c’est par l’utilisation de caches formels.

1. Lorsque le browser demande une ressource (http get /logo.jpg),
2. le serveur lui repond avec la ressource et un champ etag dans l’entête. Ce champ peut contenir ce que vous voulez (une version de document, une date…).
3. Le browser met en cache la réponse. A chaque nouvelle apparition le browser va faire des requetes au serveur pour demander la ressource et rajoute dans l’entête (if-none-match -le champ etag-).
4. Le serveur doit alors vérifier si le client a la bonne version du document. Si le client a la bonne version il doit renvoyer uniquement un statut de réponse 304 qui signifie non modifé, sinon il renvoit la ressource.
5. Le browser utilise alors son cache ou la réponse renvoyée par le serveur.

La grosse modification par rapport a la forme de cache évoquée ci-dessus est que le browser aura toujours un logo a jour. en effet lors de sa deuxième requete il demandera ‘if-none-match datedemodificationdulogo’. Le serveur pourra comparer avec l’image stockée, si le browser a la bonne il repond 304 et sinon il renvoit la bonne version.

Le browser aura donc toujours la bonne version des images, javascript, css …

Si on combine avec les URI on a donc un client qui va demander une ressource du type http://relation-client.societe.com/Clients/Client/33/. Le serveur va repondre par le html correspondant au client 33 et rajouter dans l’entête http etag ‘datededernièremodificationduclient’. A la prochaine requete le browser demande au serveur si le client a été modifié ou non, dans la négative le browser travaille avec son cache.
Une application dynamique non seulement peut utiliser les caches mais doit les utiliser de cette façon pour avoir de bonnes performances. Le seul prerequis est d’avoir facilement accès a la date de dernière modification d’une ressource ou sa version… Il faut que la page java,php… puisse en une simple et performante requete savoir s’il faut renvoyer 304 ou lancer la génératio n de la page. Les applications seront bien plus performantes lorsque ce mecanisme aura été compris.

With the original firewalls, it didn’t matter too much about the vulnerabilities in the software because the firewall wouldn’t let unexpected application protocol traffic (often referred to as layer 7 traffic) past them. The device actually understood what was going on on the connection and would drop it if strange things started happening.

Today’s firewalls don’t understand applications, so they don’t do anything other than relay traffic to a specific back-end application–with all of its vulnerabilities laid bare to the world for exploitation.

The second reason that today’s firewalls are so fast is they generally don’t do anything useful out of the box. That’s right, the $60K piece of hardware is actually going to do nothing to protect your network until you enable the controls. What’s that about default to no access or something crazy like that? Oh, and when you do start turning on those controls, it will slow down the traffic going through your network. Wow. What a surprise, but, according to Marcus, people don’t find that acceptable so they turn off the protections. Excellent stuff.

[...]

Why signature-based tools like IDS and virus scanners don’t work

This point was illustrated with a brilliant story about castle guards and Vikings (Marcus is also a bit of a military historian). The problem is that the tools (firewalls and anti-virus) don’t know about Vikings, they know about Eric the Red.

Castle guard: “Are you Eric the Red?”
Canute the Viking: “Nope.”
Castle guard: “Ok, then. In you go.”

At which point, Canute the Viking enters the castle and begins his conquest of England, Denmark, Norway and part of Sweden. Are you starting to see the issue here?

The issue is that the guard needs to know all of the potential attackers on a first-name and by-sight basis. While this is theoretically possible, in practice it will never work because you’re always reactive and there are a lot more potential Vikings in the world than there are of you. Military history shows us that the people who were always on the defensive generally didn’t end up winning the war.

Source

On n’arrete pas le progrès, des vendeurs essayent deja mettre en place des gateway xml :

http://atownley.org/2006/06/are-xml-gateways-really-the-answer/

vous aurez au passage un vrai cours sur la sécurité : le DMZ sont non seulement inutiles mais en plus dangereuses !

Bonne lecture !

un très bon site sur les problèmes d’interopérabilité.

“Great, so we’ve solved our problems. All we have to do is provide a Web services endpoint connected to our JMS vendor and we’re in business, right?”

Ah, Grasshopper… You have much yet to learn.

The real issue with the WS-R* specifications is the same as for JMS: the devil is in the detail. While WS-R* may standardize the wire protocol into sending XML documents over HTTP, which should be interoperable as long as the XML is conformant to the specification, we have a problem at the next layer of the application: the API.

Les articles du site sont très didactiques et exposent très clairement les problèmes posés par les approches actuelles avec des exemples qui ne sont que trop concrets !

une excellente citation de sa part pour finir :

Remember, as Yoda says: “Once you start down the dark path, forever will it dominate your destiny.” Don’t let your vendors steer you onto that path. Demand portable interoperability in your software solutions. If you don’t invest in it today, you’ll end up paying for it tomorrow.

>My issue with the Java platform is that it requires a different API for
>each type of middleware/communication pattern. Why does the platform
need
>so many APIs/plug-in patterns for communications: JAX-WS, JMS, JBI,
JCA,
>etc? How about taking an approach more like Microsoft’s Windows
>Communication Foundation (aka “Indigo”)?

You mean, why is the Java world (vendors and ‘community’) so fractured
and foolish and unable to see the ARY (Always Repeat Yourself) and KICS
(Keep It Complicated (and) Stupid) models they’re been not only
following but actively embracing and promoting for the past decade are
serious, severe and foundational problems of their own making and which
are, all too likely, fatal ones at that?

Gee. I dunno.

“If you can’t be a good example, then you’ll just have to serve as a
horrible warning.”

[Good thing the Web Services world didn't pay heed or who knows where
the industry might have wound up...]

- Howard

Si vous lisez ce blog, vous pouvez vous dire que mon opinion sur les webservices est marginale.
Quelques commentaires de personnes marginales…

La il s’agit d’un des coauteur des specifications des webservices, developpeur de la première couche SOAP qui parle :

http://blogs.ittoolbox.com/eai/applications/archives/the-web-services-wise-man-9598

Who else than Sanjeeva Weerawarana knows Web Services best? WSDL, BPEL, WS-Addressing, WS-Policy, WS-Eventing (and more) are all specifications where we was co-author or at least involved at a certain level. Sanjeeva is also a Java developer, has created the first Java Soap stack (Apache Soap) and is now developing Axis 2.

Recently, he has posted a very interesting message on the service-orientated-architecture mailing list:
<.. I also started into Web services with a view that it was bridge you need to cross every once-in-a-while and hence the right way to do it was by facading your existing middleware and programming model with some XML Schema and WSDL. Over time I changed my mind and am now convinced that that's all wrong .. XML is not a serialization format for an object type system and you need to deal with it as XML. WS-* is not about invoking functions remotely but rather about delivering XML messages from point A to point B and letting it do whatever it wants with it and applying policies to those messages at various points. That's the design point of WSDL 2.0, WS-Policy, SOAP 1.2 and of Apache Axis2. …>

Since you asked in an earlier thread, here’s some of my WS-* background:
- I’m to be blamed for a good part of the monstrocity called WSDL (1.0
and 1.1) .. myself and a colleague in IBM took NASSSL (Network
Application Service Specification Language; something we created) and
merged it with SDL from Microsoft and created WSDL. In the W3C I’ve been
an editor of the WSDL 2.0 specs since that effort started.

Mon commenaire :

• essayer de serialiser des objets en xml a echoué
• il faut echanger des documents xml
• cet contributeur est probablement plus libre depuis qu’il a quité son ancien employeur
• et plutot que de prendre toutes les normes WS-* 2.x utilisez plutôt http et xml. c’est la même chose moins les surcouches !