Vocabulaire SEPAmail : mode d'échange canonique versus flash

Le standard SEPAmail définit la structuration de l'information échangée, une organisation pour l'adressage, les séquences d'envoi/réception.
Concernant l'échange à proprement parler de l'information, la documentation cite de deux modes : le mode canonique et le mode flash.

Le mode d'échange canonique

L'adjectif canonique doit être compris dans son utilisation usuelle en mathématiques comme en informatique, c'est à dire standard ou encore naturel et instinctif.
SEPAmail est une messagerie sur internet, le mode d'échange canonique est donc celui de la messagerie électronique, c'est à dire le mécanisme d'échange proposé par le protocole SMTP.

Ce protocole met en œuvre le transfert direct de serveur à serveur et le relais si besoin. Il repose sur des protocoles tiers tels que le DNS, IP, TCP, ainsi qu'un mécanisme d'extensions du protocole qui permet notamment l'implémentation de priorité.
Enfin, il définit une liste de commandes pour permettre de dialoguer entre deux serveurs et, si besoin, différer la remise effective du message.
Cette souplesse protocolaire permet d'éviter de perdre des messages si l'un des composants automates de la messagerie n'est pas joignable.

En théorie, un message peut être distribué à son destinataire plusieurs jours après l'émission par son expéditeur. En pratique, la messagerie électronique est souvent très rapide; nous sommes habitués depuis des années à recevoir nos messages électroniques dans un temps très court (souvent plus rapide que les SMS) et c'est même cette particularité qui a fait le succès et la généralisation de la messagerie électronique.

Pour être efficientes dans la mise en œuvre du protocole SMTP, la plupart des applications dédiées à l'échange des messages (applications dites MTA comme Mail Tranfert Agent) ont mis en place un mécanisme efficace de files d'attente et c'est ce mécanisme qui permet une bonne articulation entre des applications différentes avec des contraintes souvent divergentes.

SEPAmail repose nativement sur le protocole SMTP pour la structuration de l'information (enveloppe SEPAmail = enveloppe SMTP).
SEPAmail repose aussi nativement sur le protocole SMTP pour l'échange de cette information.
Ainsi, une enveloppe SEPAmail peut transiter par les systèmes de messagerie électronique sans aucune modification de ces systèmes.
Avec le mode d'échange canonique, SEPAmail est totalement compatible avec la messagerie électronique existante.

Le mode d'échange flash

Le mode d'échange canonique ne garantit pas un temps très court pour l'échange des données.
SEPAmail définit donc, lorsqu'il est important d'échanger rapidement une enveloppe SEPAmail, un mode d'échange flash.

Celui-ci repose sur un mécanisme de services web avec une garantie de réponse courte dite flash, de l'ordre de quelques secondes, comme en monétique.

C'est ce mode d'échange qui est en cours d'expérimentation dans l'esprit  qui peut le plus peut le moins. Cette expérimentation permet de bien s'assurer des délais raisonnables bout à bout que l'on peut garantir selon la charge et l'organisation des systèmes d'information bancaires ainsi que les coûts maximums de l'infrastructure flash.

Quelques réflexions sur le mode d'échange batch

La monétique et les systèmes informatiques bancaires en général sont assez friands de traitements par lots (batch processing) à des temps programmés à l'avance (vacations) et donc non à la demande comme les traitements transactionnels sur requêtes d'un client. Certains acteurs bancaires adhérents de SEPAmail mettent en œuvre de tels traitements au sein de leur système d'information.

Ce mode d'échange n'est pas souhaité entre les adhérents pour plusieurs raisons :

• il va à l'encontre de la logique message unitaire de SEPAmail
• il induit une gestion centralisée et pilotée de la charge alors que SEPAmail privilégie une gestion répartie pair à pair de l'échange.
• il repose sur un mode non transactionnel alors que SEPAmail utilise le réseau IP, transactionnel par nature

Le web service sur internet et l'illusion du temps réel

Le temps réel est à la mode dans le monde internet et le service web semble être l'objet de toutes les attentions actuelles pour mettre en œuvre du temps réel.

Cependant, derrière ce terme se cache des contradictions qui sont rarement mises en avant.

Un système temps réel est généralement défini par sa capacité à délivrer un résultat dans un temps fini et garanti, ce qui oblige toute la chaîne des procédés utilisés à être en temps réel.

Or, le réseau IP repose aujourd'hui :

• sur des machines dont les système d'exploitation ne sont pas des systèmes temps réel
• sur des protocoles qui ne peuvent garantir le résultat et encore moins en temps fini

Le réseau IP repose sur le paradigme du best of qui est peu compatible avec le temps réel.

On devrait donc parler de temps court au lieu de temps réel. On peut parler aussi de temps synchrone entre deux automates, dans la transaction entre le serveur et le client.

Le mode flash SEPAmail est un mode synchrone alors que le mode canonique est un mode asynchrone.

Le service web (web services) peut être vu comme une généralisation du service de page web à l'internaute.
Les protocole de la famille tcp/ip (dont http) ont permis dans un premier temps à des automates de servir de l'information sous forme de pages html à des êtres humains organisés.

Très vite, des automates programmables doués d'ubiquité se sont substitués aux internautes pour transformer, traiter l'information et la restituer autrement (opérés de façon exceptionnelles par exemple par google, yahoo, kelkoo). Les services webs sont apparus pour permettre la communication et l'échange de données entre applications et systèmes hétérogènes dans des environnements distribués.

Les services webs présentent des particularités souvent oubliées et qu'il convient de bien appréhender dans le cadre de SEPAmail. Ils sont généralement en mode client/serveur avec une structure de coût essentiellement déportée sur le serveur. Ils sont plutôt gros consommateurs de ressources par rapport à d'autres implémentations. Ils sont souvent concurrentiels sur le réseau IP des transactions hommes/machines et l'articulation avec les échanges homme/machine est rarement facile à mettre en place.

L'engouement pour les architecture reposant sur des appels de procédures à distances (RPC ou Remote Procedure Call) a permis de régler quelques problématiques liés au secret de fabrication, au coûts d'intégration ou encore aux contraintes de distribution des services.

C'est dans ce contexte que SEPAmail a conçu un mode flash de cette messagerie sécurisée qui, devrait, à terme, n'être utilisé que pour les messages à forte valeur ajoutée pour les clients finaux.