Studienarbeit Abgabe

Studienarbeit
Dienstattribute für serviceorientierte
Workflows
Daniel Harms
Juli 2007
Betreuer: Prof. Dr. Paul Müller
Dipl. Wirtsch. Ing. Jochen Müller
Fachbereich Informatik
AG Integrierte Kommunikationssysteme
Universität Kaiserslautern  Postfach 3049  67653 Kaiserslautern
Ich versichere, dass ich die vorliegende Projektarbeit/Studienarbeit selbstständig verfasst und keine
anderen als die angegebenen Quellen und Hilfsmittel verwendet habe.
Kaiserslautern, <Datum>
(Daniel Harms)
Abstract
In der vorliegenden Arbeit wird die Verknüpfung der Workflowtechnologie
mit dem Konzept der serviceorientierten Architekturen untersucht. Dazu
werden Informationen zur möglichst umfassenden Beschreibung von
Services identifiziert, um die Integration in Workflow-Management-Systeme
und somit Geschäftsprozesse zu vereinfachen. Eine Komponente zur
Speicherung und Darstellung dieser Informationen wird konzipiert. Anhand
einer Fallstudie wird die Funktionsweise der entwickelten Konzepte
demonstriert.
Inhaltsverzeichnis
7
1.
EINLEITUNG ..................................................................................................... 9
2.
GRUNDLAGEN ............................................................................................... 11
2.1
Workflow-Management ........................................................................................................................... 11
2.2
Serviceorientierte Architekturen .............................................................................................................. 16
2.3
Verwandte Konzepte ................................................................................................................................ 23
2.4
Verwandte Projekte .................................................................................................................................. 25
2.5
Abgrenzung zu verwandten Arbeiten ....................................................................................................... 27
2.6
Exkurs: Wettbewerbsstrategien ................................................................................................................ 28
3.
MODELLBILDUNG ......................................................................................... 31
3.1
Serviceorientierter Workflow ................................................................................................................... 31
3.2
Wettbewerbsinformationen ...................................................................................................................... 32
3.3
Prozesse der Service Provider .................................................................................................................. 32
3.4
Funktionale und nicht-funktionale Eigenschaften .................................................................................... 34
3.5
Service-Schema ........................................................................................................................................ 35
4.
REALISIERUNG & FALLSTUDIE................................................................... 37
4.1
Realisierung Service-Schema ................................................................................................................... 37
4.2
Realisierung Infrastruktur ......................................................................................................................... 40
4.3
Fallstudie Flächennutzungsplanung ......................................................................................................... 45
5.
ZUSAMMENFASSUNG .................................................................................. 50
8
Inhaltsverzeichnis
LITERATURVERZEICHNIS ..................................................................................... 51
ABBILDUNGSVERZEICHNIS .................................................................................. 55
TABELLENVERZEICHNIS ....................................................................................... 56
Einleitung
9
1. Einleitung
Die effektive Ausführung und Unterstützung von Geschäftsprozessen ist für jede Organisation die
Grundvoraussetzung des Erfolgs. Die automatisierte Ausführung von Geschäftsprozessen ist durch
Workflow-Management-Systeme bereits in großem Umfang Realität geworden.
Serviceorientierte Architekturen bieten weitergehende Möglichkeiten der Realisierung von
Geschäftsprozessen mithilfe von Funktionalitäten, die als Services zur Verfügung gestellt werden. Die
Nutzer integrieren die Services flexibel in ihre eigenen Geschäftsprozesse und rufen sie dann auf,
wenn sie diese benötigen. Die Funktionalität der Services steht auf Abruf bereit. Genauso schnell wie
ein Geschäftsprozess entstanden ist kann er wieder aufgelöst werden oder können einzelne Services
durch andere ersetzt werden.
Eine Verknüpfung der Workflow-Technologie mit serviceorientierten Architekturen kann weitere
Potenziale erschließen. Die Vorteile von zentral gesteuerten Workflows und dezentral verfügbaren
Services können in einem System vereint werden, das einerseits die Kontrolle über die eigenen
Geschäftsprozesse behält und gleichzeitig die vollständige Bandbreite der verfügbaren Services in
diese integrieren kann. So kann die Ausführung von Geschäftsprozessen noch flexibler und effektiver
gestaltet werden.
Doch wie erreichen Organisationen eine optimale Integration von Services in ihre Workflows? Für
eine gesuchte Funktionalität können viele Services zur Verfügung stehen. Verzeichnisdienste listen
existierende Services auf, beschränken sich in ihrem Informationsgehalt jedoch auf technische
Merkmale wie Schnittstellen und Aufrufmodalitäten. Was hinter dem Service steckt, welche weiteren
Möglichkeiten, die für den Nutzer von Interesse sein können, der Service Anbieter zur Verfügung
stellt, diese Informationen bleiben bisher verborgen. Trotz gleicher technischer Merkmale können sich
die Rahmenbedingungen von zwei Services voneinander unterscheiden. Der eine arbeitet schneller
und zuverlässiger, aber möglicherweise auch zu höheren Kosten und nur für bestimmte Nutzer. Diese
Informationen sind nicht in existierenden Verzeichnisdiensten zu finden.
Die vorliegende Arbeit beschäftigt sich mit der Veröffentlichung dieser Merkmale von Services für
alle Servicenutzer. Da die Services die gleiche Funktionalität anbieten, wird hier vom horizontalen
Design von Workflows gesprochen, d.h. für einen Schritt im Workflow wird betrachtet, mit welchen
Services dieser möglichst sinnvoll realisiert werden kann. Die folgende Abbildung stellt diesen
Sachverhalt dar. Die zusätzlich veröffentlichten Merkmale sollen zum einen den Servicenutzern eine
verbesserte Entscheidungsgrundlage zur Verfügung stellen und zum anderen den Serviceanbietern
ermöglichen, sich von Wettbewerbern zu differenzieren. Diese Möglichkeiten sollen in einer neuen
10
Einleitung
serviceorientierten Architektur realisiert werden.
A
Schritt 1
Service 1
Schritt 2
Service 2
Service 3
Schritt 3
B
Workflow
Web Services
Abbildung 1: Horizontales Design
Die vorliegende Arbeit gliedert sich neben der Einleitung in vier Teile. Im zweiten Kapitel
(Grundlagen) werden die für den Rest der Arbeit benötigten Technologien und Konzepte erläutert. Im
dritten Kapitel (Modellbildung) wird ein Schema für die möglichst umfassende Beschreibung von
Services entwickelt. Im vierten Kapitel werden schließlich Realisierungsmöglichkeiten des
Informationsschemas betrachtet und die Anwendbarkeit anhand einer Fallstudie verifiziert. Die Arbeit
schließt mit einer Zusammenfassung.
Grundlagen
11
2. Grundlagen
In
diesem
Kapitel
werden
zunächst
die
Grundlagen
von
Workflow-Management
und
serviceorientierten Architekturen erläutert. Im Anschluss werden verwandte Konzepte und Projekte
vorgestellt und die vorliegende Arbeit von diesen abgegrenzt. Am Ende des Kapitels wird in einem
Exkurs kurz auf Wettbewerbsstrategien eingegangen.
2.1 Workflow-Management
Workflow-Management ist nach [Jab97, S.5] bereits seit geraumer Zeit „eines der meist diskutierten
Themen
im
Softwarebereich“.
Die
Optimierung
und
das
effektive
Management
von
Geschäftsprozessen wird mit zunehmendem Konkurrenzdruck für die Unternehmen immer wichtiger.
Workflow-Management-Systeme
bieten
die
Möglichkeit
Geschäftsprozessmanagement
zu
automatisieren. Ihre Aufgabe sieht [AalHee02, S. XV] im Übermitteln der richtigen Information zur
richtigen Zeit an die richtige Person bzw. die richtige Anwendung.
Vielfältige Workflow-Management-Produkte mit unterschiedlichen Funktionen sind auf dem
Software-Markt erhältlich. Trotz vieler Gemeinsamkeiten führte die fehlende Standardisierung jedoch
zu einer großen Zahl von Insel-Lösungen für einzelne Branchen und Unternehmen. Um diesem Trend
zu begegnen wurde die Workflow Management Coalition (WfMC) gegründet. Sie beschäftigt sich mit
der Entwicklung gemeinsamer Standards für Funktionen, die alle Workflow-Management-Systeme
anbieten. Nach [Hol95, S. 3] sollen diese Standards die Kompatibilität bestehender Produkte sowie die
Integrationsmöglichkeiten mit anderen IT-Services, wie z.B. E-Mail oder Dokumentenmanagement, in
Zukunft verbessern.
Die folgende Erläuterung der Workflowtechnologie basiert auf zwei Dokumenten der WfMC. In
[Hol99] werden Definitionen für grundlegende Begriffe der Workflowterminologie zur Verfügung
gestellt. Die Analyse von Workflow-Management-Systemen, des Workflow Reference Models und
des damit verbundenen Vokabulars stützt sich auf [Hol95].
2.1.1 Definitionen
Definition Geschäftsprozess
“A set of one or more linked procedures or activities which collectively realise a business
objective or policy goal (…)” [Hol99, S. 10]
12
Grundlagen
Definition Workflow
“The
automation of a business process, in whole or part, during which documents,
information or tasks are passed from one participant to another for action, according to a set
of procedural rules.” [Hol99, S. 8]
Definition Workflow-Management-System
“A system that completely defines, manages and executes workflows through the execution of
software whose order of execution is driven by a computer representation of the workflow
logic.” [Hol95, S. 6]
Die
folgende
Abbildung
stellt
beispielhaft
ein
Workflow-Management-System
dar.
Der
Geschäftsprozess (Business Process) wird in Teilschritte bzw. Aktivitäten (Steps) zerlegt. Zur
Ausführung der Teilschritte interagiert das System mit einem Mitarbeiter (User Interface & Local
Desktop Applications), einer Applikation (Applications) oder einer Datenbank (Databases). Das
Workflow-Management-System
bestimmt,
welche
Aktivität
von
wem
bearbeitet
wird
(Process/Activity Management & Distribution Function).
Abbildung 2: Workflow-Management-System [WfMC95, S. 9]
2.1.2
Allgemeine Struktur von Workflow-Systemen
Nach [Hol95] weisen die auf dem Markt erhältlichen Workflow-Management-Produkte viele
gemeinsame Charakteristika auf. Darauf aufbauend, hat das WfMC eine allgemeine Struktur von
Workflow-Management-Systemen entworfen. Das in der folgenden Abbildung dargestellte Modell
identifiziert die in allen Workflow-Management-Systemen enthaltenen Komponenten sowie die
externen Komponenten mit denen es interagiert. Es verfügt über drei Typen von Komponenten:
Grundlagen
13
1. Softwarekomponenten, die verschiedene Aufgaben innerhalb des Workflow-ManagementSystems übernehmen (Kästchen mit dunklem Hintergrund).
2. Systemdefinitions- und Kontrolldaten, die von einer oder mehreren Softwarekomponenten
genutzt werden (Kästchen mit weißem Hintergrund).
3. Applikationen und Datenbanken, die nicht Teil des Workflow-Management-Systems sind, von
diesem jedoch aufgerufen werden können (Kästchen mit grauem Hintergrund).
Abbildung 3: Allgemeine Struktur eines Workflow-Management-Systems [nach WfMC95, S. 13]
Das Definition Tool wird verwendet, um den Geschäftsprozess aus der realen Welt in eine für den
Computer lesbare Form zu bringen, die Prozess-Definition. Sie wird mithilfe einer formalen
Modellierungssprache, wie z.B. Petri-Netzen, modelliert. Dabei kann sie auf Strukturen und Rollen
beschreibende Organisation/Role Model Data und auf zu verwendende externe Applikationen
verweisen.
Der Workflow Enactment Service bildet das Herzstück des Workflow-Management-Systems. Dieser
stellt den Prozess-Instanzen eine Laufzeitumgebung in Form einer oder mehrerer Workflow-Engines
zur Verfügung. Die Workflow Engine übernimmt die Zuteilung der einzelnen Aktivitäten an
14
Grundlagen
verfügbare Ressourcen und startet bei Bedarf externe Anwendungen. Mithilfe der Workflow Control
Data sorgt sie auch dafür, dass die Prozessschritte in der richtigen Reihenfolge bearbeitet werden.
Sind während der Ausführung eines Prozesses Navigationsentscheidungen für den weiteren Verlauf zu
treffen, so werden ggf. Daten benötigt, die von externen Applikationen generiert oder modifiziert
wurden. Diese Daten sind im Modell als Workflow Relevant Data gekennzeichnet. Sie können
ausschließlich von den externen Applikationen geändert werden. Der Workflow Enactment Service
hat auf keinerlei Applikationsdaten außerhalb dieses Blocks Zugriff. Er kann lediglich für den
Transfer der Daten von einer Applikation zu einer anderen sorgen.
Ist eine Interaktion mit einem Benutzer des Workflowsystems notwendig, so legt die WorkflowEngine die zu erledigenden Aufgaben in der Work List ab. Auf diese greift der Worklist Handler zu.
Die Funktionalitäten dieser Komponente können in ihrem Umfang variieren. In einigen Systemen
stellt sie dem Benutzer lediglich einen Eingangskorb mit den zu erledigenden Aufgaben zur
Verfügung. Sie kann aber auch komplexere Funktionalitäten wie etwa die Verteilung der Aufgaben
nach Auslastungskriterien anbieten. Auch eine Log-in/Log-off Einrichtung für Benutzer ist möglich.
Das User Interface zeigt dem Benutzer letztlich die Inhalte der Work List auf seinem Bildschirm an.
Ihre Funktionalität umfasst im Allgemeinen das Anzeigen sämtlicher zu erledigender Aufgaben,
inklusive zugehöriger Informationen wie z.B. Namen, Prioritäten, Eingangszeiten etc. Nach [Jab97, S.
222] müssen zudem Funktionen zum Annehmen, Starten, Ändern, Einfügen neuer Aufgaben zur
Laufzeit, Beenden, Abbrechen oder Weiterleiten von Workflow-Instanzen angeboten werden.
Die Arbeitsliste muss nicht unbedingt wie im vorliegenden Modell strukturiert sein. In einigen
Workflow-Management-Systemen kann es vorkommen, dass die Komponenten Worklist Handler und
User-Interface vereint werden.
Externe Applikationen können nicht nur von der Workflow Enactment Software, sondern auch von der
Benutzeroberfläche bzw. vom Worklist Handler aus gestartet werden, wenn der Benutzer diese zur
Erledigung der Aufgaben benötigt.
Um zur Laufzeit Modifikationen an der Workflow Engine und Systemdaten vornehmen zu können, ist
eine
Administratorschnittstelle
erforderlich
(Supervisor,
Administration
&
Control).
Der
Administrator verwaltet die Benutzer sowie die Konfiguration des Workflow-Management-Systems
und steuert bzw. überwacht den Betrieb. Er kann Rollen und Regeln modifizieren, sich Statistiken
über die Prozess-Instanzen (z.B. abgelaufene Fristen) anzeigen lassen und Fehler oder Ausnahmen im
System beheben, z.B. durch Anhalten, Abbrechen oder Stornieren von Workflow-Instanzen [nach
Jab97, S. 223].
Grundlagen
15
2.1.3 Granularität von Workflows
Ein Workflow kann mithilfe einer Top-Down-Methodik in mehreren Stufen zerlegt werden. Eine
Möglichkeit ist die Unterscheidung von vier Ebenen: Workflows, Teilprozesse (Tasks), Aktivitäten
und Ressourcen [in Anlehnung an BecMüh99]. Die folgende Abbildung veranschaulicht diese vier
Ebenen.
Workflow
Teilprozess (Task)
Aktivität
Ressource
Ressource
Teilprozess (Task)
Aktivität
Ressource
Ressource
Aktivität
Ressource
Ressource
Aktivität
Ressource
Ressource
Abbildung 4: Workflow-Granularität
Der Workflow stellt den gesamten Geschäftsprozess dar. Ein Workflow enthält mehrere Rollen,
verfolgt verschiedene Ziele und verwendet mehrere Ressourcen. Der Workflow lässt sich unterteilen
in mehrere Teilprozesse (Tasks), die innerhalb einer bestimmten Zeitspanne abgearbeitet werden
müssen. Diese werden von nur einer Rolle bearbeitet, können jedoch weiterhin mehrere Ziele
verfolgen und mehrere Ressourcen verwenden. Ein Teilprozess lässt sich weiter unterteilen in
Aktivitäten. Eine Aktivität stellt einen Schritt in einem Teilprozess dar. Die Aktivität wird von einer
Rolle durchgeführt, verfolgt ein Ziel, kann jedoch weiterhin mehrere Ressourcen verwenden. Auf der
letzten Stufe lassen sich die Ressourcen identifizieren, die von einer Aktivität genutzt werden. Eine
Ressource ist eine Einheit, die zur Laufzeit angefordert wird, um die Arbeit einer Aktivität zu
verrichten.
16
Grundlagen
2.2 Serviceorientierte Architekturen
In diesem Abschnitt werden zunächst der Begriff der serviceorientierten Architektur sowie deren
wesentliche Charakteristika erläutert. Im Anschluss werden Web Services als eine weit verbreitete
Möglichkeit der Realisierung von serviceorientierten Architekturen vorgestellt.
2.2.1
Was ist eine Serviceorientierte Architektur?
Definition Serviceorientierte Architektur (SOA)
“Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed
capabilities that may be under the control of different ownership domains.” [Mac06]
Die Anbieter dieser Fähigkeiten (capabilites) werden in der vorliegenden Arbeit Service Provider
genannt. Die Akteure, die eine solche Fähigkeit benötigen, werden als Service Consumer angeführt.
Die Bedürfnisse eines Service Consumers können hochkomplex sein, d.h. die Befriedigung kann
mehrere Fähigkeiten von verschiedenen Service Providern erfordern. Serviceorientierte Architekturen
stellen
eine
leistungsfähige
Umgebung
dar,
um
diese
Bedürfnisse
und
Fähigkeiten
zusammenzubringen und um Fähigkeiten zur Lösung von Problemen zu kombinieren.
Das wesentliche Element einer serviceorientierten Architektur ist der Service. Das SOA Reference
Model [Mac06] definiert den Begriff des Services und einige damit zusammenhängende Elemente wie
folgt.
Definition Service
“A service is a mechanism to enable access to one or more capabilities, where the access is
provided using a prescribed interface and is exercised consistent with constraints and policies
as specified by the service description. A service is provided by an entity – the service
provider – for use by others, but the eventual consumers of the service may not be known to
the service provider and may demonstrate uses of the service beyond the scope originally
conceived by the provider.” [Mac06]
Definition Service Description
“The service description represents the information needed in order to use a service. (…) The
purpose of the description is to facilitate interaction and visibility, particularly when the
participants are in different ownership domains, between participants in service interactions.
By providing descriptions, it makes it possible for potential participants to construct systems
that use services and even offer compatible services.” [Mac06]
Die folgenden Informationen sollten nach [Mac06] in der Service Description enthalten sein:
1. Der Service existiert und ist erreichbar.
2. Informationen über die vom Service erbrachte(n) Funktion(en).
Grundlagen
17
3. Informationen über die Beschränkungen und Vorschriften unter denen der Service
operiert.
4. Eine Beschreibung der Interaktion mit dem Service, d.h. Formate, Inhalte und
Reihenfolge von Nachrichten.
Definition Service Interface
“The service interface is the means for interacting with a service. It includes the specific
protocols, commands, and information exchange by which actions are initiated that result in
the real world effects as specified through the service functionality portion of the service
description. The specifics of the interface should be syntactically represented in a standard
referenceable format.” [Mac06]
Um die Interaktion von Service Provider und Service Consumer zu ermöglichen, müssen diese jeweils
von der Existenz des anderen erfahren. Dabei helfen verschiedene Discovery-Mechanismen. Diese
ermöglichen es dem Service Provider seine Service Description, das Service Interface und eventuelle
weitere Informationen zu veröffentlichen und dem Service Consumer diese zu finden.
Neben Service Provider und Consumer gibt es in serviceorientierten Architekturen noch eine weitere
Rolle. Die Service Registry ist ein Verzeichnis in dem die Service Provider ihre Service Description(s)
veröffentlichen. Ein Service Consumer kann verfügbare Services in der Service Registry finden,
indem er eine entsprechende Suchanfrage stellt. Mithilfe der Service Description und des Service
Interfaces kann der Service Consumer den Service nun direkt beim Service Provider aufrufen. Die
Interaktionen zwischen den drei Rollen werden in der folgenden Abbildung dargestellt.
Se
Service
Consumer
c
rvi
u
es
ch
en
Service
Registry
ve
S
röf ervic
fen e
tlic
he
Service aufrufen
n
Service
Provider
Abbildung 5: Allgemeines Architekturmodell
2.2.2 Charakteristika von serviceorientierten Architekturen
Nach [Mat03] sind serviceorientierte Architekturen modular aufgebaut, d.h. ein Problem wird in
mehrere Teilprobleme unterteilt. Die Anwendungslandschaft wird [RHS05] zufolge aus „einzelnen
18
Grundlagen
fachlichen Anwendungsbausteinen“, d.h. Services aufgebaut, „die jeweils eine klar umrissene
fachliche Aufgabe wahrnehmen“.
Weiteres Merkmal von serviceorientierten Architekturen ist die Kapselung technischer Details. Nach
[Mat03, RHS05, PapHeu] werden lediglich die
„an den Geschäftsprozess gebundenen
Notwendigkeiten“ betrachtet.
Die Komponenten serviceorientierter Architekturen sind nach [RHS05] lose gekoppelt. Es bestehen
demzufolge nur sehr beschränkte Möglichkeiten zur Flusskontrolle, zur Gewährleistung der
Dienstqualität etc. [nach Hof03].
Weiterhin sind Services nach [RHS05] interoperabel und plattformunabhängig. Nach [PapHeu] muss
sich dieser Mechanismus an weit verbreiteten Standards orientieren und aus einem beliebigen ITSystem heraus aufzurufen sein.
Serviceorientierte Architekturen können auf vielfältige Art und Weise implementiert werden. Web
Services stellen eine standardisierte Infrastruktur zur Realisierung einer SOA dar.
2.2.3
Web Services
Web Services sind primär zur Integration heterogener IT-Systeme entstanden. Das große Versprechen
der Web Services lautet universelle Interoperabilität. Heterogene Software-Systeme können innerhalb
und außerhalb der Unternehmen miteinander kommunizieren. Die Systeme können von verschiedenen
Herstellern sein, in verschiedenen Programmiersprachen codiert sein und auf unterschiedlichen
Plattformen laufen. Dieser Gedanke ist nicht neu, doch Web Services ermöglichen durch die Nutzung
allgemein verfügbarer und leicht zu handhabender Standards den Zugang für jeden Interessierten. Sie
bringen „Interoperabilität für die Massen“ [Küs03].
Definition Web Service
“A Web Service is a software system designed to support interoperable machine-to-machine
interaction over a network. It has an interface described in a machine-processable format
(specifically WSDL). Other systems interact with the Web service in a manner prescribed by
its description using SOAP-messages, typically conveyed using HTTP with an XML
serialization in conjunction with other Web-related standards.” [HaaBro04]
[KosLey04] nennen weitere Schlüsseleigenschaften von Web Services. Demnach wird ein Web
Service global eindeutig durch einen Uniform Resource Identifier (URI) identifiziert. Zudem sind
Web Services autonom, d.h. man kann nicht beeinflussen, ob und wie eine Nachricht von einem
Web Service verarbeitet wird. Qualitätseigenschaften wie z.B. Antwortzeitgarantien müssen durch
zusätzliche Vereinbarungen geregelt werden.
Grundlagen
19
Nach [KosLey04] bauen Web Services auf drei Kerntechnologien auf. Dazu gehören das
Universal Description Discovery & Integration-Protokoll (UDDI), die Web Service Description
Language (WSDL) sowie das Simple Object Access Protocol (SOAP). Alle drei Technologien
basieren auf XML.
2.2.3.1 Universal Description Discovery & Integration
Das Universal Description Discovery & Integration Protokoll dient der Katalogisierung von Web
Services. Im zuvor erläuterten allgemeinen Architekturmodell speichert die Service Registry die
eingetragenen Web Services mit Hilfe von UDDI. Nach [Cer02] gliedern sich die Inhalte eines
UDDI-Verzeichnis in White, Yellow und Green Pages. In den White-Pages stehen allgemeine
Angaben zum Service Provider wie z.B. Name, Beschreibung und Ansprechpartner oder
Kontaktinformationen. Die Yellow Pages enthalten Informationen zu Produkten, Services,
Branche, geographischen Regionen etc. In den Green Pages werden letztlich die technischen
Details der Services veröffentlicht.
Nach
[OAS04]
existieren
im
UDDI-Datenmodell
vier
Datentypen:
businessEntity,
businessService, bindingTemplate und tModel. Diese sind hierarchisch angeordnet (siehe
folgende Abbildung). Eine businessEntity kann eine oder mehrere businessServices enthalten und
diese können wiederum ein oder mehrere bindingTemplates enthalten. Die bindingTemplates
verweisen schließlich mit Referenzen auf tModels. Wichtig ist hierbei: ein Objekt kann mehrere
untergeordnete Objekte enthalten (eine businessEntity kann mehrere businessServices enthalten)
aber ein Objekt kann immer nur einem anderen Objekt angehören (ein businessService kann nur
einer businessEntity angehören). tModels können mehrfach referenziert werden.
Abbildung 6: UDDI-Datenmodell
20
Grundlagen
Mit businessEntity werden Unternehmen bzw. Service Provider repräsentiert. Die Struktur enthält
allgemeine
Informationen über
das
Unternehmen
wie
z.B.
eine
Beschreibung und
Kontaktinformationen sowie eine Auflistung der angebotenen Services (siehe folgende
Abbildung). Dazu gehören jedoch noch keine technischen Beschreibungen der Services. [nach
OAS04]
Abbildung 7: businessEntity-Datentyp
Das Element businessService enthält genauere Informationen über die Services: Name,
Beschreibung, Informationen zur Klassifizierung, etc. (siehe folgende Abbildung). Auch hier sind
noch keine technischen Details spezifiziert, stattdessen können an dieser Stelle mehrere Services
unter einer Rubrik versammelt werden. Es könnten beispielsweise mehrere Services für die
Durchführung von Finanztransaktionen oder auch ein bestimmter Service in unterschiedlichen
Implementierungen angeboten werden. Jeder dieser Services verweist auf ein bindingTemplate.
[nach OAS04]
Abbildung 8: businessService-Datentyp
Grundlagen
21
Ein bindingTemplate repräsentiert einen Web Service in einer bestimmten Implementierung mit
einer bestimmten Adresse (accessPoint, z.B. eine URL) für den Aufruf des Services (siehe
folgende Abbildung). Es enthält die technischen Informationen, die Anwendungen für Aufruf und
Interaktion benötigen. Im bindingTemplate werden technical Models (tModelInstanceDetails)
referenziert, die die exakten technischen Details enthalten. [nach OAS04]
Abbildung 9: bindingTemplate-Datentyp
tModels repräsentieren technische Spezifikationen oder Konzepte. Mithilfe von Referenzen auf
tModels können Services ihre Kompatibilität mit dieser Spezifikation anzeigen. Die Angabe aller
kompatiblen tModels entspricht dem digitalen Fingerabdruck eines Service. Weiterhin ist es
möglich, die Registry nach allen zu einem bestimmten tModel kompatiblen Services zu
durchsuchen. Die technischen Spezifikationen werden in Dokumenten (overviewDoc, siehe
folgende Abbildung) außerhalb der tModel-Struktur abgelegt. [nach OAS04]
Abbildung 10: tModel-Datentyp
Um die Suche innerhalb der UDDI noch effizienter zu gestalten, ist es möglich UDDI-Inhalte
mithilfe von Taxonomien zu klassifizieren. Diese Taxonomien können von den UDDI-Nutzern
22
Grundlagen
selbst definiert werden und auf alle oben beschriebenen Objekte des UDDI-Datenmodells
angewandt werden. Die Inhalte können beispielsweise nach Anbieter, Produktart, Region etc.
kategorisiert werden. Die Suche kann schließlich vom Nutzer auf ganz bestimmte Kategorien
eingeschränkt werden und führt so zu noch genaueren Ergebnissen. Diese Klassifikations- und
Idenfikationssysteme werden in UDDI value sets genannt. [nach OAS04]
2.2.3.2 Web Services Description Language
Die Web Services Description Language (WSDL) „dient dazu, die Schnittstelle eines Web
Services zu beschreiben. Das heißt, WSDL erlaubt die Deklaration von Operationen und die
Definition der Nachrichten, die ein Web Service empfangen kann und die er verschickt.“
[KosLey04]
WSDL beschreibt Services als Sammlung von Endpunkten (ports), die Nachrichten austauschen.
Operationen (operations) und Nachrichten (messages) werden zunächst abstrakt beschrieben. Das
binding
verknüpft
diese
dann
mit
einem
konkreten
Netzwerkprotokoll
und
einem
Nachrichtenformat. Ausgestattet mit einer Netzwerkadresse bildet das binding einen Endpunkt.
Mehrere Endpunkte werden dann zu abstrakten Endpunkten (=Services) kombiniert. Das
verwendete Kommunikationsprotokoll ist üblicherweise SOAP, es kann aber auch ein anderes
Protokoll verwendet werden. [nach CCMW01]
2.2.3.3 Simple Object Access Protocol
Das
Simple
Object
Access
Protocol
(SOAP)
“legt
die
Grobstruktur
und
die
Verarbeitungsvorschriften von Nachrichten fest.“ Es ist sehr flexibel einsetzbar. In einem SOAPBody können XML-Daten oder auch binäre Daten enthalten sein. Des Weiteren unterstützt es
verschiedene Interaktionsmuster wie z.B. Remote Procedure Calls (RPC). [nach KosLey04]
Die folgende Abbildung veranschaulicht den Technologie-Stack von UDDI, WSDL und SOAP.
Die Technologien bauen aufeinander auf. UDDI dient der Veröffentlichung von Services und
deren Beschreibungen in Registries. WSDL beschreibt die Schnittstelle einzelner Services. Zur
Kommunikation wird das SOAP-Protokoll verwendet. Alle drei Technologien verwenden XML
und das Transportprotokoll HTTP.
Grundlagen
23
UDDI
WSDL
SOAP
XML
HTTP
etc.
Abbildung 11: Web Services Technology Stack [KosLey04]
2.3 Verwandte Konzepte
In der Praxis existieren verschiedene Konzepte zur Veröffentlichung der Servicemerkmale, die nicht
durch UDDI, WSDL, etc. beschrieben werden. An dieser Stelle sollen einige ausgewählte Ansätze
vorgestellt werden.
2.3.1 Dienstgüte
Existierende Ansätze zur Differenzierung von fachlich gleichartigen Services zielen zumeist auf
technische Kriterien, die so genannte Dienstgüte oder Quality-of-Service (QoS). Die am häufigsten
genannten Parameter einer Dienstgüte-Spezifikation umfassen die folgenden:
Verfügbarkeit (Availability) gibt für ein definiertes Zeitintervall die Wahrscheinlichkeit an, mit der ein
Service die Anfrage eines Service Consumer beantworten kann. Sie wird prozentual für eine gegebene
Zeitspanne angegeben. Wenn ein Service an einem Tag beispielsweise 23 von 24 Stunden verfügbar
war, beträgt die Verfügbarkeit 95,8%. [nach BHMS03, Ran03]
[ManNag02] grenzt die Accessibility von der Verfügbarkeit ab. Hier bedeutet Verfügbarkeit lediglich,
dass der Service präsent und nutzungsbereit ist. Accessibility beschreibt hingegen die Möglichkeit auf
den Service dann wirklich zugreifen zu können, um ihn zu nutzen. Ein überlasteter Service kann
verfügbar sein, aber nicht accessible.
Integrität (Integrity) beschreibt die Fähigkeit eines Service, Transaktionen auszuführen. Eine
Transaktion ist eine Sequenz von mehreren Arbeitsschritten, die als einzelne Aktivität betrachtet wird.
Dementsprechend müssen alle Schritte erfolgreich sein damit die Transaktion erfolgreich ist. Sobald
einer der Schritte abgebrochen wird, müssen die erfolgten Änderungen rückgängig gemacht werden
und die gesamte Transaktion wird abgebrochen. [nach ManNag02, Ran03]
Leistungsfähigkeit (Performance) ergibt sich aus den beiden Faktoren Durchsatz (Throughput) und
Antwortzeit (Response Time bzw. Latency). Der Durchsatz gibt an, wie viele Serviceanfragen
24
Grundlagen
innerhalb einer bestimmten Zeitperiode bearbeitet werden können. Die Antwortzeit definiert sich aus
der Zeit, die benötigt wird, bis man das Resultat einer Anfrage erhält.
Zuverlässigkeit (Reliability) beschreibt die Fähigkeit einen Service sowie die Servicequalität aufrecht
zu erhalten. Die Anzahl der Abstürze in einem bestimmten Zeitintervall kann als Zuverlässigkeitsmaß
dienen. Zuverlässigkeit kann auch die zuverlässige und geordnete Zustellung von Nachrichten
zwischen Service Consumer und Provider meinen. [nach ManNag02]
Regulatory beschreibt die Einhaltung von Regeln, Gesetzen und die Konformität mit Internetstandards
wie z.B. SOAP, UDDI und WSDL. Die Einhaltung solcher Standards durch den Service Provider ist
nötig, damit der Service Consumer den Service korrekt aufrufen kann. [nach ManNag02]
Sicherheit (Security) umfasst die Authentizität der beteiligten Partner, die Autorisierung der Nutzer
(Zugangskontrolle) sowie die Verschlüsselung der Daten bzw. Nachrichten. [nach ManNag02,
BHMS03]
2.3.2
Nicht-technische Kriterien
Zusätzlich können nicht-technische Kriterien über Services festgehalten werden. Die Nutzung eines
Service kann kostenpflichtig oder kostenlos sein. Die Nutzungsgebühren berechnen sich „nach der
Anzahl der Aufrufe, der Nutzungsdauer, des verarbeiteten Datenvolumens oder nach einem
Pauschaltarif“ [GKG03]. Auch die Reputation des Service Providers oder eines Service im speziellen
kann dokumentiert werden und so dem Service Consumer eine weitere Entscheidungshilfe bei der
Auswahl eines Service Providers bieten. [nach BHMS03]
2.3.3
Service Level Agreements (SLAs)
Service Level Agreements stellen Verträge dar, die zwischen einem Dienstleister und seinem Kunden
abgeschlossen werden. Dort werden die genauen Parameter der zu erbringenden Dienstleistung, deren
Qualität sowie die Rahmenbedingungen unter denen diese Qualität eingehalten wird, festgelegt
[BHMS03, CCDS03]. Oft werden mehrere Service Levels (z.B. Gold, Silber, Bronze) mit abgestuften
Qualitätseigenschaften und Kosten für eine Dienstleistung angeboten. Die Service Levels für eine
Störungsbehebung könnten beispielsweise eine Behebung innerhalb von 3 Stunden (Gold), 6 Stunden
(Silber) oder 12 Stunden (Bronze) vorsehen. Die Einhaltung der SLAs kann überwacht werden und bei
Nichteinhaltung entsprechende Strafen auslösen.
Eine zu technische Orientierung bei der Definition von SLAs kann deren Nutzen jedoch schnell
zunichte machen. Letztendlich ist für den Service Consumer nicht die bloße Einhaltung von
Übertragungsgeschwindigkeiten und Antwortzeiten, sondern die Erreichung seiner Geschäftsziele
entscheidend. [nach CZ06]
Grundlagen
25
2.4 Verwandte Projekte
Die in Kapitel 2.3 beschriebenen Konzepte werden in einer Reihe von Projekten bereits angewandt.
Einige interessante Forschungsprojekte sollen im Folgenden vorgestellt werden.
2.4.1 E-Finance Lab
Das E-Finance Lab ist eine Kooperation der Universitäten Darmstadt und Frankfurt sowie
verschiedener Unternehmen, vornehmlich aus der Finanzbrache. Der Cluster II dieses Projekts
beschäftigt sich mit dem Einsatz neuer IT-Architekturen, insbesondere der serviceorientierten
Architektur und Web Services zur besseren Unterstützung der Geschäftsprozesse innerhalb der EFinance Branche. Im Zuge dessen sollen die technischen Anforderungen flexibler und agiler EFinance Prozesse genauer untersucht werden. Dabei spielt die Unterstützung von Dienstgütegarantien
(QoS) für Web Services eine besondere Rolle. Der Mangel solcher Garantien hielt Finanzinstitutionen
bisher davon ab, Services von externen Anbietern in ihre kritischen Geschäftsprozesse einzubinden.
Der Forschungsprototyp WSQoSX (Web Service Quality of Service Architectural Extension) soll die
Steuerung SoA-basierter Geschäftsprozesse ermöglichen [BHS05]. Dazu müssen Service Provider ihre
Services am Portal des Service Consumers registrieren und für ihre Services Dienstgüteeigenschaften
in Form von Service Level Agreements (SLAs) garantieren. Die Services werden dann zur Laufzeit
unter Berücksichtigung ihrer Dienstgüteeigenschaften ausgewählt.
2.4.2 DySCo
Beim DySCo Framework [PFW03] handelt es sich um eine Erweiterung der Workflowtechnologie,
die es erlaubt Web Services in Geschäftsprozesse zu integrieren. Die Autoren nennen dies ServiceOriented-Workflow. Den Unterschied zwischen Workflow-Systemen und Web Services erklären sie
wie folgt. In einem Workflow steuert eine zentrale Einheit den Prozess. Sie beauftragt Ressourcen mit
der Erledigung von Tasks. Die Ressourcen selbst besitzen keinerlei Prozesswissen, d.h. sie kennen
nicht den Zweck oder das Ziel ihrer Arbeit, sondern führen lediglich die Arbeit aus, mit der sie
beauftragt wurden. Bei der Nutzung von Web Services werden Tasks an externe Service Provider
übergeben, die entsprechende Services anbieten. Der Service Provider kann zur Erfüllung des Tasks
wiederum Services von anderen Service Providern in Anspruch nehmen. Der grundlegende Prozess zu
dem der Task gehört, bleibt der gleiche, die Prozesslogik ändert sich nicht. Je nach Art der
Realisierung durch den Service Provider kann sich jedoch die Interaktions- und Koordinationslogik
ändern.
Die Interaktions- und Koordinationslogik jedoch ändern sich je nachdem, wie der Service Provider
den ihm übergebenen Task realisiert.
26
Grundlagen
Im vorgestellten Dynamic Service Composer (DySCo) verschiebt sich der Fokus von (Workflow-)
Aktivitäten
zu (Web-Service-)Interaktionen. Ressourcen werden zu Rollen, Tasks werden zu
Interaktionsschritten. Ressourcen verrichten Tasks, wenn sie damit beauftragt werden. In einem
Interaktionsschritt interagieren verschiedene Rollen miteinander, um ein vorgegebenes Ziel zu
erreichen. In Workflow enthält eine task description genügend Informationen, um die Ressource bei
der Ausführung der Aktivität anzuleiten. In einem Interaktionsschritt enthält die step description
Informationen darüber, wie die involvierten Rollen miteinander interagieren müssen. Informationen
bzw. Änderungen des Status des Gesamtprozesses können Input und Output eines Interaktionsschritts
sein. Bei der Berechnung des Outputs fließen die Beiträge aller an dem Interaktionsschritt beteiligten
Rollen ein. Die Interaktionen zwischen den Rollen eines Interaktionsschrittes sind unabhängig von den
Service Providern, die letztlich die Rollen einnehmen. Die Interaktionslogik bleibt erhalten, während
die Zusammensetzung der Service Provider sich ändern kann. DySCo rekonfiguriert dynamisch die
Interaktionsprozesse zwischen Service Providern und passt die Koordinationslogik automatisch an.
DySCo enthält eine Entwicklungs- sowie eine Laufzeitumgebung für Web Services. Die Komposition
von Web Services kann über eine graphische Oberfläche in WfMC-konformer Darstellung modelliert
werden. Dazu kann man sowohl traditionelle Workflow-Prozesse als auch Interaktionsschritte
erstellen. Die projection generation environment unterstützt die automatische Generierung der
Koordinationslogik für verschiedene Rollenkonfigurationen.
2.4.3
FRESCO
Das FRESCO-Rahmenwerk (Foundational Research on Service Composition) [PZL03] bietet
Funktionen zum Planen, Konstruieren und Betreiben von dienstorientierten Anwendungen. Der Fokus
liegt dabei, ähnlich wie bei DySCo, auf der dynamischen Komposition von Services. FRESCO enthält
zum einen konzeptionelle Modelle zur Servicekomposition, -koordination und -aggregation und zum
anderen die technologische Infrastruktur für die Entwicklung und Ausführung von zusammengesetzten
Services.
2.4.4
COSMOS
COSMOS [Gri98] ist ein internetbasierter electronic contracting Service, der es kooperierenden
Firmen erleichtern soll, Geschäftsprozesse zu automatisieren. Dazu setzt COSMOS bei Verträgen als
Grundlage jeder kommerziellen Transaktion an. Verträge sind strukturierte Dokumente, die sämtliche
Informationen bzgl. vereinbarter Leistungen, Konditionen etc. enthalten. Somit eignen sie sich ideal,
um alle Phasen einer Transaktion zu unterstützen, d.h. neben der Verhandlung der Konditionen
insbesondere die Ausführung des Vertrags und die Kontrolle der Vertragsparteien.
Grundlagen
27
COSMOS integriert mehrere Funktionalitäten mit dem Ziel die Transaktionskosten, d.h. InformationsVerhandlungs- und Ausführungskosten, in elektronischen Märkten zu reduzieren. Die folgende
Abbildung veranschaulicht den Umfang des COSMOS Service. Dieser enthält einen Servicekatalog
(Offer
Catalogue),
einen
Vermittlungsservice
Vertragsverhandlung (Negotiation),
(Brokerage)
-unterzeichnung (Signing)
sowie
und
Funktionalitäten
zur
-ausführung (Workflow
Execution).
Abbildung 12: COSMOS Service
Der Servicekatalog enthält Informationen über die von den Marktteilnehmern angebotenen Services
mitsamt deren Dienstgüteparametern. Der Vermittlungsservice sucht auf Anfrage der Marktteilnehmer
nach
potentiellen
Vertragspartnern.
Die
Vertragsverhandlungsunterstützung
ermöglicht
ein
kollaboratives Erstellen von Verträgen. Jede Vertragspartei hat dabei die Möglichkeit, Änderungen am
aktuellen Vertrag vorzunehmen und diese der anderen Partei als Angebot vorzulegen. Diese kann den
Vorschlag annehmen, selbst ein Angebot mit Änderungen machen oder das Angebot ablehnen. So
kommt Schritt für Schritt ein Vertrag zustande. Die Vertragsunterzeichnung erfolgt mithilfe digitaler
Signaturen. Workflow-Software koordiniert letztlich die Vertragsausführung, d.h. die Ausführung der
einzelnen Aktivitäten durch definierte Rollen in einer definierten Reihenfolge.
2.5 Abgrenzung zu verwandten Arbeiten
Alle vorgestellten Projekte zielen auf den Einsatz von Web Services zur Unterstützung von
Geschäftsprozessen ab. In jedem der Projekte wird der gesamte Lebenszyklus eines Web Service
unterstützt. Jedes Projekt verfolgt dabei einen eigenen Ansatz und bietet eine eigene Infrastruktur zur
Ausführung der zusammengesetzten Services.
28
Grundlagen
Im Projekt „E-Finance Lab“ werden Services an einem zentralen Portal registriert und mit
Informationen über die Dienstgüte und Service-Level-Agreements angereichert. Das Projekt DySCo
fokussiert insbesondere auf die sich ändernden Interaktionsprozesse und Koordinationslogik innerhalb
von zusammengesetzten Geschäftsprozessen. Das Projekt FRESCO verfolgt einen sehr theoretischen
Ansatz, indem insbesondere konzeptionelle Modelle für die Komposition und Aggregation von
Services entwickelt werden. Das Projekt COSMOS fokussiert auf Verträge als Grundlage und
Steuerungsinstrument jeden Geschäftsprozesses.
Die vorliegende Arbeit wird ebenfalls die Integration von Web Services in automatisierte
Geschäftsprozesse (Workflows) betrachten. Dazu sollen möglichst umfassende Informationen über
Services veröffentlicht werden, um so dem Service Consumer eine bessere Entscheidungsgrundlage zu
bieten und es Service Providern zu ermöglichen, sich von Wettbewerbern zu differenzieren.
2.6 Exkurs: Wettbewerbsstrategien
In einer serviceorientierten Architektur kauft sich ein Service Consumer von einem externen Anbieter,
dem Service Provider, eine Funktionalität ein. Services sind demnach vergleichbar mit Produkten und
Dienstleistungen, die dem Kunden ebenfalls eine Funktionalität bereitstellen. Um in einem Markt
gegen den Wettbewerb zu bestehen, muss man eine Strategie verfolgen. In der betriebswirtschaftlichen
Literatur finden sich die folgenden essentiellen Wettbewerbsstrategien.
[Por85] besagt, dass Organisationen in einem Markt nur eine von drei Grundtypen von Strategien
verfolgen können, um einen Wettbewerbsvorteil zu erlangen: Kostenführerschaft, Differenzierung und
Nischenbesetzung. Jede Strategie hat einen anderen Ansatzpunkt und verfolgt andere Ziele [nach
Bli02, S. 28].
2.6.1
Kostenführerschaft
Organisationen die die Strategie der Kostenführerschaft verfolgen, versuchen ihre Kosten möglichst
niedrig zu halten. Die Organisation mit den niedrigsten Kosten kann demnach auch dann noch Profit
erwirtschaften, wenn der Preis für das angebotene Produkt bzw. die angebotene Dienstleistung so weit
gesunken ist, dass alle anderen Wettbewerber Verluste machen. Oberste Priorität ist die Unterbietung
der Konkurrenzpreise, um somit einen möglichst hohen Marktanteil zu erobern. Kostenvorteile
können auf unterschiedliche Art und Weise erreicht werden. Einige Beispiele sind Skaleneffekte, d.h.
durch die Fertigung großer Stückzahlen fallen die Kosten pro Einheit, Erfahrungseffekte, d.h. mit
zunehmender Erfahrung wird die Produktion effizienter, was zu sinkenden Kosten führt, verbesserter
Prozesstechnik, Produktdesign, Prozessdesign, Kapazitätsausnutzung etc. Das größte Risiko bei der
Verfolgung dieser Strategie besteht in der Kostenunterbietung durch einen Wettbewerber. [nach
Gra02]
Grundlagen
29
2.6.2 Differenzierung
Organisationen die die Strategie der Differenzierung verfolgen, bieten eine überlegene Produktleistung
durch Fokussierung eines wichtigen Kundennutzen. Die überlegene Produktleistung rechtfertigt
dementsprechend einen höheren Preis und ermöglicht dem Unternehmen so eine höhere
Umsatzrendite. Mintzberg identifiziert die folgenden fünf Möglichkeiten der Differenzierung. [nach
MQG95]
 Differenzierung über den Preis bedeutet, dass eine Organisation sich über einen im Vergleich zur
