Discussion :

[davels]

Bonjour,

comme évoqué dans le titre, je voudrais créer un WebService en Delphi et le client serait du Java.
Sur le plan logique, le client enverrait un code article et j'aimerais que le retour soit des fichiers (1 fichier wrl ainsi des fichiers photos pour les textures) lu en streaming par Wirefusion (Applet 3D en Java compatible avec le langage Java).

Mais j'avoue que je ne sais pas par quelle piste commencer ...
Tous les tutoriaux que j'ai pu trouver parlait de server et client en Delphi.

Avez vous des pistes?

Merci

[Aka Guymelef]

Bonjour,

ne serait-il pas éventuellement possible de transformer le fichier en chaîne de caractère via une conversion en base 64 par exemple et de retourner cette chaîne (dans un flux XML par exemple) comme retour du WebService ?

[Rayek]

Je ne comprend pas ton problème ??

Comment créer un client SOAP en java : http://jp-clair.developpez.com/artic...E/webServices/

Comment créer un webservice en delphi : http://azanetti.developpez.com/webservice/

[davels]

le problème en soit, c'est que je n'y connais rien en Webservice!

J'ai une idée de base et je sais que le Webservice est une bonne solution à mon problème!

Je vous explique ma problématique.

Nous avons un logiciel qui permet de faire de la visualisation de nos articles commerciaux en 3D. Ce logiciel peut être contrôlé via ActiveX et permet l'export des articles vers des formats tel que 3ds, wrl, dxf, dwg, ...

Mon idée est la suivante, lorsque l'on est dans un navigateur internet, on tape l'adresse avec en paramètre le code article et j'obtiens en retour une applet Wirefusion qui permet dans son applet de la programmation Java.
Le server quant à lui, lorsqu'il recevrait la requête, ferait une recherche de l'article dans le logiciel et retournerait un ficher wrl avec ses textures

Je voudrais donc faire communiquer un server Soap Delphi (ou autre qui puise contrôler un ActiveX) avec un client Java (dans Wirefusion). Théoriquement, j'ai lu que c'était faisable, par contre dans la pratique, je ne sais pas du tout par ou commencer.
En plus, je dois récupérer les fichiers. Dans l'exemple de Soap fournis dans Delphi, il y a une image qui est dans le xml, je ne sais pas si elle est encodée en chaine de caractère par contre :/

[Aka Guymelef]

Dans ce cas je penses que les deux liens fournis par Rayek te donneras plus d'infos concernant la mise en œuvre technique.

Et sans trop me tromper si une image est contenu dans un flux XML alors c'est que son contenu binaire est recodé en Base 64 par exemple et doit être décodé en binaire par celui qui reçoit le XML.

[Rayek]

Le server quant à lui, lorsqu'il recevrait la requête, ferait une recherche de l'article dans le logiciel et retournerait un ficher wrl avec ses textures

Dans un premier temps ne serait il pas mieux de retourner une liste de liens des fichiers que le client se chargerait de rapatrier plutôt que de retourner directement le fichier.

Je voudrais donc faire communiquer un server Soap Delphi (ou autre qui puise contrôler un ActiveX) avec un client Java (dans Wirefusion). Théoriquement, j'ai lu que c'était faisable, par contre dans la pratique, je ne sais pas du tout par ou commencer.
En plus, je dois récupérer les fichiers. Dans l'exemple de Soap fournis dans Delphi, il y a une image qui est dans le xml, je ne sais pas si elle est encodée en chaine de caractère par contre :/

1- Lire le tutoriel pour faire un petit webservice et l'installer (le lien plus haut)
2- Faire des recherches sur le site pour voir s'il y a des questions/réponses sur le même sujet
3- Faire une recherche sur
4- Poser une question sur le forum s'il n'y a pas eu de réponses satisfesantes par les points 1 à 3 ^^

[davels]

Dans un premier temps ne serait il pas mieux de retourner une liste de liens des fichiers que le client se chargerait de rapatrier plutôt que de retourner directement le fichier.

