Tag Archives: web services

Le retour du Web dans les Web services

L’architecture d’entreprise est une sorte mammouth, pas très agile, beaucoup d’inertie. Elle met du temps à changer de cap et avance tête baissée. Ce sont bien souvent les éditeurs et les analystes qui fixent le cap. Depuis plusieurs années tout le monde suivait les panneaux SOA. Je connais pas beaucoup d’entreprises qui soit arrivées à destination, certains commencent même à abandonner la route. Il est donc temps de fixer un nouveau cap.

Le Web a depuis longtemps adopté les principes RESTful ils sont au coeur de GData l’api de Google. En 2008 IBM a pris la direction de la RESTful SOA, La plateforme .net 4.0 de Microsoft prend elle aussi le virage REST. Les éditeurs ont pris la route REST.

Depuis plusieurs années Pete Lacey du cabinet d’analyste Burton évangélise REST. Et la semaine dernière la bible des DSI a sauté le pas. Le Gartner recommande enfin les approches RESTful:

Gartner: Web-Oriented Architecture: Putting the Web Back in Web Services

Les analyste ont pris la route REST… Toute l’architecture d’entreprise va suivre. Je ne vous cache que j’attend celà depuis un moment. Ca ne fait jamais que 4 ans que je m’intéresse au sujet…

Je suis très agréablement surpris par la note du gartner qui a su mette le doigt sur la valeur de REST

  • “Unexpected reuse is the value of the Web” (Tim Berners-Lee)
  • “Engineer for serendipity” (Roy T. Fielding)

Ca reste des consultants… Ils inventent le concept d’application neutrality pour expliquer qu’une interface réutilisable doit être neutre et non pas spécifique à une application. REST pemet et encourage la construction de telles interfaces. Il parle aussi de “wide top” pour bénéficier de l’effet de réseau. Je parle de surface de contact, la multiplication des URI dans une application RESTful augmente la surface de contact de l’application et les possibilités de réutilisation imprévues (serendipineuses même!).

Enfin Gartner utilise le terme WOA pour Web je préfère le terme ROA pour Ressources, car le paragdime central de REST est bien la ressource.

Il est donc temps de s’y mettre, voici quelques points de départ:

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

WS-* Bashing

At this point I realize I’m flogging a dead horse. The folks I know from across the industry who have to build large scale Web services on the Web today at Google, Yahoo!, Facebook, Windows Live, Amazon, etc are using RESTful Web services. The only times I encounter someone with good things to say about WS-* is if it is their job to pimp these technologies or they have already “invested” in WS-* and want to defend that investment.

Dare Obasanjo Program Manager, Windows Live Platform group

Nowadays, all the distributed systems development I do is REST-oriented. I know from significant first-hand experience what both sides of the coin look like, and there’s no question that REST-oriented systems are easier and less expensive to develop, and far less costly to extend and manage. Like Dare said, anyone who thinks otherwise is either so emotionally or monetarily attached to WS-* that they can’t be objective, or they don’t actually write any code or build or maintain any actual systems. It’s no contest, really.

Steve Vinoski senior member of the IEEE

WS-* is where CORBA was circa 1997: it will be used to implement some good systems, but there will also be some high profile failures. A number of the specs will likely never be adopted by the mainstream (see WS-CDL, WS-Eventing), though some will definitely improve some ridiculous vendor interoperability disputes (e.g. WS-TX, WS-RM). Plenty of pundits (now bloggers) sing of its imminent triumph (channelling Orfali, Harkey and Edwards), but overall, the framework will not help solve the problem that was used to sell its adoption in the first place: increased agility, reuse, and visibility in IT. I think many WS-* tools actively hinder an SOA architect from achieving these goals.

Stu Charlton Enterprise Architect for BEA

Now that I’m working for IBM’s WebAhead group, building and supporting applications that are being used by tens of thousands of my fellow IBMers, I haven’t come across a single use case where WS-* would be a suitable fit.

James M. Snell write software for IBM

Show me the interoperable, full and free implementations of WS-* in Python, Perl, Ruby and PHP. You won’t see them, because there’s no intrinsic value in WS-* unless you’re trying to suck money out of your customers. Its complexity serves as a barrier to entry at the same time that it creates “value” that can be sold.

Mark Nottingham web expert at Yahoo

Quelqu’un aurait quelquechose de gentil à dire sur les WS-* pour l’équilibre?

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

Que fait le mot “web” dans “web services” ?

A lire absolument: Position Paper For the Workshop on Web of Services for Enterprise Computing

L’introduction et la conclusion du papier:

Web Services based on SOAP and WSDL are “Web” in name only. In fact, they are a hostile overlay of the Web based on traditional enterprise middleware architectural styles that has fallen far short of expectations over the past decade.

[…]

It is my position that the W3C should extricate itself from further direct work on SOAP, WDSL, or any other WS-* specifications and redirect its resources into evangelizing and standardizing identifiers, formats, and protocols that exemplify Web architectural principles. This includes educating enterprise application architects how to design “applications” that are “native” web applications.

Ce papier a été rédigé pour un workshop du W3C, InfoQ avait couvert l’événement et vous pouvez désormais consulter le rapport final du workshop du W3C dont la position concernant le débat REST vs SOAP est bien plus nuancé.

From the REST vs. SOAP legacy, the consensus was that there is strength in both approaches and there is a need to identify how best to leverage those strengths

wsdeathstar.png