Die 10 größten SOA-Fallstricke: #7 - Falsche Granularität der Dienste

Nachdem wir #8: Sicherheit besprochen haben, lassen Sie uns zu #7 übergehen. Eine falsche Granularität kann bedeuten, dass ein Dienst zu viel oder zu wenig Funktionalität abdeckt. Eine falsche Granularität der Dienste in Ihrer SOA kann zu schlechter Leistung, geringen Wiederverwendungsmöglichkeiten, undichten Abstraktionen und Diensten ohne geschäftlichen Mehrwert führen. . Häufige Ursachen dafür sind Bottom-up- und/oder Top-down-Design und eine zu enge Perspektive (Projekt- statt Unternehmensumfang). In diesem Blog werfen wir zunächst einen genaueren Blick auf die zuvor genannten Symptome und ihre Ursachen. Und dann erklären wir Ihnen, warum die Lösung darin liegt, bei der Entwicklung von Dienstleistungen eine Unternehmensperspektive einzunehmen.

Zunächst die Symptome, die darauf hinweisen könnten, dass die Dienste in einer SOA nicht die richtige Granularität haben:

• Sie sind nicht in der Lage, den Geschäftsleuten (z.B. Vertrieb/Marketing) zu erklären, was der Service leistet. Er passt einfach nicht zu ihrem Verständnis des Geschäfts, in dem das Unternehmen tätig ist. Die Dienstleistungen sind so detailliert, dass sie aus geschäftlicher Sicht irrelevant sind.
• Es werden viele verschiedene Dienstleistungen benötigt, um etwas von Wert für das Unternehmen zu erreichen.
• Die Verwendung von Diensten in der SOA führt zu einer enormen Menge an winzigen Interaktionen zwischen Systemen und die Leistung des gesamten Prozesses ist sehr langsam.
• Dienste sind Variationen der grundlegenden CRUD-Vorgänge (Erstellen, Lesen, Aktualisieren, Löschen) und bieten keinen zusätzlichen funktionalen Wert zu den grundlegenden CRUD-Vorgängen.
• Dienstdefinitionen legen offen, wie der Dienst implementiert wird. Aus der Dienstdefinition können Sie zum Beispiel ableiten, dass ein Dienst eine bestimmte Datenbank verwendet.
• Von den verfügbaren Diensten wird kaum ein Dienst mehr als einmal genutzt. Jeder Dienst scheint an eine bestimmte Anwendung gebunden zu sein. Das könnte bedeuten, dass die Dienste zu grobkörnig sind, weil sie eine Reihe von Funktionen umfassen, die nur von einer (oder wenigen) Anwendung(en) genutzt werden.
• Es gibt keine klaren Eigentumsverhältnisse für den Service, mehrere Abteilungen meinen, dass sie den Service (oder Teile davon) besitzen sollten.
• Viele Schichten von zusammengesetzten Diensten. Die Dienste der obersten Ebene können in diesem Fall Schnittstellen mit der richtigen Granularität aufweisen, aber sie sind aus Diensten mit einer falschen Granularität zusammengesetzt. Diese falsche Granularität wird oft durch eines der oben genannten Symptome verursacht und es werden zusätzliche, unnötige Kompositionen erstellt, um dies zu kompensieren.

Welche Arten von Fallstricken führen also zu diesen Symptomen?

• Beim Bottom-Up-Design gibt es eine Reihe von Fallstricken. Wenn zum Beispiel bestehende Systeme mit der SOA verbunden werden, ist es verlockend, die API dieses Systems zu nehmen und die Operationen in dieser API als Dienste in der SOA darzustellen. Das ist einfach zu machen, aber diese Dienste haben keine geschäftliche Bedeutung, sind möglicherweise zu feinkörnig (CRUD-Dienste sind das offensichtlichste Beispiel) und neigen dazu, Implementierungsdetails preiszugeben. Ein weiteres Beispiel für Bottom-up-Design ist, wenn mehrere Abteilungen (oder Projekte) mit ähnlichen Funktionen arbeiten und nicht voneinander wissen (oder schlimmer noch, sie wollen einfach nicht kommunizieren, siehe auch Not Invented Here-Syndrom). Jede Abteilung oder jedes Projekt betrachtet nur ihre eigene Perspektive und das führt dazu, dass ähnliche Dienste mehrfach entwickelt werden.
• Auf der anderen Seite ist Top-Down-Design nicht das Heilmittel gegen Bottom-Up-Design. Wenn Dienste von oben nach unten entworfen und in Dienste untergeordneter Ebenen zerlegt werden, die wiederum weiter nach unten zerlegt werden, erhalten Sie häufig eine Vielzahl von Diensten, die nur in diesem Teil des Zerlegungsbaums verwendet werden können. In verschiedenen Zweigen des Baums können ähnliche Dienste definiert sein und Dienste in einem Zweig sind mit anderen Diensten in diesem Zweig gekoppelt.
• Theoretisches Service Design ist eine weitere Ursache. Architekten oder Designer im Elfenbeinturm entwerfen Dienste, ohne sich von konkreten Projekten und/oder Geschäftsprozessen leiten zu lassen. Dies führt in der Regel zu Diensten, die so allgemein gehalten sind, dass kein konkretes Projekt sie ohne Änderungen verwenden kann. Jedes Projekt erfordert Änderungen an den Service-Definitionen, um sie nutzbar zu machen, was wiederum zu vielen Variationen ähnlicher Services führt.

Welches ist der richtige Grad der Service-Zerlegung?

• Ein Dienst sollte in die kleinste wiederverwendbare Einheit zerlegt werden und gleichzeitig für die Geschäftsinhaber verständlich sein. Eine andere Möglichkeit, die optimale Größe zu definieren, besteht darin, dass der Dienst keine Gruppierung von feineren Diensten sein sollte, die nicht als separate Dienste verfügbar sind. So bleibt die Möglichkeit offen, Dienste aus anderen Diensten zusammenzustellen.
• Außerdem ist es wichtig, dass eine einzige Rolle im Unternehmen der Eigentümer des Dienstes ist (natürlich können mehrere Rollen den Dienst nutzen). Dienste, die zu sehr in verschiedene Richtungen gehen, lassen sich nur schwer einem Eigentümer zuordnen, was zu unklaren Eigentumsverhältnissen führt (auf die wir später in dieser Top 10 noch näher eingehen werden).
• Und schließlich sollte der Dienst so autonom wie möglich sein. Wenn jemand einen Dienst nutzen möchte, sollte er nicht gezwungen sein, auch andere Dienste zu nutzen (beachten Sie, dass die Implementierung des Dienstes andere Dienste nutzen kann).

Die richtige Granularität der Dienste zu finden, ist nicht so einfach wie das Befolgen eines Rezepts. Es ist ein Balanceakt, der Wissen, Erfahrung und das Ausprobieren verschiedener Optionen erfordert. Entwerfen Sie Ihren Dienst anhand der obigen Richtlinien, spielen Sie eine Reihe von Szenarien durch und sehen Sie, ob eines der genannten Symptome auftaucht. Wenn ja, überdenken Sie es... Nächste Woche wird Rik de Groot mit Fallstrick Nr. 6 fortfahren.