1

ZUSICHERUNG NICHTFUNKTIONALER EIGENSCHAFTEN UND DIENSTGÜTE IM FUTURE INTERNET OF SERVICES Iris Braun, Sandro Reichert, Josef Spillner, Anja Strunk, Alexander Schill TU Dresden, Institut für Systemarchitektur, Lehrstuhl Rechnernetze Email: {iris.braun, sandro.reichert, josef.spillner, anja.strunk, alexander.schill}@tu-dresden.de

Prof. Dr. rer. nat. habil. Dr. h. c. Alexander Schill ist Professor für Rechnernetze an der TU Dresden. Die Promotion und die Habilitation erwarb er in Informatik an der Universität Karlsruhe, Deutschland. Prof. Schill erhielt die Ehrendoktor-Würde von der Universidad Nacional de Asunción, Paraguay. Prof. Schill arbeitete mit dem IBM Thomas J. Watson Research Center, New York, zusammen und war beteiligt an verschiedenen Industrie-Kooperationen. Seine Hauptforschungsinteressen sind Verteilte Systeme und Middleware, Hochleistungskommunikation, Mobile Computing und MultimediaAnwendungen. Er ist Autor bzw. Co-Autor einer großen Sandro Reichert studierte bis 2007 InAnzahl von Veröffentlichungen, einschließlich einiger Bücher formatik an der Technischen Universiauf diesen Fachgebieten. tät Dresden und arbeitete nach seinem Abschluss zunächst im Bereich Mobile Zusammenfassung—Zur Verwirklichung der Vision des Future Computing und Wireless Security am Internet of Services werden Infrastrukturen benötigt, die eine Lehrstuhl Rechnernetze. Seit 2008 arbei- flexible, dynamische und vertraglich garantierte Vermittlung tet er im Forschungsprojekt THESEUS zwischen Dienstanbietern und Dienstnutzern erlauben. im Bereich der Dienstausführung von Mit bisherigen Web-Service-Technologien können nichtfunktionale Eigenschaften und Dienstgüte nur für einzelne Dienste service-orientierten Systemen.

Iris Braun ist seit 1997 Mitarbeiterin am Lehrstuhl Rechnernetze der TU Dresden und in zahlreiche nationale und internationale Forschungsprojekte involviert. Nach Abschluss Ihrer Dissertation übernahm sie die Einwerbung und Koordination verschiedener Projekte im SOA-Umfeld. Beispielsweise beteiligt sich ihre Forschergruppe am BMWILeuchtturmprojekt THESEUS und ist im Use Case TEXO für die Unterstützung nichtfunktionaler Eigenschaften und QoS über den gesamten Lebenszyklus der Dienste verantwortlich.

Josef Spillner arbeitet seit dem Ende seines Informatikstudiums im Jahr 2006 am Lehrstuhl Rechnernetze der TU Dresden und beteiligt sich seit 2007 am Forschungsprojekt THESEUS. Thematisch fokussiert er sich auf den Themenkreis der vertragsgestützten Dienstausführung und insbesondere auf den Einsatz von Techniken zum Monitoring. Anja Strunk studierte Informatik an der Technischen Universität Dresden und arbeitet seit 2006 als wissenschaftliche Mitarbeiterin am Lehrstuhl Rechnernetze. Ihr Forschungsschwerpunkt sind service-orientierte Systeme. Seit 2007 promoviert Frau Strunk im Bereich Adaption von Web-Prozessen in serviceorientierten Systemen.

beschrieben und bewertet werden. Diese Informationen dienen als Entscheidungsgrundlage für eine dynamische Auswahl von Diensten zur Laufzeit. Sollen nichtfunktionale Eigenschaften und Dienstgüte für komplexe Geschäftsprozesse beschrieben werden, stößt man an die Grenzen gängiger Prozess- und Dienstbeschreibungssprachen. Darüber hinaus gibt es bisher keine Ansätze zur dynamischen Aushandlung dieser Dienstgüteverträge zwischen Anbieter und Nutzer, als auch zwischen Diensten, die gemeinsam in einen Geschäftsprozess integriert werden. In diesem Artikel wird vorgestellt, wie nichtfunktionale Eigenschaften im gesamten Lebenszyklus der Dienstnuzung verwendet werden können und welche Lösungen hierfür zum Einsatz kommen. Wir geben einen generellen Überblick und konzentrieren uns auf den Abschluss und die Einhaltung von Dienstgütevereinbarungen, sowie deren Überwachung und die abschließende Bewertung der Dienstqualität durch den Dienstnutzer. Die Nutzung unserer Ergebnisse erfolgt im Rahmen des Forschungsprojektes THESEUS TEXO1 , in dem eine ServicePlattform zur Bereitstellung und Nutzung adaptiver Dienste mit umfassender Unterstützung nichtfunktionaler Eigenschaften über den gesamten Lebenszyklus der Services entwickelt wird. 1 Das dem Projekt zugrunde liegende Vorhaben wurde mit Mitteln des Bundesministeriums für Wirtschaft und Technologie unter dem Förderkennzeichen „01MQ07012“ gefördert. Die Verantwortung für den Inhalt liegt bei den Autoren.

2

