Tag Archives: architecture

Questions pour RESTafarians !

Après les architecture dé-testable voici les RESTafariens, à ne pas confondre avec les SOAPafariens 😉

Et c’est David Megginson qui pose 5 questions intéressantes. Ca commence par une définition simple de REST:

“REST in its now-broadened meaning is easy to explain: pieces of data (likely XML-encoded) sit out there on the web, and you manipulate them using HTTP’s GET, PUT. Try explaining SOAP, much less the essence of the whole WS-* family in one easy sentence like that, and you’ll see the difference.”

A lire, ainsi que les commentaires.

SOAP is the EJB of XML???

Le débat fait rage sur TheServerSide après une série de billets provocateurs par Carlos E. Perez:

SOAP is Comatose But Not Officially Dead!
More Nails For SOAP’s Coffin
Why REST is Better – Explained in Code

Je trouve la comparaison avec les EJB assez judicieuse. SOAP et les spécification WS-* sont bien trop ambitieuses et complexes (comme les EJB), on nous promet que tout sera simple grâce à des outils (comme les EJB) la pluspart des applications n’ont pas besoin de toutes ces fonctions avancées (comme les EJB) et il existe des alternatives (comme pour les EJB).

Effectivement en face les examples d’architecture REST (très bonne description, à lire) extrémement efficace sont nombreux (del.icio.us, flickr, yahoo…)

Un example qui me semble assez percutant de ce que l’on peut faire avec du REST (et un peu de XPath)

A quand la spécification WS-REST ???

Le problème avec SOA

Voici un bon billet parlant de SOA

“It strikes me that making this particular SOA dream a reality is not about specs nor is it about tools, it’s about modelling things in a different way such that all the problems of changing requirements etc do not have substantial interface impact”

Voilà, tout est dit, mettre en place une architecture orienté service ce n’est pas un problème technique mais fonctionnel. Une SOA c’est etre capable de définir des interfaces qui pourront être réutilisées alors que les spécifications des applications les utilisants vont évoluer.

Ca suppose que ces interfaces soient définies par quelqu’un qui connaisse extrémement bien le métier de l’entreprise.
Ca suppose que l’on dépasse la vision projet pour passer à une vision entreprise.
Ca suppose que l’entreprise ait au préalable une organisation bien structuré. Les services d’une SOA sont la modélisation du fonctionnement de l’entreprise, si l’entreprise fonctionne mal sans SOA elle ne fonctionnera pas mieux avec.

D’ailleur google ne s’y trompe pas, quand on chercher architecture orientée services on trouve cette très bonne description par mega

Le problème avec SOA

Voici un bon billet parlant de SOA

“It strikes me that making this particular SOA dream a reality is not about specs nor is it about tools, it’s about modelling things in a different way such that all the problems of changing requirements etc do not have substantial interface impact”

Voilà, tout est dit, mettre en place une architecture orienté service ce n’est pas un problème technique mais fonctionnel. Une SOA c’est etre capable de définir des interfaces qui pourront être réutilisées alors que les spécifications des applications les utilisants vont évoluer.

Ca suppose que ces interfaces soient définies par quelqu’un qui connaisse extrémement bien le métier de l’entreprise.
Ca suppose que l’on dépasse la vision projet pour passer à une vision entreprise.
Ca suppose que l’entreprise ait au préalable une organisation bien structuré. Les services d’une SOA sont la modélisation du fonctionnement de l’entreprise, si l’entreprise fonctionne mal sans SOA elle ne fonctionnera pas mieux avec.

D’ailleur google ne s’y trompe pas, quand on chercher architecture orientée services on trouve cette très bonne description par mega