Analyse von Web-Services in Wertschöpfungsprozessen, insbesondere Konfiguration von Informationsprodukten

Inhaltsverzeichnis

Versicherung

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

Symbolverzeichnis

1 Fragestellung und Ziel der Arbeit

2 Grundlagen zu Web-Services
2.1 Definition und Abgrenzung von Web-Services
2.2 Die Funktionsweise von Web-Services
2.3 Die Architektur von Web-Services
2.3.1 Überblick über die Basiskomponenten von Web-Services
2.3.2 Netzwerkinfrastruktur und Transport für Web-Services
2.3.3 Kommunikation und Nachrichtengestaltung für Web-Services
2.3.4 Web-Service-Beschreibung
2.3.5 Web-Service-Verzeichnis
2.4 Übersicht über die innovativen Merkmale von Web-Services

3 Bewertungskriterien für Web-Services
3.1 Technische Kriterien zur Bewertung von Web-Services
3.1.1 Technische Kriterien anhand von Eigenschaften der Technologie
3.1.2 Technische Kriterien für verteilte Anwendungen
3.2 Betriebswirtschaftliche Kriterien zur Bewertung von Web-Services
3.2.1 Quantitative betriebswirtschaftliche Kriterien
3.2.2 Qualitative betriebswirtschaftliche Kriterien
3.3 Einfluss von Unsicherheit auf die Web-Services-Bewertung
3.4 Übersicht über Bewertungskriterien für Web-Services

4 Web-Services in Wertschöpfungsprozessen
4.1 Übersicht zu betrieblichen Wertschöpfungsprozessen
4.2 Web-Services in Beschaffungsprozessen
4.2.1 Charakterisierung der Wertschöpfungsstufe Beschaffung
4.2.2 Anwendungsbeispiele für Web-Services in Beschaffungsprozessen
4.2.3 Analyse von Web-Services in Beschaffungsprozessen
4.3 Web-Services in Produktionsprozessen
4.3.1 Charakterisierung der Wertschöpfungsstufe Produktion
4.3.2 Anwendungsbeispiele für Web-Services in Produktionsprozessen
4.3.3 Analyse von Web-Services in Produktionsprozessen 33

4.4 Web-Services in Absatzprozessen
4.4.1 Charakterisierung der Wertschöpfungsstufe Absatz
4.4.2 Anwendungsbeispiele von Web-Services in Absatzprozessen
4.4.3 Analyse von Web-Services in Absatzprozessen
4.5 Weitere Einsatzbereiche von Web-Services in Wertschöpfungsprozessen
4.6 Anforderungen an Web-Services in Wertschöpfungsprozessen
4.6.1 Sicherheit für Web-Services
4.6.2 Geschäftsprozesse mit Web-Services: Transaktionen und Workflows
4.7 Zusammenfassung und Schlussfolgerungen zu Web-Services in Wertschöpfungsprozessen

5 Die Konfiguration von Informationsprodukten mit Web-Services
5.1 Zum Begriff der Informationsprodukte
5.2 Der Konfigurationsprozess für Informationsprodukte
5.3 Chancen und Herausforderungen für die Konfiguration von Informationsprodukten mit Web-Services
5.3.1 Die Berücksichtigung der Semantik im Konfigurationsprozess für Informationsprodukte
5.3.2 Individualisierung und Dynamisierung von Informationsprodukten
5.3.3 Der Einfluss der Produkteigenschaften auf den Konfigurationsprozess
5.4 Analyse von Web-Services in Konfigurationsprozessen für
Informationsprodukte
5.5 Zusammenfassung zur Konfiguration von Informationsprodukten

6 Auswirkung von Web-Services auf Wertschöpfungsstrukturen
6.1 Die Fragmentierung der Wertschöpfungskette durch Web-Services
6.1.1 Outsourcing-Effekte durch Web-Services
6.1.2 Temporäre Integrations- und Konzentrationseffekte durch Web-Services
6.2 Web-Services als neuartiges Produkt
6.3 Substitution des Produktionsfaktors Arbeit durch Web-Services

7 Zusammenfassung und Ausblick
Anhang A: Ergänzende Abbildungen zu Kapitel 2
Anhang B: Ergänzende Abbildungen zu Kapitel 3
Anhang C: Ergänzende Abbildung zu Kapitel 4
Anhang D: Ergänzende Abbildung zu Kapitel 5
Anhang E: CD-Rom zur Diplomarbeit

Literaturverzeichnis

Versicherung

„Ich versichere hiermit, dass ich die vorliegende Arbeit selbständig und nur unter Benutzung der angegebenen Literatur und Hilfsmittel angefertigt habe. Wörtlich übernommene Sätze und Satzteile sind als Zitat belegt, andere Anlehnungen hinsichtlich Aussage und Umfang unter den Quellenangaben kenntlich gemacht. Die Arbeit hat in gleicher oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegen und ist nicht veröffentlicht.“

Ort, Datum: Unterschrift:

In Erinnerung an

Karola Debus (†)

und

für Birte

Abbildungsverzeichnis

Abbildung 1: Serviceorientierte Architektur von Web-Services

Abbildung 2: Schichten des Web-Services Protokollstapel

Abbildung 3: Die innovative Merkmalskombination von Web-Services

Abbildung 4: Das Modell der Wertkette nach Porter

Abbildung 5: Die betrachteten Wertschöpfungsstufen

Abbildung 6: Ausgewählte Beschreibungsmerkmale der Wertschöpfungs- stufe Beschaffung

Abbildung 7: Ein Beispiel für Web-Services in der Beschaffung

Abbildung 8: Potenzielle Kostenwirkungen von Web-Services in Be-
schaffungsprozessen nach Kostentyp und Transaktionsphase

Abbildung 9: Ausgewählte Beschreibungsmerkmale der Wertschöpfungs-
stufe Produktion

Abbildung 10: Ausgewählte Beschreibungsmerkmale der Wertschöpfungs- stufe Absatz

Abbildung 11: Orchestration und Choreographie von Web-Services

Abbildung 12: Chancen und Risiken von Web-Services in Wertschöpfungs- prozessen

Abbildung 13: Portfoliomodell für Web-Services-Kategorien

Abbildung 14: Typologisierung von Informationsprodukten

Abbildung 15: Modell des Konfigurationsprozesses

Abbildung 16: Teilung des Konfigurationsprozesses bei der Individualisie- rung von Informationsprodukten

Abbildung 17: Reduktion manueller Wiederholungen von Konfigurations- aufgaben für periodisch herausgegebene Informationspro- dukte durch Web-Services am Beispiel von Grafik und Video

Abbildung 18: Sequenzdiagramm für einen ortsbezogenen Hotel-
Informationsservice

Tabellenverzeichnis

Tabelle 1: Technische Kriterien zur Bewertung von Web-Services

Tabelle 2: Betriebswirtschaftliche Kriterien zur Bewertung von Web-Services

Tabelle 3: Funktionen von Web-Services zur Bestimmung des
Konfigurationsraumes von Informationsprodukten

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Symbolverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Fragestellung und Ziel der Arbeit

Die Berücksichtigung der in immer kürzeren Zeitabständen auftretenden technischen Entwicklungen zählt heute zu den entscheidenden Faktoren für den zukünftigen wirtschaftlichen Erfolg von Unternehmen. Diese werden mit neuen Technologien konfrontiert, die sie aus ihrer jeweiligen Perspektive verstehen, abschätzen und bewerten müssen, um eine Entscheidung über Art und Umfang eines möglichen Einsatzes zu fällen. Dabei geht es nicht mehr nur um die innerbetriebliche Hilfsfunktion von Informations- und Kommunikationssystemen oder von EDV-Abteilungen. Technologische Neuerungen sind häufig Treiber zusätzlicher Wertschöpfung in Unternehmen.^[1] Eine sorgfältige unternehmerische Planung im gesamten Spektrum heutiger informationstechnischer Möglichkeiten kann einen entscheidenden Beitrag zu der zukünftigen Stellung eines Unternehmens im Markt leisten.^[2]

