Ich war dafür verantwortlich, ein System weiterzuentwickeln, das ich ursprünglich nicht entworfen hatte, und kann die ursprünglichen Designer nicht fragen, warum bestimmte Entwurfsentscheidungen getroffen wurden, da sie nicht mehr hier sind. Ich bin ein Junior-Entwickler in Designfragen und wusste nicht genau, was ich fragen sollte, als ich mit dem Projekt anfing, das mein erstes SOA / WCF-Projekt war.

Das System verfügt über 7 WCF-Dienste, von denen jeder in einer separaten Konsolen-App / einem separaten Windows-Dienst selbst gehostet wird. Alle von ihnen sind Single-Instanz und Single-Threaded. Alle Services haben den gleichen OperationContract: Sie stellen eine Register () - und eine Send () -Methode bereit. Wenn Client-Dienste eine Verbindung zu einem anderen Dienst herstellen möchten, rufen sie zuerst Register () auf. Wenn dies erfolgreich ist, rufen sie Register () aufalle den Rest ihrer Kommunikation mit Send (). Wir haben einen DataContract mit einer Aufzählung MessageType und einer Eigenschaft Content, die andere "Nutzdaten" von DataContract enthalten kann. Was der Dienst mit der Nachricht macht, wird durch die Aufzählung MessageType bestimmt ... alles kommt über die Methode Send () und wird dann an eine switch-Anweisung weitergeleitet ... Ich vermute, dass dies ungewöhnlich ist

Register () und Send () sind eigentlich OneWay und Async ... ALLE Ergebnisse von Diensten werden von einem WCF-Rückrufvertrag an Clientdienste zurückgegeben. Ich glaube, dass der Grund für die Verwendung von CallbackContracts darin besteht, das von uns verwendete Publish-Subscribe-Modell zu vereinfachen. Das Problem ist, dass nicht alle unsere Kommunikationen für Veröffentlichungen und Abonnements geeignet sind. Die Verwendung von CallbackContracts bedeutet, dass wir Quellendetails in zurückgegebenen Ergebnisnachrichten einschließen müssen, damit Clients herausfinden können, wofür die zurückgegebenen Ergebnisse ursprünglich bestimmt waren. Wiederum müssen Clients eine switch-Anweisung ausführen Was ist mit Nachrichten zu tun, die von Diensten eingehen, die auf dem Nachrichtentyp (und anderen eingebetteten Details) basieren?

In Bezug auf die Topologie: Die Dienste bilden "Knoten" in einem Diagramm. Jeder Dienst hat eine Liste anderer Dienste, mit denen er eine Verbindung herstellen muss, beim Start fest codiert und lässt Client-Dienste erst dann "registrieren", wenn alle erforderlichen Verbindungen hergestellt wurden. Als Beispiel haben wir einen LoggingService und einen DataAccessService. Das DataAccessSevice ist ein Client des LoggingService. Daher versucht der DataAccess-Dienst beim Start, sich beim LoggingService zu registrieren. Solange der DataAccess-Dienst nicht erfolgreich registriert werden kann, können sich keine Clients bei ihm registrieren. Das Ergebnis ist, dass beim Hochfahren des gesamten Systems die Dienste kaskadenartig gestartet werden. Ich sehe das nicht als Problem, aber ist das ungewöhnlich?

Um die Angelegenheit komplexer zu gestalten, ist eine der Systemanforderungen, dass Dienste oder "Knoten" nicht direkt miteinander registriert werden müssen, um Nachrichten aneinander zu senden, sondern über indirekte Verbindungen kommunizieren können. Angenommen, wir haben 3 Dienste A, B und C in einer Kette verbunden. A kann eine Nachricht an C sendenüber B ... mit 2 Hopfen.

Ich wurde tatsächlich damit beauftragt und schrieb das Routing-System, es hat Spaß gemacht, aber der Vorsprung blieb, bevor ich fragen konnte, warum es wirklich gebraucht wurde. Soweit ich sehe, gibt es keinen Grund, warum Dienste nicht einfach eine direkte Verbindung zu den anderen Diensten herstellen können, die sie benötigen. Was mehr ist, musste ich ein Zuverlässigkeitssystem über alles schreiben, da die Anforderung war, zuverlässige Nachrichten zu habenüber Knoten im System, wobei WCF mit einfachen Punkt-zu-Punkt-Verbindungen die Aufgabe zuverlässig erledigt.

Vor diesem Projekt hatte ich nur 3 Jahre an winforms Desktop-Apps gearbeitet, wusste es nicht besser. Mein Verdacht ist, dass die Dinge bei diesem Projekt zu kompliziert sind: Ich fasse zusammen, meine Fragen sind:

1) Ist diese Idee einer Graphentopologie mit Nachrichten, die über indirekte Links springen, ungewöhnlich? Warum nicht einfach Dienste direkt mit den Diensten verbinden, auf die sie zugreifen müssen (was wir in Wirklichkeit sowieso tun ... Ich glaube nicht, dass wir irgendwelche Nachrichten haben, die hüpfen)?

2) Sind nur zwei Methoden im OperationContract verfügbar und wird mithilfe einer MessageType-Enumeration bestimmt, wofür die Nachricht gedacht ist bzw. was damit zu tun ist? Sollte ein WCF-Dienst nicht stattdessen viele Methoden mit bestimmten Zwecken verfügbar machen und der Client wählt aus, welche Methoden er aufrufen möchte?

3) Erfolgt die gesamte Kommunikation mit einem Kunden über CallbackContracts ungewöhnlich? Sicherlich ist die Synchronisierung oder die asyc-Anfrage-Antwort einfacher.

4) Ist die Idee eines Dienstes, der es Client-Diensten nicht erlaubt, sich mit ihm zu verbinden (Registrieren), bis er sich mit allen seinen Diensten (mit denen er ein Client ist) verbunden hat, ein solides Design? Ich denke, dies ist der einzige Entwurfsaspekt, dem ich zustimme. Ich meine, der DataAccessService sollte keine Clients akzeptieren, bis er eine Verbindung zum Protokollierungsdienst hat.

Ich habe so viele WCF-Fragen, mehr wird in späteren Threads kommen. Danke im Voraus.