Version imprimable
:salut:
Voilà , je dispose d'un application web sous Tomcat et d'une application GED : contineo.
Je voudrais savoir quel est le moyen le plus efficace, le plus rapide et le plus sûr pour envoyer des fichiers XML ( moyennement volumineux ) et des fichiers multimédia ( images pouvant arriver à 5 MegaOctets ) de mon serveur web à mon application GED et vice versa.
On m a proposé les Web Services mais je pense que ce n'est pas le meilleur moyen pour ce genre de choses .....
Si ca se résume à du transfert de fichiers, et en l'absence de problématiques liées à l'interopérabilité ou de politique de sécurité, un protocole simple comme TFTP rempli la fonction.
Non en fait les choses sont plus compliquées que ça ...
En fait voilà , les deux modules cités font partie d'une grande plateforme...
Les utilisateurs du portail web pourront soumettre des formulaires en XML accompagnés de pièces jointes qui devront être archivées dans l'application GED ... Le protocole de transport devra être rapide, robuste et sécurisé...
Je voudrais surtout savoir si les Web Services sont indiqués ou si ils sont plutot destinés à transporter des réponses non volumineuses . car j'ai remarqué qu'ils sont très lents...
L'option WS est délicate.
Si tu t'en tiens au protocole strict, l'échange d'information binaire se fait en uuencodant les données dans une enveloppe SOAP. Ce qui introduit un embonpoint préjudiciable à la performance.
L'autre solution est de recourir à un attachement, qui est vraissemblablement la meilleure solution, mais malheureusement peu utilisée. Voir : http://www.w3.org/TR/soap12-mtom/
Y a t il alors d'autres moyens plus indiqués ...
quel est le plus du Web Services dans ce genre de cas et pourquoi on me l'a conseillé????
Pour les éditeurs logiciels le WS apporte un avantage indéniable : ne pas devoir développer d'API pour tout les langues de programmations avec lesquels ont peut s'interfacer. Vous voulez intégrer notre GED avec votre appli au choix : Java, .NET, C++, .... ? Pas de pb, les WS sont là !
Le choix du protocole de communication avec ta GED dépend donc des API qu'elle expose. Sur la page d'accueil de contineo j'ai lu une liste de possibilités :
* Add documents via HTTP upload
* Import folder as zip
Je ne sais pas si cette liste est complète, mais je ne vois pas de WS ici. L'avantage de l'upload HTTP est qu'il te sera peut être possible de chaîner le flux avec ton application web de sorte d'économiser la mémoire de traitement nécessaire pour de gros fichiers, et donc améliorer ta capacité de montée en charge.
[edit] Autant pour moi, les WS sont mentionnés dans la section "Communication" de la page d'accueil.
En réalité toute la plateforme est en J2EE donc le langage est déjà choisi ..
De plus, le responsable de la partie GED a déjà développé une couche écrite en JAVA qui est en fait une interface supplémentaire du GED en code Java donc...
Et donc les possibilités ne se limitent plus à la liste publiées dans la doc de contineo ... par exemple là on est en train d'essayer avec des queues de message JMS.
Pourrais tu me donner plus de détails sur la méthode via HTTP upload ...
Pas sur celle de contineo ? ;)Citation:
Envoyé par NizarK
Si tu utilises la librairie Apache FileUpload, tu peux avoir accès au flux de lecture du fichier en cours d'upload. Ainsi tu évites de lire complètement le fichier en mémoire pour le retransmettre ensuite par un quelconque moyen de communication. Ceci peut être intéressant si les API vers ta GED proposent un mode en Streaming. Ainsi, au fur et à mesure que tu lit le contenu de ton flux d'entrée (provenant de l'upload côté client web) tu écrit dans ton flux de sortie (la GED).
Voilà un lien sur la documentation http://commons.apache.org/fileupload/streaming.html
Concernant JMS, cela peut amener un comportement intéressant, c'est la désynchronisation entre l'envoi et la prise en compte côté GED (si ce n'est pas géré par l'API de la GED). C'est intéressant si l'envoi du nouveau document est long (réseau lent, serveur très sollicité, indexation du fichier en mode synchrone, ...) et pénalise ton client web. C'est la magie de l'asynchrone, mais attention au middleware JMS qui devra persister le contenu des files d'attente en cas de crash.
Pour le File upload si je comprend bien, il s'agit de transmettre le fichier au GED octet par octet pendant l'opération même d'upload du fichier par le client ...
Dans mon cas ce n'est pas vraiment possible car en fait c'est le GED qui envoie des documents à l'application web après que le web lui ait soumis une requête de recherche ....
de plus le contenu échangé est de l'XML qui devra être parsé par l'application web et affiché dans un formulaire .. il ne s'agit pas de simple upload de fichiers.
Si j'ai bien compris il n y a pas de solution miracle mais vaut mieux éviter le Web Services pour ce besoin puisque l'intérêt que tu as cité, celui de l'indépendance par rapport à un langage n'est pas primordial.
Effectivement, c'est exactement ça.
Je te recommande de faire des tests pour évaluer le protocole le plus performant dans ton cas d'utilisation. JMS par exemple est une API cliente et ne préjuge pas de l'implémentation du protocole de communication entre le client et le serveur. Rien n'empêche ce protocole de zipper les flux par exemple.
Tiens nous au courant si tu fait des tests, tout le monde pourra profiter de votre recherche et de votre conclusion.
Juste une dernière chose avant de me lancer dans les tests ..
Dans ce document, un comparatif entre SOAP et 2 autres technologies ... Les résultats sont flagrants mais je voudrais savoir si dans ce comparatif il ont pris en compte l'option SOAP mtom cité par Tommy ou c'est du SOAP normal ce qui implique que je dois refaire les tests pour mtom..
Les résultats sont le simple reflet de l'empilement des couches de communication.
TCP : direct
HTTP : encodage sur TCP
SOAP : si HTTP est pris comme couche de transport ...
Donc pas de mtom dans ce document ...???
Probablement pas.
Aucune idée pour ma part.Citation:
Envoyé par NizarK
Merci à tous ... je vous met au courant dès je termine les tests ...