I. E INLEITUNG Die Nutzung von Diensten über das Internet gleicht einem Glücksspiel: Während eine formale Dienstbeschreibung auf funktionaler Ebene oftmals in Form einer WSDL2 -Datei vorliegt, werden Garantien zur Nutzung nur selten gegeben. Aus Sicht des Nutzers ist es häufig notwendig, sich auf eine maximale Antwortzeit, ein garantiertes Sicherheitsniveau oder einen günstigen Preis verlassen zu können. Diese Garantien müssen auch im Fall von Systembeeinträchtigungen eingehalten werden, wodurch ein Bedarf an vielseitigen Adaptionsmechanismen zur Unterstützung der Dienstausführung besteht. Die Integration dieser Mechanismen muss sowohl bei der Modellierung und Entwicklung der zugrunde liegenden Dienste, als auch bei der Laufzeitunterstützung und Auslieferung berücksichtigt werden. Die Laufzeitumgebung und ihre Frameworks zur Komposition von Diensten müssen dabei um dynamische Adaptions- und Aushandlungsroutinen ergänzt werden. Die Wechselwirkung zwischen den Anforderungen von Diensten und den zur Verfügung stehenden Ressourcen einer Laufzeitplattform erfordert daher Vertragsangebote, die an die jeweils aktuelle Systemsituation angepasst sind. Die Vereinbarungen zur Dienstgüte werden im Folgenden als Service Level Agreements – kurz SLAs – bezeichnet. Aus der eben genannten Wechselwirkung folgt, dass Eigenschaften und Zusicherungen auf Systemebene in SLA-Angeboten reflektiert werden müssen. Modellierungs- und Entwicklungswerkzeuge müssen ebenfalls um Modelle und Beschreibungsmöglichkeiten der Adaptivität der Dienste erweitert werden. Abbildung 1 verdeutlicht die Zusammenhänge zwischen den Phasen des Zyklus der Dienstnutzung. Die Modellierung der Dienste wird in Kapitel II betrachtet. Sie schließt Angebote von Diensten auf Basis von SLA-Vorlagen sowie Anfragen der Nutzer ein. Im Anschluss folgt die Vorbereitung der Dienstnutzung in Kapitel III. Die Phase besteht aus der Auswahl geeigneter Dienste, der hier nicht betrachteten dynamischen Komposition von mehreren Diensten zu Geschäftsprozessen, der Aushandlung der SLAs und der Anpassung der Dienstgüte. Kapitel IV beschreibt die tatsächliche Dienstnutzung zur Laufzeit. Zur Gewährleistung der vereinbarten Dienstgüte wird die Ausführung kontinuierlich überwacht. Um Verletzungen der getroffenen Vereinbarungen weitestgehend zu vermeiden, stehen Mechanismen zur Neuanpassung der Prozesse und Neuaushandlung der SLAs zur Verfügung. Die Nachbereitung der Dienstnutzung erfolgt in Kapitel V. Wir betrachten hier ausschließlich die Bewertung durch den Nutzer, auf die Modalitäten der Bezahlung und die Gewinnung innovativer Ideen aus den statistischen Daten zur Dienstnutzung wird nicht eingegangen. Eine Zusammenfassung der präsentierten Informationen in Kapitel VI rundet den Artikel ab. Zu den Teilaspekten der Phasen existieren zwar bereits umfangreiche Vorarbeiten, eine ganzheitliche Betrachtung wie die unsere wurde jedoch bisher nicht vorgenommen. Wir konzentrieren uns auf technische Aspekte und Anforderungen an die SLANutzung und behandeln Themen wie die Anbindung an Bezahlsysteme oder die Evaluation der Dienste ausschließlich am Rande. Darüber hinaus schlagen wir in einigen Bereichen 2 Web

Service Description Language

Verbesserungen der existierender Lösungen vor und skizzieren deren geplante Umsetzung am Beispiel einer fiktiven Dienstkomposition zur Berechnung eines Ökowertes für einen Autositz.

Abbildung 1.

Lebenszyklus der Dienstnutzung

II. M ODELLIERUNG VON D IENSTEIGENSCHAFTEN UND V ERTRÄGEN Vor der Beschreibung des Dienstnutzungszyklus und davon abgeleiteten Architekturmerkmalen steht eine Betrachtung der Modellebene, in der das zentrale Modell einer SLA erläutert wird. Wir setzen dabei keine bestimmte SLA-Sprache voraus, sondern definieren grundsätzliche Anforderungen bezüglich ihrer Granularität und Expressivität. Gleiches gilt für die Sprachen zur Beschreibung von Diensten und Nutzerpräferenzen. A. Angebot des Dienstes Jeder Dienstanbieter kann neben syntaktischen und strukturellen Merkmalen eines Dienstes auch weitere Informationen zur Verfügung stellen. Durch die Angabe nichtfunktionaler Eigenschaften (NFP3 ) wie garantierten Berechnungszeiten oder möglichen auswählbaren Sicherheits- und Datenschutzstufen wird eine vielfältigere Dienstlandschaft und eine optimierte Auswahl für eine eventuelle Dienstkomposition ermöglicht. Eine gängige Klassifikation von NFPs wird in [1] gegeben, es existieren jedoch viele alternative Betrachtungen ohne erkennbare Dominanz einer bestimmten Klassifikation. Üblicherweise werden formale Sprachen verwendet, um die Eigenschaften von Komponenten mit softwaretechnologischen Mitteln zu spezifizieren. Sowohl einschränkbare und erweiterbare Typsysteme, als auch regelbasierte Systeme, etwa auf Basis der Object Constraint Language (OCL), können hierbei zum Einsatz kommen. Die Vorteile wie ableitbares Monitoring und berechenbare Adaptivität bedingen dabei eine Verknüpfung von Diensteigenschaften mit Systemressourcen [2]. In der Praxis werden diese statischen Informationen aber 3 Engl.:

