Discussion :

[ego]

put...n, j'ai dû attendre une réponse mais là je suis comblé

je retiens quand même les remarques de csperandio et novembre à savoir que la suppression des WS à améliorer les perfs (de l'appli et du processus de dév.) et que les WS peuvent être utilisés plutôt pour la communication avec l'extérieur.

Mon avis perso et que les arguments autour des WS sont bons. Le problème ce sont les WS eux-mêmes en tant que solution "technique" (je ne parle pas du concept de "service" ici). Cela me semble un peu compliqué en termes de dév. et probablement pas si utile dans la mesure ou la techno cliente est définie et unique. A la rigueur, si une appli sort des standards et nécessite l'accès à des services existants, pourquoi ne pas faire un WS "wrappeur" qui permet l'accès aux dits services existants (non développés initialement avec WS-xxxxx).

Mon idée derrière tout cela est que je pense que mettre des WS partout ou l'on a des "services" est un peu une solution extrême qui ne se justifie pas (tant que le dev des WS ne sera pas simplifié).
Je priviligirai les WS pour la comm avec l'extérieur = offrir qq services synchrones à d'autres systèmes d'information que le mien et éventuellement pour qq applis qui ne sont pas dans la technos retenu pour les interfaces graphiques. Dit d'une autre manière, si toutes les IHM sont réalisées en Java, tout comme le serveur, pour mettre en place des WS ?
Ne me parlez par de "oui mais pour plus tard, tu verras le boulot sera déjà préparé" car si le dév. de WS est plus compliqués que d'autres technos, cela à un coût et qui dit qu'à l'avenir il n'y aura pas un autre truc........à la mode ?

Si vous avez d'autres éclairages, je reste preneur. Par exemple une éventuelle utilisation "massive" de WS ? (vous semblez tous avoir eu une expérience mais somme toute restreintre à une seule appli, quid d'une utilisation à plus grande échelle ?)


Merci encore pour vos lumières

[ego]

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.

je ne t'avais pas lu avant ma dernière réponse.
Merci pour ce retour qui me conforte dans mes opinions.

Petite question, tu parles de communication interne et avec le client. Si cela recouvre ce que je crois, n'y a t-il pas des cas où les "services internes" sont aussi appelés par le(les) clients (tu veux dire les IHM) ?

[smoufid]

en réponse a ce point, je crois que l'utilisation des services web et a utiliser avec modération et surtout dans les SI des entreprises, par contre s'il y a communication entre entreprises le mieux et d'utiliser d'autre scenario d'échange.

[Ho(c)ine.]