Non, car le client ne doit pas avoir les fichiers directement mais ils doivent être lu par l'applet directement pour afficher les en 3D.

1- Lire le tutoriel pour faire un petit webservice et l'installer (le lien plus haut)
2- Faire des recherches sur le site pour voir s'il y a des questions/réponses sur le même sujet
3- Faire une recherche sur
4- Poser une question sur le forum s'il n'y a pas eu de réponses satisfesantes par les points 1 à 3 ^^

J'ai déjà fait des tests, enfin un peu hier mais j'avoue que les exemples expliquent juste comment mettre en place mais pas de manière approfondie.
Et c'est la première chose que j'ai faite, j'ai surfé sur google pendant plusieurs heures mais sans réellement trouver de tutoriel qui rentraient plus en détails sur comment utiliser Soap
Si vous avez ca en stock, je suis très intéressé

[Franck SORIANO]

Je ne crois pas que ça puisse fonctionner comme tu penses.

Un WebService, comme son nom l'indique c'est avant tout un service que tu invoque à travers le web, en encodant les messages avec SOAP.
Lorsqu'un client appelle un WebService, il lance l'exécution d'une méthode sur le serveur, en renseignant des paramètres d'appels. Ces paramètres sont encodés en Xml via SOAP.
Lorsque l'exécution de la méthode est terminée, le serveur répond au client en retournant les codes de retours et paramètres de sortis définis sur la méthode. A leurs tour, les valeurs des paramètres sont encodés en Xml via SOAP.

Tu ne peux donc pas renvoyer un fichier via un webservice. Tu peux par contre renvoyer le contenu d'un fichier dans un paramètre. Tu peux à la rigueur retourner un nom de fichier, ou un lien pour qu'ensuite le client puisse déclencher un download selon un autre protocole.

Non, car le client ne doit pas avoir les fichiers directement mais ils doivent être lu par l'applet directement pour afficher les en 3D.