non-functional property

3

nahezu zwangsläufig durch reelle Messungen, Erfahrungswerte III. VORBEREITUNG DER D IENSTNUTZUNG und weitere Quellen ergänzt, so dass ein rein softwaretechnoDie Vorbereitungsphase wird mit der Auswahl eines konkrelogischer Ansatz hier wenig sinnvoll erscheint. Unser Ansatz ten Dienstes zur Ökowertberechnung eingeleitet. Mit diesem wird die Rückwirkung von Laufzeiteigenschaften auf die Dienst wird ein Vertrag ausgehandelt, dessen Bedingungen eine Dienstbeschreibung beinhalten, worauf im Abschnitt IV im Anpassungsfähigkeit des Dienstes erfordern. Detail eingegangen wird. A. Dienstauswahl B. Anfragen zum Dienst

Für die Auswahl kommt in unserem Ansatz ein DiscoveryDienst zum Einsatz, der gleichermaßen die Dienstgüte und den Wird ein bestimmter Dienst gesucht, so muss die Funktion des Dienstes als Fixkriterium an ein Dienstverzeichnis überge- Kontext der Dienstnutzung berücksichtigt. Unter Nutzung des 5 ben werden. Wenn die Formulierung des Kriteriums auf Basis WSMX-Frameworks werden die Eigenschaften der Dienste einer erforderten Syntax oder Semantik nicht von vornherein mithilfe der Web Service Modelling Ontology (WSMO) und möglich ist, dann führt üblicherweise eine Navigation oder weiterer Ontologien für Kontext- und QoS-Eigenschaften Suchfunktion im Dienstverzeichnis zum Ziel. Als Syntax dient beschrieben. Der Dienstnutzer hat die Möglichkeit, in Form von beispielsweise bei der Nutzung von WSDL eine abstrakte Goals seine Anforderungen an den Dienst zu modellieren. Im Nachrichtendefinition, als semantische Anforderung die ge- Ergebnis des ConQo-Discovery [3] wird eine sortierte Liste von nannten IOPEs4 . Hierfür wird das Verzeichnis, üblicherweise Diensten zurückgegeben, die die Anforderungen des Nutzers in eine Registry, um eine aktive Discovery-Komponente [3] Hinsicht auf die gewünschten nichtfunktionalen Eigenschaften erweitert. Einen größeren Spielraum zur Einschränkung der und Dienstgüte erfüllen, wobei der erste Dienst in der Liste Suchergebnisse bieten NFPs, die sowohl fix, als auch variabel die Kriterien am besten erfüllt und somit ausgewählt wird. mit unterschiedlichen Prioritäten angegeben werden können. Der Nutzer kann in der Goal-Beschreibung eine Priorisierung In unserem Beispiel sei ein Ökorechner gesucht, der nach der Kriterien definieren, um die Sortierung der Liste zu maximal 70 Sekunden das Ergebnis zurück gibt und höchstens beeinflussen. Nach der Auswahl wird durch weitere Komponenten eine 6 e kostet. Hierbei tritt ein kombinatorisches Problem auf, das durch gezielten Einsatz von Datenbanktechnologien wie SLA erzeugt, in der die Rahmenbedingungen für die Nutzung, Indizes oder Maximierungs- und Minimierungsfunktionen sowie qualitative und quantitative Gültigkeitsbereiche zu NFPs gelöst werden kann. Allen Suchverfahren gemeinsam ist die erfasst sind. Zur Vorbereitung der Dienstnutzung gehören Kapselung der Algorithmen durch Erstellung einer geordneten demnach die Auswahl geeigneter Dienste, die Aushandlung Liste von Diensten und Rückgabe des ersten Elements daraus von SLAs, die Einigung auf Bezahlungsmodalitäten, sowie die erstmalige Anpassung der Web Services und der Systemkomals ausgewählten Dienst. ponenten an die ausgehandelte Dienstgüte. C. SLA-Vorlagen

