Tag Archives: architecture

Pour bien débuter l’année

Mon année de veille technologique 2007 c’est terminé par la découverte de trois perles qui illustrent à merveille les 3 thèmes de ce blog: java, architecture et Web2.0.

Pour bien débuter 2008 je vous recommande donc

[youtube=http://youtube.com/watch?v=D3qltEtl7H8]
Meilleurs voeux !

Big Web Services pourquoi ça ne marche pas?

L’expérience de nombreuses personnes montre que les Big Web Services (SOAP+Ws-*) sont loin de tenir toutes leurs promesses. Voyons maintenant la principale raison théorique qui explique cette débacle:

La volonté de s’abstraire des contraintes du réseau

Relisez au moins deux fois cette citation trouvé chez Pete Lacey:

Integration point latency can be a serious performance problem. The problem becomes acute when the integration point uses some ?avor of remote object protocol. The “location transparency” philosophy for remote objects claims that a caller should be unaware of the difference between a local call and a remote call. This philosophy has been widely discredited for two major reasons. First, remote calls exhibit different failure modes than local calls. They are vulnerable to network failures, failure in the remote process, and version mismatch between the caller and server, to name a few. Second, location transparency leads developers to design remote object interfaces the same way they would design local objects, resulting in a chatty interface. Such designs use multiple method calls for a single interaction. Each method call incurs its own latency penalty. The cumulative effect is a very slow response time.

Michael Nygard

On ne peut pas faire abstraction du réseau, c’est une mauvaise idée que de vouloir faire croire au développeur qu’un appel local est lanetwork.png même chose qu’un appel réseau à cause des problèmes:

  • d’erreurs réseau.
  • de bande passante.
  • d’accès concurents et de versions qui en résultent.
  • de granularité des services.
  • … d’autres raisons sur Fallacies of Distributed Computing

Les Web Services sont les DRM du Software as a Service

Les Web Services sont les DRM du Software as a Service (SaaS) et les API Restfull en sont le mp3.

C’est Christian Fauré dans un commentaire sur un billet précédent qui m’a inspiré cette réflexion. Dis comme cela, ça semble un peu cryptique, un décodage s’impose donc.

Pour commencer quelques précisions sur le vocabulaire:

Web services: au sens du w3c ou “big Web services”, avec toute la stack SOAP + WS-*

DRM: Digital Right Management au sens CRAP: Contenu, Restriction, Annulation et Protection Ce sont ces technologies utilisées pour contrôler/limiter l’usage qui est fait de la musique téléchargée en ligne, par exemple pour restreindre la copie.

Software as a Service: Logiciel disponible sous forme de services accessibles en ligne au travers d’une interface web et d’une API.

API RESTfull: Interface de programmation respectant les principes énoncés par REST, en particulier API centrée sur la notion de ressource plutôt que de service.

Les Web Services, bien que se voulant réutilisables, imposent une manière d’accéder aux données au travers de l’interface qu’ils définissent. Ils présupposent certains type d’utilisation. Ce faisant ils limitent/contrôlent ce qu’il est possible de faire avec ces données comme le font les DRM avec la musique.

Les Web Services ne sont pas réellement intéropérable, ils fonctionnent bien sur la plateforme .net ou JEE, ils fonctionnent bien si l’on se sert des outils IBM ou Microsoft, ils fonctionnent péniblement entre .net et JEE, ils ne fonctionnent pas ou mal avec d’autres plateforme: php, ruby, python,… Tout comme un fichier aac d’apple fonctionne bien avec le logiciel itunes et les lecteurs ipod ou les fichiers wma DRMisés de Microsoft fonctionne bien avec les lecteurs “play for sure” et le logiciel windows media player. Mais ils ne marchent pas avec mon lecteur mp3 ou mon OS Linux.

Alors que les fichiers mp3 sont lisibles avec tous les lecteurs du marché et tous les logiciels. Il en va de même avec les services RESTfull, reposant sur des technologies simples et éprouvées: HTTP et XML, ils sont utilisables dans tous les environnements (java, .net, php, ruby, python, perl, script,…) avec n’importe quel outillage (du notepad à eclipse en passant par visual studio).

Enfin une API RESTfull en exposant des ressources plutôt que des services ne présuppose pas de l’utilisation qui sera faite des données exposées. Sans à priori sur les utilisations futures des données une API RESTfull ne limite pas l’usage qui sera fait des données (au contraire des DRM) et maximise les possibilités de réutilisation et de mash-up.

Un service web devrait être un site web navigable par des robots

RESTfull Web services