Eher öffentliche Wege

Mail
Wenn Sie in Thunderbird, Pegasus oder Outlook auf „Senden“ klicken, nimmt dieses Programm Kontakt zu einem sogenannten Mailserver auf. Welcher das ist, das haben Sie selbst (oder Ihre EDV-Abteilung) im Programm eingetragen.
Das Protokoll, das dabei verwendet wird, nennt sich SMTP – Simple Mail Transfer Protocol. Es wird bei Wikipedia detailliert beschrieben. Dieses Protokoll ist dafür gemacht, E-Mails von Ihnen an Ihren Server und von da aus quer durch die Welt an viele andere Server zu senden, bis sie endlich im Mailserver des Empfängers gelandet sind. Und da liegen sie dann normalerweise so lange, bis der Adressat seinerseits Kontakt mit seinem Mailserver aufnimmt und seine Mailbox – also seinen elektronischen Briefkasten – leert. Womit wir schon beim nächsten Punkt wären:

E-Mails empfangen

Schon lange gibt es das Protokoll POP – Post Office Protocol. Gebräuchlich ist es in Version 3, und man liest überall nur von POP3. Es ist vergleichsweise spartanisch, man kann damit eine Liste der aktuell auf dem Server wartenden Mails abfragen, die Mails zu sich herunterladen und sie vom Server löschen. Allzu viel mehr bietet es nicht, aber für die meisten Benutzer ist mehr auch gar nicht nötig. Hat man seine Post erst mal auf dem lokalen Rechner, kann man sie (oft automatisch über Filter im E-Mail-Programm) in unterschiedliche Ordner sortieren und ist ganz alleine Herr seiner Daten.
Wer aber mehr will, für den ist das Protokoll IMAP – Internet Message Access Protocol – gedacht. Zum einen können die E-Mails hier theoretisch ewig auf dem Server gelassen werden, zum anderen sind sie auch dort schon sauber in Ordnern sortiert (vergleichbar einer Verzeichnisstruktur im Dateisystem), und man kann seine E-Mails sogar mit anderen – zum Beispiel einem ganzen Projektteam – teilen. Obwohl IMAP kaum jünger ist als POP3, ist es längst nicht in allen Mail-Servern implementiert.

Die Eigenheiten beider Protokolle sowie deren Vor- und Nachteile für die übliche Nutzung werden in Wikipedia sowohl zu POP3 als auch zu IMAP ausreichend dargestellt.
Worum es uns hier geht ist aber nicht primär die Verwendung von Mails im klassischen Sinne, also für die Kommunikation zwischen zwei oder mehr Menschen. Uns interessiert, wie gut E-Mails im EDI-Betrieb einsetzbar sind.

E-Mail und EDI

Prinzipiell lassen sich per E-Mail beliebige Daten austauschen. Also alles, was im EDI-Umfeld so durch die Welt geschickt wird.
Erste Wahl ist diese Kommunikationsform aber nicht. Hier die wichtigsten Gründe:

• Einige Mailserver haben Größenbeschränkungen, so könnten große Anhänge einfach verloren gehen.
• E-Mails werden heute üblicherweise nicht mehr mit einer Empfangsbestätigung quittiert, man weiß also nie, ob die Daten auch angekommen sind.
• Es gibt keine Garantie dafür, dass eine E-Mail schnell ans Ziel kommt – oder überhaupt.
• E-Mails selbst sind erst einmal in keiner Weise gegen Fremdzugriff (Mitlesen oder Manipulation) gesichert. Natürlich kann man mit PGP & Co. zumindest die Inhalte verschlüsseln und/oder signieren, aber es gibt sicherere Wege.
• Man ist den Launen der eingesetzten Mail-Software unterworfen (es gibt z.B. Mailserver, die ungefragt das Encoding angehängter Texte umstellen.)
• Virenscanner und andere Sicherheitsvorkehrungen können einzelne Anhänge oder ganze E-Mails verschlucken oder blockieren.

Aufgrund dieser Mankos normaler E-Mails hat man AS1 (Applicability Statement 1) entwickelt, einen Standard zur gesicherten Übertragung von Geschäftsdaten per E-Mail. Allerdings hat sich dieser nie so wirklich durchgesetzt. Das können wir also getrost ignorieren.

Nach wie vor werden Geschäftsdaten, auch im EDI-Umfeld, per E-Mail versendet. Eigentlich sollte man hier eher von „Halb-EDI“ sprechen, da in diesen Fällen meist an einem Ende ein Mensch sitzt. Beispielsweise werden Rechnungen automatisiert im PDF-Format erstellt und per Mail verschickt, oder Sachbearbeiter eines eher kleinen Kunden geben Bestellungen noch manuell in Excel-Dateien, die dann per Mail in die automatische Verarbeitung beim Lieferanten gespeist werden. Im echten EDI, wo Daten von einem System zu einem anderen gehen, ohne Eingriff des Menschen, sollte E-Mail inzwischen ausgestorben sein.
Für die Prozesse, an denen noch Menschen beteiligt sind, sollte aber eine EDI-Software vorsichtshalber auch in der Lage sein, Daten per E-Mail zu versenden und zu empfangen. Vorzugsweise sollten dabei natürlich alle Standard-Protokolle (SMTP, POP3, IMAP) unterstützt werden.

FTP für EDI
Zunächst kann man mit FTP nur eines tun: Dateien übertragen. Man kann sich an einem FTP-Server anmelden und entweder mit „get Dateiname“ eine Datei herunterladen (bzw. mit „mget Dateimuster“ auch mehrere) oder mit „put Dateiname“ eine Datei hochladen (analog mit „mput Dateimuster“ mehrere). Fein. Anschließend liegt also eine Datei herum, lokal oder eben auf dem Server. Und nun?
Nun muss die EDI-Software in der Lage sein, die Datei aufzugreifen und zu verarbeiten. Im einfachsten Falle kann der Ablauf so aussehen:

• Ein System-Job (Cron Job unter Unix bzw. die Windows-Entsprechung) holt regelmäßig Dateien per FTP irgendwo ab oder der Partner sendet sie regelmäßig an Ihren FTP-Server. In beiden Fällen landen die Daten in lokalen Verzeichnissen.
• Die EDI-Software schaut wiederum regelmäßig in das entsprechende Verzeichnis, ob neue Dateien da sind.
• Wenn Dateien da sind, werden diese eingelesen und verarbeitet.

Und auch die andere Richtung könnte ähnlich laufen: Das Ergebnis der Verarbeitung im EDI-System wird evtl. wieder irgendwo in einem Verzeichnis abgelegt, damit ein weiterer System-Cron die Daten per FTP anderswo hinschicken kann bzw. sie vom Partner bei Ihnen abgeholt werden können.

Das wäre die Lösung für ein sehr einfaches EDI-System, das selbst keinerlei FTP-Fähigkeiten besitzt.
Schöner ist natürlich, wenn alles in einer Hand liegt, die EDI-Software also selbst per FTP Dateien holen oder auch entgegennehmen kann. In dem Fall gibt es z.B. für den Eingang von Daten per FTP zwei Möglichkeiten:

1. Die EDI-Software baut selbst eine FTP-Verbindung zu einem entfernten Server auf, besorgt sich dort die Daten und verarbeitet sie.
2. Ein entfernter Client nimmt Verbindung direkt zum EDI-System auf (das quasi FTP-Server spielt) und übergibt ihm die Dateien.

