Transcription
Fachhochschule Wiesbaden - FB Design Informatik MedienFachhochschule Wiesbaden - FB Design Informatik Medien7437 - EDI undE-Business StandardsFile Transfer- und onischer Datenaustausch)28.05.2006File transfer - messaging - mailboxingAutomatisierungshürdenTopologien für den DatenaustauschH. Werntges, FB Design Informatik Medien, FH Wiesbaden128.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden2EinordnungEinordnungMessagingEDI Unternehmen X28.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden328.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden41
File transfer - messaging - mailboxingFile transfer - messaging - mailboxing File transfer Mailboxing– Nur Inhalt wird transferiert– Routing:Implizit, durch Verbindungsaufbau– Beispiele: OSI: IP: ODETTE:––––FTAMftp, httpOFTPNur Inhalt wird transferiertNur bestimmte standardisierte Inhalte zulässig!Typisch für VANS (Value Added Network Services)Routing: Implizit, durch Sender / Empfänger-Codes im Header des Inhalts Deshalb müssen die Inhalte auch standardisiert / abgestimmt sein!– Beispiele: Messaging VANS:EDI*ExpressTradanetDanNetEcodex Innerhalb X.400:Telebox-400Allegro– Separate Header-Information, Inhalt als Body/Attachment(s)– Routing:Per Adressierung (Sender, Empfänger)– Beispiele: OSI: IP: VANS:28.05.2006X.400SMTP; aktuell: JMSIBM-IEH. Werntges, FB Design Informatik Medien, FH Wiesbaden5Automatisierungshürden 28.05.2006(GXS, weltweit)(GXS, i.w. UK)(DanNet, Dänemark)(IBM-IE, Österreich)(Telekom, Deutschland)(Allegro, Frankreich bzw. Spanien)H. Werntges, FB Design Informatik Medien, FH Wiesbaden6Zusatzanforderungen Zugriffsberechtigungen (remote side) für ftp oder: Warum reichen (s)ftp oder http denn nicht?– bilateral abzustimmen und einzurichten– ftp und http sind konzeptionell C/S-Protokolle mit einemmanuell zu bedienenden “client” Konventionen für Datei- und Verzeichnisnamen– Absprachen notwendig Typ “Mensch-zu-Maschine” Berücksichtigung von cross-platform Aspekten– High-end EDI-Anforderungen lauten dagegen:– Bsp: Unix-to-VMS, Win2000-to-AS/400– Binär/ASCII, ASCII/EBCDIC, besondere Zeichensätze– Unterstützte ftp-Kommandos? vollautomatischer 7*24 Std.-Betrieb Typ “Maschine-zu-Maschine” Kapazität für tausende Dateien pro Tag oder gar Stunde Lokale Pufferung– Konsequenzen:– Übertragungsstörungen dürfen sendende Prozesse nicht blockieren Zahlreiche Zusatzanforderungen “um ftp/http herum” Organisation mehrerer Austauschkanäle28.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden728.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden82
ZusatzanforderungenZusatzanforderungen Serialisierung (FIFO) Störungs-Management– Empfangsreihenfolge Sendereihenfolge der Dateien!– Bsp.: Bestelländerung darf “ihre” Bestellung nicht überholen– Entfernung der “Reste” nach Verbindungsabbruch? Wahrung der Eindeutigkeit– Wiederholung der gesamten Übertragung notwendig, oderWiederaufsetzen am Punkt des Abbruchs möglich?– keine Datei doppelt senden– keine auslassen– kein Überschreiben durch andere Datei gleichen Namens– Überwachung blockierender Serverprozesse (z.B. ftpd)– Automatischer Wiederanlauf nach temporären Störungen wieNetzwerkausfall Koordination mehrerer Quellen pro Kanal– Locking, gemeinsamer Server für Seriennr./ Dateinamen?– Warnung/Alarmierung bei persistenten Problemen Synchronisierung von Sender und Empfänger incl. Definition eines Schwellenwerts, evtl. pro Kanal– “Atomare” Übergaberegel verhindert Annahme von Fragmenten28.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden928.05.2006ZusatzanforderungenH. Werntges, FB Design Informatik Medien, FH Wiesbaden10Fachhochschule Wiesbaden - FB Design Informatik Medien Ablaufsteuerung– Batch: Übertragung nur zu bestimmten Zeiten z.B. zur Bündelung, Last- und KostenoptimierungTopologien für denDatenaustausch– Event: Ereignisgesteuertes Auslösen von Aktionsketten Protokollierung– Insb. lückenloser Nachweis der erfolgten Zustellungen– Schnelle Anzeige der noch offenen VorgängePoint-to-point (P2P)P2P-NetzwerkHub-and-spokeHub-and-spoke plus GatewaysVernetzte C/S-Modelle Fazit– ftp, http u.a. Transportprotokolle bilden bestenfalls eine technischeBasis für die Implementierung von für EDI-Anforderungen geeignetenÜbertragungsverfahren.28.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden1128.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden123
Point-to-point ModellP2P-Netzwerke Typisch für Initialphase Skalierungsproblem! Lösungsansatz:– Erste Schritte einfach– Bilaterale Abstimmungohnehin noch die Regel– Verbindungen “ausdünnen”– Neu: Vermittelnde Knoten (Routing) Ideal für File transfer– Kein Routing notwendig Potentielle Probleme:– Verfügbarkeit derPartnersysteme– Standardisierung– Routing– Skalierung28.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden13Point-to-point Netzwerke28.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden14Hub-and-spoke Modell Skalierungsproblem reduzierbardurch Spezialisierung– Randknoten, clients– Hauptknoten, server– Neue Aufgabe: Routing it?Standardisierung?Skalierung (große Systeme)? Fazit:– Die meisten P2P-Probleme bleiben bestehen!28.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden1528.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden164
Hub-and-spoke ModellHub-and-spoke Modell Extremfall eines P2P-Netzwerks: Zusatzleistungen einiger VANS– 1 Server (“Hub”)– viele Clients (“Spokes”) – Zustellungsnachweis– Berichte Datenmengen Einzelnachweise mit ZeitenDie Grundidee der Value Added Network Services (VANS)Ideal für MailboxingLöst das Routing-, Skalierungs- und VerfügbarkeitsproblemStandardisierung?– Andere Leistungen – Nur per Industriestandard und/oder Marktbeherrschung– Proprietäre Zugriffstechniken, nicht für alle Plattformen verfügbar Kostenmodelle– Einmalige Einrichtungskosten– Monatliche Fixkosten, z.B. pro Mailbox, Freivolumen– Variable Kosten, z.B. pro kB, “Sender zahlt”, S/E 1:1, pro Zugriff, .28.05.2006H. Werntges, FB Design Informatik Medien, FH WiesbadenSyntax-CheckTeils Konvertierung (Inter-Standard, Inter-Subset)Überwachung von “closed user groups” (Bsp: Phönix)Ablehnung von “Doppelten”Zwischenspeicherung, ArchivierungRegistrierung / Überwachung zugelassener Partnerkennungen Probleme:– Vernetzung verschiedener proprietärer “Inseln”?– Kosten, insb. bei erzwungener Mehrfach-Mitgliedschaft17Hub-and-spoke Gateways28.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden18Hub-and-spoke Gateways Vernetzung mehrere Hub-and-spoke-Inseln (z.B. VANS)über Gateways– Theoretisch von Vorteil: Nur einmal Mitgliedschaft nötigGateway– Praxis: “Coopetition”-Situation ungünstigGateway Gateways zwischen Wettbewerbern entstanden durch KundendruckSie laufen den Interessen der Betreiber meist zuwiderDaher schlechter unterstützt als der Normalbetrieb im eigenen VANSAber: Meist problemlos möglich zwischen VANS desselben Betreibers– Größte Nachteile: Informationsverlust an den Gateways, z.B. Zustellungsnachweis nur bisGateway - wertlos! Keine klare Verantwortlichkeitsregelung mehr In der Praxis doch Rücksichtnahme auf / Kenntnis von Regeln andererVANS notwendig Teuer im Betrieb aufgrund abschreckender TarifstrukturGateway28.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden1928.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden205
Vernetzte C/S-ModelleVernetzte C/S-Modelle Strenge Spezialisierung:– Entweder C(lient) oder S(erver) Konsequente Anforderungen an Server– Verfügbarkeit, Belastbarkeit, VernetzbarkeitVielleicht doch? Lösung des Skalierungsproblems durch ProtokollStandardisierung– zwischen Clients und Server– zwischen verschiedenen Servern Lösung des Routing-Problems durch neue Ebene:– Pflege einer separaten Adressierungsebene seitens derApplikationen erforderlich Resultierendes Konzept:– Messaging– Store-and-forward PrinzipWenn ja, was bringtden Erfolg?28.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden21Beispiel: SMTP / Internet Mail28.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden22Begriffsbildung zu Messaging MTA - Message Transfer AgentServer-Domäne(als ständig verfügbar Pserver– hier: Der SMTP Server– Beispiel: sendmailPOPserverPOP3MailPrgm. MS - Message Store– hier: Das Dateisystem– Allgemein: Ein Subsystem für “Langzeit”-SpeicherungClientBereichDateisystem UA - User agent– hier: Das Mail-Programm– Beispiele:SMTPüber InternetDateisystemIMAPserverIMAP4MailPrgm. Outlook Express, Netscape Messager, elm, mail, Eudora, – Varianten: RUA - Remote User Agent (heute der Normalfall) AU - Access Unit, z.B. ein automatisches Mail-Gateway28.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden2328.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden246
Fachhochschule Wiesbaden - FB Design Informatik MedienFachhochschule Wiesbaden - FB Design Informatik MedienEinführung in X.400X.400: leich X.400 - Internet Mail28.05.2006H. Werntges, FB Design Informatik Medien, FH WiesbadenHistorische EntwicklungX.400 im OSI-ReferenzmodellGrundlage: U-T)– B. Plattner, C. Lanz, H. Lubich, M. Müller and T. Walter,Elektronische Post und Datenkommunikation.X.400: Die Normen und ihre Anwendung.Bonn: Addison-Wesley, 1989– Th. Schmoll, Handelsverkehr, elektronisch, weltweit:Nachrichtenaustausch mit EDI/EDIFACT, Markt &Technik, München 19941979198019841988ISO WWW:– http://www.alvestrand.no/x400/– http://www.oppenheimer-software.com/x400.html– http://www.dfn.de/service/x400/H. Werntges, FB Design Informatik Medien, FH Wiesbaden26Meilensteine in der Entwicklung von X.400 Literatur:28.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden2728.05.20061992198019861988TC6 WG6.5 MHS (Forschung)Beginn der MHS-Arbeitenerste Empfehlung X.400-Serie MHS(sog. Rotbuch)stark überarbeitete Version X.400Serie MHS (sog. Blaubuch)ergänzte VersionBeginn der MOTIS-ArbeitenAbstimmung zu MHSIS 10021 MOTISH. Werntges, FB Design Informatik Medien, FH Wiesbaden287
X.400: Historische EntwicklungX.400 im OSI-Referenzmodell Vorgeschichte Organisatorisches Vorbild: “Gelbe Post” 1984 7: Anwendungsschicht 6: Darstellungsschicht 5: Kommunikationssteuerungsschicht 4: Transportschicht 3: Vermittlungsschicht 2: Sicherungsschicht 1: Bitübertragungsschicht 1-4: Transportdienste 5-7: Anwendungs-D.– Für IPM ausgelegt: P2 1988– EDI-Besonderheiten standardisiert: P-EDI– IPM-Verbesserungen: P22 1992– Sicherheitsanforderungen ergänzt, z.B. X.50928.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden29Anmerkungen28.05.2006 7: Application layer 6: Presentation layer 5: Session layer 4: Transport layer3: Network layer2: Data link layer1: Physical layerH. Werntges, FB Design Informatik Medien, FH Wiesbaden30OSI-Schicht 7 im Detail Das OSI-Referenzmodell erschien 1984.AnwendungsdiensteDatenaustauschformateEDIFACT ODA Es hatte große ordnende Wirkung auf die weitereEntwicklung der Datenkommunikation.7.2 OSI-Protokolle und -Normen sind heute praktisch ohneBedeutung, aber das OSI-Referenzmodell wird auch heutenoch vielfältig zitiert.7.1Quelle: Stöttinger, K.-H., Das OSI-Referenzmodell, Bergheim 198928.05.2006H. Werntges, FB Design Informatik Medien, FH WiesbadenFTAMACSEVTPRTSETPX.500ROSEODIFCCRSchicht 7.2: Application Service ElementsSchicht 7.1: Service Elements–X.400 Electronic mail–ACSE: Association Control SE–FTAM File Transfer, Access,–ROSE: Remote Operations SEManagement–RTSE: Reliable Transfer SE–VTP Virtual Terminal–CCR: Commitment, Concurrency,–TP Transaction ProcessingRecovery–X.500 Directory System X.400: Eine “echte” Schicht-7 OSI-Protokollfamilie, einer derwenigen noch nicht von der “IP-Welt” verdrängten OSIStandards. X.4003128.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden328
Bemerkungen zu ODA und EDIFACTX.400-Grundlage: ASN.1 ODA - Office Document Architecture–––– ASN.1 - eine formale Beschreibung von Daten fürTelekommunikations-Protokolle, unabhängig vonISO 8613, für Briefe, Memos, Berichte, .Logische StrukturLayoutstrukturInhalt–––– ODIF - O.D. Interchange FormatImplementierungssprachenPlattformen, ApplikationenDetails des physischen DatenaustauschsKonzeptionelle Parallelen zu XML Schema, SOAP; (MIME) Standardisiert & bewährt seit 1984, aktuelles Release: 1997 Typisierung:– Für elektronischen Austausch von ODA-Dokumenten– Begrifflich schwer von EDI(FACT) zu trennen– Basistypen wie int, boolean, char strings, bit strings, – Konstrukte: structure, list, choice, ODA und ODIF sind heute ohne große Bedeutung für EDI,besitzen aber gemeinsame Ursprünge Kombinierbar mit verschiedenen “encoding rules” wie z.B.PER (Packet encoding rules) - “Kompressionsstandard” (!) X.400-Protokolle basieren auf ASN.1 (!)Quellen: http://www.asn1.org28.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden33Fachhochschule Wiesbaden - FB Design Informatik Medien28.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden34Aufbau einer X.400 Mail Generelle Struktur:– Umschlag– Inhalt Kopf RumpfX.400: Analyse Umschlag (envelope)––––Absenderadresse (Originator)Empfängeradressen (Recipients)Dringlichkeit (Priority)Poststempel der MTA's auf dem Übertragungsweg(Trace information)– Netzweit eindeutige Kennzeichnung (MPDU-ID)– Angaben zur Art des Inhaltes(Content type und EIT (Encoded Information Types))Aufbau einer X.400 MailKomponenten eines MHSDie Protokolle28.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden3528.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden369
Aufbau einer X.400 MailAufbau einer X.400 Mail Inhalt (Content) [Forts.] Inhalt (Content)– Rumpf (Body)– Kopf (Header) Body part 1 (type t[1]), , body part n, type t[n]Absenderadresse (Originator)Adressen der Bevollmächtigenden (AuthorizingUsers)Hauptempfängeradressen (PrimaryRecipients)Empfängeradressen für Kopien (CopyRecipients)Betreff (Subject)Wichtigkeit (Importance)Vertraulichkeit (Sensitivity)Antwort an (ReplyToUsers)Antwort erwartet bis (ReplyBy)in Bezug auf (CrossReferences)Verfallsdatum (ExpiryDate)eindeutige Kennzeichnung (IPM-ID) Body part types (Auswahl):– a5text (BP 0) nur US-ASCII-Zeichen– forwarded oder message (BP 7) der Inhalt einer anderen Mail mit Header und Body– undefined (auch binär, bilaterally defined) (BP 14) im X.400(84) noch nicht erwähnt, aber in jeder Software nach X.400(84)möglich, d.h. sog. X.400(86)-Software ist X.400(84) mitErgänzungen von 1986– extended (auch externally defined) (BP 15) nur in Software ab X.400(88), sehr viele Untertypen; hauptsächlich mitUntertyp Generaltext benutzt (Text mit deutschen Umlauten) [Forts.]28.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden37Fachhochschule Wiesbaden - FB Design Informatik Medien28.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden38X.400-Begriffsbildung, -strukturierung Anwender bzw. Anwendung, nutzen: MHS - Message Handling System, bestehend aus:– MTS - Message Transfer System, ein Graph bestehend aus: MTA - Message Transfer Agents als “Knoten” Direkte Verbindungen zwischen einigen MTAs (“Kanten”)Komponenten eines MHS– MS - Message Stores, für geordnete Persistenzsicherung im Zusammenspiel mit RUAs langfristige Aufbewahrung von Nachrichten persönliche Mailboxen– UA - User Agents, die Clients / User interfaces Variante: RUA - Remote UA (nicht immer online, heute üblich)– AU - Access Units, Program interfaces bzw. Dienstübergänge Beispiele: Anbindung eines EDI-Konverters oder FAX-Servers Variante: PDAU - Physical Delivery AU (Druck & Postzustellung)28.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden3928.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden4010
Fachhochschule Wiesbaden - FB Design Informatik MedienKomponenten eines X.400 MHSX.400 MHSX.400 MTSRUAMTAMSX.400: Die ServerH. Werntges, FB Design Informatik Medien, FH Wiesbaden4128.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden42KommunikationsprotokolleX.400 MHS: Die Protokolle P1– beschreibt den Aufbau der Informationsobjekte, diezwischen zwei MTA's ausgetauscht werdenX.400 MHSX.400 MTSRUAMTAMSP7P3P1P3UA28.05.2006– beschreibt die Funktionen beim Informationsaustauschzwischen UA bzw. MS und MTSMTA P5MTAP5Anwendung P3MTAAUH. Werntges, FB Design Informatik Medien, FH WiesbadenMTA– beschreibt die Funktionen zwischen AU und MTS, z.B.Übergang zu TelexP5 P7AUFaxServer– das Zugriffprotokoll eines UA auf den MS4328.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden4411
Weitere BeschreibungenFachhochschule Wiesbaden - FB Design Informatik Medien P2– beschreibt den Aufbau der Informationsobjekte, die zwischen zweiUA's für Personen ausgetauscht werden, gemäß X.400(84) P22X.400: Organisatorische Aspekte– wie P2, aber mit Ergänzungen aus X.400(88)– erweitert um Multimedia-Unterstützung (“MIME”-artig) P35, P-EDI, PediADMDs, PRMDsRegelung der Verantwortlichkeiten, Tracking,(N)DNsO/R-Adressen: Aufbau, ParameterMTA-Routing, FallbacksGebühren (Beispiel)– beschreibt den Aufbau der Informationsobjekte, die zwischen zweiAU's für Anwendungen ausgetauscht werden, gemäß X.400(88), mitErgänzungen von 1992– explizite EDI-Ergänzung, parallel zu IPM– Wertet envelope-Informationen aus EDI-Standards aus (z.B. UNB)– Verbessert die Statusrückmeldungen über Gateways28.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden45ADMDs und PRMDs28.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden46ADMDs und PRMDs ADMDs bilden das Rückgrat des X.400 MHSAccessUnitX.400MTAMessageStore– Ein MTA oder ein MTA-Netz können als administrative domain(ADMD) zertifiziert und zugelassen werden, wenn sie bestimmteQualitätsmerkmale erfüllen.– ADMD-Dienstleistungen:Routing, Mailbox-Betrieb, Tracing, Gateway-Dienste– ADMDs sind untereinander direkt oder indirekt zu einem globalenMHS MD28.05.2006X.400MTA.X.400MTAX.400MTAADMDADMDH. Werntges, FB Design Informatik Medien, FH Wiesbaden Kommerzielle AspekteAnwendung– ADMDs sind die “VANS” eines einzigen globalen X.400 MHS– Wegen der Standardisierung von X.400 herrscht Wettbewerb, analogz.B. zu privaten Paketdiensten– ADMD-Gebührenprinzip analog Porto: Sender zahlt alles– Schutzfunktion der Kosten: Spamming / Missbrauch werden für denVerursacher teuer!.4728.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden4812
ADMDs und PRMDsVerantwortlichkeiten, Tracking, DN PRMDs: Jede X.400-Nachricht trägt eine weltweit eindeutigeKennung auf envelope-Ebene, die MPDU-ID– Private Organisationen können MTAs in eigener Regie betreiben undbilden dann PRMDs (private management domains)– Inseln: Es steht Anwendern frei, PRMD-Inseln ohne Verbindung zumglobalen MHS zu bilden, z.B. als reine “Hauspost”– Eine PRMD darf nur an höchstens eine ADMD angebunden sein– Analogie zur NVE– Tracking: ADMDs sind verpflichtet, MPDU-IDs verfolgen zu könnenund dies auf Kundenwunsch auch zu tun– MTA-Zwischenstationen fügen ihre Signaturen hinzu zwecksRückverfolgbarkeit des Weges einer Nachricht Direktverbindungen zwischen PRMDs Eine Anwendung / ein Anwender kann den Nachrichtenkopfeindeutig kennzeichnen: IPM-ID– Direktverbindungen zwischen PRMDs (auch solcher, die anverschiedene ADMDs angebunden sind) sind zulässig– Vorteile– Grundlage für Nachweis der (Nicht-)Zustellung gegenüber demAnwender / der Anwendung:(non-) delivery notification, (N)DN– Grundlage für Empfangsbestätigungen (receipts) Schnellstmögliche Zustellung, ohne Umwege Direkte Kontrolle über Erfolg Nur Leitungskosten, keine ADMD-Gebühren– Nachteile Das MHS sendet (N)DNs als spezielle Nachrichtentypenautomatisch bzw. auf Anforderung in standardisierter Form Einrichtung und Prüfung der Direktverbindungen Ständige Verfügbarkeit der direkt angeschlossenen Partnersysteme28.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden49AnwendungFunctional ackn.“CONTRL”, ung rnehmenBestätigung verterH. Werntges, FB Design Informatik Medien, FH WiesbadenX.400-ZustellbestätigungEbenen der ZustellbestätigungSendendes , X.400 DN/NDNX.400MTADN:delivery t28.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden5128.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden5213
X.400-ZustellbestätigungX.400 O/R Adressen X.400 O/R Adressen kennzeichnen i.w. eine –––O/R Originator / RecipientHierarchisches NamensschemaParametervererbung“Top-level domains”? - Länder, dann ADMDs !Vorlage “Gelbe Post”: Aufbau an Eigennamen orientiert Beispiele– Gillette's ADMD: C DE / A LION– Gillette's PRMD: C DE / A LION / P GILLETTE– EDI Testadresse des Metro-Vertriebskanals“real,-”:NDNC DE / A VIAT / P MGI / O EDI / OU REAL / S TESTAccessUnit28.05.2006X.400MTANDN:non-delivery notificationH. Werntges, FB Design Informatik Medien, FH Wiesbaden53X.400 O/R Adressen Übliche Parameter––––––––––C (country)A (ADMD)P (PRMD)O (organization)OU (bis zu 4-mal)(org. unit 1 4)S (surname)G (given name)I (middle initial)CN (common name) (generational qualifier),etc. 28.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden54MTA-Routing Besondere Parameter Routing– DDAN, DDAV (domain defined attrib.) - z.B.zur Abbildung der Parametervon VANS hinter Gateways,etwa von IBM-IE– X.121– Grundlage: Die O/R-Namen– Nur zwischen “benachbarten” MTAs im Gegensatz etwa zu SMTP! Nachbarbeziehungen erfordern i.d.R. Verträge und Einmalaufwände Analogie: IP-Router im LAN, explizite Regeln notwendig für Übergänge– Store-and-forward Prinzip Für die Angabe vonFaxnummern und KlartextEmpfängernamen Normalerweise baut der sendende MTA die Verbindung auf– Üblich: Default-Route anlegen, bei PRMDs meist die zur ADMD– (viele weitere, selten benötigt) Robustheit:– Regelungen für mehrfache Versuche eines Verbindungsaufbaus(“wann gibt der MTA auf?”)– “next hop list”: Wenn die Hauptstrecke streikt, aktiviere die Backup-Strecke Wenn die Direktverbindung streikt, route an den Default (z.B. die ADMD)28.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden5528.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden5614
MTA-RoutingMTA-Stacks Ablehnung bei endgültiger Unzustellbarkeit über NDN Traditionell– kein “stilles” Verwerfen– geordnetes Zeitverhalten– standardisierte NDN, detaillierte Standardcodes fürAblehnungsgrund, z.B. ––––Route unbekanntEmpfängeradresse existiert nichtEmpfängeradresse nicht erreichbarÜberschreitung der max. erlaubten Zustellzeit Per RFC 1006, inzwischen sehr verbreitet– IP-Stack: TP0– Für X.400 reservierter Port: 102– Kopplung flexibel realisierbar, z.B.– Kein unnötiges Rücksenden des Inhalts - nur NDN Zustellprioritäten– niedrig– normal– dringend28.05.2006X.25-Stack: TP2, native X.25-KopplungEinfach zu konfigurierenSicher, da virtuelle P2P-VerbindungLeider teuer IP über Dial-up ISDN IP über VPN IP direkt über Internet (ggf. via Firewall)H. Werntges, FB Design Informatik Medien, FH Wiesbaden5728.05.2006Gebührenbeispiele (Stand: 2002)H. Werntges, FB Design Informatik Medien, FH Wiesbaden58Fachhochschule Wiesbaden - FB Design Informatik Medien X.400 (class 4 - reicht für EU)– 0,125 / kb (erstes kB)– 0,075 / kb (ab 2. kB)X.400 vs. Internet Mail VANS am Beispiel. Phönix / GE-GXS– 40000 Belege à 2 kB 13000 0,165 / kB– Abrechnung 100-Byte-weise– separat: Gebühr pro Anwahl der MailboxVergleich X.400 - Internet MailDie Antwort der IETF: EDI-INT In beiden Fällen zusätzlich:– Monatliche Grundgebühren– Leitungskosten, z.B. X.25, ISDN28.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden5928.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden6015
Vergleich X.400 - Internet Mail Secure Not Secure– Documents managed bysecure systems Traceable Known path– can not be trusted withconfidentialinformation– Only handled byresponsible commerciale-mail firms Not Traceable– Misrouted mail can betracked down Receipts readily available– no more "I never got it” Sender Certified byoriginating e-mail carrier28.05.2006Vergleich X.400 - Internet Mail Fast– lost messages arepermanently lost– X.400 standards require95% of mail deliveredwithin 45 minutes.With the Internetbecoming increasinglybogged down, X.400stimely delivery becomesincreasingly important. Not Receiptable– You'll never know if the mailarrived Sender Spoofable– You're never sure who reallysent the messageH. Werntges, FB Design Informatik Medien, FH Wiesbaden61Fachhochschule Wiesbaden - FB Design Informatik Medien28.05.2006 Unknown path andhandling May be fast or veryslow– mail may take days to bedeliveredH. Werntges, FB Design Informatik Medien, FH WiesbadenX.400: Das Bindeglied aller VANSX.400: Das BindegliedAllegro MTAGE-GXS-ALTAllegro user group,FranceFuture Gateway toGE/GXS?CarrefourCarrefour, FrancePostDKFuture link toDanish Post DK?Other X.400ADMDs / EURGateway toDANNET / DKAdjacent MTAsvia IP stack(VPN)TandemMain ADMD linkGateway toBT EDInet / UKADMD link, backupAbschließende Betrachtung zumMessaging anhand einesUnternehmensbeispielsH. Werntges, FB Design Informatik Medien, FH WiesbadenMetro-X25Metro AG / DEGateway toECODEX / ATGateway toIBM-IE / EURTandem-X2528.05.200662Adjacent MTAsvia X.25 stackISOPLEXX.400 MTAC DE/A LION/P GILLETTEAdjacent MTAsvia IP stack(Dial-up ISDN)PostDK-X25Danish Post / DK63GE-GXS-DEGateway toTradanet / UKGateway MTA toGE/GXS servicesGateway toEDI*Express / CE28.05.2006Unternehmensbeispiel Braun / GilletteH. Werntges, FB Design Informatik Medien, FH Wiesbaden6416
Fachhochschule Wiesbaden - FB Design Informatik MedienEDI-INT AS1, AS2 (EDI over INTERNET) AS1: Standard der IETF (Internet Engineering Task Force) Übertragung von EDI-Nachrichten (EDIFACT, ANSI X.12) über Internet Transportprotokoll– E-Mail (EDI-INT AS1) oder– http, https (EDI-INT AS2)– ftp (EDI-INT AS3)Internet Messaging Nachrichten-Routing– durch Auswertung der EDI Service Segmente (UNB,.)EDI-INTTrends Verschlüsselung und Absenderauthentifizierung Sicherung der Übermittlung– S/MIME, RSA, X.509 Zertifikate für Public Key Management– durch „Message Disposition Notification“(MDN) standardisierte, verschlüsselt übertragene Zustellberichte AS2: Technisch bereits veraltet, aber „voll im Trend“– Verbreitet bereits in USA; Europa: Roll-out bei Metro AG; Carrefour u.a. !– Alternative: Web Services, insb. eb-MS der ebXML-Initiative28.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden6528.05.2006RFCs mit Relevanz für EDI-INT AS1 28.05.2006B) HTTP Transport for Secure Peer-to-Peer Business DataInterchange Using HTTP– 20. Entwurf, Dez 2004, läuft ab im Mai 2005– Nur Entwurf (draft-ietf-ediint-as2-20.txt), erhältlich unterhttp://www.ietf.org/ietf/1id-abstracts.txt !RFC seit Sept. 2002, früher: EDI-INT AS1RFC 821: SMTPRFC 822: Text Message FormatsRFC 1767: EDI Content TypeRFC 1847: Security Multiparts for MIMERFC 1892: Multipart/ReportRFC 2015, 3156, 2440: MIME/PGPRFC 2045 to 2049: MIME RFCsRFC 2298: Message Disposition NotificationRFC 2630, 2633: S/MIME v3 SpecificationH. Werntges, FB Design Informatik Medien, FH Wiesbaden66RFCs mit Relevanz für EDI-INT AS2A) RFC 3335: MIME-based Secure EDI“MIME-based Secure Peer-to-Peer Business DataInterchange over the Internet” H. Werntges, FB Design Informatik Medien, FH Wiesbaden 67RFC 2616: HTTP v1.1RFC 1767: EDI ContentRFC 1847: MIME Security MultipartsRFC 1892: Multipart/reportRFC 2045, 2046, 2049: MIMERFC 2298: Message Disposition NotificationRFC 2633, 2630: S/MIME v3 Msg. SpecificationsRFC 2376: XML Media Types28.05.2006H. Werntges, FB Design Informatik Medien, FH Wiesbaden6817
Die IETF-Antwort: EDI-INTMDN: Synchron vs. AsynchronSynchronClient(connect)(send)ServerHTTP responseincl. AS2-MDN(receive)EDI INT MessageSenderReceiverMDNClientAsynchron an encrypted EDI(FACT) message an encrypted symmetric key fordecoding the message a digital ect*)(send)H. Werntges, FB Design Informatik Medien, FH Wiesbaden69*) auchServerSMTP möglichHTTP requestincl. AS2-MDNHTTP responseH. Werntges, FB Design Informatik Medien, FH Wiesbaden70EDI-INT Lifecycle12 zulässige MDN-SzenarienSent dataReceipt requestedReceipt dunsignedunsignedsignedsignedsignedencrypted, signednone-encrypted, signedunsignedunsignedencrypted, signedsignedsigned28.05.200628.05.2006HTTP requestincl. AS2 msg.HTTP response(receive)28.05.2006HTTP requestincl. AS2 msg.H. Werntges, FB Design Informatik Medien, FH WiesbadenThe conversion and transmission of data to an EDI-INTcompliant message type is comprised of the following steps:1. Deliver data to NetIXServer2. Convert XML, EDI-X12, EDIFACT, binary, or other types ofdata to standard S/MIME format3. Encrypt, sign and route data4. Transport data over a network5. Receive data at NetIXServer6. Perform verification checks7. Re-convert data from standard S/MIME to XML, EDI-X12,EDIFACT, binary, or other
7437 - EDI und E-Business Standards Electronic Data Interchange (Elektronischer Datenaustausch) 28.05.2006 H. Werntges, FB Design Informatik Medien, FH Wiesbaden 2 Fachhochschule Wiesbaden - FB Design Informatik Medien File Transfer-und Messaging-Standards File transfer - messaging - mailboxing Automatisierungshürden Topologien für den .
