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
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
WebServices : Où ? Pourquoi ?
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
Hello
déjà des pistes :
- en cas de besoin d'interopérabilté : Java discute avec .Net et inversement
- avec Flex (ou toute autre techno de type RIA) : l'IHM riche discute avec le serveur via WS quelle que soit la techno retenue côté serveur
- ...
Bonjour,
Personnellement j'ai utilisé les WS lorsque le protocole était imposé entre le client et le serveur, à savoir HTTPs. Il fallait également prendre en compte la possibilité de futur client en d'autre language.
J'ai participé au développement d'un WebService qui sert d'interface pour interroger une base de donnée à partir de critères définis.
J'ai travaillé sur une appli multi-couches, dans la couche métier ou service, nous appelions un WS en donnant juste le nom de du service et les paramétres et nous récupérions le résultat sous forme d'un bean c'est tout ce que j'avais avec les WS mais j'aimerais bien enrichir mon expérience avec
Merci;
à toi
Je rajouterai que le projet n'est pas vraiment une réussite. Néanmoins la cause des problèmes que nous avons rencontré n'est pas dû au choix des WebServices mais à des problèmes d'architecture logicielle.Envoyé par verbose
En effet, le développement d'un WebService en Java passe généralement par un framework qui génère une api permettant d'encapsuler les appels SOAP.
Le problème est que notre client nous a imposé l'utilisation d'une deuxième api pour l'accès aux données. Du coup, l'emboîtement de ces deux apis s'est révélée pour le moins acrobatique.
La difficulté ayant été sous-estimée au départ, l'architecture du projet n'a pas réellement fait l'objet d'une réflexion approfondie. Nous nous sommes finalement retrouvé avec une véritable coulée de lave et des bugs très difficiles à analyser.
Pour résumer, le choix d'un WebService est en soi une bonne idée dans notre cas, mais il aurait du s'accompagner d'une véritable réflexion sur les technologies d'accès aux données et l'architecture. Comme dans tout projet somme toute.
@verbose
Vous auriez du regardé du coté de JAX-RS avec du REST, c'est pas mal pour accéder aux données, tu peux faire des opérations CRUD.
Dans ma boite on s'en est servi pour créer la couche d'accès aux données (DAL, Data Access Layer).
On a utilisé des WS pour lier notre application lourde (WPF), notre intranet (ASP. NET), nos applications mobile (CF), et nos différentes petites applications (Ex. : écran tactile de pointage ...)
Toutes nos applications utilisent la même base de donnée et toutes les données sont croisées.
Donc grâce aux WS on a développé une seul couche d'accès aux données.
Voilà pour moi.
Mon expérience personnelle se limite plutôt à une mauvaise utilisation des WS. J'ai bossé sur un projet où nous avons mis en place les WS (fallait obéir aux directives groupes). Or, pour notre projet ce fut fastidieux car en fin de compte, nous nous sommes rendus compte que nous aurions pu nous limiter à faire du REST. Les méthodes GET et POST auraient suffi avec notre IHM Flex.
Je pense qu'avant de faire un choix WS, il faut savoir quel sera le niveau de service.
Un peu pareil que pour csperandio, dans ma boite (appli de gestion avec BDD centralisée, les WS faisaient DAL) on a virer les WS pour mettre de la serialisation (.net), on y a gagner en perf, en souplesse et en temps de dev.
Si c'est pour coder client et server dans le meme langage, sans besoin d'interopérabilité je ne voit pas trop l'interet des WS mise a part d'éventuels problemes de firewall ou trucs du style (ceci dit je ne suis pas un expert la dedans, j'ai peut etre raté un truc...)
D'ailleurs si quelqu'un peu m'éclairer sur l'interet des WS dans un tel cas, je suis preneur
Quelques fois, je me demande si les WS c'est pas le truc un peu "mode". Dès que tu dis que tu fais une appli distribué, on te dit "faut faire du WS"Avant même de savoir, quel sera l'intérêt.
Dans une mission, j'avais bossé sur un web-services avec axis 1.1.
Le ws était interrogé par un client lourd en fait par le client du projet et codé en .NET. De plus, j'avais codé un petit programme en java pour mes test.
Pour moi un ws convient si l'on souhaite exposer un service "à l'extérieur".
Et est à éviter dans une exposition interne entre autre par le fait qu'il ne soit pas transactionnel, pour une exposition interne distribuée mieux vaut du JMS.
Exact.Pour moi un ws convient si l'on souhaite exposer un service "à l'extérieur".
Typiquement, amazon correspond pour moi a une bonne utilisation des WS:
Ils fournissent un Service(justement
Faut vraiment que ce soit assez générique et destiné a être réutilisé par des tiers pour valoir le coup je pense
Ouep, l'effet de mode joue pas mal en informatique, je pense aussi au XML qu'on voit a toutes les sauces... mais bon c'est pas le sujet du débatQuelques fois, je me demande si les WS c'est pas le truc un peu "mode". Dès que tu dis que tu fais une appli distribué, on te dit "faut faire du WS" Avant même de savoir, quel sera l'intérêt.
Hello,
gros projet d'architecture asynchrone (utilisation MSMQ+webservices), en .Net (WCF). Nous avons pu constaté que l'utilisation des webservices permet de limiter la redondance de code. Nous avons développé une couche "business" pour tous les services que nous utilisions (principalement du mapping entre différentes valeur ou entité, mais aussi accès db).
Pour ma part je trouve cela très satisfaisant comme solution si l'on sait à l'avance que nous aurons différentes apps qui utiliseront ces services et j'ajouterais que c'est tellement simple de publicer un WS... pourquoi s'en priver.
Pour ma part les web services ont été mis en place suite à une réorganisation du système d'information. Ils servaient principalement pour récupérer des informations en base de données mais également pour interagir avec des progiciels.
Généralement des clients lourd .net interagissait avec les web service jax-ws.
Tous ce fonctionnement était couplé avec l'utilisation d'un ESB.
Enfin une architecture orienté service classique.
Ses choix on principalement été fait pour bénéficier d’un couplage faible entre les applications.
Tetar
Web Services pour la mise a jour de logiciel
De mon cote, j'utilise les web services pour la mise a jour d'un logiciel. Le service est accessible via Internet et les clients interrogent regulierement le serveur pour savoir si une nouvelle mise a jour doit etre telechargee. Cela permet aussi de ternir a jour une liste de tous les sites avec la version, l'adresse IP, etc... Un deuxieme service permet de lister tous les sites grace a un client Java Swing et de selectionner les sites a metter a jour et la version. Techniquement, avec JAX-WS, il suffit simplement d'annoter la classe contenant les methodes avec @WebService. A cette simplicite de creation s'ajoute le fait que toute la couche de transport est entierement geree par la librairie donc tout est tres simple au depart. JAX-WS remplace JAX-RPC pour les Web Services de type RPC (Remote Procedure Call) utilisant SOAP et generalement HTTP.
REST est plus simple et oriente document mais moins bien outille donc demande plus de travail et n'est pas aussi avance dans le domaine de la qualite de service (QoS) offert par les standards SOAP WS-*: security, reliability...
Enfin, la solution de faire un simple requete HTTP de type POST a une URL correspondant a une simple Servlet est une version simplifiee de REST. J'ai aussi fait cela pour un service tres simple qui transmet une ligne chaque mois contenant les resultats de chaque magasins, ceci pour etre consolide sur un serveur. Cela demande plus de code donc plus de tests et plus de bugs eventuels a corriger.
Tout ca pour dire qu'un Web Service ca sert a tout et n'importe quoi et que ce n'est pas bien complique.
Cependant, la difficulte est ensuite l'evolution. Je viens actuellement de faire evoluer un service cree a partir d'une classe Java qui a pour parametre une entite (JPA). Si je modifie l'entite pour enlever un champ inutile, je casse la compatibilite, le service web ne presente plus la meme interface la prochaine fois que je le deploie donc plus rien ne marche.
Ce qu'il manque c'est des strategies pour faire evoluer les services web.
La solution pour pouvoir facilement evoluer est de commencer par la definition d'un fichier WSDL mais la, cela devient prise de tete, reserve aux amateurs de XML, namespace, XSD, etc... J'ai un peu joue avec BPEL juste pour le fun, la aussi, quand cela ne va pas, c'est tres vite la prise de tete et reserve aux gourous du XML.
merci pour vos avis.
Pour l'histoire du versioning de WS, en fait il faut décorréler le WS lui-même et l'implémentation qui fait réellement le boulot (une classe POJO ou équivalent en .Net ou autre). Il est préférable d'avoir autant de WS que de versions. Le code du WS fait ensuite de la délégation vers la classe qui réalise réellement le boulot. Charge au WS de s'arranger avec la nouvelle version de la classe qui fait le boulot (car c'est elle dont l'interface va changer).
Bref, tout ça c'est le principe de la délégation et/ou du pattern "Business Facade"
N'est ce pas un problème de toutes architectures construites à partir de composants (pouvant évoluer indépendamment les uns des autres) ?Ce qu'il manque c'est des strategies pour faire evoluer les services web.
J'entends que certaines proposent des outils de "versioning" ou autre permettant de gérer ces évolutions mais tout dépendra de la pertinence du découpage: nombre de composants, couplage entre fonctionnalités et des modalités d'évolution choisies.
Sur ce dernier point, on se focalise trop souvent aux seules fonctionnalités de la version + 1. Je pense que dans ce contexte, il faut travailler avec en ligne de mire, les 2 versions majeures à venir dans les 2/3 ans et livrer aussi des mises à jour 'non-fonctionnelles' (*) qui paveront les étapes suivantes.
(*) J'entends pas là de ne pas se réduire à ne livrer que les nouvelles fonctionnalités attendues mais ne pas hésiter à retravailler le code affecté pour le mettre en ligne avec ce qu'il devra subir plus tard.
-W
Il existe des tas de raisons aussi bien fonctionnelle, architecturales voir règelmentaires qui font qu'on utilise des services web.
Exemples rencontrés sur le terrain :
1. Cas classique, une application partage son service métier voire technique (souvent un service clé de l'entreprise) avec d'autres applications pour éviter à ces dernières de le développer.
2. Echanger des infos avec des sociétés partenaires.
3. Protocoles de communication choisit entre un client lourd et une appli web.
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.1. Cas classique, une application partage son service métier voire technique (souvent un service clé de l'entreprise) avec d'autres applications pour éviter à ces dernières de le développer.
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
Répondre avec citation
Partager