Kontext-basierte Personalisierung von Web Services Markus Keidl, Stefan Seltzsam, Christof König und Alfons Kemper Universität Passau Fakultät für Mathematik und Informatik 94030 Passau <Nachname>@db.fmi.uni-passau.de Meine Damen und Herren, willkommen zu diesem Vortrag über Kontext-basierte Personalisierung von Web Services. Ich hoffe, ich kann Ihnen nahe bringen, warum wir an der Universität Passau uns mit diesem Thema beschäftigen und welche Vorteile wir in der Personalisierung von Web-Services sehen.

Gliederung Motivation Kontext für Web Services Dienstplattform ServiceGlobe Dynamische Dienstauswahl Zusammenfassung und Ausblick Nach einer kurzen Motivation will ich dazu zuerst erläutern, was wir unter Kontext versehen und welche Arten von Kontextinformationen wir bisher betrachtet und untersucht haben. Anschließend möchte ich kurz auf die Dienstplattform SG eingehen, die an der Universität Passau entwickelt wurde und die den Rahmen für unsere Forschung und auch den Rest dieses Vortrags bildet. Den Hauptteil des Vortrags bildet die dynamische Dienstauswahl. Sie ermöglicht -- durch das Einbinden von sog. Vorgaben in den Kontext von Web Services -- die Entwicklung von personalisierbaren und flexiblen Web Services. Am Schluss will ich noch kurz darauf eingehen, woran wir gerade arbeiten bzw. in Zukunft arbeiten wollen. BTW '03 - Leipzig - Kontext-basierte Personalisierung von Web Services

Motivation Einsatz von Web Services im B2C-Bereich Heterogener Nutzerkreis erfordert Personalisierbarkeit und Flexibilität  Kontext inkl. Vorgaben für dynamische Dienstauswahl Internet als verteiltes System  Dienstplattform ServiceGlobe In den letzten Jahren haben sich Web Services als Mittel zur Integration von heterogenen Anwendungen im B2B-Bereich etabliert. Aber auch im Bereich B2C finden sie vermehrt Einsatz und dies wird auch in Zukunft vermehrt der Fall sein. Allerdings findet man im B2C-Bereich andere Voraussetzungen vor als im B2B-Bereich. Nicht wenige Unternehmen sondern sehr viele Benutzer mit unterschiedlichen Vorstellungen und Präferenzen. Zusätzlich bietet natürlich das Internet als verteiltes System eine Vielzahl von Ressourcen an, die verwendet werden können, und diese versuchen wir mit der Dienstplattform SG für die Ausführung von Web Services zu nutzen. Nachdem ich den Begriff "Kontext" nun bereits ein paar mal verwendet habe, will ich zuerst erklären, was wir darunter verstehen. Wie bereits gesagt, bildet SG den Rahmen für diese Arbeit, deshalb will ich im ersten Teil dieses Vortrags dieses System näher beschreiben. BTW '03 - Leipzig - Kontext-basierte Personalisierung von Web Services

Kontext für Web Services Informationen für einen Web Service, um Benutzern eine angepasste und personalisierte Version seiner selbst zur Verfügung zu stellen Auswertung erfolgt automatisch, soweit möglich Übertragung im SOAP-Header  Verwendung ist optional Überleitung ist hier extrem wichtig! Wenn möglich: Echte, abgefangene SOAP-Nachricht mit Kontextinformationen (inkl. Vorgaben) als Link hinter SOAP-Header Ignorieren führt zu Verlust von Funktionalität, ist also schlecht. BTW '03 - Leipzig - Kontext-basierte Personalisierung von Web Services

Kontextinformationen Kontaktinformationen: Name, Adresse, Email, … Klienteninformationen: Hard-/Software, Standort, … Vorgaben für die dynamische Dienstauswahl Eine SOAP-Nachricht mit Kontext im Header kann dann z.B. so aussehen: BTW '03 - Leipzig - Kontext-basierte Personalisierung von Web Services

