KoKoBahn

1. KoKoBahn

2. Ziele und Partner Projektstart 01. Juni 2008 Kick Off 17. Juli 2008 Ziel Standardisierter elektronischer Datenaustausch möglichst aller bahnrelevanten Prozesse zwischen den deutschen Seehäfen und dem Hinterland. Zielgruppe Alle am Bahnverkehr zwischen den deutschen Seehäfen und dem Hinterland Beteiligten. Assoziierte Partner

3. Nutzer A nicht standardisierte Schnittstellen XML WWW standardisierte Schnittstellen Nutzer B Nutzer C Prozessorientierung • Nachrichten entgegennehmen. • Nachrichten im Bedarfsfall aufsplitten und/oder an ein oder mehrere Empfänger verteilen. • Datenformate konvertieren falls die Transaktionspartner in unterschiedlichen Datenformaten kommunizieren. • Standardisierter Datenaustausch im XML-Format.

4. Vorteile • KoKoBahn ist eine neutrale, unabhängige Kommunikationsplattform und gewährleistet allen Bahnbeteiligten diskriminierungsfreien Zutritt • Die Kommunikation zwischen verschiedenen Transaktionspartnern an unterschiedlichen Standorten kann ohne Kenntnis und Anpassung der von den Transaktionspartnern genutzten Datenformate erfolgen.

5. Vorteile • Kommunikation von KMU ohne eigene Software über ein Web-Interface. • XML ermöglicht sowohl einen einfachen und flexiblen als auch einen zukunftsfähigen Informationsaustausch. • Die Anbindung an die Datendrehscheibe ist eine gesicherte Investition in die Zukunft, da innovative Technologien auf der Basis anerkannter Standards verwendet werden. • Die Plattform bietet ein Höchstmaß an Datensicherheit. • Validierung der Daten, so dass fehlende Daten eingefordert werden können. • Die Plattform bietet die Möglichkeit für den Bezug von Serviceleistungen, Datendiensten (z. B. Statusmeldungen) aus / von lokalen Anwendungen. • Möglichkeit IT-Strukturen umzustellen und zu modernisieren , ohne dass der Kommunikationspartner davon betroffen ist.

6. CODIS HABIS D1Statusmeldung Beladung A2Ver-, Entlade-anweisung E1Ladeliste C2Gestellungs-anweisung C1Gestellungs-anweisung Sonstiges EIU B2Wagen-bestellung D2Statusmel- dung Beladung nicht standardisierte Schnittstellen EVU XML E2Lade- / Wagenliste G2Antrag Trasse WWW standardisierte Schnittstellen F2Frachtbrief H1Fahrplan G1Antrag Trasse E2Ladeliste B1Wagenbestellung E2Wagenliste D2Statusmel- dung Beladung A1Ver-, Ent-ladeanweisung F1Frachtbrief H2Fahrplan Operateure Firmen Kommunikationsmodell Umschlagbetriebe

7. Technologischer Ansatz  ESB Ziel Kommunikationstechnische Zusammenführung der verschiedensten Anwendungssysteme (z. B. Häfen, EVU, EIU, Operateure) Lösungsansatz Service Oriented Architecture (SOA) Technische Basis Enterprise Service Bus (ESB) Datenaustausch XML Messages • lose Kopplung heterogener IT-Systeme • standardisierte Datenstrukturen • Datenkonvertierung / Formatkonvertierung • Monitoring des gesamten Daten- flusses C A File Soap E S B ? Mail B D E JMS

8. Technisch ESB  Connector • Der Connector (Binding Component) übernimmt die Anbindung der unterschiedlichsten Transportprotokolle an KoKoBahn (Transport Protocol Conversation). • HTTP[S] zu Java Message Service (JMS) • FTP zu Dateiabwicklung • SMTP zu TCP • Sie stehen für die Flexibilität von KoKoBahn gegenüber der Kommunikation zwischen unterschiedlichsten Kundensystemen. Quelle: www.apache.org

9. Technisch ESB  Converter • Es ist selten, dass das Format der ankommenden Nachricht dem erwartendem Format oder dem Format der ausgehenden Nachricht entspricht. • Der Converter (Transformer) wandelt das Datenformat der ankommenden Nachrichten durch Auswertung der Kopfdaten in ein internes XML-Format um, das von KoKoBahn zur internen Verarbeitung (Validierung, Filter, etc) verwendet wird. • Das interne XML-Format wird ebenfalls durch einen Converter in ein ausgehendes, dem Empfänger entsprechendes, Nachrichtenformat umgewandelt. Quelle: www.apache.org

