Discussion :

[loicmidy]

bonjour,

je n'ai pas trouvé sur internet de littérature très précise sur les cas d'utilisation pertinent des web services d'un point de vue architecture.

Dans le cas suivant : des données métier sont stockées dans une BDD interne à l'entreprise et on veut les afficher sur un site web de diffusion , est il pertinent de mettre en place une solution à base de web services? Personnellement j'ai des doutes.

Qu'en pensez vous?

Il me semble que ce type de solution est pertinent plutôt dans les cas suivants :
- je comprend qu'on mette en place des web services pour des raisons d'inter opérabilité entre applications aux techno différentes
-je comprend qu'on fasse des web service pour des briques logicielles qui sont utilisées de manière transverse par de nombreuses applications.

[Logan Mauzaize]

La vocation première des Web Services est bien de gérer la communication entre systèmes plutôt hétérogènes car le protocole et les messages sont assez indépendants d'une plateforme/langage/technologie.

Toutefois les Web Services offrent tout de même quelques avantages dans le cas d'une utilisation avec des plateformes/langages/technologies homogènes :

• Facile à mettre en place, non propriétaire, débuggable, facilement testable sans déployé tout un bouzin (Par exemple, faire un client de test dans un langage de scripts).
• Ce sont des trames réseaux simples, donc on peut facilement gérer le traffic (ex DMZ) avec des routeurs (niveau 4).

De toutes façons à un instant T, il se peut que le service ne communique qu'avec des plateformes/langages/technologies homogènes, mais cela peut changer avec le temps. Ne pas avoir à coder/déployer une autre interface de communication est un sacré gain d'argent et de temps

[el_slapper]

Question idiote de la part d'un ignare dans le domaine : est-ce que c'est gourmand en termes d'usage réseau? Pour un usage massif(genre 16 millions d'enregistrements), est-ce que ça a un sens?

[Bousk]

Ca dépend de tes services.
16 millions d'enregistrements c'est pas mal, mais as-tu besoin de les récupérer tous en même temps ? et si oui est-ce malin de le faire comme ça ? n'y aurait-il pas une autre façon de parvenir à ce résultat ?
Pourquoi pas utiliser un service qui va t'en retourner 1000, traiter ceux-là puis demander les suivants ?

Tout est à adapter ce n'est pas une solution miracle si mal utilisée.

[Logan Mauzaize]

Question idiote de la part d'un ignare dans le domaine : est-ce que c'est gourmand en termes d'usage réseau? Pour un usage massif(genre 16 millions d'enregistrements), est-ce que ça a un sens?

Autant que tout autre type de protocol
Sinon tu peux toujours compresser les données. Tu peux également les signer et les chiffrer. Il existe également un mode "flux" pour SOAP mais je n'ai jamais utilisé.

[psychadelic]

bonjour,

je n'ai pas trouvé sur internet de littérature très précise sur les cas d'utilisation pertinente des web services d'un point de vue architecture.

Quand on parle d'architecture logicielle, on est dans un ensemble de développements de produits internes à une même entreprise.

Le WebService, comme sont nom l'indique est un service utilisable via internet, et donc vers l'extérieur de l'entreprise.
C''est un "service", considéré comme tel, il ne peut véritablement être une brique dans la conception d'une architecture logicielle.

Bien sur, le Web service peut être utilisé intensivement au sein d'une même entité, comme par exemple en la gestion de stock vers la comptabilité; ou encore un système de tableaux de bord...

Cela permet d'isoler les différents systèmes, et bien sur cela implique une architecture N-Tiers en interne...

J'aurai tendance à penser qu'aujourd'hui, c'est plutôt un meilleur choix..

[ovh]

Dans le cas suivant : des données métier sont stockées dans une BDD interne à l'entreprise et on veut les afficher sur un site web de diffusion , est il pertinent de mettre en place une solution à base de web services? Personnellement j'ai des doutes.

Qu'en pensez vous?

J'imagine que le site web de diffusion a des droits restreints sur les données, par rapport à l'application interne à l'entreprise ? Typiquement les données seront sans doute en lecture seule ?
Dans ce cas, un web service a tout son sens, il agira comme un filtre d'accès aux données : il n'ira chercher que ce qui est nécessaire et interdira toute modification non explicitement prévue.

Tu envisageais quoi sinon ? Un cluster ou une réplication de base de données ?

[Bluedeep]

Autant que tout autre type de protocol

Euh .... il faut quand même préciser que l'avantage d'intéropérabilité offert par les ws se paye par un protocole effroyablement verbeux du point de vue de la sérialisation des objets.

Bref, un ratio charge utile/charge totale pas franchement bon.

Ce qui fait qu'il est assez logique d'être réticent à leur usage dès l'instant où aucune des deux contraintes suivantes n'est présente :

- opérations à travers internet
- opérations entre architectures techniques hétérogènes.

[Logan Mauzaize]

Si on opte pour le protocole HTTP, il existe le mode "Deflate" qui permet de compresser les données.
On le fait avec un Apache en frontale, ca marche très bien !

Pour les autres protocoles de transport, ca doit également être disponible.


Concernant les architectures techniques hétérogènes, je ne suis pas tout à fait d'accord. Je ne sais pas comment ce fait le "RPC" sur d'autres technos, mais en Java, ils sont revenus à "XML RPC"/"SOAP" comme méthode standard pour faire du "RPC" en lieu et place de "RMI".
Ils considèrent donc que faire du "RPC" entre deux programmes Java est "mieux" que leur protocole propriétaire.

Et comme je le disais c'est plus facile de gérer/filtrer/sécuriser des "trames" HTTP (ex: avec des routeurs niveau 4) que d'autres protocoles. Ce qui permet de mieux contrôler le trafic réseau dans une infrastructure.

Et puis on ne sait jamais de quoi l'avenir sera fait. Faire un choix fermer parce qu'à un instant T, il y avait seulement deux applis en .Net, ca peut être un risque non négligeable en fonction de l'importance des services rendus par ces applications, voir celles à venir.

[omarcisses]

Tout dépend des politique de l'entreprise dans le long termes. Je te donne un exemple imaginons que dans le futur, ils voudrons mettre en place un système multiplateformes (phone, tablette etc. ) je pense qu'il sera plus judicieux d'exposer le métier par web service pour éviter de le faire pour chaque plateforme. donc tout dépend du contexte et de la politique de l'entreprise.