ESB, Bus nur ein gedankliches Konstrukt?

Hallo,
ich arbeite mich ein bisschen in ESB's ein (rein aus Interesse) und habe mir die drei Open Source Implementierungen angeschaut: MassTransit, SimpleServiceBus und NServiceBus (zu Rhino Service Bus war das SVN Repository nicht erreichbar).

Meine Frage ist eher theoretischer Natur: Ist der Bus ein gedankliches Konstrukt oder existiert er z.B. in Form eines zentralen Servers? Nach einer Durchsicht des Quellcodes scheint mir eher ersteres der Fall zu sein, ich bin mir aber nicht sicher. Statische Zieladressen in den einzelnen Services scheinen mir irgendwie gegen den Bus Gedanken zu sein aber zumindest bei Simple Service Bus scheint dies der Fall zu sein.

Ich bin mir im Klaren, dass man da nicht alle Systeme so verallgemeinern kann, aber vll. kennt sich einer mit den dreien oder alternativen Systemen und deren Implementierungen (z.B. BizTalk) genauer aus.

Hallo malignate,

Ein ESB muss schon als konkreter Dienst implementiert werden. Schließlich ist zur Umsetzung des ESB-Gedankens eine Menge zentraler Infrastruktur nötig. Der BizTalk-Server ist eine fertige ESB-Implementierung.

Das dachte ich mir, aber zumindest bei den OSS Implementierungen, bzw. NServiceBus, scheint das eher nicht der Fall zu sein, die verwenden in den Samples zwar die MSMQ als zentraler Bus aber sonst eher eine Punkt zu Punkt Verbindung.

Kann natürlich sein, dass ich den Code nicht ganz verstehe, aber mir scheint es, als ob sie eher die Pattern aus dem hervorragenden Buch "Enterprise Integration Patterns" implementieren und das dann Bus nennen, obwohl es wohl eher ein Message System / Framework ist.

Beim BizTalk-Server ist es so, dass alle Nachrichten vor der Verarbeitung in XML-Nachrichten umgewandelt und in einer zentralen Datenbank - der MessageBox - gespeichert werden. Den Weg in bzw. aus dem Bus finden die Nachrichten über Ports, die der Entwickler einrichtet. Die Anbindung von Anwendungen oder Software-Komponenten an den Bus wird über Adapter realisiert. Diese Adapter sind kleine Plug-Ins, welche die Kommunikation zwischen BizTalk Server und einem bestimmten Fremdsystem implementieren. Für ein- und ausgehende Ports lassen sich auch Pipelines definieren, die sich um Umwandlungen, Authentifizieung, Ver- und Entschlüsselung und der gleichen kümmern.
Welche Nachrichten wohin weitergeleitet und weiterverarbeitet werden, wird über Subscriptions geregelt, die Ports oder Orchestrations (modellierte Workflows) auf die MessageBox haben.

Die Idee ist, alle Anwendungen an den Bus anzubinden und die anwendungsübergreifende Kommunikation über Orchestrations oder Message Routing in der BizTalk Infrastruktur zu regeln. Man kann dabei von EAI oder Makro-SOA sprechen.

Das klingt eigentlich wie aus dem Lehrbuch. Also ist ganz einfach XML das Canonical Data Model, macht Sinn.

Für den Preis wird sich das dann bequem per GUI konfigurieren und Flows zusammenklicken, klingt ganz cool, aber wahrscheinlich nicht ganz so billig.

Leider sind die OSS Implementierungen nicht ganz so gut. z.T. chaotischer Code, schlecht dokumentiert, keine bis wenig Kommentare...vll. hilft mir ja der Application Space von Westphal weiter.

Ich denke nicht, dass der Application Space als Plattform für EAI taugt. Damit lassen sich zwar verteilte Anwendungen entwickeln, aber für Integrations-Szenarien fehlt die Unterstützung (Mappings, Adapter, etc.). Unter der Haube arbeitet der Application Space glaube ich mit Jabber, was ein Protokoll aus dem Bereich Instant Messaging (in der Art von ICQ, MSN Messenger, etc.) ist.

Wie willst Du damit verschiedene Anwendungen orchestrieren?

Im Endeffekt geht es mir nur darum ein bisschen mit der Sache zu experimentieren, das heißt ich interessiere mich im Prinzip für das Thema Messaging, typische Integration-Szenarien mit all den netten Features die z.B. der Biztalk Server da vll. bietet und die das ganze auch so komplex machen sind für mich weniger interessant.

Mir gefällt nur der Gedanke des Messages Bus als zentrale Stelle und die Möglichkeit zentrale Anlaufstellen zur Ablaufkontrolle zu haben. Das ganze geht eigentlich gedanklich für mich eher Richtung Workflows und asynchrone Archtitektur und ist mehr ein kleines "Forschungsprojekt" für mich. Nichtsdestrotrotz fände ich natürlich eine gutes kostenloses ESB Framework.

Ich sehe hier der Application Space (der auch mit anderen Protokollen und WCF arbeitet) nicht als Ende und letzte Weisheit sondern eher als Anfang und denke, dass er zum Beispiel auch für einen Service Bus gute Dienste leisten kann. Intern ein Bus, der zum Beispiel auf einem oder mehreren Rechnern Nachrichtent routet und Prozesse (in Form von Flows, Process Manager als Pattern) verwaltet, das alles mit dem Application Space und nach außen stehen dann Adapter zur Verfügung.

Im Prinzip arbeitet der Biztalk Server intern ja auch relativ starr, die Flexibilität ist ja nur nach außen hin notwendig, zu viel flexibilität im eigentlichen Bus würde das System ja nur unnötig verkomplizieren und verlangsamen.