Wie bewerten/bewerten Sie eine Messaging-Architektur?

Question

Ich arbeite an einem Projekt, das auf der Integration mit SMS/MMS Messaging Aggregator-Unternehmen für die Bereitstellung von Anwendungen auf Handys sowie mobile Zahlungen per SMS beruht. Viele Konzepte in solchen Architekturen sind eng mit Messaging-Pattern in Enterprise-Integration und SOA-Welten verbunden. Ich bin gerade dabei, verschiedene SMS-Messaging-Anbieter zu evaluieren und würde gerne wissen, ob es bestimmte Kriterien gibt, nach denen ein Architekt in Messaging-Architekturen sucht, die von Interesse sein könnten.

Mein Ansatz besteht darin, die Architektur "itilies" (Leistung, Verfügbarkeit, Skalierbarkeit, Sicherheit ... usw.) mit einem Scoring-Modell für das System jedes Herstellers zu erstellen. Aber empfiehlt jemand andere Ansätze oder Kriterien, nach denen er bei der Integration solcher Architekturen suchen sollte?

Vielen Dank.

Answer 1

Vollständige Offenlegung: Ich arbeitete für einen der größten SMS/MMS-Broker, also könnte ich ein bisschen voreingenommen sein.

Ich denke, die Dinge, die für Sie wichtig sind, werden schwierig sein, zuverlässige (d. H. Nicht-Umsatz-Spin) Zahlen aus den Brokern zu bekommen. Die Dinge, die wir an den Broker konzentrierte sich auf Ich arbeitete waren:

1. Skalierbarkeit: Wir wählten horizontale Skalierbarkeit) unter Verwendung von Standard-Hardware für die meisten Dinge

2. Durchsatz: wie viele Verbindungen zu jedem Betreiber hat der Broker zu halten Leben/Fallback

3. Failover-Methode: Ist der Broker mit redundanten SMSC/MMSCs für jeden Betreiber verbunden, für den sie verfügbar sind?

4. Verbindungsmethode: Ist der Broker direkt über SMPP/MM4 | 7 verbunden oder verwendet er direkt das SS7-Backbone, d. H. Er hat einen Punktcode.

5. Warteschlangenkapazität: Wie lange kann der Aggregator Nachrichten im Falle eines Benutzerausfalls in die Warteschlange stellen, bevor Nachrichten verloren gehen?

6. Direkte oder Peer-Verbindungen: Wie viele Ihrer potenziellen Zustellungs-MNOs sind direkt mit dem Broker verbunden und wie viele werden über Partner erreicht?

7. End-to-End-Laufzeit

8. QOS

Answer 2

Um "Fehler" korrekt zu bewerten, sollten Sie berücksichtigen, was die Anforderungen sind.

Sie könnten versuchen, alle "Fehler" so objektiv wie möglich zu bewerten, und dann jede Punktzahl entsprechend den Anforderungen gewichten.

P.S. Sollte nicht kosten (€) auch Teil der Gleichung sein. Für Benutzer und Anbieter natürlich!

Answer 3

Haben Sie wirklich vor, die Architektur zu bewerten, dh. die interne Struktur des Aggregators? Wenn ich das täte, wäre ich sehr an Faktoren interessiert, wie der Zerlegung in Komponenten, ihrem Grad der Kohäsion und ihrer relativen Entkopplung. Diese wären aus einer Reihe von Gründen wichtig, nicht zuletzt die zukünftige Flexibilität des Produkts.

Ein weiterer Ort, an dem die interne Struktur des Produkts interessant wird, liegt im Bereich der Skalierbarkeit und Verfügbarkeit. Wenn Behauptungen für solche "Fähigkeiten" gemacht werden, würde ich sehr gerne wissen wollen: "Wie erreicht die Architektur das?"

Ich denke, Ihr Ansatz, eine externe Sicht zu nehmen und Ihre nichtfunktionalen Anforderungen gegen die Produkte "itilities" zu stapeln, ist wahrscheinlich der pragmatischste Ansatz. Ich wäre auch interessiert an den "Fähigkeiten" des Anbieters selbst - was ist die installierte Basis, glauben wir an die fortlaufende Unterstützung des Produkts, welche Produktunterstützung, ist es lokal für Ihre Zeitzone usw.