Blog

Alle Beiträge mit dem Tag Service

Der UBER Service

Antipattern-Kalender 2016 – Der UBER-Service

Baut man Software in einer bestehenden Landschaft, ist die Service-Orientierung ein Segen. Man muss nicht alles selbst bauen und kann Bestehendes wiederverwenden. Aber kennt Ihr das auch? Man will nur kurz die Postleitzahl zu einer Adresse ermitteln und der entsprechende Service steht sogar bereit, doch die Adresse kann nur für einen Auftrag eingegeben werden. Diesen hat man aber bei dem fachlichen Szenario gar nicht parat. Theoretisch könnte man ja mit einem Dummy-Auftrag arbeiten, doch auch der benötigt einen Kunden im Kundenstamm. Und so weiter, entlang der ewigen Liste der Abhängigkeiten. Wie man sich auch bemüht, ist der Service irgendwie zu groß und die Anbindung daran eine Qual.
weiterlesen

Immer das Gleiche mit der Idempotenz!

Idempotenz ist beim Aufbau einer Serviceorientierten Architektur ein häufig gefordertes Pattern bei der Gestaltung der Services. Ein Service ist idempotent, wenn er die Fähigkeit besitzt, damit umzugehen, dass Nachrichten mehrfach zugestellt werden. Er soll sich bei wiederholten Aufrufen mit denselben Parametern identisch verhalten, ohne dabei Schaden anzurichten. Im Klartext heißt das: Wird ein Service mit denselben Parametern zweimal aufgerufen, soll er denselben Zustand hinterlassen.

Diese Forderung klingt erstmal vernünftig. Um eine solches Verhalten zu erzielen, werden gelegentlich Idempotenz-Frameworks geschaffen, die Service-Aufrufe und deren Ergebnisse cachen. Wird dann der gleiche Aufruf nochmal durchgeführt, wird einfach das gecachte Ergebnis zurückgeliefert, anstatt die Verarbeitung ein weiteres Mal anzustoßen. Warum ein solcher Weg aber besonders im Kontext vom BPM und Prozessautomatisierung gefährlich ist, möchte ich an einem Praxisbeispiel erläutern.

weiterlesen

Persistenz, Transaktionsgrenzen und Optimistische Locking-Strategie

Die erste Regel der verteilten Systeme lautet: verteile nicht die Systeme. In der Tat kann die Architektur eines monolithischen Systems auf wesentliche komplexe Fragestellungen verzichten, die in der Architektur des verteilten Systems eine entscheidende Rolle spielen. Manche funktionale Anforderungen lassen sich jedoch nur sehr schwer in einem monolithischen System realisieren, so dass eine verteilte mehrschichtige Anwendung mit einem Server und einem (Rich-) Client entsteht. Eine mögliche, nicht seltene Variante ist die Bereitstellung von Funktionalität über eine Serviceschicht, die vom Client aus benutzt wird. Der Entwurf von funktionalen Service-Schnittstellen ist ein wichtiger Schritt in der Entwicklung der Mehrschichtanwendung. Auch für den Aufbau der serviceorientierten Architektur ist die Frage des Schneidens der Services von zentraler Bedeutung. Es ist ein Balanceakt zwischen fein- und grobgranular, zustandslos und zustandbehaftet, synchron und asynchron, transaktional und fire-and-forget.

Architektur

Ein nicht-untypisches Design einer Mehrschichtapplikation ist mit einem Boundary-Control-Entity Architekturpattern beschrieben.
weiterlesen