Je ne connais pas WireFusion, mais j'ai l'impression que ce n'est rien d'autre qu'un viewer de fichier wrl .
Donc à mon avis, tu n'as pas besoin d'un webservice, mais d'un simple serveur web :
- Tu affiches une page au départ qui demande un code article.
- L'utilisateur valide son formulaire, ce qui déclenche un appel au serveur web.
- Ce dernier traite la requête en créant le fichier wrl (ou le fichier existe déjà et il se contente d'identifier le wrl à utiliser) et retourne au client une page html contenant l'applet initialisée avec les références du fichier wrl à jouer.
- Le client reçoit la page, exécute l'applet et cette dernière va télécharger les resources dont elle a besoin sur le serveur pour s'exécuter.

En tout cas, c'est sur ce principe que fonctionne tous les trucs qui vont te jouer des vidéos (daily motion et autres...). La page web embarque un player et ce dernier va télécharger le fichier à jouer en streaming...

Je pense que tu devrais d'abord étudier le fonctionnement de Wirefusion.

[davels]

Tu ne peux donc pas renvoyer un fichier via un webservice. Tu peux par contre renvoyer le contenu d'un fichier dans un paramètre. Tu peux à la rigueur retourner un nom de fichier, ou un lien pour qu'ensuite le client puisse déclencher un download selon un autre protocole.

Dans les exercices que j'ai trouvé, une photo est pourtant bien retournée dans la réponse xml Soap.
Je suppose que le client Java devrait être capable à son tour de lire les informations et les transformer en fichier

Edit : Voici un exemple du code xml pour la photo, il est situé dans un attribut

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
<ROWDATA><ROW NAME="Angel Fish" SIZE="2" WEIGHT="2" AREA="Computer Aquariums"  BMP="AQAAAfY+AABCTfY+AAAAAAAAdgAAACgAAADIAAAAoAAAAAEABAAAAAAAgD4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC/AAC/AAAAv78AvwAAAL8AvwC/vwAAwMDAAICAgAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8AAA7u4CoqKgDu7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u4iIgAAKiogDu7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7i7u7u7u7u7u7u7uIiIiIgAADu7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7uIu7u7u7u7u7u7u7iIiIgDu7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7iLu7u7u7u7u7u7uIgAADu7u7u7u7u7u7u7u7u7uDu7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u4i7u7u7u7u7u7u7iJ+7u7u7u7u7u7u7u7u7u7u4O7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7iIu7u7u7u7u7u7u4i7u7u7u7u7u7u7u7u7u7u7g7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u4iLu7u7u7u7u7u7uIu7u7u7u7u7u7u7u7u7u7u4O7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7uIi7u7u7u7u7u7u4iLu7u7u7u7u7u7u7u7u7u7g7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7iIu7u7u7u7u7u7uIi7u7u7u7u7u7u7u7u7u7u4O7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7"

Je ne connais pas WireFusion, mais j'ai l'impression que ce n'est rien d'autre qu'un viewer de fichier wrl .

Je pense que tu devrais d'abord étudier le fonctionnement de Wirefusion.

C'est un viewer wrl (et x3d) mais beaucoup plus complet, il permet de programmer en java directement dans son interface et donc d'implémenter du code Java dans le moteur de l'applet, d'ou mon idée d'utiliser un webservice, sur papier, tout semble possible.

Par contre, si jamais l'envoi des fichiers via Soap ne peut fonctionner, l'idée de renvoyer les liens est bonne

[Aka Guymelef]

C'est bien ce que je m'efforce de t'expliquer depuis le début, regarde l'image d'exemple contenu dans le fichier XML, si fais l'essai de copier et d'enregistrer le contenu de l'attribut BMP dans un fichier tu seras surpris de constater que ça ne donne pas du tout une image quand tu l'ouvres avec Paint ou autre alors que pourtant elle s'affichait bien dans ton exemple !

C'est normal, pour pouvoir être renvoyée en tant que valeur d'un XML, on doit se débarrasser de tout octet qui parasiterais la lecture par le parseur (retours chariots, <, > , ]]>, etc...) une des solutions proposée est d'application une règle de décalage de bit pour faire en sorte que chaque octet devienne un caractère ASCII bien précis et que l'on peut décoder en appliquant le décalage inverse. C'est ainsi que fonctionne l'encodage en base 64 par exemple.

Donc dans l'algorithmique tu envoies une requête à ton WebService via XML/SOAP, le WebService traite et possède des fichiers à renvoyer, il encode chaque fichier avec une méthode définie à l'avance et renvoi le tout via XML/SOAP au client. Le client récupère le flux et pour chaque fichier applique la méthode de décodage et récupère un tableau d'octet représentant le fichier. Après soit tu sauvegarde sous disque et tu réouvres les fichiers temporaires, soit tu injectes directement le binaire dans tes composants de lecture si c'est faisable.

[davels]

C'est bien ce que je m'efforce de t'expliquer depuis le début, regarde l'image d'exemple contenu dans le fichier XML, si fais l'essai de copier et d'enregistrer le contenu de l'attribut BMP dans un fichier tu seras surpris de constater que ça ne donne pas du tout une image quand tu l'ouvres avec Paint ou autre alors que pourtant elle s'affichait bien dans ton exemple !

C'est normal, pour pouvoir être renvoyée en tant que valeur d'un XML, on doit se débarrasser de tout octet qui parasiterais la lecture par le parseur (retours chariots, <, > , ]]>, etc...) une des solutions proposée est d'application une règle de décalage de bit pour faire en sorte que chaque octet devienne un caractère ASCII bien précis et que l'on peut décoder en appliquant le décalage inverse. C'est ainsi que fonctionne l'encodage en base 64 par exemple.

