Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

18.12.2006

Werkzeugkästen mit SOA

Achim Born ist freier Journalist in Köln.  
Service-orientierte Architekturen gelten als Säule künftiger IT-Infrastrukturen. Mit ihren SOA-Suites bieten die Hersteller gut gefüllte Werkzeugkästen der Umsetzung an.
Der "Fuse"-Framework ist ein Beispiel für eine SOA-Suite auf Basis von Open Source.
Der "Fuse"-Framework ist ein Beispiel für eine SOA-Suite auf Basis von Open Source.

Das Angebot ist groß. Der Grund: Das facettenreiche Aufgabenspektrum erlaubt vielfältige Ausprägungen der Technik hinter SOA. "Unerlässlich ist, dass sich Services unabhängig vom jeweiligen Kontext nutzen lassen. Deshalb muss die technische Plattform für Service-orientierte Architekturen die drei großen "M" - Multichannel, Multiprotokoll und Meta-Daten - abdecken", meint Gartner-Analyst Massimo Pezzini und legt sich damit auf die Aufgaben einer SOA-Plattform fest. "Der Zugriff auf Services muss von beliebigen Endgeräten aus möglich sein, die organisationsübergreifende Nutzung bedingt im Nachrichtenaustausch verschiedene Integrationsstufen, und die Services selbst wollen unterschiedlich behandelt werden - manche verlangen ein höheres Sicherheitsniveau, andere eine größere Verfügbarkeit. Und diese übergeordneten Informationen zu Services geben sie mit Hilfe eines sogenannten Repositorys, einer Art Nachschlagwerk, bekannt."

Den Aufbau eines SOA-Backplane erachtet der Gartner-Analyst als kritischste SOA-Infrastruktur-Komponente. Der Funktions- und Feature-Umfang des Backplanes lehnt sich im Ausbau eng an den Projekterfordernissen an. Minimal sollte nach Gartner-Vorgabe ein SOA-Backplane Aufgaben der Kommunikation, der Datentransformation und der Adressumsetzung / des Routings unterstützen. Diese werden um allgemeine Features für Aufgaben der Entwicklung und des Managements ergänzt. Im fortschrittlichsten Fall zählen Funktionen für ein umfangreiches Life Cycle Management der Services einschließlich Orchestrierung, Regelwerk und Service-Verzeichnis zu einem SOA-Backplane. Dabei lässt die von Gartner aufgestellte Funktionsunterteilung ein wenig die Entwicklung der SOA-Technik aufblitzen.

Ursprünglich wurde die Unterstützung der einschlägigen Web-Services-Standards, die heute von Softwaresystemen von Haus aus geboten wird, mit einer Service-orientierten Architektur gleichgesetzt. In der Tat lässt sich eine einfache SOA-Infrastruktur auf Basis von Punkt-zu-Punkt-Verbindungen mit SOAP via HTTP jederzeit aufbauen. Anspruchsvollere Projekte verlangen hingegen schnell nach mehr Leistung, höherer Skalierbarkeit und Zuverlässigkeit, die ein einfaches SOAP schnell überfordern. Geeignete Integrationstechniken wollen beispielsweise ausgewählt werden, um Altanwendungen einzubinden. Einsätze in verteilten Umgebungen erwarten wiederum das Aufspüren von Services, die Zusammensetzung von Aufrufen sowie die Übersetzung der Schnittstellen. Wie in jeder kritischen Umgebung zählen Lastverteilung und Ausfallsicherheit, um die gewünschte Qualitätsleistung zu erlangen.

Projekt bestimmt die Technik

Zu guter Letzt muss ein Service-Verzeichnis implementiert werden, um den Lebenszyklus der Services einschließlich Wiederverwendung zu verwalten. Komplexe Toolumgebungen begleiten hierzu neben der Produktivphase (Run-Time) auch die Entwurfs- und Implementierungsphase (Design-Time) von Services.

Die Entwicklungen in der jüngsten Zeit belegen, dass zumindest die Anbieter der Prämisse "Mehr = Besser" folgen. Sie bauen den Funktionsumfang ihrer Angebote durch gezielte Zukäufe und Weiterentwicklung zu immer umfangreicheren Suites und/oder Plattformarchitekturen aus. Neben Neulingen sind es insbesondere die einschlägigen Anbieter von EAI-Tools (Microsoft, Sun/Seebeyond, Tibco, Webmethods etc.), Web Application Server (Bea, Jboss etc.) oder beidem (IBM, Oracle, Oracle etc.), die kräftig mitmischen. Sie bauen häufig ihre Architekturen zu einem sogenannten Enterprise Service Bus (ESB) aus, der im Vergleich zu den traditionellen Integrations-Broker-Konzepten universeller ausgelegt ist.

