prosero: serviceorientierung unter verwendung von referenzmodellen

82 HMD 270

Philipp Offermann, Torsten Derlat, Udo Bub

Prosero: Serviceorientierung unter Verwendung von Referenzmodellen

Serviceorientierte Architekturen (SOA) kombinie-ren Elemente der Unternehmens- und der Soft-warearchitektur. Ziel ist es, flexiblere Anwen-dungssysteme zu erzeugen, deren Bestandteileeine hohe Wiederverwendbarkeit aufweisen. Da-bei müssen gekaufte bzw. selbst entwickelte Ser-vices entsprechend den durch das SOA-System zuunterstützenden Geschäftsprozessen neu orches-triert werden. Im Forschungsprojekt »Prosero« derDeutschen Telekom Laboratories wurde ein proto-typischer Werkzeugsatz entwickelt, der eine refe-renzmodellbasierte, modellgetriebene und aufoffenen Standards basierende Entwicklung vonSOA-Systemen ermöglicht. Dieser Referenzwerk-zeugsatz zeigt auf, welche technologischen undmethodischen Konzepte Einzug in aktuelle SOA-Werkzeuge finden sollten. Im Fokus stehen hierbeidie Verwendung von Referenzmodellen und dieAutomatisierung von Aktivitäten während derImplementierung von Geschäftsprozessen.

Inhaltsübersicht1 Prosero: SOA und Referenzmodelle2 Werkzeugarchitektur3 Konstruktion eines SOA-Systems mit dem

Werkzeugsatz3.1 Registrierung und Modellsuche3.2 Modelladaption und Validierung3.3 Serviceoperation-zu-Aktivität-Matching3.4 Mediatoren und Orchestrierung

4 Stand der Werkzeugentwicklung und nächste Schritte

5 Literatur

1 Prosero: SOA und ReferenzmodelleUnternehmen sind mit der Notwendigkeit kon-frontiert, neue anforderungsgerechte Dienstezeitnah bereitzustellen. Der Bedarf an abtei-

lungsübergreifenden, wiederverwendbarenFunktionalitäten, Redundanzreduktion undweitreichender Prozessautomatisierung steigt.Ein Architekturansatz, der diesen Anforderun-gen an ein flexibles Unternehmen gerecht wird,ist die serviceorientierte Architektur (SOA).

SOA vereint Elemente der Softwarearchitek-tur und der Unternehmensarchitektur. Sie ba-siert auf der Interaktion von und mit Services,die autonom und interoperabel sind und fach-lich relevante, wiederverwendbare Funktionenüber eine technisch standardisierte Schnittstel-le anbieten. Services können auf allen Anwen-dungssystemschichten (Geschäftsprozess, Prä-sentation, Geschäftslogik, Datenhaltung) exis-tieren. Sie können aus Services tiefererSchichten zusammengesetzt, aus bestehendenAnwendungssystemen gekapselt, aber auchneu implementiert sein. Um maximale Flexibili-tät im Unternehmen zu ermöglichen, müssenSOA-Systeme möglichst schnell entwickelt wer-den. Im Forschungsprojekt »Prosero« der Deut-schen Telekom Laboratories wurde ein Werk-zeug entwickelt, mit dem die Entwicklungsge-schwindigkeit von SOA-Systemen durchmodellgetriebene Entwicklung und neue Auto-matisierungsansätze erhöht wird.

Parallel zum Werkzeug wurde auch eineMethode zum Entwurf von SOA-Systemen ent-wickelt [Offermann 2008]. Dabei wurde ein De-sign-Science-Forschungsprozess eingesetzt [Of-fermann et al. 2009]. Die Methode wird durchdas Werkzeug unterstützt. Das Werkzeug gehtaber hinsichtlich bereitgestellter technischerUnterstützung weit über die Anforderungender generischen Methode hinaus, sodass es hierseparat vorgestellt wird.

Im Prosero-Projekt wurden Probleme undEinschränkungen bisheriger SOA- und BPM-Ent-

SOA-Referenzwerkzeug

HMD 270 83

wicklungsumgebungen adressiert. Im dabeientwickelten Werkzeug werden die fachlichenund technischen Aspekte während der Model-lierung getrennt, die Orchestrierung von hete-rogenen Services entsprechend den Geschäfts-prozessen ermöglicht und die Wiederverwen-dung von Referenzmodellen für Prozesse undDaten gefördert [Schönherr et al. 2008]. Da-durch werden insbesondere die Erlangung undNutzung von Prozessexpertise und die Umset-zung von abstrakten, fachlichen Anforderungenin konkrete Datentypen und Operationen er-leichtert.

Da im Prosero-Projekt die Wiederverwen-dung und Anpassung von Referenzmodellen imVergleich zur üblichen Neu- bzw. Reimplemen-tierung von Geschäftsprozessen im Vorder-grund steht, wird auf einen Vergleich mit gängi-gen Entwicklungsumgebungen wie dem IBMBusiness Modeler und SUN Java CAPS verzich-tet. Projekte wie METEOR-S [Patil et al. 2004]oder Synthy [Agarwal et al. 2005], die mithilfevon Ontologien die Lücke zwischen abstraktenGeschäftsanforderungen und Serviceimple-mentierungen schließen wollen und ebenfalls

eine weitestgehend automatische Orchestrie-rung anstreben, haben bisher zwei Nachteile.Erstens ist unklar, woher die Ontologien unddas erforderliche Wissen dazu kommen undwie viel es kostet. Zweitens ignorieren sie exis-tierende Referenzmodelle, die solches Wissenliefern könnten.

Das Prosero-Werkzeug basiert auf einemsemantischen Repository und stellt Modellie-rungswerkzeuge zur Verfügung. Seine Architek-tur und die einzelnen Komponenten werden imfolgenden Abschnitt erläutert.

2 Werkzeugarchitektur Bei der Konzeption der Architektur des Prosero-Werkzeugs wurde darauf geachtet, dass wäh-rend des Modellierungsprozesses eine Tren-nung zwischen den technischen und fachlichenAspekten möglich ist. Des Weiteren sollte einemöglichst effektive Wiederverwendung der Re-ferenzmodelle realisierbar sein. Dies führte zudem in Abbildung 1 dargestellten Aufbau. DieGrafik zeigt auf der linken Seite die verwende-ten Technologien und auf der rechten Seite dieKernkomponenten des Werkzeugs.

Flex

Eclipse

Web Service

Gateway

MySQL

Portal

Modellierungs-

werkzeuge

Organisations-

daten

Pro-

zesse

Prä-

ferenz

BPEL-

Generator

- Erstellung - Selektion

- Anpassung - Validierung

- Verifizierung

- BPMN-BPEL-Transformation - Matching

- Mediatoren-Generierung - Masken-Generierung

Kundenmodell-Repository

(KMR)

Referenzmodell-Repository

(RMR)

Webservice-Repository

(WSR)

Terminologie

Semantisches

Repository

Abb. 1: Prosero-Architektur


84 HMD 270

Im Frontend stellt ein auf Adobe Flex basie-rendes Webportal die Inhalte des semantischenRepository dar. Zusätzlich ermöglichen die aufEclipse basierenden Modellierungswerkzeugedie Erstellung und Wiederverwendung von Or-ganisations-, Daten- und Geschäftsprozess-modellen. Der BPEL-Generator transformiertdie Spezifikation eines Geschäftsprozesses,die in der Business Process Modeling Nota-tion (BPMN) vorliegt, in eine ausführbareBPEL4People (Business Process Execution Lan-guage for People) Orchestration. Zentrale In-stanz im Backend ist das semantische Reposi-tory. Es verwaltet die Verbindungen zwischendem Kundenmodell-Repository (KMR), dem Re-ferenzmodell-Repository (RMR) sowie demWebservice-Repository (WSR) und umfasst au-ßerdem die Terminologie.

Die Terminologie verwaltet Begriffe (Terms),die automatisch aus textuellen oder semifor-malen Dokumenten des semantischen Reposi-tory mithilfe von Extraktionsalgorithmen her-ausgefiltert wurden. Die Terms der Terminolo-gie werden verwendet, um Modellelemente dessemantischen Repository mit Kontextinforma-tionen anzureichern. Dabei kann ein Elementmehrere Kontexte annehmen und der Kontextselbst kann erweitert werden.

Das Referenzmodell-Repository (RMR) spei-chert drei Typen von Best-Practice-Modellen:Organigramme mit Rolleninformationen, Da-tenmodelle und Prozessmodelle. Prozessmodel-le beinhalten Informationen über Aktivitäten,beteiligte Daten und den Kontrollfluss. Alle Mo-dellelemente sind mit Kontextannotationenversehen.

Im Kundenmodell-Repository (KMR) werdendie vom Kunden bearbeiteten und angepasstenModelle gespeichert. Die Modelle in diesem Re-pository besitzen eine Verbindung zum ent-sprechenden Modell aus dem RMR, aus dem sieabgeleitet wurden. Die Modellelemente imKMR sind nicht mit einem Kontext versehen,stattdessen besitzt der jeweilige Kunde einenKontext.

Das Webservice-Repository (WSR) beinhal-tet alle Metadaten, die Webservices beschrei-ben. Dies umfasst Daten über den Namen, denInput, den Output und über nicht funktionaleEigenschaften. Es stellt Informationen über Off-the-shelf-Services zur Verfügung, die für Kun-denprozesse verwendet werden können. DieElemente im WSR sind mit Kontextannotatio-nen versehen.

3 Konstruktion eines SOA-Systems mit dem Werkzeugsatz

Im Folgenden wird die Verwendung des Prose-ro-Werkzeugs anhand eines KMU-Kunden, dereinen Prozess computergestützt automatisie-ren lassen möchte, aufgezeigt. Bei dem Prozesshandelt es sich um den Rückgabeprozess einerAutovermietung. Der Prozess umfasst u.a. dieAktivitäten der Rückgabe eines gemieteten Au-tos, der Überprüfung der Fahrzeugdaten, der Er-mittlung der Reparaturbedürftigkeit und derRechnungsstellung. Für dieses Fallbeispiel wirdangenommen, dass hinreichend viele Orga-nigramme, Geschäftsprozessmodelle und zuge-hörige Datenobjekttypmodelle erstellt und imRepository abgespeichert wurden. Die Erstel-lung dieser Modelle kann rechnergestützt imRahmen von Projekten oder unabhängig alsEntwicklung von meist industriespezifischenBest Practices erfolgen. Beispielhaft könnenhier Prozesse aus der enhanced Telecom Opera-tions Map (TeleManagement Forum) oder demSupply-Chain Operations Reference Model(Supply-Chain Council) herangezogen werden[Holschke et al. 2008].

3.1 Registrierung und ModellsucheDer erste Schritt beginnt im Portal mit der Re-gistrierung des Kunden. Dabei werden zusätzli-che Informationen über den Kundenkontext be-nötigt. Anhand von Informationen wie der geo-grafischen Lage, der Industrieklassifizierung(Consumer Products), der Unternehmensgrößeoder des Prozesskontextes (Procurement, Pay-


HMD 270 85

ment, Financial etc.) wird nach Abschluss derRegistrierung automatisch eine Suche im Refe-renzmodell-Repository angestoßen. Die dortliegenden Referenzmodelle sind ebenfalls mitKontextinformationen (Tags) versehen. Einespezifizierte Anfrage wird mit diesen Tags auto-matisiert abgeglichen. Da alle Elemente im Re-pository als Baum vorgehalten werden, ge-schieht dies durch einen eigens entwickeltenTree-Alignment-Algorithmus, der die annotier-ten Bäume mit einer Sammlung von Kandida-ten (ebenfalls annotierte Bäume) vergleicht [El-hadad et al. 2008]. Der Algorithmus erzeugt da-bei eine Transformation, die den Quellbaum aufden Zielbaum abbildet, und berechnet die Kos-ten dieses Transformationsprozesses. Diese»semantische Distanz« ermöglicht eine quanti-tative Bewertung der Modellkandidaten. Refe-renzmodelle, die den Spezifikationen des Kun-den am besten entsprechen, können dann se-lektiert werden.

In der nun folgenden Phase des Modellie-rungsprozesses können die Wiederverwen-dungstechniken Adoption, Analogiekonstrukti-on, Restriktion und Spezialisierung eingesetztwerden [Soffer et al. 2007]. Bei der Adoptionwird das selektierte Referenzmodell ohne Modi-fizierungen übernommen. Bei der Analogiekon-struktion orientiert sich ein Modellierer an ei-nem Referenzmodell und kann bestimmte Teiledes Modells übernehmen. Bei der Restriktionmüssen die Modellelementtypen, die zugelas-sen oder ausgelassen werden, spezifiziert wer-den. Bei der Spezialisierung werden Merkmaledes Referenzmodells an das konkrete Modellvererbt, die dann vom Modellierer je nach An-wendungsfall im Modellierungstool frei modifi-ziert werden können. Am Ende der Adaptions-phase ist ein anforderungsgerechtes Geschäfts-prozess- und Datenmodell spezifiziert.

Für das Beispiel der Autovermietung ent-spricht das CheckIn-Referenzmodell den Spezi-fikationen des Rückgabeprozesses am besten(Abb. 2). Dieser Referenzprozess und all seineArtefakte (Organisations- und Datenmodelle)

werden nun automatisch in das Kundenmodell-Repository kopiert. Mithilfe einer Ähnlichkeits-schwelle filtert der Kontextfilter Datenobjekteund Aktivitäten heraus, die nicht relevant fürdie Modellierungsaufgabe sind. Gefilterte Da-tenelemente können jedoch nachträglich in dasModell übernommen werden. Somit ist die fürden Anwender notwendige Variabilität gege-ben. Nach dem Kopiervorgang bleibt eine Rela-tion zwischen dem Kundenprozess und dementsprechenden Referenzprozess erhalten.

3.2 Modelladaption und ValidierungNun kann der übernommene »CheckIn«-Pro-zess modifiziert werden. Beispielsweise könnenAktivitäten hinzugefügt, entfernt oder den spe-zifischen Kundenanforderungen entsprechendverfeinert werden. Durch den »Refine BPMNModel«-Befehl im Portal öffnet sich die Prozess-ansicht im Prosero BPMN Modeler. Wie in Abbil-dung 2 zu sehen ist, stehen dem Designer in derPalette alle typischen BPMN-konformen Model-lierungsobjekte, wie Fluss- und Verbindungsob-jekte, Verantwortlichkeitsbereiche (Pools, La-nes) und Artefakte, zur Verfügung. Nachdemder Prozess modifiziert wurde, kann dieser nacheiner erfolgreichen Validierung wieder in dasPortal exportiert werden. Neben Konsistenz-checks erfolgt diese Validierung mit Blick aufden ursprünglichen Referenzprozess, aus demder Kundenprozess abgeleitet wurde. Hierbeiwird unter anderem geprüft, ob alle als notwen-dig gekennzeichneten Aktivitäten des Referenz-prozesses im modifizierten Kundenprozessnoch immer vorhanden sind.

Zusätzlich zum Prozess können auch dasDatenmodell bzw. die Datenobjekte verändertwerden. Diese ABIEs (Aggregated Business In-formation Entities), in BPMN als Datenobjektedargestellt, konkretisieren zum einen den Da-tenfluss zwischen Aktivitäten, zum anderensind diese mit Kontextinformationen angerei-chert, anhand derer sie bei der Modellsuche ge-filtert werden. ABIEs können sich sowohl ausanderen ABIEs als auch aus BBIEs (Basic Busi-


86 HMD 270

ness Information Entities) zusammensetzen.Dabei stellen BBIEs atomare Informationsträgerdar, die aus einem Namen und einem Typ beste-hen. Datenobjekte werden wie BPMN-Modelleerst nach einer automatischen Validierung indas Portal exportiert.

3.3 Serviceoperation-zu-Aktivität-MatchingNachdem die Prozesse und Datenmodelle desKunden angepasst wurden, sind die fachlichenAktivitäten der Business Process Orchestrationin Prosero abgeschlossen. Die Spezifizierungder technischen Aspekte startet mit dem Ser-viceoperation-zu-Aktivität-Matching. Hierbeifindet ein Matching der Prozessaktivitäten mitvorhandenen Serviceoperationen im Hinblickauf funktionale und nicht funktionale Eigen-schaften (NFE) statt.

