1.3. Anwendungsfälle


1.3.1. »Major Widgets« Anwendungsfall

1.3.1.1. »Major Widgets« Einführung

1.3.1.1.1. »Major Widgets« Übersicht
Bei »Major Widgets« handelt es sich Einzelhandelsgeschäft für Autoteile, das vor kurzem drei weitere Geschäfte für Autozubehör erworben hat und jetzt die Systeme der nun insgesamt vier Geschäfte integrieren muss.
1.3.1.1.2. »Major Widgets« Geschäftsmodell
»Major Widgets« und alle drei der von ihm erworbenen Geschäfte beliefern routinemäßig eine Reihe von Autowerkstätten in ihrer Nähe. Jedes Geschäft liefert Kunden kostenlos Teile frei Haus, wenn diese sich im Umkreis von 25 Meilen befinden. Jedes Geschäft besitzt seine eigene Datenbank zur Speicherung der Kundenkonten der Autowerkstatt, dem Speichern von Inventar und der Lieferanten von Ersatzteilen.
Geschäfte wurden über das Telefon getätigt, aber jetzt will »Major Widgets« einen online Bestellservice implementieren, damit Kunden ihre Ersatzteile schneller und effizienter bestellen können. Der webbasierte Dienst wird Bestellungen und Lieferungen koordinieren, Rechnungen für Kunden ausstellen, das Inventar jedes Geschäfts beobachten und aktualisieren und Ersatzteile bei Lieferanten bestellen. Kunden können ihn zum Prüfen des Status ihrer Bestellungen verwenden.
Alle vier Geschäfte verkaufen auch Teile an Laufkundschaft, für die in der Regel keine Kundenkonten angelegt werden. Jedes der ladeninternen Bestellsysteme ist außerdem in das zentrale Bestellbearbeitungssystem eingebunden.

1.3.1.2. »Major Widgets« Integrationsplan

Abbildung 1.1, »»Major Widgets« Integrationsplan« zeigt in einer Ansicht auf hoher Ebene wie Red Hat JBoss Fuse eine Integrationslösung zur Implementierung des neuen Geschäftsmodells von »Major Widgets« implementiert.

Abbildung 1.1. »Major Widgets« Integrationsplan

Dieser Plan erstellt:
  • Einen einzelnen Eingangspunkt im Bestellbearbeitungssystem, auf den über das Web und über die ladeninternen Terminals zugegriffen werden kann
  • Ein intelligentes System zur Bestelleingabe, dass webbasierte Bestellungen an die der Lieferadresse am nächsten gelegene Geschäftsniederlassung leitet
  • Ein Bestellbearbeitungssystem (Instanzen laufen lokal in jedem Geschäft), das Bestellungen annimmt und bearbeitet, Kundenkonten wartet sowie das Inventar verfolgt und pflegt
  • Ein master/slave Broker-Cluster, der ein zuverlässiges Messaging-Rückgrat für die Integrationslösung liefert
Dieser Plan erlaubt es jedem Geschäft, seine eigenen, bestehenden Systeme beizubehalten, aber ermöglicht es Ihnen dennoch als geschlossene Einheit zu funktionieren.

1.3.1.3. »Major Widgets« Implementierung

Abbildung 1.2, »»Major Widgets« Implementierungsdiagramm« zeigt, wie ein Major Widgets Integrationsplan implementiert werden könnte.

Abbildung 1.2. »Major Widgets« Implementierungsdiagramm

1.3.1.3.1. »Major Widgets« Komponenten
Der Red Hat JBoss Fuse Kernel liefert eine Runtime Umgebung, die Enterprise Support (Management, Protokollierung, Provisioning, Sicherheit) für die Hauptniederlassung (Store A) bietet, wo die meisten Integrationsanwendungen laufen. Seine eingebetteten Dienste liefern die Frameworks für die Implementierung dieser Komponenten der Lösung:
  • RESTful-Dienst—zum Erstellen einer JAX-RS Applikation, die auf jedemTerminal der Autowerkstätten läuft (1), und Kunden die Eingabe von Bestellungen von Ersatzteilen über ein Formular zur Bestellungseingabe über das Internet ermöglicht.
  • Webdienst—zum Erstellen eines JAX-WS Frontend zur Implementierung der Bestelleingabefunktionalität an jedem der geschäftsinternen Terminals, die Bestellungen von Laufkundschaft erhalten (2), die Ersatzteile direkt kaufen.
  • camel-cxf Komponente—eine Routing und Integrationsdienstkomponente, die einen Endpunkt für einen Eingang erstellt (3), der die Major Widgets Routing-Logik nach außen hin als einen Webdienst oder einen RESTful- Dienst offenlegt.
  • Routing- und Integrationsdienst—für das Erstellen von Routen (4, 6), der vom Eingangspunkt des Web/RESTful-Diensts durch das entsprechende Backend zur Bestellbearbeitung erhaltene direkte Bestellungen weiterleitet.
  • Messaging Dienst—zum Erstellen eines persistenten, fehlertoleranten, geclusterten Messaging-Systems (5, 5a), das sicherstellt, dass niemals eine Bestellung wegen eines Systemfehlers verloren geht, der Message-Broker oder die Verbindungen zwischen dem Message-Broker und seinen verschiedenen Clients—dem Frontend inhaltsbasierten Router (4) und dem Backend dynamischen Router (6).