Mehr = Besser?

Laut der US-Beratung Forrester Research, die in schöner Regelmäßigkeit Studien hierzu veröffentlicht, umfasst ein ESB eine Vielzahl der bereits oben aufgeführten technischen SOA-Komponenten. Von ihm werden insbesondere die Kommunikationsinfrastruktur für Services, Routing von Serviceanfragen und Auflösung von Versionskonflikten, Datentransformation und -Mapping, aber auch Service-Orchestrierung und -aggregation, Prozess-Management, Transaktion-Management oder die Services-Registry nebst Metadatenverwaltung gestellt.

Spitzfindig unterteilt Ken Vollmer, führender Analyst bei Forrester, die Anbieterschar in die Gruppen Spezialisten (Pure Player), Integrationssoftware- und Plattformanbieter. Zu den Spezialisten, die von Beginn an mit einem reinen ESB-Angebot aktiv sind, rechnet der Analyst Anbieter wie Cape Clear oder Polar Lake. Aber auch der "ESB"-Erfinder, die Progress-Tochter Sonic oder Iona wie auch Bea oder IBM werden dieser Kategorie zugeschlagen, da sie ESB "stand-alone" anbieten. Die beiden letztgenannten Firmen zählen jedoch ebenso wie Microsoft, Oracle, SAP, Software AG und Sun zur Kategorie der Plattformhersteller, die ESB-Funktionen in ein breiteres Produktportfolio einbetten. Ähnliches gilt für EAI-Spezialisten wie Tibco, Vitria oder Webmethods, die ihre Suites entsprechend aufpeppen.

Eine trennscharfe Unterscheidung lässt sich jedoch nicht ganz aufrechterhalten. Selbst Forrester propagiert an anderer Stelle Unternehmen eine zusätzliche Differenzierung nach ESB-Suites und umfassenden ESB-Suites. Der kleine, aber feine Unterschied: Die einfachen Suites, die sich in der Regel aus einfachen Web-Services-Infrastrukturen oder leichtgewichtigen nachrichtenorientierten Systemen entwickelten, bieten neben dem ESB weiterreichende Komponenten für die Service-Orchestrierung, das Service-Management oder Partner-Collaboration bestenfalls optional an.

Workflow unterstützen

Vertreter der zweiten Gruppe umfassen hingegen neben allen ESB-Suite-Features noch die Unterstützung des Benutzer-Workflows, industriespezifische Prozesse, Portale, Regelmaschinen etc. Sie entstammen typischerweise dem EAI-Segment und ergänzten ihre Produkte um SOA-Unterstützung. Nach dieser Unterteilung fallen CapeClear, Fiorano, Sonic, Iona und Polarlake in erstgenannte Kategorie; Oracle, Sun, Tibco und Webmethods in die zweitgenannte Gruppe. Bea wiederum, je nachdem, ob der Aqualogic Service Bus allein oder gemeinsam mit Weblogic betrachtet wird, wird in beiden Listen als Hersteller geführt.

Entscheidender als die eher akademische Übung der Kategorisierung ist der gebotene Funktionsumfang, der meist deutlich auf die ursprüngliche Herkunft der Programme hinweist. So besitzt nach Analyse von Forrester beispielsweise der Middleware-Spezialist Iona eine leistungsstarke, verteilbare ESB, die allerdings in Service-Orchestrierung und Prozess-Modellierung Schwächen zeigt. Die ebenfalls wenig ausgeprägte Service-Montoring- und Management-Funktion müht sich der irische Hersteller durch die Kooperation mit Amberpoint abzufedern. Polarlaoke wird wiederum eine reichhaltige Vermittlungsfähigkeit und Prozessmodellierungsstärke zugebilligt. Es mangelt aber unter anderem an Unterstützung im Bereich Registry, etwa UDDI.

