Vom SOM-Geschäftsprozessmodell zur vollständig dokumentenorientierten RESTful SOA - Ein modellbasierter Ansatz
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Vom SOM-Geschäftsprozessmodell zur vollständig
dokumentenorientierten RESTful SOA – Ein
modellbasierter Ansatz
Matthias Wolf und Thomas Benker
Otto-Friedrich-Universität Bamberg, Lehrstuhl für Wirtschaftsinformatik, insbes.
Systementwicklung und Datenbankanwendung, Bamberg, Germany
{matthias.wolf,thomas.benker}@uni-bamberg.de
Abstract. Serviceorientierte Architekturen dienen als Aufgabenträger zur Au-
tomatisierung von Geschäftsprozessen. Um sicherzustellen, dass diese Aufga-
benträger den Anforderungen der Geschäftsprozesse genügen, ist die modellba-
sierte Ableitung der softwaretechnischen Spezifikation, ausgehend vom Ge-
schäftsprozessmodell, notwendig. Gegenstand der vorliegenden Arbeit ist die
modellbasierte Abbildung von SOM-Geschäftsprozessen auf eine Zielarchitek-
tur, die sich durch Dokumentenorientierung und den Architekturstil
REpresentational State Transfer (REST) auszeichnet. Letzterer wird in der
jüngsten Vergangenheit vermehrt zur Realisierung serviceorientierter Architek-
turen (RESTful SOA) diskutiert. Die softwaretechnische Spezifikation sieht da-
zu Vorgangs- und Entitätsservices vor, die über http-Verben GET, PUT, POST
und DELETE mit auszutauschenden Zustandsinformationen aufgerufen werden.
Für den Austausch werden JSON-Dokumente (Java Script Object Notation)
verwendet. Die Durchgängigkeit der Dokumentorientierung wird dadurch er-
reicht, dass JSON-Dokumente nicht nur für den Austausch, sondern auch für
die persistente Verwaltung herangezogen werden. Sie bilden den zentralen
Entwicklungsgegenstand des vorgestellten modellbasierten Vorgehens, das an-
hand einer Fallstudie veranschaulicht wird.
Keywords: Modellbasierte Entwicklung, RESTful SOA, Dokumentorientie-
rung
1 Einleitung
In aktuellen Untersuchungen werden serviceorientierte Architekturen (SOA) auf Ba-
sis des Architekturstils Representational State Transfer [1] (RESTful SOA) im Unter-
nehmensumfeld intensiv diskutiert (vgl. [2-5]). SOAs im Allgemeinen dienen der
Automatisierung von Geschäftsprozessen, welche häufig mit Geschäftsprozessmodel-
len gestaltet, analysiert und dokumentiert werden. Als Technologie zur Realisierung
wird in der vorliegenden Arbeit REST zugrunde gelegt. Ein Vergleich mit
SOAP/WSDL-Services wird ausführlich in den Beiträgen [2-4] diskutiert. Die Vortei-
le des Einsatzes von REST werden dabei hinsichtlich Flexibilität, Interoperabilität
1229
11th International Conference on Wirtschaftsinformatik,
27th February – 01st March 2013, Leipzig, Germanyund Skalierbarkeit für ad-hoc Web-Integrationsszenarien im betrieblichen Umfeld
gesehen.
Bisherige Arbeiten zur Entwicklung von RESTful SOA konzentrieren sich primär
auf die softwaretechnische Spezifikation der Aufgabenträgerebene. Geschäftsprozesse
als Spezifikation der fachlichen Anforderungen auf Aufgabenebene und die davon
ausgehende modellbasierte Ableitung serviceorientierter Anwendungssysteme finden
aktuell in der Literatur nur punktuell Berücksichtigung (siehe Kapitel 2). Durch die
modellbasierte Ableitung aus Geschäftsprozessmodellen wird jedoch zum einen die
Konsistenz zwischen Implementierung und Dokumentation erhöht. Zum anderen wird
ein Beitrag zur Beherrschung der Komplexität der Entwicklungsaufgabe geleistet, der
sich ein Entwickler ausgesetzt sieht. Hierzu ist ein möglichst hochgradig
automatisierbarer modellbasierter Entwicklungsprozess anzustreben. Als Teilaufga-
ben der Entwicklung sind v.a. die Identifikation von Ressourcen (REST-Services) als
zentrale Komponenten der RESTful SOA sowie die Spezifikation zugehöriger Zu-
standsbeschreibungen in Form von Dokumenten zu nennen. Letztere sind innerhalb
von Ressourcen persistent zu verwalten und zwischen diesen auszutauschen. Als
Formate, nicht nur zum Austausch, werden häufig XML oder die JavaScript Object
Notation (JSON) genutzt [3-4]. Jüngste Entwicklungen unter dem Begriff Dokument-
datenbanken ermöglichen die Persistierung der Zustandsinformationen in der Form
ihrer Nutzung durch das Anwendungssystem. JSON-Dokumente sollen in der vorlie-
genden Arbeit das einzig zu nutzende Datenformat und einen zentralen Entwick-
lungsgegenstand bei der angestrebten modellbasierten Ableitung einer RESTful SOA
darstellen. Dies manifestiert sich in dem Begriff der vollständigen Dokumentenorien-
tierung.
Die daraus ableitbare Problemstellung dieser Arbeit lässt sich als Konstruktions-
problem nach [6] klassifizieren und innerhalb der gestaltungsorientierten Wirtschafts-
informatik nach [7] positionieren. Den Untersuchungsgegenstand bildet das modell-
basierte Entwicklungsvorgehen zur Spezifikation einer vollständig dokumentenorien-
tierten RESTful SOA ausgehend von einem Geschäftsprozessmodell. Hierzu wird das
Semantische Objektmodell (SOM) nach Ferstl und Sinz [8] zugrunde gelegt und bzgl.
des Untersuchungsziels, der methodisch geleiteten Überbrückung der semantischen
Lücke zwischen Geschäftsprozessmodell und service-orientierter Aufgabenträgerbe-
schreibung, erweitert. Der Kernbeitrag der vorliegenden Arbeit setzt sich aus zwei
wesentlichen Bestandteilen zusammen. Zum einen erfolgt die Spezifikation der SOA,
von einem Geschäftsprozessmodell ausgehend, modellbasiert. Damit lassen sich Fle-
xibilität, Nachvollziehbarkeit und der Beitrag zur Beherrschung der Komplexität der
Entwicklung service-orientierter Anwendungssysteme steigern. Zum anderen werden
die von Geschäftsprozessen zu verwaltenden Dokumente in den Mittelpunkt der Be-
trachtung gerückt, und die Ausgestaltung der SOA hinsichtlich der Vermeidung von
Medienbrüchen an diesem Entwicklungsgegenstand ausgerichtet. Wesentliche Her-
ausforderungen der Untersuchung bestehen dabei in der Spezifikation von Regeln (1)
zur Identifikation von REST-Ressourcen, (2) zur Ableitung der Zustandsbeschreibung
durch Dokumente sowie (3) zur Ableitung der softwaretechnischen Spezifikation der
RESTful SOA.
1230Die Schritte der Problemlösung Analyse der Problemstellung (Kapitel 2: Stand der
Literatur), Konzeption (Kapitel 3: Vorstellung des modellbasierten Vorgehens) und
Validierung (Kapitel 4: Vorstellung der Fallstudie und Kapitel 5: Diskussion der Er-
gebnisse) spiegeln sich in der Gliederung dieser Arbeit wieder. Im Methodenspektrum
der Wirtschaftsinformatik [9] lässt sich die Arbeit als qualitativ-konstruktiv, im Spe-
ziellen als konzeptionell-/argumentativ-deduktive Analyse, klassifizieren.
2 Stand der Literatur
REST wurde als Architekturstil für verteilte Systeme in der Dissertation von Roy
Fielding [1] vorgestellt. Darin wird u. a. spezifiziert, wie existierende Web-Protokolle
verwendet werden können, um Web-Services zu realisieren [3]. Der Architekturstil
REST ist dabei durch folgende vier Prinzipien charakterisiert: (1) Als zentrale Kom-
ponenten werden Objekttypen und ihre Funktionalität als Ressourcen mit eindeutiger
Identifikation (URI) bereitgestellt. (2) Aus Außensicht weisen diese Ressourcen eine
einheitliche Schnittstelle in Form der http-Operatoren GET (lesen), PUT (aktualisie-
ren), DELETE (löschen) und POST (erzeugen) auf. (3) Für die Darstellung ihrer Zu-
stände kann eine Ressource in mehreren Repräsentationen vorliegen. Diese werden
häufig in Dokumentformaten wie XML, HTML, CSV oder JSON verwaltet. (4) Be-
ziehungen zwischen Ressourcen werden über das Konzept der Links (Verknüpfun-
gen) realisiert. Im Rahmen von Serviceaufrufen können diese u.a. auch zur Steuerung
der Anwendungslogik genutzt werden. Im Zusammenhang mit der Anwendung der
beschriebenen Prinzipien steht auch die Forderung nach zustandsloser Kommunikati-
on. REST sieht für Anfragen an Ressourcen vor, die für die Verarbeitung benötigten
Zustandsinformationen als Parameter im Kontext der Anfrage mit zu übergeben.
Eng verbunden mit dem Architekturstil REST ist das Konzept der ressourcenorien-
tierten Architektur (ROA). Overdick [10] charakterisiert eine ROA als SOA, welche
den REST-Prinzipien genügt, also (all) ihre Entitäten (nicht nur Web-Services) als
Ressource expliziert und somit global identifizier- und ansprechbar macht. Die Forde-
rung der einheitlichen Schnittstelle ist eine weitere Einschränkung der klassischen
SOA. Auch die im vorliegenden Beitrag entwickelte RESTful SOA ist demzufolge als
ressourcenorientierte Architektur klassifizierbar und folgt mit dieser Einordnung auch
dem Verständnis von Richardson und Ruby [4].
Mit der Modellierung und modellbasierten Entwicklung der Komponenten einer
RESTful SOA beschäftigt sich eine Reihe von Arbeiten. Die dort beschriebenen An-
sätze werden anhand folgender Kriterien analysiert: (1) Erfolgt die Identifikation von
Ressourcen bzw. Dokumenten modellbasiert? (2) Auf welchen Modellebenen wird
die RESTful SOA spezifiziert? (3) Erfolgt der Übergang zwischen den Modellebenen
modellbasiert?
Den Ausgangspunkt für die Identifikation von Ressourcen bilden zum einen natür-
lich-sprachliche Beschreibungen, wie fachliche Anforderungen [3-4] oder Beschrei-
bungen von Web-Service-Funktionalitäten [11]. Zum anderen erfolgt eine Ressour-
cenidentifikation auf Basis von Modellen durch die Analyse von Aktionen in
Workflowschemata [12], [5] oder der funktionalen Beschreibung von Interaktionen in
1231einem Schema [13]. Dieses Vorgehen setzt damit bereits spezifizierte Client-Server–
Interaktionen auf der Aufgabenträgerebene voraus. Die Ableitung selbst wird hier
natürlich-sprachig erläutert.
Dokumente werden in den untersuchten Beiträgen primär unter dem Gesichtspunkt
der Ableitung von Repräsentationsformaten diskutiert. Sie werden auf Basis von Res-
sourcenspezifikationen der REST-Anwendung (meist als Klassendiagramm) entwi-
ckelt [11-14]. Auch werden alternative Repräsentationsformate und Best Practices für
die Dokumentenbeschreibung vorgestellt und diskutiert [3-5].
Die Spezifikation einer RESTful SOA beginnt in bestehenden Ansätzen meist auf
der softwaretechnischen Ebene. Einerseits werden hierfür eigene Metamodelle für die
Ressourcenbeschreibung entwickelt [15]. Andererseits erfolgen Struktur- bzw. Ver-
haltensspezifikationen der ROA mit (erweiterten) UML-Diagrammen [3], [11], [13-
14]. Der Übergang auf und die Beschreibung der Implementierungsebene erfolgen
durch die Ableitung von Schnittstellenbeschreibungen von Ressourcen unter Verwen-
dung der Web Application Description Language (WADL) [11], [13] oder eigener
Komponentenspezifikationen [14]. Zudem werden für die detaillierte Spezifikation
von Softwarearchitektur und Implementierung der RESTful SOA eine Vielzahl an
Hinweisen, Pattern und Best Practices bereitgestellt [3-4]. Die Überwindung der Lü-
cke zwischen den Ebenen der Softwarearchitektur und der Implementierung erfolgt in
den betrachteten Ansätzen nur teilweise regelbasiert.
Bezugnehmend auf die drei anfangs formulierten Kriterien ist zusammenfassend
festzuhalten, dass in den betrachteten Arbeiten (1) die Identifikation von Ressourcen
nicht auf Basis von Geschäftsprozessmodellen auf der Aufgabenebene erfolgt. Die
Ressourcenidentifikation erfolgt durch Analyse natürlich-sprachiger Beschreibungen
oder Workflow-/Interaktionsschemata. (2) Die Untersuchung der Entwicklung von
RESTful SOA konzentriert sich primär auf die Spezifikation der softwaretechnischen
Ebene. (3) Die meisten Ansätze beschreiben zudem einen modellbasierten Übergang
hin zur Implementierung. Eine Betrachtung der Aufgabenebene in Form von Ge-
schäftsprozessen findet nicht statt. Auch wird die Beziehung zwischen Aufgaben, die
mit der SOA automatisiert werden sollen, und den korrespondierenden Komponenten
der RESTful SOA unzureichend betrachtet. Die aufgezeigte semantische Lücke zwi-
schen den Abstraktionsebenen der Geschäftsprozesse und der softwaretechnischen
Spezifikation soll mit der vorliegenden Arbeit verringert werden.
3 Modellbasierte Spezifikation einer dokumentenorientierten
RESTful SOA
Zielsetzung der vorliegenden Arbeit ist die modellbasierte Ableitung einer software-
technischen Spezifikation zur Automatisierung von Geschäftsprozessen durch eine
dokumentenorientierte RESTful SOA. Als methodische Grundlage wird das Semanti-
sche Objektmodell (SOM) nach Ferstl und Sinz [8] gewählt. Die SOM-Methodik
beinhaltet einen objekt- und geschäftsprozessorientierten Modellierungsansatz, der
einen Geschäftsprozess sowohl auf Aufgaben- als auch auf Aufgabenträgerebene
struktur- und verhaltensorientiert beschreibt. Die SOM-Methodik bildet das modell-
1232basierte Fundament der vorliegenden Arbeit, weil durch die explizite Spezifikation
der strukturorientierten Sicht auf unterschiedlichen Ebenen ein wichtiges Instrument
zur Identifikation und Spezifikation von Artefakten (Dokumente, Ressourcen) bzgl.
der vorliegenden Zielsetzung bereitgestellt wird. Das in diesem Abschnitt nun detail-
liert vorgestellte Vorgehen kann zudem an eine bestehende modellbasierte Methodik
anknüpfen und diese um eine plattformspezifische Ebene erweitern. Abbildung 1
zeigt die Modellarchitektur einschließlich der Erweiterung zur softwaretechnischen
Beschreibung einer dokumentenorientierten RESTful SOA:
Geschäftsprozessmodellebene E1: Die SOM-Methodik sieht auf Aufgabenebene
die Spezifikation von Geschäftsprozessen anhand einer Struktur- (Interaktionsschema,
IAS) und einer Verhaltenssicht (Vorgangs-Ereignis-Schema, VES) vor. Die Koordi-
nation betrieblicher Objekte mittels Transaktionen wird im IAS erfasst. Das VES
beschreibt die Durchführung der korrespondierenden Aufgaben als Ablaufdiagramm.
Struktursicht Verhaltenssicht
(E1) Geschäftsprozessmodellebene
Produkt- Liefe-
>Auftrag
A: Produktinfo. info.> rung>
Handel Handel Handel
Handels- V: Auftrag
Kunde A D
unternehmen D: Lieferung V
>Produkt- >Liefe-
Auftrag>
info. rung
IAS Kunde Kunde Kunde
VES
Transformation T1 (E1 zu E2)
(E2) Fachliche Anwendungs- Güter- Produkt- Liefe-
modellebene distribution
Produktinfo. Auftrag Lieferung
info.>
>Auftrag
rung>
Handels-
unternehmen
>Produkt- >Liefe-
KOS info.
Auftrag>
rung VOS
Kunde
Transformation T2
A1 A2 A4 A3
(E2 zu E3)
Res. URI Op. Auftragsabwicklung
transient Kunde
\ portal\ produkt\ get, post
Produktinfo {„Datum“:““, „KdName“:““, ...} Produkt \ portal\ produkt\ {nr} get,put,delete
Lieferung {Doc_Auftrag, Doc_Produkt, ...} Auftrag Auftrag
\ portal\ auftrag\ get, post Auftrag
Prüfung
Bestäti-
\ portal\ auftrag\ {nr} get,put,delete empfangen gung
\ portal\ kunde\ get, post
Kunde \ portal\ kunde\ {nr} get,put,delete
persistent Produkt
\ portal\ auftrabw\ get, post
Kunde: {„KdNr“:““, „KdName“:““, ...} Auftr.abw. \ portal\ auftrabw\ {nr} get,put,delete
Auftrag {„AufNr“:““, „AufBez“:““, ...} ... ... ...
...
Produkt {„ProdNr“:““, „ProdBez“:““, ...}
... Ressourcenschema Vorgangsservices / BPMN-Schema
Dokumentenstruktur Entitätsservices
(E3) Plattformspezifische REST-Architekturmodellebene
Abb. 1. Erweiterte Modellarchitektur der SOM-Methodik
Fachliche Anwendungsmodellebene E2: Auf Basis der Geschäftsprozessspezifikation
wird ein plattformunabhängiges objektorientiertes Modell des Anwendungssystems
(AwS), ebenfalls bestehend aus Struktur- (konzeptuelles Objektschema, KOS) und
Verhaltenssicht (Vorgangsobjektschema, VOS), modellbasiert abgeleitet. Das KOS
differenziert seine Objekttypen nach ihrem Ursprung im Geschäftsprozessmodell als
leistungs-, objekt- oder transaktionsspezifisch. Für die Erläuterung der Schritte von
Transformation T1 (E1 zu E2) sowie die zugehörige Schemakonsolidierung sei auf
die Ausführungen in [8], [16] verwiesen.
1233REST-Architekturmodellebene E3: Die plattformspezifische Aufgabenträgerebene
beschreibt die Erweiterung der SOM-Architektur zur Spezifikation einer dokumen-
tenorientierten RESTful SOA durch Vorgangs- und Entitätsservices, die notwendigen
transienten und persistenten Dokumente sowie die Schnittstellenspezifikation der
Ressourcen. Die Transformation T2 der Objekttypen aus KOS und VOS (auf E2) in
die Modellbausteine der Ebene E3 wird modellbasiert durch vier Ableitungsschritte
(A1: Identifikation und Spezifikation von Dokumenten, A2: Identifikation und Spezi-
fikation von Entitätsservices, A3: Identifikation und Spezifikation von Vorgangsser-
vices, A4: Spezifikation des Ressourcenschemas) regelbasiert beschrieben. Die Mo-
dellebene (E3) und die Spezifikation der Transformation T2 stellen die Erweiterung
der SOM-Methodik dar. Grundlage hierzu bildet die Arbeit von Wolf [16]. Das dort
vorgestellte, fachlich orientierte Vorgehen wird um softwaretechnische Artefakte
erweitert und hinsichtlich der Implementierung detailliert. Die Ableitungsschritte und
zugehörigen Regeln werden nachfolgend zunächst allgemein eingeführt und im an-
schließenden Kapitel 4 anhand einer Fallstudie verdeutlicht:
Ableitungsschritt A1: Identifikation und Spezifikation von persistenten und tran-
sienten Dokumenten. Dokumente stellen den zentralen Entwicklungsgegenstand der
vorliegenden Arbeit dar. In einer RESTful SOA werden diese einerseits transient zum
Austausch zwischen Ressourcen (Vorgangs- und Entitätsservices), andererseits zur
persistenten Verwaltung des Ressourcenzustands verwendet. In beiden Fällen werden
die Dokumente über das Repräsentationsformat JSON beschrieben. Dieses eignet sich
auch für die dokumentorientierte persistente Speicherung. In einem ersten Schritt
werden Dokumente auf Grundlage des plattformunabhängigen KOS identifiziert und
deren Struktur (Dokumenttyp) festgelegt. Hierzu wird dokumentenorientiert konsoli-
diert. Die Bildung von persistenten Dokumenten orientiert sich dabei an dem Grund-
satz nach [17] (S. 13-24), Daten auf Grundlage ihrer gemeinsamen Nutzung zu Do-
kumenten zu aggregieren. Daten, die in einer ACID-Transaktion gemeinsam behan-
delt werden, sind demzufolge in einem gemeinsamen Dokument abzubilden. Zur
weiteren Klassifikation erfolgt die Unterscheidung von persistenten Dokumenten
nach Stamm- (A1a) bzw. Transaktionsdaten (A1b):
(A1a) Stammdatendokumente leiten sich aus den linksstehenden Objekttypen des
KOS ab. Als von einem konkreten Geschäftsvorfall existenzunabhängige Objekttypen
treten diese als objektspezifische oder leistungsspezifische Objekttypen auf. Damit
werden Daten der am Geschäftsprozess beteiligten betrieblichen Objekte bzw. der
Leistungsspezifikation beschrieben. Diesen werden Attribute zugeordnet und festge-
legt, ob sie dauerhaft zu speichern sind. Je dauerhaft zu speichernden Objekttyp wird
ein korrespondierender Stammdatendokumenttyp abgeleitet.
(A1b) Transaktionsdokumente bilden einen konkreten Geschäftsvorfall (Leistungs-
erstellung und deren Koordination) ab. Zur Ableitung der Dokumenttypen werden alle
existenzabhängigen transaktionsspezifischen Objekttypen des KOS betrachtet, ihre
Dokumentenstruktur spezifiziert sowie die Persistenzeigenschaft (transient = t, persis-
tent = p) festgelegt. Diese Objekttypen werden als Nachrichten interpretiert, die wäh-
rend der Durchführung des Geschäftsprozesses zur Koordination der Leistungserstel-
lung zwischen den beteiligten betrieblichen Objekten ausgetauscht werden. Alle als
persistent markierten Objekttypen dienen zudem der Identifikation persistent zu spei-
1234chernder Dokumente. Ein persistentes Transaktionsdokument stellt die Aggregation
ausgetauschter Daten zur Koordination einer Leistungserstellung (D-Transaktion des
Geschäftsprozessmodells auf detaillierter Ebene) dar. Das Schreiben und das Lesen
von Transaktionsdaten erfolgt somit ausschließlich basierend auf einem Dokument.
Ein Beispiel für unterschiedliche Transaktionsdokumenttypen innerhalb eines Ge-
schäftsvorfalls stellen die Koordination und Durchführung der eigentlichen Leis-
tungserstellung und die Abwicklung der Abrechnung dar.
Zur Abbildung des Ressourcenzustands wird jedem Transaktionsdokument ein At-
tribut „_STATUS“ zugewiesen und zulässige Statusausprägungen aus dem initialen
KOS sowie der Ablaufspezifikation auf Aufgabenträgerebene abgeleitet. Die Ablei-
tungsregeln der Stamm- und Transaktionsdatendokumente fasst Tabelle 1 zusammen.
Tabelle 1. Ableitungsregeln der dokumentenorientierten Konsolidierung des KOS
KOS Dokumenttyp p/t
Objektspezifischer Objekttyp Stammdatendokument p
Leistungsspezifischer Objekttyp Stammdatendokument p
Aggregation zu Transaktionsdatendoku-
Transaktionsspezifischer Objekttypen p/t
ment (differenziert nach Status)
Ableitungsschritt A2: Identifikation und Spezifikation von Services zur Verwaltung
der Dokumente. Es werden Services identifiziert, die der Verwaltung, also Speiche-
rung von und Zugriff auf die Repräsentation persistenter Dokumente dienen. Diese
werden im Folgenden als Entitätsservices bezeichnet und als Ressourcen interpretiert.
Für jeden in Schritt A1 identifizierten Dokumenttyp wird zu diesem Zweck ein Ser-
vice spezifiziert. Aus Innensicht wird je zulässigem http-Verb ein Lösungsverfahren
basierend auf Attributausprägungen der übergebenen Dokumente spezifiziert. Für
Entitätsservices zur Verwaltung von Transaktionsdaten sind die Ausführungsstatus
der Transaktion als Zustandsautomat zu berücksichtigen. Über das Attribut
„_STATUS“ werden je nach Operation zu lesende bzw. schreibende Daten und zum
jeweiligen Zeitpunkt gültige und zu prüfende Integritätsbedingungen festgelegt.
Ableitungsschritt A3: Identifikation und Spezifikation von Services zur Vorgangs-
steuerung. Vorgangsservices sind zur Realisierung der Geschäftslogik notwendig und
können ebenfalls als Ressource nach dem REST-Verständnis interpretiert werden. Die
Funktionalität wird aus Außensicht dementsprechend über eine REST-Schnittstelle
angeboten und in Webclient-basierten Anwendungssystemen aus der Kommunikati-
onsschicht heraus aufgerufen. Die Identifikation der Vorgangsservices erfolgt in An-
lehnung an die Arbeit von Krücke und Sinz [18]. Vorgangsservices werden hier an-
hand von Message Exchange Patterns (MEP) [19] innerhalb des VOS abgegrenzt. Als
relevant werden die Muster In-Out (Request-Response) und In-Only angesehen, über
die die Kommunikation zwischen Servicenutzer und Serviceanbieter beschrieben
wird. Aus Innensicht wird der identifizierte Service unter Verwendung einer ausführ-
baren Workflowsprache, im Fall der vorliegenden Arbeit mit BPMN (Business Pro-
cess Model and Notation, [20]) beschrieben. Dabei werden die unter Schritt (A2)
identifizierten Entitätsservices durch REST-Aufrufe orchestriert.
1235Ableitungsschritt (A4): Spezifikation des Ressourcenschemas. Das Ressourcen-
schema spezifiziert einerseits die Schnittstellen einer RESTful-SOA mit URI, Zu-
griffsoperatoren und Dokumentenstruktur für jede abgeleitete Ressource und dient
andererseits der Ergebnisdokumentation parallel zu den Schritten (A1) bis (A3). Als
Ressourcen werden Entitäts- und Vorgangsservices unterschieden. Ihre Bereitstellung
erfolgt dabei jeweils als Listen- und Individualressource. Listenressourcen bieten
Zugriff auf alle Instanzen, Individualressourcen auf eine konkrete Instanz eines Res-
sourcentyps. Für den Zugriff auf eine Ressource sind, dem REST-Paradigma folgend,
aus Außensicht die zulässigen http-Verben festzulegen. Standardmäßig werden als
Operatoren für Ressourcenlisten GET und POST festgelegt. GET ermöglicht das Ab-
fragen der Instanzen, POST das Anlegen neuer Instanzen. Dies gilt sowohl für das
Anlegen neuer Entitäten als auch das Starten eines neuen Vorgangs. Die Abfrage und
Manipulation ausgewählter Instanzen erfolgt über die Schnittstelle der Individualres-
source mit GET, PUT und DELETE. Abschließend ist eine URI je Ressource zu spe-
zifizieren. Diese setzt sich aus der (optionalen) Angabe des Hosts als möglichen Ein-
stiegspunkt und Wurzel der REST-Anwendung sowie den Namen der Ser-
vices/Ressourcen zusammen. Die Angabe der {id} identifiziert eine Instanz. Über den
Status lassen sich Ressourcen nach dem Ausführungsstand filtern. Die Dokumenten-
struktur, die für Stamm- und Transaktionsdaten festgelegt wurde (A1), bildet die
Grundlage für die Beschreibung der Dokumentenstruktur, die eine Ressource emp-
fangen und senden kann. Tabelle 2 fasst die Ableitungsregeln für das Ressourcen-
schema zusammen.
Tabelle 2. Ableitungsregeln Ressourcenschema
Quelle Ressource URI Operator Dokument
Entitätsservice Liste \host\servicename\ get, post
(Stammdaten) Individual \host\servicename\{id}\ get, put, delete
\host\servicename\ JSON {…}
Entitätsservice Liste get, post
?status=transact.status Definition
(Transaktions-
\host\servicename\{id}\ der Struktur
daten) Individual get, put, delete
?status=transact.status nach (A1)
Liste \host\servicename\ get, post
Vorgangsservice
Individual \host\servicename\{id} get, put, delete
4 Fallstudie
Anhand einer Fallstudie wird nachfolgend das in Kapitel 3 beschriebene Vorgehen
zur Ableitung der softwaretechnischen Spezifikation einer dokumentenorientierten
RESTful SOA veranschaulicht und die Anwendbarkeit nachgewiesen.
12364.1 Einführung der Fallstudie
Gegenstand der Fallstudie ist der Geschäftsprozess einer Flugvermittlung. Die Dienst-
leistung wird über ein Online-Portal erbracht und beinhaltet das Vermitteln von Flü-
gen einschließlich der Abfrage von Fluginformationen und der Reservierung.
Der Ablauf des Geschäftsprozesses lässt sich wie folgt grob skizzieren: Nachdem
der Kunde eine Suchanfrage an das Flugportal gestellt und die Ergebnisse durchgese-
hen hat, kann er einen Flug auswählen. Wurden die Suchergebnisse noch aus dem
lokalen Datenbestand bedient, erfolgt jetzt bei der Fluglinie die Abfrage aktueller und
gesicherter Fluginformationen durch das Flugportal. Auf diesen Informationen auf-
bauend wird ein Angebot erstellt und dem Kunden übermittelt. Nach erfolgter Bu-
chung des Angebots werden die Plätze bei der Fluglinie reserviert und der Kunde
erhält abschließend eine Bestätigung sowie Buchungsunterlagen. Die Struktur des
Geschäftsprozesses stellt Abbildung 2 als IAS und die dazu korrespondierende Ver-
haltenssicht als VES dar.
Abb. 2. Geschäftsprozessmodell der Fallstudie Flugvermittlung
Die Schritte Vereinbarung (V) und anschließende Durchführung (D) der Flugvermitt-
lung werden in Form betrieblicher Transaktionen erfasst. Diese Transaktionen stellen
Kommunikationsbeziehungen zwischen den beteiligten betrieblichen Objekten dar
und weisen auf ausgetauschte Informationen hin. Über Transaktion V12 wird bei-
spielsweise eine Liste mit Flügen (Suchergebnis) von dem Flugportal an den Kunden
übermittelt. Die daran beteiligten Aufgaben werden im VES erfasst und sind „Such-
ergebnis senden“ (Flugportal: Suchergeb. >) sowie „Suchergebnis empfangen“ (Kun-
de: > Suchergeb.).
1237Der modellierte Geschäftsprozess wird nun in eine fachliche AwS-Spezifikation
transformiert, welche als Ausgangsbasis für die Identifikation und die Spezifikation
von Dokumenten, Entitätsservices und Vorgangsservices verwendet wird.
Das IAS wird in ein initiales konzeptuelles Objektschema (KOS) transformiert.
Hierbei werden die beteiligten betrieblichen Objekte (Kunde, Flugportal und Flugli-
nie) sowie die erbrachte Leistung (Flugvermittlung) links im KOS als existenzunab-
hängige Objekttypen angeordnet. Die Transaktionen werden entsprechend dem Ab-
lauf ihrer Ausführung als transaktionsspezifische Objekttypen rechts davon angeord-
net. Die Verhaltenssicht des Anwendungsmodells wird im Vorgangsobjektschema
(VOS) dargestellt. Hierzu wird jede Aufgabe des VES in einen Vorgangsobjekttyp
transformiert und die Schnittstellen zu den aufrufenden oder aufgerufenen betriebli-
chen Objekten bestimmt. In der Fallstudie werden die Aufgaben des Flugportals au-
tomatisiert, weshalb nur dessen Vorgangsobjekttypen im Folgenden zu betrachten
sind. Die Ergebnisse der initialen Ableitung von KOS und VOS zeigt Abbildung 3.
Abb. 3. Plattformunabhängige AwS-Spezifikation der Flugvermittlung
4.2 Identifikation und Spezifikation von Dokumenten (A1)
Ausgehend vom initialen konzeptuellen Objektschema (Abb.3) wird die dokumenten-
orientierte Konsolidierung mit den Schritten (A1a) Ableitung von Stammdatendoku-
menten sowie (A1b) Ableitung von Transaktionsdatendokumenten vorgenommen:
(A1a) In Tabelle 3 wird das Ergebnis der Konsolidierung der Stammdaten darge-
stellt. Kunde und Fluglinie beschreiben Geschäftspartner, die im Rahmen der Durch-
führung des Geschäftsprozesses kontaktiert werden und über das Flugportal Leistun-
gen anbieten bzw. abrufen. Das Flugportal an sich dient der Vermittlung von Flügen,
die lokal verwaltet werden. Insofern besteht für das Flugportal die Notwendigkeit zur
Spezifikation und Speicherung eines Dokumenttyps „Flug“. Der Objekttyp „Flugver-
mittlung“ ergibt sich aus der eigentlichen Leistung, die das Flugportal gegenüber dem
Kunden erbringt. Diese Leistung lässt sich anhand verschiedener Bestandteile, wie
1238Kostensätze, AGBs usw. näher beschreiben. Zur persistenten Verwaltung dieser Leis-
tungsspezifikation wird ebenfalls ein eigener Dokumenttyp erzeugt.
Tabelle 3. Ergebnis der Stammdatenkonsolidierung
Objekttyp Persistent? Dokumentttyp Dokumentformat
Kunde Ja Kunde Kundennummer, Name, Anschrift, usw.
FlugNr., Start-/Zielzeit, Start-/Ziel-
Flugportal Ja Flug
flughafen, Plätze usw.
LinienNr., Bezeichnung, Anschrift, Kon-
Fluglinie Ja Fluglinie
taktdaten, usw.
Flugver- Rahmenbedingungen zur Flugvermitt-
Ja AGB
mittlung lung: Kosten, Rücktritt, usw.
(A1b) Zur Identifikation von Transaktionsdatendokumenten werden die
Persistenzeigenschaften (transient = t, persistent = p) der transaktionsspezifischen
Objekttypen festgelegt (vgl. Tabelle 4). Die dabei als persistent markierten Doku-
menttypen werden zur Bildung des persistenten Transaktionsdatendokumenttyps
„FlugBuchung“ aggregiert. Als Struktur ergibt sich somit das folgende Dokument-
format: Transaktionsnummer (TNr), Status, Datum, Kundendaten (siehe Dokument-
typ „Kunde“), Flugdaten (siehe Dokumenttyp „Flug“). Die Überprüfung der Daten-
konsistenz obliegt den Entitätsservices, die nachfolgend in Abschnitt 4.3 vorgestellt
werden.
Tabelle 4. Analyse transaktionsspezifischer Objekttypen
Objekttyp Dokumentstruktur p/t
Suche Datum, Uhrzeit, Start-/Zielflughafen t
Suchergebnis Liste mit Flügen (siehe Dokumenttyp Flug) t
Flugwahl TNr, Flug, _Status = „FLUG-AUSGEWAEHLT“ p
Flugstatus Flugnummer t
Flugdaten TNr, Flug, _Status = „FLUGSTATUS-GEPRUEFT“ p
Angebot TNr, Flug, _Status = „FLUG-ANGEBOTEN“, Datum p
Buchung TNr, Flug, _Status = „FLUG-GEBUCHT“, Datum, Kunde p
Reservierung TNr, Flug, _Status = „FLUG-RESERVIERT“, Datum, Kunde p
Reservierungsbestä- TNr, Flug, _Status = „BUCHUNG-BESTAETIGT“, Datum,
tigung Kunde p
Best./Unterlagen Flug, Kunde t
4.3 Identifikation und Spezifikation von Entitätsservices (A2)
Für jeden unter Schritt (A1) identifizierten Dokumenttyp wird ein Entitätsservice
erzeugt und die zulässigen http-Operatoren festgelegt. Dienste zur Stammdatenver-
waltung ergeben sich für die Dokumenttypen „Flug“ (GET, PUT, POST), „Kunde“
(GET, PUT, POST), „Fluglinie“ (GET) und „AGBs“ (GET). Die Zugriffsoperatoren
ergeben sich durch Analyse der Ablaufspezifikation im VOS (Abb. 3) und dem Kon-
text der Servicenutzung. So kann es während der Ausführung des Geschäftsprozesses
1239nur zum lesenden Zugriff auf die Dokumente „Fluglinie“ und „AGB“ kommen. Das
Löschen von Stammdaten im Rahmen des Geschäftsprozesses ist nicht vorgesehen.
Zur Verwaltung von Transaktionsdaten wird ebenfalls ein Entitätsservice angelegt.
Für Dokumente des Typs „FlugBuchung“ ist lesender (GET), schreibender (POST,
PUT) und löschender (DELETE) Zugriff zu definieren. Die zulässigen Status der
Ressource zur Steuerung des Lösungsverfahrens sind in Tabelle 4 mit hinterlegt.
4.4 Identifikation und Spezifikation von Vorgangsservices (A3)
Auf Basis des initialen VOS aus Abbildung 3 werden die Vorgangsservices der
RESTful SOA identifiziert (A3a) und ihre Innensicht spezifiziert (A3b).
Nach den Message Exchange Pattern „In-Out“ und „In-Only“ werden für die Fall-
studie die Vorgangsservices „Suche“, „Angebot“ und „Buchung“ identifiziert. Über
diese findet die vom Kunden initiierte Interaktion mit selbigem statt. Die Vorgangs-
objekttypen des VOS werden bei der Spezifikation der Innensicht detaillierter be-
schrieben. Ein Kunde nutzt z. B. den Buchungsservice durch das Starten einer neuen
Vorgangsserviceinstanz mit POST auf „\flugportal\angebot\“ und Übergabe der kor-
respondierenden Dokumentdaten „FlugBuchung“.
Abb. 4. Schema der Vorgangsservices und Ausschnitt des Lösungsverfahrens (BPMN)
Für das Beispiel wird ein Ausschnitt der Innensicht (Lösungsverfahren) zum Vor-
gangsservice „Angebot“ betrachtet (vgl. Abbildung 4). Die Funktionalität zur Erstel-
lung des Angebots für den Kunden beginnt mit dem Lesen der Flugdaten mittels GET
auf die Ressource „\flugportal\flug\{id}“ sowie dem Lesen und Prüfen der Kundende-
tails (GET auf „\flugportal\kunde\{nr}“). Zur Erstellung des Angebots wird die kor-
respondierende Flugbuchung durch PUT und Übergabe eines Dokuments mit den
erstellten Angebotsdaten aktualisiert. Als Antwort auf seine Anfrage erhält der Kunde
die URI auf das neu erstellte Angebot.
12404.5 Spezifikation des Ressourcenschemas (A4)
Für die Fallstudie ergibt sich das in Tabelle 5 dargestellte Ressourcenschema. Als
Host wird „\flugportal\“ festgelegt. Die Entitätsservices der Stammdaten „Flug“,
„Kunde“, „Fluglinie“ (betriebliche Objekte) und „AGB“ (Leistung) werden jeweils
als Listen- und Individualressource bereitgestellt. Der Zugriff auf die Fluglinie und
die AGBs erfolgt dabei nur lesend (vgl. Abschnitt 4.3). Der Entitätsservice „FlugBu-
chung“ verwaltet die Flugbuchungstransaktion anhand ihrer Status. Entsprechend ist
der Stand einer Flugbuchung nach Status geordnet zugreif- und manipulierbar. Die
Vorgangsservices „Suche“, „Angebot“ und „Buchung“ werden ebenfalls als Listen-
und Individualressourcen bereitgestellt.
Tabelle 5. Ressourcenschema der Fallstudie
Ressource URI Operator Dokument
\flugportal\flug\ get, post
Flug
\flugportal\flug\{id} get, put, delete
\flugportal\kunde\ get, post
Kunde
\flugportal\kunde\{id} get, put, delete
\flugportal\fluglinie\ get
Fluglinie
\flugportal\fluglinie\{id} get
AGBs \flugportal\AGBs\ get
JSON {…}
\flugportal\flugbuchung\ get, post
FlugBuchung vgl. Tab. 3
\flugportal\flugbuchung\{id} get, put, delete
FlugBuchung \flugportal\flugbuchung\?status=X get, post
(je Status) \flugportal\flugbuchung\{id}\?status=X get, put, delete
\flugportal\suche\ get, post
Suche
\flugportal\suche\{id} get, put, delete
\flugportal\angebot\ get, post
Angebot
\flugportal\angebot\{id} get, put, delete
\flugportal\buchung\ get, post
Buchung
\flugportal\buchung\{id} get, put, delete
5 Zusammenfassung der Ergebnisse und Ausblick
In der Arbeit wird ein mehrstufiger modellbasierter Ansatz vorgeschlagen, der die
schrittweise Ableitung der plattformspezifischen Beschreibung einer dokumentorien-
tierten RESTful SOA ausgehend von SOM-Geschäftsprozessmodellen zum Gegen-
stand hat. Hierzu wird ein methodisch geleitetes Vorgehen zur Spezifikation von
Vorgangs- und Entitätsservices vorgeschlagen, das das Dokument als Entwicklungs-
artefakt in den Mittelpunkt rückt. Beide Servicearten werden als Ressourcen im
REST-Sinne interpretiert und sind über http-Verben und transiente JSON-Dokumente
aufrufbar. Entitätsservices dienen der Verwaltung von Stamm- und Transaktionsda-
ten. Sie gehen aus persistenten Dokumenten hervor, die mittels dokumentenorientier-
ter Konsolidierung des konzeptuellen Objektschemas abgeleitet werden. Die Konzep-
te des SOM-Geschäftsprozesses werden dabei über drei Abstraktionsebenen hinweg
modellbasiert in dazu korrespondierende Bausteine der REST-Architektur überführt.
1241Das Geschäftsprozessmodell stellt somit nicht nur eine zur Implementierung konsis-
tente Dokumentation dar, sondern auch den Ausgangspunkt des Entwicklungsprozes-
ses. Das bereitgestellte Regelwerk unterstützt den Entwickler bei der Bewältigung
Komplexität zur Überbrückung der semantischen Lücke zwischen Geschäftsprozess
und softwaretechnischer Spezifikation. Dazu trägt nicht zuletzt die Trennung von
struktur- und verhaltensorientierter Sicht auf den verschiedenen Modellebenen der
SOM-Methodik bei. Über eine Fallstudie wird das Vorgehen näher erläutert und die
Anwendbarkeit aufgezeigt. Die Skalierbarkeit des beschriebenen Ansatzes auf kom-
plexere Anwendungsszenarien wird durch SOM als modellbasierter Geschäftspro-
zessmodellierungsansatz über Aufgaben- und Aufgabenträgerebene mit REST als
Zielarchitektur der SOA gefördert. Gerade REST zielt als Architekturstil auf den
Entwurf verteilter Architekturen für hoch-skalierbare Systeme, z. B. dem WWW, ab.
Anhand des beschriebenen Regelwerks wurde ein Prototyp am Fallbeispiel imple-
mentiert und erfolgreich gegen seine Anforderungen validiert. In diesem Rahmen
wurden auch Technologien hinsichtlich der Unterstützung von REST und Dokumen-
tenorientierung evaluiert. Vorgangsservices wurden mit BPMN auf der Plattform
Activiti1, Entitätsservices auf Basis von Java EE und dessen API JAX-RS2 implemen-
tiert. Zur Realisierung der durchgängigen Dokumentenorientierung wurde das doku-
mentenorientierte Datenbanksystem Couchbase3 ausgewählt, das zur Datenverwal-
tung ebenfalls das Format JSON nutzt. Somit wird der Bruch zwischen Anwendungs-
logik und relationaler Datenhaltung vermieden.
Künftige Forschungsarbeiten lassen sich an den Eckpunkten der vorliegenden Ar-
beit identifizieren. Zur Erhöhung des Automatisierungsgrades der Entwicklung sollte
der Ansatz hinsichtlich einer metamodellbasierten Integration der Modellebenen er-
weitert werden. Ausgehend von den Ergebnissen bzgl. persistenter Dokumente sind
Dokumentdatenbanken als Basistechnologie sowie Einsatzmöglichkeiten und Archi-
tekturen von nicht-relationalen Datenbanken in Unternehmen, wie auch von McKin-
sey [21] motiviert, zu untersuchen.
Literatur
1. Fielding, R.T.: Architectural styles and the design of network-based software architectures.
PhD thesis, University of California, Irvine (2000)
2. Pautasso, C., Leymann, F., Zimmermann, O.: Restful web services vs. "big"' web services.
In: Proceedings of the 17th international conference on World Wide Web - WWW '08,
p. 805-814. ACM Press (2008)
3. Tilkov, S.: REST und HTTP. Einsatz der Architektur des Webs für Integrationsszenarien.
dpunkt, Heidelberg, Neckar (2011)
4. Richardson, L., Ruby, S.: RESTful web services. O'Reilly, Farnham (2007)
1
Activiti BPM Plattform (http://activiti.org/)
2
JAX-RS (http://jcp.org/en/jsr/detail?id=311)
3
Couchbase (http://www.couchbase.com/)
12425. Erl, T., Carlyle, B., Pautasso, C., Balasubramanian, R.: SOA with REST. Principles, pat-
terns & constraints for building enterprise solutions with REST. Prentice Hall, Upper Sad-
dle River, NJ (2013)
6. Sinz, E.J.: Konstruktionsforschung in der Wirtschaftsinformatik: Was sind die Erkenntnis-
ziele gestaltungsorientierter Wirtschaftsinformatikforschung? In: Österle, H., Winter, R.,
Brenner, W. (eds.): Gestaltungsorientierte Wirtschaftsinformatik. Ein Plädoyer für Rigor
und Relevanz. Infowerk, Nürnberg (2010)
7. Österle, H., Becker, J., Frank, U., Hess, T., Karagiannis, D., Krcmar, H., Loos, P., Mer-
tens, P., Oberweis, A., Sinz, E.J.: Memorandum zur gestaltungsorientierten Wirtschaftsin-
formatik. Zeitschrift für betriebswirtschaftliche Forschung, 664–669 (2010)
8. Ferstl, O.K., Sinz, E.J.: Grundlagen der Wirtschaftsinformatik. Oldenbourg, München
(2013)
9. Wilde, T., Hess, T.: Forschungsmethoden der Wirtschaftsinformatik. Wirtschaftsin-
formatik 49 (4), 280–287 (2007)
10. Overdick, H.: The Resource-Oriented Architecture. In: 2007 IEEE Congress on Services
(Services 2007), pp. 340–347. IEEE (2007)
11. Porres, I., Rauf, I.: Modeling Behavioral RESTful Web Service Interfaces in UML. In:
Chu, W., Wong, W.E., Palakal, M.J., Hung, C.-C. (eds.): Proceedings of the 2011 ACM
Symposium on Applied Computing - SAC '11, pp. 1598–1605. ACM Press (2011)
12. Xu, X., Zhu, L., Liu, Y., Staples, M.: Resource-Oriented Architecture for Business Pro-
cesses. In: 2008 15th Asia-Pacific Software Engineering Conf., pp. 395–402. IEEE (2008)
13. Laitkorpi, M., Selonen, P., Systa, T.: Towards a Model-Driven Process for Designing
ReSTful Web Services. In: IEEE Int.’l Conf. on Web Services, pp. 173–180. IEEE (2009)
14. Pérez, S., Durao, F., Meliá, S., Dolog, P., Díaz, O.: RESTful, resource-oriented architec-
tures: a model-driven approach. In: Chiu, D.K. (ed.): WISE 2010. LNCS, Vol. 6724, pp.
282–294. Springer, Berlin et al. (2011)
15. Schreier, S.: Modeling RESTful applications. In: Proceedings of the Second International
Workshop on RESTful Design - WS-REST '11, p. 15-21. ACM Press (2011)
16. Wolf, M.: Modellbasierte Spezifikation von RESTful SOA auf Basis von Geschäftspro-
zessmodellen. In: Mattfeld, D.C., Robra-Bissantz, S. (eds.): Multikonferenz Wirtschaftsin-
formatik 2012, pp. 1649–1660. GITO, Berlin (2012)
17. Fowler, M., Sadalage, P.J.: NoSQL distilled. Addison-Wesley, Boston, Mass. (2012)
18. Krücke, A., Sinz, E.J.: Entwurf partieller SOA auf der Grundlage von Geschäftsprozess-
modellen. In: Sinz, E.J., Bartmann, D., Bodendorf, F., Ferstl, O.K. (eds.): Dienstorientierte
IT-Systeme für hochflexible Geschäftsprozesse. Univ. of Bamberg Press, Bamberg (2011)
19. W3C: Web Services Description Language (WSDL) Version 2.0 Part 2: Adjuncts,
http://www.w3.org/TR/wsdl20-adjuncts/
20. OMG: Business Process Model and Notation (BPMN). Version 2.0, http://www.omg.org
/spec/BPMN/2.0/PDF
21. Manyika, J., Chui, M., Brown, B., Bughin, J., Dobbs, R., Roxburgh, C. and Hung Byers,
A.: Big Data: The next frontier for innovation, competition, and productivity,
http://www.mckinsey.com/Insights/MGI/Research/Technology_and_Innovation/Big_data_
The_next_frontier_for_innovation
1243Sie können auch lesen