In der vorliegenden Diplomarbeit wird ein Ansatz der zahlreichen informationstechnischen Neuerungen untersucht, die so genannten Web-Services. Ziel dieser Ausarbeitung ist es, Anwendungsmöglichkeiten für Web-Services und Auswirkungen der Technologie herauszuarbeiten. Die ökonomische Bewertung von Web-Services wird dabei anhand einer systematischen Analyse vorgenommen. Einer weitere Spezialisierung untersucht die konkrete Verwendung von Web-Services im Bereich der Produktpolitik für die Konfiguration von Informationsprodukten als spezielles Wirtschaftsgut. Eine Herausforderung für die Analyse besteht in einer angemessenen Zusammenführung
ökonomischer Beurteilungskonzepte und technischer Kriterien aus der Wirtschaftsinformatik. Die Arbeit hat zum Ziel, beide Bereiche in ein gemeinsames Rahmenwerk zur Beurteilung von Web-Services zu integrieren.

Die einzelnen Schritte zur Erreichung des soeben beschriebenen Gesamtziels lassen sich anhand von vier Bereichen beschreiben. Erstens erläutert der Verfasser das Konzept von Web-Services. Dazu gehört zunächst eine Begriffsbestimmung, die Beschreibung der Funktionsweisen sowie die Vorstellung der technischen Web-Services Architektur. Mit Beginn des Hauptteils dieser Schrift wird zum Zweiten ein Rahmenwerk für eine Bewertung der Technologie aus der Sicht der Wirtschaftsinformatik entwickelt, das sich aus technischen und ökonomischen Bewertungskriterien zusammensetzt. Der dritte Teil greift das aus der Betriebswirtschaftslehre bekannte Konzept der Wertschöpfungskette auf und zeigt entlang dieser die Anwendungsfelder für Web-Services auf. Diese werden zunächst in einzelnen Abschnitten beschrieben und anhand von Beispielen erläutert. Um eine systematische Darlegung zu erreichen, rundet eine Potenzialanalyse die jeweiligen Ausführungen unter Zuhilfenahme der entwickelten Bewertungskriterien ab.

Die weitere Spezialisierung im Verlauf dieser Schrift bildet die Betrachtung der Verwendung von Web-Services zur Konfiguration von Informationsprodukten. Dazu wird zunächst der Begriff des Informationsproduktes betrachtet und die Funktionsweise der Konfiguration erläutert. Anschließend wird untersucht, an welcher Stelle Web-Services im Konfigurationsprozess zur Erreichung des unternehmerischen Sachziels „Verkauf von Informationsprodukten“ eingesetzt werden könnten, welche Anforderungen damit verbunden sind und welche Veränderungen damit jeweils einhergehen.

Im letzten Kapitel wird der Fokus vom Unternehmen auf die Volkswirtschaft erweitert. Dabei wird auch ein knapper Ausblick auf die aus Sicht des Autors unter bestimmten Voraussetzungen zu erwartenden Einflüsse der Technologie auf die Wirtschaftsstruktur gegeben. Die Arbeit endet mit einer Zusammenfassung der gewonnenen Erkenntnisse.

2 Grundlagen zu Web-Services

In diesem Kapitel wird ein Verständnis des Begriffes Web-Services vermittelt, wobei in der Literatur eine endgültige Verständigung über den Begriff allerdings noch nicht erfolgt ist.^[3] Daher gibt dieses Kapitel nicht nur eine knappe Definition, es erfolgt vielmehr eine Betrachtung des Ansatzes aus verschiedenen Blickwinkeln. Das Kapitel beginnt in Abschnitt 2.1 mit einer Definition und Abgrenzung von Web-Services gefolgt von einer Übersicht der Funktionsweise (2.2). Die charakteristischen Eigenschaften von Web-Services werden im Rahmen der Darstellung der Architektur von Web-Services herausgearbeitet (2.3). Zum Abschluss der Grundlagen werden die innovativen Eigenschaften nochmals prägnant zusammengefasst (2.4).

2.1 Definition und Abgrenzung von Web-Services

Lässt man sich bei dem Begriff Web-Services von dem Wortlaut der sinngemäßen Übersetzung „Netzdienst“ leiten, so denkt man zunächst an eine über das World Wide Web (WWW) zur Verfügung gestellte Dienstleistung. Diese assoziative Übersetzung berücksichtigt jedoch die Möglichkeiten der Technologie nur teilweise und beschreibt lediglich eine mögliche Anwendung.

Im Weiteren wird eine präzisere und dennoch einfach gehaltene Definition von Snell/Tidwell/Kulchenko zu Grunde gelegt, die Web-Services konzeptionell wie folgt definieren:

„A Web-Service is a network accessible interface to application functionality, built using standard Internet technologies“^[4].

Diese Definition beschreibt die Kernelemente eines Web-Services, nämlich eine Schnittstelle zu Anwendungsfunktionalität über standardisierte Internettechnologien. Der zunächst abstrakt erscheinende Begriff Anwendungsfunktionalität steht hierbei für die Möglichkeit, durch den Web-Service Daten zwischen Systemen derart auszutauschen, dass eine Fragestellung beantwortet oder eine Aufgabe erfüllt werden kann. Diese können je nach Rolle der Anwender oder der daran beteiligten Systeme sehr unterschiedliche Ausprägungen annehmen.

Es sei darauf hingewiesen, dass das Internet bzw. der Wortbestandteil Web lediglich die verwendeten Techniken beschreibt, nicht aber den ausschließlichen Übertragungs- bzw. Nutzungsweg. So wird in obiger Definition vielmehr von einem Netzwerk gesprochen.^[5] Diese Auslegung des Begriffes Web erlaubt die Berücksichtigung eines großen Anwendungsbereichs, und zwar denjenigen in nicht-öffentlichen Unternehmensnetzwerken bzw. Virtual Private Networks (VPN).^[6] Unabhängig davon, welches Netzwerk verwendet wird, finden Web-Services in einer Umgebung statt, die als verteiltes System bezeichnet werden kann.^[7]

Die oben beschriebene Definition von Snell/Tidwell/Kulchenko bildet zwar eine gute Grundlage, sie ist aber um weitere Komponenten zu erweitern, damit Web-Services als neuer Ansatz gegenüber bestehenden Konzepten differenziert werden können. Aus diesem Grund ist noch das Merkmal der so genannten Interoperabilität von Web-Services hinzuzufügen.^[8] Sie besagt, dass für die Nutzung eines Web-Services Unabhängigkeit von verschiedenen Betriebssystemen und Programmierplattformen besteht. Zur Erreichung dieser Unabhängigkeit wird von Cerami die Verwendung der Extensible Markup Language (XML) in einem Web-Service betont.^[9] Das W3C, ein anerkanntes Standardisierungsgremium für Internetprotokolle, charakterisiert XML sogar als fundamentale Eigenschaft von Web-Services und empfiehlt die Beschreibung von Schnittstellen und des Kommunikationsprotokolls über XML-Sprachkonzepte.^[10] Für eine begriffsmäßige Bestimmung von Web-Services reichen die bisher dargelegten Merkmale aus. Ein Web-Service wird damit zusammenfassend durch folgende notwendige und hinreichende Eigenschaften charakterisiert:

- Ein Web-Service bietet Zugang zur Anwendungsfunktionalität.
- Es existiert eine Definition des Web-Services, die von anderen Softwaresystemen oder Nutzern aufgefunden werden kann.
- Web-Services nutzen eine standardisierte Schnittstelle, die über ein Netzwerk zugänglich ist.
- Web-Services werden realisiert über standardisierte Internettechnologien.
- Web-Services sind unabhängig von verwendeten Betriebssystemen einsetzbar.^[11]

Im Weiteren werden die Begiffe Web-Service, das deutschsprachige Pendant Netzdienst, Mischformen wie Web-Dienst und die Kurzformen Service oder Dienst analog verwendet.