Konkurrenz höheren oder niedrigeren Preis profilieren will. Geschieht die Differenzierung über
einen besonders niedrigen Preis, so strebt die Organisation normalerweise auch die
Kostenführerschaft an.
 Differenzierung über das Image bedeutet, dass eine Organisation versucht unter umfangreichem
Einsatz von Marketing-Techniken (z.B. Werbung) beim Kunden einen guten Eindruck bzgl.
Qualität und Leistung der Organisation bzw. ihrer Produkte zu hinterlassen.
 Differenzierung über Support bedeutet, sich über eine produktbegleitende Leistung zu
differenzieren (z.B. eine kostenlose und rund um die Uhr zu erreichende Hotline).
 Bei einer Differenzierung durch das Design steht das Produktdesign im Vordergrund. Die
Entwicklung von neuen Produkten ist hier besonders wichtig.
 Differenzierung über die Qualität bezieht sich auf die Produktions- und Prozessfähigkeiten einer
Organisation. Die Organisation versucht, Qualität in ihre Produkte und Prozesse zu integrieren
und diese streng zu kontrollieren.
2.6.3 Nischenbesetzung
Die Strategie der Nischenbesetzung sieht eine Konzentration auf ein oder mehrere eng umrissene(s)
Marktsegment(e) vor. Das Unternehmen spezialisiert sich dazu auf die Bedürfnisse dieser/dieses
Segmente/Segments. Die Strategie kann in zwei Varianten angewendet werden. Bei einer
Nischenbesetzung mit Kostenführerschaft ist das Ziel ein hoher Marktanteil. Bei einer
Nischenbesetzung mit Differenzierung ist es eine hohe Umsatzrendite.
Die Marktsegmentierung ist ein wesentlicher Schritt, um eine Nischenbesetzungsstrategie zu
implementieren. Hierzu wird die Gesamtheit eines Marktes (z.B. für Automobile) in verschiedene
Segmente mit spezifischen Charakteristika eingeteilt (z.B. Premium- und Low-Cost-Automobile). Im
B2B-Bereich sind insbesondere die demographischen Variablen von Organisationen wichtig für die
Segmentierung. In [BonSha83] werden die folgenden Variablen mit den dazu gehörigen Leitfragen
aufgelistet:
30
Grundlagen
 Branche
