Web-Services: Konzepte, Technologien und Anwendungen im Finanzdienstleistungssektor

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

1. Einleitung

2. Techniken der Web-Services und deren Relevanz für den Finanzdienstleistungssektor

3. Anwendungsszenarien im Finanzdienstleistungssektor
3.1. Interne Anwendungsgebiete
3.2. Externe Anwendungsgebiete

4. Praxisfälle von Web-Services

5. Fazit und Ausblick

Literaturverzeichnis

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abb. 1 Zwiebelschalendefinition des Web-Service Begriffs

Abb. 2 Schematische Darstellung eines Web-Services-Aufrufs

Abb. 3 Architektur des Web-Services

1. Einleitung

Web-Services ist zurzeit in aller Munde. Jeder spricht davon, jeder sieht es als die Zukunftstechnologie schlechthin an. Doch so neu ist das Konzept dieser Technik gar nicht. In der Vergangenheit gab es bereits ähnliche Ansätze^[1]. Die diversen Ziele dieser Techniken sind meist die gleichen: Verteilte Anwendungen, auf unterschiedlichen Systemen und in unterschiedlichen Programmiersprachen implementiert, sollen miteinander kommunizieren können. Techniken wie DCE, CORBA, COM und DCOM, Enterprise JavaBeans sind hier nur eine der Wichtigsten, die zu nennen sind^[2].

Was aber nun macht Web-Services so besonders und warum sollte sich diese Technik eher durchsetzen als die unzähligen Ansätze der Vergangenheit? Was ist Web-Services überhaupt und in welcher Form könnte sich die Technik im Bereich der Finanzdienstleister einsetzen lassen? Diese Fragen sollen in der vorliegenden Arbeit erörtert werden.

2. Techniken der Web-Services und deren Relevanz für den Finanzdienstleistungssektor

Im folgenden Abschnitt soll die Frage geklärt werden, wie Web-Services definiert sind. Dabei wird auf spezifische Sichtweisen eingegangen die insbesondere für den Finanzdienstleistungssektor eine Rolle spielen.

Was sind Web-Services?

Es gibt inzwischen unzählige Definitionen von Web-Services^[3]. Eine Definition lautet hier: „Web Services sind eine Infrastrukturtechnologie zur schnellen und einfachen Integration heterogener Anwendungen“^[4]. In dieser Definition wird das Umfeld der Nutzung von Web-Services und deren Technologien nicht explizit genannt. SUN, einem der bedeutendsten Anbieter und Entwickler im Gebiet Web-Services mit der Technologie SUN ONE (Open Net Environment)^[5], definiert Web-Services wie folgt: „A Web service is, simply put, application functionality made available on the World Wide Web. A Web service consists of a network-accessible service, plus a formal description of how to connect to and use the service. The language for formal description of a Web service is an application of XML. A Web service description defines a contract for how another system can access the service for data, or in order to get something done. Development tools, or even autonomous software agents, can automatically discover and bind existing Web services into new applications, based on the description of the service.”^[6]. Diese engere Definition zeigt einen speziellen Nutzungsrahmen auf, die Nutzung im WWW.

Es ist jedoch nicht notwendiges Kriterium, dass eine Anwendung mittels Web-Service-Technologie im WWW zur Verfügung gestellt wird. Gerade im Finanzdienstleistungssektor sehen wir oftmals Anwendungen, die Web-Services lediglich im Konzern selbst nutzen, ohne einen Dienst im WWW publik machen zu wollen^[7]. Verschiedene Verfasser weisen auf diesen Fakt, dass „die meisten Projekte“ eher „der internen und nicht öffentlich zugänglichen Integration von Anwendungen“ dienen, explizit hin^[8]. Hierauf wird in den Praxisfällen noch weiter eingegangen^[9].

Techniken der Web-Services

