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 !!!
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.
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 ;-)
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…
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.
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).
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.
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: Excellente Initiative
Posté par fred75 . En réponse à la dépêche WAARP : le moniteur de transfert de fichier Open Source. É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
[^] # Re: FTM <> MFT
Posté par fred75 . En réponse à la dépêche WAARP : le moniteur de transfert de fichier Open Source. É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 !
[^] # Re: Waarp en production depuis trois ans à la DGFiP ??
Posté par fred75 . En réponse à la dépêche WAARP : le moniteur de transfert de fichier Open Source. Évalué à 2.
Pour ceux qui n'auraient pas cherché, il y a aussi :
- Quartz : http://quartz-scheduler.org/
- Ortro : http://www.ortro.net/
[^] # Re: Petites précisions
Posté par fred75 . En réponse à la dépêche WAARP : le moniteur de transfert de fichier Open Source. É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: xp
Posté par fred75 . En réponse à la dépêche WAARP : le moniteur de transfert de fichier Open Source. É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: Waarp en production depuis trois ans à la DGFiP ??
Posté par fred75 . En réponse à la dépêche WAARP : le moniteur de transfert de fichier Open Source. É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: xp
Posté par fred75 . En réponse à la dépêche WAARP : le moniteur de transfert de fichier Open Source. É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: CFT/PeSIT
Posté par fred75 . En réponse à la dépêche WAARP : le moniteur de transfert de fichier Open Source. É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: Waarp en production depuis trois ans à la DGFiP ??
Posté par fred75 . En réponse à la dépêche WAARP : le moniteur de transfert de fichier Open Source. É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.