1.3.1.3.2. »Major Widgets« Integrationsfluss
Bei der »Major Widgets« Hauptniederlassung (Store A) läuft das Frontend der Bestellungseingabe (Routing und Messaging Agents, die innerhalb von Red Hat JBoss Fuse laufen) auf dem Computersystem der Hauptgeschäftsniederlassung. In jedem der vier Geschäfte (Stores A-D) läuft eine Instanz des Backend der Bestellungseingabe (Routing Agent und Backend-Bearbeitung in JBoss Fuse) auf dem lokalen Computersystem.
Wenn der Frontend-Webdienst (3) eine online Bestellung erhält, so gibt der Routing-Agent diese an den inhaltsbasierten Router (4) weiter, um zu bestimmen, an welches Geschäft das Ersatzteil zur Weiterbearbeitung geschickt werden soll. Normalerweise gelangt die Bestellung dann in die Warteschlange der Zielgeschäfts (5), wo sie darauf wartet, dass das Zielgeschäft sie erhält (6). (Mit im System eingebauter Fehlertoleranz kann das System weiter funktionieren, ohne dass Bestellungen verloren gehen, wenn der Master-Broker (5) ausfällt).
Im Fall von Autowerkstätten (1), routet der Content-basierte Router Bestellungen basierend auf der Postleitzahl an das dem Kunden nächste Geschäft. Im Fall der Laufkundschaft (2) gibt das Geschäft für Autozubehör seine eigene Postleitzahl beim Frontend an, so dass die Bestellung immer an das lokale Geschäft geleitet wird.
Erhält das Backend die eingereichte Ersatzteil-Bestellung, so verwendet die Applikation einen dynamischen Router (6), um die Ersatzteile in der Datenbank des Geschäfts zu finden und zu sehen, ob diese auf Lager sind. Die Ergebnisse hängen davon ab, ob der Kunde eine Autowerkstätte oder Laufkundschaft ist:
  • Laufkundschaft der Autowerkstätte
    Sind die Teile verfügbar, so wird die Bestellung an die Backend-Bearbeitungssoftware (8) geschickt, die den Kunden darüber informiert und die Rechnung ausstellt (1), die Terminplanung für die Lieferung organisiert, das Inventar aktualisiert und Teile entsprechend neu bestellt.
    Sind die Teile nicht verfügbar, so wird die Bestellung an einen Prozessor eingereicht, der eine Fehlermeldung generiert, die per E-Mail (9) an den Kunden(1) geschickt wird.
  • Laufkundschaft
    Sind die Teile verfügbar so wird die Bestellung an die Backend-Bearbeitungssoftware (8) geschickt, die den Mitarbeiter informiert (2), das Inventar aktualisiert und Teile entsprechend neu bestellt. Der Mitarbeiter holt die Teile aus dem Lager und verkauft diese dem Kunden im Geschäft direkt.
    Sind die Teile nicht verfügbar, so wird die Bestellung an einen Prozessor eingereicht, der eine Fehlermeldung generiert, die per E-Mail (9) an die örtliche Geschäftsniederlassung (2) geschickt wird. Der Mitarbeiter informiert daraufhin den Kunden, der dann entscheiden kann, ob der Mitarbeiter in anderen Niederlassungen nach dem Teil suchen soll.

1.3.2. »Loans Consolidated« Anwendungsfall

1.3.2.1. »Loans Consolidated« Einführung

