Category Archives: architecture

Tout, vous saurez tout, sur REST

A ne pas manquer les slides du workshop REST du Burton group par Pete Lacey. Il faut s’enregistrer mais ces 93 slides font très bien le tour de la question.

Une des clés de l’efficacité de REST? La reconnaissance des différences fondamentales entre accès locaux et distant. De nombreuses technologies de programmation distribuée (RMI, SOAP,…) passe par des proxy censés rendrent transparents les appels distants. C’est une erreur, on ne peut pas ignorer le réseau, ses problèmes de latence, de débit, de fiabilité…( peut-être ces problèmes n’existeront-ils plus dans le futur mais pas aujourd’hui). A l’opposé, REST (Representationnal transfert state) ne permet pas de manipuler directement une ressource distante, seulement de transférer une représentation d’un état d’une ressource.

Plus de détail dans les slides, l’importance de l’identifiant unique (l’url), de l’interface unique et simple (GET,POST, PUT, DELETE), et des liens (l’hypermedia)

Update: d’autres slides sur REST, the rest of REST par Roy Fielding himself!

Granularité et atomicité des services

How big should a service be? C’est la question que pose InfoQ après la lecture de The Service Granularity Matrix par zapthink. Très bon article au coeur de la problématique SOA:

  • Quelle granularité pour les services, fine or coarse grained?
  • Un service est-il réutilisable? Atomique ou composite?

Pour chaque service identifié le choix se fera selon 5 aspects:

  • reusability
  • efficiency
  • transactionality
  • consumability
  • visibility

Des services fine-grained en premier lieu pensés comme composite deviendront un seul service coarsed-grained atomique pour garantir une transaction et l’efficacité. Un service coarsed-grained sera explosé en plusieurs services fine grained pour des raisons de réutilisation.
..

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