Was ist ServiceGlobe? Forschungsplattform für Web Services Implementiert in Java Basierend auf Standards (XML, SOAP, UDDI, WSDL, …) Entwicklung von neuen Technologien für die Ausführung und Entwicklung von Diensten Vorteile von eigenem System: Man kann daran herumbauen und besonders bei SG existieren eine Reihe von speziellen Eigenschaften. BTW '03 - Leipzig - Kontext-basierte Personalisierung von Web Services

Eigenschaften von ServiceGlobe Dienste sind mobiler Code Laden des Codes von Diensten zur Laufzeit Verteilung von Diensten  Runtime Service Loading Sicherheitssystem Transaktionssystem Lastbalancierung und automatische Dienstreplikation Wichtigste Eigenschaft: Laden des Codes der Web Services von Code-Bibliotheken zur Laufzeit ermöglicht eine beliebige und möglichst optimale Verteilung der Dienste (ebenfalls zur Laufzeit) auf beliebige Rechner, sog. Service-Hosts, des Systems. Lastbalancierung zur Vermeidung von Überlast-Situationen BTW '03 - Leipzig - Kontext-basierte Personalisierung von Web Services

Einteilung von Diensten Zur besseren Unterscheidung von verschiedenen Typen von Diensten verwenden wir in SG folgende Einteilung von Diensten: externe, interne, statische und dynamische BTW '03 - Leipzig - Kontext-basierte Personalisierung von Web Services

Beispielszenario: Portal für Reiseagenturen Ich möchte Ihnen diese Diensttypen und auch die Ausführung eines Dienstes in SG anhand eines kleinen Beispiels demonstrieren: Portal für Reiseagenturen. Kennzeichnen von internen/externen bzw. statischen/dynamischen (internen) Diensten. 3 Phasen, ersten beiden verwenden externe Dienste von Teilnehmern des Portals Phase 3 verwendet internen Dienst -> Ausführung wird anhand folgender Animation gezeigt. BTW '03 - Leipzig - Kontext-basierte Personalisierung von Web Services

Architektur von ServiceGlobe in oder bei Leipzig Klient Zoo Leipzig Externer Dienst Service-Host Service-Host Auerbachs Keller Externer Dienst Code-Bibliothek AttaktionenSuche Reiseplanung Service-Host erklären! Und genau dieser Vorgang, das Nachfragen in UDDI nach Diensten mit einer definierten Funktionalität und den Aufruf dieser Dienste, automatisiert die dynamische Dienstauswahl. In der Realität wird es natürlich so sein, dass ein UDDI-Dienstverzeichnis hunderte oder tausende passende Dienste enthalten wird. Diese kann und will man nicht alle aufrufen. Auch hier hilft die dynamische Dienstauswahl, indem sie durch Vorgaben eine Beeinflussung der Auswahl und des Aufrufs ermöglicht. AttraktionenSuche UDDI- Verzeichnis Thomaskirche Externer Dienst Reiseplanung BTW '03 - Leipzig - Kontext-basierte Personalisierung von Web Services

Gliederung Motivation Dienstplattform ServiceGlobe Dynamische Dienstauswahl Kontext für Web Services Zusammenfassung und Ausblick BTW '03 - Leipzig - Kontext-basierte Personalisierung von Web Services

UDDI – Eine kurze Einführung Datenstrukturen: businessEntity businessService bindingTemplate tModel (technical model) BTW '03 - Leipzig - Kontext-basierte Personalisierung von Web Services

Dynamische Dienstauswahl UDDI: Zuordnung von Diensten zu tModels (Beschreibung der Funktionalität und der Schnittstelle) 'Aufruf eines tModels' anstatt 'Aufruf eines Dienstes' Beeinflussung von Auswahl und Aufruf durch Vorgaben Und damit zum Hauptteil des Vortrags, nämlich der dynamischen Dienstauswahl. Dazu ist es notwendig, einen kurzen Exkurs in UDDI zu geben. Bei Entwicklung: Nicht mehr Aufrufe an spezifische Dienste, sondern nur noch Aufrufe von tModels. Dienstplattform wird dann aus UDDI die passenden Dienste auswählen und diese aufrufen. BTW '03 - Leipzig - Kontext-basierte Personalisierung von Web Services