Service-Verzeichnisse beziehungsweise -Kataloge, die Adressen und Schnittstellenbeschreibungen verfügbarer Dienste verwalten, und noch mehr Repositorys, die ergänzend Metadaten (Prozessbeschreibungen, Regeln etc.) bevorraten, gelten für komplexe SOA-Umgebungen als einer der Ordnungsfaktoren. Denn sie machen den Bestand zur Wiederverwendbarkeit transparent und umreißen die semantische Welt (Domäne) des Wirkens eines Services. Die IT-nahen Registries dienen dabei meist zur Optimierung des Run-Time-Einsatzes, während Repositories zusätzlich Aufgaben der Entwurfs- und Implementierungsphase unterstützen und damit in den Bereich des Business Process Managements hineinreichen.

Mit WebSphere Registry and Repository (WSRR), das auf den Rational Buildforge, Clearquest und Software Architect basiert, ist IBM ebenfalls mit einem integrierten Produkt unterwegs. Webmethods hat nach der Übernahme von Infravio, Anbieter eines UDDI-basierenden Registry, mit Cerebra weitere Repository-Technik erworben, die unter anderem die Web-Ontologie-Sprache (OWL) und das RDF (Resource Description Framework) zur Beschreibung von semantischen Inhalten unterstützt. Und Bea komplettierte sein bereits breites SOA-Angebot nach dem Kauf von Flashline um ein weiteres Repository namens Bea Aqualogic Enterprise Repository. In Kürze wird wohl auch SAP mit der neuen Netweaver-Version das lang erwartete zentrale Verzeichnis (ESR - Enterprise Services) vorstellen. In dem gemeinsam mit IDS Scheer entwickelten ESR werden in einer einheitlichen Umgebung die mit dem Modellierungswerkzeug entworfenen Geschäftsprozessmodelle sowie die korrespondierenden Service-Beschreibungen der SAP-Anwendungen verwaltet.

Gegenwärtig starten nach Beobachtung von Forrester viele Firmen ihre SOA-Reise mit dem Einstieg in eine ESB, die nach Urteil von Vollmer ein preiswerterer Weg zur Anwendungsintegration sei als die Einführung einer integrationszentrierten BPM-Suite. Nicht alle Analysten teilen indes die hohe Einschätzung von Enterprise Service Buses als SOA-Eintrittspunkt. So ordnet Anne Thomas Manes, Forschungsdirektorin bei der Burton Group, diese Produkte zwar grundsätzlich in die Kategorie der Vermittlungslösungen ein: "Typischerweise empfehle ich nicht den Gebrauch einer ESB als Vermittlungsinstanz." Sie erkennt in ihnen eher ein Plattformkonzept für komplexere Aufgaben. Manes selbst empfiehlt für Verbindungs- und Vermittlungsaufgaben wegen der größeren Sicherheit zunächst einmal XML-Gateway- oder Web-Services-Management-Produkte.

Unternehmen, die bereits eine Integrationsinfrastruktur-Lösung nutzen, rät ZapThink-Analyst Jason Bloomberg den Einsatz reiner Intermediär-SOA-Software wie Network Director von SOA Softwares.

Der Trend wird verstärkt von dem wachsenden Angebot an Open-Source-Software. Im Herbst 2006 ist beispielsweise Red Hat in die Riege der ESB-Anbieter eingetreten und hat mit JBoss ESB ein weiteres SOA-Mosaiksteinchen der JBoss Enterprise Middleware Suite (JEMS) vorgestellt. Logicblaze stellt mit Fuse eine SOA-Plattform mit vier Ebenen für Komponenten (siehe Grafik) zusammen, die sich komplett aus Open-Source-Projekten zusammensetzt, insbesondere aus Apache (jUDDI als Registry, BPEL Engine Ode, und ServiceMix als ESB).

Alternative Open Source

Eine weiteres Angebote aus dem Open-Source-Umfeld ist der J2EE-ESB Mule von Mulesource, das von Sun initiierte Projekt Open ESB sowie Ionas Celtix, das von Entwicklungen des kommerziellen Pendants Artix profitiert.

Der Markt für SOA-relevante Produkte wird trotz Fusionen und Konsolidierung folglich breiter und bunter. Und er gewinnt an zusätzlicher Funktionalität etwa durch die Integration einer Event Driven Architecture (EDA), die Ereignisse in Echtzeit erkennt und verwaltet. Analysten sind auch flugs mit neuen Begrifflichkeiten zur Hand: In Anlehnung zu Web 2.0 reden sie bereits von SOA 2.0.

Achim Born ist freier Journalist in Köln.