Ist BizTalk ein ESB?

Question

Ich beschäftige mich mit Architekturmuster, Enterprise Services Bus (ESB) genauer gesagt. Beim Lesen dieses Artikels Enterprise Integration frage ich mich mit wenig bis gar keiner Erfahrung, ob BizTalk ein ESB ist oder nur ein EAI (Hub/Spokes oder Bus)?

Ich habe dies gefunden NServiceBus und BizTalk, das BizTalk als zentralen Message-Broker beschreibt.

Unter Berücksichtigung anderer ESB-Frameworks (NServiceBus und Rhino Service Bus). Diese Frameworks haben keinen zentralen Punkt zur Verarbeitung von Nachrichten.

Ist BizTalk eher ein EAI als ein ESB?

Vielen Dank

Answer 1

BizTalk wird von Microsoft als mit ESB-Fähigkeiten ausgestattet angepriesen - siehe das BTS ESB-Toolkit

Der Begriff 'ESB' umfasst jedoch ein sehr breites Feld, und es gibt viel Subjektivität bezüglich einer genauen Definition eines ESB. Meiner Meinung nach gibt es Schwachstellen in der Behauptung von BizTalk, umfassend als ESB zu gelten (in einer Definition des Begriffs nach 2010).

• BTS entstand in der Hub-and-Spoke-EAI-Ära, bevor ESB weit verbreitet wurde.
• BTS eignet sich eher für asynchrone Prozesse als für synchrone Prozesse - Latenzen variieren je nach Auslastung des Systems, Drosselungsstatus usw.
• BTS ist umständlich, wenn es um die Versionierung von Diensten und Schemas geht (eine neue Bereitstellung ist erforderlich).
• BTS ist umständlich, wenn es um die Verwaltung VIELEN Diensten geht (z. B. die Verwendung von BizTalk als Fassade für alle 5000 Ihrer Unternehmens-SOA / Web Services wird schmerzhaft sein).

Zum Teufel, wir haben festgestellt, dass BTS gut geeignet ist für:

• alle unsere synchrone und asynchrone EAI (d. h. formalisierte Integrationsverträge zwischen großen LOB-Systemen und mit Handelspartnern) und die große Anzahl von Adaptern unterstützt bei der Integration einer Vielzahl von Protokollen.
• Für Business-Process- und Business-Monitoring-Fähigkeiten
• Bewältigung von Transaktions- und Liefertreue - Biztalk verfügt über die Fähigkeit zum erneuten Versuch, Verfolgen und Wiederaufnehmen von angehaltenen Nachrichten, was bei unzuverlässigen Netzwerken oder bei der Integration mit unzuverlässigen Systemen nützlich ist.

Aktualisierung, mit einigen weiteren vergleichenden Erfahrungen

• BTS ist sehr zentralisiert - letztendlich ist auch ein Multi-Server-BizTalk-Cluster / -Gruppe von Sql-Server abhängig. ESB-Produkte basierend auf Warteschlangen neigen dazu, dezentralisierter zu sein (logisch und physisch), sodass der Ausfall einiger Endpunkt- oder Warteschlangenserver nicht das ganze Unternehmen lahmlegen sollte.
• Viele auf Warteschlangen basierende ESBs basieren auf Open-Source-Technologien und zielen darauf ab, eine Bindung an einen einzigen Anbieter zu vermeiden.
• Viele zeitgenössische ESBs scheinen einen Commodity-Computing-Ansatz zur Skalierung zu verfolgen. Das Skalieren mit Produkten wie BizTalk kann teuer werden.
• Andererseits sollten die Überwachungs- und Verwaltungsfähigkeiten kommerzieller Angebote wie BTS nicht unterschätzt werden - stellen Sie sicher, dass jeder ESB, den Sie in Betracht ziehen, ausreichende Auditierung, Instrumentierung, Wiederholung und diagnostische (WMI / SNMP / SCOM usw.) Fähigkeiten hat - Sie benötigen ein Dashboard zur Überwachung der Gesundheit Ihres Busses, und es gibt nichts Schlimmeres, als nicht zu wissen, wohin eine Nachricht gegangen ist. Hier ist zentrale Verwaltung und Diagnose ein Pluspunkt.

Answer 2

