EAI mit SOA

Wege aus dem Labyrinth
Kommentare

Eine serviceorientierte Architektur (SOA) macht nicht nur Geschäftsprozesse transparent und flexibel, sondern erweitert oder ersetzt auch herkömmliche Enterprise Application Integration (EAI). Die effiziente Nutzung einer SOA hängt von der Agilität, der Transparenz und ganz entscheidend von der unterstützenden Infrastruktur ab. Zu dieser gehören verschiedene Komponenten, die aufeinander abgestimmt sein müssen, um miteinander funktionieren zu können.

Die Komplexität der System- und Applikationslandschaft in den Unternehmen ist heute so groß wie noch nie. Oft wird eine Reihe heterogener Lösungssoftware unter anderem für Customer Relationship Management (CRM), Enterprise Resource Planing (ERP) und Personalverwaltung (HR) von unterschiedlichen Herstellern verwendet. Die Anwendungsplattformen reichen von CORBA und J2EE über .NET bis hin zu proprietären Infrastrukturen. Typischerweise
existieren zahlreiche Geschäftsprozesse über die vorhandenen Applikations- und Technologiegrenzen hinweg. Um diese unterstützen zu können, müssen die vorhandenen Systeme integriert werden. So involviert beispielsweise die Abwicklung einer Bestellung aus einem Kundenportal zunächst das CRM-System, danach das Rechnungslegungssystem und letztendlich die Lagerverwaltung. Dies erfolgt typischerweise entweder manuell oder durch punktuelle Integrationslösungen, womit eine entsprechend hohe Anzahl an Abhängigkeiten entsteht. Um diese besser in den Griff zu bekommen, wurde bestenfalls eine proprietäre Enterprise Application Integration (EAI)-Lösung der ersten Stunde eingeführt. Die Pflege und Erweiterungen solcher Integrationslösungen sind erfahrungsgemäß immer noch sehr aufwendig. Die Betriebskosten solcher Informationssysteme nehmen einen Großteil des IT-Budgets in Anspruch, wodurch für notwendige Erweiterungen und Anpassungen wenig Spielraum bleibt. Die Situation ist umso kritischer, als sich die Unternehmen in einer zunehmend dynamischen Marktlandschaft etablieren müssen, in der starre, in sich geschlossene Unternehmen zunehmend sterben und partnerschaftlich vernetzte Organisationen mit schlanken und flexiblen Geschäftsmodellen das Zukunftsmodell darstellen. Man spricht hierbei auch vom so genannten IT-Gap, der Kluft zwischen den sich immer rascher ändernden Geschäftsmodellen und den unterstützenden
Informationssystemen.

SOA im Trend

Zeitgleich mit dieser Entwicklung erleben serviceorientierte Architekturen eine Renaissance und werden von den Unternehmen selbst, aber auch von Systemintegratoren, Softwareherstellern und Analysten im Zusammenhang mit flexibleren und zukunftssicheren IT-Architekturen viel zitiert. Im Gegensatz zu den ersten SOA-Konzeptionen Ende der 90er Jahre tritt SOA heute mit dem Anspruch an, auf offene Standards zu setzen und damit produktunabhängig und weitestgehend technologieunabhängig zu sein. Neben den Services stehen heute auch transparente, effizient änderbare und vor allem systemübergreifende Geschäftsprozesse im Fokus von SOA. Ob sich damit das IT-Gap verkleinern lässt und letztendlich die Unternehmen effizienter und konkurrenzfähiger gemacht werden können, wird sich erst noch zeigen.

Granularität der Services ist entscheidend

Die Grundbausteine für eine SOA sind offensichtlich Services, die von einem oder mehreren Informationssystemen zur Erledigung bestimmter fachlicher Aufgaben angeboten werden. Im Sinne einer SOA hat ein Service eine fachliche
Bedeutung und unterstützt damit eine einzelne Geschäftsaktivität. Hierbei stellt sich unmittelbar die Frage nach der
Granularität eines solchen Services und es können hier sowohl grobgranulare Services wie zum Beispiel „Bestellung
abwickeln“ als auch feingranulare Ser vices wie zum Beispiel „Rechnung stellen“ identifiziert werden.

Abb. 1: Prozessbeispiel in einer SOA

Die „Verflüssigung“ der Systeme ist Voraussetzung