Donc dans l'algorithmique tu envoies une requête à ton WebService via XML/SOAP, le WebService traite et possède des fichiers à renvoyer, il encode chaque fichier avec une méthode définie à l'avance et renvoi le tout via XML/SOAP au client. Le client récupère le flux et pour chaque fichier applique la méthode de décodage et récupère un tableau d'octet représentant le fichier. Après soit tu sauvegarde sous disque et tu réouvres les fichiers temporaires, soit tu injectes directement le binaire dans tes composants de lecture si c'est faisable.

Théoriquement, je l'avais bien compris étant donné que je l'avais utilisé
Maintenant, il faut mettre le tout en pratique ... le problème, c'est que je ne trouve pas de doc assez détaillée pour comprendre ce qu'il faut faire!
Suivre un tutoriel et réussir à refaire le même n'est pas très compliqué, mais en comprendre les subtilités, c'est autre chose!
Comme convertir le fichier, théoriquement, c'est simple, pratiquement, je ne sais pas par ou commencer
Concernant les possibilités de Wirefusion et ses limites Java, je testerais sous peu mais d'après ce que j'avais compris, il a les limites du Java dans toute son étendue

[Aka Guymelef]

Consulte ceci (la version en semble plus complète toutefois) pour avoir plus d'infos sur les mécanismes d'encodage/décodage en base 64.

Après c'est pas vraiment les limites de Java mais les limites des objets Wirefusion qu'il faut prendre en compte, est-ce qu'il ne permet que de charger depuis un fichier ? Si oui, pas de miracles, il faudra sauvegarder le fichier dans le cache après décodage et le réouvrir (mais dans ce cas tu n'as vraiment besoin d'un WebService mais simplement d'un serveur Web comme l'a indiqué Franck SORIANO). S'il est possible de pouvoir injecter directement le binaire alors tu es sauvé, il te faudra simplement que ton client Java décode Base64 vers binaire et envoyer le binaire à tes objets Wirefusion.

Tu peux même implémenter une barre de chargement au fur et à mesure que tu décode chaque octet de Base64 vers binaire si tu en as envie même si je ne crois pas que ce soit très représentatif. Cette action côté client sera minime en temps par rapport au temps de transfert du serveur vers le client.

[davels]

Consulte ceci (la version en semble plus complète toutefois) pour avoir plus d'infos sur les mécanismes d'encodage/décodage en base 64.

Après c'est pas vraiment les limites de Java mais les limites des objets Wirefusion qu'il faut prendre en compte, est-ce qu'il ne permet que de charger depuis un fichier ? Si oui, pas de miracles, il faudra sauvegarder le fichier dans le cache après décodage et le réouvrir (mais dans ce cas tu n'as vraiment besoin d'un WebService mais simplement d'un serveur Web comme l'a indiqué Franck SORIANO). S'il est possible de pouvoir injecter directement le binaire alors tu es sauvé, il te faudra simplement que ton client Java décode Base64 vers binaire et envoyer le binaire à tes objets Wirefusion.

Tu peux même implémenter une barre de chargement au fur et à mesure que tu décode chaque octet de Base64 vers binaire si tu en as envie même si je ne crois pas que ce soit très représentatif. Cette action côté client sera minime en temps par rapport au temps de transfert du serveur vers le client.

Merci de ton aide (et à tous)!

En faite, j'aurais toujours besoin du webservice car le code article envoyé permettra côté server de lancé l'ActiveX et récupérer les fichiers nécessaires, car ils sont générer à la volée.
Par contre, je ne pense pas que Wirefusion puisse gérer directement le flux sans passer par un fichier, mais ce n'est pas le problème principale pour moi.

J'envoie le code article par Soap, le server fait tourner l'ActiveX et génère les fichiers que j'encode en base64 et renvoie le tout par Soap qui sera ensuite décodé par l'appli Wirefusion avec création des fichiers en local et ouverte des fichiers, ca parait tellement simple théoriquement
La barre de progression sera certainement très intéressante lors du téléchargement, certains fichiers wrl peuvent être assez lourd

Edit : Voici une solution pour décoder/décoder un fichier en base64 sous Delphi