In beiden Fällen entfallen die Zwischenschritte, Daten lokal abzulegen und dann zeitgesteuert wieder einzulesen. Variante zwei ermöglicht damit sogar eine sofortige Verarbeitung der Daten, sobald sie vom Partner erhalten werden. Bei zeitkritischen Inhalten ein großer Vorteil.
Der Rückweg gestaltet sich natürlich auch einfacher und schneller, wenn die eingesetzte EDI-Software einen eigenen FTP-Client mitbringt und ihre Daten ohne Verzögerung ausliefern kann.

Vorteile

• FTP überträgt Daten direkt zum Zielsystem. Sie wissen also genau, ob Ihre Daten angekommen sind und wann.
  Dass eine Datei (wie bei E-Mail möglich) unterwegs verloren geht, kann praktisch ausgeschlossen werden.
• FTP-Clients gibt es praktisch auf jedem Betriebssystem, damit ist jeder Partner in der Lage, mit Ihnen zu kommunizieren.
• Wählt man die binäre Übertragung, kann man sicher sein, dass die Daten unverfälscht angekommen sind.

Nachteile

• Sie erfahren, ob die Übertragung der Daten funktioniert hat. Ob das EDI-System diese auch in die Verarbeitung genommen hat, bleibt unklar.
• FTP ist per se nicht gegen Mithören und Manipulation gesichert. Hier gibt es mit FTPS (also dem Einsatz von SSL während der FTP-Übertragung) allerdings eine Abhilfe.
• Firewalls und NATting stören gerne mal die Aushandlung der Daten-Ports. Da lässt sich ein System vom anderen nicht vorschreiben, welchen Port es zu öffnen hat, bzw. der Port kann nicht durchgeroutet werden.
• Vernünftige Firewalls bekommen zwar normalerweise mit, welcher Port ausgehandelt wird, und öffnen diesen. Wird allerdings eine Verschlüsselung mittels SSL eingesetzt, kann das Aushandeln nicht mehr mitgehört werden. Das kann den Einsatz von FTP(S) zumindest sehr erschweren und einiges an Zusatzkonfigurationen nötig machen (Port Ranges definieren etc.).

Man hat auch einen auf FTP basierenden Standard zur sicheren Datenübermittlung geschaffen, der sich AS3 nennt. Hier gibt es Empfangsbestätigungen (alias MDNs) usw., doch wie AS1 (das auf E-Mail basierende Pendant) hat er sich nie wirklich durchgesetzt und ist in der Praxis nicht von Bedeutung.

FTP ist also schon wesentlich besser für EDI-Szenarien geeignet als E-Mail und wird auch intensiv genutzt. Allerdings gibt es z.B. mit AS2 optimalere Kommunikationsformen.

(Fall Sie hier übrigens SFTP vermisst haben: Da dieses Protokoll technisch nur bedingt FTP ähnelt, dafür aber eng mit SSH verbandelt ist, gibt es dazu einen eigenen Artikel.)

Im Browser oder automatisch

Die gerade angesprochenen HTML-Formulare sind, zusammen mit den Download-Links auf Webseiten, die den meisten Benutzern vertraute Art, Daten per HTTP zu übertragen. Man kann ein paar Informationen eingeben, eventuell noch eine Datei zum Upload mit angeben (oder sogar mehrere), und mit einem Druck auf’s Knöpfchen geht alles zum Webserver. Der kann dann womöglich, nach Auswertung der Angaben, nicht nur mit einer Webseite antworten, sondern mit einer ganzen Datendatei, die man auf der Plate speichern kann. Zum Klick auf einen Download-Link müssen wir wohl nichts sagen. Beispielsweise können Sie sich bei einem internationalen Paketdienst (mit braunen Autos) anmelden und bekommen dann speziell für Sie erstellte Seiten zu sehen, die z.B. Rechnungen ihrer Firma per Download zur Verfügung stellen.
Das wäre aber noch kein wirkliches EDI, denn nur auf einer Seite steht ein System, das Daten selbständig entgegennimmt und verarbeitet bzw. auch bereitstellt. Auf der anderen Seite sitzt ein Mensch vor dem Browser. Nur … das muss ja nicht so sein. Alles, was ein Mensch in einem Formular angeben kann (und erst recht, was in einem simplen Link steht), kann auch eine Software automatisch eintragen.

Einfache GET Requests

Wenn Sie in der Lage sind, mit einem Klick auf diesen Link eine Datei zu laden (was ja letztlich auch nur Ihr Browser für Sie übernimmt), kann auch ein EDI-System sich Daten besorgen, indem es dieselbe URL anspricht: http://lobster.de/wp-content/uploads/2014/06/Lobster_data_Broschüre_web_2014.pdf
Zugegeben, das ist ein schlechtes Beispiel für EDI, da ein PDF-Dokument ja nun gerade nicht für EDI-Prozesse geeignet ist.

Die oben dargestellte URL enthält tatsächlich nur die Adresse eines Dokumentes. Wollen Sie Daten versenden, können diese einfach mit in die URL gesetzt werden:
http://www.example.com/formular.cgi?parameter1=wert1&parameter2=wert2
(näheres dazu bei Wikipedia)

Diese Methode, Daten an den Server zu senden, nennt sich GET. Sie birgt einige Nachteile. Zum einen kann man in die URL nur eine begrenzte Anzahl relativ kleiner Werte stecken. Einige ganz alte Webserver vertragen URLs nur bis zu 255 Zeichen Länge, und irgendwann wird’s ja auch unübersichtlich. Dateien sind damit praktisch nicht übertragbar. Und mitlesen kann das auch noch jeder, da die ganze URL offen über’s Netz geht und sogar auf diversen Rechnern zu Caching-Zwecken zwischengespeichert werden kann.
Aber zusammen mit Authentifizierungsmechanismen wie HTTP Basic Authentication kann es durchaus dazu taugen, zu einer bestimmten Kundennummer und einem vorgegebenen Datum z.B. alle neuen Aufträge abzuholen.

Komplexer: POST

Hier muss man eigentlich drei Varianten unterscheiden:

• Einfaches POST: Was bei GET in der URL stünde, wird nun als Body des Requests über einen Datenstrom an den Server geschickt. Also z.B.: parameter1=wert1&parameter2=wert2&Datei=Langer%20Text.
• Raw POST: eignet sich wunderbar, um eine einzelne Datei direkt zum Server zu senden. Der Body, also der Datenstrom, der nach den Headern zum Server geht, enthält den Dateiinhalt, so, wie er ist. Man muss hier auch keine spezielle Zeichen extra codieren, wie im Beispiel zum einfachen POST das Leerzeichen durch %20 (was bei einem GET übrigens erst recht nötig wäre).
• Multipart/Form-Data: Man könnte es als eine Kombination aus den anderen beiden anderen sehen. Einerseits kann man damit wie mit einem Raw POST sehr gut große Dateien übertragen (meist Base64-codiert), andererseits kann man aber mehrere Parameter (und sogar mehrere Dateien) kombinieren. Der Body wird, ähnlich wie bei einer E-Mail mit mehreren Anhängen, in einzelne Teile untergliedert, von denen jeder einen Parameter enthält. Ob dieser Parameter nur einen kurzen Text oder eine ganze binäre Datei enthält, ist dabei egal. Durch Nutzung von MIME-Typen und entsprechenden Content Encodings kann jeder Teil passend zu seinem Inhalt übertragen werden.

