Das Orchestriert-Serviceorientierte-Architekturmodell: Eine Überlegung zur Wiederverwendbarkeit

Was die Orchestriert-Serviceorientierte Architektur kann

In der Welt der Softwarearchitektur gibt es verschiedene Modelle, die auf unterschiedliche Anforderungen und Ziele abzielen. Ein solches Modell ist das Orchestriert-Serviceorientierte-Architekturmodell, das eine klare Trennung von Geschäftslogik und Diensten vorsieht. In diesem Blogpost werfen wir einen genauen Blick auf dieses Architekturmodell, seine Komponenten und diskutieren Vor- und Nachteile.

Die Einstiegsschicht dieser Architektur besteht aus Business Services, die domänenspezifisch unterteilt sind. Diese Businessservices setzen sich aus vereinfachten Methoden, den sogenannten Enterprise Services, zusammen. Die Trennung dieser Dienste zielt auf Wiederverwendbarkeit ab. Mehrere Businessservices können die gleichen Enterprise Services nutzen. Zusätzlich gibt es einmalig implementierte Applikationsdienste sowie Infrastrukturdienste, die für Logging, Monitoring, Authentifizierung und Autorisierung zuständig sind. Die Orchestrierungs-Engine fungiert als Bindeglied zwischen den Businessservices und den Enterprise Services und bestimmt die Beziehung zwischen Geschäftslogik und Unternehmensdiensten.

Obwohl die Idee der Wiederverwendbarkeit in der Theorie attraktiv erscheint, kann sie in der Praxis zu Schwierigkeiten führen. Eine Änderung an einem Enterprise Service, wie beispielsweise „createCustomer()“, kann Auswirkungen auf andere Business Services haben, die diese Funktion ebenfalls benötigen. Dies führt zu einer starken Kopplung und erschwert effiziente Entwicklungsprozesse im Vergleich zu beispielsweise Microservices.

Es ist wichtig zu beachten, dass das Business-Service-Architekturmodell heutzutage nicht mehr weit verbreitet ist und in den meisten modernen Softwareanwendungen nicht mehr verwendet wird. Dies liegt zum Teil daran, dass die Testbarkeit und Bereitstellbarkeit zu der Zeit, als dieser Stil entwickelt wurde, keine vorrangigen Ziele waren. Es gibt jedoch bestimmte Anwendungsfälle, in denen dieses Modell immer noch relevant sein kann, insbesondere in Legacy-Systemen oder spezifischen Domänen, in denen die Wiederverwendbarkeit von Diensten von entscheidender Bedeutung ist.

Ein Vorteil dieses Architekturmodells liegt in der Skalierbarkeit durch Sessionreplikation. Dadurch können große Lastspitzen bewältigt werden. Jedoch weist das Modell auch einige Nachteile auf. Die Testbarkeit und Bereitstellbarkeit sind oft schlecht, da diese Aspekte bei der Entwicklung nicht im Vordergrund standen. Darüber hinaus kann die Orchestrierungs-Engine als zentraler Kopplungspunkt zum Flaschenhals werden.

Fazit

Das Business-Service-Architekturmodell bietet eine interessante Perspektive auf die Trennung von Geschäftslogik und Diensten. Obwohl es einige Vorteile wie Skalierbarkeit aufweist, sollten die Herausforderungen und Probleme bei der Umsetzung berücksichtigt werden. In der heutigen Zeit bevorzugen viele Entwickler andere Architekturstile wie Microservices, die flexibler und besser skalierbar sind. Dennoch kann das Business-Service-Architekturmodell in bestimmten Legacy-Systemen oder spezifischen Domänen weiterhin seine Berechtigung haben. Die Entscheidung für das richtige Architekturmodell hängt letztendlich von den individuellen Anforderungen und Zielen des Projekts ab.

Zusammenfassung

Die wichtigsten Merkmale dieses Stils haben wir für Sie kurz und knapp als Bild zusammengefasst.

Disclaimer: Der Architektur-Spicker basiert zu großen Teilen auf dem Buch Handbuch moderner Software-Architektur von O’Reilly. Für tiefergehende Informationen empfehlen wir dieses Buch zu kaufen.