Sind Middleware-Apps für die Geschäftslogik erforderlich?

Question

Angenommen, ich verfüge über eine große Middleware-Infrastruktur, die Anfragen zwischen verschiedenen Geschäftskomponenten (Kundenanwendungen, Netzwerk, Zahlungen usw.) vermittelt. Der Middleware-Stack ist verantwortlich für Orchestrierung, Routing, Transformation und anderes (ähnlich dem Enterprise Integration Patterns-Buch von Gregor Hohpe).

Meine Frage ist: Ist es gutes Design, um einige Geschäftslogik auf die Middleware zu setzen?

Angenommen, meine App A fordert einige Kundendaten von der Middleware an. Aber um diese Daten zu erhalten, muss ich Kundennummer und einige anderen Parameter liefern. Das Abrufen dieses Parameters sollte von der anfordernden App durchgeführt werden oder ist die Middleware verantwortlich für die Bereitstellung einer Schnittstelle, die Kunden-IDs empfängt und intern den anderen Parameter abruft?

Ich weiß, dies ist keine einfache Frage (wegen der Definition der Geschäftslogik), aber ich frage mich, ob es eine allgemeine Vorgehensweise oder einige Richtlinien ist.

Answer 1

Dies ist das "Composite Application" -Muster; das Herz einer serviceorientierten Architektur. Das ist, was die ESB-Anbieter verkaufen: eine Möglichkeit, zusätzliche Business-Logik irgendwo, die eine Composite-Anwendung aus bestehenden Anwendungen erstellt.

Dies ist nicht einfach, da Ihre Verbundanwendung nicht nur Routing ist. Es ist eine richtige neue zusammengesetzte Transaktion, die auf dem Routing überlagert ist.

Hinweis. Sehen Sie sich einen guten ESB an, bevor Sie zu viel weiter gehen. Dies gerät schnell außer Kontrolle und zusätzliche Unterstützung ist hilfreich. Selbst wenn Sie nicht so etwas wie Suns JCAPS oder Open ESB kaufen, werden Sie froh sein, dass Sie gelernt haben, was es tut und wie komplexe Composite-Anwendungen organisiert werden.

Answer 2

Die Middleware-Anwendung sollte es tun. System A sollte keine Ahnung haben, dass der andere Parameter existiert, und wird sicherlich keine Ahnung haben, wie es zu bekommen ist.

Answer 3

Orchestrierung, Routing und Transformation.

Sie tun keine dieser aus technischen Gründen, zufällig oder nur zum Spaß, Sie tun dies, weil Sie einige Geschäftsanforderungen haben - ergo gibt es Geschäftslogik beteiligt.

Das einzige, was Sie für ein komplettes Business-System vermissen, ist die Berechnung und das Reporting (nehmen wir an, Sie haben bereits Sicherheit!).

Abgesehen von sehr niedrigen Netzwerk-, Betriebssystem- und Speicherproblemen ist fast alles vorhanden, was ein Computersystem umfasst, weil das Geschäft/die Regierung/Endbenutzer es dort haben wollen.

Die Wahl von 'Business Logic' als Terminolgie war sehr schlecht und hat zu endlosen Verzerrungen von Design und Architektur geführt.

Was die meisten guten Designer/Architekten mit Geschäftslogik meinen, ist Berechnung und Analyse.

Wenn Sie "% s/Business Logik/Berechnung/g" die meisten architektonischen Verordnungen sinnvoller machen.

Answer 4

Neben dem Routing, der Transformation und Orchestrierung sollte die Leistung beim Laden von Middleware mit funktionalen Anforderungen berücksichtigt werden. Middlware sollte nur einen Bruchteil der gesamten End-to-End-Transaktionslebensdauer in Anspruch nehmen. Dies kann nur erreicht werden, indem man sich auf die Middleware-Kernfunktionalitäten konzentriert, anstatt zu versuchen, die Hostsystemfunktionalitäten zu ergänzen.