Der funktionale Teil basiert auf einem se-mantischen und syntaktischen Abgleich. Dieserfindet automatisiert zwischen Aktivitätsnamensowie Ein- und Ausgabeparametern der Aktivi-täten im Geschäftsprozessmodell einerseitsund der verfügbaren Serviceoperationen ande-

rerseits statt. Durch den zusätzlichen Vergleichvon Kontextannotationen (Terms) wird ermit-telt, welche Operationen die funktionalen An-forderungen erfüllen.

Nach dem funktionalen Matching wirdüberprüft, inwieweit die gefundenen Service-operationen die nicht funktionalen Anforderun-gen des Kunden, wie z.B. Verfügbarkeit, Preisund Antwortzeit, erfüllen. Anschließend wirdeine Rangliste dieser Anforderungen – einemPräferenzmodell entsprechend – erstellt[Schröpfer et al. 2007]. Basierend auf dieserRangliste muss für jede Aktivität im Geschäfts-prozess die passende Operation ausgewähltwerden.

Um mithilfe des Prosero-Portals ein NFE-Ranking erstellen zu können, müssen SLOs (Ser-vice Level Objectives) definiert werden. Durchdiese SLOs können später funktional identischeServiceoperationen priorisiert werden. Nach Ka-tegorien sortiert, können hier bereits vorkonfi-gurierte Anforderungsklassen (Levels) be-stimmter NFEs ausgewählt werden. Dabei be-sitzt jede Kategorie die Levels »Bronze«,

Abb. 2: Modellierungstool – Ausschnitt aus dem »CheckIn«-Prozess


HMD 270 87

»Silver«, »Gold« und »Platinum«. Je edler dasLevel, desto höher sind die Anforderungen andie NFEs. Eine manuelle Konfiguration der NFE-Parameter ist möglich. In Abbildung 3 wurdendie Kategorien »Availability« und »Perfor-mance« als SLOs angelegt. Die NFEs, in der Ab-bildung NFP (non-functional property) ge-nannt, sind für jede Kategorie vordefiniert. ImBeispiel bedeutet das »Platinum«-Level für diePerformance-Kategorie, dass die NFE »Response-Time« nicht mehr als (leq = less or equal) 0,1Sekunden (value) in 99 % aller Fälle betragendarf.

Diese Informationen reichen aber nicht aus,um eine Priorisierung der gefundenen Servicesdurchzuführen. Hierfür wird nach der Festle-gung dieser Anforderungen ein sogenanntesPräferenzmodell vorgeneriert. In diesem Modellist es möglich, sowohl NFE-Anforderungen alsauch benutzerdefinierte Anforderungen durchPräferenzrelationen in eine Prioritätsbeziehungzu stellen. Initial befinden sich die spezifiziertenNFEs der Kategorien in keiner Relation, was be-deutet, dass Services, die alle Anforderungen er-füllen, nicht nach Präferenz sortiert werdenkönnen. Abbildung 4 veranschaulicht die Bezie-hungen im Prosero-Modellierungstool. Die Dar-stellung zeigt, in welcher Beziehung die Anfor-derungen zueinander stehen. Dabei wird für je-den Knoten eine »Conditional Preference Table«(CPT) festgelegt, die bestimmt, wie viele Punkte

eine bestimmte Anforderungsausprägung, wiezum Beispiel »true« oder »false«, erhält. Dabeiwerden die möglichen Zustände der Eltern ei-nes Knotens berücksichtigt. Abschließend er-rechnet ein Algorithmus für jede Serviceopera-tion aus den CPTs und den Anforderungsaus-prägungen den endgültigen nicht funktionalenWert, den »Pref Rank«. In Abbildung 5 sieht mandie CPT der »Delay«-Anforderung. Die »Response-Time«-Zustände tauchen hier auf, da eine ge-richtete Präferenzrelation zwischen »Response-Time« und »Delay« besteht. Ersichtlich ist, dassdie Operation 50 Punkte bekommt, wenn so-wohl die »ResponseTime« als auch die »Delay«-Anforderung erfüllt ist. Falls beide nicht erfülltsein sollten, spielt es keine Rolle, welche ande-ren Anforderungen an die Operation gestelltwerden, da der Wert »-Infinity« disqualifizie-rend für die Serviceoperation im Hinblick aufNFEs wirkt (zur theoretischen Grundlage undzum Algorithmus siehe [Schröpfer et al. 2007]).

Mithilfe der Präferenzinformationen kanndas Serviceoperation-zu-Aktivität-Matching durch-geführt werden. Das Ergebnis dieses Vorgangszeigt Abbildung 6. Zu jeder Aktivität werden diegefundenen Serviceoperationen aufgelistet.Dabei erfolgt die Auflistung absteigend nachdem Grad der Erfüllung von funktionalen Eigen-schaften (»Match Cost«) und nicht funktionalenEigenschaften (»Pref Rank«). Je höher der Wert,desto besser ist der Service geeignet, die ent-

Abb. 3: Portal – Service Level Objectives


88 HMD 270

sprechende Funktionalität anzubieten. DerWert »-INF« bedeutet, dass die Serviceoperati-on die spezifizierten NFE-Anforderungen nichterfüllt, weil eine eingetretene Anforderungs-ausprägung als inakzeptabel (»-Infinity«) dekla-riert wurde. Sollte für eine Aktivität keine ent-sprechende Serviceoperation gefunden wor-den sein, muss diese erst entwickelt und imWebservice-Repository registriert werden.

3.4 Mediatoren und OrchestrierungNachdem für jede Aktivität des Prozesses eineServiceoperation ausgewählt wurde, werdendie für die Orchestrierung benötigten Mediato-ren generiert. Diese bilden die unstimmigen

Datenfelder aufeinanderfolgender Services auf-einander ab, falls die dortigen Ein- und Ausga-befelder voneinander abweichen. Diese Media-toren müssen manuell überprüft werden. Istdies geschehen, werden die einzelnen Prozess-teile orchestriert, und der WS-BPEL-Code wirderzeugt. In der Orchestrierung muss abschlie-ßend geprüft werden, ob die logischen Ausdrü-cke an den Entscheidungsknoten korrekt in dasvon den Services verwendete Datenformatübersetzt wurden. Eine ausführliche Betrach-tung der Transformation von BPMN zu BPEL bie-tet [Ouyang et al. 2006].

Damit endet der Beispielworkflow für denRückgabeprozess der Autovermietung. Es wur-

Abb. 4: Modellierungstool – Präferenzmodell

Abb. 5: »Conditional Preference Table« für »Delay«-Anforderung


HMD 270 89

de geschildert, wie es mithilfe des Prosero-Werkzeugsatzes gelingt, auf einfache Art undWeise mittels Referenzprozessen und vorhan-denen Services durch das Prinzip der automati-schen Wiederverwendung WS-BPEL-Prozessbe-schreibungen zu generieren. Abschließend wer-den diese mit einem Deployment-Deskriptoreingesetzt und ausführbar gemacht. Das Ergeb-nis des gesamten Ablaufs sind die Artefakte, diefür die Ausführung von Geschäftsprozessen aufBasis von Services in SOA erforderlich sind. Die-se sind

! Geschäftsprozessmodelle, modelliert in derBusiness Process Modeling Notation (BPMN),

! Datenmodelle für den Informationsfluss aufBasis der Core Components Technical Specifi-cation (CCTS), repräsentiert als XML SchemaDefinition (XSD),

! Mediatoren, dargestellt in XSL Transforma-tions,

! Orchestrierungsspezifikationen, notiert inder Business Process Execution Language(WS-BPEL) mit der People Extension for BPEL(BPEL4People), und

! Benutzerschnittstellen.

Als Laufzeitumgebung wird zurzeit der Active-BPEL Enterprise Server von Active Endpoints ein-gesetzt.

4 Stand der Werkzeugentwicklung und nächste Schritte

Die Generierung von SOA-Systemen ist auch beivorhandenen Services ein komplexes Unterfan-