Beispiel zur Dienstauswahl Zoo Leipzig S_3 UDDI-Verzeichnis tModel: Attraktion S_1 S_2 S_3 Auerbachs Keller S_2 Programmieren AttraktionenSuche Thomaskirche S_1 Aufruf des tModels Attraktion Aufruf der Dienste S_1 S_2 BTW '03 - Leipzig - Kontext-basierte Personalisierung von Web Services

Klassifikation von Vorgaben Metadaten-Vorgaben Orts- Vorgaben Modus- Vorgaben Antwort- Vorgaben Ergebnis- Vorgaben Selektion Eigenschaft Timeout FirstN Präferenzen X Einschränkungen … Nun zu den Vorgaben im einzelnen: Anwendung auf Metadaten (UDDI, …) Anwendung auf SOAP-Antwort BTW '03 - Leipzig - Kontext-basierte Personalisierung von Web Services

Metadaten-Vorgaben XPath-Anfragen auf Dienst-Metadaten Metadaten: UDDI + zusätzliche Beispiele: <metadataPreference> /businessEntity/name="Sheraton" </metadataPreference> <metadataCondition> /ServiceMetadata/CostsPerCall="0" </metadataCondition> ServiceMetadata: Zusätzliche Metadaten, die im SG-System zur Verfügung gestellt werden. Vorgaben in ihrer XML-Repräsentation, so wie sie auch im Kontext stehen würden BTW '03 - Leipzig - Kontext-basierte Personalisierung von Web Services

Orts-Vorgaben Auswahl anhand des Dienst-Standorts (festgelegt in UDDI) Beispiele: <locationCondition addressType="Geographical" serviceType="All"> <center>DE-SN-LEJ</center> <maxDistance>50km</maxDistance> </locationCondition> Erklärung von serviceType benötigt Kenntnis der unterschiedlichen Diensttypen am Anfang. Orts-Vorgaben können nicht nur festlegen, wo aufgerufene Dienste liegen müssen, sondern auch auf welchen Rechnern/Service Hosts aufgerufene Dienste instanziiert werden dürfen. BTW '03 - Leipzig - Kontext-basierte Personalisierung von Web Services

Modus-Vorgaben Spezifikation der Anzahl der aufzurufenden Dienste Aufrufmodi: One, Some, All Beispiele: <modeCondition modeType="Some" number="5" numberType="Percentage"/> BTW '03 - Leipzig - Kontext-basierte Personalisierung von Web Services

Antwort-Vorgaben Eigenschafts-Vorgaben: Abfrage von Eigenschaften einer Antwort Einfügen von Eigenschaften durch Dienste, Dienstplattform Selektions-Vorgaben: XPath-Anfragen auf SOAP-Antwort Beispiel: <propertyCondition> <signature> <signatureDN> CN=Cust,O=Universität Passau, C=DE </signatureDN> </signature> </propertyCondition> BTW '03 - Leipzig - Kontext-basierte Personalisierung von Web Services

Ergebnis-Vorgaben Timeout-Vorgaben FirstN-Vorgaben Beispiele: <timeoutCondition value="100" valueUnit="Seconds"/> <firstNCondition number="10" numberType="Percentage"/> Erwähnen: Solche Vorgaben sollten natürlich nur bei kostenfreien Diensten verwendet werden. Ansonsten muss man ggf. sehr viel zahlen, obwohl man die Antworten gar nicht abwartet. Natürlich kann man mit einer einzelnen Vorgabe alleine recht wenig erreichen, dazu muss man mehrere Vorgaben kombinieren. BTW '03 - Leipzig - Kontext-basierte Personalisierung von Web Services

Kombination von Vorgaben Operatoren: AND, OR Negation: Metadaten-, Selektions-Vorgaben: negierte XPath-Ausdrücke Orts-, Eigenschafts-Vorgaben: momentan noch nicht möglich Modus-, Ergebnis-Vorgaben: nicht sinnvoll BTW '03 - Leipzig - Kontext-basierte Personalisierung von Web Services