dans ma boite on vient de mettre en place les ws avec Jax-ws.
Ces ws sont appelés depuis plusieurs autres applications (pour l'instant 2 autres).
La mise en œuvre m'a semblé plutôt simple, grâce notamment à JAXB pour la conversion xml / java !
Ah au fait, coté performance super !

[TheNOHDirector]

je ne t'avais pas lu avant ma dernière réponse.
Merci pour ce retour qui me conforte dans mes opinions.

Petite question, tu parles de communication interne et avec le client. Si cela recouvre ce que je crois, n'y a t-il pas des cas où les "services internes" sont aussi appelés par le(les) clients (tu veux dire les IHM) ?

En fait non, car nos clients passent par un relais apache, et les services internes ne sont donc pas exposés aux clients d'autant plus que c'est du RPC. Quant aux clients peu importe ce qu'ils ont comme applis, que ce soit une applis web ou une autre applis métier, l'important est que leur appli ne peut utiliser que les services que nous leur exposons en JAX-WS. En plus nous avons également une authentification, car tous nos clients n'ont pas le droit à tous nos services.

Je ne connais pas les services Amazon, mais je pense qu'ils ont le même genre de chose.

REST peut être plus que du Plain Old XML, si cela vous interresse jetez un oeil à l'article d'InfoQ sur lequel je suis tombé tantôt.

Indeed, c'est vrai que j'ai été restrictif, CXF gère des choses comme du MTOM, etc. En tout cas l'article est super intéréssant, comme le reste de InfoQ d'ailleurs.

[ego]

...
Ah au fait, coté performance super !

Perfs ok mais pour combien de clients simultanés et quel nombre de transactions par secondes ?

Sinon vos WS possèdent plusieurs "opérations" ?
Côté client, comment est vu le WS ? Ou dit autrement est-ce que le client sait qu'il communique avec un WS ou bien voit-il le WS comme une simple interface Java ou .Net ou... (bref, le WS est "caché") ?

[algerian]

Salut ego,

Comme je l'ai expliqué dans mon précédent post, dans ma boite on l'utilise pour divers application et sur divers plateforme (Client lourd (notre erp), Client léger (PDA), intranet , notre site web etc ...

Les pda se synchronisent via des WS (il y en a 40, a raison de plusieurs fois par jour).

Le client lourd qui compte une vingtaine d'utilisateur connectés toute la journée.

Notre intranet une cinquantaine de façon aléatoire.

Donc je pense que dans mon cas on peut dire que le projet est assez "conséquent".

Même si on a fait le tout en .net, je pense pas qu'en java ce soit si différent ?

Pour notre besoin nous sommes très satisfait du résultat, le développement n'est pas bien compliqué et la maintenance rapide, du fait que la couche data est à un seul endroit, il suffit de mettre à jour ton WS pour que ce soit répercuté partout.

Voilà pour moi.

[TheNOHDirector]

J'ai un commentaire à ajouter sur les WS, qui a son importance. L'API exposée de l'application sur laquelle je travaille trouve pour origine le monde Java, c'est un fait regretable de l'historique de notre application. En effet le WSDL qui est générée par nos servlet, n'est pas documenté, il peut changer à tout moment s'il y a des modifications même mineure au cours du développement. En bref ce n'est pas un document qu'on peut communiquer.

Je pense que la meilleure approche avec les Webservices (que ce soit JAX-WS ou JAX-RS) est d'avoir l'approche "Contract First" ou il faut en premier désigner le WSDL (le WADL si on fait du REST). De cette façon c'est le développement qui va vers le contrat, plutôt que le contrat qui vient du dev. Evidement cette approche se doit de correspondre à la manière dont vous communiquez à vos clients (humains) et bien sûr doit s'intégrer à votre méthodologie projet!

En Scrum, typiquement le refactoring est constant, et les éléments définis en début de release sont donc amenés à changer suivant les évènements.

[ego]

Que pensez vous de l'approche où en fait on a un seul WS auquel on passe : le nom d'une opération + les paramètres, tout cela dans un flux XML et c'est cet unique WS qui oriente l'exécution vers des composants "internes", "normaux".
Perso je trouve que cela n'aide pas côté "client" dans la mesure où on ne compile pas avec une "interface" précise. Résultat, il n'est pas impossible de passer un nom d'opération qui n'existe pas, idem pour les paramètres. On ne se rend compte du problème qu'à l'exécution (et non à la compilation).

Un avis ?

[nfrancois]

Je ne connaissais pas cette approche. Ca porte un nom précis ?
Je suis d'accord avec ce ton avis. Ça n'aide pas du tout coté développement.
De plus, le service n'est pas vraiment lisible comme il le serait avec une wdsl : on n'est pas sûr ni de ce qu'on appelle, ni des paramètres, ni de ce qu'on attend en retour et au final, ça m'a l'air d'être un gros bordel.
Quelqu'un à un retour de ce type d'approche ?

[TheNOHDirector]

Eh bien ego dans ton cas tu te créerais plutôt un seul service avec une seule opération. Le service recevrais alors en paramètre, le nom de l'opération à faire et les arguments demandés.

Cependant tu vas avoir un problème pour passer tes paramètres, en effet si c'est du SOAP, il vaut mieux qu'il soient décrit dans le WSDL, et dans le cas présent ça pourrait être difficile de jongler avec les frameworks connu pour générer le WSDL (ou inversement depuis le WSDL générer le code coté serveur et client).

Et dans la pratique, on construit plus un WSDL par service (naturellement il peut y avoir plusieures opérations par service).

Coté client, une fois qu'ils ont le WSDL, c'est plus facile pour eux de générer du code qui correspond à tes services exposés.

[wiztricks]

Perso je trouve que cela n'aide pas côté "client" dans la mesure où on ne compile pas avec une "interface" précise. Résultat, il n'est pas impossible de passer un nom d'opération qui n'existe pas, idem pour les paramètres. On ne se rend compte du problème qu'à l'exécution (et non à la compilation).

Ce design n'est pas "REST", c'est limite POX.
Côté API, ce qui me gène est qu'elle sera sans doute simple à mettre en œuvre depuis un client écrit avec un interpréteur et délicate à utiliser pour depuis un langage compilé.
Se rendre compte du problème à l'exécution plutôt qu'à la compilation à des effets de bords complètement différent suivant que vous êtes dans un modèle cascade ou "test driven".
- W

[psecheresse]

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.

[ego]

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"

[wiztricks]

Ce qu'il manque c'est des strategies pour faire evoluer les services web.

N'est ce pas un problème de toutes architectures construites à partir de composants (pouvant évoluer indépendamment les uns des autres) ?

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

[Tcharl]

Le web-service nous sert à modéliser une cartographie des services afin de pouvoir les réutiliser; pour cela, ils doivent absolument être stateless et fournir un service qui pourrait être potentiellement réutilisable dans un autre contexte. Il peut sagir de service internes (non sécurisés) ou externes (contenant une surcouche cxf par exemple.
La granularité du service ne doit pas être trop fine (pas de web-service toString!!^^) ceci pour une problématique de perte de perf considérable, mais pas trop forte non plus car il doit être réutilisable dans un tout autre contexte sans tricher (on ne rajoute pas un champ booleen permettant de connaître l'appelant pour lui fournir un usage détourné du service).

Personnellement, il y a un sujet intéressant dessus sur le blog de xebia à consulter impérativement avant de se lancer dans l'aventure SOA.

[wiztricks]

Ce que je voulais dire est qu'une architecture construite autour de WEB services profite de tout ce que nous avons appris dans la construction d'une architecture basées sur des composants.

Une différence est que la couche de "médiation" devient un composant en soi du SI. Au sens où nous dépassons la logique de l'EAI qui a plutôt pour vocation de régenter les échanges de façon plutôt pragmatique entre les composants.

La difficulté de ce type d'architecture n'est pas tant dans les technos mais dans la gouvernance: nous parlons de composants métiers et le nombre d'acteurs ou d'évènements qui motivent leurs évolutions sont beaucoup plus délicat à contrôler. Nous avons donc des conflits ou des tensions entre le vite fait (on pique les informations dans les BDD plutôt que de le faire en cohérence avec la logique métier qui les produits) et le suivi de règles de construction ou d'évolution de services.

- W

[Luc Orient]

Perfs ok mais pour combien de clients simultanés et quel nombre de transactions par secondes ?

... Donc je pense que dans mon cas on peut dire que le projet est assez "conséquent".

Le SI dont parle ego, il se trouve que je le connais aussi un peu ...

Et là, on parle de plusieurs dizaines de milliers d'utilisateurs, d'environ 30 millions de transactions par jour et des pointes à 1 000 transactions / seconde ...

Donc sur les performances, on peut avoir des interrogations avec toutes ces nouvelles technologies ...

[ego]

Le SI dont parle ego, il se trouve que je le connais aussi un peu ...

Et là, on parle de plusieurs dizaines de milliers d'utilisateurs, d'environ 30 millions de transactions par jour et des pointes à 1 000 transactions / seconde ...

Donc sur les performances, on peut avoir des interrogations avec toutes ces nouvelles technologies ...

Ceci dit, avec les anciennes aussi. Sauf qu'on a appris à vivre avec et que l'on se demande s'il peut y avoir mieux. On est quand même "obligé" de batir une sacré architecture avec un mainframe maousse costaud et ça, ça coute pas mal de k€ quand même.
Maintenant, il est clair que l'on se doit absolument d'être sceptique, au moins pour faire les tests qui s'imposent.
..........mais dans qq temps nous seront fixés.........encore que les problèmes dans avec les gros volumes c'est toujours du côté de la base de données que les problèmes arrivent.......mais avec de bons DBA pas de soucis

[alatox]

Il faudrait peut être un bilan de cette discussion avec des petits tutoriaux qui illustrent les cas ou vous les trouvez utiles.