Navigation

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

SOA Discussion :

WebServices pour tous les services du SI


Sujet :

SOA

  1. #1
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    juillet 2004
    Messages
    1 883
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2004
    Messages : 1 883
    Points : 3 500
    Points
    3 500
    Billets dans le blog
    2
    Par défaut WebServices pour tous les services du SI
    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

  2. #2
    Modérateur

    Homme Profil pro
    Architecte technique
    Inscrit en
    juin 2008
    Messages
    15 098
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Industrie

    Informations forums :
    Inscription : juin 2008
    Messages : 15 098
    Points : 25 618
    Points
    25 618
    Par défaut
    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
    Architectures post-modernes.
    Python sur DVP c'est aussi des FAQs, des cours et tutoriels

  3. #3
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    juillet 2004
    Messages
    1 883
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2004
    Messages : 1 883
    Points : 3 500
    Points
    3 500
    Billets dans le blog
    2
    Par défaut
    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).

  4. #4
    Modérateur

    Homme Profil pro
    Architecte technique
    Inscrit en
    juin 2008
    Messages
    15 098
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Industrie

    Informations forums :
    Inscription : juin 2008
    Messages : 15 098
    Points : 25 618
    Points
    25 618
    Par défaut
    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
    Architectures post-modernes.
    Python sur DVP c'est aussi des FAQs, des cours et tutoriels

  5. #5
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    juillet 2004
    Messages
    1 883
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2004
    Messages : 1 883
    Points : 3 500
    Points
    3 500
    Billets dans le blog
    2
    Par défaut
    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

  6. #6
    Modérateur

    Homme Profil pro
    Architecte technique
    Inscrit en
    juin 2008
    Messages
    15 098
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Industrie

    Informations forums :
    Inscription : juin 2008
    Messages : 15 098
    Points : 25 618
    Points
    25 618
    Par défaut
    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
    Architectures post-modernes.
    Python sur DVP c'est aussi des FAQs, des cours et tutoriels

  7. #7
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    juillet 2004
    Messages
    1 883
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2004
    Messages : 1 883
    Points : 3 500
    Points
    3 500
    Billets dans le blog
    2
    Par défaut
    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

  8. #8
    Membre expert
    Homme Profil pro
    Ingénieur Exploitation Mainframe
    Inscrit en
    octobre 2005
    Messages
    1 398
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 61
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Ingénieur Exploitation Mainframe
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2005
    Messages : 1 398
    Points : 3 004
    Points
    3 004
    Par défaut Men In Black
    Citation Envoyé par ego Voir le message
    ... 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 ...

  9. #9
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    juillet 2004
    Messages
    1 883
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2004
    Messages : 1 883
    Points : 3 500
    Points
    3 500
    Billets dans le blog
    2
    Par défaut
    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....

Discussions similaires

  1. Réponses: 6
    Dernier message: 21/04/2009, 11h03
  2. TEdit numérique pour tous les claviers
    Par totofweb dans le forum C++Builder
    Réponses: 2
    Dernier message: 10/06/2004, 12h20

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo