Laden...

Architekturfrage: generischer Nachrichtendienst

Erstellt von LastGentleman vor 14 Jahren Letzter Beitrag vor 14 Jahren 1.316 Views
LastGentleman Themenstarter:in
1.274 Beiträge seit 2005
vor 14 Jahren
Architekturfrage: generischer Nachrichtendienst

Hallo zusammen,

ich möchte gerne mir einen kleinen Dienst bauen womit ich Nachrichten austauschen kann. Im Grunde möchte ich das ganze generisch halten, so das jeder Datentyp unterstütz wird.
So soll die Datenschnittstelle verwendet werden können um kurze Nachrichten zu versenden (ein Chat Programm), es soll auch möglich sei, gewissen Prozesse zu starten. Oder Benutzereingaben zu fordern.

Wie baue ich am besten die Infrastruktur auf?
Ich dachte mir ich verwende ein WCF mit Callback's for die Bi-Direktionale Kommunikation.

Der Contrakt hat 3 Feldern. Empfänger, Typename und das Objekt als XML String und ich ermittle dann selber welches Objekt dies wäre und deseralisiere es.
Das hat natürlich den Vorteil das ich mittels eines DI Injectors mir die einzelnen Aufgaben aus eigene DLL's reinladen kann.
Bin auch am Überlegen ob ich einen bestehende Nachrichtenstruktur verwenden sollen, wie z.B.: den XMPP, oder gar ServiceBus, wo ich einzelne Dienst reinhänge.

Wie denkt ihr über diesen Vorschlägen?

"Das Problem kennen ist wichtiger, als die Lösung zu finden, denn die genaue Darstellung des Problems führt automatisch zur richtigen Lösung." Albert Einstein

S
8.746 Beiträge seit 2005
vor 14 Jahren

ServiceBus-Geschichten sind für sowas eigentlich prädestiniert. Die bieten i.d.R. auch Unterstützung für DI. Der ServiceBus ist aber im Architekturmodell ganz oben. WCF wäre nur ein Transport-Typ (der wiederum auf verschiedenen Channels laufen kann) - also ganz unten im Modell (außer beim .NET Service Bus, hier ist WCF quasi der Kern und der SB nur der Aufsatz). In der Regel hat ein ServiceBus dann noch direkten Support der üblichen MessageQueue-Verdächtigen (MSMQ, Rhino, etc.), da Message-Queueing der natürliche Freund einer nachrichtenorientierten Kommunikation ist.

Ich persönlich arbeitet gerade mit SimpleServiceBus (siehe Codeplex) - einem NServiceBus-Klon.

Die Typinformation kannst du dir schenken. Das macht die Serialisierung ja von sich aus. Analog zu Webservices definierst du deine Messages ja ebenfalls über ein Schema (xsd), auch denen die Serialisierungsklassen gebaut werden - zumindest wenn du XML als Serialisierungsprotokoll verwendest. Ein Contract besteht also aus dem Messagetyp als XML complex type und dem Inhalt. Der wiederum ist aber nur Teil der transportierten Message, die ja noch Infrastrukturinformationen ,wie z.B. die CorrelationID der Message, enthält. Wie die aber serialisiert wird, hängt wiederum vom Transportprotokoll ab. Wenn du XML via MSMQ transportierst, dann steht die im MSMQ-Header.

Aber davon bekommst du aus Anwendungssicht gar nix mit. Da hast du halt Send, Receive, Request/Response und Publish/Subscribe.

LastGentleman Themenstarter:in
1.274 Beiträge seit 2005
vor 14 Jahren

Danke Svenson.

Sehr interessant. Wäre ein Punkt zum anschauen.
Ich hab ein bisschen bedenken bei der ganze MSMQ Geschichte. Noch ein Ding mehr was ich installieren muss und was Fehler verursachen kann.

Hab da noch einen Interessanten MessageBus gefunden (Rhino-Queue), sehr Lightweight von einem ALT.NET Verfechter

Das was mir an deinem Ansatz sehr gut gefällt ist, das ich mich nicht um das ganze drunter kümmern muss, Fehlerbehandlung im Transport, Persistenz der Nachrichten, ...

"Das Problem kennen ist wichtiger, als die Lösung zu finden, denn die genaue Darstellung des Problems führt automatisch zur richtigen Lösung." Albert Einstein

S
8.746 Beiträge seit 2005
vor 14 Jahren

Ja, die RhinoQueue findet sich in vielen SBs. Ist aber eigentlich nur eine Queue und noch kein Bus. Aber die Rhino-Leute haben auch das in petto:

http://ayende.com/Blog/archive/2008/12/17/rhino-service-bus.aspx

Wenn es geht, dann sind Queues - egel welche - immer Mittel der Wahl. Das gilt eigentlich für alle SOA-Geschichten. Sie nehmen - wie du ja schon gesagt hast - viel Komplexität aus der Anwendung und bringen eben auch nette Features, wie offline-Fähigkeit, damit z.B. stressfreies Runterfahren (Updates, etc.). HTTP-basierte Webservices können da nicht mithalten. Aber man muss auch sagen: Es fehlen da auch noch Standards wie Transaktionen, die aber bei fast allen SOA-Anwendungen sowieso kaum eingesetzt werden. Zumeist nicht interoperabel und skalieren schlecht.

LastGentleman Themenstarter:in
1.274 Beiträge seit 2005
vor 14 Jahren

Danke. Stimmt ist mir gleich komisch vorgekommen, beim durchschauen. Danke für den Link die Subversion Adresse vom Service Bus stimmt nicht mehr. Man muss ihn nun über Git auschecken http://github.com/ayende/rhino-esb/.

"Das Problem kennen ist wichtiger, als die Lösung zu finden, denn die genaue Darstellung des Problems führt automatisch zur richtigen Lösung." Albert Einstein

LastGentleman Themenstarter:in
1.274 Beiträge seit 2005
vor 14 Jahren

Alles was ich mir schön durch überlegt habe, beginnt zu kippen.

Falls jemanden auch sich sowas überlegt, alle Windows haben MSQM (fast vollständig) drinnen, nur nicht XP die home Variante.

Muss mir was neues suchen 😦

"Das Problem kennen ist wichtiger, als die Lösung zu finden, denn die genaue Darstellung des Problems führt automatisch zur richtigen Lösung." Albert Einstein