Warum sollten Sie Services (REST / SOAP) anstelle einer Bibliothek verwenden?

Angenommen, Sie möchten Ihre Anwendungen in Services aufteilen. Gibt es gute Gründe für einen SOA-Ansatz, anstatt nur eine Bibliotheks-API zu erstellen, die von den Anwendungen geladen werden kann, die sie benötigen?

Der Unterschied kann zwischen beiden subtil sein. In der .NET-Welt haben Sie möglicherweise eine Anwendung, die sich für einen Endbenutzer monolithisch anfühlt und auf demselben Computer ausgeführt wird, die sich jedoch in eine Reihe von WCF-Diensten aufteilt. Möglicherweise gibt es auch Architekturen, in denen Bibliotheken nicht stark miteinander verknüpft sind (Add-Ins / Plug-Ins) und nur einem Protokoll folgen, wenn sie miteinander kommunizieren.

Wenn wir diese Zwischenfälle vermeiden und nur stark verknüpfte API-Bibliotheken im Vergleich zu einem separaten REST-Service behandeln, sollten Sie möglicherweise folgende Punkte berücksichtigen:

1. Eine Bibliotheks-API wird auf demselben Computer aufgerufen. Services können überall gehostet und von überall aufgerufen werden. Wenn Sie aus Gründen der Leistung / Skalierbarkeit / Sicherheit damit rechnen, die Anwendung auf mehreren Computern zu hosten, müssen Sie möglicherweise Dienste nutzen.

2. Ähnlich verhält es sich mit der Verwendung eines Dienstes durch eine Anwendung, die auf mehreren Computern bereitgestellt wird. Wenn Sie beispielsweise eine Anwendung für eine Bank ausführen, die einige finanzielle Berechnungen vornimmt, besteht eine Möglichkeit darin, die gesamte große Anwendung auf jedem Desktop bereitzustellen und jedes Mal große Aktualisierungen für jeden Client durchzuführen. Ein anderer Ansatz besteht darin, einen Rechenteil auf Servern zu hosten und auf den Desktops nur eine kompakte App mit nur einer Benutzeroberfläche und einer Reihe von Aufrufen an diese Server bereitzustellen.

3. Wenn Sie einen REST-Dienst hosten, kann ihn jeder verwenden: ein Mac-Benutzer, eine Person, die Linux verwendet usw. Wenn Sie mit Visual Studio eine C # -Bibliothek erstellt und als DLL verteilt haben, vergessen Sie die Benutzer (Kunden) ?) wer hat kein Windows.

Ein weiterer Vorteil von Diensten besteht darin, dass sie beim Aktualisieren des Dienstes sofort für alle Benutzer des Dienstes bereitgestellt werden. Wenn Sie also einen Fehler oder ein Leistungsproblem behoben haben, hat jeder den Vorteil, sobald der aktualisierte Dienst verfügbar ist, anstatt ein Update zu verteilen, das möglicherweise ignoriert wird.

Bibliotheksvorteile:

• Geringerer Overhead pro Anruf (nur Jump oder sogar Inline ) = kann die Leistung steigern
• Einfachste Sache, die möglicherweise funktionieren könnte
• Kein Risiko, dass der zentrale Service ausfällt und alle Verbraucher beeinträchtigt

Servicevorteile:

• Jeder erhält sofort und transparent Upgrades (sofern nicht eine versionierte API angeboten wird)
• Verbraucher können den Code nicht dekompilieren
• Kann Service-Hardware separat skalieren
• Technologieunabhängig. Bei einer gemeinsam genutzten Bibliothek müssen Verbraucher eine kompatible Technologie verwenden.
• Sicherer. Die Benutzeroberflächenebene kann den Dienst aufrufen, der sich hinter einer Firewall befindet, anstatt direkt auf die Datenbank zuzugreifen.

Ein SOA-Ansatz ermöglicht es, die verschiedenen Dienste separat zu hosten und zu warten. Zusätzlich zum Code erfordert die Bereitstellung eines bestimmten Dienstes möglicherweise viele spezielle Konfigurationsschritte (Kennwörter, Ports, Zertifikate usw.). Die Inanspruchnahme eines REST-Service hat eine endliche Komplexität, die klar dokumentiert und leicht verständlich ist. Es ist auch sicherer, da Sie den Clients keinen Zugriff auf DBs oder andere Ressourcen gewähren müssen.

Wenn sich ein SOA-Service ändert, muss dieser SOA-Service neu entwickelt, erneut getestet und erneut bereitgestellt werden. Alle Anwendungen, die diesen Dienst in Anspruch nehmen, können dies weiterhin tun. Eine Änderung an einer Bibliothek in einer DLL bedeutet, dass alle Benutzer dieser Bibliothek neu entwickelt werden müssen, um auf diese DLL zu verweisen. Sie müssen alle erneut getestet und alle erneut bereitgestellt werden. Es besteht auch die Gefahr, dass dies nicht ordnungsgemäß geschieht und unterschiedliche Anwendungen unterschiedliche Versionen der DLL haben. Manchmal ist das aber kein Problem sein - vielleicht sollte jedes System die Version der Bibliothek, die zum Zeitpunkt der Bereitstellung vorlag (Sie können Ihre Logging - System aktualisiert hilfreiche neue Funktionen haben - tun Sie wirklichMüssen Sie jedes System damit aktualisieren?) In diesem Fall ist eine Bibliothek in Ordnung. Angenommen, Sie haben einen Dienst zur Berechnung des Steuersatzes, und die Steuergesetze ändern sich. Sie möchten nicht jedes System aktualisieren müssen, um diese Änderung zu übernehmen, es ist besser, sie an einem Ort auszuführen. In diesem Fall ist ein Service die bessere Option.

Es gibt mehrere gute Antworten, aber ich möchte den gegebenen Antworten weitere Dinge hinzufügen:

Die API-Bibliotheksmethode ist sehr nützlich, wenn Sie mit möglichst wenig Aufwand mit Dingen interagieren möchten. Die Folge ist eine stärkere Kopplung zwischen der API und den Anwendungen, die sie verwenden. Manchmal ist dies für die Anwendung in Ordnung und sogar notwendig. Wenn Sie jedoch ein sehr verteiltes System haben oder wenn Sie der Meinung sind, dass die Interoperabilität ein großes Problem darstellt, müssen Sie möglicherweise einen Schritt weiter gehen und andere Kommunikationsmethoden verwenden. Insbesondere wenn Sie ein verteiltes System haben möchten, ist SOAP eine Art nächster Schritt in der SOA, aber Sie werden immer noch mit der Abhängigkeit zwischen den Einheiten belassen, da sie sich gegenseitig kennen müssen. REST bringt es auf eine neue Ebene, indem eine Maschine auf einheitliche Weise etwas über den Inhalt der anderen Services lernen kann.

In Ihrem Fall sehe ich keinen Grund, Ihre Anwendung in SOA umzuwandeln, wenn Ihre Anwendung nicht verteilt wird.