Traditionell existiert in einem Unternehmen bereits eine Vielzahl von selbstentwickelten oder gekauften Informationssystemen und es geht zunächst darum, einzelne Aktivitäten dieser Systeme von außen ansprechbar zu machen und damit als Services zu veröffentlichen. Das wichtigste Kriterium für die Auswahl der Services ist hierbei der potenzielle Grad der Wiederverwendbarkeit. Kandidaten hierfür sind Lösungspakete in Bereichen wie CRM, ERP und HR. Immer häufiger werden solche Systeme nicht mehr monolithisch und abgeschlossen gebaut, sondern sind intern entkoppelt und bieten ihre Einzelfunktionalitäten bereits als Service an. Des Weiteren kommen Eigenentwicklungen und insbesondere Client-Server-Systeme für die Publikation von Services in Frage. Auch existierende, geschäftskritische Applikationen beispielsweise auf Host-Rechnern können direkt über Services gekapselt und innerhalb der SOA zur Verfügung gestellt werden. Typischerweise sind Host-Transaktionen sehr komplex und generisch, weshalb die Abbildung von Transaktionen auf eine Reihe von spezifischeren und einfacheren Services sinnvoll ist. Die Verbindung zu einem bestehenden Informationssystem inklusive der notwendigen Protokollumsetzung, Datentransformation, Sicherheitskonfiguration usw. wird oft mithilfe eines so genannten Adapters realisiert (Application Integration). Die Entwicklung von Adaptern kann recht aufwendig und teuer sein, und umso mehr bieten Adapter-Standards wie zum Beispiel die Java Connector Architecture (JCA) entsprechenden Investitionsschutz und Herstellerunabhängigkeit.

Datenservices dominieren

Untersuchungen zeigen, dass ein Großteil der Services Daten aus unterschiedlichen Informationssystemen wie Datenbanken, ERP-, CRM-, und Legacy-Systemen extrahieren, diese Information zu einem konsistenten, komplexeren Datenobjekt zusammensetzen und dann als Service zur Verfügung stellen. Circa 80% der Datenservices wiederum sind rein lesend und nur 20% propagieren Updates zurück an die ursprünglichen Datenquellen. Um Daten- Services nicht aufwendig programmieren zu müssen, werden zunehmend Produkte in der Kategorie Enterprise Information Integration (EII) entwickelt, welche die Implementierung oder gar Konfiguration solcher Services effizienter gestalten sollen. Technisch werden die Datenquellen über Adapter angeschlossen, mit einer Anfragesprache die zu lesenden Daten spezifiziert und analog zur Theorie der verteilten Datenbanken letztendlich die Anfragen optimiert, dezentral ausgeführt, Ergebnisse aggregiert, eventuell zwischengespeichert und als Service weitergegeben. Auch hier gibt es jüngst Standardisierungsbemühungen mit den so genannten Service Data Objects (SDOs) [1].

Aufmacherbild: Business man looking at a maze and the way out on brown wall von Shutterstock / Urheberrecht: ra2studio

[ header = Seite 2: Ohne Standards läuft nichts ]

Ohne Standards läuft nichts

Für eine erfolgreiche SOA reicht das pure Veröffentlichen und Konsumieren von Services bei weitem nicht aus. Es muss zunächst sichergestellt werden, dass alle Services mittels einer einheitlichen und standardbasierten Technologie zur Verfügung stehen. Auch wenn nicht unbedingt notwendig, so verdankt SOA seine derzeitige Popularität nicht zuletzt der zunehmenden Verbreitung und Akzeptanz von Web Services. Die Beschreibung der Schnittstelle eines Web Service wird über die so genannte Web Services Description Language (WSDL) standardisiert, das Nachrichtenformat wird über den SOAPStandard festgelegt und die Verwendung eines standardisierten Protokolls wie HTTP oder JMS sichert letztendlich die Interoperabilität verschiedener Service-Produzenten und -Konsumenten. Weitere notwendige Standards für die Verwendung von Web Services (WS) in einer kritischen Unternehmensumgebung hinsichtlich
Sicherheit und Zuverlässigkeit sind bereits vorhanden oder werden derzeit definiert (z.B. WS-Security, WS-ReliableMessaging).

Die Integration von Systemen auf der Basis von Web Services sichert zwar die Konnektivität zwischen den Systemen und verhindert einen Wildwuchs von Integrationsprotokollen und Technologien, sie löst jedoch nicht das Problem der großen Anzahl von Punkt-zu-Punkt- Verbindungen, der damit verbundenen Abhängigkeiten und auch der unflexiblen Verteilung der systemübergreifenden Integrations- und Geschäftslogiken über alle Systeme hinweg. Ein zentraler Erfolgsfaktor einer SOA ist die transparente und flexible Modellierung und Ausführung von Geschäftsprozessen, was im Zusammenhang mit SOA auch oft als das Orchestrieren von Services bezeichnet wird. Hierzu wird meist ein so genanntes Business-Process- Management-(BPM-)System verwendet, das neben der Modellierung und Ausführung der Prozesse auch deren Administration und Überwachung unterstützt. Auch bei der Beschreibung von ausführbaren Prozessen ist die Standardisierung für die Unabhängigkeit von einzelnen Werkzeugen und Herstellern mit der Web Services Business Process Execution Language (WS-BPEL 2.0) auf einem guten Weg [2]. Das Business Activity Monitoring (BAM) und Process Performance Management sorgt für ein zeitnahes Feedback der ausgeführten Geschäftsprozesse an die Fachabteilungen und erlaubt damit deren effiziente Optimierung und Anpassung.

