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 : Où ? Pourquoi ?


Sujet :

SOA

  1. #61
    Expert éminent sénior
    Bonsoir,

    Citation Envoyé par Patriarch24 Voir le message
    Au sein d'un même SI, ça existe aussi. L'approche SOA vise à réutiliser des services, appelables depuis plusieurs applications, de manière découplée, avec des responsabilités propres. Ca s'appelles de l'urbanisation (c'est le terme consacré), mais au fond il s'agit d'une forme de réutilisation !
    Hmm... je ne suis pas tout à fait d'accord.
    L'approche SOA (et ROA) permet de construire des interfaces au dessus des services qui vont permettre non pas de les ré-utiliser mais plus précisément de les utiliser... depuis, dans des contextes différents.

    Note: C'est un peu la même chose qu'une DLL, la différence est dans les qualités, le type de la glue: couplage faible et accessibilité depuis le web plutôt que scotchée à l'application liée à sa DLL.

    - W
    Architectures post-modernes.
    Python sur DVP c'est aussi des FAQs, des cours et tutoriels

  2. #62
    Rédacteur

    Citation Envoyé par Patriarch24 Voir le message
    Ca s'appelles de l'urbanisation (c'est le terme consacré), mais au fond il s'agit d'une forme de réutilisation !
    Urbanisation tout à fait, mais pas réutilisation. Je n'aime pas le mot réutilisation car cela fait soit magique, soit opportuniste, soit coup de bol on a trouvé un truc qui peut nous servir,...Alors que l'urbanisation n'a rien d'un coup de bol, c'est quelque chose de réfléchit. On ne fait pas appelle à tel service de tel application parce que l'on a une une "illumination" mais bien parce que pour faire le truc rendu par le service en question on a l'OBLIGATION de faire appel à CE service.

    Citation Envoyé par Patriarch24 Voir le message

    Pour terminer, il existe de nombreux articles parlant de réutilisation de processus et services métiers.
    Il faut connaitre le contexte réel de ces articles pour se prononcer sur ce qu'ils disent vraiment. Et tu sais, il y a plein de vendeurs de rêve et plein de consultants slidewares qui ne maitrisent en fait pas ce qu'il disent dans leur slides......car les slides ça ne bug pas, ça n'est pas déployé en production...

  3. #63
    Membre expert
    Citation Envoyé par Patriarch24 Voir le message
    La réutilisation métier, ça existe. Les frameworks de traitement d'images sont un exemple de réutilisation d'outil métier (métier : traitement d'image) ...
    Avec ce genre d'argument tout devient réutilisation métier ...

    Exemple :
    La réutilisation métier, ça existe. Les frameworks de traitement de fichiers sont un exemple de réutilisation d'outil métier (métier : traitement de fichiers) ...
    OPEN / READ / WRITE / SORT / MERGE ... etc ...

    Tout est dans tout et réciproquement ...

  4. #64
    Membre habitué
    Tout dépend ce que l'on appelle "métier" ....

    Ce qui est technique pour une entreprise peut constituer le cœur de métier d'une autre ...

    C'est vrai qu'il y a la théorie et la pratique. Donc ok pour la non réutilisation métier je suis d'accord (sinon on aurait plus de travail lol) mais dans la réalité ...

    Vraiment j'ai des tas d'exemples de progiciels utilisés de manière a peine différente dans plusieurs secteurs d'une entreprise. Mais bon pour moi le débat est clos. Car en disant appeler une application au lieu de re-coder je pensai à ce que font les développeurs au lieu d'appliquer la théorie SOA ...

  5. #65
    Membre à l'essai
    Migration vers des WebServices
    Bonjour

    Pour revenir sur cette vielle discussion sur le WebServices et leur utilité en particulier si on compare avec REST, je dois réfléchir à une architecture SOA devant publier des services aux applications externes.
    J'ai du mal avec cette notion de WebServices (je ne vois pas du tout à quoi ça sert en fait)
    Pour moi dans la mesure ou des applications JAVA doivent communiquer les moyens suivants existent déjà :
    - JMS, avec des messages XML
    - Socket en Java
    - Utilisation d'un ESB d'entreprise
    Que va amener exactement cette notion de WebServices ?

    Il s'agirait d'encapsuler le trafic client dans du HTTP pour passer les firewalls qu'on dit
    Mais dans ce cas autant mettre en place un serveur Web et attaquer le tout avec des bêtes requêtes HTTP, plus des Servlets derrière et enfin la partie purement applicative
    (une archi MVC classique)

    Par ailleurs l'architecture SOA se dit orientée services mais quels sont les avantages ?
    Le seul point nouveau qui m'apparait à moi c'est le BPMN, c'est à dire la modélisation métiers des applications, découpage en processus , ...etc.

    Tout le monde parle d'HTTP/WebServices, mais du coup le protocole SOAP va faire quoi ?

    En général j'ai du mal à voir ce que cette architecture va amener en regard de la complexité que celà induit

    NB : je pars de Corba, donc mes questions doivent sembler triviales mais tant pis

    Cordialement

  6. #66
    Rédacteur

    Ben imagine que les WebService avec SOAP comme protocole c'est le Corba d'aujourd'hui.
    Un client PHP pourra appeler un serveur Java par exemple
    Si tu es sûr de ne faire que du Java-Java, tu n'es pas obligé de faire des WebService SOAP, des EJB font l'affaire et c'est plus simple que les WebServices car tu as la sérialization Java en standard sans aucune contrainte

###raw>template_hook.ano_emploi###