PLP ist eine .NET basierende API für Reiseveranstalter-Buchungsmaschinen.

Außer diversen Kundenanforderungen ist ein Übergang zur Cloud (Azure) geplant. Kritisch ist hier eine vertikale Skalierung der Komponenten. Das treibt die Kosten in die Höhe. Es gibt viele Sicherheitsrisiken zu beseitigen.

Es ist immer noch ASP.NET im Einsatz. Statt auf ASP.NET Core zu migrieren, trennt das Team Middleware und Frontend auch technologisch auseinander, wobei ASP:NET Web API und Angular eingesetzt wird.

Funktionale Anforderungen: Diverse Kundenanforderungen (Reiseportalen)

Nicht funktionale Anforderungen: Migration auf der Cloud

Architektur: Microservices

Andere Merkmale: Sprint

• Gateway API stellt für externe Kunden (Reiseportale) die Dienste (Suchen und Buchen)

  zur Verfügung. Außer diversen Kundenanforderungen ist ein Übergang zur Cloud (Azure, AWS)

  geplannt. Aufgrund hoher Belastung (> 100 rq/s) sind Tracing und Logging kritisch geworden

  (Datenmenge). Komponenten lassen sich nicht gut horizontal skalieren.

  Übergang zu leichtgewichtigeren Lösungen ist durch den Abschied von mehreren erfahrenen

  Seniorentwicklern erschwert worden, bleibende Entwickler verstehen teilweise nicht,

  wie die Komponenten funktionieren (CDI, IoC Kontainererweiterung

  um AsyncRequestScope usw.).

   

  Funktionale Anforderungen: k.A

  Nicht funktionale Anforderungen: Run everywhere (Cloud)

  Architektur: Microservices

  Coaching: CDI Course - Grundlagen und SPI, Angular Course - Grundlagen und Observables

  Andere Merkmale: Sprint

• PLP is .Net basierende API, die die Reiseveranstallter-Buchungssytemen zur Verfügung stellt.

  Außer diversen Kundenanforderungen ist langfristig ein Übergang zur Cloud (Azure, AWS)

  geplannt. Als erster Schritt in dieser Richtung ist eine Migration zum .NET Core ausgewählt worden.

  Eine PCI DSS - Komformität muss gewehrleistet sein.

   

  Funktionale Anforderungen: Diverse Kundenanforderungen (Reiseportalen)

  Nicht funktionale Anforderungen: Migration von .Net Framework zum .Net core

  Architektur: Microservices

  Andere Merkmale: Sprint

IBE Web ist ein Frontendschicht aufgebaut auf Gateway API.

Als Middleware innerhalb Frontent IBE Web ist NodeJS eingesetzt.

Funktionale Anforderungen: Diverse Kundenanforderungen (Reiseportalen)

Nicht funktionale Anforderungen: k.A

Architektur: k.A.

Andere Merkmale: Sprint

Search Engine ist eine hochleistungsfähige (> 500 RQ/s) native Suchmaschine

für die Reiseindustrie. Mit zunehmender Anzahl an Anforderungen ist sie jedoch zu groß geworden.

Es ist schwierig geworden Engine weiter zu entwickeln, da z.B. Debugging schon

nicht zuverlässig läuft (Breakpoints sind oft nicht in der Lage den Prozess anzuhalten).

Ein exzessiver Einsatz von C++ Templates und Makros sind zu Problemen geworden.

Funktionale Anforderungen: k.A.

Nicht funktionale Anforderungen: Kompilierung und Linking nicht mehr als 10 min

Architektur: Monolitisch, übergang zum Microservices

Andere Merkmale: Kontainerisierung – Docker und Kubernetes – Proof of Concept

Gateway API stellt für externe Kunden (Reiseportalen) die Dienste (Suchen und Buchen)

zur Verfügung. Finnair hat eine Entscheidung getroffen die Flugleistungen

mit Hotelangeboten zu kombinieren.

Funktionale Anforderungen: Finnair integration

Nicht funktionale Anforderungen: k.A.

Architektur: C/S

Andere Merkmale: Scrum

Übergang von Monoliten zum Microservices in agilem Kontext

Es gibt ein klasisches Architecture Board. Das passt nicht mehr zur Agile Organisation.

Es ist eine netflix-artige Struktur geplannt mit Microservices, Tribes und Chapters.

JBoss ESB migrierte von Comunity to Commercial Projekt. Damit ist die Migration auf JBoss AS 7, bzw. WildFly kostenintensiv. Nach der Evaluationsphase (Spring vs. JEE) folgt der Umzug auf JEE Technologien.

Funktionale Anforderungen: Volle Rückwärtskompatibilität zum inTTegra

Nicht funktionale Anforderungen: Lang läufige Transaktionen, Fokus auf die Leistung (kurze Antwortzeiten), hohe Last (bis zum 50 Nachrichten pro Sekunde), Skalierbarkeit, Portabilität, PCI DSS Kompatibilität

