WAARP : le moniteur de transfert de fichier Open Source

Posté par  (site web personnel) . Édité par Benoît Sibaud, Xavier Teyssier, baud123, tuiu pol, Nÿco et Nils Ratusznik. Modéré par tuiu pol.
Étiquettes :
48
22
juin
2012
Technologie

Avec la montée en puissance du Big Data, le transport sécurisé de grands volumes de documents entre sites distants est une problématique récurrente des SI qui gèrent des quantités croissantes de ressources.

Waarp est né de la volonté d’une équipe de professionnels de créer et d’animer un outil communautaire à même d’assurer le transfert de fichiers dans des contextes sécurisés et performants.

Waarp est le nouveau nom du logiciel libre OpenR66 (licence GPL). Cet outil Open Source de monitoring de transfert de fichiers fut créé pour pallier les limites de performances de la passerelle propriétaire CFT, et supporter 10.000 transferts simultanés dans le cadre de la plate-forme d'échange de la DGFIP (Ministère des Finances à Bercy).

Un peu d'histoire…

Waarp était en production depuis trois ans à la DGFIP lorsque la Gendarmerie Nationale a lancé son projet d’archivage. Il fallait alors trouver une solution de rapatriement des procès verbaux de Gendarmerie qui soit abordable financièrement, performante et fiable, et c’est sur ces critères que l’équipe en charge du projet s’est intéressée au produit.

