PortalDerWirtschaft.de



Suchmaschinenoptimierung mit PdW
mit Content-Marketing - Ihre News
English

Sonic Software gibt Whitepaper mit umfassender Definition eines Enterprise Service Bus heraus


Von Sonic Software

Sonic ESB: An Architecture and Lifecycle Definition

Thumb Köln, den 13. Dezember 2005 - Sonic Software, Erfinder und führender Anbieter des Enterprise Service Bus (ESB) und eine Geschäftseinheit von Progress Software Corporation, gibt die erste umfassende, technische Definition für den ESB heraus. Das Whitepaper "Sonic ESB: An Architecture and Lifecycle Definition " stellt sowohl die Leistungsmerkmale als auch die Funktionsweise eines ESBs von der Entwicklung bis zum Betrieb auf Basis von Sonic Softwares marktführendem Sonic ESB dar. Die deutsche Übersetzung des Sonic White Paper finden Sie am Ende dieser Pressemitteilung. Die englische Version unter: www.sonicsoftware.com/esb_defined/. Das White Paper enthält: - Ein umfangreiches und eindeutiges Vokabular in einer Technikkategorie, die mit sich widersprechender Terminologie überfrachtet ist; - Eine genaue technische Referenz für eine umfassende ESB-Implementierung; - Eine solide Basis für den Vergleich zwischen früheren Technologiegenerationen, partiellen ESBs und dem dargestellten ESB-Referenzmodell. Die "Sonic ESB: An Architecture and Lifecycle Definition " ist eine technische Erklärung der architektonischen Hauptkomponenten des Sonic ESBs. Das Whitepaper nutzt mehr als zwanzig UML-Klassen (Unified Modeling Language) und Objektdiagramme zur Beschreibung der Struktur und für Beispiele, wie der ESB aufgebaut ist und funktioniert. So soll Architekten das nötige Wissen über die inneren Zusammenhänge eines ESBs vermittelt werden. Der Anhang enthält ein vollständiges Klassendiagramm sowie ein Glossar mit 100 Begriffen als Referenzmodell, um Unternehmen bei der Entwicklung einer ESB-Strategie zu unterstützen. "Dieses Referenzmodell liefert exakte Begriffe und strukturelle Definitionen für einen ESB, der sich in der Praxis bei mehr als 250 Kunden bewährt hat", erklärt Hub Vandervoort, Chief Technical Officer bei Sonic Software. "Das Whitepaper vermittelt ein klares Verständnis der wichtigsten architektonischen Unterscheidungsmerkmale eines ESBs und zeigt, wie diese Charakteristiken eine optimale Plattform für das verteilte, serviceorientierte Computing ermöglichen. Es ist an der Zeit, die vagen Vorstellungen über ESBs durch eine genaue Definition zu ersetzen, mit deren Hilfe Anwender die unvollständigen ESBs von den echten unterscheiden können." Über Sonic Software Sonic Software ist der Erfinder und führende Anbieter des Enterprise Service Bus (ESB). Diese neue Kommunikations- und Integrationsinfrastruktur bietet Unternehmen die notwendigen Vorraussetzungen für eine serviceorientierte Architektur (SOA). Zur Integration und Steuerung verteilter unternehmenskritischer Prozesse bieten Sonics Technologien die erforderliche Skalierbarkeit, Sicherheit und ständige Verfügbarkeit. Mehr als 1.000 Kunden setzen auf die Lösungen von Sonic Software und erzielen so Flexibilität und Interoperabilität ihrer IT-Systeme, um diese den sich ständig verändernden Geschäftsprozessen anzupassen. Sonic Software ist ein Tochterunternehmen der Progress Software Corporation (NASDAQ: PRGS), die mit über 360 Millionen US-Dollar Jahresumsatz zu den führenden Software-Anbietern zählt. Weitere Informationen zu Sonic Software, mit Hauptsitz in Bedford, Mass., USA, finden Sie unter: www.sonicsoftware.com Sonic ESB und Sonic Software (einschließlich des Firmenlogos) sind in den USA sowie in anderen Ländern (eingetragene) Warenzeichen der Sonic Software Corporation. Alle anderen in dieser Veröffentlichung verwendeten Warenzeichen oder Dienstleistungsmarken sind Eigentum der jeweiligen Unternehmen. Für weitere Informationen, Grafikmaterial oder Gesprächsvereinbarungen mit Sonic Software stehen wir Ihnen gerne zur Verfügung. Ihr LTC Sonic-Team Lucy Turpin Communications GmbH Eva Hildebrandt / Sybille Bloech Prinzregentenstr. 79 81675 München Tel.: +49 89 417761-14 / -35 Fax: +49 89 417761-11 Email: E.Hildebrandt@LucyTurpin.com S.Bloech@LucyTurpin.com *********************** Whitepaper Eine kurze Einführung Der Sonic ESB - Definition der Architektur und des Lifecycles Einführung: Serviceorientierte Architekturen (SOA) werden von immer mehr mittleren und großen Unternehmen als bevorzugter System- und Softwareansatz eingesetzt, stellt Randy Heffner, Analyst von Forrester Research, in "Delivering Real World SOA" fest. Den SOA-Prinzipien zufolge geschieht die Entwicklung, die Implementierung und der Betrieb von Informationssystemen auf der Grundlage von Komponenten, die Geschäftsfunktionen darstellen und implementieren. Diese Komponenten – Dienste oder Services genannt – lassen sich über geografische und Unternehmensgrenzen hinweg verteilen. Sie können unabhängig voneinander skaliert und nach Bedarf in neue Geschäftsprozesse eingebunden werden. Diese Flexibilität bietet eine Reihe von Vorteilen sowohl für die IT als für das gesamte Unternehmen. Abbildung 1: Beispiel eine SOA-Applikation Die Abbildung 1 zeigt als Beispiel eine SOA, die für die Integration und Mediation eines Multi-Channel-Prozesses im Finanzhandel genutzt wird. Diese Implementierung stellt eine Kombination aus bestehenden Systemen, die mit einer Services-Schnittstelle "verpackt" sind, und neuen Diensten dar, die zur Verbesserung des Geschäftsprozesses erzeugt wurden. Das Beispiel verdeutlicht, wie die Datenelemente eines Auftrags im Wertehandel aus einem Order Management Service so umgewandelt werden, dass sie den Anforderungen des Trading und Compliance Services entsprechen. Im weiteren Prozessablauf wird ein Trigger für einen Geldtransfer vom Funds Transfer Service angestoßen und der Auftrag schließlich als ausgeführte Transaktion im Logging Service abgelegt. Der Trade-Prozess wird nicht als integrierte Anwendung ausgeführt, sondern als eine Sequenz von heterogenen Prozessschritten, die von der SOA-Infrastruktur koordiniert werden. Das Herzstück der SOA-unterstützenden IT-Infrastruktur ist der Enterprise Service Bus (ESB), der die gesamte Kommunikation und Interaktion zwischen den Services vermittelt und zusammenfügt. Im vorgestellten Beispiel liefert der ESB die Konnektivität einschließlich des Routings zwischen den Diensten, die Umwandlung der XML-Daten, um die Kommunikation zwischen Services mit unterschiedlichen Schnittstellen zu ermöglichen, und die Abfolge der Dienste für den Geschäftsprozess. Angesichts des Stellenwerts, den der ESB in einer SOA-Implementierung hat, und seiner Auswirkungen auf Kosten, Entwicklungs- und Deployment-Prozesse ist es unerlässlich, die Funktionen und die Struktur des ESBs im Detail zu verstehen. Ebenso wichtig ist die Kenntnis darüber, wie sein Design schnelle Änderungen, einfache Konnektivität und deutliche Visibilität sowie Kontrolle der Services und Prozesse in einer SOA-basierten Anwendung ermöglicht. Sonic Software ist der Erfinder des ESBs und führender Anbieter von ESB-Funktionalität. Weitere Produkte der Sonic SOA-Infrastrukturfamilie ergänzen den Service Bus. Dazu gehören seine Workbench, der Orchestration Server, XML Server, Collaboration Server und der Database Service. Um eine vollständige ESB-Definition zu geben, wird jeder Funktionsbereich des ESBs mit seinen Funktionen und Vorteilen dargestellt. Strukturdiagramme auf der Grundlage des Industriestandards UML (Unified Modeling Language) ergänzen die Ausführungen, und UML-Klassendiagramme liefern eine eindeutige Architekturdefinition für den ESB. Die Abbildung 1 nutzt eine Notation für die ESB-Diagramme, die Dave Chappell in seinem Buch "Enterprise Service Bus" eingeführt hat. Services, Kommunikation und Mediation Die Unterstützung von Diensten und ihrer Kommunikationsmittel ist entscheidend für eine SOA. Abbildung 2 zeigt ein UML-Klassendiagramm mit einer Übersicht über die ESB-Strukturen, die Dienste, Kommunikationsmittel und die Mediation unterstützen. Die Abbildung besteht aus drei Teilen: Abbildung 2: Architektur für Services, Kommunikation und Mediation ESB-Services (links in Abb. 2): Sie können unterschiedlichen Typs sein. Typische ESB-Services, die Mediation implementieren, sind XML Transformation, Content-Based Routing und User Defined Mediation. Die Aufgabe eines XML Transformation Services ist die Datenumwandlung gemäß der XSLT-Spezifikation von einem XML-Dokument in ein anderes. Ein Content Based Routing Service leitet Nachrichten aufgrund von festgelegten Routing-Regeln an verschiedene andere Service-Endpunkte weiter. Ein benutzerdefinierter Mediation Service implementiert eine Funktion wie Logging-Validierung und ergänzt somit die grundlegende Geschäftslogik. Ein benutzerdefinierter ESB-Service nimmt Verbindung mit Geschäftsdiensten auf, um grundlegende Business-Logik zu implementieren. Diese Services arbeiten innerhalb des ESB-Containers. Dieser erzeugt die Instanzen der Dienste und liefert die Systemmanagement-Schnittstelle für die Services und übernimmt das Management der Kommunikationsprotokolle. Er bietet auch die Fähigkeit, mit mehreren Threads die Ausführung der Services zu skalieren, und eine Standardmöglichkeit, verteilte Prozesse zu verarbeiten. Connected Business Services (rechts in Abb. 2): Diese Dienste implementieren die Geschäftslogik für ESB-integrierte Anwendungen. Dazu gehören Web Services, Legacy-Systeme, JMS-Anwendungen (Java Message Service) und eine Vielfalt an Application-Server-Applikationen. Jeder dieser Business Services kann über den ESB sowohl mit jedem anderen kommunizieren als auch mit ESB-Services, um zu vermitteln. In der Abbildung 1 ist der Order Management Service ein über eine HTTP-Verbindung eingebundener Connected Service. Der Compliance Service, Trading Service und Funds Transfer Service sind Business Services, die über eine Schnittstelle direkt an den ESB als benutzerdefinierte Services angebunden sind. Kommunikations- und ESB-Prozesse (Bildmitte Abb. 2): Dieser Bereich der Abbildung 2 zeigt die Schlüsselfunktion der Services (sowohl ESB als auch Business), nämlich einen ESB-Prozess zu kommunizieren und auszuführen, der aus einer Abfolge von Schritten besteht, die Services oder andere ESB-Prozesse aufrufen. Abbildung 1 zeigt einen ESB-Prozess namens Trading Process, der aus fünf Schritten besteht. Ein ESB-Service sendet und empfängt Nachrichten, und zwar durch Bezugnahme auf ESB-Endpunkte und -Adressen. Beispielsweise kann ein ESB-Service (wie der Compliance Service in Abbildung 2) seinen Exit so konfigurieren, dass er eine Referenz auf die ESB-Adresse eines anderen Dienstes herstellt, der dann die Output-Nachrichten erhält – im Beispiel wäre das der Trading Service. Alternativ kann sich die ESB-Adresse auf einen ESB-Prozess beziehen. Ein ESB-Prozess wird durch eine so genannte ESB Itinerary (Transportweg) definiert, die aus einer Abfolge von Prozessschritten besteht. Jeder Schritt kann einen oder mehrere ESB-Services, weitere Prozesse oder einen externen Web Service aufrufen. Die Wegroute besitzt eine angefügte Nachricht, die eine komplett verteilte und zuverlässige Ausführungsumgebung für den ESB-Prozess liefert. Es gibt keine zentrale Processing Engine für die Route, denn jeder ESB-Container kann den nächsten Schritt in der ESB Itinerary ausführen oder weiterleiten. Dies gewährleistet sowohl eine effiziente Ausführung, ohne die Notwendigkeit mit einer zentralen Stelle zu kommunizieren, als auch Zuverlässigkeit, weil die Ausführung weiter gehen kann, auch wenn die Konnektivität verloren geht. Für jeden ESB-Service lassen sich die Eingangs- und Ausgangsendpunkte ändern, ohne dass Modifikationen in seiner Implementierung erforderlich sind. ESB-Endpunkte liefern die erforderliche Funktionalität für ESB-Services, Nachrichten mit einer festgelegten Quality-of-Service zu senden und zu empfangen. Beispiele dafür sind “best-effort”, “reliable” oder “guaranteed, once-and-only-once”. Die Verbindung bestimmt, welcher Nachrichtenkanal von einem Endpunkt verwendet wird, um Verbindung mit einem ESB- oder Business- Service aufzunehmen. Der Nachrichtenkanal kann eine ESB-native Verbindung oder für externe Systeme eine Web-Service-Verbindung, JMS oder JCA-Adapter (J2EE Connector Architecture) nutzen. Die ESB Connection verwendet konfigurierbare asynchrone und synchrone Auslieferungssemantik, etwa “publish-and-subscribe”, “send-and forget” oder “request-reply”. Im Beispiel ist die Verbindung zwischen dem Order Management Service und dem Trading-Prozess als Web Service Request-Reply angegeben. Muss ein Business oder ESB-Service die Verbindungsart ändern, so kann dies ohne Änderungen seiner Implementierung geschehen. Benötigen Services verschiedene Arten der Verbindungen, so vermittelt der ESB zwischen den unterschiedlichen Protokollen. Die ESB-Message-Klasse sowie die Sender- sowie Empfänger-Abhängigkeiten zwischen dem ESB-Endpunkt und der -Nachricht bilden die Grundstruktur dafür, dass ein Dienst eine Nachricht über einen Service Dispatcher (Verteiler) an einen anderen sendet. Der Dispatcher verwaltet Senden und Empfangen von Nachrichten zwischen ESB-Services und externen Endpunkten. Im Prinzip implementiert er die in Abbildung 1 dargestellten Pfeile zwischen den Prozessschritten. Der Verteiler verwaltet auch die ESB-Prozesse. Mithilfe des Industriestandards WSDL (Web Services Definition Language) lassen sich Definitionen für ESB-Services und ESB-Prozesse erzeugen. Dadurch können Standard-Tools genutzt werden, und die Integration mit weiteren SOA-Infrastruktur-Komponenten ist möglich. In der Abbildung 1 stellt sich der gesamte Trading-Prozess als Web Service dar. Dieser Ansatz für ESB-Services, Mediation und für die Verbindung zu Geschäftsdiensten bietet zahlreiche Vorteile: •Geschäftsagilität durch breite Unterstützung von Mediation-Services einschließlich XML-Transformation und eingebauter Unterstützung für verteilte Prozesse; •Hohe Reichweite über viele Arten von Business Services und Kommunikationsprotokollen hinweg sowie Integration von heterogenen Legacy- und neuen Web-Service-Elementen; •Verteilte Prozessausführung, Performance und Zuverlässigkeit auch in stark verteilten Installationen. ESB-Entwicklung, -Einführung und Produktionsmanagement Der ESB bietet breite Unterstützung für den gesamten Lebenszyklus der Services – von der Entwicklung über die Einführung bis zum Management. Abbildung 3 zeigt ein UML-Klassendiagramm mit einem Überblick über einige der Hauptstrukturen für diese Unterstützung. Das Bild ist unterteilt, um den "Lebensweg" der ESB-Services von der Systementwicklung zu Tests und einer verteilten Produktionsumgebung zu veranschaulichen. Eine entscheidende Anforderung an die Sonic SOA Suite ist die Möglichkeit, diesen Weg auf die möglichst einfachste, fehlerfreie Art zu gestalten. Abbildung 3: Architektur für ESB Deployment und Production Management Die Abbildung besteht aus drei Teilen: Entwicklungssysteme (links im Bild) Der Kopf des Diagramms zeigt Entwicklungswerkzeuge, während der unterste Teil unter der Bezeichnung "Development ESB" die Hauptkomponenten der ESB-Infrastruktur festlegt, die in jeder Phase des ESB-Lebenszyklus benötigt werden. Die Workbench liefert für jeden Entwickler ein Tool-Set für die ESB-Entwicklung und -Einführung, einschließlich benutzerangepasster Service-Implementierungen. Der Logging-Service aus Abbildung 1 stellt ein Beispiel eines angepassten Service-Typus dar. Mithilfe eines Sets von Ressourcen-Editoren und Standard-Entwicklungsumgebungen von Drittanbietern können Entwickler Ressourcendateien erzeugen und im ESB-Repository (Konfigurations-Repository) speichern. Die Sonic Workbench liefert alle erforderlichen Elemente für das Anlegen von Entwicklungsprojekten, die alle Konfigurationsdateien für ein bestimmtes Service-Entwicklungsprojekt für eine Composite Application enthalten. Im Fall des Trading-Beispiels wären dies Dateien, die den ESB-Prozess beschreiben sowie dessen WSDL-Dateien, um den Prozess als Web Service darzustellen. Außerdem gehört die Logging-Service-Implementierung dazu. Zu den Editoren zählen der visuelle ESB Process Editor zum Erzeugen und Editieren von Geschäftsprozess-Definitionen, die mehrere Services zusammenfügen, der XLST Editor, mit dessen Hilfe das XLST-Stylesheet festgelegt wird, das die XML-Umwandlung definiert, sowie der Routing Rules Editor für die Konfigurationsdatei, die die inhaltsbasierten Routing-Dienste nutzen. Die Managementkonsole liefert das Management-Framework für die Konfiguration der Sonic SOA-Infrastruktur für die Services, die Container und die Elemente des SonicMQ Mulitprotokoll-Kommunikationsservers. Die Konsole ermöglicht die Konfiguration von neuen Service- und Container-Instanzen und unterstützt damit einen einfachen "configure-and-go"-Ansatz für das Management der SOA-Infrastruktur. Mithilfe dieser Konsole würde im Beispiel in Abbildung 1 die ESB-Verbindung zwischen allen Services des Trade-Prozesses auf "once-and-only-once" gesetzt, um den Verlust von Nachrichten zu verhindern. Staging- beziehungsweise Test-Systeme und Deployment-Tools (Bildmitte) Das Deployment-Tool dient der Überführung der Konfigurationen aus der Entwicklungsumgebung in die Test-/Staging- und dann in die Produktionsumgebung. Ausgewählte Ressourcendateien und Konfigurationen werden über Interims-Archivdateien und mithilfe des Deployment Map Files weitergegeben. Damit ist sichergestellt, dass Service- und Messaging-Parameter aufeinander abgestimmt sind und in der Zielumgebung mit abweichenden Quality-of-Service-Einstellungen, Sicherheits-Policies oder ESB-Adressen korrekt funktionieren. Das Diagramm stellt die Einführung der Konfigurationen vom Development Directory Service zum Staging/Test Directory Service dar. Produktionssysteme (rechts im Bild) Die Deployment Tools dienen auch der Einführung der ESB-Konfigurationen vom Staging/Test Directory Service zum Produktions-Repository. Die Managementkonsole installiert den ESB-Container und ihre konfigurierten Dienste in mehreren verteilten Systemen, wo Interaktions-Policies, Transport-Bindings und Sicherheits-Policies für die Kommunikationsebene festgelegt werden. Der ESB bietet zuverlässige Unterstützung für verteilte Systeme. Der Diagrammbereich "ESB Distributed" zeigt, wie ein ESB Repository Cache verwendet wird, um lokale Kopien der Konfigurationsdateien zu liefern, welche die Container und Services für die Ausführung in verteilten Systemen benötigen. Infolgedessen können verteilte Systeme hochperformant und gleichzeitig zuverlässig arbeiten. Außerdem ist damit ein unabhängiger Betrieb gewährleistet, auch wenn der Production Directory Service nicht verfügbar ist. Die gleiche Ausführungsumgebung (nicht im Bild) steht auch für die Staging-/Test- und Entwicklungsumgebung zur Verfügung. Das Vorhandensein von mehreren verteilten Systemen in einem ESB ermöglicht ein Skalieren der ESB-Service-Kapazitäten über Maschinen und geografische Grenzen hinweg. Jedes verteilte System teilt sich mit allen anderen die Konfiguration für das Fehlerreporting und das Versenden des Status zurück an die Managementkonsole. Im Beispiel des Finanzhandels-Prozesses wäre es möglich, den Umwandlungsdienst auf mehrere Ausführungsmaschinen zu replizieren, sodass bei Bedarf zwischen jedem Prozessschritt mehrere Instanzen über das Maschinennetzwerk laufen können, um Lastspitzen abzufangen. Der Administrator nutzt ESB-Dienste und -Prozesse, um das Handling solcher Fehler und Benachrichtigungsereignisse serviceorientiert zu automatisieren, und zwar in derselben ESB-Infrastruktur. Treten beispielsweise im Compliance-Service-Schritt des Trading-Prozesses Fehler auf, so wäre der normale Fault-Endpunkt dieses Dienstes so konfiguriert, dass er den Fehler zurück an den Anfrager leitet. Dafür nutzt er "Reply-to"-Parameter. Denkbar ist auch ein separater Ausnahmeprozess, der den Fehler an seinem Entry-Endpunkt erhält. Dieser Ansatz der Implementierung der ESB-Entwicklung, Einführung und des Managements bietet eine Reihe von Vorteilen: •Umfassende Entwicklungs- und Management-Tools für eine einfache Konfiguration und Einführung; •Deployment-Werkzeuge unterstützen den ESB-Lebenszyklus und ermöglichen das automatische Mapping der Konfigurationen und die Überführung der Implementierungsressourcen aus den Entwicklungs- in die Test- und Produktionsumgebungen; •Eine verteilte Ausführungsumgebung einschließlich Directory Caching ermöglichen gute Performance, Skalierbarkeit und Hochverfügbarkeit von SOA-Systemen. Schlussfolgerung Wenn ein Unternehmen eine SOA für seine Systementwicklungsarchitektur und für die Prozesse einführt, sind die involvierten Menschen, Prozesse und die Technologie dafür verantwortlich, die Ebenen des SOA Maturity korrekt zu durchlaufen – von ersten Services bis zu optimierten Geschäftsdiensten. Die Sonic SOA Suite liefert die bewährte SOA-Infrastruktur, um alle Ebenen der SOA-Reife zu unterstützen und ermöglicht sowohl Geschäftsagilität und Veränderung als auch Kostenreduzierung und Wiederverwendung. Der Sonic ESB bietet Verbindungs-, Mediation- und Kontroll-Services zusammen mit den für eine unternehmensweite SOA erforderlichen Entwicklungs-, Einführungs- und Managementwerkzeugen. Schließlich ermöglicht der Sonic ESB die für alle Reifeebenen einer Unternehmens-SOA nötige Agilität, Reichweite, Skalierbarkeit und Verfügbarkeit. Anmerkung: Gerne schicken wir Ihnen das Whitepaper im Original mit Grafiken zu

Kommentare

Bewerten Sie diesen Artikel
Bewertung dieser Pressemitteilung 5 Bewertung dieser Pressemitteilung 2 Bewertungen bisher (Durchschnitt: 3.5)
Hinweis Für den Inhalt der Pressemitteilung ist der Einsteller, Isabelle Lissel-Erhard, verantwortlich.

Pressemitteilungstext: 2537 Wörter, 21662 Zeichen. Artikel reklamieren
Keywords
Diese Pressemitteilung wurde erstellt, um bei Google besser gefunden zu werden.

Tragen Sie jetzt Ihre kostenlose Pressemitteilung ein!