Serviceorientierte Architekturvorschläge

Aus persönlichen und universitären Gründen denke ich darüber nach, ein einfaches CRM mit einer serviceorientierten Architektur aufzubauen. Seine Bedeutung ist nur, die Architektur selbst zu erklären, nicht die kommerzielle Nutzung.

Ich wollte ein CRM implementieren, das einen einfachen Analysedienst und eine einfache Kundenbetreuung bietet (Speicherung von Benutzern, persönliche Kommentare und einige andere Dinge).

Die Architektur, die ich entwerfe, definiert: - WebGUI (ein Client der anderen Services) - AnalyticsService (ein Service, der Daten empfängt, analysiert und sammelt) - CustomerCareService (ein Service, der RESTful-APIs zum Anwenden von CRUD-Operationen verwendet).

Jeder Dienst verfügt über eine eigene Datenbank, die völlig unabhängig von anderen ist. Sie legen eine öffentliche Schnittstelle frei. Die Schnittstelle muss natürlich eine Art Authentifizierung bereitstellen, um nicht autorisierte Anforderungen abzulehnen.

Die Vorteile, die ich in dieser Art von Architektur erläutern möchte, sind die Möglichkeit, alle Dinge unabhängig voneinander zu haben und sie zu kombinieren, um neue Services anzubieten (wenn es zum Beispiel einen OrderService für die Auftragsabwicklung gäbe, wäre es einfach, ihn damit zu kombinieren Kunde, der die öffentlichen APIs verwendet). Der große Vorteil für mich ist, dass es einfach genug wäre, andere Clients zu erstellen, die diese Dienste nutzen.

Ich weiß nicht, was eine gute Authentifizierungsmethode ist, die einfach zu implementieren sein könnte, und ich bin mir auch nicht sicher, wie diese APIs erstellt werden sollen (verwenden Sie XML- oder reine REST-APIs mit GET / POST-Daten). Ich habe mit Amazon, PayPal und anderen Unternehmens-APIs gearbeitet. Sie scheinen REST-Dienste zu verwenden (Paypal verwendet einen hässlichen _cmd GET-Parameter, während Amazon eine bessere URI verwendet), um zu wissen, was zu tun ist XML. Natürlich muss ich auch berücksichtigen, dass das Webinterface den angemeldeten Benutzer erkennen, die Berechtigungen (Token oder was auch immer) erhalten und es mit Diensten verwenden muss, um Informationen anzuzeigen. Ich bin mir also nicht sicher, ob SOA die Art von Architektur ist, die ich wirklich aufbaue ... ist es SaaS anstelle von SOA? Ich denke, es wäre besser, RESTful-Anwendungen mit JSON oder ähnlichem zu verwenden, um es zu implementieren (ich bin kein großer Fan von XML, ich finde es zu ausführlich).

Der Übersichtlichkeit halber liste ich hier meine Fragen auf:

Wird diese Art von Architektur SOA oder SaaS (oder beides) genannt?Was ist eine gute Implementierung für das, was ich erhalten möchte? (bitte erläutern Sie es so detailliert wie möglich)Welche Art von Authentifizierung ist für einen Client besser geeignet (Benutzertoken gegen OAuth oder ähnliches)?Haben Sie einen Vorschlag für ein solches Projekt?

Ich habe ungefähr 3 Monate Zeit, um es zu machen, also kann ich nichts wirklich Komplexes machen (abgesehen von der Tatsache, dass es für einen einzelnen Programmierer nicht realistisch wäre).

Ich kenne Python (WSGI-Frameworks), Ruby on Rails, C / C ++ und andere Sprachen (ohne .NET) und würde es gerne unter einer Linux-Umgebung (MySQL oder Postgres oder sogar NoSQL, wenn Sie Vorschläge dazu haben) entwickeln die richtige Wahl), ich könnte auch mehrere Sprachen kombinieren, da diese Dienste unabhängige Programme sind.

Was ich hier haben möchte, ist eine gute Sichtweise und einen guten Vorschlag.

Vielen Dank!

Antworten auf die Frage(2)

Ihre Antwort auf die Frage