Le concepteur originel du produit et les ingénieurs Maarch (solution d'archivage électronique open source) se sont regroupés pour sortir ce produit de la confidentialité, et proposer une alternative professionnelle au monopole AXWAY/CFT sur la supervision de transfert de fichier.

Un outil robuste et performant

Waarp est un produit robuste et performant qui dispose des caractéristiques suivantes :

  • Nombre de transferts simultanés virtuellement illimités ;
  • Possibilité de limiter l'usage de la bande passante (point à point ou globalement) ;
  • Garantie d'acheminement (persistance) ;
  • Chiffrement et contrôle de l'intégrité des transferts optionnels ;
  • Intégration facilitée dans les règles de sécurité (choix des ports, multiplexages des flux) ;
  • Historisation des méta-données associées aux transferts ;
  • Exécution de pré et post-process au sein de la transaction de transfert ;
  • Authentification des partenaires (mot secret et optionnel authentification client SSL) ;
  • Virtualisation des chemins d'accès ;
  • Validation d'usage des règles par partenaire.

Le produit WAARP R66

Il utilise un protocole spécifique, public et documenté (NdM : la documentation du protocole ne semble pas être sur le site du projet), baptisé protocole Waarp, assurant un transfert en mode bloc avec reprise sur incident.

Waarp R66 est un produit entièrement administrable et exploitable :

  • Dispose d'une interface native HTTPS d'administration avec contrôle d'accès ;
  • Permet l'administration en mode script ;
  • Par exemple, permet de modifier la bande passante autorisée dynamiquement ;
  • Dispose d'une interface native HTTP de supervision ;
  • Intégration possible via requête HTTP.

Les fonctions de supervision sont à la fois accessibles sur le serveur de réception central, et les modules client.

Waarp R66 est garant de la bande passante, on pourra par exemple fixer les règles suivantes :

  • Débit montant max autorisé : 1024 Kb/s par défaut
  • Débit montant max autorisé : 512 Kb/s de 08:00 à 01:00
  • Départ des lots à partir de 01:00 le lendemain

Waarp R66 peut utiliser les relais (passerelles) locaux pour remonter les documents.

Ce produit est opérationnel et capable de grandement faciliter l’exploitabilité de la solution. En particulier, les administrateurs locaux ou centraux auront une vision claire des lots en attente de transfert, en échec, et en succès.

Aller plus loin

  • # Petites précisions

    Posté par  . Évalué à 8.

    Salut,

    Cet outil semble être très intéressant dans l'idée d'un remplacement de CFT qui coûte assez cher. Quelles sont les technos utilisées (langage?, base de données?)?

    A-t-on une idée de la date de mise à disposition de l'outil (marquée comme courant 2012 sur le site)?
    Je n'ai pas trouvé de forge/lien de téléchargement des sources sur le site. Sont-elles mises à disposition?

    Eric

    • [^] # Re: Petites précisions

      Posté par  (site web personnel) . Évalué à 8.

      Salut Eric,

      L'outil est déjà disponible sur sourceforge.net, il est référencé dans le projet goldengate, tu pourras y télécharger la dernière version d'openr66. On va changer le nom du projet sur SF en Waarp dans les jours qui viennent.

      La documentation technique (comprenant la description du protocole) est pour l'instant sur le site suivant http://openr66.free.fr/OpenR66Technical.html.

      • [^] # Re: Petites précisions

        Posté par  . Évalué à 5.

        Bonjour,

        Juste un petit mot pour indiquer que dans le monde du SI (et donc des décideurs SI qui mangent du progiciel à outrance parce qu'ils voient tous les jours des commerciaux) le terme GoldenGate est associé à une solution/produit d'Oracle : http://www.oracle.com/technetwork/middleware/goldengate/overview/index.html

        Donc si en ce moment il y a une volonté de changement de nom, il pourrait être intéressant de modifier celui là aussi…

        • [^] # Re: Petites précisions

          Posté par  . Évalué à 2.

          Et Waarp évoque OS/2 d'IBM au premier tiers des années 90

          BeOS le faisait il y a 20 ans !

        • [^] # Re: Petites précisions

          Posté par  . Évalué à 2.

          Goldengate (open source) date de 2007… je ne suis pas certain qu'Oracle avait déjà créé ce nom à cette époque… ;-)
          Le projet est en train de migrer sous son appellation Waarp (avec 2 a contrairement à IBM ;-)

    • [^] # Re: Petites précisions

      Posté par  (site web personnel) . Évalué à 6.

      Concernant la question sur les technos utilisées :
      - Java (1.5 minimum, 1.6 conseillé)
      - SGBD compatibles avec JDBC : actuellement officiellement supportées Oracle, PostgreSQL, MySQL, H2 Database, et possibilité de se passer totalement de bases (fichiers XML) mais avec une réduction des fonctionnalités
      - Dépendances :
      - - Netty pour le support NIO Java
      - - Apache Commons
      - - Logger via LogBack (successeur de log4j) mais adaptable via le paramétrage LogBack
      - - DOM4J et JAXEN (fichiers d'interface et de configuration)
      - - JavaSysMon (optionnel pour le support des charges CPU)
      - - SNMP4J (optionnel pour le support SNMP)

  • # CFT/PeSIT

    Posté par  . Évalué à 5.

    Ici, j'ai des échanges à réaliser avec l'Agence de Services et de Paiements (http://www.emploi.gouv.fr/acteurs/asp) et ils ont requis l'utilisation de CFT/PeSIT. Mais j'ai comme le sentiment que WAARP (malgré l'annonce d'une iso-fonctionnalité avec CFT) ne prend pas en charge PeSIT. Je me trompe ? (Oh, Andy)

    • [^] # Re: CFT/PeSIT

      Posté par  (site web personnel) . Évalué à 2.

      R66 n'implémente pas PeSIT, ni ETEBAC, ni autres protocoles dont les spécifications sont soient quasi fermées soit obsolètes.

      R66 implémente un protocole ad-hoc. Ce protocole est ouvert car les spécifications sont publiques, ainsi que le code qui le gère, d'autres solutions peuvent donc implémenter celui-ci.

      La seule implémentation à un protocole pré-existant est dans GgFTP (FTP bien sûr), et en étude, le protocole HTTP (en mode upload / download). Mais pour ces deux (et surtout GgFTP qui existe), il s'agit de gateway "passive", signifiant que la gateway ne peut être à l'origine d'un transfert. Elle ne peut que recevoir une commande de transfert (get ou put).
      GgFtp Exec est une extension de Gg FTP où l'interface permet de se raccrocher à un moniteur R66. L'objectif était de permettre des transferts "light" depuis des clients non équipés en R66 vers une plateforme R66 via FTP mais avec tout de même quelques contrôles et suivi de la rupture de flux (FTP / R66).

      • [^] # Re: CFT/PeSIT

        Posté par  . Évalué à 2.

        J'entends bien la difficulté d'implémenter le protocole PeSIT, mais du coup l'accroche sur l'iso-fonctionnalité avec CFT est un brin trompeuse, quoique vendeuse.

        Quoiqu'il en soit, ce logiciel est une bonne nouvelle, mais malheureusement ne pourra du coup répondre aux besoins de ma structure…

        • [^] # Re: CFT/PeSIT

          Posté par  (site web personnel) . Évalué à 4.

          ISO-fonctionnel dans le sens "même périmètre fonctionnel" : monitoring de transfert de fichiers. Cela ne veut pas forcément dire même technologie.
          Je ne trouve pas l'accroche trompeuse, waarp se positionne bien comme une alternative à CFT/Interpel de part son périmètre fonctionnel et sa robustesse.

          • [^] # Re: CFT/PeSIT

            Posté par  . Évalué à 6.

            Encore faut-il que les partenaires parlent ce protocole! Avec l'hégémonie de CFT, c'est pas prêt d'arrivée :-(
            Sinon, est-ce que le protocole SFTP est supporté?

            • [^] # Re: CFT/PeSIT

              Posté par  . Évalué à 2.

              L'hégémonie de CFT est liée à l'absence de solutions viables autres.
              Si les acteurs sont d'accord sur le changement de protocole, ils pourront sortir de CFT…

              Sur SFTP, SFTP est un sous-ensemble de SSH. SSH n'est pas supporté.
              FTPS est une version de FTP avec flux SSL. Pour le moment, les flux FTP (pour la passerelle) sont du FTP classique. Si le mode FTPS est vraiment nécessaire, il est tout à fait envisageable de proposer cette évolution.

              • [^] # Re: CFT/PeSIT

                Posté par  . Évalué à 4.

                Bonjour.
                Pas tout a fait d'accord avec cette raison de l'hégémonie de CFT.
                Si je ne me trompe CFT a été créé pour un besoin particulier, sécuriser le transfert de donnée inter-bancaire das banques françaises.
                Ce logiciel a rempli un vide à l'époque. Lorsque d'autres domaines d’activités ont recherché un logiciel de gestion de flux, ils sont tombés sur CFT. Celui-ci étant utilisé par toutes les banques françaises, il profita d'une image de sérieux, d’efficacité, d'outil professionnel, d'outil universel. Un peu comme Windows à l'image du seul OS pour les PC et de Mac Os pour les MAC.
                Il fut donc difficile pour une nouvelle solution de sortir du lot et de véritablement concurrencer ce produit dans le secteur privée.
                Waarp me semble une alternative intéressante. Le fait que ce logiciel soit utilisé par la DGFIP et la Gendarmerie apporte justement le gage de qualité que les banques ont apporté a CFT.
                Toutefois je trouve cette annonce un peu trop prématuré car il manque pas mal d'information technique de base sur le site web : Quel OS supporté, ou télécharger le logiciel……..
                A surveiller donc.

                • [^] # Re: CFT/PeSIT

                  Posté par  (site web personnel) . Évalué à 3.

                  J'allais dire qu'il y avait une concurrence de CFT avec Pelican, j'ai bien fait de vérifier

                  extrait de
                  http://fr.wikipedia.org/wiki/Cross_File_Transfer

                  "CFT et Inter.Pel(Pelican), sont désormais connus sous les noms de Axway Transfer CFT, Axway Transfer InterPEL, anciennement appelé XFB (Axway File Broker)."

                  Donc Axway doit avoir un joli monopole.

                  ウィズコロナ

  • # Waarp en production depuis trois ans à la DGFiP ??

    Posté par  (site web personnel) . Évalué à 3.

    Waarp est le nouveau nom du logiciel libre OpenR66 (licence GPL). Cet outil Open Source > de monitoring de transfert de fichiers fut créé pour pallier les limites de performances > de la passerelle propriétaire CFT, et supporter 10.000 transferts simultanés dans le
    cadre de la plate-forme d'échange de la DGFIP (Ministère des Finances à Bercy).

    Waarp était en production depuis trois ans à la DGFIP lorsque la Gendarmerie Nationale a lancé son projet d’archivage.

    Alors, pour avoir travaillé pour un ministère pendant 5 ans et en relation avec la DGFiP, surtout la dernière année (migration d'un flux CFT d'un réseau X.25 sur un réseau IP), je suis un peu étonné par cette annonce. En effet, la principale plate-forme d'échange de la DGFiP faisait tourner Synchrony Gateway, dont le principal protocole est… CFT (ou PeSIT-E). Les plate-formes régionales sont également équipées en CFT Monitor, sans parler de la plate-forme du précédent ministère, également sous CFT Monitor (avec un vieux système en prime).
    Donc, apprendre que Waarp serait la « en production depuis trois ans » me laisse un peu perplexe. Maintenant, la GN est, en pratique, un ministère à elle-seule (c'est pour cela qu'il lui fut si « facile » de changer de tutelle), notamment dans ses relations inter-ministérielles. Il reste fort possible que Waarp ait été uniquement déployé entre cette dernière et la DGFiP. La GN est connue pour son attrait pour les Logiciels Libres.

    Ce projet est cependant une bonne nouvelle, surtout quand on voit le prix des plater-formes CFT ou Gateway (merci Axway) ! À l'heure où nous parle de réduire les dépenses publiques, ce serait bienvenu mais je crains que le défaut de support des protocoles CFT ou au moins PeSIT-E soit un frein.

    • [^] # Re: Waarp en production depuis trois ans à la DGFiP ??

      Posté par  . Évalué à 3.

      Pour y avoir travailler pendant 8 ans, je peux vous assurer que Waarp est installé à la DGFiP (sous son ancien nom). Il est en lien avec une plateforme qui devait recevoir plus de 10 000 fichiers par jour, et CFT ne tenait pas le choc (pas XFB Gateway, mais bien le moniteur CFT). Cette plateforme jour un rôle "central" dans l'archivage numérique de la DGFiP et de CHORUS. Il est notamment en place pour la réception en provenance des sites informatiques déconcentrés (via le pont FTP Waarp Goldengate), et pour assurer les transferts entre les deux sites de production centraux, et ce depuis 2008 (donc même 4 ans maintenant).

      Bien sûr que le protocole PeSIT est toujours utilisé et très répandu. Mais vous n'êtes pas sans savoir que celui-ci est obsolète et qu'il tend à être remplacé (voir les travaux sur les protocoles bancaires notamment en relation avec le SEPA). Il est évident que les éditeurs supportant PeSIT (et autres ETEBAC) continuent d'étendre leur support à d'autres protocoles. Selon mon opinion (qui n'engage que moi), ces protocoles sont "datésé et mériteraient d'être totalement repensés.

      Ici le principe de Waarp est de proposer une alternative libre, mais bien sûr, comme tout protocole, les partenaires doivent s'accorder sur celui-ci.
      A noter que la passerelle Goldengate permet aussi de proposer une évolution douce depuis FTP vers Waarp.

      L'objectif n'est pas de remplacer PeSIT ou ETEBAC par un autre protocole, mais d'offrir une solution libre qui permette de ne plus faire de "ftp" ou "ssh" entre systèmes (serveurs ou SI) sans réel contrôle ni management. Le cas échéant, si l'ensemble des acteurs sont d'accord pour ne plus utiliser PeSIT ou ETEBAC, ils pourront avoir une alternative.

      • [^] # Re: Waarp en production depuis trois ans à la DGFiP ??

        Posté par  (site web personnel) . Évalué à 4.

        Bonjour,
        je connais un peu CFT et Axway :)
        Le problème c'est qu'il n'y a personne d'autres … ou alors très peu connu et chui pas un spécialiste
        Remplacer PeSIT techniquement c'est pas le problème après tout il ne s'agit "que" de transfert de fichier.
        PeSit comme Etebac est historique mais aussi très vieillissant.
        Si ce logiciel libre propose une solution sécurisée avec ligne de commande scripts exits et interface web sympa admin et user
        Pourquoi pas ?

        De toutes façon quand on voit qu'a 8 jours de la fin de TRANSPAC certaines grosses structures sont à peine prête :) et utilise encore X25 … on se demande a quoi ils réfléchissent …

        Mais comme pour M$ on ne pourra pas reprocher a un décideur de choisir CFT uniquement
        parce que c'est le 1er.

        Pour moi c'est une appli libre qui manquait (dommage que ce soit en Java :) )

        D'ailleurs pour ceux que ca intéresse CFT sous Linux c'est nickel a installer, bien mieux que sous AIX d'ailleurs … et si on gratte on dirait que l'interface graphique est en python …

        Mais maintenant que je connais Waarp je vais reconsidérer la question, j'ai connu trop de boite qui voulait automatiser des transferts entre filiale, maison mere et fournisseurs avec des rhytmes de folie.

        Si waarp tiens le choc c'est une super brique pour le libre !

        A+
        chris

      • [^] # Re: Waarp en production depuis trois ans à la DGFiP ??

        Posté par  (site web personnel) . Évalué à 2.

        CFT ne tient sans doute pas le choc mais c'est bien XFB Gateway qui était utilisé à la DGFiP. Pour ce qui est de CHORUS, ce n'est pas sous la tutelle de la DGFiP mais de l'AIFE.
        Cependant, là encore, ils sont plutôt équipés par Axway, avec la suite Synchrony (qui embarque Gateway notamment). Chaque plate-forme a coûté fort cher là où les besoins en matière d'échanges de fichiers, après quelques années de fonctionnement, sont plutôt minces. On était très loin des 10K fichier par jour.

        Quant au protocole, le seul permettant l'inter-opérabilité entre les CFT Monitor et nos Gateway (la notre et celle de la DGFiP, en face) était bien PeSIT-E.

        Si Waarp devait remplacer toutes les plate-formes mises en place au ministère en question, cela ferait pas mal d'économie en terme de licence mais demanderait énormément de travail.
        D'ailleurs, est-ce que Waarp fonctionne sous Solaris ?

        • [^] # Re: Waarp en production depuis trois ans à la DGFiP ??

          Posté par  . Évalué à 3.

          Je crois ne pas m'être fait comprendre, sans doute par manque de précision.

          CFT (et autres dérivés) est bien utilisé par la DGFiP et CHORUS.
          Je l'ai déjà écrit mais je me répète : ce dont je parle, c'est le cas d'une application centrale dans "l'archivage électronique" de la DGFiP. Elle est en production depuis fin 2007 et je suis bien placé pour le savoir ;-) Et Chorus est un des clients de cette application bien que ne faisant pas partie de la DGFiP (mais n'utilise pas le composant waarp bien qu'il ait failli utiliser son pendant HTTP pour faire le lien avec SAP).
          Et cette application "centrale" réalise bien plus de 10 K transferts par jour…

          Je suis d'accord qu'il ne faut pas minimiser le coût du changement. Ceci dit, le passage à XFB Gateway (et j'y étais aussi pour quelque chose durant ces 8 années) n'a pas été simple non plus. Et ne pouvant pas prévoir l'avenir, je ne me risquerais pas à estimer que cette façon de procéder survivra des années encore, surtout il est vrai pour des raisons de coûts logiciels. Aussi une alternative Open Source est elle toujours intéressante. Après, tout est affaire de décision politique et de moyens financiers.

          Enfin et pour ne pas sur-estimer les coûts du changement, CFT est appelé la plupart du temps par des scripts depuis les applications. Changer un script écrit une fois pour toute par un autre ne devrait pas changer la face du monde… Quant à l'usage de code embarqué (plus à l'image de Chorus cette fois), c'est tout aussi possible avec Waarp. Néanmoins, là, il est vrai, du fait de l'intégration d'un nouveau composant, les efforts ne sont pas à sous-estimer.

          Et pour conclure sur Solaris :
          - si Solaris supporte Java, c'est bon (tiens, je crois que Solaris fut créé par Sun lui même créateur de Java, ça devrait aller donc), mais nous n'avons pas eu l'occasion de tester il est vrai.
          - si Solaris survit encore longtemps (?), nous aurons sans doute la chance de le valider officiellement.

          Bien à vous,

        • [^] # Re: Waarp en production depuis trois ans à la DGFiP ??

          Posté par  . Évalué à 3.

          Pour la petite histoire, Axway est aussi au passage un des leader des orchestrateur/ordonnanceur avec Automator (ex XOS), très utilisé dans les grands comptes comme la SNCF. Ca permet très grossièrement d'enchaîner des batchs de manière graphique selon toutes les contraintes que l'on souhaite à travers tous types d'OS et de réseaux… Je n'ai d'ailleurs pas trouvé d'alternative crédible en libre.

  • # xp

    Posté par  . Évalué à 5.

    sur quel type bestiole ça se déploit ce genre de logiciel ? et pour quel volumétrie et débit de données ?

    si des utilisateurs pouvaient un peu détailler, ca serait sympa

    • [^] # Re: xp

      Posté par  . Évalué à 4.

      Le choix de Java comme langage fait sa capacité à être déployé (presque) partout.
      A ce jour, testé sous Linux, AIX, Windows, en natif et en VM.

      Côté volumétrie, 2 exemples issues de la réalité :
      - 2 partenaires échangeant plus de 10.000 transferts de 1 Mo à 100 Mo en moyenne par jour sur une liaison 200 Mbps
      - 4600 partenaires échangeant 1 à 10 transferts de 1 Mo en moyenne par jour vers un point central unique sur des liaisons 512 Kbps avec limiteur de bande passante actif

      Les débits en pointe (sans limitation de bande passante actif) dépendent… de la bande passante disponible. La charge CPU/Mémoire est assez faible (1 à 2 vCPU / 4 Go suffisent dans la plupart des cas), et ce n'est donc pas le point bloquant.
      Après cela dépend des choix de paramétrage (les options sont nombreuses), dont certaines pouvant avoir un impact sur les performances (SSL / contrôle de paquet / limiteur de CPU-bande passante / pré et post actions / … pour ne citer que les plus évidentes).

      • [^] # Re: xp

        Posté par  (site web personnel) . Évalué à 0.

        Le choix de Java est aussi pénalisant car je me demandait si on ne pourrait pas testé ce logiciel pour rapatrier nos données des centres de calculs chez nous. Une partie du rapatriement se fait via des scripts actuellement et par clef ssh.

        Justement, ce choix de Java bloque le développement d'API en Perl, Python… Pour des bibliothèques centrales, le coeur en C est souvent malheureusement une bonne chose. Je dis malheureusement car les langages de programmations normalise en général la syntaxe mais jamais le mapping ELF ! Chaque compilateur fait son propre mapping et changer de compilateur entraîne de recompiler l'ensemble de toutes les bibliothèques utilisées. C'est parfois dommage.

        • [^] # Re: xp

          Posté par  . Évalué à 3.

          Si je comprend bien, aujourd'hui ce sont des scripts qui font les transferts.
          Avec Waarp, ce serait pareil. Le script déclencherait l'envoi (ou la réception selon le sens de transmission) en synchrone (il prend en charge réellement le transfert) ou en asynchrone (il soumet le job au moniteur). Et de l'autre côté le moniteur pourrait à sont tour déclencher des scripts en post-opérations.

          Par contre, si l'objet était d'intégrer le moniteur de transfert au sein des programmes, alors oui, le Java limite au Java. Ceci dit, appeler du C ou du Perl ou Python depuis autre chose que C, Perl ou Python, c'est faisable mais pas simple non plus… Difficile de contenter tout le monde…
          Pour C, il souffre d'une portabilité plus restreinte (du fait des compilateurs et des OS, à l'instar de M$ même avec GCC).
          Pur Perl et Python, un peu comme Java, c'est plus portable, modulo néanmoins le portage de l'interpréteur. A ce jeu, Java nous a semble le meilleur choix.
          Mais je comprend tout à fait votre analyse…

          • [^] # Re: xp

            Posté par  (site web personnel) . Évalué à 3.

            Le fait d'avoir de l'asynchrone et des déclencheurs me semblent intéressant. Avec du rsync over ssh le tout dans du bash, c'est pas toujours le top… On n'a pas non plus des tuyaux infinis entre les centres de calcul (IDRIS, CINES…) et chez nous (même si Renater, c'est quand même très bien) donc pouvoir empiler les transferts dans une file est vraiment une bonne idée.

            Sinon, je pensais à des bindings léger en Perl ou en Python. Pouvoir depuis ces langages interrogés la file… Une partie du monde du calcul n'est pas fanat de java.

            J'ai aussi quelques services programmés en langage de script (relais mail QPSMTPD, gestionnaire de batch OAR…), il est assez facile pour un administrateur système d'aller modifier et d'adapter le serveur à ses besoins. C'est quasiment impossible à faire pour un service programmé en langage compilé… Donc on perds souvent en souplesse.

            • [^] # Re: xp

              Posté par  (site web personnel) . Évalué à 1.

              Ce n'est pas possible d'avoir ton server de transfert dans un coin, et une lib qui permet d'interargir avec (quitte à le faire avec system()) ?

              "La première sécurité est la liberté"

              • [^] # Re: xp

                Posté par  (site web personnel) . Évalué à 3.

                Si cela doit être possible mais si on pouvait le faire directement, c'est mieux ;-) (C'est aussi plus facile si on veut faire soi même de l'asynchrone et du non bloquant, via system, c'est un peu lourd).

          • [^] # Re: xp

            Posté par  . Évalué à 0.

            Python peut communiquer avec plusieurs autres langages et/ou librairies dll …, même du fortran.

            Pour des liens entre Java et Python, voir Jython et JPype

        • [^] # Re: xp

          Posté par  . Évalué à 4.

          Il suffit de fournir une interface thrift pour avoir des bindings pour les langages supportés (C#, python, perl, object pascal entre autres).

          Et comme c'est en java, on va pouvoir le faire tourner sur mainframe/MVS, un autre endroit ou CFT est très présent.

  • # FTM <> MFT

    Posté par  . Évalué à 3.

    Sans vouloir pinailler, le File Transfer Monitor (FTM) s'occupe du "machine to machine", le Managed File Transfer (MFT) s'occupe du "user to user" (pour de gros fichiers) et éventuellement du "machine to user" (pour de la diffusion).

    D'autre part, le "protocole" décrit est plutôt un processus.

    Je vais creuser le sujet plus en détail, j'ai un interPEL à trucider.

    • [^] # Re: FTM <> MFT

      Posté par  . Évalué à 2.

      Je suis assez d'accord avec toi, FTM est plus proche du sens utile. On peut aussi parler de Massive File Transfert (et on revient sur MFT). Perso, je préfère le terme de Moniteur de Transfert de Fichier (d'où FTM en accord avec tes définitions).

      Sur ta remarque sur JBoss, est-ce en raison de Netty ? Netty n'est plus sous JBoss depuis un moment…

      La decsription du protocole, là aussi je suis d'accord, est une description procédurale avec quelques éléments permettant de comprendre les contrôles internes.
      Le protocole en tant que tel est plus complexe mais peut être trouvé assez facilement dans le code (Network d'un part, Local d'autre part), modulo qu'il y a un multiplexage du Local dans Network, complexifiant un peu la première lecture.
      Si on en fait abstraction (Local uniquement), le protocole devient alors plus clair, et le processus décrit devient alors indispensable à la compréhension globale.

      Bonne lecture !

  • # OpenFlow

    Posté par  . Évalué à 0.

    Je ne vois pas bien a quoi sert ce logiciel. C'est juste pour superviser des transferts de fichiers?
    Qu'est ce que CFT, PeSIT ou ETEBAC? Franchement j'ai jamais entendu parler de tout ça.

    Par contre pour les transferts de fichiers BigData, j'ai vu que des mastodontes se lançaient sur OpenFlow pour avoir un contrôle total sur la partie routage des routeurs. Le principe est de confier la partie routage des routeurs a une autorité centrale qui pourra plus facilement déterminer comment orienter les paquets réseaux pour atteindre une efficacité maximum. C'est le SDN: Software Defined Networking, ou "routage défini par un logiciel" dans la langue de Molière.

    Par contre on perd coté résilience du réseau: il devient moins robuste qu'a la bonne vieille époque d'ARPANet. Mais bon il faut savoir ce que l'on veut: efficacité ou bien résilience?
    Google l'utilise déjà dans son réseau interne pour transférer efficacement des péta-octets de données entre ses data center. Par contre le trafic utilisateur utilise toujours le bon vieux routage.

  • # cherche un tuto sur l'installation de WAARP

    Posté par  . Évalué à -1.

    bonjour

    je souhaite mettre en place la solution open source de tranfert multi canal(openR66 ou Waarp)
    je n'arrive pas a trouver une documentation me permettant de tester la solution
    les .zip ou .gz sur le site une fois decompresser ne me donne pas un installer
    je ne m'y connais pas en java
    si quelqu'un a deja mis en place cette application je suis très interresé par son mode operatoire
    mercy

    kellynosoucy

    mon mail: kellynosoucy@yahoo.fr

  • # Excellente Initiative

    Posté par  . Évalué à 2.

    Bonjour,
    Je suis tombé sur cet article un peu par hasard.
    J'ai travaillé pendant 6 ans chez Axway au niveau du Support, donc je connais particulièrement bien les produits CFT, Gateway, Interpel et les nouveaux arrivés tels que Interchange, SecureTransport.
    Actuellement, je travaille toujours sur ces produits, mais je suis passés du côté clients.

    Je commencerai par dire que je ne suis pas entièrement d'accord sur le fait que le PESIT est veillissant, certe il était à l'origine pour le X25, mais la version E du PESIT fonctionne parfaitement sur TCP/IP. Et lorsque l'on connait bien le protocole et comment le configurer correctement au niveau des moniteurs de transferts, les performances sont là, ainsi que la fiabilité du transfert, mais surtout il ne faut pas oublier la possibilité de faire du transcodage avec les plateformes MVS par exemple.
    Je pense donc qu'il ne faut pas jeter à la poubelle ces vieux protocoles, car ils sont et resteront longtemps utilisés au sein des SI, surtout pour ceux qui ont encore beaucoup de SI sous MainFrame :)

    Je pense donc que, pour que votre projet sorte de la DGFIP, pour ne plus être qu'une solution in-house mais devienne une alternative sérieuse, vous devriez réellement implémenter la version E du PESIT. Les spécifications sont accessibles via le site du CFONB ( peut-être pas gratuite … )

    Je vous invite aussi sérieusement a vous intéresser au protocole EBICS, qui remplace ETBAC5. J'avais d'ailleurs vu sur ce même site un article sur un client ebics JAVA open source aussi, pouvant être intégré dans un framework existant.
    http://linuxfr.org/news/enfin-un-client-ebics-java-libre

    Bien cordialement

    • [^] # Re: Excellente Initiative

      Posté par  . Évalué à 1. Dernière modification le 28 août 2012 à 21:06.

      Je comprend votre position. PESIT (en version E) reste encore très utilisé. Mais il faut aussi être logique, si le CFONB prépare EBICS, c'est pour remplacer pas seulement ETEBAC mais aussi PESIT. Après, y arriveront ils ? C'est une autre question…

      Sur le fait de développer un module compatible E PESIT (ou EBICS), pourquoi pas, mais ça prend du temps. De plus, si PESIT est très utilisé, il n'en reste pas moins un peu abscons lorsque l'on lit ses spécifications (gratuites depuis peu de temps). C'est un peu comme FTP, ces protocoles, certes efficaces, sont un peu "compliqués". PESIT est "complexe" dans son organisation et dans la compréhension des entêtes, sans compter qu'il semblerait qu'un PESIT d'un éditeur ne soit pas forcément totalement compatible avec un PESIT d'un autre éditeur. EBICS quand à lui est basé sur du HTTP plus du XML, donc pas besoin d'un développement lourd pour ça. Mais est-ce efficace ? On peut en douter (au regard des performances désastreuses de SOAP par exemple). Mais bon il s'agit plus d'une question de chapelle… Et ce n'est pas dans mon intention.

      Lorsque Waarp R66 a été créé, c'est parce que nous avions de réels problèmes avec la stabilité du moniteur CFT (au delà de 10 000 transferts / jour), et nous n'avions pas les moyens d'acheter la Gateway XFB (x50 en prix)…

      Mais si un jour quelqu'un subventionne ce développement, nous pourrons le faire.

      Enfin, pour répondre à une demande quelques posts avant : après étude, une interface Thrift va être prochainement disponible. Elle permettra d'interagir avec le moniteur (info, status, mais aussi déclenchement de transfert). Pour le moment, seul un client Java a été réalisé à titre d'exemple. Mais a priori, si ça fonctionne en Java, cela devrait aussi fonctionner dans les autres langages…

      Nous sommes toujours à l'écoute des bonnes idées !
      Merci à ce forum pour celle-ci !!!

      Bien à tous,
      Frederic

  • # Lien

    Posté par  (site web personnel) . Évalué à 0.

    Pour plus d'infos sur le transfert de fichiers avec Waarp :
    - la doc : http://waarp.github.com/Waarp/APIReferences.html
    - téléchargements : http://waarp.github.com/Waarp/Downloads.html
    A+

  • # Compatibilité avec les outils d'Axway

    Posté par  . Évalué à 0.

    Je découvre CFT à l'occasion de la demande d'un client potentiel qui demande que nous soyons capable d'échanger des fichiers en CFT/IP. Difficile de se retrouver dans cet univers de transferts sécurisés et des réponses à apporter rapidement! Si quelques uns pouvaient m'aider en répondant à ces questions:
    L'outil Waarp permet-il d'échanger avec les outils CFT d'Axway?
    Si oui, y-a-t-il des restrictions par rapport à l'utilisation d'un outil d'Axway?
    Si non, existe-t-il d'autres outils permettant de faire du CFT et qui soient compatibles avec les outils d'Axway?
    Quelqu'un connaît-il le prix de la licence d'un logiciel Axway répondant à ce besoin (là encore je n'ai pas réussi à trouver l'info)?
    Merci d'avance pour votre aide.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.