proof of concept für das service design studio und supply ... · seite v Über dieses dokument...
TRANSCRIPT
Seite 1
Verbundprojekt Service Design Studio
Proof of Concept für das Service Design Studio und Supply Chain Execution Version: 1.0
Arbeitspaket: Arbeitspaket 1: Service Design Environment
Autor(en): Dr.-Ing. Heiko Gsell, Fraunhofer ISST
Seite iii
Partner im Verbundvorhaben Service Design Studio Fraunhofer ISST Orga Systems SOPERA tarent
Seite v
Über dieses Dokument
Dieses Dokument beinhaltet ein Proof of Concept für das Service Design Studio (SDS). Das SDS
ist ein Web-basiertes Werkzeug zur Anreicherung existierender Logistik-IT-Dienste um Spezifikati-
onen nicht-funktionaler Eigenschaften. Solche nicht-funktionalen Eigenschaften können z.B. die
Absicherung (d.h. Authentisierung und Autorisierung), den jeweiligen Service Level oder die Ab-
rechnung der Dienstnutzung betreffen. Mit dem SDS können somit ganzheitliche IT-
Dienstbeschreibungen in vereinheitlichter Form erzeugt werden. Die anschließend zur Laufzeit ei-
nes so angereicherten IT-Dienstes zusätzlich zur Verfügung stehenden Informationen können dann
von Endkunden bei der Suche nach geeigneten IT-Diensten berücksichtigt werden.
Um die Funktionsweise des SDS nachzuweisen, wird in diesem Dokument zunächst ein Bei-
spielszenario aus dem Verbundprojekt Supply Chain Execution beschrieben. Dieses Szenario wird
in seine Prozesselemente zerlegt und analysiert. Mit den Analysen werden die für das Proof of
Concept relevanten Serviceaufrufe identifiziert und mittels SOA ML dokumentiert. Auf Basis der
Serviceaufrufe werden die Methodenaufrufe, die zum Anstoßen der Mehrwertdienste erforderlich
sind, ermittelt und in einem Sequenzdiagramm beschrieben. Das Diagramm visualisiert die Kom-
munikation zwischen einem Simulationsservice und den an diesen Service anzubindenden Mehr-
wertdiensten. Der Simulationsservice beschreibt für den Fall, dass im Zuge einer Qualitätskontrolle
Fehler bzw. die Nicht-Erfüllung von Qualitätsstandards von Bauteilen bei der Möbelmontage identi-
fiziert werden, die erforderlichen Nacharbeiten. Neben der Darstellung der notwendigen Demonta-
ge- und Montageschritte prüft der Service die Verfügbarkeit der ersatzweise benötigten Bauteile
sowie deren Bereitstellungszeit; er erlaubt eine Voraussage über den Aufwand, der für die Beseiti-
gung der Qualitätsmängel einzusetzen ist. Der Simulationsservice stellt somit ein wesentliches in-
formationstechnisches Element im Prozess der Möbelproduktion dar.
Zum Abschluss des vorliegenden Proof of Concept werden die Schnittstellen der Mehrwertdienste
zum Simulationsservice und zu weiteren Systemen auf der jeweiligen Cloud-Plattform visualisiert
und die Nutzung des Service Design Studios zur Anbindung dieser Mehrwertdienste an den Simula-
tionsservice dargestellt. Mit diesen Darstellungen ist die Funktionalität des Service Design Studios
entsprechend der Zielsetzung seiner Entwicklung nachgewiesen.
Seite vii
Inhaltsverzeichnis
ÜBER DIESES DOKUMENT ......................................................................................................................... V
INHALTSVERZEICHNIS ............................................................................................................................. VII
1 EINLEITUNG ..........................................................................................................................................9
1.1 ZWECK DES DOKUMENTS ...............................................................................................................9
1.2 ZIELE UND UMFANG DES PROOF OF CONCEPTS FÜR DAS SDS UND FÜR SCE ......................................9
1.3 VERWEISE AUF SONSTIGE RESSOURCEN UND QUELLEN .....................................................................9
1.4 ERLÄUTERUNGEN ZU BEGRIFFEN UND/ODER ABKÜRZUNGEN ..............................................................9
2 BEISPIELSZENARIO ........................................................................................................................... 11
2.1 GESCHÄFTSPROZESS................................................................................................................... 11
2.2 PROZESSABLAUF ......................................................................................................................... 12
2.3 ABLAUF DER SERVICEAUFRUFE FÜR DIE FUNKTIONALEN SERVICES ................................................... 14
3 EINBETTUNG DER MEHRWERTDIENSTE IN DAS GESAMTSYSTEM ............................................... 18
3.1 SERVICEAUFRUFE UND ÜBERTRAGENE INFORMATIONEN................................................................... 18
3.2 BESCHREIBUNG UND FUNKTION DER HINZUZUFÜGENDEN MEHRWERTDIENSTE.................................... 20
3.3 ABLAUF DER SERVICEAUFRUFE FÜR DIE MEHRWERTDIENSTE ........................................................... 22
3.4 SYSTEMARCHITEKTUR .................................................................................................................. 24
4 MODELLIERUNG MIT DEM SERVICE DESIGN STUDIO ..................................................................... 26
4.1 KONZEPT DES SERVICE DESIGN STUDIOS ...................................................................................... 26
4.2 NUTZUNG DES SERVICE DESIGN STUDIOS ...................................................................................... 27
4.3 ASPEKTE .................................................................................................................................... 29
4.4 ABGLEICH DES BEISPIELSZENARIOS MIT DEM SDS-KONZEPT............................................................ 31
5 FALLBEISPIEL .................................................................................................................................... 34
5.1 RAHMENBEDINGUNGEN FÜR DIE AUSGESTALTUNG DER ASPEKTE ...................................................... 34
5.2 MODELLIERUNG EINES ABRECHNUNGSASPEKTS .............................................................................. 35
5.3 MODELLIERUNG EINES SICHERHEITSASPEKTS ................................................................................. 37
6 ZUSAMMENFASSUNG UND AUSBLICK............................................................................................. 39
7 ABBILDUNGS- UND TABELLENVERZEICHNIS ................................................................................. 40
7.1 ABBILDUNGSVERZEICHNIS ............................................................................................................ 40
7.2 TABELLENVERZEICHNIS ................................................................................................................ 40
8 LITERATURVERZEICHNIS .................................................................................................................. 41
Seite 9
1 Einleitung
1.1 Zweck des Dokuments Dieses Dokument beschreibt ein Proof of Concept für das Service Design Studio (SDS) sowie für
Supply Chain Execution. Dazu werden die Serviceaufrufe an ein Assistenzsystem aus unterschied-
lichen Kontexten und Domänen beschrieben, sodass daran aufgezeigt werden kann, was der jewei-
lige Service macht und welche Daten dieser Service für seine Ausführung benötigt. Die Untersu-
chungen und Darstellungen erfolgen entlang eines Beispiels aus der Qualitätskontrolle Endmontage
in einem Geschäftsprozess zur Möbelherstellung. In diesem Beispiel wird eine Aktivität in dem ge-
nannten Prozess fachlich ausmodelliert.
1.2 Ziele und Umfang des Proof of Concepts für das SDS und für SCE Das wesentliche Ziel des Proof of Concept liegt im Nachweis der optimalen Aufgabenerfüllung ei-
nes mittels des SDS um nicht-funktionale Eigenschaften angereicherten Services und damit im
Nachweis der komfortablen Abrechenbarkeit dieses Services, seiner hohen Sicherheit sowie der
verlässlichen Überwachung und Einhaltung der für seine Ausführung festgelegten Service Level
Agreements im Zusammenspiel mit den jeweils dahinter liegenden Systemen. Es soll damit aufge-
zeigt werden, welche Elemente das Service Design Studio an einem Service modelliert, wie es
mögliche architektonische Rahmenbedingen berücksichtigen kann (kundenlokale vs. Web-basierte
Systeme) und damit die Steuerung und Lenkung vor dem Hintergrund seiner Kern-Designfelder
Abrechnung, Sicherheit und SLA realisiert. Ziel ist es somit, entlang des Beispiels aufzuzeigen, was
ein Service-Entwickler wie mit dem Service Design Studio modellieren kann.
1.3 Verweise auf sonstige Ressourcen und Quellen Die Dokumente, die als Input bzw. begleitende Unterlagen für das vorliegende Dokument dienen,
sind nachfolgend aufgelistet:
Dokument Verbundvorhaben Service Design Studio: Konzeptpapier zum Service Design Studio, Version 1.0, Arbeitspaket 1 Service Design Environment, S. Steinbuß
Präsentation EffizienzCluster LogistikRuhr: Supply Chain Execution, 11.07.2011, G. Yüzgülec
Präsentation EffizienzCluster LogistikRuhr: Service Design Studio, 11.07.2011, S. Steinbuß
Dokument Verbundvorhaben Service Design Studio: Glossary
1.4 Erläuterungen zu Begriffen und/oder Abkürzungen Der Begriff, die im vorliegenden Proof of Concept von großer Bedeutung und wiederholt genutzt
wird ist, ist im Projekt-Glossar definiert. Dabei handelt es sich um den Begriff Aspekt, dessen Defini-
tion sich wie folgt darstellt [Gss11, S. 2 f.]:
Ein Aspekt beschreibt eine nichtfunktionale Eigenschaft eines funktionalen SOA-Services. Aspekte
Seite 10
können (a) zur Filterung bei der Suche nach geeigneten SOA-Services oder (b) zur Gewährleistung
der Einhaltung nichtfunktionaler Eigenschaften beim Aufruf von Services genutzt werden. Ein As-
pekt definiert einen konfigurierbaren Typ für spezifische nichtfunktionale Eigenschaften. Ist ein As-
pekt komplett konfiguriert (d.h. alle Eigenschaften bzw. Parameter des Aspekts sind mit Werten
versehen), und wird an einen Service gebunden, so wird eine Aspekt-Instanz erzeugt. Genauer
gesagt können Aspekt-Instanzen nicht nur an einen Service, sondern auch direkt an einzelne Ser-
vice-Operation gebunden werden. Zusätzlich gibt es noch Aspekt-Template: In einem Aspekt-
Template können einige oder alle Parameter des zu Grunde liegenden Aspekts mit sinnvollen Wer-
ten vorbelegt sein; das Aspekt-Template ist im Gegensatz zu einer Aspekt-Instanz jedoch noch
nicht an einen Service oder eine Service-Operation gebunden. Beispiel: Authentisierung, Abrech-
nungsmodell, Kosten.
Seite 11
2 Beispielszenario
Für das Proof of Concept des Service Design Studios wird ein Beispielszenario aus dem Verbund-
projekt Supply Chain Execution herangezogen, das teilweise durch informationstechnische Ser-
vices gesteuert wird. Diese Services werden durch logistische Assistenzsysteme (LAS) der SCE
(Supply Chain Execution) ausgeführt, welche die Aufgaben Zustandserfassung & Bewertung, Ent-
scheidungsunterstützung und Entscheidungsdurchführung wahrnehmen. Bei den LAS handelt es
sich um IT-Systeme oder Funktionen, die eine effiziente Steuerung logistischer oder produktions-
technischer Netzwerke unterstützen. Dazu werden bspw. aktuelle Sensordaten genutzt, die in der
SCE-Infrastruktur erzeugt, durch einen sog. Premiumservice „Sensordatenhandling“ erfasst und
durch diesen Service an ein LAS übermittelt werden. Ggf. werden die erfassten Sensordaten er-
gänzend in ein Verhältnis zu Daten aus Backend-Systemen gesetzt. Das Spektrum der LAS reicht
von der reinen Anzeige der Informationen bis hin zur Ausführung von Aktionen (Steuerung) auf IT-
Backendsystemen oder auf realen Objekten (Transportsysteme, Maschinen, etc.). Sie können mit
einem Anwender über ein User-Interface kommunizieren oder als autonome Systeme in eine IT-
Infrastruktur integriert werden.
2.1 Geschäftsprozess Die IT-Services, die durch das SDS erweitert werden, werden zur Unterstützung bzw. Durchführung
definierter Aktivitäten eines Geschäftsprozesses genutzt. Dies gilt auch für das Beispielszenario,
das die Supply Chain von einem Sägewerk über die Möbelherstellung bis hin zur Auslieferung der
Möbel an den Kunden abbildet. Im Fokus des Beispielszenarios steht die Qualitätskontrolle inner-
halb der Endmontage im Prozess Möbelherstellung (vgl. Abbildung 1). Für diese Aktivität wird das
SCE-Beispiel abgebildet.
Abbildung 1 SCE-Beispiel Qualitätskontrolle Endmontage
Seite 12
Der Geschäftsprozess Möbelherstellung setzt sich aus neun Teilprozessen zusammen, von denen
einer die Montage ist. Der Teilprozess Montage lässt sich wiederum in weitere Teilprozesse unter-
gliedern. Die Qualitätskontrolle wird mehrfach im Montageprozess durchgeführt (vgl. Abbildung 1).
Diese Aktivität wird durch den Premiumservice „Sensordatenhandling“ informationstechnisch unter-
stützt. Der Premiumservice nimmt Daten des Oberflächenprofils des montierten Bauteils über einen
Sensor auf. Auch werden über den Sensor die folgenden weiteren Informationen erfasst:
- die Qualitätskennzahl (Oberflächenbewertung und Vollständigkeit),
- Ort und Zeit,
- der vorausgegangene Prozessschritt und
- die Identifikationsnummer des kontrollierten Bauteils (Bauteil-ID)
Die erfassten Daten werden an ein LAS namens OTD-NET übermittelt.
2.2 Prozessablauf Auf Basis der erfassten Daten erfolgt die weitere SCE-Steuerung des Prozesses durch das logisti-
schen Assistenzsystem in einem definierten Prozessablauf, der in Abbildung 2 dargestellt ist. Die-
ser Ablauf zeigt den konzeptionellen Entwicklungsstand des Systems im Oktober 2011.
Abbildung 2 SCE-Steuerung im Prozess, Auswahl der Systemfunktion
Seite 13
Der Prozessablauf in Abbildung 2 zeigt die Qualitätskontrolle sowie die Schritte, die zur Auswahl
einer Systemfunktion zur Vorbereitung der Nacharbeit erforderlich sind. Im ersten Schritt des Pro-
zessablaufs werden die mittels des Premiumservice erfassten Qualitäts- und Prozessdaten mit den
Auftragsinformationen (Auftragsnummer, Liefertermin, etc.) und den Artikeldaten (Qualitätsanforde-
rungen, etc.) zusammen geführt. Diese Informationen und Daten stammen aus dem ERP-System
des Möbelherstellers. Unter Heranziehung aller erfassten und abgerufenen Daten erfolgt die Prü-
fung, ob Nacharbeit erforderlich ist.
Im Beispielszenario gehen wir davon aus, dass diese Qualitätskontrolle eine mindere Qualität an-
zeigt, sodass Nacharbeit erforderlich ist. Damit muss eine Abschätzung der Einflüsse der Nachar-
beit erfolgen. Um zunächst festzulegen, auf welche Art diese Abschätzung erfolgen soll, werden die
im rechten Strang der in Abbildung 2 dargestellten SCE-Steuerungsschritte durchlaufen. Demnach
werden zur Auswahl der Steuerungsoption die folgenden Prozessschritte durchlaufen und entspre-
chende Dialoge auf einem mobilen Gerät angezeigt:
- Nach der Prüfung, ob Nacharbeit erforderlich ist, wird das Prüfergebnis angezeigt, mit dieser
Anzeige ist die Prüfung abgeschlossen;
- Im nächsten Schritt wird im Display des Mobilen Gerätes eine Liste der Systemfunktionen
angezeigt, aus denen eine Auswahl getroffen werden kann, im vorliegenden Fallbeispiel
sind dies u.a. die Funktionen „Monitoring“, „Szenario Manager“ und „Impact Manager“; diese
Funktionen bieten Zugang zu einer Auswertung der zeitlichen Entwicklung der Prüfergeb-
nisse, zur Berechnung zu unterschiedlichen Szenarien auf Basis von Handlungsaktivitäten
sowie zur Darstellung der Einflüsse, die die Prüfergebnisse auf den Montageprozess haben
- Über das Display des mobilen Gerätes wird im Fallbeispiel die Funktion „Szenario Manager“
ausgewählt
Ausgelöst durch die getroffene Auswahl erfolgen die weiteren SCE-Steuerungsschritte und eine
Anzeige der entsprechenden Dialoge im Display des mobilen Gerätes. Diese Schritte stellen sich
wie folgt dar:
- Auf Basis der Auswahl „Szenario Manager“ wird hier eine Liste der verfügbaren Steue-
rungsoptionen angezeigt, aus der wiederum eine Auswahl getroffen werden kann. Für die
getroffene Auswahl sind die Funktionen „Nacharbeit im Verpackungsbereich“, „Nacharbeit
nicht im Verpackungsbereich“, „Allokation Alternativbauteile“ und „Verlassen des Systems“
zur Auswahl verfügbar;
- Über das Display des mobilen Gerätes wird im Fallbeispiel die Funktion „Nacharbeit im Ver-
packungsbereich“ ausgewählt;
- Diese Auswahl steuert den nachfolgenden Service – im vorliegenden Proof of Concept die
Simulation der Nacharbeit im Verpackungsbereich – an (vgl. Abbildung 3)
Die angestoßene Simulation wird in einem separaten logistischen Assistenzsystem zur Entschei-
dungsunterstützung (OTD-NET) durchgeführt. Die Ergebnisse der Simulation werden von diesem
Seite 14
LAS auf das anfragende Mobile Gerät übertragen und auf dessen Display angezeigt. Mit der Anzei-
ge ist die Prüfung des Einflusses der Nacharbeit auf den gesamten Prozess abgeschlossen.
Abbildung 3 SCE-Steuerung im Prozess, Auswahl der Steuerungsoption
Eine wesentliche Aktivität im dargestellten Prozessablauf liegt in der Simulation der Nacharbeit im
Verpackungsbereich. Diese Simulation wird durch einen eigenen Service durchgeführt, der im
nachfolgenden Abschnitt detailliert dargestellt wird.
2.3 Ablauf der Serviceaufrufe für die funktionalen Services Die Simulation der Nacharbeit im Verpackungsbereich wird durch einen Simulationsservice mit de-
finierten Serviceaufrufen innerhalb des Entscheidungsunterstützungssystems gesteuert. Service-
aufrufe bezeichnen das Anfragen eines Client-Programms an einen Service und das Bereitstellen
der angefragten Informationen durch den Service, sie leiten somit die Kommunikation zwischen
Client und Service ein. Der größte Anteil an Steuerungsoptionen fällt an die Bereitstellung von In-
formationen und Daten aus den unterschiedlichen Systemen der Akteure. Folgende Informationen
und Daten müssen für die Simulation der Nacharbeit bereitgestellt werden:
- Auftragsinformationen (Auftragsnummer, Liefertermin, etc.) aus dem ERP-System des Mö-
belherstellers;
Seite 15
- Baubarkeitsregeln des Produkts aus dem ERP-System des Lieferanten;
- Bestandinformationen (Bauteil-IDs, Abmaße, etc.) aus dem ERP des Möbelherstellers sowie
aus dem WMS des Lieferanten und dem WMS des Möbelherstellers
Neben diesen Daten müssen auch die durch den Premiumservice über einen Sensor aufgenom-
menen Informationen über den nachzuarbeitenden Artikel bereitgestellt werden, damit der Simulati-
onsservice den Bezug zwischen diesem Artikel und den oben aufgelisteten Daten herstellen kann.
Die nachfolgende Abbildung 4 stellt den Ablauf der Serviceaufrufe für den Simulationsservice
schematisch dar. Die Abbildung zeigt außerdem, welches System den jeweiligen Serviceaufruf an-
stößt bzw. auf eine Anfrage antwortet.
Abbildung 4 Ablauf der Serviceaufrufe des Simulationsservice
Nachfolgend wird der dargestellte Sequenzablauf der Serviceaufrufe des Simulationsservice im
Detail beschrieben, sodass der Zweck dieser einzelnen Aufrufe transparent wird und zu jedem die
jeweils übertragenen Informationen und Daten zugeordnet werden können.
Der Ablauf der Serviceaufrufe beginnt mit der Auswahl der Steuerungsoption „Nacharbeit im Verpa-
ckungsbereich“ über das mobile Gerät. Zur Anforderung der benötigten Daten aus den unterschied-
lichen Systemen und zur Durchführung der Simulation werden die nachfolgend aufgelisteten Ser-
viceaufrufe getätigt.
- „Nacharbeit im Verpackungsbereich“ am mobilen Gerät auswählen: Mit diesem Ser-
viceaufruf erfolgt die Auswahl der durch das System zur Entscheidungsunterstützung OTD-
NET auszuführenden Aktion, nämlich die Simulation
- Senden der Auftragsinformationen durch OTD-NET an die ERP- und WMS-Systeme: Mit
diesem Serviceaufruf werden die relevanten Auftragsdaten, die zuvor durch den Premi-
Seite 16
umservice aufgenommen worden sind, wie Bauteil-ID, Ort und Zeit sowie die Qualitätskenn-
zahl, an die führenden Systeme übermittelt; die führenden Systeme sind das ERP und WMS
des Möbelherstellers sowie das WMS des Lieferanten
- Empfangen der Auftragsinformationen durch die führenden Systeme: Mit dem Empfang der
Auftragsinformationen identifizieren die führenden Systeme das Produkt, für das diese Sys-
teme Daten bereitstellen müssen; die bereitzustellenden Daten werden in weiteren Re-
quests durch das System zur Entscheidungsunterstützung OTD-NET angefordert
- Anfordern der Bestandsinformationen: Die Anforderung der Bestandsinformationen erfolgt
durch Requests an das ERP und WMS des Möbelherstellers sowie an das WMS des Liefe-
ranten; mit jedem Request müssen die Artikel-IDs der nachzuarbeitenden oder zu ersetzen-
den Bauteile übermittelt werden, damit die führenden Systeme die Bestandsinformationen
für exakt diese Artikel zurück geben
- Bereitstellen und Senden der Bestandsinformationen durch die angefragten Systeme: Das
ERP und WMS des Möbelherstellers sowie das WMS des Lieferanten geben die Be-
standsinformationen in einer Response in den jeweiligen Systemen zu den angefragten Arti-
kel-IDs an das System zur Entscheidungsunterstützung OTD-NET zurück; dabei werden
aus den drei angefragten Systemen die Bestandshöhen geliefert, aus dem WMS des Liefe-
ranten werden dem System zur Entscheidungsunterstützung OTD-NET zusätzlich die
Transportdauer und die Beschaffungsdauer der angefragten Artikel bereitgestellt
- Speichern der Bestandsinformationen: Die aus den führenden Systemen bereitgestellten In-
formationen werden gespeichert und damit für die eigentliche Simulation vorgehalten
- Anfordern der Baubarkeitsregeln: Die Anforderung der Baubarkeitsregeln erfolgt durch ein
Request des Systems zur Entscheidungsunterstützung OTD-NET an des ERP des Lieferan-
ten; mit diesem Request wird die Produkt-ID zur Identifikation des Produkts übertragen
- Bereitstellen und Senden der Baubarkeitsregeln: Das ERP des Lieferanten stellt die ange-
forderten Baubarkeitsregeln und die Bearbeitungsdauer in einer Response bereit und das
OTD-NET speichert diese Daten strukturiert für die spätere Simulation
- Durchführung der Simulation: Mit der Durchführung der Simulation werden die gespeicher-
ten Daten zusammengeführt und entlang definierter Algorithmen verarbeitet
- Bereitstellen und Senden der Simulationsergebnisse: Nach Abschluss der Simulation wer-
den die Simulationsergebnisse an das die Simulation anfordernde mobile Gerät übermittelt;
bei den übermittelten Daten handelt es sich u.a. um die Bestandseignung, die Durchlaufzeit,
die Liefertermintreue und die Service-Laufzeit
- Anzeigen der Simulationsergebnisse: Die an das mobile Gerät übertragenen Daten werden
grafisch aufbereitet und die Simulationsergebnisse auf dem Display des mobilen Gerätes
angezeigt
Seite 17
Um die vorangehend beschriebenen Serviceaufrufe sowie den zugehörigen Datenverkehr zwischen
den unterschiedlichen Systemen übersichtlich darzustellen, werden diese Zusammenhänge in ei-
nem Sequenzdiagramm visualisiert (vgl. Abbildung 5). In diesem Sequenzdiagramm werden keine
Methoden beschrieben, da diese derzeit noch nicht festgelegt und bekannt sind. An den dargestell-
ten Serviceaufrufen sind die jeweils übertragenen Daten als Notizen dargestellt.
Abbildung 5 Serviceaufrufe des Simulationsservice
Seite 18
3 Einbettung der Mehrwertdienste in das Gesamtsystem
Zur Beschreibung der Aufgaben, die durch das Service Design Studio wahrzunehmen sind, werden
zunächst der Simulationsservice und seine architektonische Einbettung in das Ökosystem aus Mo-
biler Anwendung, dem System zur Entscheidungsunterstützung OTD-NET sowie den ERP- bzw.
WMS-Systemen des Möbelherstellers und seiner Zulieferer analysiert. Weiterhin werden die Me-
thoden, die dieser Service nutzt, beschrieben. Darauf aufbauend stellt der Autor Überlegungen an,
um welche nicht-funktionalen Mehrwertdienste der Simulationsservice sinnvollerweise für seine
Aufgabenerfüllung angereichert werden sollte und wie diese Mehrwertdienste mit der Kernfunktio-
nalitäten des Simulationsservice interagieren. Dazu werden die Interaktionen der Mehrwertdienste
mit unterschiedlichen Systemen in einem Sequenzdiagramm beschrieben. Abschließend wird dar-
aus ein Vorschlag für die Einbettung der Mehrwertdienste in die Architektur des Gesamtsystems
abgeleitet.
3.1 Serviceaufrufe und übertragene Informationen Damit der Simulationsservice ausgeführt werden kann, muss dieser zunächst aufgerufen werden
und dann seinerseits Informationen, die er für die Simulation benötigt, bei unterschiedlichen Syste-
men anfordern. Bei diesen Systemen handelt es sich um die ERP- und WMS-Systeme des Möbel-
herstellers sowie der Zulieferer. In Abbildung 6 ist die Servicearchitektur des Simulationsservice
unter Verwendung von SOA-ML (vgl. [OMG09, S. 25 ff.] abgebildet. Diese Abbildung zeigt die Zu-
sammenhänge zwischen den unterschiedlichen Akteuren bzw. Systemen auf.
Abbildung 6 Servicearchitektur des Simulationsservice (SOA-ML)
Seite 19
Wesentlich für die weiteren Untersuchungen sind die beiden Service-Kontrakte „Simulation“ und
„Data Request“. Die Serviceaufrufe, die zur Erfüllung dieser beiden Kontrakte von den beteiligten
Systemen zu tätigen sind, sind bereits in Abbildung 5 schematisch dargestellt. Mit dem Ser-
viceaufruf „Simulation der Nacharbeit im Verpackungsbereich“ durch das mobile Gerät an OTD-
NET müssen im Wesentlichen die durch den Premiumservice am Beginn des Prozesses erfassten
Informationen an das System OTD-NET übergeben werden, um die Auftragsdaten und den Simula-
tionsinhalt und -umfang für den Simulationsservice verfügbar zu machen. OTD-NET bildet im dar-
gestellten Szenario die Zielplattform. Weitere Serviceaufrufe werden von dieser Zielplattform an die
ERP- und WMS-Systeme des Möbelherstellers sowie seiner Zulieferer gerichtet, um ergänzende
Daten für die Simulation – vor allem für die zeitliche Planung der Nacharbeit – zu generieren.
Abbildung 7 Übermittelte Informationen an Service bzw. Information Provider
Abbildung 7 zeigt, welche Daten und Informationen erstens vom mobilen Gerät an das System zur
Entscheidungsunterstützung (OTD-NET) und zweitens von diesem System an die auftragsführen-
den Systeme (ERP- und WMS-Systeme) übertragen werden. Um eine Simulation ausführen zu
können, benötigt OTD-NET Informationen über das Bauteil, für welches die Nacharbeit im Verpa-
ckungsbereich durchgeführt werden soll, über die Qualität des Beuteils bzw. den aufgetretenen
Fehler, über den Ort, der durch die ID des erfassenden Sensors ermittelt wird, über den Zeitpunkt
des Auftretens des Fehlers sowie über den Prozess, in dem der identifizierte Fehler aufgetreten ist.
Weiterhin benötigt das System zur Entscheidungsunterstützung ergänzende Informationen aus den
ERP- und WMS-Systemen des Möbelherstellers und seiner Lieferanten. Mit der Anforderung dieser
Informationen werden die Beuteil-ID, die ID des Kunden, die Liefermenge und der geplante Liefer-
Seite 20
termin sowie die Qualitätskennzahl und die erwartete Qualität von der Zielplattform an diese Sys-
teme übermittelt. Nach Übermittlung dieser Informationen erfolgen die Serviceaufrufe an die ERP-
und WMS-Systeme. Abbildung 8 zeigt die Nachrichteninhalte dieser Serviceaufrufe.
Abbildung 8 Anforderung der Informationen aus den ERP- und WMS-Systemen
Die Nachrichtendetails für die einzelnen Serviceaufrufe werden durch Request-Response-Proze-
duren zwischen der Zielplattform (OTD-NET) und den ERP- bzw. WMS-Systemen des Möbelher-
stellers sowie seiner Zulieferer ausgetauscht. Aus Abbildung 8 ist ersichtlich, dass die folgenden
Informationen für die Simulation aus verschiedenen ERP- und WMS-Systemen abgefragt werden:
- Lagermenge von benötigten Bauteilen mit der angegebenen ID,
- Transportdauer der benötigten Bauteile,
- Wiederbeschaffungsdauer der benötigten Bauteile sowie
- Baubarkeitsregeln für das Produkt
Zur Übermittlung der Identifizierungsinformationen für Produkte, Aufträge und Bauteile sowie zum
Anfordern der für die Simulation benötigten Informationen aus den ERP- und WMS-Systemen ruft
OTD-NET Services (vgl. Abbildung 5) mit geeigneten Methoden auf.
3.2 Beschreibung und Funktion der hinzuzufügenden Mehrwertdienste Die funktionalen Methodenaufrufe für die Simulation müssen in ergänzende Methodenaufrufe ein-
gebettet sein, die die erforderlichen Mehrwertdienste verfügbar machen, nämlich Sicherheitsabfra-
gen (Authentifizierung und Autorisierung), die Umsetzung der Abrechnung der Simulation sowie die
Seite 21
Sicherung der Servicequalität. Für diese Mehrwertdienste wird nachfolgend ebenfalls unter Nutzung
von SOA-ML eine Servicearchitektur dargestellt, welche diese Services und ihr Zusammenspiel mit
den zur Realisierung der Services notwendigen Akteuren visualisiert (vgl. Abbildung 9). Neben dem
Zielsystem OTD-NET sind die weiteren Akteure der Authentifizierungs- und Autorisierungsservice,
ein Abrechnungsservice, welcher die Abrechnung unterstützt, sowie ein SLA-Service, der die Ein-
haltung der für die Simulation vereinbarten Service Levels sicherstellt.
Abbildung 9 Servicearchitektur der Mehrwertdienste (SOA-ML)
Die Methodenaufrufe, die zum Anstoßen der Mehrwertdienste durch die Zielplattform OTD-NET
genutzt werden, dienen den nachfolgend beschriebenen nicht-funktionalen Aufgaben:
- Authentifizierung und Autorisierung: Übergabe der Nutzerdaten (Login, Passwort) an einen
Authentifizierungsservice zur Verifizierung der Identität des Nutzers mittels eines Identity
and Access Management Systems (IAM); der Autorisierungsservice räumt dem authentifi-
zierten Nutzer anschließend wiederum mittels des IAM Systems die Rechte für die Nutzung
definierter Funktionen des Simulationsservice ein; neben der hier beispielhaft dargestellten
Umsetzung der Authentifizierung und Autorisierung mittels Login und Passwort gibt es auch
andere Umsetzungsmöglichkeiten, wie z.B. die Nutzung eines Token
- Abrechnung: Übergabe der Nutzungsdauer der Simulation (Zeitpunkt des Login eines auto-
risierten Nutzers, Beginn und Ende der Simulationsaufrufe, Zeitpunkt des Logouts des Nut-
zers) an ein Monitoring- und Abrechnungssystem
Seite 22
- SLA-Einhaltung: Übergabe der Daten der erwarteten Service Level Agreements an einen
SLA Service; dieser Service gleicht die erwarteten Daten mit den im Monitoring- und Ab-
rechnungssystem erfassten Daten ab und stößt bei Nichteinhaltung der erwarteten SLA-
Werte Aktivitäten zur Anpassung der SLA an, z.B. eine Benachrichtigung der Administration
von OTD-NET zum Verändern von Wartungsintervallen oder –zeitpunkten.
3.3 Ablauf der Serviceaufrufe für die Mehrwertdienste Aus den vorangehend dargestellten Methodenaufrufen und den zugehörigen Services bzw. Syste-
men leitet sich das folgende Sequenzdiagramm ab (vgl. Abbildung 10).
Abbildung 10 Serviceaufrufe der Mehrwertdienste
Der Ablauf der Serviceaufrufe für die Mehrwertdienste beginnt mit dem Einloggen des Benutzers
über das mobile Gerät in das System zur Entscheidungsunterstützung (OTD-NET). Dazu erfolgt
Seite 23
zunächst eine Anmeldung bei einem IAM-System, um den jeweiligen Nutzer zu authentifizieren. In
einem zweiten Schritt wird die Autorisierung des Nutzers über einen Token realisiert, den das IAM-
System bei der Authentifizierung an den Nutzer für die laufende Session vergeben hat. Zur Ausfüh-
rung der Mehrwertdienste, in die die Simulation eingebettet ist, werden die nachfolgend aufgeliste-
ten Serviceaufrufe getätigt.
- Senden der Login-Daten des Benutzers an das IAM-System: Das IAM-System nutzt im ers-
ten Schritt den Authentifizierungsservice und versendet ein Token an das mobile Gerät des
Nutzers; dieser Token wird beim Aufruf von OTD-NET eingesetzt, um die Autorisierung des
Nutzers durchzuführen und ihm damit Zugang zu bestimmten Funktionen des Systems zur
Entscheidungsunterstützung zu gewähren
- Weiterleiten der Nutzerdaten und eines Zeitstempels des Login an das Monitoring- und Ab-
rechnungssystem: Das System erfasst das Login des jeweiligen Benutzers in OTD-NET
- Übertragen der SLA-Anforderungen an den SLA-Service: Bei einer SLA-Anforderung kann
es sich bspw. um die geforderte maximale Antwortzeit vom Aufrufen der Simulation in OTD-
NET bis zur Übermittlung des Ergebnisses an das mobile Gerät handeln; OTD-NET sendet
die im SLA vereinbarten Kenngrößen und deren Zielwerte an den SLA-Service, der diese In-
formationen für die Weiterverarbeitung speichert und an das Monitoringsystem weiter gibt
- Bereitstellen der SLA-Zielwerte an Monitoring und Abrechnung: Damit das Monitoringsystem
die Zielwerte der Kenngrößen mit den tatsächlichen Werten abgleichen kann, werden die
Zielwerte vom SLA-Service an dieses System übermittelt
- Durchführung der Simulation: Zum Durchführen der Simulation werden die funktionalen Ser-
viceaufrufe für die Simulation getätigt (vgl. Abbildung 5)
- Soll-/Ist-Abgleich der SLA-Kenngrößen: Das Monitoring- und Abrechnungssystem führt in
definierten Intervallen ein Abgleich der vom SLA-Service übermittelten Soll-Kenngrößen mit
den realen Kenngrößen des Simulationsservice durch; die Kommunikation dieser Ist-Werte
vom Simulationsservice an das Monitoring- und Abrechnungssystem ist in Abbildung 10
nicht dargestellt
- Senden von Problemmeldungen bei Nichteinhaltung der SLA-Zielwerte: Stellt das Monito-
ringsystem im Zuge des Abgleichs ein Über- bzw. Unterschreiten der SLA-Grenzwerte fest,
so übermittelt es eine Problemmeldung mit Art und Zeitpunkt des Problems an den SLA-
Service; der SLA-Service hat die Aufgabe, Aktivitäten zur Problembehandlung anzustoßen,
wie z.B. eine Gutschrift der nicht nutzbaren Simulationszeit zu veranlassen
- Ausführung des SLA-Services: Der SLA-Service dient dazu, Problemlösungen in der Infra-
struktur der Cloud-Plattform, welcher der Simulationsservice zugehört, anzustoßen bzw. ei-
ne Kommunikation des Problems dahingehend zu initiieren, dass es für den Betreiber des
Simulationsdienstes bzw. der Cloud-Plattform erkennbar wird und dieser geeignete Maß-
nahmen zur Problemlösung einleiten kann
Seite 24
- Bereitstellen und Senden der Simulationsergebnisse: Nach Abschluss der Simulation wer-
den die Simulationsergebnisse an das die Simulation anfordernde mobile Gerät übermittelt
Durch den beschriebenen Ablauf der Serviceaufrufe für die Mehrwertdienste betten diese den ei-
gentlichen Simulationsservice ein. Die abgebildeten Mehrwertdienste sind für die Wahrnehmung
definierter Aufgaben zwingend notwendig, um den Betrieb von Systemen und Services auf einer
Cloud-Plattform zu realisieren und wirtschaftlich umsetzbar zu machen. Ohne diese Dienste kann
zwar ein Betrieb von fachlichen Systemen und Services auf einer Cloud-Plattform erfolgen, jedoch
wären keine Authentifizierung von Nutzern und keine Funktionsbeschränkungen von Systemen
respektive Services für definierte Nutzer umsetzbar, es könnte keine Abrechnung der genutzten
Leistungen für bestimmte Kunden erfolgen und auch eine Überprüfung der Einhaltung von Service
Level Agreements wäre nicht möglich.
3.4 Systemarchitektur Die vorangehend beschriebenen Mehrwertdienste dienen im Wesentlichen zur Kommunikation zwi-
schen dem System zur Entscheidungsunterstützung OTD-NET und den Systemen, die wichtige
organisatorische und infrastrukturelle Funktionen auf einer Cloud-Plattform wahrnehmen. Vor die-
sem Hintergrund müssen sie in geeigneter Weise in eine Architekturlandschaft eingebettet sein.
Abbildung 11 Einbettung der Mehrwertdienste in die Systemarchitektur
Wesentlich für die Gestaltung der Mehrwertdienste ist, dass sie über standardisierte Schnittstellen
verfügen, die ihre einfache und schnelle Anbindung an bzw. Integration in die Systeme ermögli-
chen, mit denen sie interagieren. Gemäß der in Abbildung 11 dargestellten Architektur muss eine
Schnittstellenanbindung der Mehrwertdienste sowohl an den Client, der einen funktionalen Service
Seite 25
– in unserem Beispielszenario den Simulationsservice – aufruft, darstellbar sein. Weiterhin müssen
die Mehrwertdienste über standardisierte Schnittstellen auch an fachliche Systeme oder Services
angebunden werden können und drittens müssen die standardisierten Schnittstellen auch eine
schnelle und reibungslose Anbindung an Infrastruktursysteme umsetzen. Bei den Infrastruktursys-
temen handelt es sich um Systeme, für den grundsätzlichen Betrieb einer Cloud-Plattform benötigt
werden, wie bspw. um ein IAM-System, ein Monitoring-, Controlling- und Abrechnungssystem oder
eine Virtuelle Maschine. Wichtig ist, dass der im Service Design Studio zur Verfügung gestellte
Schnittstellenstandard für die Mehrwertdienste so gewählt ist, dass möglichst zahlreiche Systeme
bedient werden bzw. dass die an die Mehrwertdienste anzubindenden Systeme ihrerseits über
standardisierte Schnittstellen verfügen.
Seite 26
4 Modellierung mit dem Service Design Studio
In diesem Kapitel werden aufbauend auf eine Einführung in das Konzept des Service Design Stu-
dios (vgl. [Stb11]) zunächst dessen Nutzung sowie im Weiteren die relevanten Designelemente des
SDS beschrieben. Auch werden die nicht-funktionalen Eigenschaften, die den jeweiligen Mehrwert-
dienst charakterisieren, die sog. Aspekte, im zweiten Abschnitt dieses Kapitels definiert und erläu-
tert. Abschließend erfolgt in diesem Kapitel ein Abgleich des in Kapitel 2 aufgebauten Beispielsze-
narios und der in Kapitel 3 definierten Mehrwertdienste mit dem SDS-Konzept.
4.1 Konzept des Service Design Studios Da die Mehrwertdienste wesentliche Elemente für den effizienten und effektiven Betrieb einer
Cloud-basierten Plattform bilden, wird ein Instrumentarium benötigt, das die Kapselung und Konfi-
guration derartiger Dienste sowie ihre Anbindung an die funktionalen Services, die auf einer sol-
chen Plattform angeboten werden, realisiert. Das Service Design Studio stellt ein solches Instru-
mentarium bereit: Es dient der Erweiterung bereits existierender funktionaler Services um eine Be-
schreibung von nicht-funktionalen Eigenschaften, den Aspekten. Mit dem Web-basierten Werkzeug
SDS können Serviceanbieter ihre eigenen Services erweitern, sodass diese in einer Cloud-
Umgebung lauffähig, abgesichert, nach Nutzung abrechenbar und somit sinnvoll für die Endkunden
auf der Cloud-Plattform nutzbar sind [Stb11, S. 7]. Die Informationen, welche die nicht-funktionalen
Eigenschaften beschreiben, müssen in einer einheitlichen Form gemeinsam mit der funktionalen
Beschreibung eines Service in einem Repository abgelegt werden. Sie müssen für den Zugriff
durch einen Service-Marktplatz zudem maschinenlesbar sein. Die charakteristischen Merkmale des
Service Design Studios stellen sich zusammenfassend wie folgt dar (vgl. [Stb11 S. 9 ff.]):
- Verwaltung ausführbarer funktionaler Services in Bezug auf verschiedene Zielplattformen
durch das Service Design Studio
- Unterstützung der Versionierung und des Life Cycle Managements der funktionalen Ser-
vices durch ein Service Repository, das Teil des SDS ist
- Erweiterung von funktionalen Services um nicht-funktionale Eigenschaften, welche mit
Mehrwertdiensten verbunden sein können, sowie Bearbeitung dieser Eigenschaften
- Generierung erweiterter Servicebeschreibungen, welche basierend auf einem Metamodell
funktionale Services mit Aspekten verknüpfen
- Bereitstellung einer grafisch aufbereiteten Ansicht auf die Methoden und Objekte der jewei-
ligen Servicebeschreibung sowie Annotation der Modalitäten, unter denen ein Mehrwert-
dienst nutzbar ist, in dieser Servicebeschreibung
- Export der erweiterten Servicebeschreibung für die gewählte Zielplattform und Publikation in
der zur Zielplattform gehörenden Service-Registry; mit der Publikation ist die Servicebe-
schreibung zur Nutzung freigegeben
Seite 27
- Einbringen des Codes, der den ausführbaren Logistik-IT-Dienst repräsentiert, aus dem Ser-
vice Repository in die Laufzeitumgebung, welche die für die modellierten Aspekte nötigen
Infrastrukturdienste bereitstellt
Das Auffinden von Services über ihre nicht-funktionalen Eigenschaften in einer Service Registry
erfordert die Erweiterung der Service Registry um einen Trading Service. Ein solcher Service er-
möglicht es, basierend auf den jeweils in einem funktionalen Service angebotenen Aspekten unter
mehreren Serviceanbietern einen geeigneten Service zu identifizieren.
4.2 Nutzung des Service Design Studios Ausgangspunkt der Nutzung des Service Design Studios ist das Vorhandensein eines funktionalen
Services, der auf einer Internet-basierten Plattform betrieben werden soll. In dem in Kapitel 2 be-
schriebenen Beispielszenario handelt es sich bei dem Simulationsservice um einen solchen Ser-
vice, dessen Funktion in der Simulation der Nacharbeit im Verpackungsbereich liegt. Das Ergebnis,
das dieser Service generiert, wird auf einem mobilen Gerät angezeigt. Von diesem Service sind
nach seiner Entwicklung zunächst der Code, der den ausführbaren Logistik-IT-Dienst repräsentiert
(sog. Executable), sowie die funktionale Beschreibung dieses Dienstes, z.B. als WSDL-Datei oder
REST-Beschreibung, verfügbar. Zur Generierung eines Mehrwertdienstes für einen funktionalen
Service werden die Methoden und Objekte, die dieser Service nutzt, im SDS zunächst graphisch
mit einem hohen Abstraktionsgrad beschrieben und es werden die Zielplattform, auf welcher der
Service betrieben werden soll, sowie das Zielplattform-Repository des funktionalen Service identifi-
ziert. Ausgehend von einer abstrakten Sicht auf den funktionalen Service werden diejenigen Aspek-
te im SDS modelliert, die für eine zielgerichtete Erweiterung dieses funktionalen Service erforderlich
sind. Nach der Modellierung der zu ergänzenden Aspekte werden diese im Zusammenspiel mit
diesem Service getestet und validiert, ggf. verbessert bzw. Fehlfunktionen eliminiert und schließlich
mit dem funktionalen Service bereitgestellt.
Neben der Visualisierung der Methoden und Objekte der Services werden auch ein Import der Ser-
vicebeschreibung des funktionalen Service in das SDS sowie die Überführung dieser Servicebe-
schreibung in eine um die Beschreibung der Aspekte erweiterte Servicebeschreibung mittels eines
Metamodells umgesetzt. Diese Erweiterung kann nach der Modellierung der Aspekte für den jewei-
ligen Service erfolgen. Die erweiterte Servicebeschreibung wird nach erfolgreichem Test und Im-
plementierung der modellierten Aspekte in einer Service Registry zur Übernahme auf die jeweilige
Cloud-Plattform, für welche der funktionale Service vorgesehen ist, verfügbar gemacht.
Um die Implementierung der Aspekte für einen bestimmten funktionalen Service zu realisieren, wird
auch der Code für den ausführbaren Dienst in ein Service Repository des SDS importiert. Dieses
Repository dient der Versionierung und dem Life Cycle Management der erweiterten Services (vgl.
[Stb11, S. 9]). Zudem wird hier auch der Code für die zu ergänzenden Aspekte, der ebenfalls als
Executable bezeichnet wird, abgelegt und mit dem jeweiligen funktionalen Service verknüpft. Die-
Seite 28
ses Executable wird ebenso wie das Executable des funktionalen Service mit der erweiterten Ser-
vicebeschreibung in einem für die jeweilige Internet-Plattform vorgesehenen Service Repository
bereitgestellt.
Zur Generierung der Aspekte und deren Anbindung an den jeweiligen funktionalen Service steht mit
dem Service Design Studio eine Plattform bereit, mit der die vorangehend beschriebenen Aktivitä-
ten unterstützt werden. Das SDS Importiert das jeweilige Executable des funktionalen Service so-
wie die zugehörige Servicebeschreibung als Projekt (vgl. Abbildung 12), das die Methoden und Ob-
jekte dieses funktionalen Services visualisiert und die Anbindung von Aspekten an den Service rea-
lisiert. Insbesondere werden im zentralen Fenster dieser Ansicht die Schnittstellen, die der jeweilige
Service zur Verfügung stellt, dargestellt. Mit der Standardisierung dieser Schnittstellen kann eine
einfache Anbindung der Aspekte realisiert werden. In der Projektansicht werden der Besitzer des
Services, die Namen der anzubindenden Aspekte, die Zielplattform mit URL und Port sowie der
Standard-Explorer zur Nutzung des Services aufgelistet. In der Projekt-Sicht des SDS muss auch
die Beschreibung des importierten Services visualisiert werden, um ggf. Anpassungen an dieser
Servicebeschreibung vornehmen zu können.
Abbildung 12 Projekt-Sicht des Service Design Studios
Neben der Projekt-Sicht verfügt das SDS über eine Aspekte-Sicht sowie über eine Sicht der Ziel-
plattform. In der Aspekte-Sicht sind die verfügbaren Aspekte, die an einen funktionalen Service an-
gebunden werden können, aufgelistet (vgl. Abbildung 13). Die vornehmlich anzubindenden Aspekte
sind Mehrwertdienste für die Sicherheit des jeweiligen Service, für die Abrechnung sowie für die
Prüfung der Einhaltung von Service Level Agreements. In der Aspekte-Sicht wird im zentralen
Fenster die Codierung der Anbindung des ausgewählten Aspekts an den jeweiligen funktionalen
Service bzw. eine Anpassung oder Konfiguration dieses Aspekts hinsichtlich seiner Nutzung mit
Seite 29
dem jeweiligen funktionalen Service und der genutzten Zielplattform durchgeführt. In der Aspekte-
Ansicht kann die Beschreibung des jeweiligen Aspekts erstellt werden. Mit der Anbindung dieser
Beschreibung an die Beschreibung des funktionalen Services wird eine erweiterte Servicebeschrei-
bung erzeugt.
Abbildung 13 Aspekte-Sicht des Service Design Studios
Die vorangehenden Ausführungen geben einen ersten Eindruck über die Nutzung des Service De-
sign Studios. Daraus ist ersichtlich, dass das SDS im Wesentlichen drei Funktionen erfüllt: Erstens
unterstützt es die Erstellung von erweiterten Servicebeschreibungen aus den für die jeweiligen
funktionalen Services importierten Servicebeschreibungen, zweitens erfolgt mit diesem Web-
basierten Werkzeug eine Bearbeitung der Aspekte, sodass diese mit dem jeweiligen funktionalen
Service verknüpft werden, und drittens stellt es die erweiterte Servicebeschreibung sowie die Exe-
cutables für den um definierte Aspekte ergänzten Service bereit.
4.3 Aspekte In diesem Abschnitt wird der Begriff der Aspekte näher beleuchtet. Gemäß Definition (vgl. Abschnitt
1.4) beschreibt ein Aspekt „eine nicht-funktionale Eigenschaft eines funktionalen SOA-Services.“
Somit können Aspekte entweder zur Filterung bei der Suche nach geeigneten funktionalen Services
oder zur Sicherstellung der Einhaltung benötigter nicht-funktionaler Eigenschaften beim Aufrufen
von Services genutzt werden. Sie definieren spezifische konfigurierbare nicht-funktionale Eigen-
schaften eines funktionalen Services. Ist ein Aspekt vollständig konfiguriert – d.h. alle Eigenschaf-
Seite 30
ten bzw. Parameter des Aspekts sind mit Werten versehen – und wird er an einen Service gebun-
den, so ist damit eine Aspekt-Instanz generiert.
Die Konfiguration eines Aspekts erfolgt auf Basis eines Aspekt-Templates. In einem solchen Temp-
late sind die anpassbaren Parameter bzw. Eigenschaften des zugrundeliegenden Aspekts vorge-
geben. Sie können mit konkreten Werten vorbelegt sein. Mit der Belegung der Parameter bzw. Ei-
genschaften, die noch nicht mit konkreten Werte vorbelegt sind, werden die Anpassung des As-
pekts an den Service, an den er angebunden werden soll, sowie an die erwarteten Anforderungen
des Nutzers des Services angepasst. Damit wird die Instanziierung des Aspekts umgesetzt. Eine
Aspekt-Instanz kann nicht nur an einen Service, sondern direkt an eine bestimmte Service-
Operation gebunden werden. In Abgrenzung zu einer Aspekt-Instanz ist das Aspekt-Template nicht
an einen Service oder eine Service-Operation gebunden. Ein Aspekt-Template liegt als Datei vor,
die vom Service Design Studio eingelesen wird und als Basis für eine graphische „Ausfüllhilfe“
dient. Die Informationen aus einem Aspekt-Template können in der GUI des Service Design Stu-
dios angezeigt werden. Die im Zuge der Konfiguration einzugebenden Werte sind durch das As-
pekt-Template grob vorgegeben, z.B. durch die Angabe eines Datentyps wie String oder Integer
sowie durch mögliche Einschränkungen des Wertebereichs, z.B. „0..100“. Durch die Vorbelegung
eines Aspekt-Templates mit sinnvollen Aspekt-Eigenschaften können wiederverwendbare Vorlagen
bereitgestellt werden, die an unterschiedliche Services oder Service-Operationen gebunden werden
können. Diese Eigenschaften sind im Zuge der Erzeugung einer Aspekt-Instanz änderbar.
Um die vorangehend ausgeführten Funktionen zu erfüllen, müssen Aspekte aus unterschiedlichen
Komponenten aufgebaut sein (vgl. Abbildung 14). Diese Komponenten stellen erstens die Kommu-
nikation eines Aspekts mit dem funktionalen Service, an den er angebunden ist, sicher und erlau-
ben zweitens eine individuelle Konfiguration des jeweiligen Aspekts.
Abbildung 14 Architekturmodell eines Aspekts
Seite 31
Gemäß des in Abbildung 14 dargestellten Architekturmodells eines Aspekts gibt es vier wesentliche
Komponenten, aus denen Aspekte bestehen:
- Die erste Komponente beschreibt die konfigurierbare Schnittstellen, über die der jeweilige
funktionale Service angebunden ist
- Zweitens müssen in vielen Fällen auch konfigurierbare Schnittstellen zur Anbindung einer
Infrastrukturkomponente der jeweiligen Cloud-Plattform bereitgestellt werden
- Die dritte Komponente wird gebildet durch die Logik bzw. den Code zur Erfüllung der eigent-
lichen Funktionalität des jeweiligen Aspekts
- Der jeweilige Aspekt muss i.d.R. eine kundenindividuelle Konfiguration seiner Funktionalität
unterstützen; dies erfolgt über das Aspekt-Template, in dem bereits vorgegeben ist, welche
Größen zu konfigurieren sind; ggf. sind hier bereits Werte eingetragen
Unter Nutzung der dargestellten Architekturkomponenten der Aspekte und mit der Bereitstellung
von Templates lässt sich eine strukturierte Anbindung und Modellierung jedes einzelnen Aspekts an
einen funktionalen Service mittels des Service Design Studios realisieren. Ein strukturiertes Vorge-
hen zur Anbindung der Aspekte wird im nachfolgenden Kapitel am Beispiel des Simulationsservice
OTD-NET beschrieben.
4.4 Abgleich des Beispielszenarios mit dem SDS-Konzept Die in Abschnitt 4.2 beschriebene Nutzung des Service Design Studios wird in diesem Abschnitt an
einer Erweiterung des in Abschnitt 2.3 dargestellten Simulationsservice um definierte Aspekte ge-
spiegelt. Ziel der Erweiterung des Simulationsservice ist es, den Service um eine Autorisierungs-
und Authentifizierungsfunktion zu ergänzen, einen Abrechnungsaspekt anzubinden und ggf. einen
SLA-Aspekt in den Simulationsservice zu integrieren. Um die Anbindung der genannten Aspekte an
den Simulationsservice zu realisieren, sind die folgenden Aktivitäten durchzuführen:
- In einem ersten Schritt muss im Service Design Studio ein neues Projekt mit einem Projekt-
verzeichnis erstellt werden
- Vor der Nutzung des Service Design Studios steht lediglich der singuläre Simulationsservice
mit seiner Servicebeschreibung zur Verfügung; die Original-Beschreibung des Simulations-
service wird in das SDS-Werkzeug integriert; die Integration erfolgt in das neu erstellte Pro-
jekt; zudem erfolgt eine Integration des Executables in das Service Design Studio; sowohl
der Code des Executables als auch die Metadaten zur Beschreibung des funktionalen Ser-
vice werden im dem neuen Projekt zugehörigen SDS-Projektverzeichnis abgelegt; insbe-
sondere die Schnittstellenbeschreibungen des funktionalen Service sind für das Arbeiten im
Service Design Studio von Bedeutung, da über diese Schnittstellen die Ansprache der As-
pekte erfolgen muss
- Die Aspekte, die an den Simulationsservice angebunden werden sollen, werden in das er-
stellte Projekt integriert; dazu werden die Beschreibungen der Aspekte sowie die Aspekt-
Seite 32
Templates aus einen Repository, in dem die verfügbaren Aspekt-Templates abgelegt sind
und auf welches das SDS Zugriff hat, in das SDS-Werkzeug eingelesen und damit für eine
Konfiguration der Logik verfügbar gemacht und angezeigt
- Die Aspekte-Templates stellen in ihrem Ausgangszustand bereits die Funktionalitäten zur
Verfügung, für die der jeweilige Aspekt vorgesehen ist; es muss im SDS die Kommunikati-
onsanbindung des jeweiligen funktionalen Service an die mittels des jeweiligen Aspekts zu
steuernde Infrastrukturkomponente der Cloud-Plattform, auf welcher der funktionale Service
genutzt werden soll, umgesetzt werden; weiterhin muss eine kundenspezifische Konfigurati-
on des Aspekt-Templates vorgenommen werden; durch diese Aktivitäten wird der jeweilige
Aspekt instanziiert
- Zur Integration der Autorisierungs- und Authentifizierungsfunktion sind die entsprechenden
Schnittstellen des Simulationsservice so zu gestalten, dass dieser mit den notwendigen Inf-
rastrukturkomponenten der Plattform, dem IAM (Identity and Access Management) System,
kommunizieren kann; im Zuge der Kommunikation zwischen dem Service und dem IAM-
System der Plattform wird mittels des Sicherheits-Aspekts abgefragt, ob der jeweilige Be-
nutzer die Berechtigung hat, den Service zu nutzen; weiterhin muss die Konfiguration der
Logik der mittels des Aspekts angesprochenen Funktionen vorgenommen werden, bspw.
können die maximale Anzahl von Nutzern des funktionalen Service oder die für den funktio-
nalen Service vorgesehenen Rollen festgelegt werden; ergänzend zur technischen Integra-
tion der genannten Funktionen erfolgt eine Erweiterung der Beschreibung des funktionalen
Services im SDS
- Die Integration des Aspekts, der den Simulationsservice mit einem Preismodell zu seiner
Abrechnung verbindet, erfordert ähnliche Entwicklungsarbeiten wie die Anbindung des Auto-
risierungs- und Authentifizierungsaspekts: Nach dem Aufrufen des Aspekt-Templates muss
der funktionale Service mittels einer Aspekt-gesteuerten Kommunikation an die Infrastruk-
turkomponente Abrechnungssystem angebunden werden; zusätzlich ist eine Konfiguration
des Abrechnungs-Aspekt-Templates erforderlich, über welches das Preismodell und das
Preismodell bestimmende Merkmale, bspw. die Zählintervalle für ein nutzungsabhängigen
Preismodell, definiert bzw. mit Werten belegt werden; ergänzend zur technischen Integration
des Abrechnungs-Aspekts wird auch bei diesem Aspekt die Erweiterung der Beschreibung
des funktionalen Service im SDS vorgenommen
- Auch die Anbindung eines SLA-Aspekts an den Simulationsservice erfordert die Anpassung
der Schnittstellen des Simulationsservices sowie der Infrastruktur; der SLA-Aspekt muss si-
cherstellen, dass die Festlegungen, die in einem SLA für einen funktionalen Service doku-
mentiert sind, mit den Aktionen, die mit diesem Service ausgeführt werden, abgerufen und
protokolliert werden; weiterhin muss das entsprechende Aspekt-Template über das SDS
konfigurierbar sein, sodass die SLA-Festlegungen in der SLA-Aspekt-Instanz hinterlegt wer-
Seite 33
den können; diese Konfiguration wird ebenso wie beim Abrechnungs-Aspekt im Service De-
sign Studio durchgeführt; auch für diese Aspekt-Instanz erfolgt eine Erweiterung der Be-
schreibung des funktionalen Service im SDS, u.a. können im Rahmen dieser Beschreibung
die für diesen Service konfigurierten SLAs dokumentiert werden, wie z.B. eine garantierte
Antwortzeit des Simulationsservice von 30 Sekunden
- Die erweiterte Beschreibung des Simulationsservice muss so gestaltet sein, dass die Funk-
tionen dieses Services exakt dargestellt werden; darüber hinaus muss diese Beschreibung
die in diesen Service geltenden Aspekte sowie die Bedingungen, unter denen sie genutzt
werden, ebenfalls im Detail darstellen, damit eine klare Abgrenzung dieses um Aspekte er-
weiterten funktionalen Services gegen andere Services mit möglicherweise ähnlichen Funk-
tionen realisiert wird
- Ist die Anbindung der Aspekte an den Simulationsservice abgeschlossen, werden die Exe-
cutables, die der Simulationsservice einschließlich seiner angebundenen Aspekt-Instanzen
umfasst, versioniert und aus dem SDS ausgecheckt; dasselbe gilt für die zugehörige Doku-
mentation bzw. für die erweiterte Beschreibung des Simulationsservice
- Das Projekt im Service Design Studio, in dem die Anbindung der Aspekte durchgeführt wor-
den ist, wird geschlossen
Nach Abschluss der Arbeiten im Service Design Studio werden das den Simulationsservice be-
schreibende Executable im Service Repository der Cloud-Plattform, auf dem dieser Service betrie-
ben werden soll, zur Nutzung bereitgestellt. Dies erfolgt durch eine Übertragung des Executables in
das Repository. Es steht damit zur Nutzung auf der jeweiligen Cloud-Plattform bereit. Zudem wird
die erweiterte Beschreibung des Simulationsservice mit den geltenden Aspekten öffentlich ge-
macht. Hier kann bspw. die der Cloud-Plattform zugehörige Registry mittels eines Content Ma-
nagement Systems, das die Informationen zur erweiterten Beschreibung des Simulationsservice
importieren kann, mit der im SDS generierten Beschreibung gefüttert werden. Die Bereitstellung
dieser Informationen in der Registry ermöglicht ein Auffinden des Simulationsservices und erlaubt
dem Suchenden eine Abschätzung, ob dieser Service unter den Bedingungen, unter denen er den
Service einsetzen möchte, genutzt werden kann.
Seite 34
5 Fallbeispiel
Der in Abschnitt 4.4 skizzierte Ablauf wird in diesem Kapitel konkretisiert. Dazu werden der Simula-
tionsservice als Grundlage herangezogen und die Erweiterung dieses Service um definierte Aspek-
te beschrieben. Die Aspekte konfigurieren die spezifischen Funktionskomponenten auf der Zielplatt-
form, sodass der Service auf den dort vorgehaltenen Code zugreift. Ausgehend von der Beschrei-
bung der Rahmenbedingungen werden in diesem Kapitel insbesondere die Ausgestaltung des Ab-
rechnungs- sowie des Security-Aspekts mittels bereitgestellter Templates dargestellt. Ziel ist die
genaue Beschreibung der Verwendung dieser Templates, sodass High-Level-Modelle zur Service-
beschreibung entstehen.
5.1 Rahmenbedingungen für die Ausgestaltung der Aspekte Die Ausgangssituation bildet die Nutzung des Simulationsservice für seinen produktiven Einsatz im
Ablaufszenario, das in Abschnitt 2.3 beschrieben ist. Dabei wählt der Nutzer in der Rolle eines Ana-
lysten innerhalb der SCE-Steuerung die Funktion „Nacharbeit im Verpackungsbereich“ aus und
stößt damit die Simulation in einem System zur Entscheidungsunterstützung (OTD-NET) an.
Für den Abrechnungs-Aspekt werden auf Basis des o.g. Ablaufszenarios exemplarisch die folgen-
den Anforderungen angenommen: Für die Nutzung des Simulationsservice fällt eine nutzungsab-
hängige Gebühr an, die bei 50 Cent pro Berechnung liegt. Um die Kosten für Pflege und Wartung
des Service abzudecken, wird zusätzlich eine Grundgebühr in Höhe von 5,00 Euro pro Monat fällig.
Der Simulationsservice muss nach seiner Buchung für mindestens drei Monate aboniert werden.
Die Kündigungsfrist des Service liegt bei vier Wochen. Die Aufteilung der durch diesen Service er-
wirtschafteten Erträge liegt bei 15% für den Cloud-Betreiber, 15% für den Mall-Betreiber und 70%
für den Anbieter des Service. Cloud-Betreiber und Mall-Betreiber sind in diesem Beispiel dasselbe
Unternehmen, sodass hier insgesamt 30% der Erträge zu verrechnen sind. Die Grundgebühr fällt
vollständig an den Betreiber und wird im Voraus in Rechnung gestellt. Die Abrechnung aller ange-
fallenen Gebühren erfolgt am Ende einer Abrechnungsperiode, die einen Monat beträgt. Die Steu-
ern werden dort erhoben, wo die Rechenleistung erbracht wird, also am Sitz des Cloud-Betreibers.
Dieser liegt im vorliegenden Beispiel in Deutschland, sodass hier 19% Umsatzsteuer zu veran-
schlagen ist.
Für den Security-Service gelten die folgenden Randbedingungen: Der jeweilige Nutzer gibt bei der
Anmeldung an das logistischen Assistenzsystem seinen Benutzernamen und sein Passwort ein. Bei
erfolgreicher Authentifizierung erhält er ein Token an seinen Client, der für die Autorisierung im
Service genutzt wird. Mit jedem Nutzer des logistischen Assistenzsystems sind definierte Rollen
verbunden, bspw. die eines Systemadministrators, eines Analysten oder eines Datenerfassers. Den
Simulationsservice darf lediglich der Nutzer mit der Rolle eines Analysten verwenden, den anderen
beiden Rollen wird der Zugriff auf den Simulationsservice verweigert.
Seite 35
5.2 Modellierung eines Abrechnungsaspekts Der im vorangehenden Abschnitt definierte Abrechnungsaspekt für die Simulation „Nacharbeit im
Verpackungsbereich“ wird mithilfe von Aspekte-Templates, die im Zuge der Konfiguration des dies-
bezüglichen Mehrwertdienstes auszufüllen sind, festgelegt. Mittels der Templates legt der Nutzer,
der die Konfiguration des jeweiligen Mehrwertdienstes vornimmt – i.d.R. ein Mitarbeiter des Mall-
Betreibers –, fest, welche Modelle und Methoden wann für das Abrechnungsmanagement anzu-
wenden sind. Dazu werden die Attribute (attributes) der Aspekte-Templates zunächst mit geeigne-
ten Werten (values) versehen und diese Templates in Anschluss in eine Dienstbeschreibungsspra-
che überführt, die die von der jeweiligen Zielplattform unterstützt wird. Diese Angaben, die in den
Aspekte-Templates für die Abrechnung gemacht werden, generieren einen sog. Price Plan (vgl.
[Asp11]). Dieser erhält einen Namen (name) und eine Beschreibung (description) und listet nach-
folgend die relevanten Attribute und ihre jeweiligen Werte auf. Die einzelnen Attribute des Price
Plans und ihre Bedeutung werden in [Asp11] ausführlich erläutert; dies gilt insbesondere für optio-
nale Attribute die in der nachfolgenden Tabelle 1 nicht aufgelistet werden. Diese Tabelle stellt den
Price Plan für das oben definierte Beispiel im Entwicklungsstand vom Oktober 2011 dar.
Price Plan
Attribute Value
name Simulation Fee
description Dieser Price Plan sieht eine monatliche Grundgebühr von 5,00 Euro sowie eine nutzungsabhängige Gebühr von 0,50 Euro pro Simulationsberechnung vor. Die Mindestlaufzeit für die Nutzung des Service liegt bei 3 Monaten, die Kündigungs-frist beträgt vier Wochen. Erfolgt keine Kündigung, verlängert sich der Vertrag automatisch um jeweils einen Monat.
currency EUR
effectiveFrom 2011-11-01
effectiveTo unlimited
taxes 19%
priceComponents
type = Base Fee Attribute Value
amount 5,00
unit EUR
paymentModality pre
Period Monthly
effecitveFrom +0 Days
effectiveTo unlimited
type = Usage Fee Attribute Value
amount 0,50
unit Transaction
paymentModality post
Seite 36
Price Plan
Period -
effecitveFrom +0 Day
effectiveTo unlimited
revenueComponents
Attribute Value
receipt Cloud/Mall Operator
userId Sds_op_900001
percentage 50,00
effecitveFrom +0
effectiveTo unlimited
Attribute Value
receipt Service Provider
userId Sds_sp_100001
percentage 50,00
effecitveFrom +0
effectiveTo unlimited
Tabelle 1 Price Plan für das beschriebene Szenario
Die im vorangehenden Abschnitt definierten Werte für bestimmte Attribute sind in der obigen Tabel-
le 1 eingetragen: Neben dem Namen und der Beschreibung werden hier das Datum angegeben, ab
wann dieser Plan Gültigkeit hat (effectiveFrom), sowie das Datum, wann die Gültigkeit des Plans
ausläuft (effectiveTo). Im formulierten Beispiel soll der Plan ab 01.11.2011 laufen und unbegrenzt
gültig sein. Das Ablaufen des Plans wird mit einem Wert belegt, wenn der jeweilige Kunde den Si-
mulationsservice kündigt oder wenn sich andere Faktoren, wie z.B. die Preise, verändern. In die-
sem Fall gilt ein Nachfolgeplan. Zum Attribut Steuern (taxes) wird im Beispiel die zu veranschla-
gende Mehrwertsteuer als Wert angegeben.
Die in Tabelle 1 nachfolgend aufgelisteten Preiskomponenten (priceComponents) definieren die
eigentlichen Tarife und Gebühren. Hier erfolgen die Angaben über die Höhe der Gebühren und die
Zahlungskonditionen, wie die Abrechnungsarten (pauschal, pro Transaktion) und die Zahlungszeit-
punkte (vorab, nachfolgend). Auch werden Anfangs- und Endzeitpunkte der Bepreisung angege-
ben. Im Beispiel werden Werte für die Grundgebühr sowie für eine nutzungsabhängige Gebühr an-
gegeben. Eine unentgeltliche Nutzung des Services ist nicht vorgesehen.
Mit den Ertragskomponenten (revenueComponents) werden schließlich die Erträge der verschiede-
ner beteiligten Akteure definiert. Dies sind im vorliegenden Beispiel der Cloud-/Mall-Betreiber sowie
der Anbieter des Services, unter denen sich der Ertrag aus der nutzungsabhängigen Gebühr 30%
zu 70% aufteilen soll. Der Ertrag aus der Grundgebühr soll vollständig an den Cloud-/Mall-Betreiber
fallen. Das Datenmodell für den Price Plan sieht eine unterschiedliche Aufteilung der Erträge in Ab-
Seite 37
hängigkeit von den verschiedenen Ertragsarten zwischen den beteiligten Partnern nicht vor (vgl.
[Asp11, S. 5]), sondern es verlangt eine Aufteilung der Summe der Erträge. Aus diesem Grund wird
die Summe der Erträge aus der Grundgebühr und der nutzungsabhängigen Gebühr gemäß der
obigen Tabelle 1 zu gleichen Teilen auf die Partner aufgeteilt, also 50% zu 50%.
5.3 Modellierung eines Sicherheitsaspekts Für die Modellierung des Sicherheitsaspekts ist ein ähnliches Vorgehen vorgesehen wie für die
Modellierung des Abrechnungsaspekts: Auch hier sind gemäß dem formulierten Beispiel Aspekte-
Templates auszufüllen, die den Mehrwertdienst für die Authentifizierung und die Autorisierung kon-
figurieren und festlegen, welche Methoden genutzt werden und welche Rollen angelegt und mit
welchen Zugriffsrechten versehen werden. Die relevanten Attribute für den Sicherheitsaspekt sind
die Authentifizierungsmethode (authenticationMethod) sowie die Zugriffsmethode (accessMethod)
für die jeweils definierten Rollen (role). Bei der Zugriffsmethode wird im einfachsten Fall zwischen
Zugriff und kein Zugriff unterschieden. Die Angaben aus den Aspekte-Templates für die Sicherheit
erzeugen – analog zu den Templates für den Abrechnungsaspekt – einen sog. Security Plan. Die-
ser erhält ebenfalls einen Namen (name) und eine Beschreibung (description) und listet die o.g.
Attribute mit den entsprechenden Werten auf. Tabelle 2 zeigt den Security Plan für das Beispiel.
Security Plan
Attribute Value
name Access to Simulation Service
description Dieser Security Plan sieht eine Authentifizierung des jeweiligen Benutzers über einen Token vor. Zugleich ist nur die Rolle des Analysten autorisiert, auf den Simulationsservice zuzugreifen.
effectiveFrom 2011-11-01
effectiveTo unlimited
authenticationMethod Token
accessComponents
Attribute Value
role administrator
acessMethod no access
Attribute Value
role analyst
acessMethod access
Attribute Value
role data collector
acessMethod no access
Tabelle 2 Security Plan für das beschriebene Szenario
Seite 38
Neben der im obigen Security Plan genannten Zugriffsmethode mittels eines Token können alterna-
tiv bei jedem Zugriff auf den Simulationsdienst die Eingabe von Benutzername und Passwort not-
wendig sein. Tabelle 2 zeigt zudem, dass gemäß dem definierten Beispiel lediglich die Rolle des
Analysten Zugriff auf den Simulationsservice hat (Belegung des Attributs Zugriffsmethode mit dem
Wert 1). Die anderen beiden Rollen, die im Szenario beschrieben sind, haben keinen Zugriff auf
den Service, daher ist das Attribut Zugriffsmethode hier mit 0 belegt.
Bei der Formulierung von Attributen für die unterschiedlichen Mehrwertdienste, die an einen Service
angegliedert werden können, ist vorstellbar, dass die Konfiguration dieser Dienste generell mittels
Templates vorgenommen wird, die im Anschluss in die zugehörigen Pläne überführt werden. Diese
Pläne bilden die Grundlage für die Konfiguration der spezifischen Funktionskomponenten auf der
Zielplattform, sodass der jeweilige Mehrwertdienst auf den dort vorgehaltenen zugehörigen Code
zugreift.
Seite 39
6 Zusammenfassung und Ausblick
Das vorliegende Proof of Concept hat aufgezeigt, wie ein Arbeiten mit dem Service Design Studios
aussehen kann, und welche Voraussetzungen dafür erfüllt sein müssen. Dazu ist zunächst ein Bei-
spielszenario, das teilweise durch informationstechnische Services gesteuert wird, aus dem Ver-
bundprojekt Supply Chain Execution in seine Prozesselemente zerlegt und analysiert worden. Aus
den Analysen sind die für das Proof of Concept relevanten Serviceaufrufe identifiziert und mittels
SOA ML dokumentiert worden. Damit sind die Nachrichtendetails für die einzelnen Serviceaufrufe
des Simulationsservice OTD-NET transparent. Auf dieser Basis werden die Methodenaufrufe, die
zum Anstoßen der Mehrwertdienste erforderlich sind, ermittelt und in einem Sequenzdiagramm
beschrieben. Ein solches Diagramm visualisiert die Kommunikation zwischen dem funktionalen
Simulationsservice und den anzubindenden Aspekten für diesen Service. Ein Architekturmodell
aller Komponenten rund um den Simulationsservice zeigt die einzurichtenden Schnittstellen der
Aspekte auf. In Kapitel 4 werden auf Basis der Analysen und Darstellungen der vorangehenden
Kapitel das Konzept sowie die Nutzung des Service Design Studios zunächst methodisch darge-
stellt und anhand des Beispiels Simulationsservice konkret beschrieben. Als wesentliche Elemente
werden in diesem Kapitel die Aspekte, deren Struktur und Funktionsweise beschrieben. Kapitel 5
beschreibt in einem Fallbeispiel abschließend, wie die Konfiguration der Mehrwertdienste mittels
definierter Aspekte-Templates und der daraus abgeleiteten Pläne umgesetzt wird.
Insgesamt kann mit dem vorliegenden Proof of Concept der Nachweis der Sinnhaftigkeit und Funk-
tionsweise des Service Design Studios entsprechend seiner Konzeption und Planungen nachge-
wiesen werden. Der nächste wesentliche Schritt liegt in der Implementierung des SDS selbst, so-
dass die in diesem Dokument beschriebenen Vorgehensweisen erprobt und ggf. verbessert werden
können. Die Grundlagen für eine solche Umsetzung bilden ein Architekturmodell sowie ein konkre-
tes technisches Konzept, das auf Basis des funktionalen Konzepts genau darstellt, aus welchen
Komponenten das SDS aufgebaut wird und wie diese Komponenten zusammen spielen. Daraus
leitet sich dann der Bedarf an Programmierungsaktivitäten und notwendigen Codeanpassungen ab.
Weiterhin müssen die Aspekte und Aspekt-Templates durch die Partner im Verbundprojekt bereit-
gestellt werden.
Seite 40
7 Abbildungs- und Tabellenverzeichnis
7.1 Abbildungsverzeichnis Abbildung 1 SCE-Beispiel Qualitätskontrolle Endmontage ........................................................ 11
Abbildung 2 SCE-Steuerung im Prozess, Auswahl der Systemfunktion ..................................... 12
Abbildung 3 SCE-Steuerung im Prozess, Auswahl der Steuerungsoption ................................. 14
Abbildung 4 Ablauf der Serviceaufrufe des Simulationsservice ................................................. 15
Abbildung 5 Serviceaufrufe des Simulationsservice .................................................................. 17
Abbildung 6 Servicearchitektur des Simulationsservice (SOA-ML) ............................................ 18
Abbildung 7 Übermittelte Informationen an Service bzw. Information Provider .......................... 19
Abbildung 8 Anforderung der Informationen aus den ERP- und WMS-Systemen ...................... 20
Abbildung 9 Servicearchitektur der Mehrwertdienste (SOA-ML) ................................................ 21
Abbildung 10 Serviceaufrufe der Mehrwertdienste ...................................................................... 22
Abbildung 11 Einbettung der Mehrwertdienste in die Systemarchitektur ...................................... 24
Abbildung 12 Projekt-Sicht des Service Design Studios .............................................................. 28
Abbildung 13 Aspekte-Sicht des Service Design Studios ............................................................ 29
Abbildung 14 Architekturmodell eines Aspekts ............................................................................ 30
7.2 Tabellenverzeichnis Tabelle 1 Price Plan für das beschriebene Szenario ................................................................. 36
Tabelle 2 Security Plan für das beschriebene Szenario ............................................................ 37
Seite 41
8 Literaturverzeichnis
[Asp11] Verbundvorhaben Service Design Studio: Aspekte-Templates. Verbundprojekt Service
Design Studio, EffizienzCluster LogistikRuhr, 2011.
[Gss11] Verbundvorhaben Service Design Studio: Glossary. Version 0.9, Verbundprojekt Ser-
vice Design Studio, EffizienzCluster LogistikRuhr, 2011.
[OMG09] OMG: Service oriented architecture Modeling Language (SoaML) - Specification for the
UML Profile and Metamodel for Services (UPMS). OMG Adopted Specification, Finalisa-
tion Task Force Beta 2 document (FTF Beta 2), 2009.
[Stb11] Steinbuß, S.; Flake, S.; Drescher, J.; Iscan, H.; Müller, A.: Konzeptpapier zum Service
Design Studio. Version 1.0, Verbundprojekt Service Design Studio, EffizienzCluster
LogistikRuhr, 2011.