Jede Variante hat so ihre Vor- und Nachteile. Sie sollten im Einzelfall entscheiden können, welche Sie einsetzen. HTML-Formulare verwenden meist entweder einfaches POST, wenn nur ein paar Angaben zu übertragen sind, oder gleich Multipart/Form-Data, wenn auch Dateien mitgesendet werden sollen. Daher auch der Name „Multipart/Form-Data„. Das Kontaktformular dieser Seiten beginnt übrigens auch mit folgendem HTML-Tag:

<form enctype="multipart/form-data" method="post" ...>

Identifizierung

Ursprünglich diente HTTP dazu, Informationen möglichst der ganzen Welt zur Verfügung zu stellen. Doch sehr schnell gab es die ersten Inhalte, die eben doch nur einem begrenzten Nutzerkreis zugänglich sein sollten. Also gibt es auch Möglichkeiten, den Nutzer oder das System, kurz: den Client, der eine URL aufruft, zu identifizieren. Umgekehrt möchte manchmal auch der Client sicher sein, den richtigen Server anzusprechen und nicht irgendwelchen Phishern oder Spoofern aufzusitzen.

• Eine einfache Art, den Client gegenüber dem Server zu identifizieren, sind Nutzername und Passwort. Die Übertragung dieser Angaben kann prinzipiell auf zwei verschiedene Arten erfolgen, die hier näher beschrieben sind (Nun gut, da sind drei Arten genannt, aber eine davon ist kein Standard).
• Der Server umgekehrt kann sich eigentlich nur dem Client gegenüber identifizieren, indem er ein beglaubigtes Zertifikat vorlegt. Das passiert in dem Moment, wo HTTPS ins Spiel kommt, also die SSL-Verschlüsselung der HTTP-Übertragungen. Sie werden sicher schon auf den einen oder anderen Dialog gestoßen sein, der Ihnen meldete, dass das Zertifikat eines Servers aus diesen oder jenen Gründen nicht vertrauenswürdig sei. Bei vielen Seiten ignoriert man die Warnung, bei seiner Bank dann aber hoffentlich nicht mehr.
• Denselben Mechanismus kann man auch nutzen, um den Client als tatsächlich berechtigten User auszuweisen. Dazu wird das mit dem Zertifikat einfach umgedreht. Der Client übergibt seinerseits dem Server ein Zertifikat, das dieser überprüfen kann. In Szenarien, die nur einen genau definierten Kreis von Clients zulassen, kann z.B. das gültige Zertifikat einfach beim Server hinterlegt sein.

Vorsicht, Lauscher!

HTTP selbst besitzt keine Verschlüsselung. Selbst HTTP Basic Authentification, die einfachste Art, sich an einem Webserver „einzuloggen“, überträgt Username und Passwort zwar Base64-codiert, aber nicht verschlüsselt. Wenn man also einigermaßen sicher gehen will, dass niemand mithört, sollte man eine HTTPS-Verbindung nutzen, die alles, was über die Leitung geht, SSL-verschlüsselt.

WebServices

WebServices und HTTP hängen nicht zwingend miteinander zusammen, allerdings werden in der Praxis die allermeisten WebServices via HTTP angesprochen, da sich dieses Protokoll als Frage-Antwort-Protokoll wunderbar eignet. Man sendet eine Anfrage an den Server und bekommt sofort als Antwort das Ergebnis der Anfrage. Theoretisch ließen sich WebServices aber auch via FTP oder gar E-Mail abwickeln, wenn Antwortzeiten keine große Rolle spielen.
Die meistgenutzte Sorte von WebServices sind SOAP-Requests, allerdings gibt es auch andere „Geschmacksrichtungen“, wie z.B. REST oder RPC. Ausführlich ist das alles wieder mal bei Wikipedia beschrieben. Um wenigstens SOAP kurz anzureißen, das funktioniert so:
Der Client (z.B. eine EDI-Software) schickt ein XML-Dokument mit einer Anfrage (HTTP POST) an den Server. Diese Anfrage kann eine Bestandabfrage sein, eine Zimmerreservierung oder was auch immer der Server anzunehmen bereit ist. Das XML-Dokument besteht aus einem sogenannten SOAP Envelope mit ein paar Header-Daten und einem SOAP Body mit den eigentlichen Nutzdaten der Anfrage.
Der Server (auch das kann ein EDI-System sein) nimmt das XML entgegen, wertet es aus, steckt das Ergebnis wiederum in einen SOAP Body, der in einen SOAP Envelope kommt, und reicht diesen als Antwort auf den Request an den Client zurück.
In dem Artikel über EAI und EDI sind kleine Beispiele solcher SOAP-XML-Anfragen zu finden.

Vorteile

• Das schöne an HTTP ist, dass es ein Frage-Antwort-Protokoll ist. Während man eine E-Mail einfach abfeuert und hofft, dass sie ankommt, und FTP lediglich eine erfolgreiche Übertragung der Daten bestätigen kann, hat HTTP das Zeug, auch gleich Auskunft darüber zu geben, ob die Daten auch verarbeitet werden konnten. Ja, es kann sogar – wie ein WebService – das Ergebnis dieser Verarbeitung zurücksenden. Und das, wohlgemerkt, synchron, also direkt als Antwort auf den eingehenden Request.
• Wenn es irgend etwas gibt, das durch die meisten Firewalls dieser Welt durchkommt, dann ist es das HTTP-Protokoll.
• HTTP-Server gibt es wie Sand am Meer, die bekanntesten sind sicher Apache und MS IIS.
• Eine HTTP-basierte Schnittstelle zum Datei-Up/Download kann, wenn sie entsprechend designed ist, gleichermaßen vom Menschen am Browser wie auch von einer automatisch arbeitenden Software angesprochen werden.

Nachteile

• HTTP wurde ursprünglich nicht für den Austausch wichtiger Geschäftsdaten konzipiert. Zwar gibt es Mechanismen zur Authentifizierung sowohl des Clients gegenüber dem Server als auch anders herum, und die Daten können auch verschlüsselt werden. Jeder dieser Mechanismen für sich ist standardisiert, aber nicht ihre Kombination. Im Prinzip kann sich jeder die Techniken herauspicken, die er persönlich für sinnvoll hält.
• Die Signatur von Daten ist im HTTP-Protokoll und seinen „Anhängseln“ nicht möglich. Es kann also letztlich nicht nachgewiesen werden, dass bestimmte Daten auch wirklich unverfälscht von dem kommen, der sie vermeintlich abgesendet hat.