B. Initiale Aushandlung der SLAs Die Suche nach Diensten mit den gewünschten Eigenschaften Nachdem ein Dienst ausgewählt worden ist, kann sein kann bei Ausnutzung des gesamten Suchraumes dennoch sehr Endpunkt an Clientanwendungen übergeben werden, um ihn in zeitaufwändig sein. Da nicht immer die passenden NFPs in Anspruch zu nehmen. Hierbei kommen dienstspezifische oder der gewünschten Kombination zur Verfügung stehen, gibt es auch generische interaktive Clients zum Einsatz [5]. Dies setzt Aushandlungsmechanismen, welche im Gegensatz zur Nutjedoch eine unbeschränkte Nutzbarkeit des Dienstes voraus, die zung statischer Informationen eine individuelle Aushandlung in der Praxis in vielen Fällen, insbesondere im Umfeld kommerjeder Eigenschaft erlauben. Dies ermöglicht Kombinationen, zieller Dienstanbieter, nicht gegeben ist. Stattdessen erfordern die in ihrer Komplexität nur schwerlich über die statische viele Dienste je nach Geschäftsmodell eine Kompensierung für Dienstbeschreibung zu erfassen wären. Diese Mechanismen jeden Aufruf oder einen definierten Zeitraum. Die Modalitäten können eine Optimierung der Parameter mit einem bereits der Abrechnung und der Bezahlung müssen hierbei geklärt ausgewählten Dienst vornehmen. Um das kombinatorische werden. Heutige Dienste erfordern dabei häufig die Übergabe Problem abzuschwächen, werden die gängigen Kombinationen von Token in anwendungsspezifischen Abschnitten der Nachals Profile in SLA-Vorlagen für die weitere Aushandlung zur richten, die nicht ohne semantische Zusatzinformationen als Verfügung gestellt [4]. Die Tabelle I zeigt zwei SLA-Profile solche erkennbar sind, besser sind jedoch dienstübergreifende für den Ökorechner. Beschreibungsformate für Nutzungsbedingungen. Desweiteren möchten sich oftmals sowohl der Dienstanbieter, als auch Tabelle I SLA-P ROFILE FÜR DEN Ö KODIENST der Benutzer gegen eine zu geringe Dienstgüte absichern. Dazu werden vertraglich Parameter wie die Performance eines Name Maximale Antwortzeit Kosten Dienstaufrufes, die Verfügbarkeit im Jahresmittel, sowie dienstStandard 60 Sekunden 5e Express 10 Sekunden 20 e spezifische Eigenschaften vereinbart und als SLA festgelegt. Im Beispiel wird das SLA-Profil Standard ausgewählt. Da es für beide Parameter der Benutzerpräferenz einen Spielraum 4 Engl.: Input, Output, Precondition and Effects; Ein- und Ausgaben, Vorund Nachbedingungen

5 http://www.wsmx.org

4

lässt, wird dieser in der SLA vermerkt. Der Benutzer gibt auf diese Weise sein Einverständnis, dass die Dienstnutzung auch bei veränderten Nutzungsbedingungen, wie etwa geringfügig erhöhtem Preis, fortgesetzt wird. Das Schema einer bereits erstellten SLA ist in Listing 1 vereinfacht dargestellt. Die Ermittlung der Bezahl- und Kompensationsoptionen wird an dieser Stelle nicht betrachtet. SLA { serviceID 1; serviceName Ökorechner ; userID 1; userName USERNAME; payment p e r c a l l ; validity until 12.03.2009; compensation payback ; specifications { p r i c e 5 EUR ; r e s p o n s e t i m e 60 s e c o n d s ; } userPreferences { p r i c e 6 EUR ; r e s p o n s e t i m e 70 s e c o n d s ; } } Listing 1.

Beispielschema einer SLA

C. Anpassung der Dienstgüte

eines Aushandlungsprozesses Web Services gesucht, die dazu beitragen, eine gewünschte Dienstgüte zu realisieren. Das Ergebnis des Bindens ist ein konkreter Ausführungsplan der Komposition. Die qualitätsabhängige Suche und Selektion von Web Services ist eine aktuelle Herausforderung in der Forschung. Entsprechende Binding-Komponenten wurden u.a. in den Forschungsprojekten ASG [6], SeCSE [7] und Adaptive ActiveBPEL [8] entwickelt. (mehr hierzu im Kapitel IV B) Ist die Adaptierbarkeit von Diensten gegeben, dann generiert die Aushandlung eine gültige SLA und beendet die Phase der Vorbereitung. IV. L AUFZEIT: AUSFÜHRUNG , Ü BERWACHUNG UND E INHALTUNG Nach dem Abschluss eines Dienstnutzungsvertrages beginnt die Laufzeitphase. In dieser dürfen je nach Bezahlmodell beliebig oder begrenzt viele Dienstaufrufe erfolgen. Parallel zur Interaktion zwischen Benutzer und Dienst werden Komponenten auf der Ausführungsplattform für die Überwachung der Einhaltung des SLA, sowie für mögliche Anpassungen der Dienste und Prozesse aktiviert. Auch für diese Phase des Lebenszyklus existiert die notwendige Infrastruktur in dieser Form noch nicht und wird durch unseren Ansatz konzipiert und umgesetzt.