gen. Insbesondere für IT-Integratoren, die eineVielfalt an Kundenanforderungen erfüllen müs-sen, stellt eine durchgängige Werkzeugunter-stützung eine Möglichkeit dar, die Generierungzu vereinfachen und zu beschleunigen. Existie-rende Werkzeuge bieten dem Benutzer nur we-nige automatisierte Unterstützungen an. Bei-spielsweise muss bei der Entwicklung mit SUNJava CAPS 5 die Auswahl der zu verwendendenServices manuell erfolgen. Auch die automati-sche Generierung von Orchestrierungen istnicht vorhanden, da Nachrichtenflüsse zwi-schen Services manuell angepasst werden müs-sen. Der in diesem Beitrag vorgestellte Werk-zeugsatz ergänzt die Konzepte existierenderEntwicklungswerkzeuge und unterstützt denAnwender zusätzlich durch

! Bereitstellung von Referenzmodellen für Ge-schäftsprozesse und Datenmodelle,

! Vorschlagen von passenden Services inkl. Be-achtung von SLOs und Sortieren nach einemPräferenzmodell,

! halbautomatisches Generieren von Daten-mediatoren für heterogene Webservices,

! automatisches Generieren von WS-BPEL inkl.BPEL4People,

! automatisches Generieren von Benutzer-oberflächen und

! halbautomatische Übersetzung von logi-schen Ausdrücken an Entscheidungsknoten.

Durch diese Unterstützungen wird die Erstel-lung von SOA-gestützten Geschäftsprozessenwesentlich vereinfacht. Die vorgestellte Lösungbasiert fast ausschließlich auf offenen Stan-

Abb. 6: Portalausschnitt – Matching


90 HMD 270

dards, sodass sie sich leicht auf unterschiedlicheLaufzeitumgebungen anpassen lässt.

Die Grenzen des Prosero-Werkzeugs sindeng verknüpft mit der Verfügbarkeit von Best-Practice-Modellen und Off-the-shelf-Servicesfür das Repository. Damit verbunden sind diebisher fehlenden Standards, die Informationenauf dem erforderlichen Granularitätsniveau zurVerfügung stellen. Dies impliziert einen hohenAufwand, um bestehende Industriestandardsauf dieses Level zu portieren. Insgesamt steigtdie Qualität der Werkzeugunterstützung mitzunehmender Verbreitung von Off-the-shelf-Services und Referenzmodellen.

Seit Anfang 2009 gibt es bei der T-SystemsEnterprise Services GmbH ein Innovationspro-jekt, um die im Prosero-Projekt erarbeitetenund erprobten Ideen in einer Process and Ser-vice Platform (PSP) zu produktisieren. Dazuläuft bei den Deutschen Telekom Laboratoriesein Transferprojekt, durch das aktiv Wissen undTechnologien aus dem Forschungsprojekt in dasInnovationsprojekt eingebracht werden. ImPSP-Projekt wurden zunächst in Kooperationmit den Laboratories basierend auf den Erfah-rungen Anwendungsfälle erarbeitet. Für die In-frastruktur wurde entschieden, eine Kooperati-on mit der Software AG einzugehen und auf derwebMethods-Produktsuite aufzubauen. Als Er-gebnis der Anforderungsanalyse wurde der Kin-dergartenprozess der öffentlichen Verwaltungals Pilotkunde ausgewählt. Diesen Prozess gibtes in jeder der über 10.000 Kommunen inDeutschland, in jeder Kommune läuft er aberetwas anders ab. Daher können die Vorteile derim Prosero-Werkzeug umgesetzten Automati-sierungen voll zur Geltung kommen, sobald diezugrunde liegenden Services zur Verfügung ste-hen. Zurzeit laufen die Implementierung derPlattform und die Umsetzung des Kindergar-tenprozesses für eine Kommune. Die Anpas-sung des Prozesses für weitere Kommunen unddie Vorbereitung weiterer Prozesse werden an-gegangen.