Nach dieser Definition bleibt noch eine Abgrenzung vorzunehmen. Aus der Fachliteratur geht hervor, dass der Begriff Web-Services aus verschiedenen Perspektiven betrachtet werden kann. So wird häufig von der technischen und der ökonomischen Perspektive gesprochen.^[12] Um eine betriebswirtschaftliche Analyse im weiteren Verlauf zu erleichtern, soll hier eine Abgrenzung verschiedener technischer Ansätze vorgenommen werden. Web-Services stellen nicht die einzige Möglichkeit dar, Anwendungen oder Systeme miteinander zu verbinden.^[13] Sie sind vielmehr als eine neuartige Methode anzusehen, welche die Funktionalitäten im Gegensatz zu anderen bereits verfügbaren Verfahren auf neue Weise erschließt. Darüber hinaus eröffnen Web-Services aber auch neue Anwendungsfelder. Für eine Einordnung des Ansatzes werden Web-Services im Folgenden von dem Begriff der Middleware, dem Datenaustauschformat EDI und dem Schlagwort der Softwareagenten abgegrenzt sowie Gemeinsamkeiten umrissen.

Eine Middleware stellt eine standardisierte Softwareschicht dar, die zur Ermöglichung einer Kommunikationsverbindung Kompatibilität zwischen verschiedenartigen verteilten Anwendungen und Betriebssystemen herstellt.^[14] Bezogen auf die Herstellung von Kommunikation ist die Web-Service-Architektur als Middleware anzusehen. Zur Ausführung einer konkreten Anwendung sind Web-Services in ihrer Basiskonzeption jedoch auf die lokalen Systeme angewiesen. Zwar kann die Nutzung von entfernter Funktionalität auch über andere Middleware wie CORBA oder DCOM geschaffen werden. Web-Services zeichnen sich jedoch idealerweise zusätzlich durch Verwendung von Internetstandards, die Überwindung von Firewalls, Interoperabilität und lose Kopplung, also das Auffinden und Einbinden von Softwarekomponenten zur Laufzeit, aus.^[15]

Für Businessanwendungen spielt der Datenaustausch eine große Rolle. Der Standard Electronic Data Interchange (EDI) ist ein bekannter Repräsentant für diesen Anwendungstyp. Er unterscheidet sich jedoch deutlich von Web-Services. So besteht EDI aus festen Segmenten, denen entsprechend dem Standard bestimmte Daten und deren Bedeutung a priori zugeordnet sind.^[16] Bei der Verwendung von Web-Services hingegen kann die Art der Abbildung zu übertragender Daten über XML individuell modelliert werden, was potenziell eine wesentlich höhere Anwendungsflexibilität zur Folge hat. Die Einbindung unbekannter Geschäftspartner zur Laufzeit mit einer Kommunikation von Anwendung-zu-Anwendung ist bei EDI gar ausgeschlossen.^[17]

Bleibt noch die Abgrenzung gegenüber Softwareagenten vorzunehmen. Sie weisen sich durch Autonomie, Mobilität, Lernfähigkeit, Kooperationsfähigkeit und Entscheidungskompetenz aus.^[18] Sie können ihre Handlungen in Hinblick auf ein bestimmtes Ziel ohne Interaktion mit einem menschlichen Agenten proaktiv verfolgen, wofür sie auch zwischen Systemen migrieren. Betrachtet man Web-Services unter diesem Gesichtspunkt, so umfassen sie einige dieser Fähigkeiten. Web-Services ermöglichen durch die Bereitstellung eines Kommunikationsmodells eine Kollaboration zwischen Anwendungen und eine aufgabenspezifische Autonomität ohne menschliche Interaktion. Zum Teil werden Web-Services und Agententechnologien daher bereits gemeinsam diskutiert.^[19] Andererseits zeichnen sich Agenten durch mobilen und persistenten Programmcode, Entscheidungskompetenz und Lernfähigkeit aus. Diese Eigenschaften leisten Web-Services i.e.S. nicht.^[20] Insgesamt ist es derzeit schwierig, eine treffsichere Einordnung unabhängig vom jeweiligen Blickwinkel vorzunehmen.^[21]

2.2 Die Funktionsweise von Web-Services

Das Ziel bei der Verwendung von Web-Services besteht darin, verteilte Anwendungen oder Systeme zu integrieren, so dass lokal vorliegende Daten oder Anwendungen zugänglich gemacht werden. Ein Web-Service bietet somit eine ganz bestimmte Funktion an, z.B. die Extraktion eines Produktpreises aus der Datenbank eines entfernten Computersystems. Aus der technischen Perspektive lassen sich derartige Aktionen als entfernte Methodenaufrufe bezeichnen.^[22] Dabei kann der Umfang des Web-Services vom Anbieter frei bestimmt werden. Es könnte sowohl nur ein Teil einer lokal existierenden Anwendung, als auch die gesamte Anwendung als Web-Service zur Verfügung gestellt werden. Weiterhin kann ein Netzdienst weitere Web-Services einbinden und wiederum deren Funktionen nutzen.^[23]

Die grundlegende Funktionsweise zeigt Abbildung 1. Das in der Abbildung dargestellte „System 2“ kann als Dienstanbieter grundsätzlich von jedem anderen System angesprochen werden, wie hier von dem als Klienten bezeichneten „System 1“, sofern die beteiligten Systeme mit einer Web-Services-Schnittstelle ausgestattet sind. Wie in der Definition bereits erwähnt, findet die Einbindung eines Web-Services charakteristischer Weise nicht in einem direkten Dialog der beteiligten Rechner, sondern entkoppelt statt. Der Service wird zunächst über ein Dienstverzeichnis aufgefunden und anschließend über den Anbieter in die eigene Anwendungsumgebung eingebunden.

Abbildung in dieser Leseprobe nicht enthalten

Dieses Vorgehen erscheint vorteilhaft, da in verteilten Systemen nicht davon ausgegangen werden kann, dass der Web-Service und dessen Lokalisation bekannt ist. So stellt zunächst „System 2“ in der Rolle des Dienstanbieters einen Web-Service über die dargestellte Operation „Service publizieren“ als Eintrag in dem dafür vorgesehenen Dienstverzeichnis zur Verfügung. Mit diesem Eintrag wird der Service publiziert. Das als Nachfrager (Klient) auftretende System, hier „System 1“, kann diesen dort finden und anschließend anhand der abgelegten Informationen erreichen. Erst jetzt kommt die Einbindung des Web-Services zu Stande. Die in Abbildung 1 dargestellten Beziehungen spiegeln dabei die logische Funktionsweise von Web-Services wider. Die physische Verteilung der beteiligten Komponenten kann unterschiedlich organisiert werden; sie müssen lediglich jeweils über das verwendete Netzwerk zugänglich sein. Im Gegensatz zu bisherigen Internet-Anwendungen soll das Auffinden, die Einbindung und die Ausführung entfernter Funktionen als Web-Service auch automatisch möglich sein, wobei derzeit eine erstmalige Einbindung noch manuell zu erstellen ist.^[24]

2.3 Die Architektur von Web-Services

Nachdem in dem vorangegangenen Abschnitt der Begriff Web-Services definiert und abgegrenzt wurde, soll nun die Architektur von Web-Services betrachtet werden. Ein detailliertes Verständnis der technischen Bestandteile stellt eine unabdingbare Voraussetzung für die folgende Analyse dar. Deswegen führen die folgenden Abschnitte kurz in die grundlegenden technischen Bestandteile von Web-Services ein.

2.3.1 Überblick über die Basiskomponenten von Web-Services

Ein Web-Service ist kein monolithisches Gebilde, sondern setzt sich aus einzelnen Spezifikationen zusammen, die gemeinsam eine serviceorientierte Architektur (SOA) ergeben.^[25] Diese Bestandteile von Web-Services lassen sich anschaulich in verschiedenen Schichten darstellen, wobei jede der Schichten eine spezifische Aufgabe bei der Anwendung übernimmt. Gemeinsam bilden diese Schichten den so genannten Protokollstapel.^[26] Dieser kann in der Praxis über verschiedenartige Protokolle realisiert werden. Hier wird der vom W3C standardisierte und weithin akzeptierte Aufbau dargestellt, dessen beteiligte Protokolle daher als Standardprotokolle oder Basiskomponenten zu bezeichnen sind.^[27] Die Struktur zeigt Abbildung 2 auf der folgenden Seite. In der rechten Spalte der Grafik findet sich zu jeder auf der linken Seite abgebildeten Schicht das dazugehörige technische Web-Services-Protokoll des W3C Standards.

Abbildung in dieser Leseprobe nicht enthalten

Zur Implementierung eines Web-Services müssen für die einzelnen schichtenspezifischen Aufgaben in einer passenden Weise Protokolle bereitgestellt werden. Zum Teil werden die einzelnen Schichten in der Literatur nochmals in Gruppen zusammengefasst.^[28] So weist etwa das W3C die drei Gruppen Beschreibungsstapel (Discription Stack), Verbindungsstapel (Wire Stack) und Verzeichnisstapel (Discovery Stack) aus.^[29] Neben der Erläuterung der beschriebenen Basiskomponenten werden in den folgenden Abschnitten auch Alternativen zu den Standardprotokollen benannt.

2.3.2 Netzwerkinfrastruktur und Transport für Web-Services

Die Netzwerkinfrastruktur wird durch das Transport Control Protocol /Internet Protocol (TCP/IP) bereitgestellt. Für Web-Services, die außerhalb von Firmennetzwerken zum Einsatz kommen, stellt dieses Protokoll die Grundlage dar. Den Transport des Web-Services steuert das verwendete Transportprotokoll. Durch seine weite Verbreitung kann das Hypertext Transfer Protokoll (HTTP) als der de-facto-Standard der Netzwerkprotokolle bezeichnet werden. Daneben werden dem HTTP die Eigenschaften Stabilität und Einfachheit zugeschrieben.^[30] Als nachteilig für eine Verwendung des HTT-Protokolls benennt Cerami, dass es den Anforderungen Reliabilität und Effizienz für
eine Verwendung von entfernten Methodenaufrufen (RPC) durch seine ursprüngliche Widmung zum Transport von Dokumenten nicht gerecht wird.^[31] Mögliche Schwachstellen wie diese dürften besonders bei der Verknüpfung von Web-Services über mehrere Systeme hinweg an Gewicht gewinnen. Neben HTTP können auch andere Protokolle Anwendung finden, wie etwa SMTP, JMS, FTP oder BEEP.^[32] Da SMTP und FTP ebenfalls weit verbreitet sind, entscheidet eher die Art der an den Service gestellten Anforderungen über die Wahl des Protokolls. SMTP erlaubt z.B. eine asynchrone Verarbeitung von Web-Services.^[33] Das im Folgenden erläuterte SOAP-Protokoll definierte bisher jedoch nur die Bindung an HTTP.^[34]

2.3.3 Kommunikation und Nachrichtengestaltung für Web-Services

Die zuvor beschriebenen Schichten betrafen relativ fixe Standards, während die Aufgabe der Kommunikation als eine flexible Schicht angesehen werden muss. Dies bringt den Vorteil, dass Web-Services anforderungsgerecht beschreibbar sind. Der Bereich umfasst zum Einen die Gestaltung der Nachrichten bzw. der Mitteilungen (Messaging) und zum Anderen die Organisation der Übermittlung (Kommunikation).

Die Basis für die Lösung dieser Aufgaben legt das so genannte Simple Object Access Protocol (SOAP), das seit 1999 auf dem Markt ist und aktuell in der Version 1.2 vorliegt.^[35] Es basiert auf der Extensible Markup Language (XML) und wurde für den Informationsaustausch in dezentralisierten Umgebungen entwickelt, insbesondere zwischen Anwendungen.^[36] Im Aufbau bildet der so genannte Umschlag (Envelope) den Rahmen der Nachricht, indem er den Inhalt umschließt.^[37] Der Kern einer SOAP-Message besteht aus dem „SOAP-body“, dem Körper, der die eigentliche Nachricht und deren Behandlung enthält. Dieser „body“ ist konstituierender Bestandteil einer SOAP-Nachricht. Darüber hinaus kann ein Umschlag noch optional einen weiteren Beschreibungsteil enthalten, den so genannten „header“. In diesem können zusätzliche für den Businessbereich wünschenswerte oder notwendige Regeln und Vereinbarungen für die Nachricht festgelegt werden, wie z.B. Routing, Authentifizierung oder Prozessregeln zum Transaktionsmanagement.

Insgesamt umfasst das SOAP-Konzept mehrere wichtige Bausteine. Dazu gehört die Beschreibung des Inhaltes einer Nachricht, ein Modell, das Regeln zur Übersetzung von anwendungsspezifischen Datentypen in XML bereitstellt, Konventionen zum Umgang mit Methodenaufrufen und Antworten und eine Anbindung an HTTP.^[38] SOAP ist maßgeblich für die Erreichung der Interoperabilität verantwortlich, indem es den gemeinsamen Nenner für die Datenrepräsentation der heterogenen Systeme bildet. Diese Stärke erhält es über die Eigenschaften, die sich aus XML ableiten.^[39] So lässt es sich sowohl zur Abbildung von Geschäftsdokumenten ähnlich des EDI verwenden, als auch zur Durchführung von verteilten Methodenaufrufen (RPC).^[40] Den ersten Fall bezeichnet man als eine Verwendung im „document-style“, da der Inhalt ein typisches Geschäftsdokument wie eine Rechnung abbildet. Im zweiten Fall handelt es sich um eine Verwendung im so genannten „RPC-style“, bei welcher die XML-Nachricht dann Anfrage und Übermittlung eines für die Ausführungen von Programmfunktionen üblichen Parameters repräsentiert.^[41] SOAP erlaubt darüber hinaus auch Nachrichtenweiterleitung an mehrere Empfänger und unidirektionale Mitteilungen ohne Rückmeldung.^[42] Das Protokoll stellt damit insgesamt einen beträchtlichen Teil der Funktionalität von Web-Services bereit.

Neben dem weitgehend akzeptierten SOAP bestehen eine ganze Reihe weiterer Formate oder Spezifikationen im Bereich der Nachrichtenübermittlung. Beispiele sind XML-RPC, WDDX oder Jabber.^[43] XML-RPC wird als einfache Variante von Web-Services bezeichnet, die kleine Datenabfragen oder Dienste wie Konvertierungen ermöglicht,
aber keine automatische Einbindung von Diensten erlaubt.^[44] Auf sämtliche Vor- und Nachteile aller Alternativen kann allerdings hier nicht eingegangen werden.

2.3.4 Web-Service-Beschreibung

Im Bereich von Web-Services stellt die Beschreibung eines Services eine sehr wichtige und zugleich schwierige Aufgabe dar, da letztendlich auch eine automatische Kommunikation zwischen Systemen angestrebt wird. Aus diesem Grund wurde bei den Standardisierungsbemühungen auch eine Beschreibungssprache mit aufgenommen, die von Microsoft, IBM und Ariba entwickelt wurde und mit deren Hilfe Dienste selbstbeschreibend erstellt werden.^[45] Die vom W3C standardisierte Beschreibungssprache ist die Web Services Description Language, kurz WSDL. Auch die WSDL basiert auf den Regeln der XML.^[46] Sie beschreibt was ein Dienst bietet, welche Aktivitäten ausgeführt werden, verwendete Datentypen, den Nachrichtenaufbau und die Adressierung.^[47] Durch einen zweistufigen Prozess ermöglicht WSDL die Wiederverwendung einmal erstellter Komponenten. Dieser besteht erstens aus der abstrakten Definition des Services und den Datentypen und zweitens aus der Anbindung an konkrete Protokolle.^[48] Mittlerweile
existieren bereits einige Werkzeuge, um WSDL aus Programmcode bzw. Klassen der Programmiersprachen Java oder C++ automatisch zu generieren und vice versa.^[49] Weitere komplexere Ansätze zur Service-Beschreibung sind DAML und RDF.^[50]

2.3.5 Web-Service-Verzeichnis

Den letzten noch fehlenden Baustein des Protokollstapels bildet das Service- oder Dienstverzeichnis. In der Standardvariante trägt es die englische Bezeichnung Universal Description, Discovery and Integration (UDDI), was übersetzt universale Beschreibung, Entdeckung und Integration bedeutet.^[51]

