Erlang / OTP-Architektur: REST-konformes Protokoll für SOAish-Dienste

Ich würde den dritten Weg einführen, der eher kosteneffektiv und reaktiv ist. Die Architektur sollte auf jeden Fall serviceorientiert sein, da Sie explizit Services haben. Es ist jedoch nicht erforderlich, jeden Dienst als Restful- oder WSDL-definierter Dienst verfügbar zu machen. Ich bin kein Erlang-Entwickler, aber ich glaube, es gibt eine Möglichkeit, lokale und Remote-Prozesse per Messaging aufzurufen und somit unnötige Serialisierungs- / Serialisierungsaktivitäten für interne Anrufe zu vermeiden. Aber eines Tages wirst du mit einem neuen Integrationsproblem konfrontiert sein. Zum Beispiel werden Sie ein Buchhaltungs- oder Logistiksystem integrieren. Wenn Sie die Architektur dann in Bezug auf SOA-Prinzipien gut entworfen haben, werden die meisten Anstrengungen damit verbunden sein, vorhandene Services mit REST-fähigen Front-End-Wrappern zu offenbaren, ohne dass bestehende Verbindungen zu anderen Services umgestaltet werden müssen. Aber das Problem besteht darin, den Zuständigkeitsbereich sauber zu halten. Ich meine, jeder Dienst sollte für die Aktivität verantwortlich sein, die er ursprünglich entworfen hat.

Das von Ihnen erwähnte Sicherheitsproblem ist bekannt. Sie sollten Authentifizierung / Autorisierung in allen exponierten Diensten haben, zum Beispiel mit Token.

Bei SOA ist zu beachten, dass es in der Architektur nicht um die Technologie geht (REST, WS *). So können Sie bei Bedarf eine gute SOA mit Endpunkten verschiedener Typen erhalten (was ich eine Edge-Komponente nenne) - Trennung von Geschäftsprozessen Logik aus anderen Bereichen wie Kommunikation und Protokolle) Außerdem ist es wichtig zu beachten, dass die Service-Grenze eine Vertrauensgrenze ist. Wenn Sie sie überschreiten, müssen Sie sich möglicherweise authentifizieren und autorisieren, das Netzwerk kreuzen usw. Außerdem sollte die Trennung in Schichten (wie Daten und Logik) nicht so funktionieren, wie Sie sie partitionieren Dienstleistungen.

Nach dem, was ich in Ihren Fragen lese, würde ich die Dienste wahrscheinlich in grobkörnigere Dienste aufteilen (siehe unten). Kommunikation innerhalb der Grenzen des Dienstes kann unabhängig von der Art sein, in der die Kommunikation zwischen Diensten eine öffentliche API verwendet (REST oder Erlang-native liegt bei Ihnen, aber der Punkt ist, dass sie verwaltet, versioniert, gesichert usw. ist) Der Dienst kann Endpunkte in mehreren Technologien haben, um verschiedene Benutzer zu unterstützen (manchmal verwenden Sie einen ESB, um zwischen Diensten und Protokollen zu vermitteln, aber die Notwendigkeit dafür hängt von der Größe und Komplexität Ihres Systems ab)

In Bezug auf Ihre spezifischen Fragen

• 1 Wie oben erwähnt, denke ich, dass es einen Ort gibt, an dem mehr öffentliche APIs verfügbar gemacht werden als nur einen einzigen Einstiegspunkt, bin ich mir nicht sicher, dass jeder und Jede Fähigkeit als Service mit Public-API ist der richtige Weg sehen.
• 2 & amp; 3 Die Nachteile des Freilegens jeder kleinen Sache ist Verwaltungsaufwand, verringerte Leistung (z. B. müssen Sie authentifizieren sich bei diesen Anrufen). Sie erhalten Nano-Dienste Dienste deren Overhead mehr ist als ihr Nutzen.

• Eine Sache, die über die Sicherheit hinzugefügt werden sollte, ist, dass die Tatsache, dass ein Dienst eine REST-API hat, nicht übersetzt werden muss, um diese API der Allgemeinheit zugänglich zu machen. Bereitstellungsweise können Sie es hinter einer Firewall halten und den Zugriff auf bekannte Adressen beschränken usw.

  • 5 Es ist in Ordnung, mehrere orchestrierende Module zu haben. Wenn Sie jedoch ein paar mehr erreichen, sollten Sie vielleicht ein Orchestrierungsmodul (und ESB oder eine Orchestrierungs-Engine) in Betracht ziehen, alternativ können Sie eine ereignisbasierte Integration verwenden das ist flexibler (aber etwas weniger überschaubar)

  • 6 Die erste Option hat den Vorteil einer einfachen Entwicklung und wahrscheinlich einer besseren Leistung (wenn das ein Problem ist). Die hartcodierte Integrationsschicht kann sich im Laufe der Zeit als schwieriger erweisen. Die erlang-Dienste sollten, wenn Sie sie geschrieben haben, in der Lage sein, sich unabhängig voneinander weiterzuentwickeln, wenn Sie die API-Integration und Nachrichtenübermittlung zwischen ihnen beibehalten (glücklicherweise macht Erland dies relativ leicht durch seine inhärenten Merkmale (z. B. Unveränderbarkeit)).