Services lose gekoppelt

Eine flexible und dynamisch änderbare Verbindung zwischen Service-Anbietern und Service-Konsumenten reduziert die Abhängigkeiten, sodass sie sich leichter verwalten und erweitern lassen. Realisiert wird dies, indem Anbieter ihre Services den Konsumenten nicht direkt zur Verfügung stellen, sondern den Service zunächst an eine Service-Management-Komponente übergeben. Service-Konsumenten treten ebenfalls nicht direkt mit den Service-Produzenten in Verbindung, sondern richten ihre Anfrage ebenfalls an das Service Management. Die Service-Management-Komponente verbindet nun konfigurativ Service-Konsumenten mit -Produzenten, indem eine so genannte Routing Pipeline definiert wird. Routing Pipelines können auch komplexere Serviceflüsse abbilden, wie zum Beispiel das Weiterleiten einer Anfrage an unterschiedliche Anbieter in Abhängigkeit von den übergebenen Daten. So können Kunden mit einer alten Kundennummer an das Legacy-System weitergeleitet werden, und nur neue Kunden werden vom CRM bearbeitet.

Die Service-Management-Komponente ist die Drehscheibe der SOA und kann damit eine Reihe weiterer Aufgaben übernehmen, die zur Service Governance beitragen: Definition, Überprüfung und Eskalation von Service Level Agreements (SLAs) sowohl für Konsumenten als auch für Produzenten, Überwachung der Verfügbarkeit von Services, Management eines Serviceverzeichnisses, Unterstützung des Service Lifecycles inklusive Service-Aktivierung, -Deaktivierung, -Versionierung und -Upgrade. Diese vielfältigen Aufgaben werden von spezialisierten Web-Service-Management-Lösungen übernommen und zunehmend durch so genannte Enterprise-Service-Bus-(ESB-) Lösungen abgedeckt.

Abb. 2: Service-Infrastruktur mit SOA

Die Service-Infrastruktur bildet das Rückgrat der SOA

Neben der offensichtlichen Agilität und Transparenz hängt der effiziente Betrieb einer SOA entscheidend von der unterstützenden Infrastruktur ab [3]. Dazu gehören zumindest eine hoch performante und zuverlässige Web-Service-Plattform, eine Business-Process-Modelling-Umgebung für die Service-Orchestrierung, ein Enterprise Service Bus für das Service-Management und eine Sicherheitslösung. Alle Komponenten sollen natürlich soweit als heute möglich auf offenen Standards wie Web Services, XML, XSLT, WS-BPEL aufbauen. Die Abstimmung der einzelnen Komponenten und deren reibungsloses Funktionieren miteinander bleibt eine der heutigen Herausforderungen. Analog zu den heute verfügbaren, entwicklungsorientierten Applikationsplattformen (Gartner definiert diese als Application Platform Suites) bietet SOA Raum für eine neue Art von konfigurationsorientierten Serviceplattformen, welche die für eine SOA notwendigen Infrastrukturkomponenten in einem Plattform-Produkt integriert und damit einen effizienten und flexiblen Betrieb einer SOA ermöglicht. Ein erstes Produkt in dieser Kategorie ist beispielsweise von der Firma BEA Systems unter dem Namen AquaLogicTM erhältlich.

Erwähnenswert in diesem Zusammenhang ist auch die Standardisierungsbemühung innerhalb des Java Community Process (JCP) mit dem Java Specification Request (JSR) 208 zum Thema Java Business Integration (JBI) [4]. Hier werden eine Integrationsumgebung und deren Komponenten auf der Basis einer SOA standardisiert. Es bleibt zu bemerken, dass SOA beziehungsweise der Erfolg einer SOA nicht bei der Technik, sondern in der Denkweise beginnen muss. Das Denken in Services und Geschäftsprozessen kann und muss gemeinsam mit dem Management und den Fachabteilungen praktiziert werden.

Fazit

Eine transparente, flexible und entkoppelte interne IT ist die Voraussetzung für einen effizienten partnerschaftlichen externen Verbund innerhalb einer gemeinschaftlichen und immer öfter globalen Wertschöpfungskette. Die Fokussierung von SOA auf effizient optimierbare und ausführbare Geschäftsprozesse sowie deren Überwachung und Laufzeitanalyse scheint zumindest die richtige Vision einer IT zu sein, die nicht nur die Kluft zwischen Geschäftsanforderungen und unterstützenden IT-Systemen verkleinern, sondern auch zunehmend die Rolle eines Enablers für neue Geschäftsmodelle übernehmen kann.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -