it-swarm.com.de

Vorteile eines Enterprise Service Bus

Wo finde ich Informationen zu Einsatz und Nutzen eines Enterprise Service Bus (ESB)?

Ich suche nach Informationen zu:

  1. die Art von Problemen und ESB hilft bei der Lösung
  2. die Alternativen zu einem ESB - und die Kompromisse bei der Auswahl zwischen ihnen
  3. was Sie als Entwickler tun müssen, um ESB-kompatible Systeme zu erstellen

Ich suche nach mehr Details als nur Wikipedia oder Online-Marketingbroschüren von Anbietern. Im Idealfall würde ein Beispielcode helfen zu klären, was es heißt, einen ESB zu nutzen. Informationen aus einer .NET- oder Java-Perspektive wären am nützlichsten.

Vielen Dank.

28
LBushkin

Ich würde vorschlagen, dass Um ESB oder nicht ESB zu beginnen, vom Ersteller von Mule geschrieben.

22
Mirko N.

ESBs sind eine gute Möglichkeit, Enterprise Integration Patterns zu implementieren. 

Arten von Problemen, zu deren Lösung ein ESB beiträgt

  • Sie haben eine Reihe von Protokollen, die Sie auf ein einzelnes Protokoll normieren möchten (z. B. FTP, E-Mail, SOAP, XMPP usw. für ein Nachrichtensystem), z. ActiveMQ. Auf diese Weise können Sie die Implementierung von Diensten vom Protokoll abkoppeln.
  • Sie möchten eine konsistente Methode zum Einbinden von Diensten in diese Architektur, um auf Nachrichten zu warten, Nachrichten zu verarbeiten und Nachrichten zu generieren (Nachrichtenendpunkte, Kanaladapter usw.).
  • Möglicherweise möchten Sie, dass ein verwalteter Container diese verschiedenen Komponenten bereitstellt (z. B. ServiceMix, Mule).
  • Möglicherweise möchten Sie eine Reihe von vorgefertigten Komponenten und Adaptern für verschiedene Protokolle verwenden (z. B. haben ServiceMix, Mule und Camel viele vorgefertigte Komponenten).
  • Möglicherweise benötigen Sie lange laufende Workflows. Business Process Management wird häufig zusammen mit einem ESB bereitgestellt (Apache ODE wird in eine Reihe von Open Source-ESBs eingesteckt).

Alternativen zu einem ESB

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

  • Um verteilte Dienste bereitzustellen, verwenden Benutzer häufig Anwendungsserver, die Dienste über ein Punkt-zu-Punkt-RPC-Protokoll (z. B. EJBs über RMI oder Webservices über HTTP) bereitstellen. Anstatt eine Nachricht auf einen 'Bus' zu legen, ruft ein Client also einen Server direkt an.
  • Um auf bestimmte Protokolle zu reagieren, können Sie einfach einen Client erstellen, der auf dieses Protokoll reagiert, z. B. eine Anwendung schreiben, die auf E-Mails mit JavaMail wartet oder auf XMPP mit Smack. Wenn Ihr Problem auf ein oder zwei Protokolle beschränkt ist, lohnt es sich möglicherweise nicht, einen vollständigen ESB einzubringen.

Was Sie als Entwickler tun müssen, um ESB-kompatible Systeme zu erstellen

Dies hängt von dem von Ihnen ausgewählten ESB ab, auch wenn die meisten guten Geräte für alle Arten von Protokollen und Host-POJOs ausgelegt sind, sollten Sie nicht unbedingt ESB-kompatible Systeme erstellen. Es lohnt sich zu versuchen, Ihren Code asynchron zu machen.

Zum Beispiel hat Apache Camel wahrscheinlich die prägnanteste Konfiguration. Hier ist ein Tutorial

19
Jamie McCrindle