Diese Nachteile werden durch den Standard AS2 adressiert. AS2 nutzt als Übertragungsprotokoll HTTP, jedoch sind hier diverse Mechanismen festgelegt, wie die Authentifizierung zwischen den beteiligten Kommunikationspartnern zu geschehen hat, wie die Daten verschlüsselt und signiert werden usw. AS2 kann auch nur zwischen zwei Partnern gesprochen werden, die sich vorher darauf verständigt und untereinander Kennungen und Zertifikate ausgetauscht haben. Und: Für AS2-Software gibt es eine Art Gütesiegel, das garantiert, dass sich diese Software an den definierten Standard hält. Alles weitere dazu in einem eigenen Artikel.
Wenn Sie Benutzern die Möglichkeit bieten wollen, sowohl manuell als auch automatisiert Daten zu oder von Ihnen zu übertragen, ist HTTP eine feine Sache. Sinnvollerweise sollte die EDI-Software auch HTTP-Schnittstellen zur Verfügung stellen bzw. sich an einen der verbreiteten Webserver anbinden lassen. Haben Sie hohe Anforderungen bzgl. der Sicherheit, sollten Sie allerdings auf ein EDI-System mit AS2-Integration setzen.

AS2 ist ein Übertragungsverfahren, das speziell für den Austausch von Geschäftsdaten entwickelt wurde. Dementsprechend hat man hier von Anfang an Wert auf Dinge wie Sicherheit und Nachweisbarkeit gelegt. Sicherheit wird durch Verschlüsselung und Signatur erreicht, die Nachweisbarkeit durch Empfangsbestätigungen (sogenannte MDNs).
Die Basis bildet HTTP bzw. HTTPS. Damit hat man den Vorteil, dass die Antwort auf eine Übertragung sofort (synchron) noch in derselben Verbindung gegeben werden kann. Außerdem ist das HTTP-Protokoll praktisch überall einsetzbar und nur in seltenen Fällen von Firewalls geblockt. Mit HTTPS (also SSL bzw. TLS) hat man zugleich eine Grundverschlüsselung der gesamten Kommunikation. Im Unterschied zu einfachem HTTP gibt es bei AS2 aber für Daten nur die Sende-Richtung (bei HTTP wäre das ein POST oder PUT), aber keinen Download von Dateien wie bei einem HTTP GET (es kommt höchstens eine kleine Empfangsbestätigung zurück).
Das ist aber noch nicht alles. Wie schon bei SSL, so kommen nun noch weitere Zertifikate zum Einsatz. Die Daten werden noch mal extra verschlüsselt und signiert. Hier wird der S/MIME-Standard genutzt. Und: Es gibt eine Empfangsbestätigung. Aber eines nach dem anderen.

Erst mal kurz zu diesen Zertifikaten:
Ganz vereinfacht arbeiten Zertifikate (wir sprechen hier speziell von Public-Key-Zertifikaten) mit einem genialen mathematischen Kunstgriff, nämlich der sogenannten asynchronen Verschlüsselung. Dieses Verfahren nutzt zwei Schlüsseln (große Zahlen), wobei man immer einen Schlüssel zur Verschlüsselung verwenden kann, dann aber den anderen zur Entschlüsselung braucht. Man kann also denselben Schlüssel, mit dem verschlüsselt wurde, nicht wieder zur Entschlüsselung einsetzen.
Das praktische daran ist: Einen der beiden Schlüssel kann man veröffentlichen (das ist der „Public Key“), damit jedermann Daten, die er einem schicken will, damit verschlüsseln kann. Und niemand, nicht mal er selbst, kann die Daten wieder entschlüsseln. Man selbst kann dies aber mit dem anderen Code, den man für sich behalten hat (sinnigerweise „Private Key“ genannt), durchführen.
So kann sichergestellt werden, dass wirklich nur der Adressat der Sendung diese auch lesen kann.
Umgekehrt funktioniert das auch. Verschlüsseln Sie etwas mit Ihrem privaten Schlüssel, kann es nur mit Ihrem öffentlichen wieder lesbar gemacht werden. So ist garantiert, dass die Daten auch wirklich von Ihnen stammen (solange der private Schlüssel niemandem in die Hände gefallen ist…). Diese Umkehrung macht man sich bei der sogenannten Signatur zu Nutze. Nur wird dabei nicht die ganze Nachricht verschlüsselt. Stattdessen wird ein sogenannter Hashwert über die Daten gebildet (eine Art Kennzahl, simpelstes Beispiel wäre eine Quersumme) und nur dieser Wert mit dem privaten Schlüssel codiert. Der Empfänger bildet über die Daten denselben Hashwert (setzt also denselben Algorithmus ein), entschlüsselt den Wert des Senders und vergleicht. Stimmen beide Werte nicht überein, wurden entweder die Daten manipuliert oder der angebliche Absender stimmt nicht. Auf jeden Fall stinkt das, was er da bekommen hat, und er kann es zurückweisen.
Zertifikate enthalten den öffentlichen Schlüssel eines solchen Schlüsselpärchens und ein paar Metadaten (wem gehört das Ding, für welchen Server gilt es, solche Sachen). Außerdem kann das Zertifikat darüber informieren, dass (und von wem) es beglaubigt wurde, man ihm also vertrauen kann. Das muss man wissen, um das Prinzip von AS2 zu verstehen.

Spielen wir das alte Alice-und-Bob-Spiel. Alice will Daten per AS2 an Bob senden. Folgende Schritte finden während der Übertragung statt:

1. Alice bildet einen Hashwert über die Daten und signiert diesen mit ihrem privaten Schlüssel.
2. Alice verschlüsselt die Daten (plus den signierten Hashwert) mit Bobs öffentlichem Schlüssel.
3. Alice baut eine HTTP- oder HTTPS-Verbindung zu Bob auf.
4. Im Falle HTTPS wird die ganze Übertragung noch mal extra verschlüsselt, darauf gehen wir hier nicht näher ein.
5. In diversen speziellen HTTP-Headern werden die Kennungen (Seriennummern) der verwendeten Zertifikate mitgesendet, außerdem die AS2-Kennungen von Sender und Empfänger.
6. Der reine HTTP-Empfang kann an dieser Stelle schon mal bestätigt werden, falls die offizielle Empfangsbestätigung erst später folgt.
7. Bob entschlüsselt die Übertragung mit seinem privaten Schlüssel. Welchen er nehmen muss, steht ja im HTTP-Header.
8. Bob bildet einen Hashwert über die entschlüsselten Daten, entschlüsselt Alices Hashwert mit ihrem öffentlichen Schlüssel und vergleicht die beiden.
9. Bob entscheidet, ob er Alice den Empfang positiv oder negativ bestätigen will (negativ z.B., wenn er Manipulation vermutet oder die ganze Entschlüsselung schief ging).
10. Die Empfangsbestätigung (Message Disposition Notification, MDN) kann mit Bobs privatem Schlüssel signiert werden.
11. Bob schickt die MDN an Alice, synchron (als Antwort auf Alices HTTP-Request) oder asynchron (in einer neu aufzubauenden HTTP-Verbindung, diesmal von Bob zu Alice).

Dieser Ablauf ist sehr schön schematisch in einem Bild des Wikipedia-Artikels zu AS2 dargestellt.
Übrigens: Wenn Sie sich fragen, wozu denn noch die HTTPS-Verschlüsselung gebraucht wird, wenn AS2 dies doch sowieso schon vornimmt: AS2 verschlüsselt die Daten, aber nicht die HTTP-Header. So kann noch jeder mitlesen, wer an wen mit welchen Zertifikaten Daten schickt (und noch ein paar andere Kleinigkeiten). HTTPS verschlüsselt auch noch diese Metadaten.
Davon abgesehen ist bei AS2 die Verwendung von Verschlüsselung und Signatur nicht zwingend vorgeschrieben. Man kann das auch weglassen. Wenn man dabei nicht wenigstens HTTPS verwendet, kann man seine Daten auch gleich in die Zeitung setzen…

