Discussion :

[ego]

Bonjour,

je ne suis pas un expert des WebServices, j'ai plutôt une expérience (longue....) des architectures distribuées avec Corba, EJB (bon ok les sockets à la grande époque aussi).
Je me demande s'il est très "intelligent" de construire une architecture d'un système informatique en disant : "Tous les services offerts par les applications de mon SI seront implémentés sous la forme de WebServices (avec HTTP/SOAP)".

J'ai le sentiment que ce n'est pas forcément une bonne idée. En effet, je trouve qu'il y a une rupture de paradigme entre l'approche objet que l'on utilise in fine au coeur de l'application, derrière les "services", et la notion de WS qui me semble orienté "documents" (ou "données"). La "tambouille" pour faire du marshalling/unmarshalling entre Java et XML (oui, nos applis sont en Java) ainsi que la déclaration des WS en WSDL et tout et tout me parait vraiment très lourd pour le concepteur/développeur.
Mon idée est qu'il est probablement préférable de s'appuyer sur des EJB (à la mode Spring = Interface+POJO+EJB-Proxy) pour distribuer les services au sein du SI (pas de rupture de paradigme, pas de problématique de marshalling/unmarshalling ou tout au moins la sérialization est "gratuite").
Je réserverrais les WS pour les services que je dois exposer en dehors de mon SI car là, je ne maitrise pas les technos de mes "clients/partenaires".

Voilà, c'est un peu rapide comme explications mais si vous avez un avis voir un retour d'expérience, ça m"intéresse vraiment.

D'avance merci

[wiztricks]

Bonsoir

Quelques réflexions à propos de vos inquiétudes.

Je me demande s'il est très "intelligent" de construire une architecture d'un système informatique en disant : "Tous les services offerts par les applications de mon SI seront implémentés sous la forme de WebServices (avec HTTP/SOAP)".

Les différences entre "architecture" (SOA) et "design" (SOAP, WSDL, REST, ...) peuvent paraître subtiles mais elles sont du même ordre qu'entre le QUOI et le COMMENT.
Mais je vous rejoins quant au constat que des WebServices tels que proposés par le 'design' WS-* est non seulement indigeste mais donne une impression de déjà vu.

En effet, je trouve qu'il y a une rupture de paradigme entre l'approche objet que l'on utilise in fine au coeur de l'application, derrière les "services", et la notion de WS qui me semble orienté "documents" (ou "données").

Définitivement.

1. WS-* est orienté orchestration de 'processus' qui emprunte beaucoup à la problématique de management des entreprises.
2. REST/ROA est orienté "ressources" et documents et emprunte pas mal au WEB, au discours académique.

Ceci dit je ne comprends pas 'rupture de paradigme': à mon sens, l'approche "objets" n'est peut être pas la plus adaptée pour aller au delà de la construction de composants (composites) logiciels.

Mon idée est qu'il est probablement préférable de s'appuyer sur des EJB (à la mode Spring = Interface+POJO+EJB-Proxy) pour distribuer les services au sein du SI (pas de rupture de paradigme, pas de problématique de marshalling/unmarshalling ou tout au moins la sérialization est "gratuite").

Il faut bien que le service offert par le "WEB service" soit 'in fine' réalisé d'une façon ou d'une autre: et pourquoi pas avec ce que vous savez déjà bien faire aujourd'hui?

A mon sens, lorsqu'on parle de Web services, on s'attache surtout à rationaliser les interfaces.

En prenant le risque de simplifier un peu trop... Pour réaliser simplement une application au dessus de Spring nous pouvons utiliser une couche MVC (Struts ou autre). Les browsers utilisateurs envoient des requêtes qui, in fine, produiront les messages HTML affichés.
Quelque soit le design retenu, un 'Web services' s'articule au même niveau.

Cordialement
-W

[ego]

Tout d'abord merci pour ton avis.
Je n'aime pas beaucoup l'usage du mot "WebService" quand on parle d'architecture et que l'on fait une différence avec le "Design" des WebServices. Je comprend bien ce que tu dis, il y a une différence entre l'archi orienté service et le design / implémentation.
Notes que l'on passe facilement du terme "orienté service" à WebService et c'est ça qui me gène.
Depuis toujours nos applications bien ou mal foutues, ont offert des "services". Ma problématique est à la fois l'efficacité du développement et la standardisation quand on veut que les autres SI nous parlent.
Dans le cas de services "interne au SI", je ne vois vraiment pas l'intérêt des WebServices (HTTP/SOAP et autres trucs WS-???). Notre SI est en Java, du front au back et on se moque de pouvoir faire des appels via d'autres technos. On n'est pas borné mais c'est juste qu'un choix de techno ça ne se change pas comme ça du jour au matin (il y a les compétences à trouver et à pérenniser)