1.3.2.1.1. »Loans Consolidated« Übersicht
»Loans Consolidated« ist eine neue Firma mit Augenmerk auf die Konsolidierung anderer Kunden- und Hausinformation von Verkäufern und dem Vergleich dieser Informationen mit lokalen Schulen, so dass sich Verkäufer eine Auswahl verschiedener Häuser ansehen und diese vergleichen können.
1.3.2.1.2. »Loans Consolidated« Geschäftsmodell
»Loans Consolidated« bezieht Kundendaten und Hausinformationen von verschiedenen Kreditanbietern; diese Anbieter liefern regelmäßig Informationen zu neuen Häusern und Kunden sowie aktualisierte Informationen zu bestehenden Einträgen.
Kunden sehen online den Schätzwert dieser wird von »Loans Consolidated« auf Grundlage der Hausinformationen sowie der Anzahl der Schulen in der Umgebung berechnet.
Die Anbieter der Kredite haben um die Bereitstellung eines Dienstes gebeten, der alle Daten mit dem aktualisierten Schätzwert an sie zurückschickt.

1.3.2.2. »Loans Consolidated« Integrationsplan

Ein Plan auf hoher Ebene, der Red Hat JBoss Fuse verwendet bietet eine Integrationslösung zur Implementierung des neuen Geschäftsmodells von »Loans Consolidated«. Diese Lösung erstellt:
  • Einen einzelnen Eingangspunkt im Bestellbearbeitungssystem, auf den entweder über einen FTP-Server oder einen Batch-Job über Nacht Dateien abgelegt werden.
  • Ein intelligentes System, das XML-Dateien umleitet und bei Haus-Dateien den Wert des Hauses schätzt, ehe es an einen Messaging-Broker weiterleitet.
  • Ein System, das umgebende Informationen abruft, um eine bessere Bewertung zu liefern.
  • Die Möglichkeit, die Ergebnisse des Schätzwerts an die Anbieter zurückzuschicken.

1.3.2.3. »Loans Consolidated« Implementierung

Abbildung 1.3, »»Loans Consolidated« Implementierungsdiagramm« zeigt, wie ein »Loans Consolidated« Plan implementiert werden könnte.

Abbildung 1.3. »Loans Consolidated« Implementierungsdiagramm

1.3.2.3.1. »Loans Consolidated« Komponenten
Der Red Hat JBoss Fuse Kernel liefert eine Runtime Umgebung, die Enterprise Support (Management, Protokollierung, Provisioning, Sicherheit), und seine eingebetteten Dienste liefern die Frameworks für die Implementierung dieser Komponenten der Lösung:
  • Routing und Integrationsdienst zum Erstellen von Routen, die dynamisch die Inhalte abgelegter XML-Dateien prüfen, um die passende Destination zu ermitteln.
  • Integration mit der Google App Engine die die Anzahl der Schulen in der Umgebung ermittelt und die zur Aktualisierung des geschätzten Wertes jedes Hauses verwendet wird.
  • RESTful Dienst-zur Bereitstellung aller Daten mit dem aktualisierten Schätzwert an den Anbieter.
1.3.2.3.2. »Loans Consolidated« Integrationsfluss
Mehrere Verkäufer platzieren ihre XML-Dateien (1) in einem Verzeichnis entweder über einen FTP-Server oder einen Batch-Job über Nacht. Diese Dateien werden in einen auf Inhalten basierenden Router (2) gelesen, der die Dateien trennt, je nachdem ob sie Haus- oder Kundeninformationen enthalten.
Nach dem Trennvorgang werden die Kundeninformationen enthaltenden Dateien in eine arbeitsspeicherinterne Warteschlange platziert (3) ehe sie für Persistenz an eine Backend-Datenbank gegeben werden (6).
Die die Hausinformationen enthaltenden Dateien werden in einer separaten Warteschlange platziert (4) ehe der Wert geschätzt (5). Als Teil dieser Berechnung wird der Standort an die Google App Engine (7) gegeben, die nahe gelegene Schulen ermittelt, um den Schätzwert zu liefern. Der Schätzwert wird in der Backend-Datenbank gespeichert (6).
Ein RESTful Webdienst (8) wird zur Weitergabe der Information von der Datenbank in einem JSon-Format gegeben, so dass Anbieter diese bequem abrufen können.
Nach oben
Red Hat logoGithubredditYoutubeTwitter

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Wir helfen Red Hat Benutzern, mit unseren Produkten und Diensten innovativ zu sein und ihre Ziele zu erreichen – mit Inhalten, denen sie vertrauen können. Entdecken Sie unsere neuesten Updates.

Mehr Inklusion in Open Source

Red Hat hat sich verpflichtet, problematische Sprache in unserem Code, unserer Dokumentation und unseren Web-Eigenschaften zu ersetzen. Weitere Einzelheiten finden Sie in Red Hat Blog.

Über Red Hat

Wir liefern gehärtete Lösungen, die es Unternehmen leichter machen, plattform- und umgebungsübergreifend zu arbeiten, vom zentralen Rechenzentrum bis zum Netzwerkrand.

Theme

© 2025 Red Hat