Die MDN ist ein wichtiger Bestandteil von AS2 und muss deshalb näher erläutert werden.
In einer MDN steht die Nachrichten-ID der Datenübertragung drin, die bestätigt werden soll. Diese ID hat der Absender (bei uns Alice) in einem HTTP-Header mitgeliefert. Also heißt die MDN ganz einfach: Danke, ich habe Deine Nachricht Nr. xyz erhalten, konnte sie entschlüsseln und als (sehr wahrscheinlich) authentisch einstufen. Oder sie sagt, dass die Daten korrupt waren, ein benutztes Zertifikat unbekannt oder was auch immer. Bei einer negativen MDN spricht man verkürzt von einer NDN.
Diese Information ist für den Versender wichtig. Das ist wie mit einem Einschreiben mit Rückschein, an diesem Punkt geht die Verantwortung für die Daten auf den Empfänger über. Er bestätigt, sie sauber erhalten zu haben. Wenn danach etwas schief geht, ist der Absender aus dem Schneider.
Ob die MDN nun sofort als Antwort auf den HTTP-Request rausgeht, in dem die Daten reinkamen, oder erst ein paar Minuten oder gar Stunden später als eigenständige Übertragung, ist für diesen Zweck unerheblich. Manchmal wird auch die reine HTTP-Übertragung von einem System erledigt, das Entschlüsseln und der Signatur-Check aber erst später von einem anderen. Deshalb gibt es die Wahlmöglichkeit zwischen synchronen und asynchronen MDNs. Eine synchrone MDN geht direkt als HTTP Response auf den HTTP Request raus, mit dem die Daten geschickt wurden. Eine asynchrone MDN dagegen wird in einem eigenen HTTP Request an den Absender der Daten zurückgeschickt.
Allerdings kann der Empfänger nicht einfach so entscheiden, dass er seine MDN erst später schicken mag. Im Gegenteil, der Absender ist derjenige, der dem Empfänger vorschreibt, wie er seine MDN haben will. Und falls der Absender eine asynchrone MDN anfordert, dann gibt er dem Empfänger auch gleich die URL mit, an die diese MDN dann geschickt werden soll. Jede dem Standard genügende AS2-Software beherrscht beide Varianten.

Wenn Sie mit Ihren Partnern Daten via AS2 austauschen wollen, brauchen Sie (und Ihre Partner) zumindest folgendes:

• Eine AS2-Kennung pro Teilnehmer (die können Sie selbst festlegen, bzw. jeder Teilnehmer legt seine fest).
• Ein Zertifikat pro Teilnehmer (es können für Signatur und Verschlüsselung auch unterschiedliche verwendet werden, dann wären es zwei Zertifikate pro Teilnehmer). Es geht zwar auch ohne, das ist aber nicht der Sinn von AS2.
• Die öffentlichen Schlüssel aller Zertifikate, die ihre Partner verwenden.
• Und natürlich eine AS2-fähige Software.

Zertifikate generiert man selbst, es gibt diverse Software auf dem Markt, und eine gute AS2-Software kann das sicher auch. Allerdings kann es passieren, dass Ihre Partner eine Software einsetzen, die auf signierten (also von Verisign oder ähnlichen Stellen als glaubwürdig abgezeichneten) Zertifikaten besteht. Das Signieren kostet dann. Ausgetauscht werden die Zertifikate im Vorfeld. Da nur die Zertifikate mit dem öffentlichen Schlüssel ausgetauscht werden, kann man sie einfach per E-Mail verschicken.
Bei der Software sollten Sie auf eine sogenannte Drummond-Zertifizierung achten. Die Drummond Group definiert Testaufgaben (Testcases), die alle an einer Testrunde teilnehmenden AS2-Systeme miteinander meistern müssen. Nur, wer mit allen anderen Teilnehmern alle geforderten Aufgaben fehlerfrei durchspielen kann, bekommt das Gütesiegel der Drummond Group. Ein sehr aufwendiges (und kostspieliges) Verfahren. Dabei müssen sogar mehr Testkriterien erfüllt sein, als der RFC 4130 (in dem AS2 beschrieben ist) festlegt. Fragen Sie einfach beim Hersteller der Software an, ob er ein Drummond-Zertifikat vorweisen kann.

Wenn Sie mit Ihren Partnern Daten via AS2 austauschen wollen, brauchen Sie (und Ihre Partner) zumindest folgendes:

• Eine AS2-Kennung pro Teilnehmer (die können Sie selbst festlegen, bzw. jeder Teilnehmer legt seine fest).
• Ein Zertifikat pro Teilnehmer (es können für Signatur und Verschlüsselung auch unterschiedliche verwendet werden, dann wären es zwei Zertifikate pro Teilnehmer). Es geht zwar auch ohne, das ist aber nicht der Sinn von AS2.
• Die öffentlichen Schlüssel aller Zertifikate, die ihre Partner verwenden.
• Und natürlich eine AS2-fähige Software.

Zertifikate generiert man selbst, es gibt diverse Software auf dem Markt, und eine gute AS2-Software kann das sicher auch. Allerdings kann es passieren, dass Ihre Partner eine Software einsetzen, die auf signierten (also von Verisign oder ähnlichen Stellen als glaubwürdig abgezeichneten) Zertifikaten besteht. Das Signieren kostet dann. Ausgetauscht werden die Zertifikate im Vorfeld. Da nur die Zertifikate mit dem öffentlichen Schlüssel ausgetauscht werden, kann man sie einfach per E-Mail verschicken.
Bei der Software sollten Sie auf eine sogenannte Drummond-Zertifizierung achten. Die Drummond Group definiert Testaufgaben (Testcases), die alle an einer Testrunde teilnehmenden AS2-Systeme miteinander meistern müssen. Nur, wer mit allen anderen Teilnehmern alle geforderten Aufgaben fehlerfrei durchspielen kann, bekommt das Gütesiegel der Drummond Group. Ein sehr aufwendiges (und kostspieliges) Verfahren. Dabei müssen sogar mehr Testkriterien erfüllt sein, als der RFC 4130 (in dem AS2 beschrieben ist) festlegt. Fragen Sie einfach beim Hersteller der Software an, ob er ein Drummond-Zertifikat vorweisen kann.

Vorteile

• Durch HTTP haben Sie sofort eine Bestätigung, dass die Übertragung an sich funktioniert hat (zumindest den HTTP Response Code).
• Die MDN bestätigt darüber hinaus, dass die Daten sauber empfangen werden konnten und normalerweise auch, dass Entschlüsselung und Signaturcheck passten. Je nach Anforderung synchron oder asynchron.
• Die Daten werden verschlüsselt, was sicherstellt, dass nur der gewünschte Empfänger sie lesen kann.
• Die Signatur wiederum garantiert, dass weder Inhalt noch Absender manipuliert wurden.
• HTTPS setzt noch mal ein Stückchen mehr Sicherheit obendrauf.
• Durch alle vorgenannten Sicherheitsmechanismen kann die Übertragung kostengünstig über das freie Internet erfolgen, es ist weder ISDN noch ein VAN nötig.