„Auf welche Branchen, die unser Produkt benötigen, sollten wir uns konzentrieren?“
 Organisationsgröße
„Auf Unternehmen welcher Größe sollten wir uns konzentrieren?“
 Standort bzw. Region
„Auf welche geographischen Gebiete sollten wir uns konzentrieren?“
 Operative Variablen
„Auf welche Kundentechnologien sollten wir uns konzentrieren?“
 Kundenkompetenz
„Sollten wir uns auf Kunden konzentrieren, die viele Dienstleistungen benötigen, oder auf solche,
die wenige benötigen?“
Die folgende Abbildung stellt die drei erläuterten Strategien grafisch dar.
Kostenführerschaft
Differenzierung
mit Kostenführerschaft
mit Differenzierung
Nischenbesetzung
Abbildung 13: Generische Wettbewerbsstrategien nach Porter
Das Konzept der Wettbewerbsstrategien wird im weiteren Verlauf der Arbeit hilfreich bei der
Definition von sinnvollen Informationen zur Beschreibung von Services sein.
Modellbildung
31
3. Modellbildung
3.1 Serviceorientierter Workflow
So wie einzelne Aktivitäten in einem Workflow von Applikationen erledigt werden, könnten auch
Services in einen Workflow integriert werden. Die Archivierung von Dateien in einer Datenbank kann
intern im eigenen Unternehmen erfolgen, es kann aber auch der Datenbank-Service eines externen
Anbieters genutzt werden. Dank der globalen Verfügbarkeit von Services über das Internet kann die
ganze Vielfalt der angebotenen Services zur Unterstützung des Workflows eingesetzt werden. Die
Organisation, bzw. das Workflow-Management-System übernimmt in diesem Fall die Rolle des
Service Consumers.
Bei der Integration offenbaren sich dennoch einige Probleme. Einen Datenbankservice können viele
Service Provider anbieten. Diese können sich in der Kapazität des Speichers, der Leistung der
verwendeten Rechner, der Bandbreite der Verbindung und vielen anderen Merkmalen unterscheiden.
Die in der Service Registry veröffentlichten Informationen beschränken sich jedoch auf die
Aufrufschnittstellen der verschiedenen Services. Die Unterschiede zwischen den Services werden dem
Service Consumer nicht angezeigt. Diesen Sachverhalt stellt die folgende Abbildung dar.
Service X
?
Service 1
Service Provider 1
Service 2
Service 3
Service Provider 2
Service Provider 3
Abbildung 14: Serviceorientierter Workflow
Es
liegt
folglich
ein
Informationsproblem
vor.
Dem
Service
Consumer
fehlt
die
Entscheidungsgrundlage für die Auswahl eines Service. Besitzt der Service Consumer nicht die
technische Expertise um die Schnittstellenbeschreibung zu verstehen, findet er seinen gesuchten
32
Modellbildung
Service möglicherweise gar nicht. Der Service Provider bekommt in der Service Registry keine
Möglichkeit, sich von der Konkurrenz abzuheben, da Merkmale seines Service teilweise gar nicht
kommuniziert werden. Die Funktionalität der Service Registry muss demnach erweitert oder ergänzt
werden, um die Speicherung weiterführender Informationen zu ermöglichen.
Zur Identifikation der Informationen die für die Service Consumer interessant sind, erfolgt zunächst
eine genauere Betrachtung der Service Provider. Wie ein angebotener Service zustande kommt ist
dabei von besonderem Interesse. Daher wird im Folgenden genauer auf die Prozesse, die innerhalb
eines Service Providers ablaufen, eingegangen. Anschließend werden Möglichkeiten zur
umfangreichen Beschreibung dieser Prozesse aufgezeigt und diese schließlich in einem Schema
zusammengetragen.
3.2 Wettbewerbsinformationen
Das Konzept der Wettbewerbsstrategien kann auch auf unseren Anwendungsfall, d.h. den Markt für
Services, übertragen werden. Dabei soll nicht die Art der Strategie, die die Service Provider verfolgen,
von Interesse sein, sondern die Art der Informationen, die im Markt vorhanden sein müssen. Verfolgt
eine Organisation die Strategie der Kostenführerschaft, so muss es den Kunden Informationen über die
Kosten seiner Produkte (über den Preis) zur Verfügung stellen. Verfolgt eine Organisation die
Strategie der Differenzierung, so muss es seinen Kunden Informationen über die Art der
Differenzierung seiner Produkte zur Verfügung stellen. Gleiches gilt für die Strategie der
Nischenbesetzung, hier müssen Informationen über das bearbeitete Segment verfügbar gemacht
werden. Ein Markt benötigt demnach Informationen über Kosten, Differenzierungsmerkmale und
Segmente, um den Marktteilnehmern einen idealen Wettbewerb zu ermöglichen.
Auch auf dem Markt für Services müssen Informationen aus den drei genannten Kategorien
veröffentlicht werden, um Wettbewerb herzustellen. Diese Informationen sollen in das zu
entwickelnde Modell einfließen.
3.3 Prozesse der Service Provider
Services basieren auf einer Vielzahl von Prozessen. Nach [ZirLam04] können diese Prozesse in
interne Erstellungs- und externe Erbringungsprozesse unterteilt werden.
Erstellungsprozesse umfassen die Fähigkeiten eines Service Provider, die notwendig sind, um die
Inhalte einer Leistung zu realisieren. Betrachtet man einen Logistikdienstleister, gehören zu dessen
Fähigkeiten etwa die Handhabung und der Transport von Waren.
Modellbildung
33
Erbringungsprozesse umfassen hingegen all die Fähigkeiten, mit denen der Service Provider dem
Service Consumer die Dienstinhalte verfügbar und nutzbar macht. Im Logistikbeispiel gehören dazu
etwa die Interaktion mit dem Kunden oder die Veröffentlichung von Preisen und Lieferfristen.
Zur Erstellung einer Leistung greift ein Service Provider auf Ressourcen zurück. Diese Ressourcen
bestimmen maßgeblich das Ergebnis des Erstellungsprozesses. Die internen Fähigkeiten Gefahrgut
oder zerbrechliche Waren unbeschadet zu transportieren, ist für den Service Consumer von ebenso
hoher Bedeutung wie die externen Attribute Preis und Lieferfrist. Service Provider unterscheiden sich
demnach nicht nur durch die externen Erbringungsprozesse, sondern ebenso durch die internen
Erstellungsprozesse und Ressourcen.
Serviceorientierte
Architekturen
und
Web
Services
fokussieren
traditionell
auf
die
Erbringungsprozesse. Das Medium über das die Erbringung eines Service realisiert wird, ist die
Schnittstelle. Insbesondere diese ist in der Service Registry beschrieben. Nutzt ein Service Consumer
einen Service, interessiert ihn aber nicht nur die Schnittstelle an sich, sondern vielmehr die
Funktionalität, die ihm über diese Schnittstelle verfügbar gemacht wird. Diese hängt direkt mit den
Erstellungsprozessen, die im Inneren des Service Providers ablaufen, zusammen.
In der Service Registry sind lediglich Informationen über die externen Erbringungsprozesse hinterlegt.
Die Leistung, die der Service Consumer letztlich erhält, wird aber auch von den internen
Erstellungsprozessen und Ressourcen des Service Providers beeinflusst. Demnach müssen auch über
diese Prozesse und Ressourcen Informationen in der Service Registry hinterlegt werden.
Die folgende Abbildung veranschaulicht diesen Zusammenhang. Die drei hellblauen Kreise stellen die
drei Rollen in serviceorientierten Architekturen dar. Beim Service Provider erscheint nun die
Trennung zwischen Erbringungs- und Erstellungsprozessen. Die Erbringungsprozesse des Service
Providers sind als hellblauer Kasten dargestellt. Der Informationsfluss zwischen den drei Rollen ist
mit durchgehenden Pfeilen dargestellt und beschränkt sich in der klassischen serviceorientierten
Architektur auf die Erbringungsprozesse. Die schraffierten Kästen zeigen die Erstellungsprozesse
sowie die von diesen genutzten Ressourcen. Diese befinden sich im Inneren des Service Providers, da
von diesem die Leistung erstellt wird. Mit unserem Modell soll der Informationsfluss auf die
Erstellungsprozesse erweitert werden. Der zusätzliche Informationsfluss wird durch die gestrichelten
Pfeile angezeigt.
34
Modellbildung
Service
Registry
Erbringung
Service
Consumer
Service
Provider
Erstellung
Ressource
Abbildung 15: Konzeptionelles Servicemodell
3.4 Funktionale und nicht-funktionale Eigenschaften
Funktionale Eigenschaften beschreiben die Funktionalität eines Service, d.h. die Arbeit die er für den
Service Consumer verrichtet bzw. die Fähigkeit eine bestimmte Aufgabe zu lösen.
In serviceorientierten Architekturen existieren für die Beschreibung der funktionalen Eigenschaften
bereits mehrere Elemente: die Service Description sowie das Service Interface. Aus der Service
Description sind die vom Service erbrachten Funktionen, die Beschreibung der Interaktion, d.h.
Formate, Inhalte und Reihenfolge von Nachrichten sowie eventuelle Beschränkungen und
Vorschriften hervorzuheben. Das Service Interface gibt genauere Informationen zur Bindung eines
Service und über die dazu benötigten Protokolle. Es stellt dem Service Consumer sämtliche
Informationen zur Verfügung, um den Service selbstständig aufrufen zu können (z.B. die URI).
Nicht-funktionale Eigenschaften umfassen die Eigenschaften eines Service, die nicht direkt mit der
Funktionalität zu tun haben. Einige nicht-funktionale Eigenschaften wurden bereits in Kapitel 2.3
vorgestellt. Sie werden im Folgenden in vier Kategorien aufgeteilt: Dienstgüte, Nutzungsgebühren,
Reputation des Service Providers und zusätzliche nicht-funktionale Leistungen.
Wie oben beschrieben, umfasst die Dienstgüte die Parameter Verfügbarkeit, Integrität,
Leistungsfähigkeit, Zuverlässigkeit, Regelkonformität und Sicherheit. Diese Parameter haben keinen
direkten Einfluss auf die Funktionalität des Services.
Wie oben erwähnt, kann die Nutzung kostenlos oder kostenpflichtig sein. Ist sie kostenpflichtig, kann
die Abrechnung „nach der Anzahl der Aufrufe, der Nutzungsdauer, des verarbeiteten Datenvolumens
oder nach einem Pauschaltarif erfolgen“ [GKG03].
Modellbildung
35
Die Reputation des Service Providers könnte über ein Punktesystem angezeigt werden. So könnten die
Nutzer eines Service diesen Service und auch den Service Provider auf einer Punkteskala bewerten.
Diese Bewertungen könnten zentral gespeichert und aufbereitet werden und so eine Bewertung aller
Service Provider ermöglichen. Zukünftigen Nutzern kann die Bewertung wiederum hilfreich bei der
Wahl des Services bzw. Service Providers sein.
Verfügt der Service über weitere nicht-funktionale Eigenschaften, sollten auch diese veröffentlicht
werden. Dazu gehören alle zusätzlichen Leistungen, die nicht direkt die Funktionalität des Services
berühren, für den Service Consumer aber dennoch nützlich sein könnten. Dazu gehören z.B. SupportLeistungen wie eine Service-Hotline, eine Fortschrittsüberwachung, die Berichterstattung in textueller
oder grafischer Form etc..
Im Folgenden werden die genannten Eigenschaften in einem Service-Schema zusammengefasst.
3.5 Service-Schema
Um
Redundanz
zu
vermeiden,
wird
nicht
jede
der
zuvor
genannten
Kategorien
(Wettbewerbsinformationen, Prozesse, funktionale und nicht-funktionale Eigenschaften) als eigener
Punkt im Service-Schema aufgelistet. Die Service-Kosten würden so beispielsweise unter dem Punkt
Wettbewerbsinformationen und nicht-funktionale Eigenschaften gelistet. Zur Gliederung der oben
identifizierten Informationen bietet sich am ehesten die Unterscheidung von funktionalen und nichtfunktionalen Eigenschaften an. Unter diesen Kategorien können auch die Informationen zu
Wettbewerb und Prozessen versammelt werden.
Informationen über die Kosten eines Service fallen in die Kategorie nicht-funktionale Eigenschaften,
da
sie
die
Funktionalität
nicht
direkt
beeinflussen.
Auch
die
zuvor
genannten
Differenzierungsmerkmale (Preis, Qualität, Image etc.) gehören zu den nicht-funktionalen
Eigenschaften, denn gerade über diese können sich Services, die ansonsten die gleiche Funktionalität
bieten, differenzieren. Die Informationen zum Segment gehören hingegen zu den funktionalen
Eigenschaften. Sie beschreiben über die beabsichtigte Zielgruppe indirekt auch die Funktionalität bzw.
beschränken diese. Die Funktionalität wird für eine bestimmte Gruppe zur Verfügung gestellt.
Die Erbringungsprozesse werden über das Service Interface beschrieben. Dort wird erläutert, wie man
die Leistung des Service Providers erhält. Das Service Interface gehört zu den funktionalen
Eigenschaften. Die Erstellungsprozesse beschreiben zum einen was im Inneren des Service Providers
geschieht, dazu dient die Service Description, und zum anderen wie das geschieht, d.h. mit welcher
Dienstgüte. Die Service Description ist den funktionalen Eigenschaften zuzurechnen, die Dienstgüte
den nicht-funktionalen Eigenschaften.
36
Modellbildung
Grundlegende Informationen zur Identifikation eines Service sind ein Titel, ein Name und eine
Beschreibung des Service-Providers. Diese erscheinen zu Beginn des Service-Schemas.
Die Erkenntnisse des Kapitels zusammenfassend ergibt sich folgendes Service-Schema:
1. Titel
o
Umgangssprachliche Beschreibung
2. Service-Provider
o
Beschreibung
o
Kontaktdaten
o
URL
3. Funktionale Eigenschaften
o
Service Description
o
Service Interface
o
Segment