Architektur: SOA, MDA, EDA
Andere Merkmale: Scrum, TDD, Continuous Integration

Vereinfacht sollte das inTTegra-Framework als Service-Bus angesehen werden, das die vorhandenen externen EDV-Dienste (Touroperatoren, Zusatzleistungen, und Zahlungs-Systeme) in inTTegra-Dienste kapselt und dann so orchestriert, dass ihre Leistungen zu höheren Diensten zusammengefasst und anderen Abteilungen oder externen Kunden zur Verfügung gestellt werden können.

Funktionale Anforderungen: B2C, B2B2C Dienste, OTA (Open Travel Alliance) Standard Anwendung, B2B Client, Agenturverwaltung und Monitoring Tools
Nicht funktionale Anforderungen: Änderbarkeit, geringe Komplexität. Effektive Weiterentwicklung und schnelle Einarbeitung für lokale Teams, hohe Last, Skalierbarkeit, Portabilität
Architektur: SOA, MDA, MVC
Andere Merkmale: V-Model/Scrum, TDD, Continuous Integration/Deployment

TravelTainment UK nahm auf .NET Platform basierte Softwarelösung in Betrieb. Die Integrationsplatform für diverse UK Reiseveranstalter sollte ins inTTegra integriert sein um UK Anbieter durch inTTegra WS zur Verfügung zu stellen.

Funktionale Anforderungen: Web Services Provider liefert Dienste so, dass UK 3rd Party Anbieter für WS Consumer transparent sind.
Nicht funktionale Anforderungen: Rückkompatibilität für .NET sowie JSE/ESB Systeme
Architektur: SOA, MDA, MVC
Andere Merkmale: V-Modell

TravelTainment UK nahm auf .NET Platform basierte Softwarelösung in Betrieb. Die Integrationsplatform für diverse UK Reiseveranstalter sollte ins inTTegra integriert sein um UK Anbieter durch inTTegra WS zur Verfügung zu stellen.

Funktionale Anforderungen: Web Services Provider liefert Dienste so, dass UK 3rd Party Anbieter für WS Consumer transparent sind.
Nicht funktionale Anforderungen: Rückkompatibilität für .NET sowie JSE/ESB Systeme
Architektur: SOA, MDA, MVC
Andere Merkmale: V-Modell

Nach sehr erfolgreichem Produkt (Datamix) für dynamische Paketierung war notwendig Reseller - orientierende Lösung anzubieten.

Funktionale Anforderungen: inTTegra WS liefert neue 3rd Party Provider.
Nicht funktionale Anforderungen: Lang läufige Transaktionen, Fokus auf die Leistung (kurze Antwortzeiten), hohe Last (bis zum 20 Nachrichten pro Sekunde), Skalierbarkeit, Portabilität

 Architektur: SOA, MDA
Andere Merkmale: Scrum, TDD

Reiseveranstalter liefert konsolidierte Daten im vordefinierten Format. Die Daten sind in die Datenbank importiert.

Nachher kommt es zum Denormalisation und Optimierung, so dass die Query - Antwortzeiten durchschnittlich nicht über 2 Sekunden liegen.

Funktionale Anforderungen: Backend-Schicht sucht, filtriert und liefert touristische Leistungen (Paketen)
Nicht funktionale Anforderungen: DataLoad während online Betrieb, Oracle DB in Cluster, viele langläufige Transaktionen (OLAP) zusammen kombiniert mit relative kurze Antwortzeiten (OLTP)

Architektur: k.A
Andere Merkmale: k.A

X-Gate Web Services setzen auf eine serviceorientierte Architektur (SOA), Opensource-Technologien und anerkannte Standards für moderne Kommunikation mit den Leistungsanbietern auf. Die X-Gate XML-Schnittstelle basiert dabei auf den weltweiten Branchenstandards der Open Travel Alliance (OTA). Der Nutzer erhält über X-Gate Zugriff auf den gesamten Content der an das Middleware  angeschlossen ist (Charterflug, Mietwagen, Hotel, Reiseveranstalter).

Funktionale Anforderungen: XGate WS liefert neue 3rd Party Provider.
Nicht funktionale Anforderungen: Langläufige Transaktionen, hochbelastbares, responsives System, Skalierbarkeit, Portabilität

Architektur: SOA, MDA
Andere Merkmale: V-Modell

Robin - Plattform für gesamten Content der an das Robin-Rechenzentrum in Hamburg angeschlossen Leistungsträger (Charterflug, Mietwagen, Hotel, Reiseveranstalter) ohne spezielle Formatkenntnisse der Touristik

Funktionale Anforderungen:  Lesende und modifizierende Zugriffe auf die Daten und deren Struktur (Oracle DB) ermöglichen
Nicht funktionale Anforderungen: Leistung, hohe Nebenläufigkeit

Architektur: N/A

Andere Merkmale: N/A