Es ist zu hoffen, dass die vorgestellten An-sätze auch in andere Entwicklungsplattformen,die fehlerträchtige, wiederkehrende und zeit-aufwendige Aufgaben bisher vollständig dermanuellen Bearbeitung überlassen, Einzug hal-ten. Dies würde die Zeit zur Generierung undAnpassung von durch SOA-Systemen gestütz-ten Geschäftsprozessen signifikant senken. Da-mit würde man den Zielen einer SOA, durch Fle-xibilität und Wiederverwendung den steigen-den Kunden- und Marktanforderungen erfolg-reich entgegenzutreten, einen Schritt näherkommen. Die Akzeptanz und die Marktdurch-dringung der SOA würden steigen.

5 Literatur[Agarwal et al. 2005] Agarwal, V.; Chafle, G.; Das-

gupta, K.; Karnik, N.; Kumar, A.; Mittal, S.; Sri-vastava, B.: Synthy: A System for End to EndComposition of Web Services. In: Journal ofWeb Semantics, 3. Jg., 2005, Heft 4.

[Elhadad et al. 2008] Elhadad, M.; Balaban, M.;Sturm, A.: Effective Business ProcessOutsourcing: The Prosero Approach. In: Interna-tional Journal of Interoperability in Business In-formation Systems, 3. Jg., 2008, Heft 1.

[Holschke et al. 2008] Holschke, O.; Gelpke, P.; Of-fermann, P.; Schröpfer, C.: Business Process Im-provement by Applying Reference Process Mo-dels in SOA – a Scenario-based Analysis. In:Multikonferenz Wirtschaftsinformatik, 2008.

[Offermann 2008] Offermann, P.: SOAM – Eine Me-thode zur Konzeption betrieblicher Softwaremit einer Serviceorientierten Architektur. In:Wirtschaftsinformatik, 50. Jg., 2008, Heft 6, S.461-471.

[Offermann et al. 2009] Offermann, P.; Levina, O.;Schönherr, M.; Bub, U.: Outline of a Design Sci-ence Research Process. In: DESRIST'09, 2009,http://desrist2009.ist.psu.edu/Papers/desrist2009_submission_27.pdf, Zugriff am15.07.2009.

[Ouyang et al. 2006] Ouyang, C.; van der Aalst, W.M. P.; Dumas, M.; ter Hofstede, A. H. M.: Transla-ting BPMN to BPEL. In: BPM Center Report BPM-06-02, BPMcenter.org, 2006.


HMD 270 91

[Patil et al. 2004] Patil, A. A.; Oundhakar, S. A.;Sheth, A. P.; Verma, K.: Meteor-s web service an-notation framework. In: Proceedings of the 13thconference on World Wide Web, 2004, S. 553-562.

[Schönherr et al. 2008] Schönherr, M.; Holschke, O.;Offermann, P.; Bub, U.: Werkzeuggestützte Refe-renzmodellanwendung im SOA-Entwurfspro-zess. In: Informatik 2008: Beherrschbare Syste-me dank Informatik – Band 1, 2008, S. 139-144.

[Schröpfer et al. 2007] Schröpfer, C.; Binshtok, M.;Shimony, S. E.; Dayan, A.; Brafman, R.; Offer-mann, P.; Holschke, O.: Introducing preferencesover NFPs into service selection in SOA. In:Workshop on Non-Functional Properties andService Level Agreements in Service OrientedComputing (NFPSLA-SOC), 2007.

[Soffer et al. 2007] Soffer, P.; Reinhartz-Berger, I.;Sturm, A.: Facilitating Reuse by Specialization ofReference Models for Business Process Design.In: 8th Workshop on Business Process Mode-ling, Development, and Support (BPMDS'07) inconjunction with the 19th International Confe-rence on Advanced Information Systems Engi-neering (CAiSE'07), 2007.

Philipp OffermannDr. Udo BubDeutsche Telekom AG LaboratoriesErnst-Reuter-Platz 710587 Berlin{philipp.offermann, udo.bub}@telekom.dewww.laboratories.telekom.com

Torsten DerlatTechnische Universität BerlinInstitut für WirtschaftsinformatikStraße des 17. Juni 13510623 [email protected]

prosero: serviceorientierung unter verwendung von referenzmodellen

Documents