Pour la rupture de paradigme, c'est peut être certaines implémentations qui m'ont fait dire cela. J'ai vu des implémentations où l'interface du WebService (comme on l'a au sens Java du terme) n'avait pas trop d'importance. Le WS n'avait qu'une seule méthode genre "do it" et c'est en fonction du contenu du message que le WS orientait vers des composants implémentant réellement la logique métier. Je ne trouve pas cette approche très claire dans la mesure où l'opération devant être effectuée est "caché" dans les paramètres d'appel.
Mais bon, c'est peut être un cas particulier et une mauvaise façon de faire.

J'ai d'ailleurs vu qu'avec le JDK1.6 et les nouvelles annotations on pouvait se rapprocher de ce que je connais déjà avec les EJB ou Corba.

Il n'empêche, je trouve que les WebService (i.e les WS-????, SOAP,...) c'est franchement pas très simple et à part pour communiquer avec les "autres SI", ça ne sert pas à grand chose (dans la mesure où il y a des technos plus simples).

[wiztricks]

Je n'aime pas courir après plusieurs lièvres à la fois... Je me contenterais donc de réagir sur:

Notre SI est en Java, du front au back et on se moque de pouvoir faire des appels via d'autres techno. On n'est pas borné mais c'est juste qu'un choix de techno ça ne se change pas comme ça du jour au matin (il y a les compétences à trouver et à pérenniser)

La seule question à se poser porte sur la pérennité d'un tel choix.
A court terme, vous percevez certains avantages à avoir du Java du sol au plafond. A long terme, 2, 5 10 ans, votre SI devra intégrer d'autres technologies.
Comment organiser, préparer cela?
-W

[ego]

ok, un lièvre...

Tu as raison mais qui sait si les WS seront LE truc dans 10 ans. Tu sais, ça fait 30 ans que cela tourne avec Cobol + "Corba" et ça fonctionne.
En faisant du Java + EJB à la mode Spring ( = EJB délègue au service POJO) ça me parait plus simple et pas risqué du tout....enfin selon moi.
J'ai aussi un peu peur des perfs dans cette affaire. Est-ce que l'on sait si un service implémenté avec WS/SOAP est plus ou moins performant qu'un EJB ? Et côté sécurité et montée en charge / clustering, y a t-il des différences ?

Merci encore

[wiztricks]

Tu as raison mais qui sait si les WS seront LE truc dans 10 ans. Tu sais, ça fait 30 ans que cela tourne avec Cobol + "Corba" et ça fonctionne.

Pour moi, le legacy c'est les trucs qui fonctionnent.

En faisant du Java + EJB à la mode Spring ( = EJB délègue au service POJO) ça me parait plus simple et pas risqué du tout....enfin selon moi.

Cela décrit comment sont construites les applications aujourd'hui.
Alors que la logique WS porte plutôt sur "comment" on les fait dialoguer/coopérer ensemble.
but
la granularité n'est pas la même lorsqu'on parle de construction à partir de composants et lorsqu'on parle de composants métier (ex: la paie).

i.e. Les WEB services pourront peut être vous intéresser plus lorsque vous aller devoir remplacer une application métier (style paie), i.e. un quartier entier de votre SI ou que votre DSI préféré vous demandera d'intégrer des services construits sur des "clouds" à la Amazon S3 ou EC2.
Note: le grain est un peu plus fin que les connexions vers les partenaires externes que vous envisagiez initialement.

J'ai aussi un peu peur des perfs dans cette affaire. Est-ce que l'on sait si un service implémenté avec WS/SOAP est plus ou moins performant qu'un EJB ?
Et côté sécurité et montée en charge / clustering, y a t-il des différences ?

Mêmes atouts et mêmes tares que toutes les architectures distribuées auxquelles on ajoute (souvent) une couche supplémentaire pour intégrer l'existant : garder les traitements au plus prés des données pour éviter d'être pénalisés par les délais.
-W

[ego]

ok ok
Et aaaaah ! le vieux rêve de la réutilisation et du "je vais changer de système X par Y" et vous verrez comme j'ai pensé à tout il y a 5 / 10 ans il n'y aura pratiquement rien à faire (qu'est ce qu'on était fort il y a 5/10 ans, hein !?).
De ce point de vu, l'informatique ne change pas, on essaye toujours d'attraper le gogo avec les mêmes recettes............et souvent ça marche !!

Merci encore pour cet échange

[Luc Orient]

... Tu as raison mais qui sait si les WS seront LE truc dans 10 ans. Tu sais, ça fait 30 ans que cela tourne avec Cobol + "Corba" et ça fonctionne.

Surtout quand ça dépote à 31 / 32 millions de transactions / jour ...

J'ai aussi un peu peur des perfs dans cette affaire.

Mais tu n'est pas le seul, cher et éminent collègue ... Surtout quand ça va arriver à l'accès aux données stockées sur le mainframe ... On est plusieurs à penser que là ça ne tiendra pas la route ...

[ego]

Ben disons que l'on peut faire aussi bien en Java qu'en Cobol mais à condition de ne pas monter une usine à gaz (je connais des cas où la réécriture en Java mais surtout la "re-conception" de l'application a fait gagner beaucoup en perfs et baissé la conso machine).
En fait, comme toujours c'est une affaire de conception d'application et quelque soit le langage on peut toujours faire des trucs tordus qui rament.

En ce qui NOUS concerne, on verra bien avec le bench qui se prépare mais ça ne me dit rien de bon..............mais je suis parfois mauvaise langue alors....