Transcription
Fachhochschule Wiesbaden - Fachbereich her Datenaustausch)28.05.2003H. Werntges, FB Informatik, FH Wiesbaden1Fachhochschule Wiesbaden - Fachbereich InformatikKlassisches EDI - der KernEinleitung - die KernkomponentenFile Transfer- und Messaging-StandardsUN/EDIFACT und EANCOM im DetailApplikationsschnittstellenKonverter- und Mappingtechniken28.05.2003H. Werntges, FB Informatik, FH Wiesbaden21
Die Kernkomponenten mateMappingRoutingMessaging / File rmierungTracking & Tracing28.05.2003H. Werntges, FB Informatik, FH Wiesbaden3Von der Applikationsergänzung .Front-End Konzept aceUnternehmen XBnFormatkonverter 28.05.2003AnwendungUnternehmen YViele KommunikationsverbindungenViele EDI-PartnerH. Werntges, FB Informatik, FH Wiesbaden42
zum EDI ClearingcenterDer EDI-Server - Eine zentrale IT-RessourceEDI Clearing ServerAnwendungAnwendungenABDatennCVANSBrAun GmbH / Gillette 28.05.2003Viele KommunikationsverbindungenViele EDI-PartnerVerschiedene AnwendungenVerschiedene GeschäftseinheitenH. Werntges, FB Informatik, FH Wiesbaden5Fachhochschule Wiesbaden - Fachbereich InformatikFile Transfer- und MessagingStandardsFile transfer - messaging - mailboxingAutomatisierungshürdenTopologien für den Datenaustausch28.05.2003H. Werntges, FB Informatik, FH Wiesbaden63
File transfer - messaging - mailboxing File transfer– Nur Inhalt wird transferiert– Routing: Implizit, durch Verbindungsaufbau– Beispiele: OSI: IP: ODETTE:FTAMftp, httpOFTP Messaging– Separate Header-Information, Inhalt als Body/Attachment(s)– Routing: Per Adressierung (Sender, Empfänger)– Beispiele: OSI: IP: VANS:28.05.2003X.400SMTP; aktuell: JMSIBM-IEH. Werntges, FB Informatik, FH Wiesbaden7File transfer - messaging - mailboxing Mailboxing––––Nur Inhalt wird transferiertNur bestimmte standardisierte Inhalte zulässig!Typisch für VANS (Value Added Network Services)Routing: Implizit, durch Sender / Empfänger-Codesim Header des Inhalts– Beispiele: VANS:EDI*ExpressTradanetDanNetEcodex Innerhalb X.400:Telebox-400Allegro28.05.2003(GXS, weltweit)(GXS, i.w. UK)(DanNet, Dänemark)(IBM-IE, Österreich)(Telekom, Deutschland)(Allegro, Frankreich bzw. Spanien)H. Werntges, FB Informatik, FH Wiesbaden84
Automatisierungshürden oder: Warum reichen ftp oder http denn nicht?– ftp und http sind konzeptionell C/S-Protokolle mit einemmanuell zu bedienenden “client”– High-end EDI-Anforderungen sind dagegen vollautomatischer 7*24 Std.-Betrieb Kapazität für tausende Dateien pro Tag oder gar Stunde– Konsequenzen:Zahlreiche Zusatzanforderungen “um ftp/http herum”28.05.2003H. Werntges, FB Informatik, FH Wiesbaden9Zusatzanforderungen Zugriffsberechtigungen (remote side) für ftp– bilateral abzustimmen und einzurichten Konventionen für Datei- und Verzeichnisnamen– Absprachen notwendig Berücksichtigung von cross-platform Aspekten– Bsp: Unix-to-VMS, Win2000-to-AS/400– Binär/ASCII, ASCII/EBCDIC, besondere Zeichensätze– Unterstützte ftp-Kommandos? Lokale Pufferung– Übertragungsstörungen dürfen sendende Prozesse nichtblockieren Organisation mehrerer Austauschkanäle28.05.2003H. Werntges, FB Informatik, FH Wiesbaden105
Zusatzanforderungen Serialisierung (FIFO)– Empfangsreihenfolge Sendereihenfolge der Dateien!– Bsp.: Bestelländerung darf “ihre” Bestellung nichtüberholen Wahrung der Eindeutigkeit– keine Datei doppelt senden– keine auslassen– kein Überschreiben durch andere Datei gleichen Namens Koordination mehrerer Quellen pro Kanal– Locking, gemeinsamer Server für Seriennr./ Dateinamen? Synchronisierung von Sender und Empfänger– “Atomare” Übergaberegel verhindert Annahme vonFragmenten28.05.2003H. Werntges, FB Informatik, FH Wiesbaden11Zusatzanforderungen Störungs-Management– Entfernung der “Reste” nach Verbindungsabbruch?– Wiederholung der gesamten Übertragung notwendig,oder Wiederaufsetzen am Punkt des Abbruchs möglich?– Überwachung blockierender Serverprozesse (z.B. ftpd)– Automatischer Wiederanlauf nach temporären Störungenwie Netzwerkausfall– Warnung/Alarmierung bei persistenten Problemen incl. Definition eines Schwellenwerts, evtl. pro Kanal28.05.2003H. Werntges, FB Informatik, FH Wiesbaden126
Zusatzanforderungen Ablaufsteuerung– Batch: Übertragung nur zu bestimmten Zeiten z.B. zur Bündelung, Last- und Kostenoptimierung– Event: Ereignisgesteuertes Auslösen vonAktionsketten Protokollierung– Insb. lückenloser Nachweis der erfolgenZustellungen28.05.2003H. Werntges, FB Informatik, FH Wiesbaden13Fachhochschule Wiesbaden - Fachbereich InformatikTopologien für denDatenaustauschPoint-to-point (P2P)P2P-NetzwerkHub-and-spokeHub-and-spoke plus GatewaysVernetzte C/S-Modelle28.05.2003H. Werntges, FB Informatik, FH Wiesbaden147
Point-to-point Modell Typisch für Initialphase– Erste Schritte einfach– Bilaterale Abstimmungohnehin noch die Regel Ideal für File transfer– Kein Routing notwendig Potentielle Probleme:– Verfügbarkeit derPartnersysteme– Standardisierung– Routing– Skalierung28.05.2003H. Werntges, FB Informatik, FH Wiesbaden15P2P-Netzwerke28.05.2003H. Werntges, FB Informatik, FH Wiesbaden168
Point-to-point Netzwerke Skalierungsproblemreduzierbar durchSpezialisierung– Randknoten, clients– Hauptknoten, server– Neue Aufgabe: Routing t?Standardisierung?Skalierung (große Systeme)? Fazit:– Die meisten P2P-Problemebleiben bestehen!28.05.2003H. Werntges, FB Informatik, FH Wiesbaden17Hub-and-spoke Modell28.05.2003H. Werntges, FB Informatik, FH Wiesbaden189
Hub-and-spoke Modell Extremfall eines P2P-Netzwerks:– 1 Server (“Hub”)– viele Clients (“Spokes”) Die Grundidee der Value Added Network Services (VANS)Ideal für MailboxingLöst das Routing-, Skalierungs- und VerfügbarkeitsproblemStandardisierung?– Nur per Industriestandard und/oder Marktbeherrschung– Proprietäre Zugriffstechniken, nicht für alle Plattformen verfügbar Kostenmodelle– Einmalige Setupkosten– Monatliche Fixkosten, z.B. pro Mailbox, Freivolumen– Variable Kosten, z.B. pro kB, “Sender zahlt”, S/E 1:1, pro Zugriff, .28.05.2003H. Werntges, FB Informatik, FH Wiesbaden19Hub-and-spoke Modell Zusatzleistungen einiger VANS– Zustellungsnachweis– Berichte Datenmengen Einzelnachweise mit Zeiten– Andere Leistungen Syntax-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-Mitgliedschaft28.05.2003H. Werntges, FB Informatik, FH Wiesbaden2010
Hub-and-spoke GatewaysGatewayGatewayGateway28.05.2003H. Werntges, FB Informatik, FH Wiesbaden21Hub-and-spoke Gateways Vernetzung mehrere Hub-and-spoke-Inseln (z.B. VANS)über Gateways– Theoretisch von Vorteil: Nur einmal Mitgliedschaft nötig– Praxis: “Coopetition”-Situation ungünstig Gateways zwischen Wettbewerbern entstanden durch KundendruckLaufen 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 Tarifstruktur28.05.2003H. Werntges, FB Informatik, FH Wiesbaden2211
Vernetzte C/S-ModelleVielleicht doch?Wenn ja, was bringtden Erfolg?28.05.2003H. Werntges, FB Informatik, FH Wiesbaden23Vernetzte C/S-Modelle Strenge Spezialisierung:– Entweder C(lient) oder S(erver) Konsequente Anforderungen an Server– Verfügbarkeit, Belastbarkeit, Vernetzbarkeit Lösung des Skalierungsproblems durch ProtokollStandardisierung– zwischen Clients und Server– zwischen verschiedenen Servern Lösung des Routingproblems durch neue Ebene:– Pflege einer separaten Adressierungsebene seitens derApplikationen erforderlich Resultierendes Konzept:– Messaging– Store-and-forward Prinzip28.05.2003H. Werntges, FB Informatik, FH Wiesbaden2412
Beispiel: SMTP / Internet MailServer-Domäne(als ständig verfügbar temSMTPüber gm.H. Werntges, FB Informatik, FH Wiesbaden25Begriffsbildung zu Messaging MTA - Message Transfer Agent– hier: Der SMTP Server– Beispiel: sendmail MS - Message Store– hier: Das Dateisystem– Allgemein: Ein Subsystem für “Langzeit”-Speicherung UA - User agent– hier: Das Mail-Programm– Beispiele: 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.2003H. Werntges, FB Informatik, FH Wiesbaden2613
Fachhochschule Wiesbaden - Fachbereich InformatikEinführung in X.400HintergrundAnalyseOrganisatorischesVergleich X.400 - Internet Mail28.05.2003H. Werntges, FB Informatik, FH Wiesbaden27Fachhochschule Wiesbaden - Fachbereich InformatikX.400: HintergrundHistorische EntwicklungX.400 im OSI-ReferenzmodellGrundlage: ASN.128.05.2003H. Werntges, FB Informatik, FH Wiesbaden2814
Quellenangaben Literatur:– 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 1994 WWW:– http://www.alvestrand.no/x400/– http://www.oppenheimer-software.com/x400.html– http://www.dfn.de/service/x400/28.05.2003H. Werntges, FB Informatik, FH Wiesbaden29Meilensteine in der Entwicklung von 05.20031992198019861988TC6 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 Informatik, FH Wiesbaden3015
X.400: Historische Entwicklung Vorgeschichte Organisatorisches Vorbild: “Gelbe Post” 1984– Für IPM ausgelegt: P2 1988– EDI-Besonderheiten standardisiert: P-EDI– IPM-Verbesserungen: P22 1992– Sicherheitsanforderungen ergänzt, z.B. X.50928.05.2003H. Werntges, FB Informatik, FH Wiesbaden31X.400 im OSI-Referenzmodell 7: Anwendungsschicht 6: Darstellungsschicht 5: Kommunikationssteuerungsschicht 4: Transportschicht 3: Vermittlungsschicht 2: Sicherungsschicht 1: Bitübertragungsschicht 1-4: Transportdienste 5-7: Anwendungs-D.28.05.2003 7: Application layer 6: Presentation layer 5: Session layer 4: Transport layer3: Network layer2: Data link layer1: Physical layerH. Werntges, FB Informatik, FH Wiesbaden3216
Anmerkungen Das OSI-Referenzmodell erschien 1984. Es hatte große ordnende Wirkung auf die weitereEntwicklung der Datenkommunikation. OSI-Protokolle und -Normen sind heute praktischohne Bedeutung, aber das OSI-Referenzmodellwird auch heute noch vielfältig zitiert. X.400: Eine “echte” Schicht-7 OSI-Protokollfamilie,einer der wenigen noch nicht von der “IP-Welt”verdrängten OSI-Standards. Quelle: Stöttinger, K.-H., Das OSI-Referenzmodell, Bergheim 198928.05.2003H. Werntges, FB Informatik, FH Wiesbaden33OSI-Schicht 7 im PDatenaustauschformateEDIFACT ODAX.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–VTPVirtual Terminal–CCR: Commitment, Concurrency,–TP Transaction ProcessingRecovery–X.500 Directory System28.05.2003H. Werntges, FB Informatik, FH Wiesbaden3417
Bemerkungen zu ODA und EDIFACT ODA - Office Document Architecture––––ISO 8613, für Briefe, Memos, Berichte, .Logische StrukturLayoutstrukturInhalt ODIF - O.D. Interchange Format– Für elektronischen Austausch von ODA-Dokumenten– Begrifflich schwer von EDI(FACT) zu trennenODA und ODIF sind heute ohne große Bedeutung fürEDI, besitzen aber gemeinsame Ursprünge28.05.2003H. Werntges, FB Informatik, FH Wiesbaden35X.400-Grundlage: ASN.1 ASN.1 - eine formale Beschreibung von Daten fürTelekommunikations-Protokolle, unabhängig , ApplikationenDetails des physischen DatenaustauschsKonzeptionelle Parallelen zu XML Schemas, SOAP; (MIME) Standardisiert & bewährt seit 1984, aktuelles Release: 1997 Typisierung:– Basistypen wie int, boolean, char strings, bit strings, – Konstrukte: structure, list, choice, 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.2003H. Werntges, FB Informatik, FH Wiesbaden3618
Fachhochschule Wiesbaden - Fachbereich InformatikX.400: AnalyseAufbau einer X.400 MailKomponenten eines MHSDie Protokolle28.05.2003H. Werntges, FB Informatik, FH Wiesbaden37Aufbau einer X.400 Mail Generelle Struktur:– Umschlag– Inhalt Kopf Rumpf 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))28.05.2003H. Werntges, FB Informatik, FH Wiesbaden3819
Aufbau einer X.400 Mail Inhalt (Content)– Kopf (Header) 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) [Forts.]28.05.2003H. Werntges, FB Informatik, FH Wiesbaden39Aufbau einer X.400 Mail Inhalt (Content) [Forts.]– Rumpf (Body) Body part 1 (type t[1]), , body part n, type t[n] 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)28.05.2003H. Werntges, FB Informatik, FH Wiesbaden4020
Fachhochschule Wiesbaden - Fachbereich InformatikKomponenten eines MHS28.05.2003H. Werntges, FB Informatik, FH Wiesbaden41X.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”)– 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.2003H. Werntges, FB Informatik, FH Wiesbaden4221
Komponenten eines X.400 MHSX.400 MHSX.400 xServerH. Werntges, FB Informatik, FH Wiesbaden43Fachhochschule Wiesbaden - Fachbereich InformatikX.400: Die Protokolle28.05.2003H. Werntges, FB Informatik, FH Wiesbaden4422
X.400 MHS: Die ProtokolleX.400 MHSX.400 3MTAP5AUAUFaxServerH. Werntges, FB Informatik, FH Wiesbaden45Kommunikationsprotokolle P1– beschreibt den Aufbau der Informationsobjekte, diezwischen zwei MTA's ausgetauscht werden P3– beschreibt die Funktionen beim Informationsaustauschzwischen UA bzw. MS und MTS P5– beschreibt die Funktionen zwischen AU und MTS, z.B.Übergang zu Telex P7– das Zugriffprotokoll eines UA auf den MS28.05.2003H. Werntges, FB Informatik, FH Wiesbaden4623
Weitere Beschreibungen P2– beschreibt den Aufbau der Informationsobjekte, die zwischen zweiUA's für Personen ausgetauscht werden, gemäß X.400(84) P22– wie P2, aber mit Ergänzungen aus X.400(88)– erweitert um Multimedia-Unterstützung (“MIME”-artig) P35, P-EDI, Pedi– 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.2003H. Werntges, FB Informatik, FH Wiesbaden47Fachhochschule Wiesbaden - Fachbereich InformatikX.400: Organisatorische AspekteADMDs, PRMDsRegelung der Verantwortlichkeiten, Tracking,(N)DNsO/R-Adressen: Aufbau, ParameterMTA-Routing, FallbacksGebühren (Beispiel)28.05.2003H. Werntges, FB Informatik, FH Wiesbaden4824
ADMDs und endungX.400MTAX.400MTAADMDADMD.H. Werntges, FB Informatik, FH Wiesbaden49ADMDs und PRMDs ADMDs bilden das Rückgrat des X.400 MHS– 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 verbunden Kommerzielle Aspekte– 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!28.05.2003H. Werntges, FB Informatik, FH Wiesbaden5025
ADMDs und PRMDs PRMDs:– 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 Direktverbindungen zwischen PRMDs– Direktverbindungen zwischen PRMDs (auch solcher, die anverschiedene ADMDs angebunden sind) sind zulässig– Vorteile Schnellstmögliche Zustellung, ohne Umwege Direkte Kontrolle über Erfolg Nur Leitungskosten, keine ADMD-Gebühren– Nachteile Einrichtung und Prüfung der Direktverbindungen Ständige Verfügbarkeit der direkt angeschlossenen Partnersysteme28.05.2003H. Werntges, FB Informatik, FH Wiesbaden51Verantwortlichkeiten, Tracking, DN Jede X.400-Nachricht trägt eine weltweit eindeutigeKennung auf envelope-Ebene, die MPDU-ID– 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 Eine Anwendung / ein Anwender kann den Nachrichtenkopfeindeutig kennzeichnen: IPM-ID– Grundlage für Nachweis der (Nicht-)Zustellung gegenüber demAnwender / der Anwendung:(non-) delivery notification, (N)DN– Grundlage für Empfangsbestätigungen (receipts) Das MHS sendet (N)DNs als spezielle Nachrichtentypenautomatisch bzw. auf Anforderung in standardisierter Form28.05.2003H. Werntges, FB Informatik, FH Wiesbaden5226
Ebenen der ZustellbestätigungSendendes gung ”EDIKonverterFunctional ackn.EDIKonverter“CONTRL”, 997Bestätigung B., X.400 DN/NDNAusgehendeNachricht28.05.2003H. Werntges, FB Informatik, FH ADNAccessUnit28.05.2003X.400MTADN:delivery notificationH. Werntges, FB Informatik, FH WiesbadenZugestellteNachricht5427
n-delivery notificationH. Werntges, FB Informatik, FH Wiesbaden55X.400 O/R Adressen X.400 O/R Adressen kennzeichnen i.w. eine Person––––Hierarchisches 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,-”:C DE / A VIAT / P MGI / O EDI / OU REAL / S TEST28.05.2003H. Werntges, FB Informatik, FH Wiesbaden5628
X.400 O/R Adressen Übliche Parameter–––––––––– Besondere ParameterC (country)A (ADMD)P (PRMD)O (organization)OU1 OU4(org. unit 1 4)S (surname)g (given name)I (middle initial)CN (common name) (generationalqualifier), etc. 28.05.2003– DDAN, DDAV (domain defined attrib.) z.B. zur Abbildung derParameter von VANShinter Gateways, etwavon IBM-IE– X.121 Für die Angabe vonFaxnummern undKlartext-Empfängernamen– (viele weitere, seltenbenötigt)H. Werntges, FB Informatik, FH Wiesbaden57MTA-Routing Routing– 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 Normalerweise baut der sendende MTA die Verbindung auf– Üblich: Default-Route anlegen, bei PRMDs meist die zur ADMD 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.2003H. Werntges, FB Informatik, FH Wiesbaden5829
MTA-Routing Ablehnung bei endgültiger Unzustellbarkeit über NDN– 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– Kein unnötiges Rücksenden des Inhalts - nur NDN Zustellprioritäten– niedrig– normal– dringend28.05.2003H. Werntges, FB Informatik, FH Wiesbaden59MTA-Stacks Traditionell––––X.25-Stack: TP2, native X.25-KopplungEinfach zu konfigurierenSicher, da virtuelle P2P-VerbindungLeider teuer Per RFC, inzwischen sehr verbreitet– IP-Stack: TP0– Für X.400 reservierter Port: 102– Kopplung flexibel realisierbar, z.B. IP über Dial-up ISDN IP über VPN IP direkt über Internet (ggf. via Firewall)28.05.2003H. Werntges, FB Informatik, FH Wiesbaden6030
Gebührenbeispiele X.400 (class 4 - reicht für EU)– 0,125 / kb (erstes kB)– 0,075 / kb (ab 2. kB) VANS am Bsp. Phönix / GE-GXS– 40000 Belege à 2 kB 13000 0,165 / kB– Abrechnung 100-Byte-weise– separat: Gebühr pro Anwahl der Mailbox In beiden Fällen zusätzlich:– Monatliche Grundgebühren– Leitungskosten, z.B. X.25, ISDN28.05.2003H. Werntges, FB Informatik, FH Wiesbaden61Fachhochschule Wiesbaden - Fachbereich InformatikX.400 vs. Internet MailVergleich X.400 - Internet MailDie Antwort der IETF: EDI-INT28.05.2003H. Werntges, FB Informatik, FH Wiesbaden6231
Vergleich X.400 - Internet Mail Secure Not Secure– Documents managed bysecure systems Traceable Not Traceable– Misrouted mail can betracked down– lost messages arepermanently lost Receipts readily available– no more "I never got it” Sender Certified byoriginating e-mail carrier28.05.2003– can not be trusted withconfidentialinformation Not Receiptable– You'll never know if the mailarrived Sender Spoofable– You're never sure who reallysent the messageH. Werntges, FB Informatik, FH Wiesbaden63Vergleich X.400 - Internet Mail Known path– Only handled byresponsible commerciale-mail firms Fast– X.400 standards require95% of mail deliveredwithin 45 minutes.With the Internetbecoming increasinglybogged down, X.400stimely delivery becomesincreasingly important.28.05.2003 Unknown path andhandling May be fast or veryslow– mail may take days to bedeliveredH. Werntges, FB Informatik, FH Wiesbaden6432
Fachhochschule Wiesbaden - Fachbereich InformatikInternet MessagingEDI-INTTrends28.05.2003H. Werntges, FB Informatik, FH Wiesbaden65EDI-INT AS1, AS2 (EDI over INTERNET) Standard der IETF (Internet Engineering TaskForce) Übertragung von EDI Nachrichten (EDIFACT, ANSI X.12) über Internet Transportprotokoll– eMail (EDI-INT AS1) oder– HTTPS (EDI-INT AS2) Nachrichtenrouting– durch Auswertung der EDI Service Segmente (UNB,.) 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 Schon wieder veraltet oder kurz vor dem Durchbruch?– Verbreitung „nur“ in USA, aber nun Bewegung auch in Europa– Weitere Verbreitung und Reifung behindert durch neue Entwicklungen28.05.2003H. Werntges, FB Informatik, FH Wiesbaden6633
Die IETF-Antwort: EDI-INTEDI INT MessageSenderMDNReceiver an encrypted EDI(FACT) message an encrypted symmetric key fordecoding the message a digital signature28.05.2003H. Werntges, FB Informatik, FH Wiesbaden67EDI-INT LifecycleThe 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 types of data.8. Deliver data to back-end system9. Send signed return receipt to sender28.05.2003H. Werntges, FB Informatik, FH Wiesbaden6834
Trends 2002 https– Interessant als low-level Protokoll SOAP– Problem: Nur für XML-Daten geeignet XML Frameworks– Bisher allgemeinster Ansatz: ebXML(später zu besprechen)28.05.2003H. Werntges, FB Informatik, FH Wiesbaden69Fachhochschule Wiesbaden - Fachbereich InformatikX.400: Das BindegliedAbschließende Betrachtung zumMessaging anhand einesUnternehmensbeispiels28.05.2003H. Werntges, FB Informatik, FH Wiesbaden7035
X.400: Das Bindeglied aller VANSAllegro 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 toIBM-IE / EURTandem-X25Gateway toBT EDInet / UKADMD link, backupMetro-X25Metro AG / DEGateway toECODEX / ATAdjacent MTAsvia X.25 stackISOPLEXX.400 MTAC DE/A LION/P GILLETTEAdjacent MTAsvia IP stack(Dial-up ISDN)PostDK-X25Danish Post / DKGE-GXS-DEGateway toTradanet / UKGateway MTA toGE/GXS servicesGateway toEDI*Express / CE28.05.2003Unternehmensbeispiel Braun / GilletteH. Werntges, FB Informatik, FH Wiesbaden7136
EDI Electronic Data Interchange (Elektronischer Datenaustausch) 28.05.2003 H. Werntges, FB Informatik, FH Wiesbaden 2 Fachhochschule Wiesbaden - Fachbereich Informatik Klassisches EDI - der Kern Einleitung - die Kernkomponenten File Transfer- und Messaging-Standards UN/EDIFACT und EANCOM im Detail Applikationsschnittstellen Konverter- und .
