Vorteile eines Enterprise Service Bus

https://stackoverflow.com/questions/2023130

19-09-2019
|

Frage

Wo kann ich einige Informationen über die Einsatzmöglichkeiten und Vorteile eines Enterprise Service Bus finden (ESB)?

Ich bin auf der Suche nach Informationen über:

die Arten von Problemen und ESB hilft lösen
die Alternativen zu einem ESB - und die Kompromisse zwischen ihnen bei der Auswahl
, was Sie brauchen als Entwickler zu tun ESB-kompatible Systeme

Ich suche nach einer feineren Detailebene als nur Wikipedia oder Online-Marketing-Broschüren von Anbietern. Idealerweise würden einige Beispiel-Code zu klären helfen, was in die Vorteile eines ESB beteiligt ist. Informationen aus einer .NET oder Java-Perspektive wäre am nützlichsten.

Danke.

Lösung

Ich würde vorschlagen, Um ESB oder nicht ESB mit zu beginnen, geschrieben von dem Schöpfer von Mule .

Andere Tipps

ESB ist eine gute Möglichkeit, Enterprise Integration Patterns zu implementieren.

Arten von Problemen, die eine ESB

lösen hilft

Sie haben eine Reihe von Protokollen Sie auf ein einzelnes Protokoll normalisieren möchten (z FTP, E-Mail, SOAP, XMPP, usw. zu einem Messaging-System), z.B. ActiveMQ. Auf diese Weise können Sie die Implementierung von Diensten aus dem Protokoll zu entkoppeln.
Sie wollen eine konsistente Art und Weise Dienste in diese Architektur Haken, so dass sie für Nachrichten hören können, Prozessmeldungen und Nachrichten erzeugen (Message Endpoints, Channel-Adapter usw.).
Sie können einen verwalteten Container wollen diese verschiedenen Komponenten in (zum Beispiel ServiceMix, Mule)
Sie können eine Reihe von vorgefertigten Komponenten und Adapter in verschiedene Protokolle wollen (zum Beispiel ServiceMix, Mule und Kamel haben eine Menge vorgefertigter Komponenten).
Sie können lange laufenden Workflows erfordern. Business Process Management ist oft etwas, das neben einem ESB zur Verfügung gestellt wird (Apache ODE-Stecker in eine Reihe von Open-Source-ESB).

Die Alternative zu einem ESB

Die Alternativen wirklich hängen von dem Problem, das Sie zu lösen versuchen.

verteilte Dienste, nutzen die Menschen oft Anwendungsserver-Dienste über einem bestimmten Punkt aussetzt RPC-Protokoll-zu-Punkt (wie EJBs über RMI oder Web Services über HTTP). Also, anstatt eine Nachricht auf einen ‚Bus‘ setzt, ruft ein Client direkt einen Server aus.
Um auf bestimmte Protokolle zu reagieren, können Sie nur einen Client erstellen, die zum Beispiel das Schreiben einer Anwendung auf dieses Protokoll reagiert, die für E-Mails mit Java Mail oder zuhört, die mit Smack auf XMPP hört. Wenn Ihr Problem auf ein oder zwei Protokolle beschränkt ist, ist es nicht wert sein kann, in einem vollen ESB zu bringen.

Was Sie brauchen, als Entwickler zu tun ESB-kompatible Systeme

bauen

Das auf der ESB abhängen Sie wählen, obwohl gegeben, dass die meisten von den guten in alle Arten von Protokollen zu nennen sind so konzipiert, wie auch Gastgeber POJOs, gibt es nicht viel sollten Sie ESB kompatible Systeme tun müssen, bauen . Es ist ein Versuch wert, Ihren Code asynchron zu machen.

Für Beispiele, Apache Camel hat wahrscheinlich die knappste Konfiguration, hier ist ein Tutorial .

Drei entscheidende Vorteile:

