IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
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

Services Web Java Discussion :

ServiceMix : Déployer un module BPEL ?


Sujet :

Services Web Java

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre confirmé
    Profil pro
    Inscrit en
    Octobre 2006
    Messages
    167
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2006
    Messages : 167
    Par défaut ServiceMix : Déployer un module BPEL ?
    Bonjour,

    J'ai créé sous Netbeans un module BPEL, il contient donc :
    un fichier BPEL (workflow),
    les wsdl des services qui sont appelés dans mon workflow,
    le wsdl du workflow
    le xsd décrivant les données entre le client et le workflow.

    J'ai buildé le module, j'ai donc maintenant un .JAR.

    Je souhaiterais l'implanter dans une application JBI pour ensuite le déployer et le tester.
    Cependant, je ne veux pas utiliser Glassfish + JAX-WS.

    Je suis donc parti dans un premier temps sur ServiceMix.
    Cependant, je ne comprend pas comment il fonctionne.

    Auriez-vous de bons tutoriaux là-dessus ?
    Ou peut être pourriez vous me proposer une autre solution qui me permettrait de créer et déployer une Application JBI ?

    Merci.

  2. #2
    Membre confirmé
    Profil pro
    Inscrit en
    Octobre 2006
    Messages
    167
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2006
    Messages : 167
    Par défaut
    Pour les plus courageux d'entre vous qui se demandent pouquoi je ne veux pas utiliser Glassfish + JAX-WS, c'est que je rencontre apparement des pb d'incompatibilités :

    J'ai déployé des Web-Services sous Tomcat + Axis2.
    Le Workflow que j'avais déployé sous Glassfish + JAX-WS utilise ces Web Services.
    Cependant, lors des tests, il plante au premier "Invoke".
    J'ai posté un message par rapport à ce pb sur le forum de SUN : http://forums.sun.com/thread.jspa?threadID=5381692

    J'ai donc pensé à une incompatibilité entre JAX-WS et Axis2 car que l'erreur dit que j'envoi du html au lieu d'envoyer du xml.
    Cependant, quand je teste le Workflow avec une api comme SoapUI, j'ai vérifié que j'envoi du xml.
    Du côté du serveur des Web Services, il ne va pas jusqu'à appeler le Web Service, il me rejette de suite ma requete.

    Voilà, c'est pas grave si vous n'avez pas suivi.

    Au final, je suis juste à la recherche d'un designer/moteur BPEL stable.

  3. #3
    oca
    oca est déconnecté
    Membre chevronné
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    354
    Détails du profil
    Informations personnelles :
    Âge : 52
    Localisation : Suisse

    Informations forums :
    Inscription : Octobre 2004
    Messages : 354
    Par défaut
    Il faut que le produit JBI ait un SE (Service Engine) pour BPEL.
    Glassfish utilise openESB qui fournit un tel composant.

    ServiceMix ce base lui sur un autre projet apache, ODE.

    La norme JBI n'impose pas le processus de déploiement, Il faut donc se baser sur la documentation du produit choisi.

    Je te conseil le livre open source esb in action qui explique pas mal de chose sur ServiceMix.

    Cela dit ton processus devrait tourner pouvoir tourner sous glassfish,A ta place, je continuerais à chercher d'où vient le problème.

    Si tu veux essayer de rester sur glassfish, ce livre là est bien
    http://www.packtpub.com/netbeans-enterprise-pack/book

    (non, je ne travail pas pour une librairie )


    A+

  4. #4
    Membre confirmé
    Profil pro
    Inscrit en
    Octobre 2006
    Messages
    167
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2006
    Messages : 167
    Par défaut
    D'accord, merci pour ces références, ça pourrait m'être bien utile.

    Je crois que j'ai une piste pour mon conflit.

    Mes Web Services sont en fait déployés sur Tomcat + Axis1 (pas Axis2).
    Mon Workflow est sur Glassfish + JAX-WS.

    Axis1 = support de SOAP1.1 uniquement.
    JAX-WS = support de SOAP1.1 ET 1.2.
    Cependant, le problème ne devrait venir pas de là, car les définitions des methodes dans les WSDL sont à la norme SOAP1.1.

    Par contre, j'ai testé un Web Service déployé sur Axis2 + Tomcat, et le workflow fonctionne (après une légère modification du WSDL du Web Service).
    J'ai regardé les WSDL définis par Axis1 et Axis2 pour mes Web Services, ils sont différents.
    Donc je me disais que les Axis utilisaient peut être des versions différentes de la norme WSDL pour générer les WSDL.

    D'où mon topic que tu as déjà trouvé ^^ : http://www.developpez.net/forums/d73...1-1-1-2-2-0-a/

    Vous en pensez quoi ?

  5. #5
    Membre confirmé
    Profil pro
    Inscrit en
    Octobre 2006
    Messages
    167
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2006
    Messages : 167
    Par défaut
    Bon en fait, j'ai trouvé : pour générer un WSDL1.1, il suffit de rentrer l'adresse "....?wsdl".
    Pour générer un WSDL 2.0, il faut rentrer l'adresse "....?wsdl2".

    Donc j'ais pu en déduire que autant pour Axis1 et Axis2, j'utilisais des WSDL1.1
    Donc mon problème n'est pas lié à la version du WSDL.

    Cependant, les WSDL générés par Axis1 et Axis2 ne se ressemblent pas.

    J'ai réussi à régler mon problème avec Axis2 en modifiant le WSDL qu'il me générait :
    ds la partie de définition du "binding", au moment où je décrit l'opération de mon Web Service, je remplace
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    <soap:operation soapAction="urn:monOperation" style="document"/>
    par
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    <soap:operation soapAction="" style="document"/>
    .

    Cependant, qd j'utilise le WSDL d'Axis1 qui n'est pas écrit tout a fait pareil, la ligne est déjà corrigée, et j'ai quand même l'erreur.

    Une idée ?
    Et c'est quoi cet argument "soapAction" que j'ai dû vider dans le WSDL généré par Axis2 ?

  6. #6
    oca
    oca est déconnecté
    Membre chevronné
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    354
    Détails du profil
    Informations personnelles :
    Âge : 52
    Localisation : Suisse

    Informations forums :
    Inscription : Octobre 2004
    Messages : 354
    Par défaut
    la soapAction permet de mettre une information sur "l'intention" de la requête soap dans le header de la requête http.

    du coup, un router qui ne saurait lire que du http (et pas du soap ou du xml) pourrait quand même prendre une action en fonction ce paramètre. Aujourd'hui, on va plutôt dans l'autre sens, le hardware commence à se débrouiller très bien avec du xml donc ce paramètre n'est plus très utile...

    http://www.w3.org/TR/2000/NOTE-SOAP-...#_Toc478383528

    A+

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 1
    Dernier message: 19/04/2013, 09h32
  2. Comment déployer un BPEL ?
    Par RudyWI dans le forum Services Web
    Réponses: 6
    Dernier message: 04/01/2011, 18h20
  3. Le module EJB ne veut pas se déployer
    Par Chabanus dans le forum NetBeans
    Réponses: 0
    Dernier message: 08/01/2010, 18h13
  4. Réponses: 0
    Dernier message: 16/06/2009, 12h04
  5. Déployer FireFox avec modules
    Par Enthau dans le forum Firefox
    Réponses: 1
    Dernier message: 13/02/2009, 11h01

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