Discussion :

[tit_nouveau]

Bonjour,

Je tente de comprendre le SOA depuis un moment. Mais il y a certains points qui restent obscurs.

1 - Jusqu'où peut s'étendre un service ?
Est ce que le CRM est un service ? Quand j'ai lu les différentes documentation, il semblait plus que chacun des processus contenu dans le CRM (par exemple, créer un client, passer une commande, etc...) étaient des services. Mais si c'est le cas, ça veut dire que chacun de ces processus peut être utilisé indépendamment des autres ? Je pourrais par exemple utiliser le service contenant "passer une commande" en le combinant avec un autre service que je n'ai pas codé et qui remplit le processus "créer un client" ?
J'espère que vous voyez où je bloque.

2 - Par ailleurs, je ne comprends pas pourquoi est ce que l'on se met à faire du SOA en amont alors qu'au niveau de la base de données, tout reste en monolithique ? Je me demande en fait pourquoi est ce que la base de données ne serait pas elle aussi éclatée ? S'il doit être possible de remplacer le service "créer un client", cela voudrait dire que les entities correspondants ne devraient plus exister et, par conséquent, les tables associées dans la base de données non ?

3 - Est ce que je ne suis pas en train de tourner autour de l'ESB ? Ou mon problème c'est la granularité d'un service ? Au secours !

4 - C'est la dernière... Quand vous créez un service : vous ne pouvez pas demander en paramètres des objets métiers qui vous sont propres. Vous devez passer par des messages n'est ce pas ? Est ce que l'interface de mes services doivent par exemple contenir des types simples (entier, string, etc...) ou dois je recevoir des messages de type XML et donc confirmer ma question 3 à savoir que qui dit SOA, dit ESB puisque c'est lui qui orchestre le tout ? Qui met de la colle entre les services ?

Merci à ceux qui liront !
Un grand merci à ceux qui répondront de la part de ceux qui liront et moi même !
En fait, merci tout le monde ;-) !

[wiztricks]

Bonjour,

1 - Jusqu'où peut s'étendre un service ?
Est ce que le CRM est un service ? Quand j'ai lu les différentes documentation, il semblait plus que chacun des processus contenu dans le CRM (par exemple, créer un client, passer une commande, etc...) étaient des services. Mais si c'est le cas, ça veut dire que chacun de ces processus peut être utilisé indépendamment des autres ? Je pourrais par exemple utiliser le service contenant "passer une commande" en le combinant avec un autre service que je n'ai pas codé et qui remplit le processus "créer un client" ?
J'espère que vous voyez où je bloque.

Il faut comprendre la notion de service dans sa problèmatique métier et non composant. Le CRM est un (gros) composant, créer un client est une activité métier qui aura ou pas des impacts sur le CRM, l'ERP, etc.

2 - Par ailleurs, je ne comprends pas pourquoi est ce que l'on se met à faire du SOA en amont alors qu'au niveau de la base de données, tout reste en monolithique ? Je me demande en fait pourquoi est ce que la base de données ne serait pas elle aussi éclatée ? S'il doit être possible de remplacer le service "créer un client", cela voudrait dire que les entities correspondants ne devraient plus exister et, par conséquent, les tables associées dans la base de données non ?

Si "créer un client" est un service SOA, il faudra lui associer une fonction de persistence et la base de donnée n'est pas très loin puisqu'elle participera à la réalisation du service.

3 - Est ce que je ne suis pas en train de tourner autour de l'ESB ? Ou mon problème c'est la granularité d'un service ? Au secours !

Je pense qu'il est préférable de penser SOA avec une logique de services et d'orchestration (au sens workflow). Les services vont s'appuyer sur un certain nombre d'opérations qui seront réalisée par des composants applicatifs (CRM, Oracle,...)
Suivant la complexité, un ESB pourra être nécessaire pour effectuer ces compositions.

Important
Tel que je le décris, SOA est une couche conceptuelle qui vient au dessus des composants existants. Si on se contente d'implémenter cette couche conceptuelle "en dur" on fera du SOA dit de façade...

Si cela peut avoir son intérêt, si on en reste là on n'a fait qu'ajouter de la complexité sans vraiment refondre le SI. Et la refonte du SI doit s'envisager à partir des différents référentiels (clients, produits,...) utilisés dans les transactions métiers et non pas se contenter de mettre un chapeau "au dessus" - Mais bon c'est plus cher

4 - C'est la dernière... Quand vous créez un service : vous ne pouvez pas demander en paramètres des objets métiers qui vous sont propres. Vous devez passer par des messages n'est ce pas ? Est ce que l'interface de mes services doivent par exemple contenir des types simples (entier, string, etc...) ou dois je recevoir des messages de type XML et donc confirmer ma question 3 à savoir que qui dit SOA, dit ESB puisque c'est lui qui orchestre le tout ? Qui met de la colle entre les services ?