Das UDDI nimmt eine Stellung als Intermediär ein, indem es die Beschreibungen der angebotenen bzw. verfügbaren Web-Services dauerhaft bereitstellt. Es kann auch als Repository bezeichnet werden.^[52] Damit übernimmt es eine Komplexitätsreduktion bezüglich des Suchprozesses, wie sie z.B. mit Telefonbüchern oder Warenkatalogen in zahlreichen Lebensbereichen bereits praktiziert wird. Die Beschreibung besteht dabei aus drei Teilen, die in Analogie zu dem Begriff der „Gelben Seiten“ eingeteilt werden.^[53] Hier sind die so genannten „weißen Seiten“ mit Informationen zum Anbieter, die „gelben Seiten“ mit einer zweckmäßigen Kategorisierung sowie die „grünen Seiten“ mit den Angaben zur Einbindung des Services zu nennen. Theoretisch bietet ein Dienstverzeichnis damit alle Informationen, um eine dynamische Einbindung von verzeichneten Services durchzuführen.

Entsprechend der in der Definition getroffenen Annahmen kann das UDDI auch in privaten Netzwerken eingesetzt werden. Zur Sicherung der Eindeutigkeit eingetragener Services und ihrer Objekte vergibt das UDDI bei dem ersten Eintrag eine eineindeutige Idenfikationsnummer, die UUID.^[54] Eine Alternative für die Sammlung von Services bietet die Web Service Inspection Language, kurz WS-I.^[55] Zur Zeit der Anfertigung dieser Arbeit hat das Standardisierungsgremium OASIS, ein Gremium gebildet durch die Kooperation mehrerer IT-Firmen, eine Version 2.0 des UDDI verabschiedet.^[56] Inwieweit hier Absprachen mit dem W3C erfolgen oder sich konkurrierende Ansätze ergeben ist noch nicht absehbar.

2.4 Übersicht über die innovativen Merkmale von Web-Services

Für die weiteren Ausführungen fasst Abbildung 3 die Eigenschaften von Web-Services in einer Grafik zusammen. Als innovativ erweist sich dabei in erster Linie die Kombination der verschiedenen Merkmale Interoperabilität, Verwendung von XML-Protokollen und Internetstandards, Automatisierbarkeit, loser Kopplung, Kompositionierbarkeit und Firewall-Gängigkeit.^[57]

Abbildung in dieser Leseprobe nicht enthalten

Die Verwendung von XML als Protokollsprache und Internetstandards für den Transport im Netzwerk legen dabei einen wichtigen Grundstein für die dargestellte Merkmalskombination und damit für eine mögliche Verbreitung von Web-Services. Durch die Wahl dieser Protokolle lässt sich Interoperabilität, also die Zusammenarbeit zwischen verteilten und zuvor getrennten Anwendungssystemen, erst erreichen. Die Flexibilitätseigenschaften der XML mit einer weitreichenden Einflussmöglichkeit auf die Granularität kommt der Kompositionierbarkeit zu Gute. Die Abbildung von Werten als Klartext in XML-Tags erlaubt die Wahl zwischen manueller und automatischer Verarbeitung. Eine Anbindung an HTTP ermöglicht eine einfache Firewallgängigkeit.

3 Bewertungskriterien für Web-Services

Im folgenden Kapitel wird ein Kriterienkatalog entwickelt, der eine Bewertung für die Einsatzentscheidung der neuen Informationstechnologie erlaubt. Da Web-Services noch am Anfang ihres Lebenszyklusses stehen und im vierten Kapitel unterschiedliche Anwendungsgebiete untersucht werden, erscheint eine Auswahl von bestimmten Bewertungsverfahren ohne Anwendungsbezug ebenso problematisch wie die Darstellung der Gesamtheit bekannter Methoden.^[58] Grundlage einer Beurteilung bildet i.d.R. der Vergleich einer Realisierung eines konkreten Anwendungsfalls mittels Web-Services mit einem bestehenden System, einer alternativen Lösung oder mit einem Verzicht auf Funktionalität. In all diesen Fällen sollen die hier dargelegten multidimensionalen Kriterien oder eine Auswahl davon in passender Gewichtung verwendet werden können.^[59] Dieses Vorgehen entspricht am ehesten einer Nutzwertanalyse.^[60]

Im ersten Unterabschnitt 3.1 werden zunächst einige technische Kriterien dargestellt. Danach folgen in 3.2 die betriebswirtschaftliche Kriterien, die sich zum Teil aus Ersten ergeben oder auf ihnen aufbauen. Es folgen Anmerkungen zu dem Einfluss der Unsicherheit auf die Kriterien (3.3) und die Tabellen 1 und 2, welche den gefundenen Kriterienkatalog und anzunehmende Interdependenzen nochmals zu einer Übersicht zusammenfassen (3.4).

3.1 Technische Kriterien zur Bewertung von Web-Services

In diesem Kapitel sollen einige Kriterien genannt werden, die aus der technischen Perspektive für eine Bewertung einer Technologie herangezogen werden können. Sie lassen sich in zwei Gruppen einteilen. Die erste sammelt in Abschnitt 3.2.1 Eigenschaften der Technologie bzw. der verwendeten Sprachen mit Entscheidungsrelevanz. In einer zweiten Einordnung finden sich Kriterien, die zur Beurteilung von Anwendungen in verteilten Umgebungen von Bedeutung sind. Beide Gruppen üben letztendlich auch einen Einfluss auf die wirtschaftliche Einschätzung der Technologie aus.

3.1.1 Technische Kriterien anhand von Eigenschaften der Technologie

Bereits auf abstrakter Ebene lassen sich die technischen Eigenschaften verschiedener Implemtierungsoptionen vergleichen. Dieser Abschnitt stellt dafür die Kriterien Interoperabilität, Zugang, Modularisierbarkeit, Kapselung, Wiederverwendbarkeit und Erweiterbarkeit vor.

Bereits in der Definition von Web-Services wurde auf die Bedeutung der Interoperabiltität hingewiesen. Die mit ihr einhergehenden Vorteile lassen sich anhand der bereits vor den Zeiten des Internet entstandenen Netzeffekttheorie erklären, die für die Betrachtung von Web-Services einen wichtigen Beitrag liefert.^[61] Danach erhöht sich als direkter Effekt der Nutzen eines Produktes (hier Web-Services) dadurch, dass auch andere Wirtschaftssubjekte dieses verwenden. Dadurch entstehen so genannte Externalitäten.^[62] Der Nutzen wird durch Einsparungen von Kosten für den Informationsaustausch, eine erweiterte Verwendbarkeit von Funktionen verschiedener Systeme und eine Ausweitung des Kreises potenzieller Partner repräsentiert. Während aus Sicht eines Unternehmens der Nutzen linear zunimmt, steigt der Wert für das gesamte Netz sogar quadratisch.^[63] Durch die Schaffung von Interoperabilität können vormals getrennte Netzwerke verbunden und damit der Gesamtnutzen sprunghaft erhöht werden.

Ein weiterer Aspekt ist der Zugang zur Nutzung von Web-Services. Durch die technisch angelegte Möglichkeit zentraler Dienstverzeichnisse, bspw. durch das besprochene UDDI, besteht ein offener und von jedem Ort möglicher Zugang. Diese Eigenschaft erfüllt in besonderer Weise das Kriterium der Ortstransparenz.^[64] Das als Repository fungierende Dienstverzeichnis sorgt gleichzeitig für eine Transparenz im Hinblick auf bereits entwickelte Services. Dadurch lassen sich Mehrfachentwicklungen ein und derselben Funktion vermeiden.

Lässt sich eine Software in klar abgrenzbare Funktionen mit definierten Schnittstellen aufteilen (Dekomposition), so kann ihr die Eigenschaft der Modularisierbarkeit zugeschrieben werden.^[65] Da Web-Services für eine verteilte Umgebung konzipiert sind, lassen sich Komponenten bilden, die einzelne Anwendungen kapseln.^[66] Diese Kapselung erlaubt eine unkomplizierte Wiederverwendung von Services in anderen Anwendungsumgebungen in Form einer losen Kopplung.^[67] In Verbindung mit der Transparenz wird die Wiederverwendung praktisch erreichbar und es lassen sich positive Wirkungen auf Produktivtät, Qualität und Entwicklungszeit erwarten.^[68] Je spezieller ein einzelner Web-Service ist, desto geringer fällt die Wahrscheinlichkeit einer Wiederverwendung aus
– und damit auch die potenziellen Vorteile.