Genauso wie es bei der Definition Unterschiede gibt, gibt es unterschiedliche Quellen, welche Techniken bei Web-Services eingesetzt werden. Denn ob Web-Services explizit ein bestimmtes Protokoll nutzen muss oder Wahlmöglichkeiten bestehen ist nicht festgeschrieben. Einen guten Überblick über die bestehenden Techniken und deren Anordnung bietet die nachfolgende Darstellung:

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1: Zwiebelschalendefinition des Web-Service Begriffs^[10]

Wir sehen hier, dass die Dienstleistung im Zentrum steht. Diese Dienstleistung ist auf einem bestimmten System in einer bestimmten Programmiersprache implementiert und soll anderen Systemen zur Verfügung stehen (im Internet oder innerhalb eines betrieblichen Systems). Web-Services stellt nun diese Technologie zur Verfügung, indem es eine Schnittstelle bietet, die standardisiert ist. Bei der Übertragung der Inhalte hat sich XML als Standard bereits quasi-etabliert^[11].

Als Transport-Protokoll dient meist das SOAP-Protokoll, welches sich der Beschreibungssprache XML bedient^[12]. Die Anfragen und Rückmeldungen werden hierbei in einen so genannten SOAP-Envelope eingefasst.

Für den Finanzdienstleistungssektor ist hierbei relevant, dass über das SOAP-Protokoll eine Identifizierung der Geschäftspartner realisiert werden kann. Dies ist besonders wichtig, wenn rechtsverbindliche Transaktionen ausgeführt werden sollen oder wenn kostenpflichtige Anwendungen zur Verfügung stehen. Die Identifizierung (bzw. Legitimation) wird realisiert über so genannte namespaces^[13].

Da die Sicherheit und Transaktionalität von Web-Services ein wichtiger Faktor für die Durchsetzung von Web-Services ist, dies jedoch den Rahmen dieser Arbeit sprengen würde, sei hier auf den Artikel „Risikokanidat“ von Khaled Popal hingewiesen^[14].

Die im folgenden beschriebenen Techniken UDDI und WSDL dienen der öffentlichen Bekanntmachung und Beschreibung von Web-Services^[15]. Diese Technologien können auch für interne Projekte verwendet werden. Da die Anwendungen jedoch meist einmal implementiert werden und die Clients nur einmal angepasst werden müssen, ist die Verwendung bisher meist unüblich.

Grundgedanke hierbei ist es, dass in einem öffentlichen Verzeichnis, ähnlich der Gelben-Seiten, die einzelnen öffentlich angebotenen Web-Services-Anwendungen dokumentiert werden^[16].

Die einzelnen Anwendungen und ihre technischen Spezifikationen, wie Struktur und Aufbau des Anfrage- und Rückantwort-SOAP-Envelopes etc., sollen in einem auf XML basierenden WSDL-Dokument beschrieben werden. Damit wäre es dann technisch möglich, dass Anwendungen bei einem Verzeichnisdienst, der zentral gehostet ist, eine Anfrage zu einem bestimmten Problem stellen und dieses Verzeichnis dann alle verfügbaren Anwendungen inklusive der Beschreibung zurückgibt. Die Anwendung kann dann die Web-Services nutzen und die Ergebnisse dem User anzeigen lassen. In der nachfolgenden Grafik wird der Ablauf von einem solchen Aufruf schematisch dargestellt:

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2: Schematische Darstellung eines Web-Services-Aufrufs^[17]

Anzumerken ist, dass sich alle der hier beschriebenen Techniken, SOAP, WSDL sowie UDDI, der Sprache XML bedienen. Damit ist gewährleistet, dass Basistechnologien für den Transport, wie HTTP ohne Probleme genutzt werden können. Dies hat den Vorteil, dass Übertragungsprobleme durch Firewalls eliminiert sind, da XML reiner ASCI-Text ist. Dies ist für die externe sowie die interne Anwendung von Web-Services ein nicht zu unterschätzender Vorteil im Vergleich zu anderen Lösungen, die durch Firewalls mit Problemen konfrontiert sind.

Interoperabilität von Standards