Nachteile

• Eine gute (möglichst Drummond-zertifizierte) AS2-Software kostet Geld.
• Falls einer der Partner auf signierten Zertifikaten besteht, kosten diese ebenfalls etwas Geld.

Was die Kosten angeht, kann man sagen, dass ab einer nennenswerten Anzahl Übertragungen pro Monat das Geld für die Software (und evtl. die Zertifikate) schnell wieder hereinkommt. Bei ISDN-basierten Verfahren (wie OFTP) oder VANs (wie X.400) kostet jede Übertragung extra, während die AS2-Kommunikation über Ihre ganz normale Internet-Flatrate läuft. Wie hoch diese „nennenswerte Anzahl“ ist, können Sie selbst am besten abschätzen.
Da man sich über Jahre die laufenden Übertragungskosten sparen kann, gibt es aktuell eine starke Wanderung von X.400 zu AS2.

Im Vergleich zu normalem FTP bietet SFTP/SCP zwei Vorteile:

• Die gesamte Kommunikation ist verschlüsselt (was sich allerdings auch mit FTPS, also SSL-verschlüsseltem FTP erreichen lässt).
• Es muss nur ein einziger Port (üblicherweise Port 22) in der Firewall freigeschaltet werden.

Die Sache mit den Ports ist die:
Bei FTP wird für jede einzelne Datenübertragung (sei es eine Datei oder nur ein Verzeichnislisting) ein neuer Port ausgehandelt. Firewalls können bei unverschlüsseltem FTP die Aushandlung belauschen und den entsprechenden Port freigeben, bei FTPS nicht. Deshalb fängt dann der Spaß an, die Datenports auf einen gewissen Bereich (eine sog. Port Range) einzuschränken und diese Ports in der Firewall alle freizugeben. Wenn man die ganze Netzwerkerei an einen Dienstleister ausgelagert hat, macht das echt Laune. 😉
SFTP dagegen nimmt einfach Port 22 (oder auch einen anderen, wenn der SSH-Server anders konfiguriert ist). Darüber laufen Kommandos wie auch Datenübertragung. Diesen einen Port gibt man frei und gut.
Für SCP gilt derselbe Vorteil, es kann nur ein paar Sachen nicht, die SFTP kann. Aber wenn man die nicht braucht (oder anderen bewusst nur das reine Kopieren gestatten will), ist es eine feine Sache. Auf der anderen Seite kann jemand, der für ihn bestimmte Daten abgeholt hat, diese nicht einfach löschen. Dazu braucht er wieder die Befehle der Secure Shell (SSH) selbst. Und jemandem zu erlauben, auf dem eigenen Rechner SSH-Befehle abzusetzen, ist nicht Jedermanns Sache.

Womit wir auch schon beim Nachteil wären, zumindest für eine Seite der Kommunikation. Da ein SSH-Server für den Verbindungsaufbau und die Verschlüsselung genutzt wird, besteht je nach genutzter Software die Gefahr, dass der User, der eigentlich nur SCP oder SFTP machen dürfte, sich auch in eine Secure Shell einloggt, um auf dem Server irgendwelche anderen Sachen anzustellen. Zwar hat er sein eigenes Konto und begrenzte Rechte, aber den einen oder anderen Ausbruch gibt’s ja immer wieder. Das verursacht manchem Administrator doch gehöriges Bauchgrimmen.
Davon abgesehen gelten für SFTP und SCP natürlich die selben Vor- und Nachteile wie für normales FTP (soweit eben nicht schon als Unterschied angesprochen).
Abhilfe schafft in einigen Punkten wiederum ein System mit eigener Integration der Protokolle. Eine solche Software kann z.B. einen SFTP- und SCP-Server bereitstellen, der aber gerade nicht die Möglichkeiten einer Secure Shell bietet. Und es kann übertragene Daten sofort in die Verarbeitung nehmen, ohne Zwischenschritte, wie sie im FTP-Artikel beschrieben sind.

Wie gesagt, X.400 hat herzlich wenig mit der normalen Internet-E-Mail gemein. Aber: Es ist ein Mail-Protokoll. Man versendet also Mails, mit Absender, Empfänger, Text und evtl. Anhängen. Diese überträgt man an seinen Mail-Server, der leitet sie (unter Umständen) an andere Mail-Server weiter, bis sie schließlich im Postfach des Empfängers landen. Der holt sie von dort ab. Das war’s dann aber auch schon mit den Gemeinsamkeiten.
Womit wir bei den Unterschieden wären:

• Nicht jeder kann einfach so im Netz einen eigenen X.400-Server betreiben. Das bedeutet ein Stück Sicherheit, da die Mails nur über bekannte (und hoffentlich vertrauenswürdige) Stellen laufen.
• Die Einlieferung einer Mail im (eigenen) X.400-Server wird mit einem sogenannten Report bestätigt.
• Der Empfänger kann den Eingang einer Mail bei sich wiederum dem Absender bestätigen (das gab es bei den alten Internet-Mails auch mal. Bis die Spammer alles kaputt gemacht haben).
• Damit kann man das Netz aus X.400-Servern und -Clients als VAN bezeichnen, denn es bietet neben der reinen Übertragung auch noch die Sicherheit, dass nicht jeder mithören kann.
• Wie bei VANs üblich, kostet die Zusatzleistung etwas. Das Postfach sowieso, darüber hinaus kostet jede Verbindung, jede Nachricht extra. Auch die Empfangsbestätigung durch den Adressaten. Deshalb werden die so selten verschickt.
• X.400-Server wurden ursprünglich via ISDN angesprochen, es existiert aber schon seit einer ganzen Weile die Möglichkeit, sie über das Internet zu kontaktieren. Und das auch SSL-verschlüsselt. Die ISDN-Variante kostet durch die Verbindungsgebühren noch mal extra Geld.
• Als Mail-Client kann die von der Telekom verteilte Software Filework oder auch eine andere verwendet werden. EDI-Systeme sollten dieses Protokoll integriert haben, da X.400 gerade im EDI-Bereich sehr häufig anzutreffen ist.
• Es gibt auch ein Gateway zwischen X.400- und Internet-E-Mails. Dieses setzt die Nachrichten in beiden Richtungen um, sodass auch Nutzer normaler E-Mail mit X.400-Kunden kommunizieren können. Auch das kostet allerdings Geld.

X.400 oder AS2?

