SOA : Quand utiliser des WebServices, et pourquoi ?
Faites nous part de votre retour d'expériences

Le , par ego, Rédacteur
Pour ceux qui utilises des WebServices (JAX-RPC et/ou JAX-WS) :

1- Dans quelS contextes les utilisez-vous ?
2- Dans quelS contextes ne les utilisez-vous pas ?

je recherche des infos du terrain, pas de la théorie...

Merci d'avance


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de inconnu652000 inconnu652000 - Membre habitué https://www.developpez.com
le 19/10/2009 à 12:27
Citation Envoyé par ego  Voir le message
Dans un système informatique, on ne développe pas un service métier pour que les autres l'utilisent. On fait ce que l'on appelle de l'urbanisation, c'est à dire que l'on donne des responsabilités à des applis. Ensuite, si on doit faire qq chose qui est sous la responsabilité d'une autre appli, et bien c'est à cette appli qu'on le demande et ce n'est pas au petit bonheur la chance.

Une discussion que je vais peut être lancer un de ces 4, la réutilisation métier au niveau d'un SI CA N'EXISTE PAS

Oui c'est jouer sur les mots. Une application apelle le service adéquat au lieu de recoder .... C'est équivalent a dire apeller l'application responsable du service métier. Si on ne sais pas qu'elle existe -----> On recode. On ne vit pas dans un monde parfait.

Je connais des cas ou une problématique métier partagée par différentes applications du SI à été centralisée car l'urbanisme a été repensé.

Donc des bouts de code quasi identique vont disparaitre de ces applications (lire des fichiers plats, envoyer des email ....) !!!

Par contre je suis assez d'accord il est difficile de faire de la réutilisabilité métier. Mais souvent comme le disait une personne au dessus certaines applications sont redondantes pour des raisons politiques, règlementaires voire même techniques ou les deux (banques régionales ....)

Faut pas être catégorique.
Avatar de inconnu652000 inconnu652000 - Membre habitué https://www.developpez.com
le 20/10/2009 à 16:23
Citation Envoyé par ego  Voir le message
Je répondais au post d'avant où la personne parlait de service métier réutilisé par les autres.
Je n'aime pas cette notion de réutilisation quand on parle de services métier rendus par des applications.
Au niveau du SI, on se doit de réfléchir aux applications qui vont le composer. A chaque application, on attribut des fonctions métier = des responsabilités. On a par exemple un système de gestion des contrats X, Un système comptable, un système de gestion des éditions papier,.... Ensuite, si une application (système) a besoin de réaliser une fonction, elle a OBLIGATION de faire appel à l'application qui a la responsabilité de rendre cette fonction. Il s'agit donc d'un choix réfléchit, on parle d'urbanisation; ce n'est pas de la réutilisation mais simplement de l'utilisation.

Je préfère donc parler de réutilisation pour des choses "techniques". Encore que même là, se définir des frameworks techniques et les utiliser au niveau de chaque application peut aussi être qualifié d'urbanisation technique. Mais je crois que l'on utilise pas trop ce terme d'urbanisation dans le monde technique.

Oui mais cela reviens au même il s'agit d'utiliser un "runtime" c'est à dire une application qui remplit ce rôle et qui tourne sur une archi matérielle donnée ...

Mais supposons que tu embarques ce runtime au complet dans ton application pour des raisons xy tout en accèdant à la bonne source de donnée ?? et tout ça de façon maitrisée ...

Tu as fait de la réutilisation d'un composant métier, même si c'est pas SOA comme façon de faire, ça reviens au même ...

D'ailleurs supposons la règle métier d'entreprise lambda suivante :
Tous les clients doivent être majeur, de sexe masculin, mesurer plus de 1m65 bla bla bla .... Le niveau d'exigence est tel que cette règle doit être vérifiée partout !

Pour tester cette règle dans la multitude d'applis de ton SI, ce serait un anti pattern que d'apeller le "service client" à chaque fois ! C'est plus facile de prévoir des composants métiers ré utilisable sous une forme ou une autre (conception uml, jar, code source PHP ...., documentation)

Non ??

Attention, je suis d'accord sur les principes d'urbanisation ! Je disais juste ce que je voyais dans la PRATIQUE pour ce qui est de l'utilisation de services web, je n'ai pas dit que c'était bien
Avatar de ego ego - Rédacteur https://www.developpez.com
le 20/10/2009 à 19:57
Tous les clients doivent être majeur, de sexe masculin, mesurer plus de 1m65 bla bla bla .... Le niveau d'exigence est tel que cette règle doit être vérifiée partout !

