Einfache und simplifizierende Antworten sind in – und genau so eine Antwort scheint der Enterprise Service Bus (ESB) auf die Frage nach SOA zu sein. Verstehen Sie mich nicht falsch: ein ESB ist eine sehr wertvolle und nützliche Komponente in einer SOA-Landschaft. Wenn Sie aber meinen, gut vorbereitet an SOA heranzugehen, nur weil Sie einen ausgeklügelten Auswahlprozess für die Beschaffung eines ESB hinter sich gebracht haben – Sie können weit daneben liegen.
Andere Perspektive: Ein ESB ist nicht gleichzusetzen mit SOA, er ist aber ihr Herzstück. Klingt schon besser, trifft den Hauptgedanken von SOA aber immer noch nicht ganz. Bei SOA geht es darum, die IT Welt in kleine Häppchen zu unterteilen. Diese sind nach den Wünschen der Fachabteilungen geformt, entsprechen Industriestandards und lassen sich zu neuen Prozessen und Anwendungen zusammensetzen. Sie müssen miteinander kommunizieren, Nachrichten austauschen, diese transformieren und sicher weiterleiten. Auch besteht die Anforderung, kleine Häppchen zu größeren zusammenfügen, womit wir bei dem Thema Orchestrierung und Komposition sind. Und hierbei hilft tatsächlich der ESB.
Doch wie kommen Sie zu den Häppchen, wer sagt der IT was Business braucht und wer sagt Business was für die IT machbar ist?
Und wer sagt Ihnen, ob die verschiedenen Häppchen so eingesetzt werden wie ursprünglich geplant? Hier geht es auf einmal nicht mehr um Middleware. Hier geht es darum, wie der Entstehungsprozess von Services gehandhabt wird, es geht um SOA Management und Governance. Ohne durchgängige Prozesse über Abteilungsgrenzen hinweg können keine Services entstehen, die es wert wären über einen ESB miteinander verknüpft zu werden. Also ist das Herzstück einer SOA doch eher auf der organisatorischen Ebene zu suchen – angereichert um Prinzipien und Best Practices zum Thema SOA Governance. Wenn diese Prozesse verstanden werden, dann macht auch der ESB für SOA sehr viel Sinn, genau so wie das HTTP Protokoll für das Internet.
Peter Kürpick
Mitglied des Vorstands
Software AG
Beiträge (Atom)
Dass man alleine mit dem Zukauf von Technologien die fachlichen und organisatorischen Schwierigkeiten nicht bewältigt klingt verständlich.
Für die Frage der Notwendigkeit eines ESB wäre eventuell Ihre ESB Definition hilfreich. Manche Definitionen sind so, dass ein einfaches EAI-Produkt ohne weiteres als ESB durchgehen würde, manche fordern speziellere Eigenschaften wie zum Beispiel queuing, publish-subscribe oder ähnliche Mechanismen. Die deutsche Wikipedia-Definition beispielsweise ist ebenfalls sehr unkonkret.
Die Minimalbedingung für eine SOA ist aus meiner Sicht eine vorhandene Infrastruktur um die Kommunikation von Services untereinander sowie zwischen Services und einem aufrufenden Client zu ermöglichen. Jedes weitere Feature beeinflusst (um bei Ihrer Analogie zu bleiben) den Herzschlag oder den Blutdurchfluss und bietet damit eventuell eine höhere Chance auf langfristiges Überleben. Die Frage nach dem optimalen Wert kann von Person zu Person unterschiedlich ausfallen.
Ich wäre an einer Sammlung von ESB-Definitionen sehr interessiert. Eigene Definitionen oder Link-Tipps gerne hier oder falls nicht erwünscht an mich persönlich.
Interessant wäre natürlich auch, ob sich die Experten oder auch die Leser hier zumindest auf eine grobe Definition oder eine Minimaldefinition einigen können.
Ich stimme Herrn Kürpick zu, dass ein ESB nicht mit SOA gleichzusetzen ist. Obwohl ein ESB von fast allen Herstellern zwischenzeitlich als Produkt vermarktet wird, ist und bleibt es ein,zugegeben wichtiges, Konzept in einer SOA. Es geht aber bei SOA aus meiner Sicht ganz und gar nicht darum, die IT in kleine Häppchen zu unterteilen sondern darum, einen IT-Weg für die Herabsetzung des Widerstands gegen Veränderung zu finden. Dabei spielt eine Betrachtung und evtl. Veränderung der Funktionsgranularität zwar eine nicht unwichtige Rolle, sie ist aber nicht eine durch SOA vorgegebene Prämisse. Zu glauben, dass wenn ich nur möglichst feingranular schneide, alle Probleme gelöst werden, hat sich schon mit dem objektorientierten Ansatz als Trugschluß herausgestellt.
Hier der Versuch einer Definition aus unserem Haus (leider in Englisch)
An enterprise service bus (ESB) is a pattern of middleware that unifies and connects services, applications and resources within a business. Put another way, it is the framework within which the capabilities of a business’ applications are made available for reuse by other applications throughout the organization and beyond. The ESB is not a new software product — it’s a new way of looking at how to integrate applications, coordinate resources and manipulate information. Unlike many previous approaches for connecting distributed applications, for example RPC or distributed objects, the ESB pattern enables the connection of software running in parallel on different platforms, written in different programming languages and using different programming models.
An enterprise service bus:
Is standards-based
Can enable all parts of a business to react instantly to new information
Minimizes risk by using industry standard interfaces and protocols
Overcomes differences in platform, software architecture and network protocols
Assures delivery of transactions, even when systems and networks go off-line
Re-routes, logs and enriches information without rewriting applications
Provides an infrastructure that is highly distributed and yet can be managed centrally
Can distribute data throughout your business and beyond to your customers and business partners
Spans different operating systems, programming models, application types and locations
Can be deployed incrementally, project by project, to better manage expense
May combine new and existing technologies and standards
Supports message, service and event oriented architecture
Gruss
Norbert
(Teil-)Antworten auf Fragen nach Veränderung vielleicht?
Die ganzen Themen im/um den Bereich SOA/ESB/EDA/XYZ drehen sich doch, richtigerweise, darum, wie die IT dem Druck nach Veränderung begegnen kann.
Insofern stimme ich Hr. Kürpick absolut zu, dass ein ESB selber keine Alleinlösung ist. Ein Herzstück mit Sicherheit, aber nicht ohne organisatorisches Rückgrat.
Wobei sich die Themen langsam auf die Bereiche “zurückziehen”, auf denen sie sinnvoll eingesetzt werden können. Damit ergibt sich für die IT die Möglichkeit, mit etablierten Standards zum Einen auf Frage nach Veränderung zu beantworten. Zum Anderen ergibt sich aber auch die Möglichkeit, diese Frage geordnet zu beantworten.
Mit einem ESB als Rückgrat schafft sich die IT eine Infrastrukturplattofrm, die ausbaufähig und wartbar ist/bleibt. Darauf aufbauend können service-orientierte Architekturen implementiert werden, die dem Nutzen der Fachbereiche dienen (wobei das ein ESB nicht auch täte).
Aus diesem Grunde sehe ich die aktuellen Entwicklungen vermehrt als Chance der IT, auf anstehende Probleme mit Lösungen zu antworten, die zu einem gewissen Maße ausgereift sind.
Dabei muss ein ESB nicht zwangsläufig als Produkt verstanden werden, auch wenn es mittlreweile viele Produkte gibt. Die zugrundeliegenden Architekturen und Design-Ideen können in vielen Umgebungen umgesetzt werden.