Voraussetzung für eine erfolgreiche Aushandlung ist die Fähigkeit eines Web Services, seine Dienstgüte anzupassen. A. Ausführung und Überwachung Nach den Vorbereitungen zur Nutzung, die in der Regel nur Während monolithische Dienste dafür eine Konfigurationsschnittstelle zur Verfügung stellen müssen, um interne Einstel- einmal pro Dienst oder gar Dienstanbieter durchgeführt werden lungen verändern zu können, bietet sich für dekomponierbare müssen, findet die eigentliche Dienstnutzung statt. Nebenläufig dazu werden auf der Ausführungsplattform, auf dem ClientDienste ein generischer Ansatz an. Die Dienstgüte einer Komposition hängt im Wesentlichen system oder seitens Dritter Überprüfungen der getroffenen von der Dienstgüte der aufgerufenen Sub Web Services ab. Vereinbarungen durchgeführt. Während einige Verletzungen, Durch die Auswahl geeigneter Sub Web Services kann die speziell bei Garantien unter Angabe von Durchschnittswerten, Dienstgüte der Komposition verändert werden. Auf diesem erst unmittelbar zum Ende der vereinbarten Vertragslaufzeit Prinzip basiert der Adaptionsmechanismus spätes Binden (engl. festgestellt werden können, erfordern andere Parameter ein Monitoring idealerweise in Echtzeit, möglicherweise unterLate-Binding) [6]. stützt durch Vorhersagen basierend auf vorherigen Mess- und Berechnungswerten. Die zu überwachenden Eigenschaften eines Dienstes lassen sich prinzipiell unterscheiden in von außen überwachbare und solche, die eine Unterstützung der Laufzeitplattform benötigen. Klassische QoS-Eigenschaften wie Antwortzeit, Verfügbarkeit oder auch die Feststellung der Verschlüsselung auf Transportebene fallen in die erste Kategorie, während die Performance oder der datenschutzgerechte Umgang mit eingehenden Nachrichten der zweite Gruppe zugeordnet werden. Für Dienste, die erkennbar als dekomponierbare Prozesse ablaufen, stehen erweiterte Möglichkeiten des Monitoring zur Verfügung [9]. Neben diesen Messungen, die periodisch oder ereignisgesteuAbbildung 2. Adaptionsmechanismus spätes Binden ert Logdaten erzeugen, werden für viele Zwecke aggregierte Kenndaten auf höherer Ebene benötigt, etwa für die Erkennung Abbildung 2 zeigt die Funktionsweise des späten Bindens. von dienstübergreifenden Sicherheitsproblematiken oder die Zur Entwicklungszeit werden keine konkreten Web Services in Korrelation von Ereignissen der Dienstausführung mit solchen die Komposition eingebunden, sondern die geforderten Funk- der Prozessabarbeitung, wie in Abbildung 3 dargestellt. Die retionalitäten und Schnittstellen lediglich in Form so genannter sultierende Architektur aus Sensoren, Datenbank und datenverTasks formal beschrieben. Auf dieser Basis werden im Rahmen wertenden Clients erlaubt eine Verteilung über mehrere Systeme

5

und damit eine hohe Skalierbarkeit und Messgenauigkeit. Wir haben einen Monitoringdienst mit mehreren vertragsabhängig agierenden Sensoren und Aggregatoren implementiert und streben eine Kombination mit Vorhersagemodellen an.

Abbildung 3.

Überwachung der Dienstausführung

Im Fall einer durch den Monitor festgestellten Vertragsverletzung sind SLA-Spielräume hilfreich, die es Softwareagenten erlauben, basierend auf den initialen Präferenzen des Benutzers an seiner Stelle eine automatische Neuaushandlung des Vertrages mit eng gesetztem Verhandlungsrahmen durchzuführen. Schlägt eine solche Neuaushandlung fehl, so muss der Vertrag annulliert, die Zugriffsberechtigung für den Dienst entzogen und der Benutzer informiert werden. Für die automatische Neuaushandlung existieren verschiedene Algorithmen, beginnend vom einfachen Abgleich von Angebot und Nachfrage über Gegenangebote bis hin zu mehrstufigen Verfahren [10]. Ein weiteres Merkmal zur Klassifizierung der Aushandlungsalgorithmen betrifft die Einteilung in optimistische und konservative Algorithmen, wobei letztere erst die Systemressourcen reservieren, bevor sie eine Garantie dafür abgeben. Die Reservierung erfordert einen ganzheitlich auf solche Anforderungen ausgelegten Systemaufbau, der echtzeitfähig sein muss, um beispielsweise Zugriffszeiten zu garantieren. Dieser Ansatz gerät spätestens beim netzübergreifenden Einsatz an seine Grenzen, so dass wir ihn nur in Kombination mit optimistischen Verfahren für sinnvoll halten und diese Kombination auch umsetzen. Die durch das Monitoring gestützte Kombination stellt ein Unterscheidungsmerkmal zu existierenden Ansätzen wie COMQUAD [11] dar. B. Einhaltung der Verträge in Prozessen Die Einhaltung der vereinbarten Dienstgüte zwischen einem Prozess und einem Dienstnutzer hat oberste Priorität. Eine Verletzung stellt einen Vertragsbruch dar, der dem Provider der Dienstleistung einen erheblichen wirtschaftlichen Schaden