Beispiel für eine Vorgaben-Kombination Beispiel: <orGroup> <andGroup> <metadataCondition> /ServiceMetadata/ServiceType="Dynamic" </metadataCondition> <locationPreference serviceType="Dynamic" addressType="Geographical"> <pattern>DE-SN-LEJ</pattern> </locationPreference> </andGroup> <locationPreference serviceType="All" addressType="Geographical"> <pattern>DE-*-*</pattern> </locationPreference> </orGroup> Sehr genau erklären: orGroup, andGroup und auch die Vorgaben. Achte auf Condition=Einschränkung und Preference=Präferenz <pattern>Tag genauer erklären Vorgabe bedeutet: Beliebige Dienste (statisch + dynamisch) in ganz Deutschland oder nur dynamische Dienste, vorzugsweise in Leipzig BTW '03 - Leipzig - Kontext-basierte Personalisierung von Web Services

Auswertung von Vorgaben Zusammenfassen aller Vorgaben für einen tModel-Aufruf Transformation in DNF Auflösung von Konflikten basierend auf Prioritäten Parallele Auswertung von disjunktiv verknüpften AND-Termen Die Frage ist jetzt natürlich, woher kommen die Vorgaben: a) sind im Web Service codiert -> schlecht, da fix und nicht personalisierbar b) aus dem Kontext und werden automatisch übernommen -> flexibel und personalisierbar BTW '03 - Leipzig - Kontext-basierte Personalisierung von Web Services

Quellen für Vorgaben Angabe direkt im Web Service Vorgaben im Kontext: Klient fügt Vorgaben in Kontext ein Service-Hosts Web Services in der Aufrufkette BTW '03 - Leipzig - Kontext-basierte Personalisierung von Web Services

Auswertungsstrategie Metadaten Ort Modus Antwort Ergebnis                     Transformation in disjunktive Normalform BTW '03 - Leipzig - Kontext-basierte Personalisierung von Web Services

Auswertungsstrategie Metadaten Ort Modus Antwort Ergebnis                 BTW '03 - Leipzig - Kontext-basierte Personalisierung von Web Services

Gliederung Motivation Kontext für Web Services Dienstplattform ServiceGlobe Dynamische Dienstauswahl Zusammenfassung und Ausblick BTW '03 - Leipzig - Kontext-basierte Personalisierung von Web Services

Kontext für Web Services Informationen für einen Web Service, um Benutzern eine angepasste und personalisierte Version seiner selbst zur Verfügung zu stellen Auswertung erfolgt automatisch, soweit möglich Übertragung im SOAP-Header  Verwendung ist optional Überleitung ist hier extrem wichtig! Wenn möglich: Echte, abgefangene SOAP-Nachricht mit Kontextinformationen (inkl. Vorgaben) als Link hinter SOAP-Header Ignorieren führt zu Verlust von Funktionalität, ist also schlecht. BTW '03 - Leipzig - Kontext-basierte Personalisierung von Web Services

Kontextinformationen Kontaktinformationen: Name, Adresse, Email, … Klienteninformationen: Hard-/Software, Standort, … Vorgaben für jeden tModel-Aufruf Eine SOAP-Nachricht mit Kontext im Header kann dann z.B. so aussehen: BTW '03 - Leipzig - Kontext-basierte Personalisierung von Web Services

Zusammenfassung Kontext für Web Services Dienstplattform: ServiceGlobe Architektur Schlüsseleigenschaften Dynamische Dienstauswahl Personalisierbare und flexible Ausführung von Diensten Diese Dienstplattform bildete den Rahmen für unsere Forschung an der dynamischen Dienstauswahl, die zusammen mit der Verwendung von Kontext eine personalisierbare und flexible Entwicklung und Ausführung von Diensten ermöglicht. BTW '03 - Leipzig - Kontext-basierte Personalisierung von Web Services

Ausblick Caching von SOAP-Antworten Evaluierung von automatisch auswertbaren Kontextinformationen und Dienst-Metadaten Weitere Informationen (inkl. Demo): http://www.db.fmi.uni.passau.de/projects/sg Meine Damen und Herren, vielen Dank für Ihre Aufmerksamkeit. BTW '03 - Leipzig - Kontext-basierte Personalisierung von Web Services