Ihnen ist sicher aufgefallen, wie oft in obigen Punkten die Aussage „Das kostet Geld.“ zu finden ist. Dies ist einer der größten Nachteile von X.400. Vorteil gegenüber anderen Übertragungsverfahren ist die relative Sicherheit der Übertragung (ISDN oder SSL-verschlüsselt, nur bekannte Server und Teilnehmer, …) und die Möglichkeit, Empfangsbestätigungen zu erhalten. Aber Sicherheit gibt es auch mit anderen Protokollen, und Empfangsbestätigungen werden (aufgrund der Kosten) längst nicht von jedem verschickt.
Wenn Sie den Artikel zu AS2 schon gelesen haben, sollten Sie gerade an die MDNs gedacht haben, die Empfangsbestätigungen von AS2. Die gehören dort zum Standard, ohne die geht es nicht. Noch dazu ist die eigentliche Datenübertragung bei AS2 kostenlos (Internet-Flatrate vorausgesetzt). Deshalb gibt es auch eine starke Wanderbewegung weg von X.400 und hin zu AS2.
Der Wikipedia-Artikel stellt diese beiden Protokolle einander gegenüber (Stand 09. Oktober 2013). Er nennt als Nachteile von AS2 den Aufwand der Zertifikatspflege und den Zwang, ein eigenes EDI-System verlässlich am Laufen zu halten. Nun ja, die Zertifikatspflege ist mit der richtigen Software nicht wirklich so aufwendig, und in Zeiten von Serverfarmen mit virtuellen Maschinen usw. kann man sein EDI-System doch relativ verlässlich anbieten. Auch die X.400-Server der Telekom sind des Öfteren „down“ oder durch extreme Häufung von Anfragen blockiert. Und wenn da was klemmt, kann man nicht mal schnell selbst reingreifen. Bei AS2 kann man dann den HTTP-Server des Gegenübers nicht erreichen und versucht es später noch mal, kein wirklicher Nachteil.
Und was die Sicherheit angeht: Wer sich darauf verlässt und seine Daten unverschlüsselt über das X.400-Netzwerk schickt, vertraut den Betreibern der Server evtl. mehr, als gut ist. Eine komplett verschlüsselte und signierte AS2-Nachricht über HTTPS verursacht zumindest einige Arbeit, wenn man sie knacken will. Manche „Dienste“ haben dagegen, wie inzwischen ja bekannt wurde, ihre Finger schon ziemlich tief in den Servern so mancher IT-Unternehmen.

Ob Sie X.400 oder AS2 einsetzen (oder auch etwas anderes), hängt natürlich von Ihrem Datenaufkommen ab, aber auch ganz einfach davon, was Ihre Kommunikationspartner denn überhaupt unterstützen. Wer mit X.400 gut bedient ist, wird sich womöglich weigern, auf AS2 umzusteigen, nur, weil er Ihnen damit Kosten sparen kann. Und umgekehrt. Am Ende brauchen Sie beides. Stellen Sie also sicher, dass eine EDI-Software auch beides (und noch möglichst viele weitere Protokolle) beherrscht, bevor Sie sie kaufen.

Das Grobe

OFTP stammt aus einer Zeit, als das Internet noch in den Kinderschuhen steckte. Damals war ISDN so ziemlich das Modernste, was allgemein zugänglich war. Dementsprechend wurde OFTP auch über ISDN-Leitungen betrieben und wird es heute noch großenteils. Wobei das Protokoll selbst eigentlich unabhängig von der reinen Transportschicht ist und auch das alte OFTP in Version 1 bereits via TCP/IP und somit via Internet genutzt werden kann. Üblich ist der Weg über ISDN, was sinnvoll ist, da sich eine direkte Verbindung schlechter abhören lässt als eine offene Internet-Übertragung. OFTP 1 hat noch keine eigenen Verschlüsselungsvorschriften. Da ist die vergleichsweise neue Version 2 schon weiter, denn hier gehört die Verwendung von TLS (bzw. SSL) zum Standard. Deshalb wird OFTP 2 auch über das Internet betrieben.

Wie schon erwähnt, kennt OFTP eine Empfangsbestätigung, die sogenannte End-to-end Response (kurz: EERP). Diese bestätigt dem Absender, dass die Datei tatsächlich beim Empfänger angekommen ist. Das ist also ähnlich wie bei AS2 oder X.400. Wie bei AS2 die MDN kann bei OFTP die EERP sofort in der laufenden Übertragung geliefert werden oder erst in einer späteren Verbindung. Anders als bei X.400 wird sie üblicherweise auch tatsächlich genutzt, da sie bei vernünftig aufgesetzter Kommunikation keine zusätzlichen Kosten verursacht.

Die Nutzung von direkten ISDN-Verbindungen zwischen den Gesprächspartnern bei OFTP 1 bzw. SSL-Verschlüsselung bei OFTP 2 bietet Sicherheit bei der Übertragung, die EERP darüber hinaus die Nachvollziehbarkeit, ob eine Datei tatsächlich ihren Empfänger erreicht hat.
Das große Manko von OFTP 1 ist, dass es beinahe ausschließlich via ISDN realisiert wird. Das bedeutet zum einen, dass jede Verbindung Geld kostet (und das können in manchen Unternehmen schnell viele tausend Euro pro Monat sein), zum anderen aber auch, dass man ausreichend freie ISDN-Kanäle braucht, um nicht andauernd ein „Besetztzeichen“ zu bekommen, wenn man Daten übertragen will. Dafür wiederum braucht es auch die entsprechende Hardware. Deshalb wird OFTP1 derzeit Schritt für Schritt abgewickelt. Gerade die großen Autobauer (OFTP stammt ja aus dem Automotive-Umfeld) lösen ihr altes, ISDN-basiertes OFTP 1 zur Zeit durch OFTP 2 ab. Im Prinzip könnten sie genau so gut gleich AS2 nehmen, das noch ein bisschen mehr Sicherheit bietet (siehe AS2-Artikel), aber man bleibt doch lieber bei dem, was man kennt. Außerdem muss dafür zwar evtl. eine neue Version der OFTP-Software (oder auch eine ganz neue Software) eingespielt werden, diese ist dann aber normalerweise immer noch für OFTP 1 nutzbar, da ja nicht alle Partner auch gleichzeitig auf OFTP 2 wechseln dürften. Nimmt man dagegen etwas ganz Neues für z.B. AS2, kann das womöglich kein OFTP mehr. Natürlich gibt es auch EDI-Systeme, die beides (und noch einiges mehr) beherrschen.
Wenn Sie also damit rechnen müssen, OFTP einzusetzen, achten Sie auf ein Produkt, das auf jeden Fall OFTP Version 1 und 2 beherrscht. Manche Hersteller verlangen dafür noch mal extra Geld, andere nicht.

Etwas feiner

Rein theoretisch ist OFTP ein reines Sende-Protokoll. Man öffnet eine Verbindung zum Partner, gibt sich mit Username – das ist in diesem Falle eine von ODETTE vergebene ODETTE-ID – und Passwort zu erkennen, prüft User und Passwort der Gegenseite und schickt Dateien zur anderen Seite. Dateien abrufen (wie bei einem FTP GET) kann man nicht. Was man aber sehr wohl kann, ist die Richtung des Datenaustausches zu wechseln. Man schickt, nachdem man seine Dateien abgesetzt hat, einfach das Kommando „Change Direction“, was in etwa die Botschaft übermittelt: „Ich bin fertig, wenn Du noch was für mich hast, her damit.“ Dieser Mechanismus erlaubt zum einen, die EERPs zu vorher übermittelten Dateien an deren Absender zu liefern, zum anderen aber auch eine Zwei-Wege-Kommunikation. Der Partner, der gerade noch Empfänger war, kann nun selbst Dateien senden. Dieser Seitenwechsel kann theoretisch beliebig oft wiederholt werden, bis eine Seite zwar das Senderecht erhält, aber einfach nichts mehr zum Senden hat. Dann macht diese Seite die Verbindung zu.
Im einleitenden Artikel zu den Kommunikationswegen wurde schon erwähnt, dass man per OFTP eigentlich nicht, wie bei FTP, Daten irgendwo abholen kann. Nun können Sie sich denken, wie man trotzdem eine solche Abfrage realisieren kann: Man baut die Verbindung auf und setzt einfach mal auf Verdacht ein „Change Direction“ ab. Hat der andere was zum Senden vorliegen, kann er es jetzt loswerden.

