Ein service-orientierter Ansatz zur nachhaltigen Anwendungsintegration in Unternehmen
TillLuhmann BTC AG Escherweg 3 26121Oldenburg till.luhmann@btc-ag.com
Abstract.Service-orientierte Architekturen(SOA) sind ein vielversprechender Ansatz für die unternehmensübergreifende Integration im B2B- und B2C- Bereich. Gleichwohl bietensichSOA-Lösungenauchfür die Integrationunter- nehmensinterner Anwendungslandschaftenan. Zwar stehen mitheutigen Integ- rationswerkzeugengeeignete Plattformenfür die Umsetzung bereit, doch tun sich Unternehmen häufig mit der konkreten Überführung einer gewachsenen Punkt-zu-Punkt-Architektur in eine SOA schwer. Der vorliegende Beitrag skiz- ziert die Problemstellung undbietet Lösungsansätze an.
1 Einleitung
Unternehmen mit Schwerpunkten imB2B- wie imB2C-Bereich müssen sich heute stärker dennje an den wachsenden Kommunikationsbedürfnissen desMarktesorien- tieren. Hauptanforderung an die IT ist dabei die nahtlose Integration mit anderen Marktteilnehmern. Doch auch die Situation innerhalb von größeren Unternehmen oder Konzernen ist mit der Marktsituation vergleichbar: Konzernweit sollen Daten, Anwendungenund Prozessemit dem Zielintegriert werden, auf allenEbenenSyner- gieeffekte zu erwirtschaften(siehe z.B. [BFGH02]).
Die Problemstellung ist dabei seitlangem bekannt und dennochungelöst: Zwar wer- den heute die Abläufe innerhalb von Unternehmen durchweg durch IT unterstützt, doch ist die dabei eingesetzte Software meist sehr heterogen. Eine Konsolidierung durchEinführung vonStandardsoftware wie SAP istnur in einigen Unternehmensbe- reichen möglich bzw.sinnvoll. Insbesondere in technischen bzw.industriellen Kern- prozessen kommen spezialisierte Anwendungen zum Einsatz. Zur Vermeidung von Medienbrüchen wurdendiese Systeme inder Vergangenheit vielfachdurchPunkt-zu- Punkt-(PzP-)Kopplungen zum automatisierten Datenaustausch verknüpft. So sind nachundnachkomplexeSchnittstellenlandschaftengewachsen.
Durchdie Einführung einerIntegrationsplattform(IP), die eine Infrastruktur für die Integration bereitstellt, soll das entstandene „Schnittstellenchaos“überwunden wer- den. Über die Möglichkeit derIntegrationauf Daten- und Anwendungsebene hinaus („klassische“ EAI-Funktionalität) bieten heutige IP zusätzliche Funktionalitäten für die Integrationauf Workflow-bzw.Geschäftsprozessebene [FLM05].
Die vielfältigen MöglichkeitenderIntegrationswerkzeuge liefernjedochkeinPatent- rezept zur nachhaltigen Vereinfachung der Integrationslandschaft. So besteht die Gefahr, dass eine bestehende PzP-Landschaft auf Plattformbasis erneut abgebildet wird (Abb. 1 und nächster Abschnitt). Einen Ausweg stellt die konsequente Einfüh- rung einer internenSOA (siehe [BHMN+04]) dar.
IP App.
App.
App.
App.
App.
App.
App.
App.
Integrationsplattform
Abb.1.Punkt-zu-Punkt-Integrationslandschaften
2 Hintergrund: Die Punkt-zu-Punkt-Falle
PzP-Verbindungen sind gekennzeichnet durch eine individuelle Kopplungslogik, die auf die technischen Merkmale undhäufig auf die Fachlichkeit derbeteiligten Anwen- dungen zugeschnittenist (Abb. 2 li). Mängeldieser Architektur sind z. B. die schlech- te Wartbarkeit infolge des Einsatzes heterogener Technologien(z. B. Shell-Skripte, Add-Ins), diefehlende Überwachbarkeit oder das Vermischen von Applikations-und Geschäftslogik. DurchEinsatz einerIP wird die Möglichkeit geboten, Anwendungen durch Adapter anzubindenund die Geschäfts- undTransformationslogik auf einheitli- cherTechnologiebasis als Prozess innerhalbderIP abzubilden(Abb. 2re).
IP Logik
A -> B A
B
Logik A -> B A
B Schnittstelle von A
(File, DB, API, ...)
wie links, zzgl.:
- XML, WS, BPEL, ...
- Ablaufsteuerung - Überwachbarkeit Punkt-zu-Punkt-
Logik
Schnittstelle von B (File, DB, API, ...)
Ad.
Ad.
Abb.2.Individuelle Kopplungslogik, umgesetztmit verschiedenen Technologien
Zweifellosbietet der Plattformeinsatz bereits inder in Abb. 2gezeigtenForm Vortei- le, unter anderemdurchdie werkzeugseitige Vereinheitlichung der Schnittstellenent- wicklung, denEinsatz einer Ablaufsteuerung für Verarbeitungsprozesse und die damit einhergehende Möglichkeit einer Überwachung der implementierten Prozesse. Die durch die IP gebotenen technischenFreiheitsgrade verleitenjedochProzessarchitek-
tendazu, sich erneut indie -nunplattformgestützte - PzP-Falle zubegeben. Wie die Praxis zeigt, wirdnach wie vor Applikationslogik indie Prozesslogikhineingezogen, z. B. in Form von individuellen PzP-Datentransformationen, applikationsnahem Skripting als Prozessaktivitätoder dem1:1-Umsetzen bestehender Dateitransfers auf Plattformbasis. Dieser Ansatz führtletztlich nicht zur Reduktionder Anzahlindividu- eller Wartungsbaustellen. Neue Standardtechnologien wie XML, Web Services, BPEL u. a. [ACKM04, HW04] werden hier lediglich zur Reimplementierung der bestehendenPzP-Verbindungen eingesetzt. Vonden neuen Technologien gehtoffen- bar eine gewisse Blendwirkung aus: Ihr Einsatz ermöglicht erst eine nachhaltige In- tegrationslösung, docher impliziert sie keineswegs.
3 Lösungsansatz: Service-orientierte Architektur
Abb.3.Integrationsplattformals Diensteanbieter und -nutzer imRahmen einer SOA Zur Schaffung der Grundlagen für den Aufbau einer flexiblen Geschäftslogik ist es vielmehrnotwendig, die festen Verbindungenaufzulösen. Hierzu sind die zu integrie- renden Anwendungen A, B, usw. zunächsteinzeln zubetrachtenund in eine standar- disierte undnormierte Form zuüberführen. Abb. 3links zeigt, wie dies zu verstehen ist:Die IP koppelt Anwendung Adurch eine auf A zugeschnittene Logik an(B ana- log). Inhalt dieser Logik ist sowohldie Überführung der Schnittstelle von Ain einen nachrichtenorientierten, technischen Standard (z.B. Web Service), als auch deren Abbildung auf einenfachlichenStandard (z.B. ebXML). ImRahmendes Logikbau- steins kann Aoptionalumergänzende Applikationslogik erweitert werden. ImErgeb- nis wird A durch die IP vollständig gekapselt und potentiellen Dienstenutzern als standardisierter undnormierter Dienst A’ angeboten(B’ analog).
Die ursprünglich betrachtete Kopplung von Aund B wirdnunmehr mit derIP unter Nutzung der Dienste A’ und B’ als standardisierter, ggf. normierter Prozess AB um- gesetzt1(Abb. 3 rechts). Die IP tritt dabei zum eineninder Rolle einesDiensteanbie- ters, zum anderen in der eines Dienstenutzers auf. In dieser unternehmensinternen
1Darüberhinaus kannProzessAB imRahmender SOA als zusätzlicher, standardisierter Dienst ABbereitgestellt werden(Diensteaggregation, vgl. [Ley03]).
SOA sind Applikations- und Prozesslogik getrennt2. Der VorteildieserKonstruktion ist das Wegfallen der individuellenPzP-Verbindungen. Es werden nur nochstandar- disierte, normierte Dienste durch die Dienstenutzer (Prozesse) verschaltet. Dies er- möglicht erst die in einem Marktgeschehen erforderliche AgilitätbeimProzessdesign und reduziert nachhaltig die Schnittstellenanzahl. Mehraufwand entsteht allerdings durchdie Normierung der Diensteschnittstellenauf einenfachlichenStandard (s.u.).
4 Standardisierung und Normierung
UDDI
Konzern-Dienste
IP IP
IP
App.
App. App.
App.
App. App.
App. App.
App.
Domänenspezif.
Dienste
Abb.4.Mehrplattformarchitektur imRahmen einerKonzernlösung
Je größer der zu bedienende Kontext (Fachabteilung vs. Konzern vs. Markt), desto globaleren Ansprüchen muss die geforderte technische und fachliche Standardisie- rung der angebotenenDienste genügen. Währendmit WebServices, BPEL undUDDI heute auf technischer Seite Standardsbereitstehen, die für alle Kontexte geeignet sind, fällt die Auswahl geeigneter fachlicher Standards für normierte Datenobjekte, Schnittstellen und Prozessabläufe schwerer. Die Entwicklung eines eigenen unter- nehmensweiten, umfassenden Informationsmodells kann eine unüberbrückbare Hürde auf dem Weg zu einerIntegrationslösung darstellen. Es empfiehlt sichdaher, Dienste domänenspezifisch zu gruppieren und hierfür jeweils spezifische Fachstandards ein- zusetzen. Im Rahmen einer konzernweiten Integrationslösung kann hierbei eine Mehrplattformarchitektur sinnvollsein(vgl. Abb. 4). Vorteildieses Ansatzes ist, dass spezifische Anwendungslandschaften einzelner Fachdomänen (z. B. kaufmännisch, technisch) durch jeweils geeignete IP integriert werden können („best-of-breed“- Ansatz). Jede IP bietet normierte Dienste innerhalb einer ausgewählten Fachlichkeit an und verschaltet diese zu domänenspezifischer Geschäftslogik. Inder Regel ver- bleibt diese Logik innerhalb eines engeren Kontexts (einerIP) und muss daher weni- ger harten Anforderungen an Normierung genügen. Darüber hinaus kann jede IP Konzerndienste anbieten, für die übergreifende Standards gelten. In Abb. 5 wurden einmal verschiedene, domänenspezifische Standardsnach wachsendem Anwendungs- kontext klassifiziert.
2soweit existierende Anwendungenkeine eigene Prozesslogik enthalten. IndiesemFall muss die Wechselwirkung dieser Prozesslogikmit denSOA-Prozessenkritisch bewertet werden.
Standard
De facto- Standard
Produkt- spezifischer
Standard Unternehmens
-spezifischer Standard
StandardSAP-
Fachabteilungs-
Standard Siebel-
Standard Konzern-
Standard
Industrie- Standard
Branchen- übergreifender
Standard
ebXML EDIFACT Branchen-
spezifischer Standard RosettaNet
CIM EVU
(tendenziell) breiterer Anwendungskontext
Abb.5.Klassifikation vonStandards
5 Zusammenfassung und Ausblick
Der Beitrag zeigt, wie eine service-orientierte Architektur zurIntegrationder Anwen- dungslandschaft in Unternehmen eingesetzt werdenkann. ZurnachhaltigenReduktion von Integrationsaufwänden dürfen neue Technologieplattformen nicht für die Reim- plementierung bestehender Architekturen zweckentfremdet werden. Vielmehr muss die heutige PzP-Integration nachhaltig durchdie Einführung einer Dienstearchitektur überwunden werden. Auch ergänzende oder alternativeKonzepte im Zusammenhang mit derIdee eines Enterprise Service Bus[Chap04]können hierbei eine Rolle spielen.
Verwiesen sei auf das Vorhaben [USLA05], in demder skizzierte Ansatz als Refe- renzarchitektur dient. In einem weiteren nichtöffentlichen Projekt für einen Konzern wird derbeschriebene Mehrplattformansatz verfolgt.
Literaturverzeichnis
[ACKM04] Alonso, G.;Casati, F.; Kuno,H.; Machiraju, V.:WebServices - Concepts, Archi- tectures and Applications. Springer, 1. Aufl.,2004
[BFGH02]Bunjes, B.;Friebe,J.;Götze, R.; Harren, A.: Integration von Daten, Anwendungen und Prozessen amBeispieldes TelekommunikationsunternehmensEWE TEL. Wirtschaftsin- formatik, 44(5): 415-23 (2002)
[BHMN+04]Booth, D. et al.: WebServices Architecture. W3C Working Group Note 11,2004, http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/
[Chap04]Chapell, D.:EnterpriseServiceBus. O’Reilly, 1. Aufl.,2004
[FLM05]Friebe,J.;Luhmann,T.; Meister,J.: Auswahl geeigneter Technologienfür betriebli- che Integrationsszenarien. BTW 2005, 11. GI-Fachtagung für Datenbanksysteme inBusi- ness,Technologie und Web,Karlsruhe 2005,515-32
[HW04] Hohpe, G.; Woolf, B.: Enterprise Integration Patterns. AddisonWesley, 1. Aufl.,2004 [Ley03]Leymann, F.: WebServices: Distributed Applicationswithout Limits. BTW 2003, 10.
GI-Fachtagung Datenbanksysteme für Business,Technologie und Web. Leipzig,2003,2-23 [USLA05] Uslar, M.;Schmedes,T.;Luhmann,T.; Appelrath, H.-J.: Eine service-orientierte
Architektur für das dezentraleEnergiemanagement. 35. GI-Jahrestagung, Bonn,2005, zur Veröffentlichung angenommen