10. Technisch ESB  Usermanagement • Die Usermanagement (Mandantenmanagement) nutzt das Publish & Subscribe Verfahren. • Die bereitgestellten Daten der Publisher können vom Subscriber ausgewählt werden, wobei der Publisher letztendlich bestimmt, wer die Daten bekommen darf (einmaliger Vorgang). • Diesem Verfahren liegen im Vorfeld beschlossene Verträge zugrunde. Die Endgültige Herstellung der Verbindung erfolgt durch einen KoKoBahn-Administrator.

11. Technisch ESB  Routing • Die Komponente Routing ist verantwortlich für die Weiterleitung an den/die Empfänger. Dabei werden sowohl Adressinformationen aus dem Nachrichtenkopf als auch Informationen aus der Benutzerverwaltung (Abbonnement von Meldungen) ausgewertet. Quelle: www.apache.org

12. Technisch ESB  Accounting und Logging • Das Accounting (Rechnungskontrolle) hinterlegt für jeden gebuchten kostenpflichtigen Nachrichtendienst im KoKoBahn-Konto des Nachrichtenempfängers einen entsprechenden Kosteneintrag. • Die Komponente Logging zeichnet alle relevanten Nachrichtenprozesse sowohl für jeden einzelnen Kunden, als auch allgemeine serverseitige, systemspezifische Nachrichtenprozesse auf. • Die kundenspezifische Einsicht in diese Aufzeichnungen ermöglichen: • Transparenz • Nachvollziehbarkeit • Rechtssicherheit

13. CONNECTOR CONNECTOR CONVERTER CONVERTER JMSHTTP[S] File-FTP Handling TCPSMTP HTTP[S]JMS FTP File- Handling SMTPTCP XMLFlatfile FlatfileXML Datenfluß Module KoKoBahn INHOUSESYSTEM/CL I EN T INHOUSESYSTEM/CL I EN T KoKoBahn Usermanagement • Database • Accounting • Logging ROUTING Protokoll Protokoll Format Format

14. Aktueller Stand  Server Apache ServiceMix 4 • OSGiTM-konforme Plattform (Open Services Gateway initiative) • Standard für Komponenten-orientierte Software • Bietet die Möglichkeit Softwarekomponenten zu installieren, zu aktualisieren bzw. zu deinstallieren ohne das System neu starten zu müssen und ohne andere Dienste zu beeinflussen. • Wird von vielen namhaften Herstellern wie IBM, Oracle, Siemens, Sun und vielen mehr entwickelt. • Ermöglicht Verarbeitung von über 100 Meldungen pro Sekunde. Ausgehend von 10-15 Meldungen pro Container bis zur Verladung, ergeben sich im Jahr 2006 für Bremerhaven zwischen 4,17 und 6,15 Millionen Meldungen bei 417.000 Containern. Bei einer Verdoppelung des Containerumschlags bis 2014 ergeben sich daraus für Bremerhaven im Durchschnitt 0,4 Nachrichten pro Sekunde.

15. Aktueller Stand  Grundprinzipien Serverkonzept • Ausfallsicherheit • Verwendungeines Virtual Private Network (VPN) für den Austausch von Verwaltungsinformationenbeigetrennten Internet-Sites • Ausfallsicherheitder Frontends • Skalierbarkeit • Netzwerksicherheit - UnterstützungdurchArchitektur • Firewall • Demilitarisierte Zone (DMZ) WeitereEntwicklung • ServerkonzeptliegtdemRechenzentrumderdbh Logistic IT AG vor. Bereitstellungder Server-Hardware erfolgtimerstenQuartal 2010 (EndeJanuar).

16. Aktueller Stand  Softwareentwicklung • Entwicklung eines Demonstrators auf der Grundlage des Apache ServiceMix3 • Test der Anforderungen an KoKoBahn (Validieren, Verteilen, Splitten …) • Leistungsfähigkeit (Belastbarkeit) • Bedienbarkeit • Unterstützung in der Softwareentwicklung (Versionsverwaltung, Deployment etc.) Weitere Entwicklung • Erstes Testszenario mit einem assoziierten Partner – erstes Quartal 2010 • DB-Modell, Benutzerverwaltung, Logging und Accounting • Validierungskomponenten, Konnektoren und Konverter

17. KoKoBahn Vielen Dank !