Interessant ist noch, dass an so einer Datenübertragung nicht nur zwei ODETTE-IDs beteiligt sein können, sondern auch mehr. Denn OFTP kennt nicht einfach nur Absender und Empfänger. OFTP unterscheidet vielmehr, wer gerade miteinander tatsächlich Daten austauscht (die Session IDs) und von wem die Daten an wen gehen sollen (die File IDs). Will heißen:
Teilnehmer ABC macht eine OFTP-Verbindung zu Teilnehmer XYZ auf. Die beiden tauschen ihre IDs und Passworte aus und wissen dann, wer hier mit wem redet. ABC sendet nun eine Datei, gibt aber an, dass er diese im Auftrag von DEF schickt, und zwar für den eigentlichen Adressaten UVW. Überträgt er dann die nächste Datei, geht die vielleicht von GHI an RST.
Verwirrend? Aber sinnvoll! Denn auf diese Weise können z.B. Konzernzentralen oder auch Dienstleister im Auftrag ihrer Standorte oder Kunden Daten via OFTP versenden, und jeder weiß, wer der eigentliche Absender bzw. Empfänger ist.

Ohne allzu tief auf die Protokollebene hinabzutauchen sollten wir noch über eine Besonderheit von OFTP sprechen:

Die virtuellen Dateien

Jede zu versendende Datei wird in eine sogenannte virtuelle Datei verpackt, die noch ein paar Zusatzinformationen beinhaltet. Deren Dateiname setzt sich zusammen aus:

• dem ursprünglichen Dateinamen
• dem Datum und Zeitpunkt (bis auf Sekunden-Ebene) der Übertragung
• einem Zähler zur feineren Auflösung

Eine wichtige Information über den Inhalt der (Daten-)Datei steckt auch noch in der virtuellen Datei. Nämlich die Angabe, ob es sich um einen der folgenden Strukturtypen handelt:

• F = Feste Länge: Jeder Datensatz hat eine exakt definierte, immer gleiche Länge (die ebenfalls angegeben wird). Das wäre reinstes Feste-Länge-Format wie in diesem Artikel beschrieben.
• V = Variable Länge: Datensätze innerhalb der Datei haben unterschiedliche Längen. Auch das ist im oben erwähnten Artikel nachzulesen.
• U = Unstrukturiert: Hier können beliebige Daten transportiert werden, also auch Binärdaten (wie bei ENGDAT).
• T = Text: Die Daten bestehen ausschließlich aus ASCII-Zeichen. Es gibt keinerlei Steuerzeichen außer dem Zeilenumbruch (CR-LF), und jede Zeile ist maximal 2048 Zeichen lang.

OFTP in der Praxis

Wie schon erwähnt ist OFTP im Automotive-Bereich besonders verbreitet, aber auch darüber hinaus wird dieses Protokoll eingesetzt. Wenn Sie mit Geschäftspartnern Daten austauschen, die auf OFTP bestehen, werden Sie nicht umhin kommen, es auch einzusetzen.
Kann statt des alten OFTP 1 via ISDN schon das neuere OFTP 2 genutzt werden, ist es nicht mit nennenswerten laufenden Kosten verbunden. Sie brauchen eine Software, die OFTP 2 beherrscht, einen Internet-Anschluss, eine ODETTE-ID und ein Zertifikat. Letzteres muss von ODETTE selbst ausgestellt oder von ODETTE oder einer diesem Institut genehmen Trust Center signiert sein. Diese vier Punkte kosten Geld, und die Verlängerung des Zertifikates kostet ab und zu noch mal ein wenig, aber verglichen mit den ISDN-Kosten der alten Methode ist das kaum der Rede wert. Zumindest, wenn Sie eine nennenswerte Zahl von Übertragungen vornehmen.
Müssen Sie sich noch mit dem alten OFTP 1 herumschlagen, dann benötigen Sie eine dafür geeignete ISDN-Hardware. Das kann je nach Einsatzgebiet eine ISDN-Karte im Rechner sein oder eine eigene Kiste, die per TCP/IP über das Netz angesprochen wird (aber eben mit der Außenwelt ISDN spricht). Bevor Sie irgend etwas kaufen, fragen Sie am besten beim Hersteller Ihrer favorisierten OFTP- bzw. EDI-Software nach, was er Ihnen empfiehlt. Nehmen Sie aber bitte keine Software, die nur OFTP 1 kann, weil diese evtl. billiger ist! Wie gesagt, OFTP 1 wird gerade abgewickelt; Sie kaufen mit Sicherheit ein Auslaufmodell und müssen nochmals Geld in die Hand nehmen, wenn Ihre Kommunikationspartner auf Version 2 schwenken.
Sollte das ENGDAT-Verfahren im Raum stehen, dürfen Sie übrigens gleich mit OFTP rechnen. Zwar hat niemand die beiden offiziell miteinander verheiratet, doch OFTP hat sich als das Protokoll zur Datenübertragung im ENGDAT-Prozess durchgesetzt. Die OFTP-Version ist allerdings noch offen, beide werden für ENGDAT eingesetzt.

WebDAV und EDI

Wenn wir uns im EDI-Umfeld bewegen, sind die ganzen, schönen Editier- und Versionierungsmöglichkeiten relativ uninteressant. Da müssen wir Daten in unser EDI-System hineinbekommen bzw. von diesem wieder hinausschicken. Es geht also letztlich nur um Datentransport. Schaut man sich unter diesem Aspekt die Methoden an, die WebDAV bietet (zusätzlich zu denen von HTTP), stellt man fest, dass diejenigen, die im EDI-Bereich interessant sind, eigentlich auch im FTP-Protokoll vorhanden sind. Und da gibt es sogar noch ein paar mehr Möglichkeiten. Wobei letztlich auch HTTP selbst mit GET und POST alles für diese Zwecke Nötige bereitstellt.
Wo ist jetzt der Vorteil von WebDAV? Nun ja, gegenüber FTP hat es den Vorteil, dass HTTP von praktisch jeder Firewall durchgelassen wird und man auch beim Einsatz von SSL-Verschlüsselung nicht auf die Probleme wie bei FTPS treffen wird (siehe FTP-Artikel). Gegenüber einfachem HTTP hat es den Vorteil, dass man mit einer Verzeichnisstruktur arbeiten (und sie auch modifizieren) kann, ähnlich wie bei FTP. Ob man nun einen WebDAV-Server an seinen HTTP-Server andockt (es gibt viele davon) oder ein simples CGI-Script, das Daten per Post entgegennimmt (Download per GET geht ja sowieso), dürfte ansonsten ziemlich egal sein. Ach ja, Benutzerrechte sind noch ein Pluspunkt, die hat aber wiederum FTP auch.

Letztlich dürfte der Einsatz von WebDAV in einem EDI-Szenario schlicht dann sinnvoll sein, wenn einer Ihrer Partner Ihnen auf diese Weise Daten zur Verfügung stellt. Für diesen Fall sollte eine EDI-Software deshalb auch das WebDAV-Protokoll beherrschen.