BizTalk ist eine Messaging- und Workflow-Orchestrierungsplattform, auf der Sie ESB-Verhaltensweisen und -Fähigkeiten entwickeln können. Um dies zu vereinfachen und die ESB-Implementierung auf BizTalk zu standardisieren, hat Microsoft das BizTalk ESB Toolkit veröffentlicht - ein Satz von Richtlinien, Mustern und Code.

Die Konzepte von EAI und BPM gibt es schon seit einiger Zeit, daher gibt es viele Unternehmen, die BizTalk genutzt haben, um Lösungen für diese Probleme zu erstellen. Unternehmen, die einen vollständigen ESB auf dem BizTalk-Server hosten, sind viel weniger, und die Akzeptanz hat sich sicherlich mit dem Aufkommen von WCF/WF/NServiceBus und natürlich Azure Service Bus verlangsamt.

Zusammenfassend lässt sich sagen, dass BizTalk von Haus aus weder EAI noch ESB ist, aber mit einer Reihe von Entwicklern beide Aufgaben erfüllen kann.

Answer 3

Bei "EAI oder ESB" gehe ich davon aus, dass Sie wissen wollten, ob BizTalk der Hub&Spoke- oder der Bus-Architektur folgt.

Von einem Architekturmuster-Perspektive fallen Integrationslösungen grob unter eines der zwei Muster-

• Der Hub und das Rad: Dabei handelt es sich um ein zentrales Nachrichtenbroker, der Nachrichten an verschiedene Empfänger sendet, während alle Sender ihre Nachrichten nur an diesen Broker senden. Somit müssen weder die Sender noch die Empfänger voneinander wissen. Dies ist typischerweise das, was viele Leute als EAI bezeichnen (obwohl es absolut möglich ist, eine EAI-Lösung zu implementieren, die dem BUS-Muster folgt). Lösungen, die diesem Muster folgen, sind einfach zu entwickeln und zu verwalten. Alle Routing-Logik wird zentral an einem Ort verwaltet - im Hub. Aber wie Sie sich vielleicht vorstellen können, hat dies einen offensichtlichen Nachteil - einen einzelnen Ausfallpunkt. Wenn der Hub abstürzt, kommt alles zum Stillstand. Außerdem skaliert dieses Modell nicht sehr gut.

• BUS: Unternehmen-Integrationslösungen, die um dieses Muster herum entwickelt wurden, werden im Allgemeinen als ESB bezeichnet. Hier gibt es keine intelligenten zentralen Behörden. Alle Sender veröffentlichen ihre Nachrichten im Bus. Die Empfänger müssen intelligent genug sein, um zu bestimmen, welche Nachrichten für sie bestimmt sind und sie vom Bus abholen. Somit müssen die Sender und Empfänger nur über den Bus Bescheid wissen. Aber hier ist die Routing-Logik auf die Empfänger verteilt, sodass es keinen einzelnen Ausfallpunkt gibt. Auch dieses Modell ist äußerst skalierbar. Allerdings sind solche Lösungen ziemlich komplex und schwer zu verwalten.

Kommen wir zur Frage, welchem Muster BizTalk folgt - es ist eine Mischung aus beiden Mustern.

Das Hub-ähnliche Aussehen ist sehr offensichtlich mit seinem zentralen Nachrichten-Engine und einer zentralen MessageBox-Datenbank. Dies gibt einem die Einfachheit und Leichtigkeit der Verwaltung, die typisch für den Hub-Ansatz ist.

Aber wenn man sich die BizTalk-Architektur ansieht, kann man ein Host mit seinen Host-Instanzen über mehrere Server verteilt haben. Es ist auch möglich, die verschiedenen BizTalk-Datenbanken wie MessageBox, Tracking, Ent SSO usw. auf verschiedenen Servern konfiguriert zu haben, Dies macht BizTalk-Lösungen skalierbarer und toleranter gegenüber Fehlern als die Standard-Hub-Implementierungen - was in der Regel dem Bus-Ansatz zugeschrieben wird.

Hoffentlich beantwortet das Ihre Frage.

Answer 4

BizTalk ist sicherlich ein ESB. EAI ist eher ein lockeres Konzept - BizTalk kann sicherlich bereitgestellt werden, um EAI zu unterstützen, und es kann auch noch viel mehr tun.

Answer 5

BizTalk ist mehr als ein ESB, aber passt sicherlich. Dieser Link ist etwas veraltet, aber beantwortet genau Ihre Frage.

EDIT: Hier ist ein neuerer MS-Link, der speziell auf die Implementierung eingeht.