Die Erweiterbarkeit einer verwendeten Software erlaubt das Hinzufügen neuer Funktionen und damit die Nutzung unter neuen Anforderungen.^[69] Durch die Verwendung der mächtigen XML in Web-Services wird ein hoher Grad dieser Flexibilität erreicht.^[70] Diese Eigenschaft stellt eine Investion dar, die sich im Bereich der sich schnell weiterentwickelnden Webanwendungen auszahlen dürfte und die im Bedarfsfall unmittelbar zu Kostenreduktionen führt.

Auf Grund der weitgehenden Objektivierbarkeit lassen sich verschiedene Technologien anhand der Kriterien dieses Abschnittes weitgehend global vergleichen. Es kann so geprüft werden, inwieweit ein Ansatz einen anderen dominiert. Dies trifft auf die folgenden Kriterien nicht ohne weiteres zu.

3.1.2 Technische Kriterien für verteilte Anwendungen

Für die technischen Kriterien mit Bezug zur Anwendung der Technologie in einem verteilten Umfeld stehen die Items Verfügbarkeit, Skalierbarkeit, Übertragungsgeschwindigkeit, Stabilität und Anwendungskontext, die in diesem Abschnitt vorgestellt werden.

Ein in der Informatik häufig verwendetes Kriterium besteht in der Untersuchung der Verfügbarkeit.^[71] In vielen Anwendungsfällen stellt diese einen Engpass dar, der bereits alleine über die Anwendung einer Infrastruktur entscheiden kann. Dies trifft gerade bei einer automatisierten Funktionseinbindung zur Laufzeit zu. Die Verfügbarkeit entscheidet über das zu Stande kommen einer Verbindung. Sie kann über das Verhältnis des Zeitraumes der tatsächlichen Erreichbarkeit eines Dienstes zum gesamten Betrachtungszeitraum operationalisiert werden.^[72] Analog ist in diesem Kontext der Begriff der Erreichbarkeit zu betrachten. Der einen Service anbietende Server sollte im Idealfall für jede Anfrage an vierundzwanzig Stunden an sieben Tagen in der Woche (24/7) erreichbar sein.^[73] Die Verfügbarkeit ist eine der bedeutenden Eigenschaften im Rahmen von vertraglichen Leistungsvereinbarungen, den so genannten Service Level Agreements.

Für die Gesamtsicht aller auf einen Service zugreifenden Instanzen spielt die Fähigkeit des Anbieters eine Rolle, viele parallele Anfragen ohne nennenswerte Leistungsein-bußen verarbeiten zu können. Diese Fähigkeit wird als Skalierbarkeit eines Services bezeichnet.^[74] Besteht die Skalierbarkeit nicht in ausreichendem Maße, so kann Verfügbarkeit nur zu Lasten der Übertragungsgeschwindigkeit erhalten werden.

Die Übertragungsgeschwindigkeit, die ein Charakteristikum einer konkreten Verbindung ist, lässt sich in eine potenzielle und eine tatsächliche unterscheiden. Unter der potenziellen Übertragungsgeschwindigkeit versteht man die Bandbreite, die das theoretische Maximum der Leistungsfähigkeit eines Übertragungsweges angibt. Die tatsächliche Übertragungsgeschwindigkeit ergibt sich hingegen aus der Verarbeitungskapazität des Anbieters, den Eigenschaften des Netzwerkes und denen des anfragenden Systems. Sie wird in Form der so genannten Übertragungsrate gemessen, die sich aus dem Verhältnis der übertragenen Bits pro Sekunde ergibt.^[75]

Ein weiteres Kriterium ist das der Stabilität. Diese hat ebenfalls die einzelne Verbindung im Blick und prüft die Robustheit. Sie beschreibt ob oder zu welchem Grade eine vorliegende Verbindung fehlerfrei ausgeführt wird. Bei der Datenübertragung im Internet können prinzipiell Daten verloren gehen. Dieses Instabilitätsrisiko kann durch redundante Datenübermittlung verhindert werden, die dann jedoch in einer Reduzierung der Übertragungsrate resultiert. Es besteht somit u.U. ein Trade-Off zwischen Übertragungsrate und Stabilität. Wird wie im Falle von Transaktionen eine Rückmeldung über den fehlerfreien Empfang benötigt oder bestehen Systemanfälligkeiten, wie z.B. in Funknetzen, stellt Stabilität ein wichtiges Kriterium dar. Die Kriterien Stabilität, Verfügbarkeit und Übertragungsrate sind Indikatoren für die Qualität einer Kommunika-tionsverbindung und lassen sich unter dem Begriff Konnektivität zusammenfassen.^[76]

Aus dem spezifischen Anwendungskontext ergibt sich ohne Zweifel eines der bedeutendsten Kriterien für die Chancen von Web-Services, nämlich der Erfüllungsgrad von kontextspezifischen Anforderungen. Bestehen für den Einsatz situative Anforderungen an ein Informationssystem, so ist eine Technologie c.p. umso höher zu bewerten, je besser die Anforderungen erfüllt werden. Im Falle von Web-Services ergeben sich mehrere typische Anforderungsfälle. Diese sind Transaktionsfähigkeit, Fähigkeit zur
Prozessunterstützung, Bereitstellung eines Authentifizierungsmechanismus, Abrechnungsfähigkeit sowie die Verfügbarkeit von Sicherheitsmechanismen.^[77] Die genannten Anforderungen haben ihre Ursache zwar in ökonomischen Notwendigkeiten, erfordern aber ohne Ausnahme eine technische Lösung und wurden daher hier vorgestellt. Zum Anwendungskontext gehört auch die Existenz von technologischen Alternativen.

3.2 Betriebswirtschaftliche Kriterien zur Bewertung
von Web-Services

Für eine Bewertung aus betriebswirtschaftlicher Sicht lassen sich die Kriterien in die zwei Kategorien quantitativer und qualitativer Faktoren unterteilen.^[78] Unter quantitativen Faktoren werden hier Kriterien verstanden, die direkt in Geldeinheiten oder Zahlen ausgedrückt werden. Qualitative Kriterien repräsentieren demgegenüber Wirkungen, die sich in erster Linie an Sachzielen orientieren und als schwer bezifferbar gelten.^[79] Diese Unterscheidung lässt jedoch weder den Schluss zu, dass die Ausprägungen quantitativer Kriterien von vorneherein bekannt seien, noch dass umgekehrt qualitative Merkmale überhaupt nicht messbar wären. Vielmehr entsteht für eine wertmäßige Erfassung bzw. eine Prognose ein entsprechender Aufwand, der sich an der gewünschten Genauigkeit orientiert. Beide Gruppen entfalten letztendlich eine monetäre Wirkung, die sich im Gewinn beziehungsweise Deckungsbeitrag niederschlägt und die daher als entscheidungsrelevant gelten kann.

3.2.1 Quantitative betriebswirtschaftliche Kriterien

Die quantitativen Kriterien bilden entsprechend ihrem Ausdruck in Werten oder Mengen wiederum zwei Untergruppen, die Kategorie der monetär bemessenen Kosten und Erlöse sowie die mengenorientierten Maße Verwendungshäufigkeit und Anzahl der externen Marktteilnehmer.

Die Übersicht zu den Bewertungskriterien beginnt mit einer Betrachtung der Kostenkomponenten. Die durch Netzdienste entstehenden Kostenwirkungen können sowohl positiv als auch negativ ausfallen.^[80] Zur Bildung einer Aufstellung der Web-Service-Kosten wird hier die folgende Systematisierung vorgeschlagen.^[81] Danach lassen sich für eine Analyse von Web-Services drei Dimensionen abgrenzen, die getrennt zu betrachten sind:

1. Kosten der Technologie
2. Kosten der mit Hilfe der Technologie ausgeführten Prozesse
3. Kosten für die über die Prozesse ausgetauschten Güter oder Leistungen