Mais cela n'a pas de sens !!
On ne vérifie pas "partout" ce genre d'exigence. Une "règle de gestion" est attachée à un contexte et une application est chargée de gérer ce contexte. Par exemple, ta règle est applicable à la souscription d'un contrat X et pas Y. C'est donc le système qui gère les contrat X qui va la vérifier et personne d'autre, personne.

Ce que j'essaye d'expliquer c'est que l'on a pas des trucs qui se baladent comme ça dans un SI. On a des appli réfléchies qui ont des responsabilités claires et choisies.

Et donc, la réutilisation métier, ça n'existe pas, j'insiste
Avatar de Patriarch24 Patriarch24 - Membre expérimenté https://www.developpez.com
le 21/10/2009 à 11:01
la réutilisation métier, ça n'existe pas

La réutilisation métier, ça existe. Les frameworks de traitement d'images sont un exemple de réutilisation d'outil métier (métier : traitement d'image). À un niveau plus élevé, les processus métiers peuvent très bien être réutilisables (processus de fabrication de produits en kit, d'impression de livres, etc...).

Au sein d'un même SI, ça existe aussi. L'approche SOA vise à réutiliser des services, appelables depuis plusieurs applications, de manière découplée, avec des responsabilités propres. Ca s'appelles de l'urbanisation (c'est le terme consacré), mais au fond il s'agit d'une forme de réutilisation !

On pourra toujours argumenter en disant que cela ne se joue pas au niveau du code, mais je n'ai pas parlé de réutilisation de code, mais bien de services et processus métier.

Pour terminer, il existe de nombreux articles parlant de réutilisation de processus et services métiers.
Avatar de wiztricks wiztricks - Modérateur https://www.developpez.com
le 21/10/2009 à 21:59
Bonsoir,
Citation Envoyé par inconnu652000  Voir le message
Oui mais cela reviens au même il s'agit d'utiliser un "runtime" c'est à dire une application qui remplit ce rôle et qui tourne sur une archi matérielle donnée ...

Mais supposons que tu embarques ce runtime au complet dans ton application pour des raisons xy tout en accèdant à la bonne source de donnée ?? et tout ça de façon maitrisée ...

Tu as fait de la réutilisation d'un composant métier, même si c'est pas SOA comme façon de faire, ça reviens au même ...
...

La différence est dans le type de liaison et les implications sur le couplage entre le runtime et l'application qui les utilise.
A court terme le résultat est identique, la différence s'il y en a se verra dans les évolutions, les mises à jour des différents composants qui pourront se faire plus ou moins facilement.
Mais SOA n'a pas pour objectif de remplacer tous les interfacages possibles entre composants, c'est une techno qui s'ajoute aux "anciennes" et qui sur certains aspects pourra être plus pertinente.

- W
Avatar de wiztricks wiztricks - Modérateur https://www.developpez.com
le 21/10/2009 à 22:12
Bonsoir,

Citation Envoyé par Patriarch24  Voir le message
Au sein d'un même SI, ça existe aussi. L'approche SOA vise à réutiliser des services, appelables depuis plusieurs applications, de manière découplée, avec des responsabilités propres. Ca s'appelles de l'urbanisation (c'est le terme consacré), mais au fond il s'agit d'une forme de réutilisation !

Hmm... je ne suis pas tout à fait d'accord.
L'approche SOA (et ROA) permet de construire des interfaces au dessus des services qui vont permettre non pas de les ré-utiliser mais plus précisément de les utiliser... depuis, dans des contextes différents.

Note: C'est un peu la même chose qu'une DLL, la différence est dans les qualités, le type de la glue: couplage faible et accessibilité depuis le web plutôt que scotchée à l'application liée à sa DLL.

- W
Avatar de ego ego - Rédacteur https://www.developpez.com
le 24/10/2009 à 10:48
Citation Envoyé par Patriarch24  Voir le message
Ca s'appelles de l'urbanisation (c'est le terme consacré), mais au fond il s'agit d'une forme de réutilisation !

Urbanisation tout à fait, mais pas réutilisation. Je n'aime pas le mot réutilisation car cela fait soit magique, soit opportuniste, soit coup de bol on a trouvé un truc qui peut nous servir,...Alors que l'urbanisation n'a rien d'un coup de bol, c'est quelque chose de réfléchit. On ne fait pas appelle à tel service de tel application parce que l'on a une une "illumination" mais bien parce que pour faire le truc rendu par le service en question on a l'OBLIGATION de faire appel à CE service.

Citation Envoyé par Patriarch24  Voir le message

Pour terminer, il existe de nombreux articles parlant de réutilisation de processus et services métiers.

Il faut connaitre le contexte réel de ces articles pour se prononcer sur ce qu'ils disent vraiment. Et tu sais, il y a plein de vendeurs de rêve et plein de consultants slidewares qui ne maitrisent en fait pas ce qu'il disent dans leur slides......car les slides ça ne bug pas, ça n'est pas déployé en production...
Avatar de Luc Orient Luc Orient - Membre émérite https://www.developpez.com
le 24/10/2009 à 14:56
Citation Envoyé par Patriarch24  Voir le message
La réutilisation métier, ça existe. Les frameworks de traitement d'images sont un exemple de réutilisation d'outil métier (métier : traitement d'image) ...

Avec ce genre d'argument tout devient réutilisation métier ...

Exemple :
La réutilisation métier, ça existe. Les frameworks de traitement de fichiers sont un exemple de réutilisation d'outil métier (métier : traitement de fichiers) ...
OPEN / READ / WRITE / SORT / MERGE ... etc ...

Tout est dans tout et réciproquement ...
Avatar de inconnu652000 inconnu652000 - Membre habitué https://www.developpez.com
le 27/10/2009 à 11:34
Tout dépend ce que l'on appelle "métier" ....

Ce qui est technique pour une entreprise peut constituer le cœur de métier d'une autre ...

C'est vrai qu'il y a la théorie et la pratique. Donc ok pour la non réutilisation métier je suis d'accord (sinon on aurait plus de travail lol) mais dans la réalité ...

Vraiment j'ai des tas d'exemples de progiciels utilisés de manière a peine différente dans plusieurs secteurs d'une entreprise. Mais bon pour moi le débat est clos. Car en disant appeler une application au lieu de re-coder je pensai à ce que font les développeurs au lieu d'appliquer la théorie SOA ...
Avatar de egondragon egondragon - Membre à l'essai https://www.developpez.com
le 25/08/2011 à 10:06
Bonjour

Pour revenir sur cette vielle discussion sur le WebServices et leur utilité en particulier si on compare avec REST, je dois réfléchir à une architecture SOA devant publier des services aux applications externes.
J'ai du mal avec cette notion de WebServices (je ne vois pas du tout à quoi ça sert en fait)
Pour moi dans la mesure ou des applications JAVA doivent communiquer les moyens suivants existent déjà :
- JMS, avec des messages XML
- Socket en Java
- Utilisation d'un ESB d'entreprise
Que va amener exactement cette notion de WebServices ?

Il s'agirait d'encapsuler le trafic client dans du HTTP pour passer les firewalls qu'on dit
Mais dans ce cas autant mettre en place un serveur Web et attaquer le tout avec des bêtes requêtes HTTP, plus des Servlets derrière et enfin la partie purement applicative
(une archi MVC classique)

Par ailleurs l'architecture SOA se dit orientée services mais quels sont les avantages ?
Le seul point nouveau qui m'apparait à moi c'est le BPMN, c'est à dire la modélisation métiers des applications, découpage en processus , ...etc.

Tout le monde parle d'HTTP/WebServices, mais du coup le protocole SOAP va faire quoi ?

En général j'ai du mal à voir ce que cette architecture va amener en regard de la complexité que celà induit

NB : je pars de Corba, donc mes questions doivent sembler triviales mais tant pis

Cordialement
Avatar de ego ego - Rédacteur https://www.developpez.com
le 25/08/2011 à 18:41
Ben imagine que les WebService avec SOAP comme protocole c'est le Corba d'aujourd'hui.
Un client PHP pourra appeler un serveur Java par exemple
Si tu es sûr de ne faire que du Java-Java, tu n'es pas obligé de faire des WebService SOAP, des EJB font l'affaire et c'est plus simple que les WebServices car tu as la sérialization Java en standard sans aucune contrainte
Offres d'emploi IT
Ingénieur H/F
Safran - Ile de France - Moissy-Cramayel (77550)
Data scientist senior H/F
Safran - Ile de France - Magny-les-Hameaux (Saclay)
Architecte sécurité des systèmes d'information embarqués H/F
Safran - Ile de France - 100 rue de Paris 91300 MASSY

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique ALM