Es gibt zurzeit verschiedene Institutionen, die an der Realisierung von Web-Services arbeiten. Drei wichtige Technologien scheinen sich hierbei durchzusetzen^[18]. Diese sind zurzeit .Net^[19], Enterprise JavaBeans/J2EE^[20] und CORBA^[21]. Wichtig hierbei ist, sofern die Dienstleistungen in den Finanzinstitutionen auch im WWW zur Verfügung gestellt werden sollen, dass die Techniken im Bezug auf Interoperabilität miteinander kooperieren^[22]. Innerhalb eines abgekapselten Projekts kann dieser Faktor vernachlässigt werden, sofern mit nur einer Technologie gearbeitet wird.

3. Anwendungsszenarien im Finanzdienstleistungssektor

Es wurde nun die Technologie, die hinter Web-Services steht, beschrieben und Besonderheiten im Hinblick auf den Finanzdienstleitungssektor herausgestellt. Nun soll erläutert werden, wie eine konkrete Anwendung in diesem Sektor aussehen könnte.

Dabei wird zwischen der bereits erläuterten Aufteilung von internen und externen Anwendungsgebieten unterschieden.

3.1. Interne Anwendungsgebiete

Die Anwendungsfelder im internen Bereich, also innerhalb der Unternehmen selbst, sind als eher sektorenunspezifisch zu betrachten. Die Probleme von heterogenen Programmen auf heterogenen Systemen können sich bei jedem größeren Unternehmen ergeben. Gerade aber in Banken ist diese Situation oftmals vorzufinden. Die internen Anwendungsgebiete lassen sich in drei Gruppen einteilen, die im Folgenden erläutert werden.

Veraltete Technologie

Gerade in Großbanken, aber auch in Versicherungsunternehmen und anderen, sich bereits seit längerem am Markt befindlichen Unternehmen, werden oftmals veraltete Technologien verwendet. Systeme, die vor längerer Zeit angeschafft wurden, beinhalten zentral gespeicherte Daten auf einem so genannten Mainframe. Der Aufwand, die Daten in ein neueres, moderneres System zu überführen, überstieg bis heute die Kosten das System trotz seiner evtl. schlechteren Performance immer wieder anzupassen. Eine sehr häufig anzufindende Programmiersprache ist in diesem Zusammenhang COBOL. Bei jeder Änderung muss ein neues Programm geschrieben werden.

Mit der jetzt verfügbaren Technologie ist es möglich, Web-Services einmalig auf dem Mainframe zu installieren und damit das System für andere Betriebssysteme und Programme zur Verfügung zu stellen. Die Anfragen und Rückgaben würden dann z.B. in SOAP übermittelt. Ob das UDDI- und das WSDL-Protokoll Einsatz finden würden ist dabei nicht zwangsläufig.

Heterogenes EDV-System

Oftmals sind die EDV-Systeme in einem Unternehmen oder einem Konzern bzw. Verbund sehr heterogen. Ein Phänomen, das sehr häufig bei zusammengewachsenen Unternehmen, aber auch bei im Verbund organisierten Unternehmen anzutreffen ist. Es wird an dieser Stelle auf Kapitel 4 hingewiesen, wo ein solches Anwendungsszenario im Sparkassensektor beschrieben ist.

Mittels der Web-Services-Technologie können heterogene Systeme miteinander kommunizieren, ohne dass die Systeme kostenaufwendig komplett ausgetauscht werden müssen. Auch hierbei ist der Einsatz von UDDI oder WSDL dem Unternehmen überlassen.

Konzipieren von neuen Systemen

Die bisher beschriebenen Anwendungsszenarien gehen immer von bereits bestehenden Anwendungen in den Betrieben aus. Oftmals steht ein Unternehmen aber vor der Frage in welcher Form neue Anwendungen implementiert werden sollen. Web-Services dienen lediglich zur Kommunikation und Verbindung von verteilten Anwendungen. Bei der Entwicklung von neuen Systemen könnte die gleichzeitige Implementierung der Schnittstellen für Web-Services mehr Bedeutung erfahren. Die Systeme sind dann später einfacher in andere Umgebungen zu integrieren. Denkbar ist auch, dass einzelne Funktionen erst zu einem späteren Zeitpunkt über Web-Services zugänglich gemacht werden müssen.

