Zum Inhalt springen
SOA-Serie Teil 18

SOA ist vielfältig

SOA ist vielfältig Standards sorgen für Gemeinsamkeiten, doch die SOA-Produkte der Middleware-Anbieter ­unterscheiden sich in wesentlichen Hinsichten.

Autor:Redaktion connect-professional • 25.4.2008 • ca. 1:45 Min

Inhalt
  1. SOA ist vielfältig
  2. Open-Source-Angebote
  3. Konkurrierende Standards

Middleware gibt es in verschiedenen Ausprägungen. Als moderner Vertreter dieser Software-Kategorie bildet ein Enterprise Service Bus (ESB) das Kernstück einer serviceorientierten Architektur (SOA). Über eine solche Plattform können Programme verschiedener Art verbunden werden. Anwendungsintegration wird in solchen Szenarien durch Modularisierung und Mediation erreicht. Über sogenannte Service Container können dabei die verwendeten Protokolle, Datenformate und Programmierschnittstellen verborgen werden. Allgemein gesagt geht es hier um Kapselung, Abstraktion oder Virtualisierung. Nach Auffassung von Anne Thomas Manes, Vice President und Research ­Director des Beratungs- und Marktforschungshauses Burton Group, fließen in den ESBs außerdem die älteren Middleware-Kategorien Applikationsserver und Integration Broker zusammen.

Unterschiedliche Konzepte
Der Begriff ESB ist heute unter Middleware-Herstellern sehr weit verbreitet – jeder will dabei sein. Im Detail unterschieden sich die als ESB bezeichneten Produkte jedoch erheblich, wie Manes bestätigt. Zum ersten Mal verwendet wurde dieser Terminus im Jahr 2002: von dem Software-Hersteller Progress, um damit ein neues Messaging-Produkt namens Sonic zu charakterisieren, das mit XML und Java arbeitet. Inzwischen hat dieses Unternehmen seine Middleware-Palette ausgebaut. So wurde für das SOA-Management der Hersteller Actional übernommen und zur Verarbeitung von Ereignissen die Firma Apama. Der ESB Artix des für seine Corba-Implementierung bekannten Anbieters Iona, und ähnlich der quelloffene Abkömmling Fuse, beruht im Gegensatz dazu nicht auf Messaging, sondern stützt sich auf ein Modell des verteilten Computings, um Nachrichten zwischen Endpunkten zu handhaben. Der Aqualogic Service Bus von BEA wiederum setzt Manes zufolge den hauseigenen Java-Applikationsserver voraus, Analoges gilt für den Websphere ESB von IBM. Neben diversen Standards aus der WS-*-Familie implementieren manche Hersteller die Service Component Architecture (SCA), andere stattdessen die Spezifikation Java Business Integration (JBI). Zur Kombination von Services im Hinblick auf Geschäftsprozesse offerieren etliche die Business Process Execution Language (BPEL) als Teil des ESB, andere hingegen über ein separates Produkt für das Business Process Management (BPM) oder auch gar nicht. Manche ESBs liefern ein Repository frei Haus, manche nicht. Eine weitere Zusatztechnologie stellt das Complex Event Processing (CEP) dar. Unterschiede gibt es, wie Manes weiß, ferner bei Geschwindigkeit und Skalierbarkeit, etwa per Lastverteilung und Clustering, sowie bei der Integrierbarkeit von Legacy-Technologien. Um für ein bestimmtes Projekt einen ESB auszuwählen, müsse man sich daher die Eigenschaften im Hinblick auf die Anforderungen genau ansehen. »Dass für die gesamte SOA-Landschaft eines Unternehmens ein einziger ESB Verwendung findet, ist unrealistisch«, meint Manes allerdings.