zufügen kann. Zum einen muss der Anbieter mit Schadensersatzansprüchen rechnen, zum anderen wird die Bewertung des komponierten Dienstes negativ ausfallen. Eine schlechte Bewertung kann den allgemeinen Ruf eines Services schädigen und die Nutzerzahl verringern, selbst wenn zukünftige Kompositionen andere Sub Web Services verwenden. Zur Sicherstellung der Dienstgüte kann der Betreiber einer Dienstleistung auf bewährte Mechanismen wie z. B. replizierte Hardwarestrukturen oder spezielle Netzwerkprotokolle zurückgreifen. Handelt es sich bei dem angebotenen Web Service um eine Komposition, stößt deren Betreiber hierbei jedoch an Grenzen. Die Dienstgüte der Komposition hängt hauptsächlich von der Qualität ab, mit der die von der Komposition genutzten Dienste ihre geforderte Funktionalität erbringen. Zwar wird der Betreiber der Komposition mit diesen Sub Web Services ebenfalls SLAs aushandeln, doch eine Absicherung der Dienstgüte ist für den Betreiber der Komposition nicht möglich. Um zu verhindern, dass sich eine Dienstgüteverletzung eines Sub Web Services auf die Qualität der Komposition auswirkt, existieren mehrere Adaptionsmechanismen, von der Substitution eines Einzeldienstes bis hin zur autonomen Umgestaltung von Teilen des Prozesses zur Laufzeit. Da es für letzteren Ansatz bisher nur unzureichende Erkenntnisse über die Nutzbarkeit speziell bei Echtzeitanforderungen gibt und eine automatische Komposition vorausgesetzt wird (wir verweisen auf [12] und [6]), konzentrieren wir uns auf den Adaptionsmechanismus erneutes Binden (engl. Re-Binding). Nach dem derzeitigen Stand der Forschung (Bindingkomponenten in [6], [7] und [8]) wird Re-Binding immer dann durchgeführt, wenn im Rahmen des Monitorings eine SLA-Verletzung oder ein Ausfall eines Sub Web Services registriert wird. Während des Re-Bindings wird dann versucht, durch Austausch der verwendeten Sub Web Services die Dienstgüte der Komposition zu erhalten. In unserem Beispiel (siehe Abbildung 4) hat der Kunde eine Obergrenze von 6 e und 70 Sekunden Antwortzeit vertraglich festgelegt. Nach der Ermittlung der Öko-Werte aller SubKomponenten (insg. 2 e und 20 Sekunden verbraucht) soll das Produkt des Kunden durch den Dienst von Provider A (Zertifiziere (A)) zertifiziert werden. Dieser Service ist jedoch momentan nicht verfügbar, was nach 10 Sekunden durch die Monitoring-Komponente erkannt wird. Für die Fehlerkorrektur durch ein Re-Binding wird eine Zeit von 5 Sekunden benötigt. Um die vertraglich vereinbarte Antwortzeit von 70 Sekunden einzuhalten, muss ein neuer Zertifizierungsdienst mit einer Antwortzeit von 25 Sekunden gefunden werden. Ein solcher Dienst (Antwortzeit 15 Sekunden) wird durch den Provider B für 4 e angeboten. Dieser Preis liegt im Rahmen der Vertragsbedingungen und die Komposition kann ihre Dienstleistung im vordefinierten Rahmen erbringen. Wie auch schon der Adaptionsmechanismus spätes Binden ist auch das erneute Binden Gegenstand aktueller Forschung. Eine gemeinsame Herausforderung beider Prozesse bildet die Selektion geeigneter Sub Web Services. Eine ausschließlich qualitätsabhängige Selektion, wie dies u. a. die bereits genannten Forschungsprojekte ASG, SeCSe und Adaptive ActiveBPEL betreiben, ist nicht ausreichend. Jeder Re-Binding-Prozess erfordert Rechenzeit und verlängert die Ausführungszeit der Komposition. Dadurch wird die Einhaltung der Antwortzeit der

6

Abbildung 4.

Adaptionsmechanismus erneutes Binden

der Prototyp um die Berücksichtigung der oben erwähnten Re-Binding-Wahrscheinlichkeit erweitert. Das Migrationsproblem stellt eine zusätzliche Herausforderung beim Ersetzen von Diensten dar. Es beschreibt, wie der Ausführungsstatus des entfernten Services auf den neu eingefügten Service übertragen wird [15]. Da der Fokus unserer Arbeit auf der Selektion und Identifikation der passenden Dienste liegt, lösen wir dieses Problem vorerst pragmatisch. Ein neu eingesetzter Service beginnt seine Abarbeitung immer von vorn, Statusinformationen werden demnach nicht übertragen. Eine weitere Herausforderung im Rahmen des erneuten Bindens ist die Festlegung des Zeitpunktes der Ersetzung. Ziel ist es, die Anzahl der Re-Binding-Prozesse möglichst gering zu halten. Geringfügige SLA-Verletzungen, z. B. eine Überschreitung der Antwortzeit von einer Minute um wenige Millisekunden, können oftmals durch den Einbau von Puffern und ohne Austausch des Service kompensiert werden. Schwerwiegende Verletzungen, z. B. eine Überschreitung der Antwortzeit von einer Minute um mehrere Minuten, resultieren immer in einem Re-Binding-Prozess. Die Schwierigkeit besteht jedoch darin zu entscheiden, ab wann eine SLA-Verletzung als schwerwiegend gilt. Das Ausmaß einer SLA-Verletzung ist nicht vorhersagbar, sondern kann immer nur nachträglich ermittelt werden. Ersetzt man zu zeitig, so verlängert man unnötig die Ausführungszeit. Ersetzt man dagegen zu spät, vernichtet man wertvollen Handlungsspielraum. Neben der Lösung des Selektionsproblems ist auch die Berechnung des Re-Binding-Zeitpunktes ein Schwerpunkt unserer Arbeit. Bisherige Lösungen im Rahmen des erneuten Bindens vernachlässigen leider dieses Problem. In den meisten Ansätzen wird ein Re-Binding-Prozess sofort nach Registrierung einer SLA-Verletzung bzw. eines Serviceausfalls durchgeführt. Wir wollen diese Ansätze um sinnvolle Re-Binding-Zeitpunkte erweitern.