Drei wesentliche Vorteile:

  • Über einen Bus können Endpunkte miteinander verbunden werden, ohne direkt miteinander sprechen zu müssen. Es vereinfacht die Kommunikationfür die Endpunkte, da sie nur einer Standard-Kommunikationsschnittstelle, dem Bus, entsprechen müssen. (Dies gilt für jeden technischen Bus, nicht nur für ESBs).
  • Ein ESB stellt ein single place) bereit, um einige wichtige Endpunktmetriken zu erhalten: Häufigkeit, Verfügbarkeit und Leistung.
  • Ein ESB bietet tendenziell mehr als eine Kommunikationsschnittstelle. Ein Entwickler muss jedoch nur den einfachsten auswählen, um die Daten vom Bus zu erhalten und zu empfangen.

Stellen Sie jedoch sicher, dass diese Geschäftswert für Ihre Situation bieten. Mit einem ESB erhält Ihr Unternehmen eine weitere Komplexität. Idealerweise sollten Sie dies nicht auf Basis einiger Anwendungen auswählen, sondern der gesamten Organisation. Es sollte nur one production ESB-Cluster für die Organisation geben.

Alternativen:

  • Verbinden Sie einfach Dinge direkt miteinander, insbesondere wenn die Kommunikationsprotokolle gleich sind. Dies ist gut für einfache Anwendungscluster und erfordert nicht zu viel Nachdenken. Mit der Anzahl Ihrer Anwendungen wird es jedoch schwierig, die Verbindungen aufrechtzuerhalten.
  • Eine andere Alternative ist eine MQ-Implementierung. Dadurch haben Sie die Möglichkeit, Daten zu verschieben, ohne komplexe Verbindungen zu haben. Sie müssen dann jedoch nur einen Kommunikationskanal verwenden. Zum Glück für Java haben sie den JMS-Standard.

Praktikabilität:

Ich habe die möglichen Alternativen angegeben. Sie mögen auf den ersten Blick miserabel erscheinen, aber es heißt nicht, dass Sie nicht so anfangen können. Ich persönlich schreibe Dinge, um direkt mit der Fernbedienung zu sprechen, ohne eine ESB zu durchlaufen, um sicherzustellen, dass sie funktioniert, ohne sich zu viele Gedanken über Integrationsprobleme zu machen.

Wenn Sie keinen ESB haben, sollten Sie Mule for Development und WebSphere ESB für Test und Produktion ausprobieren. Ich neige dazu, zwei Produkte zu verwenden, die angeblich Standards befolgen, um sicherzustellen, dass wir die Hersteller ehrlich halten und sicherstellen, dass Ihre Entwickler die Standards einhalten, um ein versehentliches Einkoppeln der Anbieter zu verhindern.

Beantworten Sie am Ende einfach die folgende Frage: Fügt die Zeit etwas Komplexität hinzu, um andere Komplexitäten zu vereinfachen, die Ihr Unternehmen langfristig wert ist?

7

Neben den bereits erwähnten Standorten. Sie sollten diesen Artikel lesen über " Verwenden Sie keine ESB, es sei denn, Sie müssen unbedingt ". Es wurde vom CTO von MuleSource geschrieben, einem der beliebtesten verfügbaren Open-Source-ESBs. Nicht gerade eine Antwort auf Ihre Frage, sondern eher die Frage, ob ich einen ESB brauche?

6
Robin

Es gibt eine anständige 3-teilige Serie bei IBM in Bezug auf ESB, die ziemlich konzeptorientiert und (meist) herstellerunabhängig ist. Ich habe viele gute Sachen auf ESB gefunden, als ich auf der IBM-Website herumstocherte. Auf der BizTalk-Site gibt es auch ein paar anständige Informationen und Videos und Sachen.

3
JP Alioto

Ein Enterprise Service Bus (ESB) ist eine Softwarearchitektur für Middleware, die grundlegende Dienste für komplexere Architekturen bereitstellt. Beispielsweise enthält ein ESB die Funktionen, die zur Implementierung einer serviceorientierten Architektur (SOA) erforderlich sind. Im Allgemeinen kann ein ESB als ein Mechanismus betrachtet werden, der den Zugriff auf Anwendungen und Dienste (insbesondere ältere Versionen) verwaltet, um Endbenutzern eine einzige, einfache und konsistente Schnittstelle über eine web- oder formularbasierte Client-Seite bereitzustellen vordere Enden.