Un service c'est une interface en général présentée sous forme XML et un medium SOAP, SMTP, ... XML est suffisament flexible pour permettre la représentation de tout types de paramètres (simples ou complexes).

Au dessus, il faut au moins un fonction d'annuaire pour déclarer le service et le localiser (UDDI).

Un ESB ajoute beaucoup de fonctionnalités au dessus de cela notament la possibilité de connecter des services qui n'ont pas été prévus pour dialoguer ensemble "nativement".
Compte tenu de sa nature, l'ESB "coordonne" mais je range cela dans les solutions plutot que le concept.
- W

[tit_nouveau]

wiztricks merci pour tes éclaircissements. Je découvre et je me pose des questions. Et comme je ne suis plus étudiants, faut que je me débrouille moi même pour trouver les réponses. Et quand je les trouve pas, j'appelle à l'aide.

Il faut comprendre la notion de service dans sa problèmatique métier et non composant. Le CRM est un (gros) composant, créer un client est une activité métier qui aura ou pas des impacts sur le CRM, l'ERP, etc.

Si "créer un client" est un service SOA, il faudra lui associer une fonction de persistence et la base de donnée n'est pas très loin puisqu'elle participera à la réalisation du service.

Je crois que je n'ai pas compris. C'est sûr qu'il faudra lui associer une fonction de persistence. Mais si on veut former un CRM en associant plusieurs services ici et là (activités métier) et qu'à un moment donné, l'activité de création d'un client est à changer (on a le droit, c'est un service et donc c'est interchangeable en autant qu'il présente la même interface) : au niveau des connexions entre services pas de problèmes mais au niveau de la base de données ? Chaque service devrait avoir une base de données embarquée ? (D'où l'éclatement dont je parlais).

Je pense qu'il est préférable de penser SOA avec une logique de services et d'orchestration (au sens workflow). Les services vont s'appuyer sur un certain nombre d'opérations qui seront réalisée par des composants applicatifs (CRM, Oracle,...)

Ce ne sont pas les composants qui s'appuient sur les services ?

Tel que je le décris, SOA est une couche conceptuelle qui vient au dessus des composants existants. Si on se contente d'implémenter cette couche conceptuelle "en dur" on fera du SOA dit de façade...

C'est ce que fait petshop soa. Enfin, c'est ce que plusieurs articles expliquent. Ils font un design objet puis par dessus, ils ajoutent une architecture SOA, des interfaces qui se contentent de regrouper les différents objets métiers et d'en faire des services.

Mais je crois que la refonte du SI dont vous parlez après rejoint mon questionnement sur la scission de la bdd de plus haut.

En tout cas, un grand merci.

[wiztricks]

Je crois que je n'ai pas compris. C'est sûr qu'il faudra lui associer une fonction de persistence. Mais si on veut former un CRM en associant plusieurs services ici et là (activités métier) et qu'à un moment donné, l'activité de création d'un client est à changer (on a le droit, c'est un service et donc c'est interchangeable en autant qu'il présente la même interface) : au niveau des connexions entre services pas de problèmes mais au niveau de la base de données ? Chaque service devrait avoir une base de données embarquée ? (D'où l'éclatement dont je parlais).

Imaginons que l'application métier CRM soit construite par une orchestration de services incluant "créer client".
Il faudra bien que d'une façon ou d'une autre "créer client" s'interface à la base - ce qui ne signifie pas qu'elle soit embarquée.
Une autre question est de savoir si cette interface est directe ou passe à travers un autre service qui...
Enfin, si nous modifions le service client parce que l'enregistrement "client" à un champ en plus, j'aurais quand même un problème sur les interfaces.

Ce ne sont pas les composants qui s'appuient sur les services ?

En haut j'ai les utilisateurs, plus bas j'ai l'orchestration des services métiers, plus bas les composants applicatifs qui les réalisent.
Dans ma représentation les services sont au dessus des composants et donc s'appuie sur... Mais c'est relatif.

C'est ce que fait petshop soa. Enfin, c'est ce que plusieurs articles expliquent. Ils font un design objet puis par dessus, ils ajoutent une architecture SOA, des interfaces qui se contentent de regrouper les différents objets métiers et d'en faire des services.

C'est une façon de procéder qui a le mérite de ne pas trop casser l'existant. On peut l'utiliser lorsqu'on doit intégrer une nouvelle application full SOA dans un patrimoine qui évoluera plus tard.

Mais je crois que la refonte du SI dont vous parlez après rejoint mon questionnement sur la scission de la bdd de plus haut.

Conceptuellement, vous pourriez considérer la BDD comme un service en soit. Ca multiplie les couches, mais ce n'est ni interdit ni une monstruosité en soit (j'ai bien précisé "conceptuellement" car dans la pratique, il va falloir s'adapter!)

En tout cas, un grand merci.

De rien, bon courage
- W