bietet ein Bus, einen Weg für die Punkte Ende miteinander zu verbinden, ohne direkt mit reden miteinander. Es vereinfacht die Kommunikation für die Endpunkte, da sie nur zu einer Standard-Kommunikationsschnittstelle entsprechen haben, den Bus. (Dies ist bei jedem technischen Bus, nicht nur ESBs)
Ein ESB bietet eine einzigen Ort , um einige der wichtigsten Endpunkt Metriken zu erhalten. Frequenz, Verfügbarkeit und Leistung
Ein ESB neigt mehr als eine Kommunikationsschnittstelle zur Verfügung zu stellen. Allerdings ist ein Entwickler braucht nur die am einfachsten zu wählen, um die Daten aus dem Bus und zu empfangen.

Stellen Sie jedoch sicher, dass diejenigen, wird Unternehmenswert für Ihre Situation. einen ESB zu haben, ist noch eine weitere Komplexität zu Ihrem Unternehmen hinzufügen. Im Idealfall sollten Sie diese nicht auf wenige Anwendungen wählen, sondern die gesamte Organisation. Es sollte nur eine Produktion ESB-Cluster für die Organisation sein.

Alternativen:

Schließen Sie einfach die Dinge direkt miteinander vor allem, wenn die Kommunikationsprotokolle gleich sind. Das ist gut für einfache Anwendung Cluster und nicht zu viel Denken erfordern. Wie jedoch die Anzahl der Anwendungen wachsen, die Verbindungen aufrechterhalten wird schwierig.
Eine weitere Alternative ist eine MQ-Implementierung. Dies wird Ihnen eine Möglichkeit der Daten drängen bieten um ohne komplexe Verbindungen zu haben, aber dann sind Sie nur einen Kommunikationskanal verwenden gezwungen. Zum Glück für Java, haben sie den JMS-Standard.

Praktikabilität:

Ich habe die möglichen Alternativen angegeben. Sie können auf den ersten lausig erscheinen, aber es ist nicht zu sagen, dass Sie nicht auf diese Weise beginnen können. Ich persönlich schreibe direkt an die Fern zu sprechen, ohne über einen ESB geht um sicherzustellen, dass es funktioniert, ohne zu viel Sorgen über Integrationsprobleme.

Wenn Sie keinen ESB haben, empfehle ich Ihnen Mule versuchen, für Entwicklung und WebSphere ESB für Test und Produktion. Ich neige dazu, zwei Produkte, die angeblich Standards folgen, um sicherzustellen, halten wir die Verkäufer ehrlich und sicherstellen, dass Ihre Entwickler-Standards konform sind unbeabsichtigte Vendor Lock-in zu verhindern.

Am Ende beantworten Sie einfach die folgende Frage: ist die Zeit, die etwas komplizierter zu machen andere Komplexität zu vereinfachen Ihr Unternehmen lohnt sich die Kosten auf lange Sicht

Zusätzlich zu den Websites, die bereits erwähnt wurden. Sie sollten diesen Artikel auf „ lesen keine ESB verwenden Sie, wenn Sie absolut haben “. Es wurde von der CTO von MuleSource geschrieben, einer der beliebtesten Open-Source-ESB zur Verfügung. Nicht gerade eine Antwort auf Ihre Frage, mehr einen Punkt machen fragen Sie sich, „Muss ich ein ESB“?

Es gibt eine anständige 3-teiligen Serie über bei IBM ESB in Bezug auf die ziemlich Konzept orientiert und anbieterunabhängig (zum größten Teil) ist. Ich habe viele gute Sachen auf ESB gefunden um IBMs Website stoßen. Es gibt auch einige anständige Infos und Videos und Sachen über im BizTalk Website .

Schauen Sie sich diese Hansel Podcast . Es beantwortet ein paar Fragen, die Sie wirklich, sich vor der Implementierung eines Service-Bus stellen sollten.

Ein Enterprise Service Bus (ESB) ist eine Software-Architektur für die Middleware, die für komplexere Architekturen grundlegende Dienste zur Verfügung stellt. Zum Beispiel enthält ein ESB die Eigenschaften erforderlich, um eine serviceorientierte Architektur (SOA) zu implementieren. In einem allgemeinen Sinne kann ein ESB gedacht wird als ein Mechanismus, der eine einzige, einfach zu präsentieren verwaltet und konsistente Schnittstelle zu den Endnutzern über Web- oder den Zugriff auf Anwendungen und Dienste (insbesondere ältere Versionen) formularbasierte Client-Seite Frontends.