Die erste Kostendimension ergibt sich aus den Aufwendungen für Einrichtung und Betrieb der Technologie selbst.^[82] Vor der Nutzung von Web-Services steht die Implementierung einer Anwendung. Diese verursacht Anschaffungskosten, die wiederum in Beschaffungskosten beim Kauf oder Herstellungskosten bei Selbsterstellung einer Web-Service-Applikation unterschieden werden können. Diesen sind auch anfallende Kosten der Softwareanpassung (Customizing) zuzurechnen. In den darauf folgenden Nutzungsperioden entstehen Betriebskosten, die sich z.B. in der Wartung von Serverarchitekturen niederschlagen. Die zweite Kategorie umfasst Prozesskosten, die sich durch den Einsatz einer neuen Technologie verändern, wie Such-, Verhandlungs- und Abwicklungskosten. Buchhalterisch schlagen sich diese zumeist über die Arbeitszeit im Personalaufwand nieder.^[83] Gerade die Kommunikation von Anwendung-zu-Anwendung lässt in diesem Segment Auswirkungen erwarten, die aus der (industriellen) Automatisierung in der Vergangenheit bereits bekannt sind: die Substitution von menschlicher Arbeit durch maschinelle Verfahren.

Im Hinblick auf die bisher eingeführten Kostenkomponenten ist das von Buxman 1996 vorgestellte Standardisierungsproblem (SP) für die weitere Analyse von Bedeutung.^[84] Anhand eines Modells gerichteter Graphen werden alle Kommunikationspartner als Knoten abgebildet, die je nach Granularität Unternehmen, Abteilungen oder einzelne Anwendungen repräsentieren.^[85] Anschließend werden diesen die als bekannt angenommenen Anschaffungskosten für den Standard sowie die zu den ebenfalls standardisierenden Knoten einzusparenden Kommunikationskosten zugeordnet, um so eine Standardisierungsentscheidung zu erleichtern. Für die Analyse von Web-Services in einzelnen Wertschöpfungsprozessen wird die in diesem Modell untersuchte Koordination der Standardisierungsentscheidung von Interesse sein.^[86] Kann bei einem Einsatz in einer Firma die Entscheidung über die Standardisierung für alle Knoten kontrolliert werden (zentrales SP), so herrscht bei einem Einsatz an der Schnittstelle zu Marktteilnehmern Unsicherheit über die Adoption (dezentrales SP) vor.^[87] Damit bleiben die Einsparungen unklar und die Standardisierungsentscheidung erfolgt unter erhöhtem Risiko.

Der noch zu erläuternde dritte Kostenblock resultiert aus Veränderungen von Kosten für die den Geschäftsprozessen zu Grunde liegenden Objekte, z.B. eingekaufte Vorleis-tungen. Eine Kommunikation zwischen Unternehmen und externen Partnern findet meist mit dem Ziel statt, eine Transaktion durchzuführen. Das für Web-Services verwendete Dienstverzeichnis könnte eine erhöhte Transparenz im Hinblick auf Preise und Anbieter bestimmter Waren oder Dienstleistungen zur Folge haben, so dass sich eine verbesserte Ressourcenallokation ergäbe.^[88] Solche Effekte werden auch unter den Begriff der Informationswerterhöhung behandelt.^[89]

Den Gegenpol zu den Kosten bilden die Erlöse eines Unternehmens. Für Erlöse zeichnen sich die zwei Komponenten „Erlöse durch Prozessverbesserungen“ und „Erlöse durch neue Leistungen“ ab. Besser gestaltete Prozesse an der Schnittstelle zum Kunden können steigende Erlöse erbringen. Gründe dafür können eine verbesserte Erreichbarkeit, Einfachheit der Dienstnutzung, größer werdende Kundenzahlen oder auch eine erhöhte Geschwindigkeit sein. Als neue Leistungen können neue Produkte bzw. neue Funktionalitäten gelten, die durch die Kombinierbarkeit von Diensten entstehen.

[...]

---

^[1] Vgl. Horváth, P./Rieg, R. 2001, S. 10 f.; Heinrich, L./Pomberger, G. 2001, S. 19; . Picot, A./Reichwald, R./Wigand, R. 2001, S. 286; Buxmann, P. 2001, S. 109 – 111

^[2] Vgl. Kempis, R.-D. u.a. 1998, S. 14 – 24, S. 43 – 45 und S. 219 f.; Horváth, P./Rieg, R. 2001, S. 10 f.

^[3] Vgl. Kuschke, M./Wölfel, L. 2002, S. 3

^[4] Snell, J./Tidwell, D./Kulchenko, P. 2002, S. 1

^[5] Vgl. Gottschalk, K. u.a. 2002, S. 171; Snell, J./Tidwell, D./Kulchenko, P. 2002, S. 1

^[6] Vgl. zum internen Einsatz etwa Herwig, V. 2002, S. 18

^[7] Vgl. Tanenbaum, A. 2002, S. 2 – 4; Iyer, A. u.a. o.J., o.S.; Wedekind, H. 1988, S. 264 – 269

^[8] Vgl. Cerami, E. 2002, S. 3; Booth, D. u.a. [W3C Working Draft] 2003, Abschnitt: 1.6.1, o.S.

^[9] Vgl. Cerami, E. 2002, S. 3

^[10] Vgl. Booth, D. u.a. [W3C Working Draft] 2003, Abschnitt: 1.5 und 1.7, o. S.

^[11] Sofern eine Web-Services Schnittstelle implementiert ist

^[12] Vgl. etwa Kuschke, M./Wölfel L. 2002, S. 3; Snell, J./Tidwell, D./Kulchenko, P. 2002, S. 4

^[13] Vgl. Hars, A./Schlüter-Langdon, C. 2002, S. 13

^[14] Vgl. Manes, A. 2003, S. 12; EITO/EEIG 2003, S. 164; für einen Vergleich ausgewählter Middleware siehe Abbildung A.1 in Anhang A

^[15] Vgl. Mougin, P./Barriolade, C. 2001, S. 13 – 31; Farell, J./Kreger, H. 2002, S. 217

^[16] Vgl. König, W. u.a. 2003, S. 348 – 350; siehe auch Hagel III, J. 2002, S. 32

^[17] Vgl. Weitzel, T./Harder, T./Buxmann, P. 2001, S. 11 f.

^[18] Vgl. Weiß, G. 2001, o. S.; Ollmert, C./Schinzer, H. 2001, S. 93 – 98; König, W. u.a. 2003, S. 345 f.; Graham, S. u.a. 2002, S. 530 f.

^[19] Vgl. Booth, D. u.a. [W3C Working Draft] 2003, Abschnitt: 1.5.1 und 2.3.1.2.2 f., o.S.

^[20] Siehe für eine vergleichende Darstellung der Eigenschaften auch Abb. A.2 in Anhang A

^[21] Vgl. Wright, R. 2002, S. 88; siehe für weitere Abgrenzungen etwa zu Grid Computing z.B. Graham, S. u.a. 2002, S. 533 f.; oder zum Peer-to-Peer-Konzept Hurley, O. 2001, S. 14

^[22] Vgl. Rawolle, J./Burghardt, M. 2002, S. 40

^[23] Vgl. Champion, M. u.a. [W3C Working Draft] 2002, Abschnitt: 3.1, o. S.; Hars, A./Schlüter-Langdon, C. 2002, S. 14; Yang, J./Papazoglou, M. 2002, S. 21 – 36; Peer, J. 2002, S. 281

^[24] Vgl. Cowles, P. 2002, S. 29; Fensel, D./Bussler, C./Maedche, A. 2002, S. 2

^[25] Vgl. zur SOA Ferris, C./Farrell, J. 2003, S. 31; Gottschalk, K. u.a. 2002, S. 170; Leymann, F./Roller, D./Schmidt, M.-T. 2002, S. 199; zum nicht-monolithischen Aufbau siehe Bettag, U. 2001, S. 303;
Herweg, V. 2002, S. 17

^[26] Vgl. Kuschke, M./Wölfel L. 2002, S. 4

^[27] Vgl. zur Akzeptanz Lebender, M. 2003, S. 28

^[28] Vgl. Myerson, J. o.J., S. 3 – 11

^[29] Vgl. Champion, M. u.a. [W3C Working Draft] 2002, Abschnitt: 3.3.1 – 3.3.4, o. S.

^[30] Vgl. Cerami, E. 2002, S. 19

^[31] Vgl. Cerami, E. 2002, S. 19