3.2. Externe Anwendungsgebiete

Um die externen Anwendungsgebiete im Finanzdienstleistungssektor beschreiben zu können, muss der Begriff Finanzdienstleistungssektor zuerst definiert werden. Da sich jedoch bei den verschiedenen Institutionen enorme Überschneidungen bei den Dienstleistungen ergeben (sowohl eine Versicherung, ein Finanzdienstleister als auch eine Bank können Versicherungen anbieten) wird in der Arbeit so vorgegangen, dass über die Definition Finanzdienstleistung^[23] die Dienstleistungen strukturiert werden. Anhand der Tätigkeiten werden dann mögliche Anwendungsszenarien beschrieben.

Eine Finanzdienstleistung ist „jede Dienstleistung finanzieller Art, die von einem Finanzdienstleistungserbringer einer Vertragspartei angeboten wird“^[24]. Damit sind im Rückschluss alle Unternehmen, die diese Dienstleistungen anbieten, als Finanzdienstleistungserbringer zu definieren. Wer dabei welche Dienstleistung erbringt, ist für die vorliegende Arbeit von sekundärer Relevanz.

Zu den Finanzdienstleistungen gehören folgende Tätigkeiten^[25] :

A. Alle Versicherungsdienstleistungen und versicherungsbezogenen Dienstleistungen
1. Direktversicherung / Rückversicherung und Folgerückversicherung
2. Versicherungsvermittlung wie Leistungen von Versicherungsmaklern und -agenturen
3. Versicherungsbezogene Hilfsdienstleistungen wie Versicherungs-mathematik, Risikobewertung und Schadensregulierung

B. Bank- und sonstige Finanzdienstleistungen (ausgenommen Versicherungsdienstleistungen)
1. Annahme von Spar- und sonstigen rückzahlbaren Einlagen von Kunden
2. Ausreichung von Krediten jeder Art, einschließlich Verbraucherkredit, Hypothekenkredit, Factoring und Finanzierung von Handelsgeschäften

[...]

^[1] Vgl. Kosch, Andreas, 2002, S. 33.

^[2] Vgl. Knuth, Michael, 2002, S. 13ff.

^[3] Vgl. Jeckle, Mario, 2002.

^[4] Meyen, Sebastian, S. 15.

^[5] Vgl. Sarakatsanis, Anthanasios, 2001, S. 40.

^[6] Vgl. Jeckle, Mario, 2002.

^[7] Vgl.Craes, Michael / Oellermann, Frank, 2002, S. 95ff.

^[8] Ziegler, Cai, 2002, S. 42.

^[9] Vgl. Abschnitt 4.

^[10] Jeckle, Mario, 2002.

^[11] Ersichtlich aus den einzelnen Definitionen von Web-Services verschiedener Institutionen und den Implementierungs-Anleitungen diverser Fachzeitschriften.

^[12] Vgl. Großwendt, Colkmar, 2002, S. 95.

^[13] Vgl. Cerami, Ethan, 2002, S. 15.

^[14] Vgl. Popal, Khaled, 2002, S. 78ff.

^[15] Hierauf wird in den nachfolgenden Kapiteln, insbesondere im Kapitel Praxisfälle für Web-Services näher eingegangen.

^[16] Vgl. Ziegler, Cai, 2002, S. 40.

^[17] Vgl. Ziegler, Cai, 2002, S. 40.

^[18] Hofmann zur Linden, Klaus / Koschel, Arne, S. 87

^[19] Microsoft

^[20] SUN

^[21] Object Management Group

^[22] Hofmann zur Linden, Klaus / Koschel, Arne, S. 87

^[23] Dialoge Beratungsgesellschaft, 2001, S. 68ff.

^[24] Dialoge Beratungsgesellschaft, 2001, S. 68.

^[25] Vgl. Dialoge Beratungsgesellschaft, 2001, S. 68ff.