Ich übernehme ein Projekt, um ein altes Legacy-System von Grund auf zu ersetzen. Bevor ich dazu kam, beauftragte das Unternehmen einen Berater, der eine grundlegende Skizze des Systems erstellte und SOA stark vorantrieb. Dies führte zu einer langen Liste von "Entity Services" mit der Absicht, sie zu komplexeren Dienstleistungskombinationen zusammenzufassen. Zum Beispiel würde ein Benutzer, der Informationen zu Ausschüssen wünscht, den Dienst "Ausschuss" treffen, der dann den Dienst "Person" aufruft, um seine Mitglieder zu erhalten, und den Dienst "Besprechung", um seine Besprechungen zu erhalten, und so weiter.
Ich verstehe die Flexibilitätsgewinne darin, aber meine Bedenken betreffen die Leistung. Es scheint mir, dass ein System, das mit einem so feinen Grad an Granularität für seine Dienste aufgebaut ist, zu viele Ressourcen für die Übersetzung von Dienstnachrichten ausgibt und die Leistung inakzeptabel ist. Es scheint mir auch, dass die Flexibilitätsgewinne immer noch mit einfachen wiederverwendbaren Objekten möglich sind, obwohl in diesem Fall der Nutzen einer Technologie-unabhängigen Schnittstelle verloren geht, um Leistung zu erzielen.
Weitere Hintergrundinformationen: Die Organisation, die diese Software anfordert, verfügt derzeit nicht über stabile Software-Suites von Drittanbietern, die eine Integration erfordern. Diese Software wird alle Suiten ersetzen. Es gibt derzeit auch keine externen Verbraucher, die außerhalb der bereitgestellten Website-Schnittstelle auf die Daten zugreifen müssen - alle Serviceanrufe stammen von anderen Teilen unseres Systems. Die Auswahl der SOA scheint in diesem Fall vollständig auf dem Konzept der "Vorbereitung" zu beruhen.
Also meine Frage - welches Maß an Granularität ist akzeptabel in einem stabilen Dienst ohne Leistungseinbußen? Bin ich zu skeptisch gegenüber den Performance-Hits, die wir implementieren, wenn wir alle unsere Entitäten als Services implementieren? Sollte die Funktionalität nur dann als Web-Service zur Verfügung stehen, wenn sie benötigt wird, wobei der Schwerpunkt "Vorbereitung" stattdessen auf die Gestaltung der Business-Schicht für die Wahrscheinlichkeit der späteren Absetzung von Services gelegt wird?
Zunächst ist es schwierig, den "Sweet Spot" in der Anzahl der Dienste zu finden. Zu viele Services und Ihre Integrationskosten leiden zu wenig und Ihre Implementierungskosten leiden darunter. Du musst ein gutes Gleichgewicht finden.
Mein Rat an Sie ist, die Methode von Juval Lowy darin zu befolgen, dass Sie Ihre Dienste nach Bereichen aufteilen sollten Volatilität oder Bereiche der Veränderung. Dadurch erhalten Sie Ihre Granularität. Sie sollten auch sein WCF-Buch lesen , wenn Sie können.
Was die Leistung anbelangt, unterstützt WCF abhängig von Ihren Anwendungsfällen und Ihrer Hardware inhärent viele tausend Anrufe pro Sekunde. Dienste, die Dienste aufrufen, sind kein Problem. Die Plattform wird es unterstützen, wenn Sie Ihren Teil dazu beitragen. Verwenden Sie beispielsweise die richtige Bindung für das richtige Szenario (named Pipes, um Services auf demselben Computer aufzurufen, und TCP, um Services meh rere auf dem Computer aufzurufen, wo dies möglich ist). Sie sollten auch eine vertikale Schicht der Anwendung implementieren und Leistungstests durchführen, bevor Sie den Rest der Anwendung erstellen. Dies überprüft Ihre Architektur.
Wenn ich "Service" sage, meine ich die komplette vertikale Komponente, die eine vollständige unabhängige Operation ausführen kann. Und ich bevorzuge es nicht, detaillierter vorzugehen, es sei denn, es gibt außergewöhnliche Anforderungen. Aus meiner Sicht von SOA sollte ein Dienst die sinnvolle Geschäftsfunktion ausführen, die unabhängig ausgeführt werden kann. Ein Dienst sollte keinen anderen Dienst benötigen, um seine Funktion zu vervollständigen.
Welche Granularität ist in einem stabilen Dienst akzeptabel, ohne dass die Leistung beeinträchtigt wird?
Einzelne Entitäten. Wie vom Berater beschrieben.
Bin ich zu skeptisch gegenüber den Performance-Hits, die wir implementieren, wenn wir alle unsere Entitäten als Services implementieren?
Ja. Viel zu skeptisch.
Ein anständiges Framework kann einige dieser Anfragen optimieren, so dass sie nicht viel Netzwerk-Overhead beinhalten.
Wie bei SQL-Datenbanken sind die Probleme weitgehend gelöst. Sie werden feststellen, dass die zugrunde liegenden Anwendungen, die Sie als Dienste präsentieren, Engpässe sind. Die SOA-Schicht ist weitgehend plumbing. Die Bits müssen sich immer noch durch die Pipes bewegen, die SOA-Schicht organisiert sie nur intelligenter als die meisten Alternativen.
Sollen Services nur dann implementiert werden, wenn sie benötigt werden, während der Fokus "Vorbereitung" stattdessen auf die Gestaltung der Business-Schicht für die Wahrscheinlichkeit von Services gerichtet ist, die später darauf fallen gelassen werden?
Ja.
Das ist was Agil bedeutet.
Finde eine User Story. Erstellen Sie nur die Dienste (und Entitäten) für diese Geschichte.
Sie werden einen beträchtlichen Overhead für die ersten paar Geschichten haben, wenn Sie Ihr SOA-Framework als einen einfachen, wiederholbaren Release-Schritt platzsparend und verfügbar machen wollen.
Machen Sie niemals umfangreiche Vorbereitungen für Dinge, die Sie in einer unwahrscheinlichen Zukunft brauchen. Informieren Sie sich über Agile und wie Sie einen Rückstand priorisieren können.
Tags und Links architecture web-services soa granularity