Discussion :

[sakli]

Bonjour ,

je commence d'implémenter une application on utilisant le SOA, mais je trouve un problème avec le Design Patterns.

- Quelle est la relation entre SOA et le Design Patterns?
- Comment je choisie un Design Patterns?

Merci

[el muchacho]

Ca n'a pas grand sens, cette question.
SOA, c'est déjà un design pattern, non pas de conception, mais d'architecture, donc à un niveau au-dessus.

On ne choisit pas des design patterns de conception pour le plaisir, mais au moment de la conception, pour la rendre plus simple/extensible/modifiable/etc.

Visiblement, tu n'as pas trop l'air de savoir ce que c'est que la SOA, ni même ce que c'est que la conception OO. Peut-être n'est ce pas ton rôle de te poser ce genre de question. Celui qui se la pose, c'est l'architecte. Ceci dit, pour commencer à comprendre, tu peux lire "Design Patterns tête la première".

Au passage, l'architecte qui va faire du SOA a intérêt à bien connaitre J2EE et/ou le framework Spring et un design pattern très utile nommé "injection de dépendance".

[hed62]

SOA, c'est déjà un design pattern, non pas de conception, mais d'architecture,

SOA = architectural pattern quoi

Effectivement on ne choisit ni SOA, ni MVC, ni aucun design pattern pour dire d'en faire, sinon c'est que l'on subit un effet de mode, et c'est très nocif pour le projet (enfin, 1 chance sur 2)

SOA a intérêt à bien connaitre J2EE et/ou le framework Spring

Ou tout autre environement de développement permettant de le faire, comme C#/WCF.

[el muchacho]

Oui, autant pour moi. J'associe SOA avec le monde Java un peu abusivement

[sakli]

Bonjour,
pour vous avez dit que SAO avec le monde Java et abusivement? je pense que le meilleur implémentation se fait avec la Java.

[Keihilin]

Ca n'a pas grand sens, cette question.
SOA, c'est déjà un design pattern, non pas de conception, mais d'architecture, donc à un niveau au-dessus.

Mouais...Je suis moyennement d'accord avec ça.
Un "Pattern" est une solution éprouvée à une problématique récurrente; solution dont l'implémentation est connue et très peu variable hormis quelques spécificités du langage cible.

En ce sens, SOA n'est pas un "pattern", c'est une philosophie architecturale.

Au passage, l'architecte qui va faire du SOA a intérêt à bien connaitre J2EE et/ou le framework Spring et un design pattern très utile nommé "injection de dépendance".

J'ai beaucoup de mal à voir la corrélation "obligatoire" entre Spring/IoC et SOA

[sakli]

oui le SOA est une philosophie.

Mais je veux allez un peux loin dans la pratique avec le framwork de J2EE.

exemple Spring ...

[el muchacho]

Mouais...Je suis moyennement d'accord avec ça.
Un "Pattern" est une solution éprouvée à une problématique récurrente; solution dont l'implémentation est connue et très peu variable hormis quelques spécificités du langage cible.

En ce sens, SOA n'est pas un "pattern", c'est une philosophie architecturale.

C'est une *solution* architecturale. Dont le principe est de séparer les responsabilités en services communiquants ("diviser pour mieux régner"). On peut tout-à-fait considérer cette solution comme un pattern, de même que le modèle client-serveur ou mainframe-terminaux sont des patterns d'architecture. Ces architectures répondent parfaitement à ta définition de "solution dont l'implémentation est connue et très peu variable".
Après, ce n'est qu'une question de définition. Tu es en droit de considérer que mon usage du terme "pattern" (motif en français) est inapproprié, bien que le terme soit lui-même volontairement relativement flou.

J'ai beaucoup de mal à voir la corrélation "obligatoire" entre Spring/IoC et SOA

Il n'y a pas de corrélation à proprement parler, mais c'est une alternative à JEE, dont les applications sont très souvent des applications d'entreprise (si ça signifie qq chose, p-ê en opposition aux applis desktop), domaine où s'appliquent les archis SOA.