Software is written by humans–emotional, fallible, creative, and messy–for other humans. Any attempt to treat development as robotic will end in tears.
Monthly Archives: November 2007
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.
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 la
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?
Google open social DReaM
S’était le sujet phare de l’expo Web2.0 à Berlin: les réseaux sociaux et l’annonce de open social par Google. Google le chevalier blanc armé de son “open API” qui vient libérer le graph social enfermé derrière le bouclier des API propriétaires du méchant Facebook.
Malheureusement tout cela n’est qu’un rêve et la réalité est bien différente. Pour comprendre je vais poursuivre ma métaphore entre DRM et Web services.
L’API de facebook contrôle ce que l’on peut faire avec le social graph de Facebook, en particulier elle empêche d’utiliser votre liste d’amis à l’extérieur du site Facebook, en ce sens c’est un DRM, des barreaux, un vérou numérique qui contrôle l’usage que vous pouvez faire d’une donnée.
On pourrait imaginer que pour contrer Facebook, Myspace ou Linkedin fassent de même et proposent leurs propres APIs fermées pour utiliser leur graph sociale. On aurait alors plusieurs DRMs en compétition au détriment des utilisateurs comme pour la musique. Que propose Open social? D’ouvrir ces api? Non, il propose de rendre intéropérables ces DRMs potentiels.
Une application écrite avec open social fonctionnera dans le container Facebook tout comme dans le container Myspace.
Mais Facebook ne s’est pas joint à open social.
Mais le système ne permet toujours pas d’ouvrir les données du graph social et de les utiliser en dehors du site de réseau social d’origine.
Mais open social s’appuie sur Google gadget, il y a donc une dépendance forte avec Google que ce soit open source ou pas.
Un système d’intéropérabilité entre DRM, des containers, un leader qui ne rejoint pas l’initiative, ça me rappel quelque chose, et vous ? C’est la plateforme DReaM de sun qui avait pour objectif l’intéropérabilité des DRMs.
Plus grand monde ne conteste le fait que les DRMs sont une impasse et on a même totalement oublié cette idée saugrenue d’intéropérabilité des DRMs. Ca donne une bonne idée de l’avenir d’open social.
A moins qu’il ne reste un espoir… Open Social est une réponse précipité à la menace Facebook pour Google -Imaginez que demain en s’appuyant sur les données de votre réseau social Facebook donne des résultats de recherche plus pertinents que ceux proposés par Google?- Google a donc dégainé son fusil à pompe sans vérifier les cartouches. Les spécifications et les implémentations open social sont à moitié finies. Ce que j’ai décrit correspond à la partie disponible d’open social, c’est à dire l’API javascript qui repose sur google gadget. Mais open social prévoit une autre API à base de GData, qui respecte les principes de REST, le mp3 des services web 😉 Mais pour l’instant cette open social people Data Api n’existe pas encore. Pourtant cette API répondrait aux souhait de Tim O’Reilly: OpenSocial: It’s the data, stupid. Est-ce que les containers open social l’implémenteront? Pourtant comme le dis O’Reilly le premier à fournir ce social network ouvert va gagner.
Social network
Whichever company gets there first, to a truly open, user-empowering, internet-turbocharging social network platform, is going to be the net’s next big winner.