Commentaires sur : Le style d’architecture SOA

Par : Revue Argus - Les technologies permettent-elles l’intelligence collective?

Revue Argus - Les technologies permettent-elles l’intelligence collective? — Sun, 10 Apr 2011 21:29:13 +0000

[...] détecté. Il se produit alors une « excroissance du code », comme le note Christian Fauré6, la technique étant perçue comme un palliatif, un remède qui soigne mais ne guérit pas vraiment [...]

Par : Le guide des égarés. » Quels concepts et compétences transmettre du système scolaire et universitaire au marché du travail ?

Sun, 03 Apr 2011 12:57:31 +0000

[...] 3 Christian FAURE. Le style d’architecture SOA. In Christian Fauré. Billet du 8 octobre 2008. <http://www.christian-faure.net/2008/10/08/le-style-darchitecture-soa/> [...]

Par : Les technologies relationnelles dans les systèmes d’information – Christian Fauré

Tue, 05 Oct 2010 06:11:03 +0000

[...] ce qui a produit le monstre du tunnelling Http et des normes WS-*, et tout cela a culminé avec le matraquage marketing autour de la SOA.La raison en est que, à chaque fois, les DSI appréhendaient les technologies relationnelles comme [...]

Par : Christian Fauré — Une certaine conception de la souverainneté s’exprime aussi dans les choix d’architecture

Wed, 04 Feb 2009 23:26:04 +0000

[...] (Service Oriented Archtitecture) en privilégiant une archtiecture technique s’appuyant sur SOAP et les Web Services plutôt que sur un style d’archtiecture [...]

Par : Meriem

Meriem — Mon, 26 Jan 2009 12:02:00 +0000

Bonjour;
Merci pour cet article tres important.
Je voudrai savoir qu’elles sont les autres styles d’architeture logicielles qui existe à part SOA?

Par : Got

Got — Fri, 10 Oct 2008 08:57:12 +0000

@Cyril Gambis (et globalement tous les défenseurs de SOA) La différence que relève Christian entre SOA et REST ne repose pas uniquement sur le style d’architecture, mais aussi sur le soin particulier qu’il faut accorder à l’architecture des données indépendamment de tous processus.

SOA est massivement orienté processus et application, le problème de cette approche réside dans le fait qu’il est difficile de faire évoluer le SI en cas d’évolution du modèle de données ou de mashup très complexe entre les données (la démonstration de Christian aurait tout aussi bien pu s’appliquer à un ERP et autre BI). L’ESB ne résoud rien, il ne constitue qu’une verrue, un patch pour essayer de résoudre le problème en continuant de le voir du point de vue des processus.

REST est orienté « ressource », il impose donc par nature une réflexion minimum sur les données en dehors des processus qui exploitent les données (cela ne suffit pas, mais c’est un début).

Le défaut de SOA (et globalement de toutes les conceptions du SI depuis très longtemps) réside dans le peu d’attention qui est portée aux données elles-mêmes. Vous adaptez les données aux besoins, alors qu’une ressource (et pas un objet au sens langage de programmation, je vous en supplie !) a des attributs/propriétés en dehors de toutes utilisations. Le SI de demain, son évolutivité, sa maintenance voire sa pérennisation passe par une séparation entre les données et les applications.

J’ai bien conscience qu’il va falloir désapprendre et que la conception est différente, mais ce changement est plus que nécessaire !!

PS pour Christian : c’est amusant de constater que, sans même se voir, on continue à rester en phase pratiquement à la phrase près…

Par : Mickael

Mickael — Fri, 10 Oct 2008 08:37:48 +0000

Article très intéressant. Je suis d’accord avec Aurélien a propos que l’ESB cache le plat de spagetti. A ce propos, regarder cette vidéo sur le sujet de Martin Fowler: http://www.infoq.com/presentations/soa-without-esb .
A mon avis, tout cela résulte d’une incompréhension et que il n’existe pas de technologie all-in-one (ou one-fit-all) pour une bonne intégration des SI. Il faut utiliser les différentes techologies (SOA/REST/MVC) là ou elles sont efficaces et appropriées. Un petit avantage à REST pour sa simplicité (apparente) et à SOA qui va un peu plus loin que ‘juste’ une technologie comme le souligne à juste titre Cyril.

Par : Cyril Gambis

Cyril Gambis — Fri, 10 Oct 2008 08:01:54 +0000

C’est intéressant d’avoir une autre vision, mais je suis assez d’accord avec gl3am: il y a des concepts derrière une architecture orientée services qui vont au delà de la présentation d’un vendeur d’ESB.

A mon humble avis, il n’y a pas besoin d’ESB, et on peut utiliser du REST pour une architecture SOA, si l’on parle de SOA dans le sens conceptuel (une application devenant une sorte de « mashup » qui fait appel à d’autres entités/modules pour offrir toutes ses fonctionnalités, par opposition aux applications legacy à base de batch et de bases de données centralisées).

REST/SOAP/JMS ou autre, c’est technique; SOA représente aussi une manière d’organiser ses applications (par exemple remise en cause de l’encapsulation pour les langages objets, avec traitements et règles métiers dans les services et échanges de POJO entre services).

Par : Bruno Paul

Bruno Paul — Thu, 09 Oct 2008 18:20:34 +0000

gl3am : pour la discussion sur les patterns SOA, voir la reference:
http://www.eaipatterns.com/docs/SoaPatterns.pdf

Ce qui manque le plus désormais, c’est une démarche REST pour le SI. Qui publie le premier billet sur le sujet ?

Par : gl3am

gl3am — Thu, 09 Oct 2008 10:51:16 +0000

Il ne faut pas se limiter aux discours marketing de vendeur d’ESB. Il y a vraiment des concepts intéressants à la fois dans le pattern d’architecture SOA et dans la démarche SOA qui est permet une certaine approche du SI. La différence entre ces deux notions pattern SOA et démarche SOA n’est pas souvent faite et est source de beaucoup d’ambiguïtés.