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

Stellen wir uns vor, wir haben ein Auftragsabwicklungssystem für eine Pizzeria, das entworfen und gebaut werden kann.

Die Anforderungen sind:

R1. Das System sollte mandanten- und anwendungsfallunabhängig sein. Dies bedeutet, dass ein Mandant auf das System zugreifen kann, der bei der Erstkonstruktion nicht berücksichtigt wurde. Wenn die Pizzeria beispielsweise feststellt, dass viele ihrer Kunden die Samsung Bada-Smartphones später verwenden, müssen Sie beim Schreiben eines Clients für Bada OS nicht die API des Systems und das System selbst neu schreiben. oder wenn sich zum Beispiel herausstellt, dass die Verwendung von iPads anstelle von Android-Geräten für Auslieferungstreiber besser ist, ist es einfach, einen iPad-Client zu erstellen, und die API des Systems wird in keiner Weise beeinträchtigt.

R2. Wiederverwendbarkeit: Das System kann einfach neu konfiguriert werden, ohne dass viel Code neu geschrieben werden muss, wenn sich der Geschäftsprozess ändert. Wenn beispielsweise die Pizzeria später beginnt, Zahlungen online sowie Barzahlungen durch Zusteller zu akzeptieren (Akzeptieren einer Zahlung vor der Entgegennahme einer Bestellung im Gegensatz zur Annahme einer Zahlung bei Lieferung), ist es einfach, das System an den neuen Geschäftsprozess anzupassen ;

R3. Hochverfügbarkeit und Fehlertoleranz, dh das System sollte online sein und Bestellungen rund um die Uhr annehmen.

Um R3 zu erfüllen, könnten wir Erlang / OTP verwenden und die folgende Architektur haben:

Das Problem hierbei ist, dass diese Art von Architektur viele "fest programmierte" Funktionen enthält. Wenn der Pizzashop zum Beispiel von der Annahme von Barzahlungen bei Lieferung zur Annahme von Online-Zahlungen übergeht, bevor die Bestellung aufgegeben wird, erfordert es viel Zeit und Mühe, das gesamte System neu zu schreiben und die API des Systems zu ändern.

Darüber hinaus müssten die API, die Clients und das System selbst neu geschrieben werden, wenn die Pizzeria einige Verbesserungen für ihren CRM-Client benötigt.

Die folgende Architektur zielt also darauf ab, diese Probleme zu lösen und somit dazu beizutragen, R1, R2 und R3 zu erfüllen:

Jeder 'Dienst' im System ist ein Webmachine-Webserver mit einer RESTful-API. Ein solcher Ansatz hat folgende Vorteile:

Alles Gute von Erlang / OTP, da jede Webmaschine eine Erlang-Anwendung ist, die überwacht und in ein Erlang-Release eingefügt werden kann.Serviceorientierte Architektur mit allenLeistungen von SOA;leicht anpassbar anÄnderungen im Geschäftsprozess;Einfaches Hinzufügen neuer Clients und neuer Funktionen zu Clients (z. B. zum CRM-Client), da ein Client REST-konforme APIs aller Dienste im System anstelle einer "zentralen" API (Service Composability in Bezug auf SOA) verwenden kann.

Im Wesentlichen handelt es sich bei der im zweiten Bild vorgeschlagenen Systemarchitektur um eine serviceorientierte Architektur, bei der jeder Service eine RESTful-API anstelle eines WSDL-Vertrags hat und bei der jeder Service eine Erlang / OTP-Anwendung ist.

Und hier sind meine Fragen:

Bild 2: Versuche ich hier das Rad neu zu erfinden? Sollte ich stattdessen einfach bei der reinen Erlang / OTP-Architektur bleiben? ("Pure Erlang" bezeichnet Erlang-Anwendungen, die in einem Release gepackt sind und über die Funktionsaufrufe gen_server: call und gen_server: cast miteinander kommunizieren.)Können Sie irgendwelche Nachteile im vorgeschlagenen Ansatz nennen? (Bild 2)Glauben Sie, es wäre einfacher, ein solches System zu warten und zu erweitern (R1 und R2) (Bild 2) als ein wirklich Erlang / OTP-System?Die Sicherheit eines solchen Systems (Bild 2) könnte ein Problem darstellen, da viele Einstiegspunkte für das Web (REST-konforme APIs aller Dienste) anstelle nur eines Einstiegspunkts (Bild 1) geöffnet sind, nicht wahr?Ist es in Ordnung, mehrere 'Orchestrierungsmodule' in einem solchen System zu haben, oder gibt es vielleicht eine bessere Praxis? (Dienste "Bestellungen annehmen", "CRM" und "Versandaufträge" in Bild 2);Hat reines Erlang / OTP (Bild 1) irgendwelche Vorteile gegenüber diesem Ansatz (Bild 2) in Bezug auf die Nachrichtenübermittlung und die Einschränkungen des Protokolls? (teilweise besprochen in meinem vorherigen ähnlichFrage, gen_server: VS HTTP RESTful Calls aufrufen)

Antworten auf die Frage(2)

Ihre Antwort auf die Frage