Komposition gefährdet. Das Ziel einer Selektion muss daher nicht nur die Erfüllung der Qualitätsanforderungen des Clients sein, sondern vor allem auch die Reduzierung möglicher ReBinding-Prozesse. Um dies zu erreichen sind Dienste zu binden, die ihre Qualitätszusagen zuverlässig einhalten. Die Zuverlässigkeit eines Dienstes bezüglich seiner Qualitätsversprechen kann nicht aus seinen aktuellen Qualitätsparametern abgelesen werden. Hierfür ist die Auswertung vergangener Interaktionen notwendig. Ein Maß für die Zuverlässigkeit bildet die Anzahl an Vertragsverletzungen in vergangenen Interaktionen. Diese Daten werden im Rahmen des Monitorings erfasst und stehen in einer Datenbank zur Verfügung. Ein zuverlässiger Dienst zeichnet sich dadurch aus, dass er in der Vergangenheit die vertraglich vereinbarte Dienstgüte möglichst oft einhalten konnte. Ziel unserer Arbeit ist es, die gegenwärtigen Ansätze zur Selektion von Sub Web Services im Rahmen von spätem und erneutem Binden so zu erweitern, dass die Monitoring-Historie zur Identifikation zuverlässiger Dienste genutzt wird. Hierfür definieren wir Zuverlässigkeit als neue Eigenschaft für Dienste sowie Re-Binding-Wahrscheinlichkeit als neue Eigenschaft für Ausführungspläne. Die Zuverlässigkeit V. NACHBEREITUNG DER D IENSTNUTZUNG eines Dienstes gibt als Prozentzahl an, in vielen Fällen Nach dem regulären Ende der Vertragslaufzeit oder dem ein Dienst in der Vergangenheit seine Dienstgüteversprechen gebrochen hat. Auf Basis dieser Information kann die Re- Erreichen der maximalen Anzahl an Dienstaufrufen wird eine Binding-Wahrscheinlichkeit eines Ausführungsplans berechnet abschließende Überprüfung des Vertrags vorgenommen. Hierbei werden. Die Re-Binding-Wahrscheinlichkeit gibt an, wie sicher treten eventuell Kompensationsforderungen, Strafzahlungen es bei einem Ausführungsplan zu einem erneuten Binden oder andere weitere Aktionen auf. Darüber hinaus ist es sinnvoll, den Benutzer interaktiv zu kommt. Durch dieses Attribut ist die Ordnung alle möglichen Ausführungspläne einer Komposition bezüglich ihrer Stabilität befragen, ob er mit der gebotenen Leistung zufrieden war. möglich. Existierende Algorithmen zur Selektion qualitativ Ein entsprechendes Formular kann, ähnlich wie bereits in der geeigneter Ausführungspläne, wie der genetische Algorithmus initialen Aushandlung, basierend auf den Eigenschaften des [7] oder die Integer Programming [13], sind dann nur um die Dienstes und des Vertragsinhaltes individuell gestaltet werden. Beachtung der Re-Binding-Wahrscheinlichkeit zu erweitern. Mit der vertragsgestützten Bewertung des Web Services Für detaillierte Informationen zu unserem Ansatz sei der schließt sich der Kreislauf der Dienstnutzung, wie in Abbilgeneigte Leser auf [14] verwiesen. dung 5 dargestellt. Für die Berechnung eines geeigneten Ausführungsplanes Die Beurteilung des Nutzers geht in die Gesamtbewertung im Rahmen von Late- und Re-Binding existiert bereits ein des Dienstes ein und beeinflusst auf diese Weise die DienstPrototyp. Dieser arbeitet auf Basis von vier verschiedenen auswahl zukünftiger Anwender. Die Überprüfung von SLAqualitätsabhängigen Selektionsalgorithmen, jeder von ihnen Verstößen wirkt sich auf die zukünftige Bildung von SLAmit einer anderen Komplexität. In Abhängigkeit der Anzahl Profilen aus. Zu optimistisch abgeschlossene Verträge, die zur der verfügbaren Ausführungspläne wird der jeweils effizienteste Laufzeit gebrochen wurden und zusätzlichen administrativen Algorithms zur Berechnung herangezogen, um so die Vorteile Aufwand erforderten, müssen vermieden werden. Neben diesen der verschiedenen Alternativen zur kombinieren. Aktuell wird technischen Aspekten lassen sich die Bewertungen der Dienste

7

Zur Laufzeit wird die Dienstausführung überwacht, um Verletzungen der zugesicherten NFPs und Dienstgüte so früh wie möglich zu erkennen und Kompensationsmaßnahmen wie die Anpassung der Komposition vorzunehmen. Die Dienstgüte ist ein wichtiges Kriterium für den Ruf eines Services oder Anbieters und wird nach Abschluss der Dienstnutzung vom Anwender bewertet. Dieses Feedback sowie die in der Monitoring-Historie gesammelten Daten des Dienstes schließen den Lebenszyklus der NFPs, indem sie abschließend in den Auswahlprozess für zukünftige Kompositionen eingehen. L ITERATUR

Abbildung 5.

Lebenszyklus der SLA-gestützten adaptiven Dienstnutzung