Im Wesentlichen leistet ESB für verteilte heterogene Back-End-Dienste und -Anwendungen sowie für verteilte heterogene Front-End-Benutzer und Informationskonsumenten, was Middleware wirklich tun soll: Komplexität ausblenden, Zugriff vereinfachen, Entwicklern die Verwendung generischer, kanonischer Abfragen, Zugriffs- und Zugriffsmöglichkeiten ermöglichen Interaktion, Umgang mit den komplexen Details im Hintergrund. Der Schlüssel für die Attraktivität des ESB und möglicherweise auch für dessen zukünftigen Erfolg liegt in der Fähigkeit, die inkrementelle Service- und Anwendungsintegration zu unterstützen, die von den geschäftlichen Anforderungen abhängt und nicht von der verfügbaren Technologie bestimmt wird.

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

WSO2 Enterprise Service Bus (Produkt)

WSO2 Enterprise Service Bus (ESB) 4.7.0 Dokumentation! WSO2 ESB ist ein schnelles, leichtes, 100% Open Source und benutzerfreundliches ESB, das unter der Apache Software License v2.0 vertrieben wird. Mit WSO2 ESB können Systemadministratoren und Entwickler das Nachrichtenrouting, die Mediation, die Umwandlung, die Protokollierung, die Taskplanung, das Failover, die Lastverteilung und vieles mehr bequem konfigurieren. Es unterstützt die am häufigsten verwendeten Enterprise Integration Patterns (EIPs) und ermöglicht Transportumschaltung, Ereignisse, regelbasierte Mediation und prioritätsbasierte Mediation für erweiterte Integrationsanforderungen. Die ESB-Laufzeit ist vollständig asynchron, nicht blockierend und basiert auf dem Apache Synapse-Mediationsmodul.

WSO2 ESB wurde auf der revolutionären WSO2 Carbon-Plattform entwickelt, einem OSGi-basierten Framework, das eine nahtlose Modularisierung Ihrer SOA über die Komponentenisierung ermöglicht. Sie enthält viele Funktionen und optionale Komponenten (Add-Ons), die Sie im ESB installieren können, und Sie können leicht Funktionen entfernen, die in Ihrer Umgebung nicht erforderlich sind. So können Sie WSO2 ESB vollständig anpassen und an Ihre genaue SOA anpassen. braucht.

Architektur Die Anwendungsinfrastruktur in Unternehmen kann von Natur aus komplex sein und Hunderte von Anwendungen mit völlig unterschiedlicher Semantik umfassen. Einige dieser Anwendungen werden kundenspezifisch erstellt, andere werden von Drittanbietern erworben, und einige können eine Kombination aus beiden sein und können in verschiedenen Systemumgebungen betrieben werden.

Die Integration dieser heterogenen Anwendungen ist für das Unternehmen von entscheidender Bedeutung. Verschiedene Dienste verwenden möglicherweise unterschiedliche Datenformate und Kommunikationsprotokolle. Physische Standorte von Diensten können sich beliebig ändern. Aufgrund all dieser Einschränkungen sind Ihre Anwendungen immer noch eng miteinander verbunden. Ein ESB kann verwendet werden, um diese Kopplungen zwischen verschiedenen Diensten und Dienstkonsumenten zu lösen.

WSO2 ESB ist ein vollwertiger, betriebsbereiter ESB. Es basiert auf dem Apache Synapse-Projekt, das mit dem Apache Axis2-Projekt erstellt wird. Alle Komponenten sind als OSGi-Bundles aufgebaut.

Schauen Sie sich diesen Hanselminutes-Podcast an . Sie beantwortet einige Fragen, die Sie sich vor der Implementierung eines Servicebusses unbedingt stellen sollten.

2
Igor Zevaka

Werfen Sie einen Blick auf meine Präsentation " Die Qual der Wahl - Wie wähle ich die richtige ESB ". 

Ich erkläre, wann ein ESB, eine Integration Suite oder nur ein Integration Framework (wie Apache Camel) verwendet wird. Ich diskutiere auch die Unterschiede zwischen Open Source und proprietären ESBs.

1
Kai Wähner

Die erste Frage, die Sie sich stellen müssen, lautet: Warum brauchen Sie einen ESB?

