Dienstintegration auf der Präsentationsschicht

Wie sind wir hier gelandet? Vor fünfzehn Jahren, am Ende des zweistufigen Client-Server-Zeitalters, begann man zu erkennen, wie wichtig es ist, in der Architektur zwischen mindestens drei verschiedenen Schichten zu unterscheiden. Eine Geschäftsschicht, die eine bequeme API bereitstellt, mit der Sie ein bestimmtes Geschäftsproblem angehen können, eine Datenschicht, die die zugehörigen Daten speichert, und eine Präsentationsschicht, die einen bequemen Benutzerdialog über der Geschäftslogik bereitstellt.

Irgendwann wurde klar, dass diese Art der Modularisierung nicht ausreichen würde. Wir mussten die Geschäftsebene modularisieren und "Dienste" für bestimmte Anliegen erstellen. Das ist das, was wir letztendlich hatten: In unserer neuen Welt hatten wir Dienste mit klaren Schnittstellen, und diese Dienste kommunizierten untereinander über klar definierte Schnittstellen (entweder lokal oder remote). Aber wir haben geschummelt. In den meisten Fällen konnten wir nicht herausfinden, wie wir die Konsistenz bewahren konnten, ohne uns auf die Bequemlichkeit von SQL-Lösungen zu verlassen. Also erlaubten wir eine gewisse "Integration" auf der Datenebene, d.h. wir speicherten alle Daten in einer einzigen Datenbank und täuschten im Wesentlichen isolierte Dienste auf dieser vor. Und dann - da wir immer noch in der Lage sein mussten, eine einzige integrierte Benutzeroberfläche zu präsentieren - schufen wir eine einzige Komponente für die Präsentationsschicht, die alles, was sie brauchte, aus der darunter liegenden Geschäftslogik bezog. Das Aufkommen von SOA veranlasste uns im Wesentlichen dazu, uns noch mehr auf die Dienstgrenzen zu konzentrieren. Und obwohl es verschiedene Denkansätze gab - und es gab tatsächlich einige Leute, die der Meinung waren, dass Serviceorientierung nichts mit Webservices zu tun hat - verlagerte sich der Schwerpunkt von einem Modularisierungsproblem zu einem Problem der Fernintegration. Es ging also im Wesentlichen darum, die verschiedenen bereits identifizierten Dinge noch weiter auseinander zu ziehen. Wenn Sie nun die Dienste wie oben dargestellt auseinanderziehen, wird die Verknüpfung mit einem einzigen Datenspeicher natürlich schmerzen. Das Gute an allem, was damals geschah, ist also, dass jeder begann, den Schmerz der Verknüpfung mit einem gemeinsamen Datenspeicher zu spüren. Die technischen Komplikationen zwangen die Menschen dazu, Dienste mit einer eigenen Datenschicht zu versehen und die 'Integration' auf eine Datenebene zu verlagern. Das mag nicht der ideale Grund dafür gewesen sein, aber der Nettoeffekt war folgender: Zu diesem Zeitpunkt begann man auch zu erkennen, dass ACID auf lange Sicht nicht ausreichen würde und dass wir andere Möglichkeiten zur Wahrung der Konsistenz in Betracht ziehen sollten. Damit war der Weg für NoSQL geebnet und das Wort von kompensierenden Transaktionen und Idempotenz verbreitet. Was haben wir also jetzt? Auf der Habenseite haben wir Dienste, die so gut wie voneinander isoliert sind (gut!). Allerdings ist die Integration mit der Benutzeroberfläche immer noch ein ziemlich großer Klumpen. Und aus irgendeinem Grund wird das als ganz in Ordnung angesehen. Aber ist es das wirklich? In vielen Fällen sind die Abhängigkeiten zwischen der Präsentationsschicht und der Geschäftslogikschicht ziemlich eng. Nehmen wir einen Zahlungsdienst als Beispiel. Was auch immer der Zahlungsdienst vom Benutzer verlangt, muss natürlich auch in der Präsentationsschicht eingegeben werden. Das Ersetzen eines Zahlungsdienstes durch eine andere Art von Zahlungsdienst wird höchstwahrscheinlich große Auswirkungen auf die Präsentationsschicht haben. Gleichzeitig ist der Rest des Dialogs, der dem Benutzer angeboten wird, wahrscheinlich völlig unabhängig von dem Dialog, der beim Umgang mit dem Zahlungsdienst präsentiert wird. Wenn wir also der Meinung sind, dass Dienste so weit wie möglich voneinander isoliert werden sollten (freie Interpretation von Parnas) und das, was offengelegt werden muss, auf ein absolutes Minimum beschränken sollten, warum nicht auch die Präsentationsschicht trennen? Integration von Diensten auf der Präsentationsschicht Aus irgendeinem Grund kommt die Idee einer auf der Präsentationsschicht basierenden Integration in einer Welt, die einst von der WS-Variante der SOA dominiert wurde, nicht besonders gut an. Mashups sind jedoch im Internet allgegenwärtig. Sie werden nur oft nicht als Möglichkeit zur Integration von Diensten innerhalb eines einzigen Systems in einem einzigen Unternehmen betrachtet.Die Organisation Ihrer serviceorientierten Architektur, wie sie oben beschrieben wurde, ähnelt in gewisser Weise den Ideen, die Allen Holub vor mehr als einem Jahrzehnt geäußert hat, damals allerdings in einem größeren Maßstab. Die zentrale Botschaft in seinem Artikel war, dass man verhindern sollte, dass Objekte zu viel von ihrem eigenen internen Zustand preisgeben, indem man Objekte dafür verantwortlich macht, eine UI-Darstellung von sich selbst bereitzustellen. Das klingt nach einer schrecklichen Idee im Sinne des Modells, das eine strikte Trennung zwischen Präsentationsschicht und Geschäftslogikschicht vorsieht, aber ich denke, dass es in einer dienstorientierten Architektur durchaus Sinn macht.Zurück zum Beispiel des Zahlungsdienstes: Nehmen wir einmal an, dass der linke Dienst ein Einkaufsservice ist (einschließlich des Dialogs mit dem Benutzer in der Präsentationsschicht) und dass der rechte Dienst der Zahlungsdienst ist. Die Integration der Dienste würde sowohl eine Integration auf der Präsentationsschicht als auch auf der Geschäftslogikschicht erfordern.Wenn der Benutzer eine Zahlungsmethode auswählt, die mit einem bestimmten Zahlungsdienst verknüpft ist, sollte die Präsentationsschicht des Zahlungsdienstes aufgerufen werden und Hinweise darauf geben, was zu tun ist, wenn die Zahlung erfolgreich war oder nicht. Von diesem Zeitpunkt an hat der Zahlungsdienst selbst die Kontrolle über (einen Teil) des Dialogs.Wenn die Zahlung abgeschlossen ist, gibt die Präsentationsschicht des Zahlungsdienstes die Kontrolle an die Präsentationsschicht des Einkaufsdienstes zurück. Die Geschäftslogikschicht kann jedoch weitere Informationen über den Status einer Zahlung über den vom Einkaufsservice definierten SPI übermitteln. (Wie z.B. abrechnungsbezogene Informationen.) Konsequenzen Indem Sie die Präsentationsschicht als Teil des eigentlichen Dienstes betrachten, führen Sie eine Reihe neuer Freiheitsgrade ein. Zunächst einmal haben Sie, je nachdem, wie die Integration in die Präsentationsschicht erfolgt, die Möglichkeit, einen Teil des Benutzerdialogs im selben Adressraum wie die Geschäftslogik auszuführen. Anstatt mehrere Remote-Aufrufe zu tätigen, um alle Daten für die Präsentation für den Benutzer zusammenzustellen, würde die Präsentationsschicht all diese Aufrufe intern durchführen und dann die resultierende Präsentation an den Ort liefern, an dem sie mit den anderen Komponenten des Präsentationsteils integriert wird. Auf diese Weise könnten Sie die Vorteile der räumlichen Lokalisierung nutzen. Ein weiterer Vorteil, der bereits erwähnt wurde, ist die Tatsache, dass Sie einen Dienst einfach zerreißen und ersetzen können. Sie müssen sich nur um die Schnittstellen der Präsentations- und Geschäftslogikschicht kümmern, nicht um das, was tatsächlich hinter diesen Schnittstellen passiert. Denken Sie an Field Replaceable Units (FRUs), aber dann mit Software. Gegenargumente Das Gegenargument für die Integration der Präsentationsschicht ist, dass Sie die Schnittstellen der Präsentationsschicht für jede neue Art von Präsentation, die Sie anvisieren, im Grunde neu erstellen müssten. Ich neige dazu, dem nicht zuzustimmen, und da es sich hier nur um einen Blogbeitrag handelt, werde ich versuchen, mich davon zu lösen, indem ich zunächst nur um einen Beweis dafür bitte. Implementierung In "Understanding UI Integration" aus dem Jahr 2007 geben die Autoren einen Überblick über den aktuellen Stand der UI-Integration. Sie sprechen im Wesentlichen über Browser-Plugin-Komponenten, Mashups, Portlets und WSRP (was eine der Möglichkeiten wäre, die oben beschriebenen Vorteile der räumlichen Lokalisierung zu erreichen). Allerdings stellen sie Folgendes fest:

"Obwohl die hier beschriebenen Bemühungen sicherlich nützlich sind, glauben wir, dass eine wirksame Standardisierung ähnlich wie bei der Standardisierung von Service-Schnittstellen erforderlich ist, damit die UI-Integration wirklich durchstarten kann. Im Allgemeinen sehen wir einen Mangel an Abstraktion, um kompositionsorientierte Funktionen im Kontext der UI-Integration zu konzeptualisieren."

Ich denke, das gilt auch heute noch. Es gibt vielleicht ein paar Initiativen, die die Grenzen ein wenig weiter hinausschieben(OpenSocial fällt mir da ein), aber es gibt keine klare Richtung. Was ist also Ihre Meinung dazu? Halten Sie Dienste mit einer Präsentationsschichtschnittstelle für einen Fehler oder für entscheidend für echte serviceorientierte Architekturen? Und wenn Sie Dienste haben, die eine Schnittstelle zur Präsentationsschicht anbieten, welche Prinzipien haben Sie dann, um das Ganze zu organisieren?