und Verträge auch für eine weitergehende Rückwirkung bis in die Dienstentwicklung und -innovation verwenden. Diese verlängerte Feedbackschleife ginge jedoch über die Betrachtungen in dieser Arbeit hinaus. In unserem Beispiel sieht der Benutzer des Ökorechners seine Erwartungen als erfüllt an, auch wenn die ursprünglichen optimalen Bedingungen (5 e Kosten) nicht eingehalten werden konnten und bewertet die Dienstausführung mit der Note gut. VI. Z USAMMENFASSUNG In diesem Artikel stellen wir die Betrachtung nichtfunktionaler Eigenschaften von Services über deren gesamten Lebenszyklus dar. Wir betrachten existierende Vorarbeiten, die sich jeweils nur auf Teilaspekte beziehen und überführen die Erkenntnisse erstmals in eine ganzheitliche Betrachtung. Hierbei auftretende Probleme werden aufgezeigt und Verbesserungen skizziert. Unser Ziel im Kontext des Future Internet of Services ist, eine dynamische, flexible und vertraglich garantierte Vermittlung von Diensten zu ermöglichen. Dynamische Adaptions- und Aushandlungsroutinen werden sowohl in der Phase der Modellierung, als auch in der Laufzeitumgebung benötigt, um die Anforderungen der Dienste und die verfügbaren Ressourcen der Plattform in Einklang zu bringen. Zur Optimierung des Auswahlprozesses werden NFPs in die Dienstbeschreibung aufgenommen und anschließend flexible SLAs ausgehandelt, die Spielräume für eine optionale, agentenbasierte Neuaushandlung enthalten. SLA-Vorlagen mit gängigen Kombinationen von NFPs erleichtern den Prozess.

[1] J. O’Sullivan, D. Edmond and A. H. T. Hofstede: „Formal description of non-functional service properties“. Technischer Bericht FIT-TR-2005-01, University of Technology, Brisbane, Australien, 2005. [2] S. Röttger and S. Zschaler: „CQML+: Enhancements to CQML“. In Proceedings of 1st. Intl. Workshop on QoS in CBSE, Toulouse, Frankreich, 2003. [3] I. Braun, A. Strunk, G. Stoyanova and B. Buder: „ConQo - A Context- and QoS-Aware Service Discovery“. IADIS Intl. Conference WWW/Internet 2008, Freiburg, Deutschland, 2008. [4] P. Hasselmeyer, H. Mersch, B. Koller, H.-N. Quyen, L. Schubert and P. Wieder: „Implementing an SLA Negotiation Framework“. eChallenges 2007, Den Haag, Niederlande, 2007. [5] J. Spillner, I. Braun and A. Schill: „Flexible Human Service Interfaces“. In Proceedings of 9th Intl. Conference on Enterprise Information Systems (ICEIS), Funchal, Madeira, Portugal, 2007. [6] H. Meyer; D. Kuropka and P. Tröger: „ASG-Techniques of Adaptivity“. In Proceedings of Autonomous and Adaptive Web Services, Dagstuhl, Deutschland, 2007, http://asg-platform.org/cgi-bin/twiki/view/Public. [7] M. Di Penta; R. Esposito; M. L. Villani; R. Codato; M. Colombo and E. Di Nitto: „WS Binder: a Framework to enable Dynamic Binding of Comosite Web Services“. In Proceedings of the Intl. Workshop on Service Oriented Software Engineering (IW-SOSE’06), Shanghai, China, 2006, http://secse.eng.it. [8] F. A. A. Lins; J. Carlos and N. S. Rosa: „Adaptive Web Service Composition“. In Proceedings of 4th Intl. Workshop on SOA and Web Services Best Practices, pp. 40–51, Portland, Oregon, USA, 2006. [9] L. Zeng, H. Lei and H. Chang: „Monitoring the QoS for Web Services“. In Proceedings of Intl. Conference Service-Oriented Computing - ICSOC’07, Wien, Österreich, 2007. [10] M. Mulugeta and A. Schill: „An Approach for QoS Contract Negotiation in Distributed Component-Based Software“. In Proceedings of 10th Intl. ACM SIGSOFT Symposium on Component-Based Software Engineering, Medford, Massachusetts, USA, 2007. [11] R. Aigner, H. Berthold et. al.: „COMQUAD - Komponentenbasierte Softwaresysteme mit zusagbaren quantitativen Eigenschaften und Adaptionsfähigkeit“. Technischer Bericht TUD-FI02-10, Technische Universität Dresden, 2002. [12] G. Canfora, M. Di Penta, R. Esposito and M. L. Villani: „QoS-Aware Replanning of Composite Web Services“. IEEE International Conference on Web Services (ICWS’05), icws, pp. 121–129, Orlando, Florida, USA, 2005. [13] L. Zeng, A. Benatallah, H. H. A. Ngu, M. Dumas, J. Kalagnanam and H. Chang: „QoS-aware middleware for web services composition“. IEEE Trans. on Software Engineering, Ausgabe 30/4, 2004. [14] A. Strunk: „A Feedback-Aware Binding Component“. 1st Internet of Services Doctorial Symposium, I-ESA Konferenz, Berlin, Deutschland, 2008. [15] A. Fugetta, G. Picco and G. Vigna: „Understanding Code Mobility“. IEEE Trans. on Software Engineering, Ausgabe 24/5, 1998.