Discussion :

[ego]

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

[palmipod]

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
- ...

[Akira]

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.

[verbose]

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.

[lionel84]

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

[algerian]

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.

[csperandio]

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.

[vincepoencet]

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

[csperandio]

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.

[nfrancois]

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.

[vincepoencet]

Pour moi un ws convient si l'on souhaite exposer un service "à l'extérieur".

Exact.

Typiquement, amazon correspond pour moi a une bonne utilisation des WS:
Ils fournissent un Service(justement), qu'on peut attaquer depuis n'importe quoi dans des applis diverses sans trop savoir comment ça marche derriere.

Faut vraiment que ce soit assez générique et destiné a être réutilisé par des tiers pour valoir le coup je pense

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.

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ébat

[hatman]

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.

[cf1020]

J'utilise et je programme des webservices selon le besoin de mes applications en .Net avec la FrameWork 3.5.

Je les utilise surtout pour interroger des bases de données SQL Server qui sont online et qui ont besoin d'être rafraichis automatiquement.

Tout cela est développé en .Net 3.5, le meilleur outil de développement dans le marché de l'informatique actuellement.

[tetar]

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

[TheNOHDirector]

En fait il faut savoir ce que ton application / ton architecture a besoin

a. Si tu veux simplement faire de l'invocation à distance (machine ou jvm différente), bref une application orientée "message" (ta méthode est le signal et tes paramètres le contenu) => Alors du JAX-RPC est suffisant.

Par contre il faut absolument que tu fasses attention à l'implémentation sous-jacente, en effet ça peut être du SOAP, du RMI, du XML-RPC, etc, et forcement certaines implémentation ne sont pas compatibles entre elles!

b. En revanche si ton application / archi a besoin de features plus avancé comme de l'addressage, de la sécurité, de la validation, etc, alors JAX-WS pourra t'aider, l'idéal étant de choisir une implémentation SOAP car elle est plutôt mature.

Pour ça CXF est plutôt pas mal, c'est le fork officiel du très bon XFire.

c. Si tu as besoin de services orientés ressource, tu peux t'intérésser à JAX-RS qui est *stateless*. En gros la seule implémentation que je connaisse est le REST, c'est du POX qui circule sur du HTTP.

CXF a également une implémentation JAX-RS, celà dit ce n'est pas l'implémentation de référence, mais elle marche pas trop mal. Et elle a l'avantage d'être en développement actif.

__________
Pour info, notre archi est découpés en couche et en strates réparties sur des JVM différentes et des machines différentes, à celà s'ajoute des clients qui tapent sur des services que nous exposons. Bref une archi typiquement SOA.

Pour la communication de nos applications internes il s'agit essentiellement d'invocation d'EJB et on utilise le RMI, c'est suffisant mais les besoins pourrait évoluer et nous commander de passer à une autre solution.

En revanche pour gérer la communication et être le plus interopérable avec le client, nous utilisons les WebServices avec du SOAP.

[verbose]

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.

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.

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.

[TheNOHDirector]

@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.

[Emmanuel Lecoester]

En fait il faut savoir ce que ton application / ton architecture a besoin

a. Si tu veux simplement faire de l'invocation à distance (machine ou jvm différente), bref une application orientée "message" (ta méthode est le signal et tes paramètres le contenu) => Alors du JAX-RPC est suffisant.

Par contre il faut absolument que tu fasses attention à l'implémentation sous-jacente, en effet ça peut être du SOAP, du RMI, du XML-RPC, etc, et forcement certaines implémentation ne sont pas compatibles entre elles!

b. En revanche si ton application / archi a besoin de features plus avancé comme de l'addressage, de la sécurité, de la validation, etc, alors JAX-WS pourra t'aider, l'idéal étant de choisir une implémentation SOAP car elle est plutôt mature.

Pour ça CXF est plutôt pas mal, c'est le fork officiel du très bon XFire.

c. Si tu as besoin de services orientés ressource, tu peux t'intérésser à JAX-RS qui est *stateless*. En gros la seule implémentation que je connaisse est le REST, c'est du POX qui circule sur du HTTP.

CXF a également une implémentation JAX-RS, celà dit ce n'est pas l'implémentation de référence, mais elle marche pas trop mal. Et elle a l'avantage d'être en développement actif.

__________
Pour info, notre archi est découpés en couche et en strates réparties sur des JVM différentes et des machines différentes, à celà s'ajoute des clients qui tapent sur des services que nous exposons. Bref une archi typiquement SOA.

Pour la communication de nos applications internes il s'agit essentiellement d'invocation d'EJB et on utilise le RMI, c'est suffisant mais les besoins pourrait évoluer et nous commander de passer à une autre solution.

En revanche pour gérer la communication et être le plus interopérable avec le client, nous utilisons les WebServices avec du SOAP.

C'est le genre de réponse que j'aimerais comprendre dès sa première lecture çà à l'air plus qu'intéressant mais beaucoup trop technique en première lecture.

[wiztricks]

E
c. Si tu as besoin de services orientés ressource, tu peux t'intérésser à JAX-RS qui est *stateless*. En gros la seule implémentation que je connaisse est le REST, c'est du POX qui circule sur du HTTP.

Bonsoir,

REST peut être plus que du Plain Old XML.

En ce moment, j'évalue REST pour effectuer des échanges de données entre applications "dans" l'entreprise. C'est largement suffisant pour construire des micro-webservices, l'article mentionné montre comment faire 'plus'.

- W

[*alexandre*]

nous on l'utilise essentiellement pour communiquer avec le monde de SAP, pour l'exposition et la consomation on utilise CXF mais je me demande si on va pas retourner sur axis qui était mon choix initial car lorsque l'on doit paramétrer la consomation sur les services SAP il faut exposé en clair le user name et le password (configuration par spring oblige et pas possible à ma connaissance de bypasser le fichier de configuration de spring et cxf pour le forcer à décrypter tout ca)

et c'est franchement pas agréable quand on doit utiliser différents serveurs pour le dev, la qa et la prod ...