Im Wesentlichen ist ESB für verteilte heterogene Backend-Dienste und -Anwendungen und verteilte heterogene Front-End-Anwender und Informationskonsumenten WHAT Middleware soll wirklich tun: Komplexität verbergen, den Zugang zu erleichtern, ermöglichen es Entwicklern, generic, der Abfrage kanonischen Formen zu verwenden, , den Zugang und die Interaktion, die komplexen Details im Hintergrund Handhabung. Der Schlüssel zum ESB Attraktivität und möglicherweise auch den zukünftigen Erfolg liegt in seiner Fähigkeit, inkrementellen Service und Anwendungsintegration zu unterstützen, wie von Geschäftsanforderungen angetrieben, wie nicht verfügbarer Technologie geregelt.

http://searchsoa.techtarget.com/definition/enterprise-service-bus

Enterprise Service Bus (Produkt)

WSO2 Enterprise Service Bus (ESB) 4.7.0 Dokumentation! WSO2 ESB ist ein schnell, leicht, 100% Open Source und benutzerfreundlich ESB unter der v2.0 Software-Lizenz Apache verteilt. WSO2 ESB ermöglicht es Systemadministratoren und Entwickler bequem Message-Routing, Vermittlung, Transformation, Protokollierung, Aufgabenplanung, Failover, Load-Balancing und konfigurieren. Es unterstützt die am häufigsten Enterprise Integration Patterns verwendet (EIP) und ermöglicht Transportumschaltung, Vielseitigkeits, regelbasierte Vermittlung und prioritätsbasierte Vermittlung für erweiterte Integrationsanforderungen. Die ESB-Laufzeit ist so konzipiert, vollständig asynchron, nicht blockierend zu sein, und auf der Apache Synapse Mediations Engine basiert Streaming.

WSO2 ESB ist auf der revolutionären WSO2 Carbon-Plattform entwickelt, ein OSGi-basiertes Framework, die für Ihre SOA über Komponentisierung nahtlose Modularität bietet. Es enthält viele Funktionen und optionale Komponenten (Add-ons), die Sie in der ESB installieren können, und Sie können leicht Features entfernen in Ihrer Umgebung nicht erforderlich, wodurch Sie in vollem Umfang anpassen und Schneider WSO2 ESB Ihre genaue SOA Anforderungen gerecht zu werden.

Architektur Anwendungsinfrastruktur auf den Unternehmen kann von Natur aus komplex sein, mit Hunderten von Anwendungen mit völlig unterschiedlicher Semantik. Einige dieser Anwendungen speziell angefertigten sind, werden einige von Dritten erworben, und einige können eine Kombination aus beidem sein und kann in unterschiedlichen Systemumgebungen in Betrieb sein.

Integration zwischen diesen heterogenen Anwendungen ist für das Unternehmen von entscheidender Bedeutung. Verschiedene Dienste können unter Verwendung unterschiedlicher Datenformate und Kommunikationsprotokolle sein. Physische Standorte von Dienstleistungen können beliebig geändert werden. All diese Einschränkungen bedeuten, dass Ihre Anwendungen sind immer noch eng miteinander verbunden sind. Ein ESB verwendet werden, können diese Kopplungen zwischen verschiedenen Diensten und Dienst Verbraucher zu lösen.

WSO2 ESB ist ein vollwertiges, Enterprise-Ready ESB. Es basiert auf dem Apache Synapse-Projekt gebaut, die das Apache Axis2 Projekt gebaut verwendet. Alle Komponenten werden als OSGi-Bundles gebaut.

Werfen Sie einen Blick auf meine Präsentation " die Qual der Wahl - Wie Sie den richtigen ESB wählen".

