|
| |
| A LIRE AILLEURS |
 |
|
|
| Les bonnes feuilles du Web |
| Les critiques SOAP font tâche - Bon code et mauvais code selon le créateur de C++ - Pas de solution unique
(12/12/2006) |
| |
  |
 |
Forum |
|
|
Réagissez
dans les forums
de JDN Développeurs
|
Les critiques SOAP font tâche
 Dans le monde des services Web, il existe trois protocoles d'accès : SOAP, XML-RPC, et HTTP (ce dernier au moyen du style REST) (lire notre article "SOAP, XML-RPC et REST : différences et intérêts"). Soutenu par les grands acteurs, à commencer par le W3C, IBM et Microsoft, SOAP semblait être la voie unique - ou plutôt, SOAP et la pléthore de spécifiques WS-*, regroupant les WS-Security, WS-Policy, WS-Reliability et tant d'autres. Face à la complexité du format SOAP et de ses assistants WSDL et UDDI, il semblait reposant de ne se baser que sur un protocole solidement établi et disposant des verbes nécessaires : HTTP, avec les méthodes classiques GET et POST, mais également PUT, DELETE... Et c'est exactement cela que prônent de plus en plus de développeurs, culminant ces dernières semaines avec des articles pointant du doigt la ridicule complexité de l'usage de SOAP, et la simple logique de REST. Le plus parlant reste probablement l'article de Pete Lacey, "The S stands for Simple", où l'auteur reprend le principe du dialogue socratique pour opposer le développeur et l'évangélisateur SOAP. Dans la même veine, mais en plus sérieux, Duncan Cragg entame une série de neuf "REST Dialogues" entre lui-même et un architecte eBay imaginaire, commençant par "Getting Data" et "Setting Data". Les réactions ne se firent pas attendre, avec l'approbation de Tim Bray (co-éditeur de XML), de David Heinemeier Hansson, créateur de Ruby on Rails et même Nelson Minar, implémenteur des accès SOAP pour les API Google Search et Google AdWords.
Bon code et mauvais code selon le créateur de C++
TechReview a publié une longue interview avec Bjarne Stroustrup, en deux parties, dans laquelle le programmeur expose les concessions qu'il à dû faire lors de la création de C++, leurs implications dans le code écrit aujourd'hui et les solutions qu'il propose aux problèmes soulevés. Dans la seconde partie, il explique ne pas voir la programmation orientée Aspect devenir un paradigme aussi important que la programmation structurée ou la programmation orientée Objet, ne pas souhaiter que la programmation devienne un hobby pratique par tout un chacun. Il donne son point de vue sur la compatibilité descendante, la portabilité et .Net. [première partie, seconde partie]
Pas de solution unique
Régulièrement, le monde du développement est secoué par l'arrivée de nouvelles méthodes, de nouveaux concepts, d'idées géniales qui, supposément, devraient révolutionner la manière de développer, faciliter la vie du programmeur tout en lui promettant du code sans faille, portable et maintenable par tous. C'est alors le bon moment pour relire un article publié par Frederick P. Brooks en avril 1987, "No Silver Bullet: Essence and Accidents of Software Engineering", où il stipule que ces miracles ne sont qu'illusions, arguant qu'il existe une différence entre la complexité accidentelle, liée aux problèmes que nous créons et pouvons résoudre, et la complexité essentielle, liée au problème qu'il faut résoudre. Cette seconde complexité ne pouvant pas être contournée ou oubliée, le gain de productivité ne peut être fait que sur la complexité accidentelle - qui aujourd'hui comme il y a 20 ans, peut difficilement être plus rapide à résoudre grâce à l'arrivée des langages de haut niveau, comme Fortran. [Lire]
| SOMMAIRE |
|
2006
|
|
|
Quelques pistes pour réformer le W3C - Le bon Agile et le mauvais Agile - Ruby n'est pas encore un choix sûr... |
|
12/07
|
Les 8 problèmes qui persistent selon Jakob Nielsen - Paul Graham et le Web 2.0 - Java EE trop complexe ? - Les fontes, monopole oublié de Microsoft |
|
|
|
|