Branche

Organisationsgröße

Standort/Region

Operative Variablen

Abteilungsfunktion

Kundentechnologien
4. Nicht-funktionale Eigenschaften
o
o
o
o
Nutzungsgebühren

Preis pro Aufruf

Preis pro Zeiteinheit

Preis pro Volumeneinheit

Pauschaltarife
Dienstgüte

Leistungsfähigkeit

Verfügbarkeit

Integrität

Zuverlässigkeit

Regelkonformität

Sicherheit
Reputation

Reputation des Service Providers

Reputation des Services
Nicht-funktionale Zusatzleistungen
Realisierung & Fallstudie
37
4. Realisierung & Fallstudie
Das Kapitel Realisierung & Fallstudie gliedert sich in drei Teile. Im ersten Teil wird die Realisierung
des Service-Schemas mit Informationen aus vorhandenen und neuen Datenstrukturen untersucht. Im
zweiten Teil wird die neue Komponente Domain Manager vorgestellt, die die Informationen des
Service-Schemas zusammentragen und verfügbar machen soll. Im letzten Teil wird das entwickelte
Modell auf einen Prozess aus dem E-Government angewandt.
4.1 Realisierung Service-Schema
Bisher stehen als Informationsquellen für die Realisierung des Service-Schemas die drei Rollen
Service Registry, Service Provider und Service Consumer zur Verfügung. Im Folgenden wird
dargestellt, welche der Rollen welche Informationen zur Verfügung stellen kann.
In der Service-Registry werden bereits einige Informationen über die eingetragenen Services
bereitgestellt. Über das UDDI-Datenmodell (siehe Kapitel 2.2.3.1) werden Informationen über den
Service Provider durch die businessEntity-Klasse bereitgestellt. Sie enthält Name, Beschreibung,
URL, Kontaktinformationen sowie eine Liste der angebotenen Services. Die businessService-Klasse
enthält Name, Beschreibung und angebotene bindingTemplates eines Services. Die bindingTemplateKlasse enthält die Beschreibung, die Adresse für den Aufruf und eine Liste der unterstützten tModels.
Die tModels enthalten wiederum den Namen, eine Beschreibung sowie Spezifikationen. Die WSDLDateien, die für jeden eingetragenen Service existieren, enthalten Angaben zu Nachrichtenformaten,
Operationen und Adressen.
Die weiteren Informationen des Service-Schemas muss der Service Provider liefern. Für die
Bereitstellung gibt es zwei Möglichkeiten. Sie kann entweder statisch erfolgen, d.h. die Informationen
werden einmalig übermittelt oder sie werden dynamisch, d.h. zum Zeitpunkt der Anfrage durch den
Service Consumer zur Verfügung gestellt. Statische Informationen sollten durchgehend für den
Service gelten und sich nicht ändern, während sich die dynamischen Informationen ständig ändern
können und nur zum Zeitpunkt der Anfrage und des evtl. folgenden Aufrufs gültig sein müssen.
Zu den statischen Informationen gehören die Informationen zum Marktsegment, den permanent
gültigen Parametern der Dienstgüte (Integrität, Regelkonformität, Sicherheit), den Nutzungsgebühren
und eventuellen Zusatzleistungen, sofern diese konstant sind. Zu den dynamischen Informationen
gehören die variablen Parameter der Dienstgüte (Leistungsfähigkeit, Verfügbarkeit, Zuverlässigkeit),
sowie variable Nutzungsgebühren und Zusatzleistungen (z.B. je nach Auslastung).
38
Realisierung & Fallstudie
Einen Sonderfall stellen die Informationen zur Reputation dar. Die Bewertungen der Services
stammen vom Service Consumer, aber die Ermittlung der Reputation muss durch eine neutrale Instanz
erfolgen. Hierauf wird im nächsten Abschnitt genauer eingegangen.
Es werden folglich mehrere neue Datenstrukturen zum Datenaustausch benötigt. Die Datenstrukturen
der UDDI sind bereits in Kapitel 2.2.3.1 erläutert worden. Für die Übermittlung der statischen und
dynamischen Informationen werden im Folgenden an XML angelehnte Schemas definiert.
1. Schema für statische Informationen
<statische_information>
<marktsegment>
<branche>
<organisationsgröße>
<standort>
<operative_variable>
<abteilungsfunktion>
<technologie>
</operative_variable>
</marktsegment>
<dienstgüte>
<integrität>
<regelkonformität>
<sicherheit>
</dienstgüte>
<nutzungsgebühr>
<pro_aufruf>
<pro_zeiteinheit>
<pro_volumeneinheit>
<pauschaltarif>
</nutzungsgebühr>
<zusatzleistung>
</statische_information>
2. Schema für dynamische Informationen
<dynamische_information>
<dienstgüte>
<leistungsfähigkeit>
<verfügbarkeit>
<zuverlässigkeit>
</dienstgüte>
<nutzungsgebühr>
<pro_aufruf>
<pro_zeiteinheit>
<pro_volumeneinheit>
<pauschaltarif>
</nutzungsgebühr>
<zusatzleistung>
</dynamische_information>
Die Herkunft der Informationen des Service-Schemas wird hier nochmals im Überblick dargestellt.
Realisierung & Fallstudie
39
1. Titel
o
businessService Name
Umgangssprachliche Beschreibung
businessService Description
2. Anbieter
businessEntity Name
o
Beschreibung
businessEntity Description
o
Kontaktdaten
businessEntity Contacts
o
URL
businessEntity discoveryURLs
3. Funktionale Eigenschaften
o
Implementierung