ESB wird normalerweise in verteilten Architekturen von Event SOA verwendet, die heutzutage ein heißes Schlagwort zu sein scheinen. Bevor Sie in die ESB einsteigen, möchte ich Sie an Martins Fowler First Law of Distributed Systems erinnern:

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

"Mein erstes Gesetz zum Design verteilter Objekte: Verteilen Sie Ihre Objekte nicht (von P der EAA).

Das entsprechende Kapitel ist online verfügbar. "

Wenn Sie ein neues System erstellen, ist der wichtigste Aspekt, dass es zukunftssicher ist. Dies bedeutet einfache Skalierbarkeit und Wartbarkeit. Wenn Sie Ihr System auf das Konzept loser Dienste mit statisch definierten Vertragsbedingungen in einer Netzwerkumgebung aufbauen, können Sie die gewünschte Architektur für diesen bestimmten Dienst "ausblenden", da die Schnittstellen noch vorhanden sind.

ESB ist eng mit asynchronen Messagingsystemen verwandt. Bevor Sie also in diese Art von Implementierung einsteigen, müssen Sie wissen, dass eine Architektur nicht homogen sein muss. Das heißt, dass alle Dienste auf die gleiche Weise implementiert werden, beginnen Sie nicht mit dem größten Fehler Wenn Sie Ihr System von Anfang an verteilen, sollten Sie nur so verteilen, wie Sie es benötigen, nicht vorher. Sie müssen jedoch sicherstellen, dass Ihre Dienste bei Bedarf leicht verteilt werden können, ohne dass Verträge gebrochen werden, die Änderungen an den Kunden dieses Dienstes bedeuten würden.

Die Vorteile von ESB sind dieselben wie bei SOA. ESB fügt den Kontext von asynachrichten (ereignissen) hinzu.

0
MeTitus

Einen sehr kurzen Überblick über die Vorteile eines ESB finden Sie hier:

http://javaenterpriseworld.blogspot.de/2014/02/benefits-of-esb.html

Die Hauptprofis sind grob aufgelistet ...

0
leon4

es gibt keinen Grund, einen ESB zu verwenden. Tu es nicht. Unnötige Komplexität. Warum durch einen Vermittler gehen, wenn Sie direkt gehen können? Die ESB-Leute werden Ihnen sagen, dass Punkt zu Punkt schlecht ist, aber Punkt zu Punkt vom und zum ESB ist gut.

0
user671731
0
Albert Cheng

Lassen Sie mich zuerstSOAerklären. Es ging darum, eine Architektur als eine Reihe wiederverwendbarer Softwaremodule aufzubauen, die als "Services" mit genau definierten Schnittstellen bereitgestellt werden. Die Dienste erleichtern die lose Kopplung und abstrahieren die Implementierungsdetails von den Kunden.

SOA kann enden, wenn jede Komponente Dienste direkt anruft. Daher gibt es folgende Probleme.

  • Wie finden Sie welche Services verwendet werden und welche nicht?
  • Wie finden Sie die Kunden, die einen bestimmten Dienst verwenden?
  • Wie stellen Sie Updates für einen Dienst bereit oder setzen Sie neue Versionen ohne Unterbrechung für vorhandene Dienste bereit?
  • Wie unterstützen Sie die Abwärtskompatibilität für ältere Clients, die ältere Service-Schnittstellen aufrufen?
  • Wie führen Sie Protokollierung, Überwachung, Durchsetzung von Sicherheitsmaßnahmen usw. für alle Dienste für internen/externen Datenverkehr durch?

Der ESB ist die Lösung zu den oben genannten Problemen. ESB…

  • Hilft bringt Ordnung
  • Kann Unternehmensrichtlinien strikt durchsetzen
    • z.B. Sicherheit, Throttling, Audit usw. werden konsequent angewendet
  • Virtualisiert Serviceendpunkte
    • Erleichterung der Versionierung, flexibler Updates, HA/Load Balancing usw.
  • Führen Sie Routing, Mediation, Transformation usw. Durch

Einige Anwendungsbeispiele finden Sie hier . Beachten Sie, dass sie von der AdroitLogic-Entwicklerseite stammen und streng mit UltraESB, dem ESB von AdroitLogic, gekoppelt sind. 

0