^[32] Vgl. Rebstock, M./Lipp, M. 2003, S. 295; Booth, D. u.a. [W3C Working Draft] 2003, Abschnitt: 1.7, o.S.; Rawolle, J./Burghardt, M. 2002, S. 41; Cerami, E. 2002, S. 20

^[33] Vgl. Knuth, M. 2002, S. 76

^[34] Vgl. Murphy, C. 2002, S. 44

^[35] Vgl. Mitra, N. [W3C Recommendation] 2003, o.S.

^[36] Vgl. Janakinaman, M. 2002, S. 32 f.

^[37] Vgl. auch im Folgenden Snell, J./Tidwell, D./Kulchenko, P. 2002, S. 11 – 36

^[38] Vgl. Janakinaman, M. 2002, S. 32 f.; Booth, D. u.a. [W3C Working Draft] 2003, Abschnitt 3.15.2, o. S.

^[39] Vgl. zu XML Hepp, M./Thome, R. 2003, S. 510 – 518; s. ausführlich Graham, S. u.a. 2002, S. 33 – 87

^[40] Vgl. zu den beiden Verfahren Chappell, D. 2003, S. 58; Venkatapathy, C./Melgar, D. 2003, S. 48; Zimmermann, O./Tomlinson, M./Peuser, S. 2003, S. 98 – 103; Graham, S. u.a. 2003, S. 171 – 173

^[41] Vgl. Snell, J./Tidwell, D./Kulchenko, P. 2002, S. 12; Gottschalk, K. u.a. 2002, S. 17

^[42] Vgl. Rawolle, J./Burghardt, M. 2002, S. 41; Peer, J. 2002, S. 281

^[43] Vgl. Janakinaman, M. 2002, S. 32

^[44] Vgl. im Folgenden Cerami, E. 2002, S. 14; Beimborn, D./Mintert, S./Weitzel, T. 2002, S. 277

^[45] Vgl. Lebender, M. 2003, S. 29; Herwig, V. 2002, S. 16 f.

^[46] Vgl. Peer, J. 2002, S. 280

^[47] Vgl. Kuschke, M./Wölfel L. 2002, S.4; vgl. auch Janakiraman, M. 2002, S. 32; vgl. auch Lim, B./ Wen, J. 2003, S. 52 f.; vgl. Lebender, M. 2003, S. 29 f.; Peer, J. 2002, S. 280; Cerami, E. 2002, S. 119 – 127

^[48] Vgl. auch im Folgenden Janakinaman, M. 2002, S.32

^[49] Vgl. Graham, S. u.a. 2002, S. 358

^[50] Vgl. Snell, J./Tidwell, D./Kulchenko, P. 2002, S. 8; Cowles, P. 2002, S. 29 f.

^[51] Vgl. Snell, J./Tidwell, D./Kulchenko, P. 2002, S. 7

^[52] Vgl. Ankolekar, A./Huch, F./Sycara, K. 2002, S. 318

^[53] Vgl. auch im Folgenden Lim, B./Wen, J. 2003, S. 52; Lebender, M. 2003, S. 31

^[54] Vgl. Snell, J./Tidwell, D./Kulchenko, P. 2002, S. 98

^[55] Vgl. Snell, J./Tidwell, D./Kulchenko, P. 2002, S. 96

^[56] Vgl. o.V. [Fortschritte] 2003b, S. 9

^[57] Vgl. Knuth, M. 2002, S. 12; Farrell, J./Kreger, H. 2002, S. 217

^[58] Vgl. für eine Übersicht zu Bewertungsmodellen z.B. Nagel, K. 1990, S. 39 – 58; oder Pietsch, T. 1999, S. 58 – 138; vgl. zum Lebenszyklus bspw. Minz, R./Datel, A./Wenzky, H. 2002, S. 6, 10; Rawolle, J./Burghardt, M. 2002, S. 44

^[59] Vgl. Österle, H./Fleisch, E./Alt, R. 2000, S. 52 – 54; Priemer, J. 1995, S. 58 – 66

^[60] Vgl. Baumgartner, C./Kueng, P. 1999, S. 33 – 37; Scheckenbach, R. 1997, S. 42, Heinrich, L. 2002,
S. 425 – 436; Pietsch, T. 1999, S. 70 – 76

^[61] Vgl. Minz, R./Datel, A./Wenzky, H. 2002, S. 7; Vgl. Katz, M./Shapiro, C. 1994, S. 424; siehe für eine
Übersicht zu den Kernaussagen der Netzeffekttheorie Anhang B Abbildung B.1

^[62] Vgl. auch im Folgenden Choi, S.-Y./Stahl, D./Whinston, A. 1997, S. 66 – 69; sowie Katz, M./Shapiro, C. 1985, S. 424 f.; und auch Buxmann, P./Weitzel, T./König, W. 1999, S. 134 f.

^[63] Vgl. auch im Folgenden Hanson, W. 2000, S. 63 – 66

^[64] Vgl. Bettag, U. 2001, S. 302; Zimmermann, O./Tomlinson, M./Peuser, S. 2003, S. 7

^[65] Vgl. Balzert, H. 1998, S. 571 – 574; Bettag, U. 2001, S. 302

^[66] Vgl. Bettag, U. 2001, S. 302; vgl. auch Leymann, F./Roller, D./Schmidt, M.-T. 2002, S. 199; Hars, A./Schlüter-Langdon, C. 2002 S. 16

^[67] Vgl. Horváth, P./Rieg, R. 2001, S. 13; Rawolle, J./ Burghardt, M. 2002, S. 45

^[68] Vgl. Balzert, H. 1998, S. 637 – 643; Hars, A./Schlüter-Langdon, C. 2002 S. 16

^[69] Vgl. Priemer, J. 1995, S. 44; Minz, R./Datel, A./Wenzky, H. 2002, S. 10

^[70] Vgl. Weitzel, T./Harder, T./Buxmann, P. 2001, S. 20 f.

^[71] Vgl. auch im Folgenden Wedekind, H. 1988, S. 263

^[72] Vgl. Schamburger, R. 2001, S. 18 – 20

^[73] Sofern keine andere Spezifikation in der Servicebeschreibung hinterlegt ist.

^[74] Vgl. anschaulich zur Skalierbarkeit Davidson, N. 2002, S. 54 f.

^[75] Vgl. Schröter, U. 1997, S. 126 f.; zur Erläuterung von Bits siehe Mertens u.a.1998, S. 11

^[76] Vgl. Schamburger, R. 2001, S. 18 – 20

^[77] Vgl. Hars, A./Schlüter-Langdon, C. 2002 S. 15; siehe dazu auch Abschnitte 4.6

^[78] Für eine Übersicht zu weiteren Möglichkeiten der Kategorisierung von Kriterien bei Wirtschaftlichkeitsbetrachtungen siehe z.B. Scheckenbach, R. 1997, S. 39 f.; Buxmann, P. 2001, S. 26 – 30

^[79] Vgl. Heinrich, L. 2002, S. 416 f.; Scheckenbach, R. 1997, S. 35 – 39

^[80] Auf eine begriffliche Unterscheidung von Aufwand, Kosten und Ausgaben wird hier verzichtet.

^[81] Vgl. allerdings zu einzelnen Kostenarten bei Wirtschaftlichkeitsanalysen von IuK-Systemen
Buxmann, P. 2001, S. 26 – 29

^[82] Vgl. Pietsch, T. 1999, S. 42 f.; Samtani, G./Sadhwani, D. 2002c, o.S.

^[83] Vgl. Picot, A. 1982, S. 270

^[84] Vgl. auch im Folgenden Buxmann, P. 1996, S. 26 – 39

^[85] Vgl. zur Graphentheorie Domschke, W./Drexl, A. 2002, S. 59 – 65

^[86] Vgl. auch im Folgenden Buxmann, P./Weitzel, T./König, W. 1999, S. 138 f. und S. 147

^[87] Eine verbindliche, vertragliche Absprache aller Marktteilnehmer würde der Bedingung einer zentralen
Entscheidung gleichkommen. Siehe für eine Darstellung des Standardisierungsmodells Anhang B.2

^[88] Vgl. Brenner, W./Wilking, G./Zarnekow, R. 1999, S. 13

^[89] Vgl. Buxmann, P. 2001, S. 36