Service Description
businessService Description,
bindingTemplates, tModels

o
Service Interface
WSDL-Dateien
Marktsegment

Branche

Organisationsgröße

Standort/Region

Operative Variablen
<statische_information>

Abteilungsfunktion

Kundentechnologien
4. Nicht-funktionale Eigenschaften
o
o
o
o
Dienstgüte

Leistungsfähigkeit

Verfügbarkeit

Zuverlässigkeit

Integrität

Regelkonformität

Sicherheit
<dynamische_information>
<statische_information>
Nutzungsgebühren

Preis pro Aufruf

Preis pro Zeiteinheit

Preis pro Volumeneinheit

Pauschaltarife
<statische_information> / <dynamische_information>
Reputation

Reputation des Service Providers

Reputation des Services
neutrale Instanz
Nicht-funktionale Zusatzleistungen
<statische_information> / <dynamische_information>
40
Realisierung & Fallstudie
Die im Service-Schema enthaltenen Informationen können nicht komplett in der Service-Registry
gespeichert werden. Es wird eine zusätzliche Rolle im Dreieck der serviceorientierten Architektur
benötigt. Im Folgenden wird die existierende Architektur um die Rolle Domain Manager erweitert.
4.2 Realisierung Infrastruktur
Nachdem definiert wurde, wie das Service-Schema auszusehen hat und mit welchen Datenstrukturen
es realisiert werden soll, stellt sich als nächstes die Frage nach der Infrastruktur für die Speicherung
und Darstellung der Daten. An dieser Stelle werden lediglich Möglichkeiten der Realisierung skizziert,
die vorgestellten Komponenten sind nicht implementiert worden.
Es stehen die Rollen Service Consumer, Service Provider und Service Registry zur Verfügung.
Welche Rolle eignet sich am besten für die Speicherung und Darstellung der Daten des ServiceSchemas?
Im bereits vorgestellten Projekt E-Finance Lab (siehe Kapitel 2.4.1) registrieren sich Service Provider
mit ihren Services an einem Portal des Service Consumers. Die Speicherung der Daten erfolgt
demnach beim Service Consumer. Bei dieser Möglichkeit ist davon auszugehen, dass nur ein Bruchteil
der Service Provider, die einen für Service Consumer X interessanten Service anbieten, sich auch
wirklich an seinem Portal registrieren werden. Dem Service Consumer steht folglich nur eine stark
reduzierte Auswahl an Services zur Verfügung.
Eine weitere Möglichkeit ist die Speicherung der Daten direkt beim jeweiligen Service Provider. Jeder
Service Provider würde dann selbstständig die im Service-Schema definierten Informationen für
potenzielle Service Consumer verfügbar machen. Problematisch ist bei dieser Option die
wahrheitsgemäße Angabe der Service-Informationen. Die vom Service-Provider veröffentlichten
Informationen müssen nicht der Wahrheit entsprechen und es existiert keine neutrale Instanz, die dies
überwacht. Weiterhin kann sich der Informationsgehalt bei verschiedenen Service Providern
unterscheiden. Einige geben möglicherweise alle Informationen des Service-Schemas an, andere nur
Auszüge davon. Auf diese Weise schwindet der Nutzen des Service-Schemas.
Am ehesten könnte die Service Registry zur Speicherung und Darstellung der Daten dienen. Der weit
verbreitete UDDI-Standard sieht die vorgestellten Informationen jedoch nicht vor. Zudem kommen
immer häufiger private Service Registries zum Einsatz, die nur interne Services der eigenen
Organisation beinhalten. Ziel dieser Arbeit ist jedoch die universelle, über die Grenzen einer
Organisation hinausgehende Verfügbarkeit von Service-Informationen.
Daher wurde die Definition einer neuen Rolle entschieden. Ein Domain Manager soll alle Daten des
Service-Schemas beinhalten und mit zusätzlichen Funktionen integrieren. Der Domain Manager soll
über Prozesswissen innerhalb einer Anwendungsdomäne verfügen und so die Marktteilnehmer optimal
Realisierung & Fallstudie
41
bei der Suche von Services unterstützen. Er agiert dabei als electronic intermediary, d.h. als neutrale
Instanz am (elektronischen) Service Markt. Im Folgenden wird zunächst auf die Funktionen von
electronic intermediaries eingegangen. Im Anschluss wird genauer auf die Funktionsweise des
Domain Managers eingegangen.
4.2.1 Electronic Intermediaries
[BaiBak97] nennen die folgenden vier wichtige Funktionen von electronic intermediaries.
Um zu verhindern, dass jeder Käufer mit jedem Verkäufer einzeln über eine Transaktion verhandeln
muss, kann der intermediary das Angebot oder die Nachfrage von mehreren Verkäufern bzw. Käufern
aggregieren. Er kann Rahmenbedingungen festlegen, die für alle Transaktionen gelten. Eine solche
Aggregation kann Kostenvorteile durch reduzierte Transaktionskosten und Skaleneffekte ermöglichen
sowie Probleme durch die ungleiche Verhandlungsmacht von Käufern und Verkäufern reduzieren. Der
Amazon Marketplace [AMA] ist ein Beispiel für eine solche Aggregation. Hier werden die Angebote
von mehreren Verkäufern neben dem Angebot von Amazon selbst angezeigt, so dass der Käufer eine
größere Auswahl hat und den Artikel beim günstigsten Anbieter kaufen kann.
Weiterhin kann ein intermediary opportunistisches Verhalten der Marktteilnehmer verhindern, indem
er als agent of trust fungiert. Da der intermediary langfristig am Markt aktiv ist und möglichst viele
Nutzer erreichen will, hat er ein großes Interesse daran, dass Transaktionen für alle Teilnehmer
erfolgreich abgeschlossen werden. Selbst wenn die beiden Parteien einer Transaktion nur ein
einmaliges Geschäft abschließen, sind sie doch am erfolgreichen Ausgang interessiert, da sie mit dem
intermediary möglicherweise erneut in Kontakt kommen werden. Bei eBay [EBA] können Käufer und
Verkäufer nach einer erfolgreichen Transaktion den Transaktionspartner bewerten. Die erhaltenen
Bewertungen eines Käufers oder Verkäufers haben Einfluß auf die Auswahl der Transaktionspartner.
Ein intermediary kann Märkte vereinfachen, indem er die Prozess- und Koordinationskosten für
Transaktionen senkt. Der Informationstransfer zwischen den austauschenden Parteien kann wesentlich
effizienter von einem intermediary organisiert werden als dies die Parteien alleine machen könnten.
Um m Käufer mit n Verkäufern zu verbinden benötigt man in einem Markt ohne intermediary n*m
Verbindungen, während ein Markt mit intermediary mit n+m Verbindungen auskommt.
Zuletzt kann ein intermediary Käufern helfen, den passenden Verkäufer zu finden und umgekehrt. Er
kann also die Bedürfnisse von Käufern und Verkäufern abgleichen. Bietet ein intermediary
beispielsweise einen Mechanismus zum Preisvergleich an, kann er durch das Sammeln von
Informationen über erfolgte Transaktionen die Präferenzen von Käufern und Verkäufern erkennen.
42
4.2.2
Realisierung & Fallstudie
Domain Manager
Die folgende Abbildung zeigt die Erweiterung der klassischen serviceorientierten Architektur um die
neue Komponente Domain Manager. Dieser soll als Portal realisiert werden. Nach [BodSch03] stellt
ein Portal „eine feste Eintritts- und Rückkehrstelle“ im Internet dar, „um neue Kunden zu gewinnen
oder bestehende Kunden zu binden“. Portale integrieren „Inhalte, Dienste und Funktionen, die
benutzerspezifisch angepasst werden, um den Kunden einen personalisierten Zugang zum
Leistungsangebot eines Unternehmens zu schaffen“ [BodSch03]. Der Domain Manager soll für eine
ausgewählte Domäne möglichst umfangreiche Informationen über Prozesse und Services besitzen.
Die Interaktionen innerhalb der erweiterten serviceorientierten Architektur verändern sich gegenüber
der klassischen Architektur. Der Domain Manager ist von nun an bei der Suche der alleinige
Interaktionspartner des Service Consumers. Der Domain Manager stellt dem Service Consumer eine
genaue Beschreibung sämtlicher verfügbarer Services nach dem oben definierten Schema bereit. Der
Service Consumer kann so den für ihn am besten geeigneten Service finden und diesen, wie in der
alten Architektur, selbstständig aufrufen.
Merkmale veröffentlichen
Services
Informationen übermitteln
Service suchen
Domain Manager
Service
Registry
Service
Consumer
Serv
i ce v
eröf
fentl
i
ch e n
Service aufrufen
Service
Provider
Abbildung 16: Erweitertes Architekturmodell
Der Service Provider hat bei der Veröffentlichung seines Services von nun an zwei
Interaktionspartner. Er registriert wie früher seinen Service in einer Service Registry. Zusätzlich
registriert er sich auch beim Domain Manager und hinterlegt dort für seine Services die zusätzlichen
Informationen des Service-Schemas.
Realisierung & Fallstudie
43
Der Domain Manager erhält die Einträge von neuen Services von der Service Registry. Die
weiterführenden Informationen des Service-Schemas muss der Service Provider selbst beim Domain
Manager veröffentlichen.
Die Funktionsweise des Domain Managers wird im Folgenden einzeln für die fünf Phasen
Registrierung, Suche, Optimierung, Aufruf und Bewertung betrachtet.
Registrierung
Suche
Optimierung
Aufruf
Bewertung
Abbildung 17: Domain Manager Nutzungsphasen
4.2.2.1 Registrierungsphase
In dieser Phase registriert sich ein Service Provider mit seinen Services beim Domain Manager. In der
Registrierungsphase erhält der Domain Manager die grundlegenden Informationen zu Service Provider
und Services von der Service Registry. Der Service Provider übermittelt zusätzlich die statischen
Informationen seines Services. Die dynamischen Informationen werden erst in der Suchphase
übermittelt.
4.2.2.2 Suchphase
Der Domain Manager soll für die Suche nach einem Service vier Möglichkeiten bieten: eine ProzessSuche, eine Service-Suche, ein Service-Verzeichnis und einen Service-Vergleich.
Der Nutzer kann nach Prozessen suchen, die dem Domain Manager bekannt sind. Für die öffentliche
Verwaltung könnte der Domain Manager bspw. den Prozess „Flächennutzungsplanung“ und den
Teilprozess „Beteiligung TöB“ kennen. Für einen gegebenen Prozess kennt der Domain Manager die
für die Realisierung nötigen bzw. verfügbaren Services.
Der Domain-Manager bietet die Möglichkeit nach einzelnen Services unter Angabe von Informationen
aus dem Service-Schema zu suchen. Es kann also nach funktionalen und nicht-funktionalen
Eigenschaften gesucht werden. So können z.B. Services gesucht werden, die ein bestimmtes tModel
unterstützen (funktionale Eigenschaft), die eine bestimmte Nutzungsgebühr nicht überschreiten (nichtfunktionale Eigenschaft) oder die für eine bestimmte Branche oder Region gedacht sind
(Kontextinformation). Als Ergebnis soll das Service-Schema mit sämtlichen eingetragenen
Informationen angezeigt werden. Betrachtet der Service Consumer das Schema eines Service, besteht
die Möglichkeit, dass er sich Services mit gleichen Eigenschaften anzeigen lässt. Z.B. kann er sich
Services anzeigen lassen, die das gleiche tModel unterstützen oder vom gleichen Service Provider
stammen.
44
Realisierung & Fallstudie
Im Service-Verzeichnis sind die Services nach Marksegmenten, also nach Branchen, Regionen,
Abteilungsfunktionen etc. geordnet. Die Service-Consumer können durch diese Kategorien navigieren
und bekommen die enthaltenen Services angezeigt.
Hat ein Service-Consumer zwei oder mehr für ihn relevante Services gefunden, kann er dessen
Eigenschaften in einer Gegenüberstellung miteinander vergleichen. Dazu werden alle Eigenschaften
der ausgewählten Services in tabellarischer Form nebeneinander angezeigt, um so einen direkten
Vergleich zu ermöglichen. Auf diese Art können für Services mit gleichen funktionalen Eigenschaften
z.B. die nicht-funktionalen Eigenschaften oder zu zwei Services mit gleicher Dienstgüte die
Nutzungsgebühren verglichen werden.
4.2.2.3 Optimierungsphase
Die Service-Optimierung soll den Service Consumern die Auswahl eines Services erleichtern. Dazu
macht der Service Consumer Angaben über die gesuchte Funktionalität und seine Präferenzen bzgl.
nicht-funktionaler Eigenschaften. So könnte er beispielsweise besonderen Wert auf günstige
Nutzungsgebühren oder auch auf hohe Dienstgüteparameter legen.
Die Service-Optimierung läuft in zwei Schritten ab. Im ersten Schritt wird eine Suche über die vom
Service Consumer angefragte Funktionalität durchgeführt. Die Suche kann in unterschiedlicher
Granularität erfolgen, z.B. kann nach Segment, businessService Description, tModel, port, operation
etc. gesucht werden. Liefert diese Suche mehr als einen Service, startet die Optimierung der nichtfunktionalen Eigenschaften. Die aus dem ersten Schritt hervorgegangenen Services werden nach
einem Punktesystem bewertet. Die bestplatzierten Services in jeder Kategorie bekommen Punkte.
Diese Punkte werden in jeder Kategorie mit den Präferenzen des Service Consumers multipliziert und
schließlich addiert. Die Gesamtpunktzahl entscheidet über die Endplatzierung. Der Nutzer bekommt
die besten ermittelten Services in einer Liste angezeigt.
4.2.2.4 Aufrufphase
Hat der Service Consumer sich für einen Service entschieden, werden die Konditionen, d.h.
insbesondere die vereinbarte Dienstgüte und Nutzungsgebühren fixiert und beim Domain Manager
hinterlegt. Dieses Dokument sollte möglichst verbindlichen Charakter haben, um Missbrauch
vorzubeugen. Anschließend übermittelt der Domain Manager dem Service Consumer die
Informationen (UDDI-Schema) für den Aufruf der angeforderten Services. Der Service Consumer
ruft die Services, wie in der klassischen serviceorientierten Architektur, selbstständig auf.
4.2.2.5 Bewertungsphase
Nach Ausführung der Transaktionen können sich Service Consumer und Service Provider gegenseitig
bewerten. Die Informationen werden in Form des Bewertungs-Schemas an den Domain Manager
übermittelt.
Realisierung & Fallstudie
45
Im Folgenden werden die entwickelten Komponenten anhand einer Fallstudie aus der
Flächennutzungsplanung verifiziert.
4.3 Fallstudie Flächennutzungsplanung
Im Folgenden wird zunächst ein Überblick über den Prozess der Flächennutzungsplanung gegeben.
Ein
Teilschritt
aus
diesem
Prozess
soll
in
einem
Szenario
mit
Informations-
und
Kommunikationstechnologien unterstützt werden. Dazu wird das entwickelte Service-Schema und die
erweiterte serviceorientierte Architektur mit der Komponente Domain Manager herangezogen und die
Funktionsweise so an einem Beispiel verdeutlicht.
4.3.1 Prozessbeschreibung
Ein Flächennutzungsplan (FNP) bzw. vorbereitender Bauplan gibt einen Überblick über die geplante
Nutzung von Flächen innerhalb einer Gemeinde. Damit dient er als „strategische Grundlage für
Nutzungsentscheidungen und die räumliche Investitionssteuerung“ [FNP1]. Ein FNP stellt „die
Abgrenzung von bebauten und unbebauten Flächen; die Gliederung der Wohnbauflächen nach
baulicher Dichte; die Lage der gemischten, gewerblichen und Sonderbauflächen; Standorte und
Flächen für Einrichtungen des Gemeinbedarfs und der Ver- und Entsorgung (soweit von
übergeordneter Bedeutung bzw. größer 3 ha); die wichtigsten Verkehrstrassen und die Gliederung der
Freiflächen in Grün-, Wald- und Landwirtschaftsflächen“ dar [FNP1]. Der FNP besitzt einen
geringeren Detailgrad als ein Bebauungsplan. Er soll Übersichtscharakter haben und schließt daher
keine Grundstücke oder Flurstücksgrenzen ein. [nach FNP2]
Das Baugesetzbuch sieht vor, die Öffentlichkeit möglichst frühzeitig über die Inhalte der
Flächennutzungsplanung zu informieren und diese bei der Planung zu beteiligen. Dazu erhalten sie die
Gelegenheit eigene Stellungnahmen einzureichen. Neben den Bürgern werden auch Behörden und
Träger öffentlicher Belange (TöB) zu Stellungnahmen aufgefordert. Dieser Beteiligungsprozess soll
im Folgenden als Anwendungsszenario für die erweiterte serviceorientierte Architektur dienen. [nach
FNP2]
4.3.2 Szenario: Beteiligung der Träger öffentlicher Belange (TöB)
Eine Gemeinde will das Beteiligungsverfahren der Flächennutzungsplanung durch Informations- und
Kommunikationstechnologien unterstützen bzw. automatisieren. Die dafür benötigten SoftwareFunktionalitäten will die Gemeinde nicht selbst erstellen, sondern über Services von externen
Anbietern realisieren. Das Beteiligungsverfahren stellt [Küm04, S. 72-73] wie folgt dar.
„Der Gemeindevertreter (bzw. Mitarbeiter der Flächennutzungsplanung) erstellt einen neuen
Flächennutzungsplan. Nach einer möglichen nachträglichen Bearbeitung wird der FNP aktiviert, d. h.
46
Realisierung & Fallstudie
er kann sowohl von der Gemeinde als auch von den TÖB öffentlich eingesehen werden. Die TÖB
werden gesondert per E-Mail über den neuen FNP informiert. Bis zum Ende der Einsichtnahme
können die TÖB ihre Stellungnahmen und, falls erforderlich, einen Antrag auf Verlängerung der
Einsichtnahme stellen. Nach dem Ende der Einsichtnahme kann der Gemeindevertreter alle von den
TÖB verfassten Anträge und Stellungnahmen ansehen und entscheiden, ob das Ende der Einsichtname
verlängert wird oder ob die Einsichtname beendet werden soll.“
Die Gemeinde übernimmt die Rolle des Service Consumers. Sie wendet sich an einen Domain
Manager, um dort die für den Prozess benötigten Services zu finden. Dazu wird sie nicht einzelne
Services, sondern die abzubildenden Prozesse beim Domain Manager anfragen. Diese kennt der
Domain Manager und kann so die zur Unterstützung des Prozesses benötigten Funktionalitäten und
Service-Typen identifizieren, welche zu einem orchestriertem Service zusammengesetzt werden
können.
Bei der Suche nach geeigneten Services sind die folgenden Merkmale entscheidend. Zunächst spielt
die Anzahl und Art der TöB eine Rolle. Beides hängt von der Größe der Gemeinde ab. Gemeinden
lassen sich in drei Kategorien einteilen: das Grundzentrum mit weniger als 50.000 Einwohnern, das
Mittelzentrum mit 50.000 bis 100.000 Einwohnern und das Oberzentrum mit mehr als 100.000
Einwohnern. Die Art der TöB unterscheidet sich weiterhin nach regionalen Gegebenheiten, z.B.
Flüsse, Berge, Tourismus, Verkehr (Autobahnen, Eisenbahnen, Flughäfen). Je nach Ausprägung gibt
es unterschiedliche TöB, die zu benachrichtigen sind. In Abhängigkeit des erwarteten Datenvolumens
sind die technischen Charakteristika der Services zu berücksichtigen. In einer großen Gemeinde mit
vielen TöB und möglicherweise vielen Änderungsvorhaben ist das Datenvolumen größer als bei einer
kleinen Gemeinde. Die Services sollten so ausgewählt werden, dass die Systeme auch zu
Spitzenlastzeiten nicht überfordert sind. Weiterhin können sich die Gemeinden hinsichtlich eigener ITKompetenz unterscheiden. Große Gemeinden besitzen möglicherweise eigene IT-Spezialisten, die sich
um den korrekten Betrieb der Services kümmern können, während kleine Gemeinden möglicherweise
Unterstützung in diesen Bereichen benötigen. Entscheidend sind demnach auch Support-Leistungen
der Service Provider wie z.B. Techniker vor Ort, eine Hotline etc.
4.3.3
Ablaufbeschreibung
An dieser Stelle wird der Ablauf der Suche von geeigneten Services und deren Optimierung
beschrieben. Auf die weiteren Phasen wird nicht im Detail eingegangen.
4.3.3.1 Suchphase
Da der Gemeinde nicht bekannt ist, welche Funktionalitäten sie für die Realisierung der
Flächennutzungsplanung benötigt, startet sie zunächst eine Suche über das Marktsegment. Dazu macht
sie Angaben zur Branche (öffentliche Verwaltung), Organisationsgröße (Verwaltung mit 10.000
Realisierung & Fallstudie
47
Angestellten), Standort/Region (Rheinland-Pfalz), Abteilungsfunktion (Regionalplanung), und
Technologien (MS Windows, MS Office, Internet).
Der Domain Manager ermittelt für die Marktsegmentinformationen eine Liste zur Verfügung
stehender Prozesse. Dort findet sich auch der Prozess „Flächennutzungsplanung“ und als Sub-Prozess
„Beteiligung TöB“. Zu diesem Prozess stehen die folgenden Services zur Verfügung:
1. TöB-Service
Dieser Service liefert wahlweise für eine Gemeinde oder eine Postleitzahl und einen Kilometerradius
die Liste aller TöB.
2. Upload-Service
Dieser Service wird von einem Gemeindevertreter verwendet, um einen neuen Flächennutzungsplan
im Internet verfügbar zu machen. Zu dem Flächennutzungsplan gehören der Titel und eine
Beschreibung sowie eventuell weitere Gutachten, Statistiken oder sonstige Informationen, die für die
an der Planung beteiligten Akteure von Interesse sind. Der Service speichert diese Datei(en) auf einem
Server, der über das Internet erreichbar ist. Für den Zugriff auf die Dateien sind vom
Gemeindevertreter festgelegte Benutzernamen und Passwörter nötig.
3. Inform-Service
Der
Inform-Service
benachrichtigt
die
betroffenen
Akteure
darüber,
dass
ein
neuer
Flächennutzungsplan erstellt wurde. Auch dieser Service wird vom Gemeindevertreter angestoßen.
Die benachrichtigten TöB können sich entscheiden, ob sie den Flächennutzungsplan online einsehen
möchten oder ob sie die Dokumente in Papierform erhalten möchten.
4. Account-Service
Wenn die TöB den Flächennutzungsplan online einsehen möchten, müssen sie sich mit dem AccountService in Verbindung setzen. Dieser teilt ihnen ihre Login-Daten, d.h. Benutzernamen und Passwort,
mit.
5. Print-Service
Möchten die TöB die Dokumente in Papierform erhalten, müssen sie den Print-Service anstoßen, der
den Flächennutzungsplan und die dazugehörigen Informationen ausdruckt.
6. Reminder-Service
Der Reminder-Service wird vom Gemeindevertreter angestoßen und soll die betroffenen Akteure eine
Woche vor Ablauf der Frist an die Stellungnahmen und Anträge erinnern.
Die oben genannten sechs Services reichen aus, um die TöB-Beteiligung innerhalb der
Flächennutzungsplanung zu automatisieren.
48
Realisierung & Fallstudie
4.3.3.2 Optimierungsphase
Der Domain Manager muss in diesem Schritt für jeden der sechs benötigten Services den optimalen
Anbieter finden. Dazu benötigt er Informationen über die Präferenzen der Gemeinde hinsichtlich
funktionaler und nicht-funktionaler Eigenschaften. Die Präferenzen der Gemeinde sind wie folgt:
1. Hohe Verfügbarkeit (x4)
2. Hohe Reputation des Service Providers (x3)
3. Günstige Gebühren (x2)
Die Auswahl des optimalen Services wird für zwei der sechs Services beispielhaft dargestellt. Für die
beiden Services TöB-Liste und Upload-Service stehen in diesem Beispiel drei Anbieter zur
Verfügung. Die Ausprägungen der Service-Eigenschaften Verfügbarkeit, Reputation und Gebühren
sind in den folgenden Tabellen dargestellt. Die jeweils beste Ausprägung in einer Kategorie ist fett
markiert. Der beste Service innerhalb einer Kategorie bekommt zwei Punkte, der zweitbeste bekommt
einen Punkt und der letzte keinen Punkt. Wenn mehrere Services gleich gut sind, bekommen beide die
gleiche Punktzahl. Multipliziert mit den Präferenzen der Gemeinde ergibt sich die Endpunktzahl und
somit der optimale Service.
Service TöB-Liste
Serviceeigenschaften
TöB-Liste 1
99,99%
Verfügbarkeit
(2 Punkte x 4
= 8 Punkte)
Reputation
(Max. = 10)
99%
95%
(1 Punkt)
(0 Punkte)
8,9
(1 Punkt x 3
(2 Punkte x 3
= 3 Punkte)
= 6 Punkte)
(1 Punkt x 2
= 2 Punkte)
Gesamtpunkte
TöB-Liste 3
8,5
2€/Eintrag
Gebühren
TöB-Liste 2
13
3€/Eintrag
(0 Punkte)
7
Tabelle 1: Service TöB-Liste
„TöB-Liste 1“ wird der Gemeinde als optimaler Service vorgeschlagen.
7,2
(0 Punkte)
1,50€/Eintrag
(2 Punkte x 2
= 4 Punkte)
4
Realisierung & Fallstudie
49
Upload-Service
Serviceeigenschaften
Verfügbarkeit
Upload-Service 1
Upload-Service 2
Upload-Service 3
99 %
99,999 %
99 %
(1 Punkt x 4
(2 Punkte x 4
(1 Punkt x 4
= 4 Punkte)
= 8 Punkte)
= 4 Punkte)
8,3
8,0
(2 Punkte x 3
(1 Punkt x 3
= 6 Punkte)
= 3 Punkte)
Reputation
7,7
(Max. = 10)
(0 Punkte)
10 € / GB
Gebühren
(1 Punkt x 2
= 2 Punkte)
Gesamtpunkte
15 € / GB
(0 Punkte)
6
Tabelle 2: Upload-Service
„Upload-Service 2“ wird als optimaler Service vorgeschlagen.
14
8 € / GB
(2 Punkte x 2
= 4 Punkte)
11
50
Zusammenfassung
5. Zusammenfassung
Die effektive Ausführung und Unterstützung von Geschäftsprozessen kann mit vielfältigen Systemen
unterstützt werden. In der vorliegenden Arbeit wurde die Verknüpfung der Workflowtechnologie mit
serviceorientierte Architekturen untersucht, um so den bereits vielfach eingesetzten WorkflowManagement-Systemen zusätzliche Effektivität und Flexibilität zu verleihen. Als entscheidendes
Problem wurde in diesem Zusammenhang ein Mangel an Informationen identifiziert. Services werden
nicht umfassend genug beschrieben, um diese in Workflows integrieren zu können.
Das entwickelte Service-Schema enthält ausführliche Informationen über funktionale und nichtfunktionale Eigenschaften eines Service, über interne und externe Prozesse sowie über Kosten,
Differenzierungsmerkmale und Segmente des Service Providers. Diese Informationen stellen dem
Service Consumer eine solide Entscheidungsgrundlage zur Verfügung und ermöglichen es den Service
Providern, sich von der Konkurrenz abzuheben.
Zur Speicherung und Darstellung der Daten wurde die Komponente Domain Manager konzipiert.
Dieser tritt an die Stelle der Service Registry ohne diese komplett zu ersetzen, und stellt Informationen
über Service Provider und Services für eine Domäne zur Verfügung. Der Domain Manager bietet die
Möglichkeit zur Suche von Services und automatischen Optimierung nicht-funktionaler Eigenschaften
nach den Präferenzen des Service Consumers.
Die Funktionsweise des Service-Schemas und des Domain Managers wurden im Rahmen einer
Fallstudie an einem Prozess aus der Flächennutzungsplanung veranschaulicht.
Die Komponente Domain Manager und das Service-Schema wurden konzeptuell entwickelt. Weitere
Arbeiten könnten sich mit der Implementierung der vorgestellten Komponenten beschäftigen. Es
könnte z.B. ein Domain Manager für Services der Fakultäten und Lehrstühle der Technischen
Universität Kaiserslautern aufgesetzt werden. Dieser könnte zunächst zur universitätsinternen Nutzung
vorgesehen werden und an späterer Stelle möglicherweise für universitätsexterne Nutzer freigegeben
werden.
Langfristig ist eine weitere Verbreitung von serviceorientierten Architekturen zu erwarten. Dazu
müssen vor allem die Zuverlässigkeit serviceorientierter Architekturen und die Möglichkeiten zur
Integration in bestehende Systeme, wie z.B. Workflow-Management-Systeme, verbessert werden.
Literaturverzeichnis
51
Literaturverzeichnis
[AalHee92]
W. van der Aalst; K. van Hee.: Workflow Management – Models, Methods,
and Systems, The MIT Press Cambridge, Massachusetts London, England,
2002
[AMA]
www.amazon.de
[BaiBak97]
J. P. Bailey; Y. Bakos: An Exploratory Study of the Emerging Role of
Electronic Intermediaries. International Journal of Electronic Commerce, Vol.
1, No. 3, S. 7 – 20, 1997.
[BecMüh99]
J. Becker; M. zur Mühlen: Rocks, Stones and Sand – Zur Granularität von
Komponenten
in
Workflowmanagementsystemen,
In:
IM
Information
Management & Consulting. Saarbrücken, 17 (1999) 2, S. 57-67.
[BHMS03]
R. Berbner; O. Heckmann; A. Mauthe; R. Steinmetz: Eine Dienstgüte
unterstützende
Webservice-Architektur
für
flexible
Geschäftsprozesse.
Wirtschaftsinformatik 47 (2005) 4, S. 268 – 277.
[BHS05]
Berbner, Rainer; Heckmann, Oliver; Steinmetz, Ralf: An Architecture for a
QoS driven composition of Web Service based Workflows. Networking and
Electronic Commerce Research Conference (NAEC 2005), October 6-9, 2005,
Riva Del Garda, Italy.
[Bli02]
Bliemel, Friedhelm: Marktorientierte Strategische Planung als Vorbereitung
zum Erfolg. Vorlesungsskript Marketing WS 2002/2003.
[BodSch03]
F. Bodendorf; A. Schobert: Integration von Web-Services in ein
Kundenportal. In: HMD 234 – Praxis der Wirtschaftsinformatik, 2003.
[BonSha83]
T. P. Bonoma; B. P. Shapiro: Segmenting the Industrial Market. Lexington
Books, 1983.
[CCDS03]
M. Castellanos; F. Casati; U. Dayal; M-C. Shan: Intelligent Management of
SLAs for Composite Web Services. In: Databases in Networked Information
Systems, S. 158 – 171, 2003.
[CCMW01]
E. Christensen; F. Curbera; G. Meredith; S. Weerawarana: Web Services
Description Language (WSDL) 1.1. W3C Note, [online], 2001, verfügbar im
World Wide Web: http://www.w3.org/TR/wsdl
52
[Cer02]
Literaturverzeichnis
E. Cerami: Web Services Essentials – Distributed Applications with XMLRPC, SOAP, UDDI & WSDL. O’Reilly, 2002.
[CZ06]
Service Levels lassen das Business außen vor. Computer Zeitung, Nr. 45,
6.11.2006.
[EBA]
www.ebay.de
[Fau04]
Faust, Nicole: Modellierung und Design von virtuellen Organisationen in
Grid-Architekturen. 2004
[FNP1]
Flächennutzungsplan Berlin. [online], http://fbinter.stadt-berlin.de/fnp/
[FNP2]
Wikipedia:
Stichwort
“Flächennutzungsplan”.
[online]
http://de.wikipedia.org/wiki/Fl%C3%A4chennutzungsplan
[GKG03]
D. Gouscos; M. Kalikakis; P. Georgiadis: An Approach to Modeling
Webservice QoS and Provision Price. In: Proceedings of the 4th International
Conference on Web Information Systems Engineering Workshops (WISEW
2003). Rom, Italien 2003, S. 121–130.
[Gra02]
R. M. Grant: Contemporary Strategy Analysis, concepts, Techniques,
Applications. Blackwell Publishers Inc, 2002.
[Gri98]
F. Griffel et. al.: Electronic Contracting with COSMOS – How to Establish,
Negotiate and Execute Electronic Contracts on the Internet. In: Enterprise
Distributed Object Computing Workshop, 1998. EDOC '98. Proceedings (La
Jolla, CA, USA). Nov. 1998, S. 46 – 55.
[HaaBro04]
H. Haas; A. Brown: Web Services Glossary. W3C Working Group Note,
[online], 2004, verfügbar im World Wide Web: http://www.w3.org/TR/wsgloss/
[Hof03]
O. Hofmann: Web-Services in serviceorientierten IT-Architekturkonzepten. In:
HMD 234 – Praxis der Wirtschaftsinformatik, 2003.
[Hol95]
D. Hollingsworth: Workflow Management Coalition - The Workflow
Reference Model, Issue 1.1, [online], 1995, verfügbar im World Wide Web:
http://www.wfmc.org/standards/docs/tc003v11.pdf
[Hol99]
D. Hollingsworth: Workflow Management Coalition - Terminology &
Glossary, [online], 1999, verfügbar im World Wide Web:
http://www.wfmc.org/standards/docs/TC-1011_term_glossary_v3.pdf
Literaturverzeichnis
[Jab97]
53
S. Jablonski et al.: Workflow-Management – Entwicklung von Anwendungen
und Systemen, dpunkt-Verlag, 1997.
[KosLey04]
D. Kossmann; F. Leymann: Web Services. In: Informatik Spektrum 27(2) S.
117-128 (2004), verfügbar im World Wide Web:
http://www.dbis.ethz.ch/research/publications/WebServices.pdf
[Kot94]
Kotler, Philip; Marketing Management. Analysis, Planning, Implementation,
and Control. 8th edition. Prentice Hall. Englewood Cliffs, NJ, 1994.
[KotBli01]
P. Kotler; F. Bliemel: Marketing-Management. Schäffer-Poeschel Verlag,
2001.
[Küm04]
A. Kümpel: Strategien zur Prozessorchestrierung und Workflow-Integration
in Web-Applikationen. Diplomarbeit Fachbereich Informatik, TU
Kaiserslautern, Dezember 2004.
[Küs03]
M. W. Küster: Web-Services – Versprechen und Realität. In: HMD 234 –
Praxis der Wirtschaftsinformatik, 2003.
[Mac06]
C. MacKenzie et al.: Reference Model for Service Oriented Architecture 1.0 –
OASIS Standard. [online], 2006, verfügbar im World Wide Web:
http://docs.oasis-open.org/soa-rm/v1.0/
[ManNag02]
A. Mani; A. Nagarajan: Understanding quality of service for Web services.
[online], 2002, developerWorks – IBM’s Resource for developers, verfügbar
im World Wide Web: http://www-128.ibm.com/developerworks/library/wsquality.html
[Mat03]
Mattern, Thomas: Web-Services als Basis neuer betriebswirtschaftlicher
Konzepte. In: HMD 234 – Praxis der Wirtschaftsinformatik, S. 34 – 41, 2003.
[MQG95]
H. Mintzberg; J. B. Quinn; S. N. Ghoshal: Strategy Process: Concepts,
Context and Cases. Prentice Hall, 1995.
[Oas04]
OASIS - Organization for the Advancement of Structured Information
Systems: Introduction to UDDI: Important Features and Functional
Concepts. [online], 2004, verfügbar im World Wide Web:
http://uddi.org/pubs/uddi-tech-wp.pdf
[PapHeu]
M. P. Papazoglou; W. J. van den Heuvel: Service-Oriented Computing: Stateof-the-Art and Open Research Issues. [online], Tilburg University. verfügbar
54
Literaturverzeichnis
im World Wide Web: https://doc.telin.nl/dscgi/ds.py/Get/File40060/UvT_SOC_research_agenda.pdf
[PFW03]
G. Piccinelli; A. Finkelstein; S. L. Williams: Service-Oriented Workflows: The
DySCo Framework. In: Euromicro Conference, 2003, Proceedings, S. 291 –
297.
[Por85]
M. E. Porter: Competitive Advantage: Creating and Sustaining Superior
Performance. Free Press, 1985.
[PZL03]
G. Piccinelli; C. Zirpins; W. Lamersdorf: The FRESCO Framework – An
Overview. In: Applications and the Internet Workshops, 2003, Proceedings, S.
120 – 124.
[Ran03]
S. Ran: A Model for Web Services Discovery With QoS. In: ACM SIGecom
Exchanges, Vol. 4, Issue 1, 2003, S. 1 – 10. verfügbar im World Wide Web:
http://www.acm.org/sigs/sigecom/exchanges/volume_4_(03)/4.1-Ran.pdf
[RBR91]
R. Reeder; E. G. Brierty; B. H. Reeder: Industrial Marketing. Analysis,
Planning and Control. 2nd edition. Prentice Hall. Englewood Cliffs, NJ, 1991
[Rei03]
H. A. Reijers: Design and Control of Workflow Processes, Springer-Verlag
Berlin, Heidelberg 2003.
[RHS05]
J. P. Richter; H. Haller; P. Schrey: Serviceorientierte Architektur. In:
Informatik Spektrum, Vol. 28 (5), 2005.
[ZirLam04]
Zirpins, C.; Lamersdorf, W.: Dienstorientierte Kooperationsmuster in
servicebasierten Grids. In: PIK – Praxis der Informationsverarbeitung und
Kommunikation. Vol. 27 (3), 2004, S. 152 – 158, verfügbar im World Wide
Web: http://vsys-www.informatik.unihamburg.de/getDoc.php/publications/214/zl-dksg-04.pdf
Abbildungsverzeichnis
55
Abbildungsverzeichnis
Abbildung 1: Horizontales Design ........................................................................................................ 10
Abbildung 2: Workflow-Management-System [WfMC95, S. 9] .......................................................... 12
Abbildung 3: Allgemeine Struktur eines Workflow-Management-Systems [nach WfMC95, S. 13] ... 13
Abbildung 4: Workflow-Granularität.................................................................................................... 15
Abbildung 5: Allgemeines Architekturmodell ...................................................................................... 17
Abbildung 6: UDDI-Datenmodell ......................................................................................................... 19
Abbildung 7: businessEntity-Datentyp ................................................................................................. 20
Abbildung 8: businessService-Datentyp ............................................................................................... 20
Abbildung 9: bindingTemplate-Datentyp ............................................................................................. 21
Abbildung 10: tModel-Datentyp ........................................................................................................... 21
Abbildung 11: Web Services Technology Stack [KosLey04] .............................................................. 23
Abbildung 12: COSMOS Service ......................................................................................................... 27
Abbildung 13: Generische Wettbewerbsstrategien nach Porter ............................................................ 30
Abbildung 14: Serviceorientierter Workflow........................................................................................ 31
Abbildung 15: Konzeptionelles Servicemodell ..................................................................................... 34
Abbildung 16: Erweitertes Architekturmodell ...................................................................................... 42
Abbildung 17: Domain Manager Nutzungsphasen ............................................................................... 43
56
Tabellenverzeichnis
Tabellenverzeichnis
Tabelle 1: Service TöB-Liste................................................................................................................. 48
Tabelle 2: Upload-Service ..................................................................................................................... 49