ich erklären, wenn ein ESB, Integration Suite zu verwenden, oder einfach nur eine Integration Framework (wie Apache Camel). Ich diskutiere auch die Unterschiede zwischen Open Source und proprietären ESBs.

gibt es null Grund eine ESB zu verwenden. Tun Sie es nicht. Unnötig Komplexität. Warum über einen Vermittler gehen, wenn Sie direkt gehen können? Die ESB Leute werden Sie sagen, Punkt zu Punkt schlecht ist, noch irgendwie zu und von den ESB Punkt zu Punkt ist gut.

Die erste Frage, die Sie sich stellen müssen, ist, warum brauchen Sie einen ESB?

ESB ist in der Regel in dem Ereignisse SOA verteilten Architekturen verwendet, die ein heißes Modewort heute zu sein scheinen. Bevor Sie in ESB springen lassen Sie mich Ihnen von Martin Fowler Erstes Gesetz erinnern Systeme zu verteilen:

http://martinfowler.com/bliki/FirstLaw.html

"Mein erstes Gesetz verteilter Objektgestaltung. Sie Ihre Objekte nicht verteilen (von P von EAA)

Das entsprechende Kapitel ist online verfügbar. "

Wenn Sie ein neues System sind zu bauen, ist der wichtigste Aspekt ist, dass es zukunftssicher ist, die einfache Skalierbarkeit und Wartbarkeit bedeutet. Wenn Sie Ihr System um das Konzept der losgebunden Dienste mit statischem definiert Vertrag in einer vernetzten Umgebung verteilt bauen, können Sie „verstecken“, um die Architektur, die Sie für diesen speziellen Service wünschen, weil die Schnittstellen noch da sind.

ESB nahe asyn Messaging-Systeme im Zusammenhang, so, bevor Sie springen beginnen in diese Art der Implementierung, weiß, dass eine Architektur nicht sein muss homogen, dh alle Dienstleistungen die gleiche Art und Weise implementiert werden, dont die größte starten Fehler, die Ihr System von Anfang verteilt, sollten Sie nur verteilen, wie Sie skalieren müssen, nicht vor der Hand. Was Sie brauchen, wenn Sie sicher zu machen, ist, dass Ihre Dienste der Lage sein, sollte die Notwendigkeit entstehen, ohne Verträge zu brechen, die bedeuten würde, Änderungen an Kunden dieser Dienstleistung leicht verteilt werden sollte.

Wie für die Vorteile der ESB, sie sind die gleichen wie SOA, ESB fügt den Kontext asyn Meldungen (Events) Operationen.

Lassen Sie mich zuerst erklären SOA . Es es um den Aufbau eine Architektur als eine Reihe von wiederverwendbarer Software-Module ausgesetzt als „Service“ mit klar definierten Schnittstellen. Die Dienste erleichtern lose Kopplung und abstrahiert ihre Implementierungsdetails von den Kunden.

SOA könnte Ende-up chaotisch, wenn jede Komponente auf Dienste direkt aufgerufen. Daher hat es sich häufig gestellte Fragen folgen.

Wie finden Sie, welche Dienste verwendet werden und welche nicht?
Wie finden Sie die Kunden auf einen bestimmten Dienst verwenden?
Wie Sie Updates zu einem Dienst ausrollen kann oder neue Versionen ohne Unterbrechung der bestehenden Dienste aussetzen?
Wie unterstützen Sie die Abwärtskompatibilität für ältere Clients Aufruf ältere Service-Schnittstellen
Wie führen Sie die Protokollierung, Prüfung, Durchsetzung von Sicherheitsrichtlinien usw. über alle Dienstleistungen für den internen / externen Datenverkehr?

Die ESB ist die Lösung , um über Fragen. ESB ...

Hilft bringt, um
Kann streng Unternehmensrichtlinien erzwingen
- z. Sicherheit, Drosselung, Revision usw. konsequent angewandt
virtualisiert Service-Endpunkte
- Erleichtern Versionierung, flexible Updates, HA / Load Balancing etc.
Führen Sie Routing, Vermittlung, Transformation, usw.

Einige Anwendungsfälle Probe gefunden werden kann

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow