2016-04-04 12 views
2

Ich habe die letzte Woche über Nevatech Senteinet gelesen und stelle mir gerade die folgende Frage: "Wenn NevaTech Sentinet mit all diesen genannten Features existiert, warum sollte jemand BizTalk mit ESB Toolkit verwenden und es mit Sentrinet erweitern? "NevaTech Sentinet

Sehe ich etwas falsch, aber Sentrinet ist in der Lage, alles und mehr zu handhaben, was BizTalk mit ESB Toolkit auch tun kann?

Antwort

4

Im Wesentlichen sprechen Sie hier über 2 sehr unterschiedliche Produkte.

Sentinet ist ein sehr gutes Tool, wenn Sie an zentralisiertes API-Management denken. Es ist sehr gut in dem, was es in dieser Nische macht.

BizTalk auf der anderen Seite ist eine ESB, die eine Publish/Subscribe-Architektur verwendet. BizTalk hat auch verschiedene Möglichkeiten der Verbindung mit nicht-trivialen Systemen wie SAP, DB2, Siebel, MSMQ, etc ... Es kann auch EDI/AS2/X12, Flat-File-Parsing und so weiter. Sie können es als ESB und/oder Nachrichtenbroker/Hub/etc ...

In Ihrem speziellen Fall (ich vermute, Web-Services verwandt?) Scheint es, dass BizTalk und Sentinet sind ähnlich, noch die beiden sind sehr unterschiedlich und ergänzen sich eigentlich recht gut.

Wie Sie sehen, sind dies 2 völlig verschiedene Produkte und zusammen können sie tatsächlich eine perfekte Ergänzung in Ihrem Fall sein.

Einige weitere Klärung nach dem Kommentar:

BizTalk bedeutet das Verwenden von nicht notwendigerweise Sie ESB Toolkit verwenden. BizTalk kann perfekt als ESB ohne das ESB-Toolkit fungieren.

Die Vorteile der Verwendung von Sentinet sind definitiv API-Management. Worauf Sie sich konzentrieren, wenn Sie die API-Verwaltung mit Sentrinet durchführen, besteht darin, innerhalb von Sentinet eine einzige API-Schicht zu bilden. Oft würden Sie alle Ihre Kunden (sowohl intern als auch extern) auf Sentinet verweisen, wo Sie alle Ihre Dienste virtuell hosten würden. Auf diese Weise erhalten Sie eine Menge Kontrolle und können Ihren vorhandenen Diensten problemlos Sicherheit, Versionierung, Lastenausgleich, SLA-Berichte usw. hinzufügen. Eine andere Sache, Sentinet ist ziemlich gut bei Diensten mit niedriger Latenz. Dies ist etwas, auf das BizTalk nicht besonders gut ist, da es alles in seiner Datenbank beharrt, um den Verlust von Nachrichten zu verhindern. (Ich habe es einmal in einem POC verwendet und einen virtuellen Dienst eingerichtet, der einen vorhandenen externen Dienst mit zusätzlicher Anreicherung aufgerufen hat und problemlos 200+ trx/Sekunden abgedeckt hat).

BizTalk auf der anderen Seite ist Middleware. Das ist ein ganz anderes Spielfeld.
Es ist sehr gut, verschiedene Systeme mit verschiedenen Protokollen zu verbinden, Nachrichten in andere Formate (XML, Flatfile oder EDI) zu mappen, Geschäftslogik zu Ihren Abläufen hinzuzufügen, Integrationsmuster, lange laufende Flüsse, lose Kopplung usw. Sie möchten es nicht als virtuellen Dienst verwenden, da es alles in seinem Meldungsfeld hält!

Hoffentlich sehen Sie jetzt, dass sie beide ein ganz anderer Werkzeugsatz sind.

Sie spielen aber nett nebeneinander: Das Hosting Ihrer BizTalk-Webdienste in einem virtuellen Webdienst auf Sentinet hat viele Vorteile, besonders in einer schnelllebigen Umgebung.

+1

Vielen Dank für Ihre nette Antwort und ja, ich nehme über Web-Services mit SOAP/WSDL. Allerdings war ein Teil der Frage (vielleicht nicht nett gefragt): Gibt es einen wirklichen Vorteil der Verwendung des ESB-Toolkits mit BizTalk Server und erweitern Sie es dann mit Sentinet statt nur BizTalk Server ohne das ESB Toolkit, sondern mit Sentinel – Chris

+1

Hallo Chris, ich habe meine Antwort aktualisiert, hoffentlich macht es das für dich klarer. –

+1

Vielen Dank für Ihre extrem klare Antwort! In der Tat wäre Sentinet als zentrale API-Plattform für die Verwaltung von in BizTalk gehosteten Diensten eine mögliche Lösung. Wenn jetzt ein ESB Toolkit in BizTalk benötigt wird, wird Middleware überprüft. Vielen Dank für Ihre Antwort. – Chris

2

One Neben @ Peters große Antwort:

ich installieren fast immer die ESB ToolKit, wenn nichts anderes für die zentrale Ausnahmebehandlung (EsbExceptionDb). Sie können die Reiseroute und andere Dienste im Toolkit verwenden oder nicht, aber die Ausnahme-DB ist sehr praktisch, wenn Sie versuchen, Fehler zu beheben und möglicherweise Nachrichten erneut zu übermitteln.

+1

Und die hinzufügen und entfernen Namespace-Pipeline-Komponenten sind ebenfalls praktisch. – Dijkgraaf

+0

Ok danke für deine Antwort. – Chris