Entwicklung einer transnationalen experimentbasierten Lernumgebung im Leonardo-Da-Vinci-Programm der Europäischen Union

Größe: px
Ab Seite anzeigen:

Download "Entwicklung einer transnationalen experimentbasierten Lernumgebung im Leonardo-Da-Vinci-Programm der Europäischen Union"

Transkript

1 Hasso-Plattner-Institut für Softwaresystemtechnik an der Universität Potsdam Entwicklung einer transnationalen experimentbasierten Lernumgebung im Leonardo-Da-Vinci-Programm der Europäischen Union Frank Feinbube, Peter Kruttke, Daniel Richter, Alexander Schäfer, Robert Wierschke {Frank.Feinbube, Peter.Kruttke, Daniel.Richter, Alexander.Schaefer, 30. Juni 2007, Potsdam Lehrstuhl Betriebssysteme und Middleware Leitung: Prof. Dr. Andreas Polze Betreuung: Dipl.-Inf. Andreas Rasche Dipl.-Inf. Peter Tröger This project has been sponsered by the Valorisation of an Experiment-based Training System through a Transnational Educational Network Development project. (RO/06/B/F/NT175014) DCL N AXP 1

2 Entwicklung einer transnationalen experimentbasierten Lernumgebung im Leonardo-Da-Vinci-Programm der Europäischen Union Im Rahmen des Bachelorprojektes DNA wurden das Distributed Control Lab (DCL), welches die Benutzung von Echtzeitsteuerungsexperimenten ermöglicht, sowie die ASG-C5-Komponente des Adaptive-Services-Grid-Projektes zur dynamischen Platzierung von Diensten, zu einem neuen System verbunden. Hierbei wurde die ASG-C5-Komponente neu implementiert und ein Schedulingmechanismus sowie eine Komponente zur dynamischen Erweiterung der Dienst-WSDLs hinzugefügt. Es wurde ermöglicht, Ausführungsumgebungen für verschiedene Plattformen bereitzustellen, wobei eine Ausführungsumgebung für.net-webdienste geschaffen wurde. Darüber hinaus wurde die Datenhaltung vereinfacht und für eine heterogene Nutzung optimiert. Vorhandene DCL-Experimente wurden in das neue System portiert und es wurden Werkzeuge zur Entwicklung weiterer Dienste geschaffen. Die vorhandene Verwaltungsschnittstelle wurde neu implementiert und um Algorithmen zur Messdatenauswertung erweitert. Zur Nutzung der Experimente im neuen System wurde die bisherige Benutzungschnittstelle überarbeitet und erweitert. Das neu geschaffene System ermöglicht die verteilte Nutzung von Experimenten/Diensten, welche in verschiedenen Programmierspachen implementiert sind. Diese neue Laborinfrastruktur wird im Rahmen des VET-TREND Projekts mehreren Partnern in ganz Europa zur Verfügung gestellt. Within the bachelor project DNA the Distributed Control Lab (DCL), that facilitates the usage of real-time control experiments, and the ASG-C5 component of the Adaptive Services Grid (ASG) for dynamic placement of services, were combined. Thereby, the ASG-C5 component was reimplemented. Besides, a scheduling mechanism and a component that augments the WSDL of a service with state management methods was created. The new system is able to interoperate with execution environments for miscellaneous programming languages. An execution environment for.net web services was realized. Furthermore, the data management was optimized for heterogeneous usage. In addition to the portation of existing DCL experiments, tools for the creation of new services were added. Also, the existing management interface was reimplemented and extended by algorithms for the analysis of measurement data. The user interface was extended and revised in order to provide better usability for the experiments in the new system. The developed system allows the distributed usage of experiments or web services, that can be provided in miscellaneous programming languages. Within the VET-TREND project the new lab infrastructure will be available to different partners throughout Europe. 2 DCL N AXP

3 INHALTSVERZEICHNIS Inhaltsverzeichnis 1 Glossar 6 2 Einleitung 9 3 Analyse, Erweiterung und Dokumentation einer J2EE-basierenden Infrastruktur für dienstorientierte Architekturen (Robert Wierschke) Infrastruktur für dynamische Dienstausführung Ausgangssituation: ASG-C Gründe für eine Neuimplementierung Erweiterung der Architektur Erweiterung der Dienstschnittstelle WSRF-Methoden Nutzung der zusätzlichen Methoden Bearbeitung von AXP-Dienstanfragen Zustandsmodell für logische Dienstexemplare Anfragenannahme und -weiterleitung WS-Action-basiertes Routing Prioritätenbasiertes Scheduling von Dienstanfragen Konfiguration des Schedulings Probleme Lösungsansätze Verwandte Arbeiten: Zustandsbehaftete Dienste in JAX-WS Ausblick Design und Implementierung von Ausführungsumgebungen für heterogene dynamische Dienstumgebungen (Frank Feinbube) Die Ausführungsumgebungen im AXP-Projekt Was muss ein AXP-Dienstcontainer leisten? Der.NET-Dienstcontainer Der Java-Dienstcontainer Datenbank Die Umstellung des Datenbankzugriffs Die Auslagerung der Datenlogik in die Datenbank Ausblick Integration und Portierung von Steuerungsexperimenten in eine verteilte Experimentierumgebung (Daniel Richter) Experimente als AXP-Dienste Ausgangssituation: Experimente im DCL Vorteile von Experimenten als AXP-Dienste Auftretende Probleme und deren Lösungen Anforderungen an die Implementierung eines DNA-Experiments implementierte DNA-Experimente Vergleich: DCL-Experiment vs. portiertes DNA-Experiment DCL N AXP 3

4 Entwicklung einer transnationalen experimentbasierten Lernumgebung im Leonardo-Da-Vinci-Programm der Europäischen Union 5.2 Softwareentwicklungswerkzeuge für AXP-Dienste/DNA-Experimente Microsoft Visual Studio Projektvorlagen Editor für dienstspezifische Parameter Dienstimplementierungsgenerator Testschnittstelle für AXP-Dienste Klassenbibliothek für den Zugriff auf AXP-Akteure aus.net Tests Ausblick Portierung von Nutzerschnittstellen für eine verteilte Experimentierumgebung (Peter Kruttke) Aufgabenstellung Vorgegebenes DCLFrontend Komponenten desdclfrontend Diskussion der Portierung Allgemeine Betrachtung Abfrage der Dienste/Speicherung in der Datenbank Datenbankschema Experimentnutzung Anpassungen im Frontend Ergebnisdaten Sicherheit Performanz Vorstellung der portierten Dienste DCLExperimentService DCLTicketServer Teilprojekte AxpHelper AxpExperimentRequester ExperimentUsageServer Verwandte Arbeiten Zusammenfassung Ausblick Architektur und Implementierung von Verwaltungssschnittstellen für eine Dienstinfrastruktur (Alexander Schäfer) Anforderungsanalyse Anforderungen Neuimplementierung Implementierung der Grundfunktionalität Dienstinstallation Registrierung von AXP-Dienstcontainern Datenbank Sicherheit Layout DCL N AXP

5 INHALTSVERZEICHNIS 7.3 Implementierung der Messdatenanzeige und Messdatenauswertung Anzeige & Abfrage von Messdaten Messdatenauswertung Zusammenfassung Zusammenfassung Ausblick Fazit 93 9 Literaturverzeichnis Abbildungsverzeichnis Quelltextverzeichnis 97 DCL N AXP 5

6 Entwicklung einer transnationalen experimentbasierten Lernumgebung im Leonardo-Da-Vinci-Programm der Europäischen Union 1 Glossar Anwendungsserver (Application Server) Ein Container (z. B. glassfish), der die Ausführung von - in einem spezifischen Format vorliegenden (z. B. war-datei) - Diensten ermöglicht. AXP (Adaptive Execution Platform) Die Bezeichnung der Neuimplementierung des ASG-C5-Stacks. Dazu gehören im weiteren Sinne auch die entsprechenden AXP- Dienstcontainer. AXP-Dienstcontainerregistrierung Der Dienst des AXP-Projektes, der die automatisierte An-/Abmeldung eines AXP-Dienstcontainers ermöglicht. DNA (DCL N ASG) Der Arbeitstitel unseres Bachelorprojektes, welches die ASG- C5-Software mit dem DCL-Projekt verbindet. Dienst (Web Service) Ein Webdienst im Sinne des W3C. 1 (AXP-)Dienstcontainer Ein Anwendungsserver, der die AXP- Infrastrukturanforderungen erfüllt (siehe auch 4.1.1). Dienstimplementierung Ein Base64-kodiertes Byte-Feld, welche die für den Dienst benötigten Komponenten beinhaltet. Das Format wird durch den Dienstimplementierungstyp bestimmt. Dienstimplementierungstyp Bestimmt das Format der Dienstimplementierung. Der Dienstimplementierungstyp legt fest in welchen AXP-Dienstcontainern der Dienst ausgeführt werden kann. Dienstplatzierungsdienst Der Dienst, den ein AXP-Dienstcontainer zur Verfügung stellen muss, damit in diesem physische Dienstexemplare platziert werden können. Eigenschaften (eines Dienstcontainers) Die Hard- oder Softwareeigenschaften über die ein AXP-Dienstcontainer verfügt (siehe auch 4.1.1). ID Kurzform von Identifikator. Informationsdienst für Dienstimplementierungen Der Dienst des AXP- Dienstcontainers, der zur Extraktion von Informationen aus einer Dienstimplementierung dient (z. B. WSDL). 1 siehe 6 DCL N AXP

7 1 GLOSSAR Installation Bei Installation eines Dienstes wird die Dienstimplementierung mit zugehörigen Parametern in der Datenbank des AXP/ASG abgelegt. Komponente Eine Komponente ist ein Bestandteil eines (Software-)Systems (Systembaustein). Im Kontext der Softwareentwicklung ist zwischen dem Begriff der Komponente als statische Beschreibung eines Systembausteins, sowie dem Begriff des Komponentenexemplars zu unterscheiden. Im Gegensatz zur statischen Beschreibung, bezeichnet ein Komponentenexemplar einen Teil eines sich in der Ausführung befindlichen Systems, wobei das Komponentenexemplar einen Zustand besitzt und diesen gemäß der zugrunde liegenden Beschreibung ändert. Daher kann dieses auch als Akteur bezeichnet werden (siehe auch [KGT05]). Da sich der Unterschied zwischen Komponente und Komponentenexemplar aus dem Kontext ergibt, wird der Begriff Komponente in diesem Dokument für beides verwendet (vgl. [GT00]). Logisches Dienstexemplar Eine AXP-/ASG-C5-Verwaltungseinheit, die bei der Bearbeitung von Anfragen benötigt wird. Darüber hinaus ermöglicht sie die Zuordnung eines Zustands zu einem Dienstexemplar (nur AXP). Physisches Dienstexemplar Ein auf einem Anwendungsserver platzierter Dienst. Platzierung Das Platzieren eines Dienstes bezeichnet dessen Übertragung und Installation in einem verfügbaren AXP-Dienstcontainer. Im Zuge dieses Vorgangs wird dem Dienst eine URL zugewiesen, über den Klienten auf den Dienst zugreifen können. Ticket Repräsentiert die eindeutige Zuordnung eines Experiments und dessen Nutzung zu einem Nutzer. Zustandspersistierung Die Programmbibliothek, die den logischen Dienstexemplaren das Speichern bzw. Lesen von Zustandsvariablen in bzw. aus einer zentralen Datenbank ermöglicht. Zustandsvariable Von der AXP-Software verwaltete Dienste haben die Möglichkeit, bestimmte Werte zu persistieren. Dabei gibt es drei verschiedene Gültigkeitsbereiche für diese Daten: exemplarspezifische Zustandsvariablen sind genau einem logischen Dienstexemplar zugeordnet, auf eine dienstklassenspezifische Zustandsvariable haben jeweils alle logischen Dienstexemplare eines Dienstes Zugriff. Auf globale Zustandsvariablen können alle logischen Dienstexemplare zugreifen. DCL N AXP 7

8 Entwicklung einer transnationalen experimentbasierten Lernumgebung im Leonardo-Da-Vinci-Programm der Europäischen Union 8 DCL N AXP

9 2 EINLEITUNG 2 Einleitung Im Leonardo-Da-Vinci-Programm wird die grenzüberschreitende Zusammenarbeit in Europa zwischen den nationalen Bildungssystemen gefördert. Dabei sollen transnationale Netze für Fachwissen und Wissenstransfer aufgebaut werden. Im VET-TREND 2 - Projekt arbeiten Partner aus Rumänien, Italien, Portugal, Schweden und Deutschland an der Entwicklung einer verteilten Lern- und Experimentierumgebung. Das Fachgebiet Betriebssysteme und Middleware stellt dabei den Zugriff auf das Distributed Control (DCL) Lab bereit, das am Hasso-Plattner-Institut (HPI) betrieben wird. Das Distributed Control Lab ist eine verteilte Infrastruktur zur entfernten Ausführung von Echtzeitsteuerungsexperimenten über das Internet. Existierende Experimente umfassen das Foucault sche Pendel, die Lego-Mindstorms-Roboter und den Hau-den-Lukas. Die Experimente werden in Lehrveranstaltungen zur Programmierung eingebetteter Systeme genutzt. Abbildung 1: Übersicht über das DNA-Projekt Das HPI beteiligte sich ebenfalls am Adaptive-Services-Grid-Projekt (ASG) der Europäischen Union. Die aus diesem Projekt hervorgegangene ASG-C5-Komponente ermöglicht die ortsunabhängige Nutzung von dynamisch platzierten Diensten. Das DCL-Projekt und das ASG-Projekt beinhalten bereits Aspekte, die für die zu entwickelnde Lern- und Experimentierumgebung benötigt werden. Das Ziel des Projektes war es nun, diese Systeme zu kombinieren. Hierbei mussten Anpassungen vorgenommen werden, um die Interoperabilität zu gewährleisten sowie zusätzliche Anforderungen an das Gesamtsystem umzusetzen. Im Rahmen unseres Bachelorprojektes wurde eine verteilte dienstorientierte Infrastruktur zur entfernten Ausführung von Steuerungsexperimenten geschaffen. Die Adaptive Execution Platform (AXP) übernimmt dabei die Verwaltung von Dienstcontainern und die Platzierung von Diensten. Die Experimente sind AXP-Dienste, die in Dienstcontainern ausgeführt werden. Die 2 Valorisation of an Experiment-based Training System through a Transnational Educational Network Development DCL N AXP 9

10 Entwicklung einer transnationalen experimentbasierten Lernumgebung im Leonardo-Da-Vinci-Programm der Europäischen Union Verwaltung der AXP-Software und der Zugriff auf verschiedene Experimente ist dabei über verschiedene Benutzungsschnittstellen möglich. (Siehe dazu auch Abbildung 1.) Dieses System wird im Rahmen von Lehrveranstaltungen über eingebettete Systeme den Partnern aus Schweden (BTH), Portugal, Rumänien (Uni Brasov) und anderen zugänglich gemacht. Zur Umsetzung des Projekts waren folgende Aufgabenbereiche zu bearbeiten: Anpassung und Erweiterung der ASG-C5-Komponente Entwicklung einer Ausführungsumgebung für Experimente Portierung vorhandener Experimente sowie die Bereitstellung von Werkzeugen zur Vereinfachung der Entwicklung weiterer Experimente Entwicklung von Nutzungsschnittstellen zur Ausführung der Experimente Entwicklung einer Nutzungschnittstelle zur Verwaltung der Infrastruktur Die genannten Aufgaben werden in der Reihenfolge ihrer Nennung in den folgenden Abschnitten näher erläutert. 10 DCL N AXP

11 3 ANALYSE, ERWEITERUNG UND DOKUMENTATION EINER J2EE-BASIERENDEN INFRASTRUKTUR FÜR DIENSTORIENTIERTE ARCHITEKTUREN (ROBERT WIERSCHKE) 3 Analyse, Erweiterung und Dokumentation einer J2EE-basierenden Infrastruktur für dienstorientierte Architekturen (Robert Wierschke) Für die einleitend beschriebene Lernumgebung wurde ein System zur Verwaltung der Experimente benötigt. Die Aufgabenstellung sah vor, hierfür die ASG-C5-Komponente des Adaptive-Services-Grid-Projekts zu verwenden. Damit diese für die Verwaltung von DCL-Experimenten geeignet ist, sollte ein Mechanismus zum Scheduling der Anfragen integriert werden. Da die ASG-C5-Komponente bisher nur Java-Dienste verwalten konnte, musste diese erweitert werden, um auch für.net-dienste nutzbar zu sein. Es stellte sich jedoch heraus, dass eine Neuimplementierung der ASG-C5- Komponente die Integration in das Gesamtsystem vereinfachte. Die folgenden Abschnitte beschreiben die Neuimplementierung, sowie die hierbei eingebrachten Erweiterungen und Anpassungen. Abschließend soll die bereits im ASG-Projekt verwendete Realisierung eines Zustandskonzepts für Dienste mit der Realisierung von zustandsbehafteten Diensten in aktueller Java-Technologie verglichen werden. Außerdem werden Ansatzpunkte für weiterführende Arbeiten genannt. 3.1 Infrastruktur für dynamische Dienstausführung Ausgangssituation: ASG-C5 Adaptive Services Grid (ASG) ASG-C5 ist eine Komponente des Adaptive- Services-Grid-Projekt 3 der Europäischen Union. Ziel des Projektes war u. a. eine dynamische Komposition von Diensten basierend auf einer semantischen Beschreibung. Hierbei war es die Aufgabe der ASG-C5-Komponente Dienste dynamisch zu platzieren, sowie an die Dienste gerichtete Anfragen an verfügbare Dienstexemplare zu delegieren [TMMF07]. Im Folgenden soll dieser Vorgang kurz beschrieben werden. Die Nutzung eines ASG-C5-verwalteten Dienstes lässt sich in drei Phasen gliedern. Installation des Dienstes. Ein Dienst muss zunächst installiert werden. Dies erfolgt durch den Aufruf der deploy-methode des Dienstinstallationsakteurs (DeploymentService). Hierbei sind eine Dienstimplementierung, deren Format vom jeweiligen Dienstimplementierungstyp (siehe 4.1) abhängig ist, sowie dienstspezifische Parameter (siehe 5.1.4) zu übergeben. Bei der Installation des Dienstes wird diesem eine ID zugewiesen. Bildung eines Dienstexemplars. Um den installierten Dienst zu nutzen, muss zunächst ein Exemplar des Dienstes erzeugt werden. Dies erfolgt unter Verwendung der createserviceinstance-methode des Verwaltungsakteurs für logische Dienstexemplare (ServiceFactory). Hierbei muss u. a. die ID des zuvor installierten Dienstes angegeben werden. Die Angabe einer gültigen ID führt zur Bildung eines logischen Dienstexemplars. Ein logisches Dienstexemplar ist eine Entität, 3 DCL N AXP 11

12 Entwicklung einer transnationalen experimentbasierten Lernumgebung im Leonardo-Da-Vinci-Programm der Europäischen Union die zur Verwaltung der Anfragen an einen Dienst, sowie der Zuordnung eines Zustandes zu einem Dienstexemplar verwendet wird. Dem erzeugten logischen Dienstexemplar wird ebenfalls eine ID zugeordnet [TMMF07]. Das logische Exemplar wird für den Klienten durch eine Endpoint Reference (kurz EPR), welche die ID als Reference Parameter enthält, identifiziert [W3C07]. Die Endpoint Reference muss bei jedem Aufruf als SOAP-Header [W3C06] übertragen werden. Nutzung des Dienstexemplars. Durch die Verwendung der erzeugten Endpoint Reference werden Anfragen an einen Anfragenbearbeitungsakteur gesendet. Dieser ermittelt die ID des logischen Dienstexemplars aus der Endpoint Reference. Die Anfrage wird dann an ein verfügbares physisches Dienstexemplar delegiert oder, falls es sich um bestimmte Anfragen (siehe 3.2) handelt, intern verarbeitet. Hierbei wird dem (logischen) Dienstexemplar ein Zustand zugeordnet, welcher durch eine Programmbibliothek in eine zentrale Datenbank geschrieben bzw. aus dieser gelesen werden kann. Es ist somit möglich den Zustand ortsunabhängig zu rekonstruieren. Hierdurch können folgende Anfragen durch verschiedene physische Dienstexemplare bearbeitet werden Gründe für eine Neuimplementierung Nach einem ersten Prototyp auf ASG-C5-Basis erwies es sich als schwierig, die angestrebten Erweiterungen wie zum Beispiel prioritätenbasiertes Scheduling (siehe 3.4) zu integrieren. Als hinderlich erwies sich vor allem der Maven 4 -basierte Entwicklungsprozess, sowie die resultierenden Probleme beim Testen der Software auf dem verwendeten Anwendungsserver (hier: JBoss 5 ). Aufgrund mangelhafter IDE-Integration von Maven war ein effizientes Entwickeln nicht möglich. Insgesamt führten folgende Aspekte zur Entscheidung für eine Neuimplementierung: J2EE-Version. Die ASG-C5-Komponente basiert auf J2EE 1.4. Die aktuelle J2EE- Version 1.5 bietet wesentliche Verbesserungen hinsichtlich Java-Web-Services und vereinfachter Programmiermodelle (POJO). Das J2EE 1.4 nicht mehr ganz zeitgemäß ist, beweist die ASG-C5-Implementierung selbst. Hier wird teilweise Java 5 für die Implementierung verwendet. Axis. Im ASG-Projekt wird Axis für die Verarbeitung von SOAP-Nachrichten verwendet. Axis bietet keine Unterstützung für das verwendete WS-Addressing- Protokoll. Insbesondere werden an vielen Stellen, auch auf der Seite des Klienten, SOAP-Nachrichten manuell bearbeitet. Ferner ist Axis nicht Bestandteil von J2EE oder J2SE. Maven. Wie bereits oben beschrieben, erschwert Maven die Entwicklung durch mangelnde IDE-Integration. Insbesondere ist es nicht möglich, den entwickelten Quelltext aus der IDE heraus in das entsprechende Ausführungsformat (z. B. ear- Dateien) zu bringen und diese im Debug-Modus auf dem Server auszuführen DCL N AXP

13 3 ANALYSE, ERWEITERUNG UND DOKUMENTATION EINER J2EE-BASIERENDEN INFRASTRUKTUR FÜR DIENSTORIENTIERTE ARCHITEKTUREN (ROBERT WIERSCHKE) Die als Adaptive Execution Platform (kurz AXP) bezeichnete Neuimplementierung der ASG-C5-Komponente basiert auf JAX-WS und wurde vollständig in Java 6 entwickelt. Die JAX-WS Referenzimplementierung ermöglicht die Implementierung von state of the art Web Services für Java-Plattformen [KG07]. Durch das POJO- Programmiermodell vereinfacht sich die Entwicklung der Dienste. In der aktuellen Version 2.1 erleichtert JAX-WS die Nutzung von WS-Addressing sowie die Verarbeitung von SOAP im Allgemeinen durch entsprechende Programmierschnittstellen. Eine wesentliche Neuerung ist die Möglichkeit die Dienste ohne einen komplexen Anwendungsserver anzubieten. Darüber hinaus ist das AXP-System flexibler und erlaubt nun die Integration von Dienstcontainern in anderen Programmiersprachen, wodurch auch Dienste in den jeweiligen Sprachen verwaltet werden können. Damit die AXP-Software ausgeführt werden kann, wird eine Java-Umgebung mit JAX-WS benötigt. Die in J2SE enthaltene Version 2.0 ist hierfür nicht ausreichend. Eine Aktualisierung auf die benötigte Version 2.1 muss über den Endorsed 8 -Mechanismus durchgeführt werden. Es ist jedoch wahrscheinlich, dass in Zukunft aktuelle Versionen von JAX-WS in J2SE integriert werden. Somit benötigt das AXP-System keinen Anwendungsserver, sondern kann in jeder aktuellen J2SE-Umgebung betrieben werden. Zusammenfassend bietet die Neuimplementierung folgende Vorteile: Keine manuelle Bearbeitung von SOAP-Nachrichten Direkte Unterstützung von WS-Addressing Kein Anwendungsserver benötigt POJO-Programmiermodell Vereinfachter Entwicklungsprozess Kompatibel zu.net-diensten Erweiterbar durch Dienstcontainer in anderen Programmiersprachen Erweiterung der Architektur Die Architektur der ASG-C5-Komponente sowie verwendete Konzepte und Arbeitsweisen wurden bei der Neuimplementierung weitgehend übernommen. Jedoch wurde die Architektur im Rahmen des Projekts um einige Komponenten erweitert bzw. wurden Komponenten wesentlich verändert. Scheduler Zur Steuerung der Experimente musste ein Scheduling-Mechanismus integriert werden. Die hierbei betrachteten Probleme und die realisierte Lösung wird in Abschnitt 3.4 dargelegt. 7 https://jax-ws.dev.java.net/ 8 DCL N AXP 13

14 Entwicklung einer transnationalen experimentbasierten Lernumgebung im Leonardo-Da-Vinci-Programm der Europäischen Union WSDL-Generator Im Zuge der Erweiterung der Dienste um einen Zustand werden der Schnittstelle des Dienstes weitere Methoden hinzugefügt. Damit für deren Nutzung keine manuelle Bearbeitung von SOAP-Nachrichten nötig ist, müssen diese Methoden in der WSDL des Dienstes definiert werden. Hierdurch werden, durch die verwendeten Werkzeuge, in den Proxies entsprechende Methoden generiert. Der WSDL- Generator stellt eine wesentliche Verbesserung dar und wird deshalb in Abschnitt 3.2 näher erläutert. Execution Host Registration Um den Verwaltungsaufwand bei der Anbindung neuer Dienstcontainer (siehe 4.1) zu verringern, wurde eine neuer Dienst eingeführt. Bei diesem können sich Dienstcontainer bei ihrem Start registrieren sowie beim Beenden abmelden. Eine Registrierung kann ferner auch durch den AXP-Administrator über die Verwaltungsbenutzungsschnittstelle (siehe 7) vorgenommen werden. WSRF-Dienste Zur Bearbeitung der Web-Service-Resource-Framework-Anfragen wurden ein Dienst für Web Service Resource Properties sowie ein Dienst für Web Service Resource Lifetime hinzugefügt. Die beiden Dienste implementieren die in 3.2 beschriebenen Methoden. Verwaltung physischer Dienstexemplare Physische Dienstexemplare sind Dienste, die in einem Dienstcontainer ausgeführt werden und zur Bearbeitung von Anfragen verwendet werden. Ein Ziel des AXP-Projekts ist es, die Anfragen und dazu auch die physischen Dienstexemplare möglichst effizient auf alle verfügbaren Dienstcontainer zu verteilen. Auf der Basis ausgewählter Messdaten muss hierzu zunächst ein Dienstcontainer ausgewählt werden. Anschließend wird ein Dienst in diesem platziert. Ferner müssen Dienste, falls sie ausfallen, neu platziert werden. Dies wird durch die neu eingeführte Komponente, den Verwalter für physische Dienstexemplare, übernommen. Da das Sammeln der Messdaten von den Dienstcontainern noch nicht funktioniert, wird hier zurzeit ein Dienstcontainer per Zufallsprinzip gewählt. Anfragenbearbeitung Der hierfür zuständige Anfragenbearbeitungsakteur (ServiceInvocationService) nimmt alle Anfragen an logische Dienstexemplare entgegen und leitet diese entweder an entsprechende physische Dienstexemplare weiter oder delegiert die Anfrage an interne Komponenten, falls es sich um WSRF- Anfragen handelt. In der ASG-C5-Komponente wurden hierzu die SOAP-Nachrichten manuell bearbeitet. Da dies in der Neuimplementierung vermieden werden sollte, musste die Anfragenbearbeitungskomponente überarbeitet werden. Außerdem musste in den Prozess des Aufrufs des physischen Dienstexemplars der Scheduler integriert werden. Alle übrigen ASG-C5-Komponenten wurden zwar ebenfalls vollständig neu implementiert, wurden jedoch in ihrer Funktionsweise nicht wesentlich verändert. Insgesamt ergibt sich die in Abbildung 2 dargestellte Architektur. 14 DCL N AXP

15 3 ANALYSE, ERWEITERUNG UND DOKUMENTATION EINER J2EE-BASIERENDEN INFRASTRUKTUR FÜR DIENSTORIENTIERTE ARCHITEKTUREN (ROBERT WIERSCHKE) Abbildung 2: AXP-Architektur 3.2 Erweiterung der Dienstschnittstelle In der AXP werden die verwalteten Dienste um ein Zustandskonzept erweitert (siehe auch 3.3.1). Im Rahmen dieser Erweiterung bietet der Anfragenbearbeitungsakteur die Möglichkeit Resource Properties [OAS06b] abzufragen, sowie zusätzliche Methoden zur Verwaltung der Lebenszeit des erzeugten logischen Dienstexemplars aufzurufen. Hierfür sind die entsprechenden OASIS Standards 9 des Web Service Resource Frameworks implementiert. Die entsprechenden Implementierungen sind jedoch nicht in vollem Spezifikationsumfang realisiert WSRF-Methoden Insgesamt wird die Dienstschnittstelle um die folgenden drei Methoden erweitert: GetResourceProperty. Diese Methode ermöglicht die Abfrage von Zustandsdaten des logischen Dienstexemplars. Hierzu gehören eine Anzahl wohldefinierter Zustandsdaten, welche durch AXP-Akteure verwaltet werden, wie zum Beispiel der Zustand des logischen Dienstexemplars selbst (siehe 3.3.1) oder die Bearbeitungszeit einer Dienstanfrage durch das physische Dienstexemplar. Ferner können auch beliebige Eigenschaften abgefragt werden, die durch den Dienst während der Anfragebearbeitung geschrieben werden. Destroy. Ein Aufruf dieser Methode führt zur sofortigen Zerstörung des logischen Dienstexemplars, wobei auch alle Zustandsdaten aus der Datenbank entfernt 9 DCL N AXP 15

16 Entwicklung einer transnationalen experimentbasierten Lernumgebung im Leonardo-Da-Vinci-Programm der Europäischen Union werden. Nach dem Aufruf dieser Methode sind weitere Anfragen an das assoziierte logische Dienstexemplar nicht mehr zulässig bzw. der Klient darf nicht mehr von der Verfügbarkeit des Dienstexemplars und der zugehörigen Zustandsdaten ausgehen [OAS06a]. SetTerminationTime. Aufgrund von Verbindungsstörungen zwischen Klienten und AXP-Akteuren ist eine direkte Zerstörung des logischen Dienstexemplars nicht immer möglich. Daher wird das logische Dienstexemplar automatisch nach dem Ablauf einer Lebenszeit beseitigt. Zur Steuerung dieser Lebenszeit bietet der Web-Service-Resource-Lifetime-Standard die Methode SetTerminationTime. Mit Hilfe dieser Methode kann die Lebenszeit des logischen Dienstexemplars sowohl durch eine Zeitspanne als auch durch ein absolutes Enddatum festgelegt werden. Eine Abfrage der aktuellen Lebenszeit ist gemäß der Spezifikation [OAS06a] durch die oben genannte GetResourceProperty-Methode möglich Nutzung der zusätzlichen Methoden Die Nutzung der oben genannten Methoden erfolgt, wie in den entsprechenden Standards definiert, durch SOAP-Nachrichten. Da der Entwickler eines Dienstes diese Methoden nicht kennt, werden sie nicht von ihm oder von verwendeten Generator- Werkzeugen in der Schnittstelle des Dienstes aufgeführt. Somit wird auch keine Methode im generierten Proxy auf der Seite des Klienten erzeugt. Daher erfolgte die Nutzung durch den Klienten über manuell erstellte SOAP-Nachrichten, welche durch den Anfragenbearbeitungsakteur ebenfalls manuell bearbeitet werden mussten. Dies ist mühselig, fehleranfällig und nicht ganz einfach. Um das manuelle Bearbeiten von SOAP-Nachrichten zu vermeiden, wurde die Infrastruktur im Zuge der Neuimplementierung um eine Komponente, den WSDL- Generator, erweitert. Durch den WSDL-Generator wird eine neue WSDL aus der WSDL des verwalteten Dienstes sowie den nötigen Elementen der obigen drei Methoden erzeugt. Für das Erstellen des neuen WSDL-Dokuments wurden folgende Technologien in Betracht gezogen: XSLT. XSLT ermöglicht die Transformation von XML in andere Notationen (auch XML selbst). Da jedoch der Großteil der Dienst-WSDL bei der Generierung der AXP- Dienst-WSDL erhalten bleibt, erwies sich XSLT nach einigen Tests als ungeeignet. Spezielle APIs. Es existieren Bibliotheken für die Bearbeitung von WSDL- Dokumenten, zum Beispiel JSR Jedoch sollte für eine möglichst einfache Installation auf zusätzliche Bibliotheken verzichtet werden. Herkömmliche XML Parser-Technologien. Eine weitere Möglichkeit wäre die Verwendung einer der üblichen XML-APIs wie SAX, DOM, StAX. SAX und StAX sind weniger geeignet, da beide auf einer Iteration über das XML-Dokument beruhen, DCL N AXP

17 3 ANALYSE, ERWEITERUNG UND DOKUMENTATION EINER J2EE-BASIERENDEN INFRASTRUKTUR FÜR DIENSTORIENTIERTE ARCHITEKTUREN (ROBERT WIERSCHKE) wodurch ein Einfügen von Elementen an bestimmten Positionen in einem existierenden Dokument eher umständlich erscheint. DOM ist prinzipiell gut für die Modifikation von bestehenden XML-Inhalten geeignet, da hier eine speicherinterne Abbildung des XML-Inhalts erstellt wird. Durch die Angabe der qualifizierten Namen der XML-Elemente kann in dieser speicherinternen Repräsentation auf beliebige Elemente zugegriffen werden. Jedoch abstrahiert DOM vollständig von der WSDL-Semantik. JAXB. Ähnlich DOM ermöglicht JAXB 11 das Erstellen einer speicherinternen Repräsentation des XML-Inhalts [KVF06]. Im Gegensatz zu DOM besteht diese jedoch nicht aus allgemeinen Elementen, sondern aus spezifischen Klassen, welche durch Annotationen auf die Struktur des XML-Dokuments abgebildet werden. Diese Klassen lassen sich aus einer entsprechenden XML-Schema-Datei erzeugen. JAXB verwendet an einigen Stellen DOM, so wird zum Beispiel der XML-Schema-Datentyp any auf ein DOM-Element abgebildet. Die Datenstruktur kann nach ihrer Bearbeitung wieder in XML transformiert werden. Somit bietet JAXB die Möglichkeit existierende XML-Dokumente zu modifizieren und erhält dabei die Semantik des entsprechenden XML-Schemas. Daher wurde JAXB für die Implementierung des WSDL-Generators verwendet. Das Generieren der AXP-Dienst-WSDL geschieht im Rahmen des Dienstinstallationsvorgangs. Die generierte WSDL wird in der Datenbank gespeichert und kann später vom Klienten abgefragt werden. Da das Installieren von Diensten im Vergleich zu ihrer Nutzung relativ selten ausgeführt wird, beeinflusst der zeitliche Aufwand des Vorgangs nicht die Nutzung der Dienste. Arbeitsweise des WSDL-Generators Zunächst muss die ursprüngliche WSDL des Dienstes aus der Dienstimplementierung extrahiert werden. Dies geschieht mit Hilfe des entsprechenden Informationsdienstes (siehe 4.1.1). In die extrahierte WSDL müssen nun folgende Elemente eingefügt werden. Abstrakte Bestandteile der WSRF-Methoden Binding für WSRF-Methoden [W3C01] UsingAddressing-Element [W3C07] Explizite WS-Addressing-Action-Attribute [W3C07] für WSRF-Methoden Resource Property Document [OAS06b] Verweis auf Resource Property Document in porttype-element der WSDL. [OAS06b] 11 https://jaxb.dev.java.net/ DCL N AXP 17

18 Entwicklung einer transnationalen experimentbasierten Lernumgebung im Leonardo-Da-Vinci-Programm der Europäischen Union Zur Einbindung der abstrakten WSRF-Definitionen (schema-, message- und port- Type-Elemente) werden zwei import-elemente eingefügt. Das binding für diese Elemente musste zunächst erstellt werden. Da das AXP-System auf Basis des SOAP1.1- Protokolls über HTTP-Transport operiert, wurden entsprechende bindings für WSRLund WSRP-portTypen definiert. Die methodenspezifischen Bestandteile des porttypesowie binding-elements werden dann den entsprechenden Elementen in der Dienst- WSDL hinzugefügt [W3C01]. Hierdurch erscheinen die WSRF-Operationen als Methoden des Dienstes. Die AXP verwendet WS-Addressing [W3C07], um eine Dienstanfrage einem logischen Dienstexemplar zuzuordnen, sowie bestimmte Anfragen (u. a. die genannten drei Methoden) gesondert zu bearbeiten (siehe auch 3.3). Um die Verwendung von WS-Addressing in der WSDL zu deklarieren, muss das in Listing 1 gezeigte Element dem binding des Dienstes hinzugefügt werden. Listing 1: UsingAddressing-Element 1 <wsaw:usingaddressing wsdl:required="true" 2 xmlns:wsaw="http://www.w3c.org/2006/addressing/wsdl" 3 xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" /> Entsprechend der WSRP-Spezifikation ist ein Resource Property Document anzulegen und dem Schema der Dienst-WSDL hinzuzufügen. Ein Resource Property Document ist ein XML-Element, welches alle Resource Properties mit Namen und Typ auflistet. Listing 2: Beispiel Resource Property Document eines AXP-Dienstes 1 <xsd:element name="axpserviceproperties"> 2 <xsd:complextype> 3 <xsd:sequence> 4 <xsd:element name="state" type="xsd:string" /> 5 <xsd:element name="executiontime" type="xsd:long" /> </xsd:sequence> 8 </xsd:complextype> 9 </xsd:element> Das Resource Property Document muss im porttype des Dienstes über ein extension-attribut [W3C01] [W3C07] referenziert werden. Listing 3: Beispiel der Resource-Property-Document-Referenzierung 1 <wsdl:porttype name="exampleaxpserviceport" 2 wsrf-rp:resourceproperties="axpserviceproperties" > </wsdl:porttype> Damit der Anfragenbearbeitungsakteur die eingefügten Methoden erkennen und entsprechend gesondert behandeln kann, muss bei deren Aufruf ein entsprechender WS-Addressing-Action-Header [W3C06] verwendet werden. Die implizite WSA-Action setzt sich u. a. aus dem Namen des porttype, in dem die Operation definiert ist, sowie dem Namen der Operation selbst zusammen. Da die Operation in einen anderen porttype eingefügt wurde, stimmt die Action nicht mehr mit der Spezifikation überein. Um dies zu beheben, muss der Wert explizit, ebenfalls durch ein extension-attribut, angegeben werden. 18 DCL N AXP

19 3 ANALYSE, ERWEITERUNG UND DOKUMENTATION EINER J2EE-BASIERENDEN INFRASTRUKTUR FÜR DIENSTORIENTIERTE ARCHITEKTUREN (ROBERT WIERSCHKE) Leider stellte sich heraus, dass der hierfür benötigte Umgang mit dem XML- Schema-Datentyp anyattribute in JAXB fehlerhaft 12 ist. Da die ersten drei Punkte jedoch für eine korrekte Funktionsweise ausreichend sind, wurden die letzten drei nicht implementiert. Der Fehler wurde gegen Ende des Projekts durch einen der JAXB Entwickler behoben. Dies konnte jedoch nicht mehr berücksichtigt werden. Die erzeugte WSDL wird beim Aufruf der createserviceinstance-methode als Metadaten 13 in die EPR eingefügt, sofern dies vom Klienten durch den entsprechenden Parameter gefordert wurde. 3.3 Bearbeitung von AXP-Dienstanfragen Die Bearbeitung von Anfragen an ein logisches Dienstexemplar wird durch den Anfragenbearbeitungakteur vorgenommen. Aufgrund der Einbindung des Schedulers (siehe 3.4) sowie der Umstellung auf JAX-WS wurde diese jedoch stark verändert Zustandsmodell für logische Dienstexemplare Die Nutzung eines AXP-verwalteten Dienstes erfolgt über ein zustandsbehaftetes logisches Dienstexemplar. Der Zustand des logischen Exemplars setzt sich durch bestimmte AXP-verwaltete sowie dienstspezifischen Variablen zusammen. Folgende Variablen werden durch AXP-Akteure verwaltet und stehen jedem Dienst zur Verfügung. State. Eine Zeichenkette, die den Zustand des logischen Dienstexemplars angibt. Analog zu den in Abbildung 3 gezeigten Zuständen sind die folgenden Werte möglich: ready, failed, finished, queued, execution, canceled ExecutionTime. Die Dauer der letzten Anfragebearbeitung durch ein physisches Dienstexemplar in Millisekunden. Der Wert darf nur im Zustand finished abgefragt werden. QueuePosition. Die Position der aktuell zu bearbeitenden Anfrage in der Warteschlange des Dienstes. Der Wert darf nur im Zustand queued abgefragt werden. Priority. Die dem logischen Dienstexemplar zugeordnete Priorität. ServiceInfo. Einige Informationen über den genutzten Dienst. TerminationTime. Die aktuelle Lebenszeit des logischen Dienstexemplars als Zeichenkette im GMT-Format. CurrentTime. Die aktuelle Zeit. Dies ist nötig, um fehlende Synchronisationsmechanismen zu kompensieren [OAS06a]. 12 Der Fehler wurde gemeldet. Issue Hierbei wurde ein Fehler entdeckt und gemeldet. Issue 333. Der Fehler wurde inzwischen behoben. DCL N AXP 19

20 Entwicklung einer transnationalen experimentbasierten Lernumgebung im Leonardo-Da-Vinci-Programm der Europäischen Union Abbildung 3: Zustandsmodell eines logischen Dienstexemplars Darüber hinaus ist die Abfrage dienstspezifischer Zustandsdaten möglich. Die Abfrage aller Zustandsdaten erfolgt mit Hilfe der GetResourceProperty-Methode durch Angabe des Variablennamens als qualifizierter Name [OAS06b]. Hierbei ist eine leere Zeichenkette als Namensraum zu verwenden. Das Zustandsmodell eines logischen Dienstexemplars wird in Abbildung 3 veranschaulicht. Wie in der Abbildung gezeigt, sind dienstspezifische Anfragen nur im Zustand verfügbar möglich. Dies bedeutet, dass zu einem bestimmten Zeitpunkt nur eine Anfrage je logisches Dienstexemplar bearbeitet werden kann Anfragenannahme und -weiterleitung Die Anfragenbearbeitungskomponente ist als AsyncProvider-Dienst implementiert. JAX-WS-Provider-Dienste implementieren keine dienstspezifische Schnittstelle, sondern arbeiten direkt auf der Nachricht (z. B. SOAP). Der Deserialisierungsprozess wird hierbei umgangen. Die AsyncProvider-Schnittstelle ermöglicht zudem eine asynchrone Ergebnisrückgabe (siehe auch Listing 4). Wie in 3.4 dargelegt, werden hierdurch die beim Scheduling auftretenden Probleme gelöst. Bei der Implementierung der Anfragenbearbeitungskomponente wurde ein Problem mit dem in JAX-WS integrierten HTTP-Server festgestellt. Hier wurden die Anfragen in einem Thread aus einem Threadpool bearbeitet. Die Größe des Threadpools war auf 5 festgelegt, wodurch nur fünf Anfragen gleichzeitig angenommen wurden. Der Fehler wurde gemeldet 14 und 14 Issue DCL N AXP

21 3 ANALYSE, ERWEITERUNG UND DOKUMENTATION EINER J2EE-BASIERENDEN INFRASTRUKTUR FÜR DIENSTORIENTIERTE ARCHITEKTUREN (ROBERT WIERSCHKE) inzwischen behoben. Nun wird ein Threadpool mit dynamischer Größe verwendet WS-Action-basiertes Routing Für eine eingehende Dienstanfrage wird vom Anfragenbearbeitungsakteur eine Art Routing auf Basis des in der empfangenen EPR enthaltenden WS-Addressing-Action- Elements [W3C07] vorgenommen. Der Zugriff auf dieses Element sowie auf die benötigte ID des logischen Dienstexemplars ist in JAX-WS ohne manuelles parsen der SOAP-Nachricht möglich. Jedoch muss hier berücksichtigt werden, dass Web Service Enhancements 3.0 [Fus05] eine ältere WS-Addressing-Version benutzt. Dies hat zur Folge, dass das benötigte Action-Element in einem anderen Namensraum definiert ist. Um dennoch die Nutzbarkeit für.net-klienten zu gewährleisten, werden hier die folgenden Namensräume unterstützt: Hierbei ist der erstgenannte Namensraum zu bevorzugen. Aufgrund der in genannten Schwierigkeiten wird die Routing-Entscheidung lediglich auf Basis des Methodennamens getroffen. Durch das vorgenommene Routing ist es ferner möglich bestimmte Anfragen, wie z. B. WSRF-Anfragen am Scheduler vorbei zu führen und sofort zu bearbeiten. Insgesamt wird zwischen folgenden Weiterleitungsmöglichkeiten gewählt. WSRL-Anfragen gem. [OAS06a]. WSRP-Anfragen gem. [OAS06b]. CancelRequest Scheduling In den ersten beiden Fällen wird ein entsprechender Dienst aufgerufen. Hierdurch wird die Komplexität der verwendeten Übertragungsprotokolle, wie SOAP und WS- Addressing, vollständig in die JAX-WS-Implementierung verlagert. Im Fall eines CancelRequests wird geprüft, ob die zuvor an das logische Dienstexemplar gerichtete Anfrage bereits ausgeführt wird. Der Aufruf wird dementsprechend entweder an das zuständige physische Dienstexemplar delegiert oder die Anfrage wird aus dem Scheduler entfernt. In allen anderen Fällen wird der Aufruf an den, für das jeweilige logische Dienstexemplar zuständigen, Scheduler delegiert. 3.4 Prioritätenbasiertes Scheduling von Dienstanfragen Eine der wesentlichen Erweiterungen im Zuge der Neuimplementierung ist das Scheduling der Anfragen an einen AXP-verwalteten Dienst. Obwohl der Einsatz in anderen Szenarien denkbar ist, besteht die primäre Aufgabe des Schedulings in der Verwaltung der Experimenthardware der gesteuerten DCL-Experimente. Hierbei ergibt sich die Notwendigkeit des Schedulings aus den Experimenten selbst. DCL N AXP 21

22 Entwicklung einer transnationalen experimentbasierten Lernumgebung im Leonardo-Da-Vinci-Programm der Europäischen Union Hardwareressourcen. Bei den meisten Experimenten wird ein Steuerungsalgorithmus auf einer entsprechenden Hardware ausgeführt (z. B. Lego-Roboter). Die Anzahl der entsprechenden Hardwareressourcen ist natürlich begrenzt und es können nicht gleichzeitig verschiedene Experimente mit demselben Gerät durchgeführt werden. Dementsprechend müssen die Experimente nacheinander (serialisiert) auf dem Gerät ausgeführt werden. Ferner benötigen einige Geräte nach einer Experimentausführung eine gewisse Zeit, bis sie wieder zur Verfügung stehen. Beispielsweise muss der Lego-Roboter wieder in seine Ausgangsposition gefahren werden. Entsprechend muss der Scheduler dafür Sorge tragen, dass zwischen zwei aufeinanderfolgenden Experimentausführungen eine experimentspezifische Wartezeit eingehalten wird. Experimentlaufzeiten. Experimentausführungen sind potenziell sehr langläufig (z. B. Foucault sches Pendel). Daher ist es in bestimmten Situationen wünschenswert die Experimente bestimmter Nutzer bevorzugt auszuführen. Beim Scheduling der Dienstanfragen sind daher Prioritäten zu berücksichtigen Konfiguration des Schedulings Die Konfiguration des Schedulings erfolgt für jeden Dienst während der Installation des Dienstes durch Angabe entsprechender Parameter (siehe auch 5.1.4). Anzugeben sind hier ein Modus für das Scheduling (SchedulingMode), sowie die genannte Verzögerungszeit (ExecutionDelay) zwischen aufeinanderfolgenden Dienstaufrufen. SchedulingMode. Dieser Parameter definiert das Scheduling-Verfahren, nach dem alle eingehenden Dienstanfragen für einen Dienst ausgeführt werden. Das Scheduling findet hierbei je Dienst statt, wobei Dienstanfragen auf dem nächsten verfügbaren physischen Dienstexemplar ausgeführt werden. Derzeit werden folgende Modi unterstützt: serialized. Alle Anfragen werden nacheinander auf einem verfügbarem physischen Dienstexemplar ausgeführt. Dabei wird zwischen aufeinanderfolgenden Aufrufen eine entsprechende Wartezeit eingehalten. Die Anfragen können parallel auf verschiedenen physischen Dienstexemplaren ausgeführt werden. none. Alle Anfragen werden direkt an ein physisches Dienstexemplar weitergeleitet. Die Anfragen werden hierbei gleichmäßig auf alle verfügbaren physischen Dienstexemplare verteilt. Die genannte dienstspezifische Wartezeit wird hier ignoriert. Für die verfügbaren Modi ist ein Aufzählungsdatentyp in der WSDL der Dienstinstallationskomponente definiert. ExecutionDelay. Dieser Parameter gibt den Zeitraum in Sekunden an, in dem die Experimenthardware nach einer Experimentausführung nicht benutzt wird. 22 DCL N AXP

23 3 ANALYSE, ERWEITERUNG UND DOKUMENTATION EINER J2EE-BASIERENDEN INFRASTRUKTUR FÜR DIENSTORIENTIERTE ARCHITEKTUREN (ROBERT WIERSCHKE) Probleme Beim prioritätenbasierten Scheduling von Dienstanfragen ergeben sich zwei grundlegende Probleme. Ermitteln der jeweiligen Priorität Antwort an den richtigen Klienten senden Die Priorität eines logischen Dienstexemplars wird bei dessen Bildung festgelegt. Diese Priorität wird dann aus der ID ermittelt, welche bei jedem Aufruf als WS- Addressing Reference Parameter [W3C06] zu übertragen ist. Die Schwierigkeit besteht in der Zugriffsmöglichkeit auf die genannte ID. Greift man auf diese auf SOAP-Ebene zu, so hat der Deserialisierungsprozess meist schon begonnen und es folgt üblicherweise der Aufruf einer entsprechenden Methode mit den deserialisierten Parametern. Eine Änderung der Bearbeitungsreihenfolge ist hier nicht mehr möglich, da sonst die Rückgabewerte an die falschen Klienten zurückgegeben werden. Hierbei ist zu beachten 15, dass auch beim Rückgabetyp void eine entsprechende Antwortnachricht zurückzusenden ist Lösungsansätze Eine Lösung bestand darin, die Prioritäten auf unterschiedliche URLs/Endpunkte abzubilden. Somit gibt es für einen Dienst p verschiedene URLs, wobei p die Anzahl der Prioritäten darstellt. Hierdurch wäre dem Endpunkt die Priorität implizit bekannt. JAX-WS bietet die Möglichkeit, die Abarbeitung von an einen Endpunkt gerichteten Anfragen durch ein Exemplar vom Typ java.util.concurrent.executor zu beeinflussen. Der eingerichtete Executor ermöglicht die Zuordnung von HTTP-Anfragen auf Threads, in denen diese bearbeitet werden. Da dies vor dem Deserialisierungsprozess geschieht, wird hierdurch das Problem der Rückgabe auf Kosten einer sehr komplexen Architektur gelöst. Eine weitere und aktuell verwendete Lösung bietet die Nutzung des in JAX-WS zur Verfügung stehenden AsyncProvider-Dienstes. Listing 4: AsyncProvider-Schnittstelle im Service Invocation Service 2 servicename="serviceinvocationservice", 3 portname="serviceinvocationserviceport") = "http://schemas.xmlsoap.org/wsdl/soap/http") = javax.xml.ws.service.mode.message) 6 public class ServiceInvocation implements AsyncProvider<SOAPMessage> { 7 //... 8 public void invoke(soapmessage request, 9 AsyncProviderCallback<SOAPMessage> callback, 10 WebServiceContext wscontext) { 11 // validate logical instance ID mit Ausnahme von oneway-nachrichten DCL N AXP 23

24 Entwicklung einer transnationalen experimentbasierten Lernumgebung im Leonardo-Da-Vinci-Programm der Europäischen Union 13 // process AXP service request 14 } 15 // } Der Provider-Dienst arbeitet auf SOAP-Ebene und bietet somit einfachen Zugriff auf die benötigte ID. Der Zugriff auf die ID wird sogar noch durch WS-Addressingspezifische Methoden in der WebServiceContext-Schnittstelle vereinfacht. Darüber hinaus bietet der AsyncProvider ein AsyncProviderCallback<T>-Objekt, mit dem man zu beliebigem Zeitpunkt eine Antwort-SOAP-Nachricht an den Klienten senden kann. Somit werden beide genannten Probleme mit geringem Aufwand gelöst. 3.5 Verwandte Arbeiten: Zustandsbehaftete Dienste in JAX-WS Die AXP erweitert die verwalteten Dienste um ein Zustandskonzept. Wie bereits erläutert, ist hierzu explizit ein logisches Dienstexemplar zu erzeugen, welches bei jedem Aufruf durch eine EPR zu adressieren ist. Hierbei wird das Exemplar durch einen Referenzparameter in der EPR identifiziert. JAX-WS [KG07] bietet selbst ein Konzept für zustandsbehaftete Dienste. Bei einem Vergleich zeigte sich, dass bereits im ASG-Projekt zur Realisierung des Zustandskonzepts ähnlich vorgegangen wurde. Ein zustandsbehaftetes Dienstexemplar muss im JAX-WS-Konzept ebenfalls durch einen zweiten Dienst explizit gebildet werden. Hierbei wird ein Exemplar der Klasse StatefulWebServiceManager verwendet. Auch hier wird das erzeugte Exemplar durch eine EPR adressiert. Wie die in Listing 5 gezeigte EPR eines JAX-WS zustandsbehafteten Dienstes beweist, wird auch hier das Exemplar durch einen Referenzparameter identifiziert. Eine EPR eines AXP-Dienstes hat eine analoge Struktur und unterscheidet sich im Wesentlichen nur durch den Namen des Referenzparameters. Listing 5: EPR eines zustandsbehafteten Dienstes in JAX-WS 1 <EndpointReference xmlns="http://www.w3.org/2005/08/addressing"> 2 <Address>http://localhost:8080/jaxws-stateful/book</Address> 3 <ReferenceParameters><jaxws:objectId 4 xmlns:jaxws="http://jax-ws.dev.java.net/xml/ns/" 5 xmlns:ns2="http://server.stateful/" 6 xmlns:ns3="http://www.w3.org/2005/08/addressing" 7 xmlns:wsa="http://www.w3.org/2005/08/addressing"> 8 de d70-4cf3-84f8-bbe b0 9 </jaxws:objectid> 10 </ReferenceParameters> 11 </EndpointReference> Bei einem eingehenden Aufruf wird das entsprechende Exemplar durch einen sogenannten InstanceResolver ermittelt und die entsprechende Methode an diesem Exemplar aufgerufen. Obwohl es möglich ist einen eigenen InstanceResolver zu implementieren, stellt diese Möglichkeit keine Alternative zur derzeitigen AXP-Implementierung dar, da die Verteilung der Anfragenbearbeitung auf mehrere Dienstcontainer sowie die Unterstützung anderer Programmiersprachen hierdurch schwer zu realisieren ist. Even- 24 DCL N AXP

25 3 ANALYSE, ERWEITERUNG UND DOKUMENTATION EINER J2EE-BASIERENDEN INFRASTRUKTUR FÜR DIENSTORIENTIERTE ARCHITEKTUREN (ROBERT WIERSCHKE) tuell könnte jedoch die Nutzung von JAX-WS zustandsbehafteten Diensten die Implementierung der Anfragenbearbeitungskomponente vereinfachen, da hierdurch die Ermittlung des zuständigen Schedulers durch JAX-WS bzw. einen entsprechenden InstanceResolver erfolgen würde. 3.6 Ausblick Im Rahmen des Projekts wurde die ASG-C5-Komponente vollständig neu implementiert. Hierbei wurde die Neuimplementierung (AXP) um ein System zum Scheduling eingehender Anfragen erweitert, welches zur Steuerung der DCL-Experimente benötigt wird. Ebenso wurde der Anfragenbearbeitungsmechanismus überarbeitet und an die Anforderungen angepasst. Insbesondere wurde hierbei die Kompatibilität zu.net-diensten berücksichtigt. Darüber hinaus wurde eine Komponente (WSDL- Generator) geschaffen, welche die WSDL eines Dienstes um Methoden zur Verwaltung des Zustandes eines logischen Dienstexemplars erweitert. Durch die Verwendung von JAX-WS und JAXB sowie dem WSDL-Generator konnte die manuelle Bearbeitung von SOAP-Nachrichten vermieden werden. Dies stellt eine Verbesserung der Wartbarkeit sowie eine Erleichterung der Nutzbarkeit für Klienten dar. Bei der Neuimplementierung wurde außerdem die Erweiterbarkeit des Systems berücksichtigt. Daher ist es jetzt möglich, Dienstcontainer für andere Programmiersprachen zu integrieren. Während der Arbeit wurden mehrere Fehler in den verwendeten JAX-WS- und JAXB- Implementierungen gefunden und gemeldet. Die meisten der Fehler wurden hiernach durch die verantwortlichen Entwickler behoben. Darüber hinaus konnten die im Laufe des Projekts gewonnenen Erfahrungen in die JAX-WS/JAXB-Community eingebracht werden. Hierdurch konnte u. a. die JAX-WS-Dokumentation verbessert und in einer Forumsdiskussion ein Mangel der JAX-WS-Spezifikation bzgl. des Umgangs mit EPRs festgestellt werden. Da JAX-WS und JAXB Bestandteile von J2SE 16 sind, wurde hiermit ein Beitrag zur Verbesserung der Java-Plattform geleistet. Natürlich bestehen weitere Möglichkeiten zur Erweiterung und Verbesserung des Systems. Weiterführende Arbeiten könnten u. a. folgende Aspekte beinhalten. Sicherheit. Derzeit existieren keine Sicherheitsmechanismen. Sinnvoll wäre hier die Nutzung des UsernameToken-Protokolls zur Authentifizierung sowie die Verwendung einer SSL-Verbindung. WSDL-Generator. Aufgrund der genannten Probleme sind die vom WSDL-Generator erzeugten WSDL-Dokumente nicht konform zu den jeweiligen WSRF-Standards. Die Probleme wurden inzwischen behoben, wodurch die fehlenden Elemente nun vom WSDL-Generator erzeugt werden könnten. Verbesserung der Nutzbarkeit. Das vom WSDL-Generator erzeugte WSDL-Dokument wird dem Klienten zurzeit nur in den Metadaten der EPR eines logischen Dienstexemplars zur Verfügung gestellt. Die Erweiterung der Schnittstelle der Dienstinstallationskomponente um eine entsprechende Methode wäre hier sinnvoll. 16 ab Version 6 DCL N AXP 25

26 Entwicklung einer transnationalen experimentbasierten Lernumgebung im Leonardo-Da-Vinci-Programm der Europäischen Union Zustandsbehaftete Dienste in JAX-WS. Wie in 3.5 dargelegt, könnte die Anfragenbearbeitungskomponente vereinfacht werden. MTOM. Die Übertragung der Dienstimplementierungen erfolgt zurzeit als Byte-Feld in Base64-Kodierung. Durch die Verwendung von MTOM 17 könnte die Übertragung optimiert werden. Anfragenbearbeitung. Die Anfragenbearbeitung könnte die Anfragen nicht nur weiterleiten, sondern auch zusätzliche Mechanismen anbieten. So könnte beispielsweise: Ein Caching der SOAP-Nachrichten erfolgen Anfragen an mehrere physische Dienstexemplare delegiert werden (Replication) Die oben genannten Anregungen stellen Verbesserungs- und Erweiterungsmöglichkeiten des implementierten AXP-Systems dar DCL N AXP

27 4 DESIGN UND IMPLEMENTIERUNG VON AUSFÜHRUNGSUMGEBUNGEN FÜR HETEROGENE DYNAMISCHE DIENSTUMGEBUNGEN (FRANK FEINBUBE) 4 Design und Implementierung von Ausführungsumgebungen für heterogene dynamische Dienstumgebungen (Frank Feinbube) Dieser Abschnitt beschäftigt sich vor allem mit der Realisierung von Softwarekomponenten, deren Aufgabe es ist, Webdienste auf unterschiedlichen Plattformen verfügbar zu machen. Dazu werden zunächst die allgemeinen Anforderungen an eine solche Komponente erörtert und dann - anhand der in unserem Projekt entstandenen Produkte - Möglichkeiten für deren Umsetzung diskutiert. Zusätzlich geht es in diesem Abschnitt um die Änderungen in der Datenhaltung bei der Entwicklung vom ASG-Projekt hin zum AXP-Projekt. 4.1 Die Ausführungsumgebungen im AXP-Projekt Im AXP-Projekt werden Dienste auf verschiedenen Umgebungen zur Ausführung gebracht. Zu diesem Zweck muss die jeweilige Umgebung eine Komponente anbieten, welche die Verwaltung der Dienste und die Verarbeitung von Anfragen an diese übernimmt. Diese Komponente wird im Folgenden als AXP-Dienstcontainer bezeichnet Was muss ein AXP-Dienstcontainer leisten? Dieser Abschnitt beschreibt die Anforderungen, die ein AXP-Dienstcontainer erfüllen muss. (vgl. Abbildung 4) Registrierung der Dienstcontainer in der AXP-Infrastruktur Jeder AXP- Dienstcontainer soll sich nach dem Starten automatisch bei der AXP-Software registrieren. Dazu steht ihm die AXP-Dienstcontainerregistrierung zur Verfügung. Alternativ kann er auch über die Verwaltungsschnittstelle (siehe Abschnitt 7) registriert werden. Dienstimplementierung Die AXP-Dienstcontainer ermöglichen die Ausführung von Diensten, die in einem spezifischen Format verfasst sind. So unterstützt der Java- Dienstcontainer zum Beispiel Dienste, die als Jar-Dateien vorliegen. Jedem AXP- Dienstcontainer ist genau ein solches Implementierungsformat zugeordnet. Die AXP- Software sorgt dafür, dass eine Dienstimplementierung nur auf einem Dienstcontainer platziert wird, der deren Typ verarbeiten kann. Eigenschaften Den AXP-Dienstcontainern ist außerdem eine Liste von Eigenschaften zugeordnet. Diese beschreiben Hard- oder Softwarebesonderheiten, über die ein Dienstcontainer verfügt, weil sie der Rechner, auf dem er ausgeführt wird, anbietet. Solche Merkmale können zum Beispiel Bluetooth oder die Verfügbarkeit eines bestimmten Übersetzers sein. Ein Dienst im AXP-Projekt kann nun seinerseits eine Liste von DCL N AXP 27

28 Entwicklung einer transnationalen experimentbasierten Lernumgebung im Leonardo-Da-Vinci-Programm der Europäischen Union Eigenschaften angeben, die für seine Ausführung notwendig sind. Die AXP-Software wird dann dafür sorgen, dass diese Dienste nur auf einem passenden Dienstcontainer platziert werden. Abbildung 4: Die Architektur eines Dienstcontainer in der AXP-Infrastruktur Informationsdienst für Dienstimplementierungen Da nur die AXP- Dienstcontainer in der Lage sind, das Format für sie verfasster Dienstimplementierungen zu interpretieren, müssen diese in der AXP-Infrastruktur einen Informationsdienst für Dienstimplementierungen (Quellcodeauszug 6) anbieten. Durch die Nutzung dieses Informationsdienstes ist es der AXP-Software möglich, die Beschreibung des entsprechenden Dienstes im WSDL-Format aus der Dienstimplementierung zu extrahieren. Listing 6: Die Schnittstelle des Informationsdienstes für Dienstimplementierungen (des.net-dienstcontainers) 1 public interface BinaryInformationService { 2 string ExtractWsdlFileFromBinary(byte[] placementunit); 3 } 28 DCL N AXP

29 4 DESIGN UND IMPLEMENTIERUNG VON AUSFÜHRUNGSUMGEBUNGEN FÜR HETEROGENE DYNAMISCHE DIENSTUMGEBUNGEN (FRANK FEINBUBE) Platzierung der Dienstimplementierungen Der wichtigste Bestandteil eines AXP- Dienstcontainers ist der Dienstplatzierungsdienst (Quellcodeauszug 7). Er dient dazu, einen Dienst auf dem Dienstcontainer zu platzieren und ihn somit für die Nutzung durch die AXP-Software zur Verfügung zu stellen. Zudem kann man eine Liste aller platzierten Dienste abfragen und einzelne Dienste wieder entfernen. Listing 7: Dienstplatzierungsdienstschnittstelle (des.net-dienstcontainers) 1 public interface PlacementService{ 2 string[] list(); 3 string place(string implid,string placementtype,byte[] placementunit); 4 bool unplace(string implid); 5 } Messdatenanbieter Damit die AXP-Software gute Platzierungsentscheidungen treffen kann, ist eine Erfassung und Auswertung von Leistungsindikatoren der einzelnen AXP-Dienstcontainer notwendig. Ein Dienstcontainer sollte daher einen Messdatenanbieter implementieren, der die in Quellcodeauszug 8 gezeigten Schnittstellen erfüllt. Der Messdatenanbieter hat zwei Aufgaben: Zum einen muss er Methoden anbieten, die es ermöglichen, die gemessenen Werte abzufragen, zum anderen muss er den lokalen Messdatensammlern eine Möglichkeit geben, ihre Messwerte weiterzuleiten. Als Messdatensammler werden dabei kleine Programme oder Programmteile bezeichnet, die Messdaten erfassen und sie dem Messdatenanbieter übergeben. Listing 8: Die Schnittstellen der Messdatenanbieter (des.net-dienstcontainers) 1 public interface MeasurementHost4Consumer{ 2 Measurement GetLatestValue(string measurementtype); 3 Measurement GetLatestValueForService(string measurementtype, 4 Service service); 5 6 Measurement[] GetMeasurementsForTimespan(string measurementtype, 7 DateTime start, DateTime end); 8 Measurement[] GetMeasurementsForTimespanAndService( 9 string measurementtype, DateTime start, DateTime end, 10 Service service); 11 } public interface MeasurementHost4Provider{ 14 void AddMeasurementValue(Measurement measurement); 15 } Zustandspersistierung Den Diensten im AXP-Projekt steht eine Bibliothek zur Verfügung, die ihnen die Persistierung ihres Zustandes erlaubt. Dabei gibt es verschiedene Gültigkeitsbereiche für die Zustandsvariablen: So existieren Zustandsvariablen für spezifische Dienstexemplare, solche für Dienstklassen und globale Zustandsvariablen. In diesem Kontext ist die eindeutige Identifikation der Dienstexemplare ein Problem, das es zu lösen gilt. Auf die jeweilige Lösung wird in den Abschnitten über den.net-dienstcontainer (4.1.2) und den Java-Dienstcontainer (4.1.3) näher eingegangen. DCL N AXP 29

30 Entwicklung einer transnationalen experimentbasierten Lernumgebung im Leonardo-Da-Vinci-Programm der Europäischen Union Listing 9: Die Zustandspersistierung (des.net-dienstcontainers) 1 public class PropertySupport{ 2 public static void SetProperty(PropertyType type, string propertykey, 3 object value); 4 public static T GetProperty<T>(PropertyType type, string propertykey, 5 T defaultvalue); 6 public static void DeleteProperty(PropertyType type, 7 string propertykey); 8 } Prinzipiell kann jeder Dienstcontainer, der die oben genannten Anforderungen erfüllt, in die AXP-Infrastruktur eingebunden werden. Auf diese Weise können mehrere Programmiersprachen und Plattformen in die AXP-Infrastruktur eingebunden werden. Wir haben in unserem Bachelorprojekt einen.net-dienstcontainer und einen unvollständigen Java-Dienstcontainer umgesetzt. Abbildung 5: Die Architektur des.net-dienstcontainer 30 DCL N AXP

31 4 DESIGN UND IMPLEMENTIERUNG VON AUSFÜHRUNGSUMGEBUNGEN FÜR HETEROGENE DYNAMISCHE DIENSTUMGEBUNGEN (FRANK FEINBUBE) Der.NET-Dienstcontainer Der allgemeine Aufbau des.net-dienstcontainers folgt dem in Kaptiel 4.1 beschriebenen Muster (vgl. Abbildung 5). So verfügt dieser über einen Informationsdienst für Dienstimplementierungen, einen Dienstplatzierungsdienst und einen Messdatenanbieter. Diese Funktionalität wird vom Dienstcontainerkern implementiert, welcher über.net Remoting angeboten wird. Die Logik der zugehörigen Webdienste greift per.net Remoting auf diesen Kern zu. Initialisiert wird der Kern vom Start und Einrichtungs -akteur, welcher auch die Registrierung bei der AXP-Software übernimmt und für das Setzen der Einstellungen sorgt. Der.NET-Dienstcontainer ist als Windowsdienst realisiert. Zusätzlich verfügt er über eine einfache Benutzungsschnittstelle, die eine eigene Windows Forms -Anwendung ist und die Verwaltung der platzierten Dienste ermöglicht. Wichtig ist bei den.net-dienstcontainern vor allem der Bestandteil, der die Anfragenverarbeitung für die Webdienste übernimmt. Die Realisierung dieses Teilsystems wird im nächsten Abschnitt diskutiert. Anfragenbearbeitung für Webdienste mit dem.net Framework In der folgenden Auflistung werden die verschiedenen Varianten für die Realisierung der Anfragenverarbeitung von Webdiensten mit dem.net Framework betrachtet. Internet Information Services. Die Internet Information Services 18 (IIS) von Microsoft bilden einen Webserver, der unter anderem die Anfragenbearbeitung für ASP.NET-Webdienste erlaubt. Während die IIS 6.0 einen monolithischen Aufbau hatten, bestehen die IIS 7.0 aus einem kleinen Kern und über 40 Komponenten, die bei Bedarf aktiviert werden können. Dieses komponentenbasierte Grundgerüst in Kombination mit der umfangreichen API, die das Erstellen eigener Module für jede Ebene unterstützt, machen die IIS 7.0 zu einer guten Grundlage für die Entwicklung eines.net-dienstcontainers. Da die IIS 7.0 jedoch nur unter Microsoft Vista und Microsoft Longhorn zur Verfügung stehen und für das Projekt langfristig Lauffähigkeit unter Linux (mit Hilfe des Mono 19 -Projektes) angestrebt wurde, kam die Verwendung der IIS für uns nicht in Frage. Die IIS sind zudem sehr komplex und für unsere Belange viel zu mächtig. Wir haben eine kleine, effektive Lösung für die Anfragenverarbeitung angestrebt und wollten selbst Einfluss auf den dazu verwendeten Quellcode haben..net-remoting. Eine weitere Idee war, unsere AXP-Dienste per.net Remoting anzubieten. Dabei stellte sich jedoch heraus, dass die WSDL-Beschreibungen der.net-remoting-objekte denen der Webdienste, die sie repräsentieren, nicht entsprechen. Die von den.net Remoting -Objekten erzeugten WSDL- Beschreibungen waren nicht WS-I 20 konform. Dies führte zu Problemen mit der Interoperabilität (siehe dazu Tabelle 1). 18 (früher Internet Information Server genannt) 19 Page 20 Sie waren insbesondere rpc-kodiert [W3C01]. DCL N AXP 31

32 Entwicklung einer transnationalen experimentbasierten Lernumgebung im Leonardo-Da-Vinci-Programm der Europäischen Union Cassini. Beim Cassini-Projekt von Microsoft handelt es sich um einen einfachen, kompakten Open-Source-HTTP-Webserver. Im Laufe unseres Bachelorprojektes entstand ein.net-dienstcontainer, der den Cassini-Quellcode zur Anfragenverarbeitung der ASP.NET-Webdienste verwendete. Leider wird mit dem Cassini- Webserver für jeden angebotenen Webdienst ein eigener Port benötigt. Auch für das Cassini-Projekt gilt wie bei den Internet Information Services, dass die Fähigkeiten weit über unsere Anforderungen hinaus gehen. Unsere finale Realisierung des.net-dienstcontainers verwendet daher nicht den Cassini-Quellcode, sondern direkt die Klassen aus dem System.Web.Hosting-Namensraum, der im nächsten Abschnitt vorgestellt wird. Einen guten Überblick über das Cassini- Projekt und dessen Möglichkeiten und Grenzen erhält man in [Wey04]; nähere Erläuterungen zum Cassini-Quellcode gibt es in [New]. System.Web.Hosting. Im System.Web.Hosting-Namensraum befindet sich alles, was man zur Bearbeitung von Webdienstanfragen an ASP.NET-Webdienste benötigt. Dabei wird für die Entgegennahme der Anfragen die HTTP.SYS und für die Verarbeitung die ASPNET ISAPI.DLL-Komponente verwendet. Auf diesen Systemen setzen auch die Internet Information Services und Cassini auf. Unsere Lösung verwendet direkt die Klassen aus dem System.Web.Hosting-Namensraum und hat dadurch die Möglichkeit die Verarbeitung der Anfragen direkt zu beinflussen. Ein umfassender Einstieg in das Thema findet sich in [Sko04]; Windows Communication Foundation. Die Windows Communication Foundation (WCF) ist ein Bestandteil des Microsoft.NET Framework 3.0. Sie erleichtert das Anbieten und Konsumieren von Webdiensten sehr stark. Allerdings hätte uns die Verwendung der WCF-Klassen und damit des neuen Frameworks von unserem Ziel der Lauffähigkeit unter Linux (mit Hilfe des Mono-Projektes) entfernt. Ein guter Überblick über den Einsatz der WCF-Klassen zur Arbeit mit Webdiensten findet sich in [Wey06]. Problemfeld Interoperabilität Um die Möglichkeiten und Grenzen der Interoperabilität zwischen Java und.net zu evaluieren, haben wir einige Tests durchgeführt. Dabei ging es vor allem darum zu validieren, ob es sinnvoll ist, die.net-webdienste per.net Remoting anzubieten. Wir haben dazu vier einfache Webdienste entworfen. Der erste Webdienst enthielt Methoden die nur die Basisdatentypen bool, byte, int, float, double und string verwendeten. Der zweite enthielt Methoden, die Arrays dieser Datentypen benutzten, ausgenommen Byte-Arrays, weil wir diese in einem eigenen - dem dritten - Webdienst testeten. Der letzte Dienst schließlich definierte eine eigene Klasse, die alle Basisdatentypen und entsprechende Arrays als Felder enthielt, sowie Methoden die diese Klasse verwendeten. Diese Webdienste wurden nun jeweils von einer Komponente angeboten und von der anderen konsumiert. Dabei wurde überprüft, ob die Interaktion problemlos funktioniert. Angeboten wurden die Dienste zunächst über.net WS Remoting..NET WS Remoting bedeutet dabei, dass die Webdienst-Klasse dahingehend geändert wurde, 32 DCL N AXP

33 4 DESIGN UND IMPLEMENTIERUNG VON AUSFÜHRUNGSUMGEBUNGEN FÜR HETEROGENE DYNAMISCHE DIENSTUMGEBUNGEN (FRANK FEINBUBE) dass sie von System.MarshalByRefObject ableitet und so über.net Remoting zur Verfügung gestellt werden konnte (siehe dazu auch [Ras05]). Weiterhin wurden sie zum Vergleich über Java 6.0 mit integriertem JAX-WS 21 und dem integrierten Webserver 22 des Visual Studio 2005 verfügbar gemacht. Die Konsumenten wurden für Java 6.0 (mit integriertem JAX-WS) mit dem wsimport-werkzeug und für.net über das im Visual Studio 2005 integrierte Werkzeug zur Erzeugung von Webreferenzen (in Tabelle 1 mit.net Webref Klient bezeichnet) erzeugt. verwendete Anbieter / Konsumenten.NET WS Remoting &.NET Webref Klient.NET WS Remoting & Java 6.0 JAX-WS Java 6.0 JAX-WS &.NET Webref Client.NET VSWebserver & Java 6.0 JAX-WS Basis- Array (ohne Byte- eigene Klasse Datentypen Byte-Array) Array möglich a eingeschränkt nicht eingeschränkt möglich ab möglich ac möglich abc nicht nicht möglich a nicht nicht möglich a möglich a möglich a möglich möglich möglich möglich möglich d möglich möglich möglich a.net Remoting nicht WS-I konform (veränderte WSDL, rpc-encoded [W3C01]) b Probleme mit Bool-Arrays c Probleme mit Byte-Arrays (Probleme mit der Base64-Kodierung) d Java bildet Byte auf Short ab Tabelle 1: Problemfeld Interoperabilität Wie man anhand von Tabelle 1 erkennen kann, ist das Anbieten der Webdienste mittels.net Remoting für unsere Zwecke ungeeignet. Eine Verwendung von normalen Webdiensten hingegen ist problemlos möglich. Die Interoperabilität zwischen Java und.net ist gewährleistet. Weitergabe der ID eines logischen Dienstexemplars Einem Dienstexemplar soll, wie in Abschnitt beschrieben, die Speicherung seiner Zustände ermöglicht werden. Dabei ist es für die Realisierung der Zustandspersistierung notwendig, dass das Dienstexemplar eindeutig identifiziert werden kann. Die Identität des Dienstexemplars ist der AXP-Software bekannt, und wird von dieser bei einer Webdienstanfrage als Identifikator mittels WS-Adressing-Header [W3C06] an den AXP-Dienstcontainer übergeben (siehe dazu auch 3.1.1). Nun muss dafür gesorgt werden, dass dieser Identifikator der Zustandspersistierung verfügbar gemacht wird. Wir haben uns für die Lösung 21 Nähere Informationen zu JAX-WS finden sich in [KG07] 22 Dieser verwendet letztlich auch den im letzten Abschnitt besprochenen System.Web.Hosting- Namensraum. DCL N AXP 33

34 Entwicklung einer transnationalen experimentbasierten Lernumgebung im Leonardo-Da-Vinci-Programm der Europäischen Union dieses Problems an der Realisierung im ASG-C5-Projekt orientiert, welches die Übergabe des Identifikators durch den Thread Local Storage erreicht. Die Zustandspersistierung liest den Identifikator aus dem Thread Local Storage und verwendet diesen für das Lesen und Speichern der Zustandsdaten. Dies ist deshalb möglich, weil die Zustandspersistierung als Bibliothek vorliegt und der Zugriff darauf per Konvention im selben Thread erfolgen muss wie die Anfragenabarbeitung des Webdienstes. Zunächst jedoch muss der Identifikator aus der Anfragenachricht extrahiert und in den Thread Local Storage eingestellt werden. Dazu muss die entsprechende Komponente Zugang zu der Anfragenachricht haben, sich im selben Thread wie deren Bearbeitungskomponente befinden und vor Beginn der Bearbeitung aktiv werden. Unser erster Ansatz hierfür war diese Aufgabe direkt in der Bearbeitungskomponente - dem System.Web.HttpWorkerRequest - zu realisieren, da diese alle genannten Anforderungen erfüllt. Diese Umsetzung war jedoch nicht ganz intuitiv und brachte viele Probleme mit sich. Es war uns zwar möglich auf diese Weise eine funktionale Lösung zu entwickeln, dennoch schien uns diese nie richtig elegant zu sein. Die Verwendung von Soap-Erweiterungen, die im nächsten Abschnitt erläutert ist, gab uns die Möglichkeit, eine sehr viel elegantere Lösung zu erreichen. Der Einsatz von SOAP-Erweiterungen im.net-dienstcontainer Durch SOAP- Erweiterungen kann man vor und nach der Bearbeitung der Anfrage an einem Webdienst eigenen Quellcode zur Ausführung bringen. Die SOAP-Erweiterung wird dabei im selben Thread wie die Bearbeitungskomponente der Anfrage ausgeführt. Daher eignen sich SOAP-Erweiterungen optimal für die Realisierung der Weitergabe des Dienstexemplaridentifikators. In Abbildung 6 ist der Ablauf einer Anfragenbearbeitung im.net-dienstcontainer dargestellt. Zunächst bekommen die SOAP-Erweiterungen die Möglichkeit ihre Logik auszuführen, dann wird der eigentliche Webdienst aufgerufen und kann mit Hilfe der Zustandspersistierung seinen Zustand laden. Dazu verwendet die Zustandspersistierung die Datenbankzugriffsschicht und den Dienstexemplaridentifikator aus dem Thread Local Storage. Zum Ende der Bearbeitung speichert der aufgerufene Webdienst seinen Zustand. Danach können die SOAP-Erweiterungen noch einmal Quellcode ausführen. Dann ist die Bearbeitung abgeschlossen. Bei der Verknüpfung von Webdiensten mit SOAP-Erweiterungen kann man wählen, ob man die SOAP-Erweiterungen als unkompilierte Quellcodedatei oder als kompilierte Bibliothek verwendet. Wir haben uns für Letzeres entschieden, da die Einbindung von anderen Bibliotheken so sehr viel einfacher ist und auf die Weise sichergestellt werden kann, dass der Quellcode der SOAP-Erweiterungen frei von Syntaxfehlern ist. Zudem ist es auf diese Weise möglich diese Bibiotheken in dem globalen Bibliothekenverzeichnis abzulegen und damit komfortabel für die Verwendung durch alle Webdienste zur Verfügung zu stellen und Redundanz zu vermeiden. Weiterführende Literatur zu SOAP-Erweiterungen findet sich in [Pow04] und in [Tab02]. 34 DCL N AXP

35 4 DESIGN UND IMPLEMENTIERUNG VON AUSFÜHRUNGSUMGEBUNGEN FÜR HETEROGENE DYNAMISCHE DIENSTUMGEBUNGEN (FRANK FEINBUBE) Abbildung 6: Der Aufruf eines Webdienstes im.net-dienstcontainer DCL N AXP 35

36 Entwicklung einer transnationalen experimentbasierten Lernumgebung im Leonardo-Da-Vinci-Programm der Europäischen Union Der Java-Dienstcontainer Das ASG-Projekt verfügte über einen Java-Dienstcontainer. Bei der Neuimplementierung (siehe Abschnitt 3) wurde die Infrastruktur allerdings so stark überarbeitet, dass dieser im AXP-Projekt nicht mehr lauffähig ist. Dies liegt vor allem an den gravierenden Änderungen in der Datenhaltung (siehe Abschnitt 4.2.1). Dennoch genügt es für die Portierung, eine Anpassung der Java-Zustandspersistierung vorzunehmen sowie einen Informationsdienst für die Dienstimplementierungen zu realisieren. Ein Teil der Problemlösungen aus dem ASG-Projekt, wie die im folgenden Abschnitt beschriebene Weitergabe des Dienstexemplaridentifikators, kann also übernommen werden. Weitergabe der ID eines logischen Dienstexemplars Wie schon im ASG-Projekt wird der Dienstexemplaridentifikator von einem JAX-WS-Handler( [Pul]) aus der SOAP- Nachricht ausgelesen und in den Thread Local Storage geschrieben. Die Arbeitsweise entspricht dabei ziemlich genau der.net-implementierung aus Abschnitt Datenbank Ein Teil unseres Projektes war die Erstellung und Anpassung eines geeigneten Datenbankschemas um eine einfache, effiziente Persistierung zu erreichen. Auf einige Probleme, die sich dabei ergaben und einige Entscheidungen, die wir in diesem Zusammenhang getroffen haben, wird in diesem Abschnitt eingegangen Die Umstellung des Datenbankzugriffs Im Folgenden werden die Gründe für die Änderungen in der Datenhaltung diskutiert sowie deren Umsetzung vorgestellt. Der Datenbankzugriff im ASG-C5-Projekt Im ASG-C5-Projekt wurde der Datenbankzugriff mit dem Hibernate 23 -Persistierungssystem auf eine PostgreSQL 24 - Datenbank realisiert. Allerdings kam es im Laufe der damaligen Projektarbeit zu Problemen mit dem Hibernate-System. Dieses verursachte in einigen Situationen Fehler, weil es versuchte beim Entfernen von Einträgen eine Aktualisierung ihrer Zustände durchzuführen. Zudem gab es sehr viel Optimierungspotenzial. So enthielt das vom Hibernate-System generierte Datenbankschema viele ähnliche Tabellen und einige redundante Informationen. Das Datenbankschema des ASG-C5-Projektes Das grundlegende Datenbankschema des ASG-C5-Projektes ist in folgender Auflistung erklärt: (vgl. Abbildung 7) DCL N AXP

37 4 DESIGN UND IMPLEMENTIERUNG VON AUSFÜHRUNGSUMGEBUNGEN FÜR HETEROGENE DYNAMISCHE DIENSTUMGEBUNGEN (FRANK FEINBUBE) Abbildung 7: Die Datenbankstruktur des ASG-C5-Projektes [Saa06] DCL N AXP 37

38 Entwicklung einer transnationalen experimentbasierten Lernumgebung im Leonardo-Da-Vinci-Programm der Europäischen Union Host. Die Rechner, die in der ASG-C5-Software registriert sind. Sie verfügen über einen Namen (bzw. IP) und ein URI auf das Messsystem 25, welches für die Erfassung von rechnerspezifischen Messwerten zuständig ist. Das Messsystem ist eine eigene vom Dienstcontainer unabhängige Software. Server. Die Dienstcontainer des ASG-C5-Projektes. Sie enthalten eine Zuordnung zu einem Rechner, den Dienstimplementierungstyp (hier PlatformType genannt), die sie verarbeiten können, und den URI des Dienstplatzierungsdienstes. Zudem gibt es wie bei Host einen URI auf das Messsystem. Die URIs werden dabei nur teilweise gespeichert und bei Bedarf dynamisch generiert. Diese automatische Erzeugung der URIs verbietet es allerdings andere Protokolle als das HTTP- Protokoll zu verwenden. Service. Die Dienstklassen, die in der ASG-C5-Software registriert sind. Sie enthalten einen Namen, eine Beschreibung im WSDL-Format, die eigentliche Dienstimplementierung im Binärformat sowie deren Typ (hier PlatformType genannt). server service rel. Die physischen Dienstexemplare. Sie entsprechen einem Diensteexemplar, das auf einem Dienstcontainer platziert ist und haben einen URI über den der Zugriff auf sie erfolgen kann. svc instance. Die logischen Dienstexemplare. Sie sind einer Dienstklasse zugeordnet und haben einen Zeitpunkt, nach dessen erreichen sie ihre Gültigkeit verlieren. Request. Die Aufrufe an Dienstexemplare in der ASG-C5-Software. Diese Relation beinhaltet den Dienstcontainer, auf dem der Aufruf ausgeführt wird, das logische Dienstexemplar, an dem dieser Aufruf erfolgt sowie die zugehörige Methode. Operation. Die Methoden der Dienste, die in der ASG-C5-Software registriert sind. Sie verfügen über einen Namen und sind den Diensten über die service_operation -Relation zugeordnet. Im Schema der Datenbank des ASG-C5-Projektes finden sich fünf Relationen, die für die Erfassung von Messwerten zuständig sind. Diese Relationen unterscheiden sich jedoch nur in einem Punkt, nämlich bei den Fremdschlüsseln. So enthält server_measurement eine server_id, während request_measurement eine request_id enthält. Da hier alle Fremdschlüssel den Typ integer haben, wäre es ein Leichtes, diese fünf Relationen in einer einzigen zusammenzufassen, die um die Spalte measurement_type erweitert ist. Der Inhalt dieser neuen Spalte würde dann identifizieren, ob der Messwert einem Server oder einem Request zugeordnet werden soll. Diese Optimierung wird sogar vom Hibernate-System unterstützt; eine Umstellung wäre folglich trivial. 26 Eine äquivalente Optimierung könnte mit den Tabellen inst_property, svc_property und global_property 27 durchgeführt werden. 25 Nähere Informationen zum Messsystem des ASG-C5-Projektes finden sich in [Saa06]. 26 Realisiert werden kann dies durch den Einsatz der Discriminator-Funktionalität (siehe dazu [CB04]). 27 Die Tabelle global_property wurde in der Übersicht leider vergessen, ist aber äquivalent zu den beiden anderen hier genannten Relationen. 38 DCL N AXP

39 4 DESIGN UND IMPLEMENTIERUNG VON AUSFÜHRUNGSUMGEBUNGEN FÜR HETEROGENE DYNAMISCHE DIENSTUMGEBUNGEN (FRANK FEINBUBE) Der Datenbankzugriff im AXP-Projekt Aufgrund der Probleme mit dem Hibernate- System im ASG-C5-Projekt und unserem Mangel an Erfahrung bezüglich der Arbeit mit Hibernate und NHibernate 28 haben wir uns entschieden, kein vorgefertigtes Persistierungssystem zu verwenden. Da die Anzahl unserer Tabellen sehr gering ist, war der Aufwand den Datenbankzugriff von Hand zu implementieren viel geringer, als der Aufwand einer Einarbeitung in Hibernate und NHibernate. Um die Anwendungslogik für den Datenbankzugriff zentral zu halten, haben wir uns für die Verwendung von Stored Procedures entschieden. Daraus ergaben sich jedoch Probleme mit dem PostgresSQL-Datenbankmanagementsystem, denn dieses unterstützt das Konzept der Stored Procedures nicht. Die Realisierung wäre zwar über das Functions-Konzept dennoch möglich gewesen, allerdings erlaubten die uns zur Verfügung stehenden PostgresSQL-Werkzeuge keine effiziente Entwicklung. Basierend auf meiner Erfahrung mit Firebird 29 -Datenbanken aus früheren Projekten, der Verfügbarkeit von umfangreichen Datenbankwerkzeugen für dieses Datenbankmanagementsystem und unter Berücksichtigung des Zeitdrucks unter dem sich die Einführung eines neuen Persistierungssystems beim damaligen Projektstand befand, entschloss ich mich daher auf das Firebird-Datenbankmanagementsystem umzusteigen. Nun war es sehr schnell und komfortabel möglich, die benötigten Stored Procedures zu erstellen und den Umstieg unserer Infrastruktur auf das neue Persistierungssystem zu vollziehen. In unserem Projekt erfolgt der Datenbankzugriff mittels ODBC 30 aus der.net- Datenzugriffsschicht und mittels JDBC 31 aus Java-Datenbankzugriffsschicht auf eine Firebird-Datenbank, deren Struktur im Folgenden beschrieben ist. Das Datenbankschema des AXP-Projektes Das Datenbankschema des AXP- Projektes ist in folgender Auflistung erklärt: (vgl. Abbildung 8) Server. Die Dienstcontainer, die in der AXP-Software registriert sind, werden in der Relation Server gehalten. Ein Server-Eintrag verfügt dabei über URLs auf die Dienste, die ein AXP-Dienstcontainer mindestens anbieten muss, damit er von der AXP-Software genutzt werden kann. Zudem wird hier der Typ der Dienstimplementierung, die der Dienstcontainer verarbeiten kann, abgelegt. Jedem Dienstcontainer ist eine Liste von Eigenschaften zugeordnet, über die er verfügt. Diese Liste wird ihm über die Server_PlatformFeature_Rel-Tabelle zugeordnet. Zusätzlich wird der Name (bzw. die IP-Adresse) des Rechners gespeichert, auf dem der Dienstcontainer ausgeführt wird. Nähere Informationen zu AXP-Dienstcontainern, Dienstimplementierungen und Eigenschaften finden sich in Service. In der Tabelle Service werden die Dienste des AXP-Projektes abgelegt. Hier findet sich die Beschreibung des Dienstes im WSDL-Format (optional zusätzlich 28 NHibertnate ist eine Portierung des Hibernate-Persistierungssystems für das Microsoft.NET Framework DCL N AXP 39

40 Entwicklung einer transnationalen experimentbasierten Lernumgebung im Leonardo-Da-Vinci-Programm der Europäischen Union Abbildung 8: Die neue Datenbankstruktur des AXP-Projektes in Worten) sowie der Dienst- und Port-Name, jeweils mit zugehörigem Namensraum. Auch der eigentliche Dienst liegt in Form einer Dienstimplementierung vor. Dazu wird die Dienstimplementierung im Binärformat sowie deren Typ gespeichert. Weiterhin werden die Scheduling-Informationen für den Dienst in dieser Tabelle gehalten. Zuletzt verfügt ein Dienst im AXP-Projekt über eine Liste von Eigenschaften, die er für seine Ausführung benötigt. Diese werden ihm über die Tabelle Service_PlatformFeature_Rel zugeordnet. PlatformFeature. Eine Eigenschaft verfügt über einen Namen und eine Beschreibung. Sie ist über die *_PlatformFeature_Rel-Relationen den entsprechenden AXP- Dienstcontainern und Diensten zu geordnet. (siehe auch 4.1.1) LogicalServiceInstance. Die logischen Dienstexemplare des AXP-Projektes befinden sich in der LogicalServiceInstance-Relation. Ihnen ist ein Dienst, dessen aktueller Status und seine Priorität zugeordnet. Zudem verfügen sie über einen Zeitpunkt, nach dessen Erreichen sie ungültig werden. PhysicalServiceInstance. In der Tabelle PhysicalServiceInstance liegen die physischen Dienstexemplare. Sie benötigen die Zuordnung zu einem Dienst und zu dem Dienstcontainer auf dem sie platziert und damit verfügbar sind. Zusätzlich genügt es die URL des physischen Dienstes zu speichern. Property. Den Diensten im AXP-Projekt können ihre Zustandsdaten speichern. Diese Speicherung erfolgt in der Tabelle Property. Dabei gibt es verschiedene Ebenen der Zustandsspeicherung. Eine Zustandsvariable kann für ein Dienstexemplar, für eine Dienstklasse oder global gelten. Dieser Gültigkeitsbereich wird mittels PropertyType festgelegt. Falls es sich nicht um einen globalen Eintrag han- 40 DCL N AXP

41 4 DESIGN UND IMPLEMENTIERUNG VON AUSFÜHRUNGSUMGEBUNGEN FÜR HETEROGENE DYNAMISCHE DIENSTUMGEBUNGEN (FRANK FEINBUBE) delt, muss in ForeignID die ID des entsprechenden Dienstes bzw. des zugehörigen logischen Dienstexemplars abgelegt werden. Damit eine Zustandsvariable identifiziert werden kann, wird ihr zudem ein Zustandsschlüssel zugeordnet. Die Zustandsinformationen werden in PropertyValue im Binärformat gespeichert. Zusätzlich wird für jeden Zustand auch der Zeitpunkt seiner Erstellung und der letzten Änderung erfasst Die Auslagerung der Datenlogik in die Datenbank Da die AXP-Software und alle Zustandspersistierungen auf eine zentrale Datenbank zugreifen, haben wir uns entschlossen Stored Procedures zu verwenden. Durch die Verwendung von Stored Procedures kann ein Teil der Anwendungslogik, nämlich der Teil, der sich mit der Verwaltung der Datenobjekte beschäftigt, in die Datenbank ausgelagert und auf diese Weise zentral zur Verfügung gestellt werden. Für die Datenobjekte gibt es jeweils eine Reihe von Standardzugriffsmethoden, die das folgenden Namensschema erfüllen: ADDORUPDATE<TYPE>. Aktualisieren, wenn der Eintrag in der Tabelle bereits vorhanden ist, ansonsten einen neuen Eintrag erstellen. DELETE<TYPE>. Entfernen eines einzelnen Eintrags aus der Tabelle. GET<TYPE>BY<PK>. Ermitteln eines Eintrages anhand des Primärschlüssels. GET<TYPE>BY<FK>. Ermitteln einer Liste von Einträgen, die über den Fremdschlüssel identifiziert werden. Für die Verwaltung der Eigenschaften waren darüber hinaus Datenbankprozeduren notwendig, die es erlaubten, einzelne Eigenschaften mit einem AXP-Dienstcontainer (ADDPLATFORMFEATUREFORSERVER) bzw. Dienst (ADDPLATFORMFEATUREFORSER- VICE) zu verbinden sowie alle diese Verbindungen für einen Dienstcontainer (DELETEALLPLATFORMFEATFORSERVER) bzw. Dienst (DELETEALLPLATFORMFEATFORSER -VICE) zu entfernen. Darüber hinaus gibt es Stored Procedures für spezielle Anfragen im AXP-Projekt: Die GETLOGICALSVCINSTWITHMINTTL-Prozedur ermöglicht es, zum Beispiel das logische Dienstexemplar zu ermitteln, das als nächstes seine Lebensdauer überschreitet. Über die GETVALIDSERVERFORSERVICE-Prozedur erhält man alle AXP-Dienstcontainer, die in der Lage sind den Dienstimplementierungstyp eines Dienstes zu verarbeiten und zudem über alle von ihm geforderten Eigenschaften verfügen. DCL N AXP 41

42 Entwicklung einer transnationalen experimentbasierten Lernumgebung im Leonardo-Da-Vinci-Programm der Europäischen Union 4.3 Ausblick Der.NET-Dienstcontainer erfüllt alle in Abschnitt vorgestellten Anforderungen. Darüber hinaus kann auch hier einiges verbessert werden. Um eine sichere Ausführung der Dienste im Dienstcontainer zu gewährleisten, muss die Konfiguration der Anwendungsdomäne durchdacht und die Frage nach der richtigen Konfiguration geklärt werden. Um diese Konfigurationen zu testen, müssen zudem Angriffszenarien erdacht, in Webdiensten implementiert und getestet werden. Auch am Messsystem gibt es noch viele Aufgaben zu erledigen. Aufgrund der beschränkten Projektzeit, die uns für die Realisierung des Messsystems zur Verfügung stand und der Tatsache, dass das Erfassen von gültigen Messwerten, deren Aufbereitung und Auswertung eine beliebig hohe Komplexität aufweisen kann, ist die Implementierung des Messsystems nur als Prototyp zu verstehen. Es ergaben sich einige Probleme, die es noch zu lösen gilt. Die Realisierung als Webdienst hat zum Beispiel den Nachteil, dass die Menge der zu übertragenen Daten für einen Messwert auf diese Weise drastisch anwächst. Hier sollte über eine Alternative zur Kommunikation nachgedacht werden. Ein schwieriges Problem war die Frage welche Informationen zusätzlich zu einem Messwert gespeichert werden müssen, um diesem Wert eine Bedeutung zu geben. Auch die Erfassung weiterer Leistungsindikatoren durch die AXP-Dienstcontainer ist noch zu leisten. 42 DCL N AXP

43 5 INTEGRATION UND PORTIERUNG VON STEUERUNGSEXPERIMENTEN IN EINE VERTEILTE EXPERIMENTIERUMGEBUNG (DANIEL RICHTER) 5 Integration und Portierung von Steuerungsexperimenten in eine verteilte Experimentierumgebung (Daniel Richter) Ein grundlegender Bestandteil unseres Bachelorprojektes sind Experimente, welche als Dienste in die AXP-Infrastruktur installiert werden. Dazu gehörte die Aufgabe, die bestehenden Experimente aus dem Distributed Control Lab (DCL) in die neue Experimentierumgebung zu portieren. Im folgenden Abschnitt werden zunächst Vorteile von DNA-Experimenten gegenüber DCL-Experimenten, Probleme dienstorientierter Experimente und deren Lösungen, sowie Anforderungen an DNA-Experimentdienste erläutert. Zudem werden die entwickelten/portierten Experimente vorgestellt und ein DCL-Experiment mit der portierten DNA-Lösung verglichen. Nachdem die entstandenen Werkzeuge zur Erstellung von Diensten für das AXP bzw. von DNA-Experimenten erläutert wurden, wird schließlich ein Erfahrungsbericht über das Testen in unserem Projekt gegeben. 5.1 Experimente als AXP-Dienste Ausgangssituation: Experimente im DCL Der Hauptbestandteil eines Experiments in der bisherigen Experimentierumgebung (Distributed Control Lab) ist die Experimentsteuerungskomponente (ExperimentController). Diese meldet sich selbstständig bei der Experimentverwaltungskomponente (ExperimentManager) an und überträgt Experimentierergebnisse an die Ergebnisspeicherungskomponente (ResultManager) - beides geschieht via.net-remoting (siehe auch [RRTP04]). Da es sich bei einem DCL-Experiment um eine eigenständige Anwendung handelt, muss man diese auch manuell konfigurieren und installieren Vorteile von Experimenten als AXP-Dienste Werden die bisherigen Experimentsteuerungen jedoch als AXP-Dienste realisiert, ergeben sich folgende Vorteile bzw. Anforderungen: Reduzierung von Verwaltungsaufgaben. Die Experimentverwaltungskomponente wird nicht mehr benötigt. Stattdessen wird ein Experiment als Dienst installiert. Eine selbstständige Anmeldung durch das Experiment entfällt dadurch ebenfalls. Ebenso muss ein Experiment nicht mehr manuell platziert und auf dem Zielrechner konfiguriert werden, da Dienste (hier: Experimentsteuerungsdienste) auf geeigneten Maschinen platziert werden. Änderungen können zentral über die Verwaltungsschnittstelle (siehe 7.2.1) vorgenommen werden. vereinfachter Ergebnisdatenzugriff. Die Ergebnisspeicherungskomponente entfällt ebenfalls. Experimentergebnisse sind direkt als Web Service Resource Properties [OAS06b] abfragbar. DCL N AXP 43

44 Entwicklung einer transnationalen experimentbasierten Lernumgebung im Leonardo-Da-Vinci-Programm der Europäischen Union bessere Performanz. Im DCL wird die Analyse des Experimentquelltextes und dessen Ausführung in einem Schritt durchgeführt. Das heißt, dass bei mehreren gleichzeitigen Experimentläufen die Quelltextanalyse der letzten Anfrage erst dann ausgeführt wird, wenn alle Experimentausführungen vor ihm beendet wurden. Bei einem Experimentlauf im DNA ist die Analyse des Quelltextes getrennt von der Ausführung. Dadurch kann eine Analyse auch stattfinden, während eine Ausführung läuft, wodurch ein Benutzer des Experiments schon sehr früh auf Fehler in seinem Quelltext aufmerksam gemacht werden kann. Zudem kann - durch die dynamische Dienstplatzierung der Adaptive Execution Platform - die Quelltextanalyse auf anderen Rechnern als die Ausführung und auch parallel zu anderen Quelltextanalysen stattfinden. Sicherheit. Die Verhinderung von Schaden durch böswilligen Quelltext kann in manchen Fällen (z. B. Zugriff auf Systemressourcen) komplett vom AXP- Dienstcontainer übernommen werden Auftretende Probleme und deren Lösungen Sind Experimente anstatt eigenständiger Applikationen Dienste, treten jedoch auch folgende Probleme auf: Trennung von Quelltextanalyse und Ausführung. Die Trennung von Analyse des Quelltextes und dessen Ausführung wird im DNA durch zwei separate Dienste - und nicht nur durch verschiedene Methoden - realisiert, dem Quelltextanalyse- /Kompilierungsdienst (CompileService, nachfolgend nur Kompilierungsdienst genannt) und dem Ausführungsdienst (ExecutionService). Gründe dafür sind, dass diese beiden Dienste verschiedene Anforderungen an den Dienstcontainer haben, was in einer besseren Lastverteilung resultiert. Darüber hinaus können Quelltextanalysen in der Regel parallel ausgeführt werden, während Ausführungen serialisiert werden müssen; beides sind verschiedene dienstspezifische Parameter (siehe auch 5.1.4). Ein Problem ist nun die Weitergabe der Resultate des Kompilierungsdienstes an den Ausführungsdienst. Eine direkte Rückgabe aller Ergebnisse entfiel auf Grund von Performanzbetrachtungen (da dadurch eine hohe Netzlast entsteht). Ebenso die Speicherung der Daten als exemplarspezifische Zustandsvariablen, da verschiedene Dienste keine Zugriffsmöglichkeit auf diese haben. Daher entschieden wir uns für die Speicherung der Resultate als globale Zustandsvariablen unter einem eindeutigen Schlüssel. Dieser Schlüssel ist dann die Rückgabe des Kompilierungsdienstes und wird an den Ausführungsdienst übergeben. Daraus ergibt sich jedoch ein weiters Problem: Kompilierungsdienst und Ausführungsdienst eines Experiments müssen einander zugeordnet werden. Dies kann nur über spezielle dienstklassenspezifische Zustandsvariablen realisiert werden (die genauen Konventionen werden in erläutert). 44 DCL N AXP

45 5 INTEGRATION UND PORTIERUNG VON STEUERUNGSEXPERIMENTEN IN EINE VERTEILTE EXPERIMENTIERUMGEBUNG (DANIEL RICHTER) Realisierung als Webdienst. Experimentdienste können als logische Dienstexemplare mit der Zustandspersistierung ihren Zustand speichern. Der Zustandspersistierung ist es jedoch nicht möglich, spezielle Referenzdatentypen, wie zum Beispiel Datenbankverbindungen oder geöffnete Sockets, zu speichern. Aufgrund der sich dadurch ergebenden Einschränkungen musste beispielsweise auch die sich direkt auf dem Experimentiergerät befindende Ausführungskomponente des Hau den Lukas -Experiments geändert werden. Wenn Objekte, die einen Zustand des Dienstes speichern sollen, serialisierbar sind, können diese aber ohne Probleme für die Zustandspersistierung benutzt werden. spezielle Infrastrukturanforderungen. Einige Experimente besitzen besondere Anforderungen an die Infrastruktur. Einige Kompilierungsdienste benötigen zum Beispiel bestimmte Übersetzer und Maschinenkonfigurationen, ebenso wie einige Ausführungsdienste, die eine Verbindung zu Experimentiergerätschaften herstellen müssen. Da AXP-Dienste dynamisch platziert werden, bietet sich jedoch auch hierfür Abhilfe durch bestimmte dienstspezifische Parameter. In diesen können Eigenschaften angegeben werden, welche der Dienstcontainer, in den der Dienst platziert wird, besitzen muss (siehe auch 5.1.4). Für den Fall, dass ein Dienst zudem maschinenspezifische Konfigurationen benötigt, haben wir uns entschieden, dass diese über Umgebungsvariablen zu realisieren sind. Da die Eigenschaften eines Dienstcontainers bei dessen Installation eingerichtet werden müssen, macht jenes keinen großen zusätzlichen Aufwand. langläufige Dienstaufrufe. Langläufige Aufrufe können für Klienten zu Problemen führen, da es zu Zeitüberschreitungen kommen kann bzw. Benutzungsschnittstellen nicht rechtzeitig reagieren. Durch bestimmte Resource Properties kann jedoch zu jeder Zeit der aktuelle Zustand eines Dienstes/Dienstaufrufs (siehe 3.3.1) sowie eventuelle Ergebnisdaten abgefragt werden. Somit können Experimentaufraufe auch leicht asynchron ausgeführt werden. Ein weiteres Problem ist die vorzeitige Beendigung von (langläufigen) Aufrufen. Da ein laufender Aufruf nicht einfach ignoriert und der nächste gestartet werden kann, bietet der AXP-Anfragenbearbeitungsakteur die Möglichkeit für einen Aufrufabbruch an (siehe 3.3.3). Durch Implementierung der CancelRequest-Methode (welche nie serialisiert aufgerufen wird) kann so dafür Sorge getragen werden, dass der aktuell ausgeführte Dienstaufruf die Abarbeitung beendet. Die Unterstützung von Aufrufabbrüchen ist somit optional und Angelegenheit des Experimententwicklers Anforderungen an die Implementierung eines DNA-Experiments Ein AXP-Dienst in.net ist ein einfacher Webdienst (Spezialisierung von System.Web.Services.WebService). Damit der AXP-Anfragebenarbeitungsakteur diesen DCL N AXP 45

46 Entwicklung einer transnationalen experimentbasierten Lernumgebung im Leonardo-Da-Vinci-Programm der Europäischen Union Dienst korrekt aufrufen kann, muss der Webdienst zusätzlich die beiden Attribute [WebServiceBinding(ConformsTo=WsiProfiles.BasicProfile1_1)] (er entspricht dem WS-I-Basisprofil Version 1.1.) und [SoapDocumentService(RoutingStyle =SoapServiceRoutingStyle.RequestElement)] (die Adressierung wird nicht mehr durch die SOAP-Action bestimmt, sondern durch die SOAP-Nachricht selbst) erhalten. (Sowohl für AXP-Dienste als auch für DNA-Experimente gibt es Projektvorlagen für das Microsoft Visual Studio - siehe 5.2.1). Der Quelltextanalyse-/Kompilierungsdienst erhält den vom Benutzer entwickelten Experimentsteuerungsquelltext, analysiert diesen, speichert die Resultate als globale Zustandsvariable und gibt den Schlüssel für den Zugriff auf jene zurück. Dafür muss die Webdienstmethode string Compile(string code) implementiert werden. Das Speichern der Analyse-/Kompilierungsdaten geschieht mit der (statischen) Methode PropertySupport.SetGlobalProperty(string propertykey,object propertydata), wobei der dafür verwendete Schlüssel der Rückgabewert der Compile-Methode ist. Der Ausführungsdienst kann Daten auf zweierlei Art annehmen: Entweder direkt als byte[] oder indirekt, indem er den zurückgegebenen Schlüssel des Kompilierungsdienstes als Parameter erhält. Ergebnisdaten der Experimentausführung können dann als exemplarspezifische Zustandsvariablen gespeichert werden. Die dafür verwendeten Schlüssel müssen in den dienstspezifischen Parametern angegeben werden (Details siehe unten). Folgende Webdienstmethoden müssen implementiert werden: void ExecuteFromParameter(byte[] compilationresult) (für die direkte Datenübergabe) und void ExecuteFromPropertySupport(string compilationresultpropertykey ) (für eine indirekte Datenübergabe). Das Lesen der Kompilierungsdaten mit dem Schlüssel des Kompilierungsdienstes ist mit der PropertySupport.GetGlobalProperty <T>(string propertykey,object defaultvalue)-methode der Zustandspersistierung möglich (dabei muss der Datentyp des gespeicherten Resultats bekannt sein). Die Speicherung der Experimentergebnisse geschieht mittels PropertySupport. SetInstanceProperty(string propertykey,object propertyvalue). Die (optionale) Implementierung der Webdienstmethode void CancelRequest() sollte dafür sorgen, dass eine aktuelle Experimentausführung schnellstmöglich abbricht. Dienstspezifische Parameter Bei der Installation eines AXP-Dienstes müssen zusätzlich zur Dienstimplementierung dienstspezifische Parameter angegeben werden. Realisiert sind diese als XML-Dokument, das einem speziellen Schema 32 entspricht. Dabei müssen u. a. folgende Angaben gemacht werden: Dienstimplementierungstyp DCL N AXP

47 5 INTEGRATION UND PORTIERUNG VON STEUERUNGSEXPERIMENTEN IN EINE VERTEILTE EXPERIMENTIERUMGEBUNG (DANIEL RICHTER) bestimmte Eigenschaften des Dienstes (für den Zugriff durch den AXP- Anfragenbearbeitungsakteur) Eigenschaften des Dienstcontainers, die dieser besitzen muss, um den Dienst korrekt anbieten zu können Scheduling-Verfahren des Dienstes Wartezeit zwischen zwei (serialisierten) Dienstaufrufen Zustandsvariablen mit Standardwerten, welche beim Erstellen eines logischen Dienstexemplars bereits eingerichtet werden (optional) Falls zum Beispiel ein Ausführungsdienst nur serialisiert aufgerufen werden kann oder Experimentgerätschaften eine bestimmte Ruhephase benötigen, kann dies in den dienstspezifischen Parametern angegeben werden. Ebenso wird der Dienst nur auf solchen Maschinen platziert, die auch die angegebnen Eigenschaften besitzen (eine solche Eigenschaft ist als eine einfache Zeichenkette realisiert; siehe auch 4.1.1). Die Zuordnung von Kompilierungsdienst und Ausführungsdienst geschieht durch spezielle Zustandsvariablen in den dienstspezifischen Parametern: Der Kompilierungs- und der Ausführungsdienst muss jeweils eine dienstklassenspezifische Zustandsvariable mit dem Schlüssel ExperimentType besitzen, dessen Wert für ein Experiment gleich und eindeutig ist. Außerdem muss der Name des Kompilierungsdienstes die Zeichenfolge Compile sowie der Ausführungsdienst die Zeichenfolge Execution beinhalten. In die dienstspezifischen Parameter des Ausführungsdienstes können zusätzlich noch folgende dienstklassenspezifische Zustandsvariablen eingefügt werden: ID Bedeutung Beispiel RenderTypes Aufzählung der Schlüssel der Zustandsvariablen, die für Ergebnisspeicherungen benutzt wurden, getrennt durch Komma. Hinter jedem Wert muss angegeben werden, wie diese gespeicherten Daten in der Experimentbenutzungsschnittstelle angezeigt werden sollen (Text, Diagram, Image, Flash) StdOut (Text), Diagram Data ( Flash) ManualUrl URL zu einer Anleitung der Benutzung des Experiments content/manual.pdf SampleCode Beispielquelltext für das Experiment ImageUrl URL zu einem Bild des Experiments experiment.jpg Location Standort des Experiments Hasso Plattner Institut DCL N AXP 47

48 Entwicklung einer transnationalen experimentbasierten Lernumgebung im Leonardo-Da-Vinci-Programm der Europäischen Union implementierte DNA-Experimente Echo. Das Echo-Experiment liefert als Experimentergebnis wieder den Experimentssteuerungsquelltext zurück. Es benötigt keine speziellen Eigenschaften des Dienstcontainers und wird für Tests der Experimentnutzungsschnittstelle benutzt. LEGO-Simulator. Hierbei handelt es sich um die Portierung des entsprechenden DCL- Experiments. Es nimmt C-Quelltext entgegen und simuliert einen Experimentlauf mit dem LEGO-RCX. Als Experimentergebnisse stehen Daten für die Darstellung als Animation, Graph und Text zur Verfügung. Der Kompilierungsdienst benötigt als Dienstcontainer-Eigenschaft einen C-Übersetzer. HauDenLukas. Auch hier handelt es sich um die Portierung des entsprechenden DCL- Experiments. Entgegengenommen wird sowohl C- als auch C#-Quelltext, der zu einer WindowsCE-Anwendung für das Experimentgerät übersetzt wird. Der Kompilierungsdienst benötigt folgende Dienstcontainer-Eigenschaften: einen C- und einen C#-Übersetzer, RealTime.NET, embedded C++ 4 und CygWin. Anfragen an den Ausführungsdienst müssen serialisiert werden. Als Experimentergebnis erhält man Text, der vom Experimentbenutzer selbst erzeugt wird. LEGO-NXT. Das LEGO-NXT-Experiment ist eine Neuentwicklung zur Steuerung des LEGO-NXT-Roboters. Dabei kann der Experimentbenutzer alle drei Motoren ansteuern und erhält Zugriff auf alle vier Sensoren. Entgengenommen wird C#-Quelltext, wobei aufgrund der Kompilierung mittels Microsoft. CSharp.CSharpCodeProvider keine Dienstcontainer-Eigenschaften für den Kompilierungsdienst benötigt wird. Der Ausführungsdienst benötigt eine Bluetooth- Verbindung zum LEGO-NXT-Roboter, wobei dessen Steuerung als Fernsteuerung mit Hilfe der NXT#-Klassenbibliothek 33 erfolgt. Somit müssen die Aufrufe des Ausführungsdienstes serialisiert ausgeführt werden Vergleich: DCL-Experiment vs. portiertes DNA-Experiment Nun soll kurz der Aufwand für die Implementierung des Experiments Hau den Lukas als DCL-Implementierung und als DNA-Implementierung untersucht werden. Betrachtet werden dabei die reinen Quelltextzeilen 34 aller beteiligten selbst implementierten Softwarekomponenten zur Steuerung des Experiments. Schon der Aufwand für die tatsächliche Experimentsteuerung ist in der DCL- Implementierung etwas größer. Darüber hinaus kommt zusätzlich etwa die Hälfte davon als Verwaltungsaufwand hinzu - dieser Anteil entfällt im DNA-Experiment ermittelt mithilfe des Microsoft-Visual-Studio-Plugins (http://www.wndtabs.com) Project Line Counter 48 DCL N AXP

49 5 INTEGRATION UND PORTIERUNG VON STEUERUNGSEXPERIMENTEN IN EINE VERTEILTE EXPERIMENTIERUMGEBUNG (DANIEL RICHTER) LOC im LOC im DNA DCL tatsächliche Experimentsteuerung (Kompilierungsd. 80, Ausführungsd. 151) Anmeldung an der Experimentverwaltungsund Ergebnisspeicherungs-Komponente sonstiges gesamt Softwareentwicklungswerkzeuge für AXP-Dienste/DNA- Experimente Im Rahmen der Entwicklung von Experimenten als AXP-Dienste entstanden auch die im folgenden vorgestellten Werkzeuge, welche die Dienstentwicklung stark unterstützen: Microsoft Visual Studio Projektvorlagen für den schnellen Einstieg in die Implementierung eines AXP-Dienstes bzw. eines DNA-Experiments (in.net) Editor für dienstspezifische Parameter (DeploymentDescriptorEditor) für die einfache Erstellung einer Datei mit dienstspezifischen Parametern. Dienstimplementierungsgenerator (DeploymentPackager) für die automatisierte Erstellung einer Dienstimplementierung mit allen erforderlichen Dateien (für AXP- Dienste in.net) Testschnittstelle für AXP-Dienste (AxpServiceInvoker) für das Testen des entwickelten Dienstes direkt in der AXP-Infrastruktur. Darüber hinaus entstand die Klassenbibliothek AxpSupport, welche einen einfachen Zugriff auf die AXP-Funktionen ermöglicht Microsoft Visual Studio Projektvorlagen Funktionsweise Hierbei handelt es sich um eine Microsoft-Visual-Studio- Projektvorlage für einen allgemeinen AXP-Dienst sowie um eine weitere für ein DNA-Experiment, das aus einem Kompilierungsdienst und einem Ausführungsdienst besteht. Die Vorlagen beinhalten jeweils Quelltextgrundgerüste für voll funktionsfähige AXP-Dienste inklusive dienstspezifischen Parametern und einem Postbuild-Ereignis für das Erstellen der Dienstimplementierung (mittels Dienstimplementierungsgenerator). Bei den gegebenen Quelltextgrundgerüsten wäre es denkbar gewesen, dass es eine abstrakte Basisklasse gibt, die bereits alle in genannten Attribute bzw. die für DNA-Experimentdienste benötigten Methodensignaturen enthält. Da jedoch einige Attribute von der vom.net-dienstcontainer verwendete ASPNET ISAPI.DLL nicht aus der gesamten Vererbungshierarchie gelesen werden und eine Basisklasse somit nutzlos machen, beließen wir es bei einem vollständigen Quelltextgrundgerüst. DCL N AXP 49

50 Entwicklung einer transnationalen experimentbasierten Lernumgebung im Leonardo-Da-Vinci-Programm der Europäischen Union Benutzung Die Projektvorlagen bestehen jeweils aus einer ZIP-Datei, welche in das Verzeichnis %Eigene Dateien%\Visual Studio 2005\Templates\ProjectTemplates\ Visual C# kopiert werden müssen. Danach kann man diese im Visual Studio Assistenten Neues Projekt anlegen auswählen Editor für dienstspezifische Parameter Funktionsweise Dieser Editor bietet eine grafische Benutzeroberfläche für die Erstellung und Editierung einer Datei mit dienstspezifischen Parametern (siehe 5.1.4). Der Benutzer kann seine Daten über Eingabefelder eingeben, die Erstellung einer validen XML-Datei geschieht dabei im Hintergrund. Mittels.NET-Reflection werden dabei Daten - falls möglich - schon automatisch ermittelt. Benutzung Es besteht die Möglichkeit, Dateien mit dienstspezifischen Parametern (u. a.) im Microsoft Visual Studio direkt mit dem Editor für dienstspezifische Parameter zu öffnen. Bei der Erstellung einer neuen Datei mit dienstspezifischen Parametern wird man dazu aufgefordert, die.net-assembly mit dem Webdienst auszuwählen, welcher als AXP-Dienst veröffentlicht werden soll. Hat man als nächstes den konkreten Webdiensttyp ausgewählt, werden mehrere Felder automatisch mit den erforderlichen Daten befüllt. Nun kann man alle gewünschten Parameter bearbeiten. Abbildung 9: Erstellung einer Datei mit dienstspezifischen Parametern Dienstimplementierungsgenerator Funktionsweise Um einen.net-axp-dienst installieren zu können, wird eine ZIP- Datei mit mehreren Dateien benötigt: Zunächst werden alle zum Webdienst gehörenden Dateien der Dienstimplementierung hinzugefügt. Hinzu kommt die Datei mit dienstspezifischen Parametern und die zum zu veröffentlichenden Webdienst gehörende (mithilfe der System.Web.Services.Description.ServiceDescription-Klasse generierte) WSDL. Da der.net-dienstcontainer ASP-Dienste anbietet, muss außer- 50 DCL N AXP

51 5 INTEGRATION UND PORTIERUNG VON STEUERUNGSEXPERIMENTEN IN EINE VERTEILTE EXPERIMENTIERUMGEBUNG (DANIEL RICHTER) dem eine ASMX-Datei erstellt und hinzugefügt werden. Auf die Erstellung des ASPspezifischen Ordners für verwendete Assemblies kann verzichtet werden, da der.net- Dienstcontainer dahingehend von mir angepasst wurde. Benutzung Der Dienstimplementierungsgenerator ist eine Konsolenanwendung, die als Parameter den Pfad zur Datei mit den dienstspezifischen Parametern und das Verzeichnis mit den zu verpackenden Dateien entgegennimmt. Als zusätzlichen optionalen Parameter kann der Pfad der zu erstellenden Datei angegeben werden. Durch das Einrichten eines Aufrufs des Dienstimplementierungsgenerators als PostBuild-Ereignis 35 wird auch sofort nach dem Kompilieren des entwickelten Dienstes eine Dienstimplementierung automatisch erstellt Testschnittstelle für AXP-Dienste Funktionsweise Ein Testen der AXP-Dienste ist zum Einen nicht möglich, da Aufrufe an einen AXP-Dienst immer vom AXP-Anfragenbearbeitungsakteur bearbeitet werden (und somit der eigentliche Webdienst nicht direkt aufrufbar ist), zum Anderen verwendet die zum Testen von.net-webdiensten üblicherweise benutzte Browserbenutzungsschnittstelle kein SOAP. Mithilfe der Testschnittstelle für AXP-Dienste kann man - nachdem der entwickelte AXP-Dienst automatisch installiert wurde - dessen Methoden mit frei wählbaren Parametern aufrufen. Zusätzlich sind auch alle AXP-Funktionen, wie WS Resource Properties und WS Resource Lifetime, verfügbar. Schließlich wird der getestete Dienst auch wieder deinstalliert. Zum Starten wird nur eine Dienstimplementierung benötigt. Als erstes wird dieses mittels Dienstinstallationsakteur installiert. War dies erfolgreich, wird anhand der in der Dienstimplementierung enthaltenen 36 WSDL dynamisch ein Proxy für diesen Dienst erstellt. Dazu werden zunächst alle Referenzen aus der WSDL ermittelt 37 und der Dienst in einen DOM-Baum 38 importiert. Da für einen AXP-Dienst-Proxy das WSE 3.0-Paket benutzt werden muss (siehe 5.2.5), muss als nächstes die Basisklasse des Proxies in Microsoft.Web.Services3.WebServicesClientProtocol geändert werden. Zudem wird ein zusätzlicher Konstruktor eingefügt, der eine Microsoft.Web.Services3.Addressing.EndpointReference als Parameter entgegennimmt. Schließlich wird der Quelltext des Proxies aus dem DOM-Baum erzeugt und zur Laufzeit kompiliert im Microsoft Visual Studio: in den Projekteigenschaften in der Registerkarte Buildereignisse bei Befehlszeile für Postbuildereignis einen Aufruf des Dienstimplementierungsgenerators mit den entsprechenden Parametern hinzufügen 36 Der Verwaltungsakteur für logische Dienstexemplare gibt zwar auch eine (vom AXP-WSDL- Generator generierte) WSDL zurück, jedoch kann aus dieser kein.net-proxy generiert werden, weil zusätzliche Methoden von WS Resource Lifetime und WS Resource Properties eingefügt wurden. Da diese Funktionalitäten jedoch über die Klassenbibliothek für den Zugriff auf AXP-Akteure aus.net verfügbar sind, kann auch die lokale WSDL benutzt werden. 37 Funktionalität aus den Namensräumen System.Web.Service.Description und System.Web. Services.Discovery 38 Funktionalität aus dem Namensraum System.CodeDom 39 Funktionalität aus dem Namensraum Microsoft.CSharp DCL N AXP 51

52 Entwicklung einer transnationalen experimentbasierten Lernumgebung im Leonardo-Da-Vinci-Programm der Europäischen Union Nachdem der Webdienst-Proxy erzeugt wurde, wird ein neues Exemplar des installierte AXP-Dienstes durch Verwaltungsakteur für logische Dienstexemplare gebildet. Schließlich werden mit.net-reflection alle (Web-)Methoden des Dienstes ermittelt und in die graphische Benutzungsschnittstelle eingetragen. Wird das Fenster der Testschnittstelle für AXP-Dienste geschlossen, wird der AXP-Dienst automatisch wieder deinstalliert. Abbildung 10: Die Testschnittstelle für AXP-Dienste im Einsatz. Benutzung Ähnlich wie beim Editor für dienstspezifische Parameter besteht auch wieder die Möglichkeit der Parameterübergabe. Im Microsoft Visual Studio ist es somit möglich, die durch ein Postbuild-Ereignis erstellte Dienstimplementierung beim Debuggen direkt an die Testschnittstelle für AXP-Dienste zu übergeben 40 und seinen AXP- Dienst sofort in der AXP-Infrastruktur zu testen. Die in der Benutzungsschnittstelle bereits eingetragenen URLs zum Dienstinstallationsakteur und zum Akteur zur Verwaltung logischer Dienstexemplare können in der app.config-datei geändert werden. 40 in den Projekteigenschaften in der Registerkarte Debuggen bei Externes Programm starten den Pfad zur Testschnittstelle für AXP-Dienste angeben und als Befehlszeilenargument den Pfad zur Dienstimplementierung eintragen 52 DCL N AXP

53 5 INTEGRATION UND PORTIERUNG VON STEUERUNGSEXPERIMENTEN IN EINE VERTEILTE EXPERIMENTIERUMGEBUNG (DANIEL RICHTER) Klassenbibliothek für den Zugriff auf AXP-Akteure aus.net Die Interoperabilität zwischen Java und.net durch Kommunikation über Webdienste funktioniert sehr gut, solange die Typen der Rückgaben bekannt sind (also nur Spezialisierungen statt deren Generalisierungen verwendet werden) und keine besonderen Standards implementiert werden. Da dies bei mehreren AXP-Akteuren nicht der Fall ist, muss teilweise viel Aufwand betrieben werden, um deren gesamte Funktionalität gewährleisten zu können. Mit der Klassenbibliothek für den Zugriff auf AXP-Akteure aus.net ist es möglich, auf Funktionen der Adaptive Execution Platform zuzugreifen. Sie enthält speziell nachbearbeitete Proxies für den Dienstregistrierungsakteur, den Dienst zur Verwaltung logischer Dienstexemplare, WS Resource Properites und WS Resource Lifetime und kümmert sich um Datenkonvertierung und -deserialisierung, sowie um das Werfen spezieller AXP-Ausnahmen. Zudem sind bereits alle Dokumentationstexte von Klassen, Methoden und Parametern für die Nutzung durch z. B. IntelliSense eingebunden. Bei der Erzeugung von Proxies entschieden wir uns, das Web Service Enhancements 3.0-Paket [Fus05] zu benutzen. Nötig machte dies u. a. die Verwendung von WS Addressing (siehe 3.3.3) und dem UsernameToken-Protokolls, was System.Web. Services nicht nativ unterstützt. Zwar wäre die Verwendung der aktuellsten Technologie Microsoft Windows Communication Foundation [Wey06] ebenfalls möglich gewesen. Da dies aber das Microsoft.NET Framework 3.0 voraussetzt, entschieden wir uns für die erstgenannte Lösung. Der Namensraum Axp.Net.Deployment. Die vielen für die Dienstregistrierung nötigen Typen, der Proxy für den Dienstregistrierungsakteur und der Typ für dienstspezifische Parameter wurden u. a. für eine einfachere Benutzung und die Anzeige in einem PropertyGrid bearbeitet. Der Namensraum Axp.Net.ServiceFactory. Die Erzeugung von Quelltext für einen Proxy des Dienstes zur Verwaltung logischer Dienstexemplare gestaltete sich schwierig. Zum einen verweigerten Werkzeuge zur Quelltexterzeugung aufgrund der Verweise auf den Typ WS-Addressing-EndpointReference den Dienst, andererseits kann man den Typ Microsoft.Web.Services3.EndpointReference nicht als Rückgabetyp verwenden. Also musste ein Adapter geschrieben werden, der für eine korrekte Typkonvertierung sorgt. Der Namensraum Axp.Net.WsrLifetime. Da sich aus WSDLs des AXP-WSDL- Generators keine Proxies in.net erzeugen lassen, wird ein Zugriff auf WS- ResourceLifetime-Funktionen [OAS06a] über die Klasse WsrLifetimeService ermöglicht. Auch hier waren wieder manuelle Anpassungen, wie Einträge für WS-Action-Header und die korrekte Serialisierung für Datentypen, nötig. Der Namensraum Axp.Net.WsrProperties. Noch etwas schwieriger als WS Resource Lifetime gestaltete sich Generierung eines Proxies für WS Resource Properties [OAS06b], da dies komplett manuell geschehen musste (selbst in verschiedensten Varianten wollte dies kein einziges Werkzeug für.net ausführen). Die nächste Hürde war, dass der Rückgabetyp der GetResourceProperty-Methode DCL N AXP 53

54 Entwicklung einer transnationalen experimentbasierten Lernumgebung im Leonardo-Da-Vinci-Programm der Europäischen Union den Datentyp xml:any zurückgibt. Da der Inhalt der SOAP-Antwortnachricht keinerlei Rückschlüsse auf den eigentlichen Typ zulässt, wurde jene Methode um einen generischen Typ ergänzt, in den die SOAP-Nachricht deserialiert wird. Zudem ist das anzuwendende Deserialisierungsverfahren ebenfalls nicht bestimmbar, sodass eine Deserialisierung zuerst mit dem zum gewünschten Typ gehörenden Converter versucht wird. Gelingt das nicht, wird der XmlSerializer benutzt. Des Weiteren wurden Methoden für den Zugriff auf bekannte Resource Properties (siehe 3.3.1) eingefügt. Bei Resource Properties mit unbekannten Namen gibt der AXP-WSRP-Anfragenbearbeitungsakteur eine exemplarspezifische Zustandsvariable als byte[] zurück. Diese muss dann - analog zur Serialisierung durch die Zustandspersistierung - als konkreter.net-typ deserialisiert werden. Der Namensraum Axp.Net.Exceptions. Bei der Benutzung von Proxies sind alle von Diensten geworfenen Ausnahmen vom Typ SoapException, in welche die eigentliche Ausnahme gekapselt ist. Die Klasse CustomExceptionFactory bietet die Möglichkeit, die von den AXP-Akteuren definierten Ausnahmen aus einer SoapException zu generieren. Somit werden alle SoapExceptions in den Proxy- Aufrufen abgefangen und in AXP-Ausnahmen umgewandelt. 5.3 Tests Einen wichtigen, manchmal auch unbeliebten 41 Teil der Projektarbeit nahm das Testen ein. Die Tests der einzelnen Komponenten nahm der dafür verantwortliche Programmierer selbst vor, zusätzlich wurde ein Integrationstest geschaffen, welcher das Zusammenspiel möglichst vieler Komponenten überprüfte. Dadurch konnten Fehler auch schnell und leicht erkannt und beseitigt werden. Aufgrund der Kombination von Komponenten verschiedener Implementierer wurden ebenso deren unterschiedliche Vorstellungen von Funktionsweisen offen gelegt, was nicht selten zu angeregten Diskussionen führte. Als Testumgebung wurde für.net-komponenten NUnit 42 in Verbindung mit Test- Driven.NET 43 und für Java-Komponenten JUnit 44 verwendet. TestDriven.NET machte dabei als Microsoft-Visual-Studio-Integration das Testen sehr effizient. Einige Fehler waren aber auch durch Tests nicht leicht aufzudecken. So zum Beispiel die Tatsache, dass ein angebotener.net-webdienst maximal zwei Verbindungen gleichzeitig akzeptiert oder der JAX-WS-Webserver nur maximal fünf Threads für die Verarbeitung zur Verfügung stellt (siehe 3.3.2). Denn Funktionsweise der getesteten Komponente war völlig korrekt: Aufrufe mit höherer Priorität wurden bevorzugt ausgeführt, doch die eigentliche Reihenfolge konnte nur von einem menschlichen Tester als seltsam befunden werden. Insgesamt wurden Tests durchweg als positiv aufgenommen und für nützlich und hilfreich befunden. 41 falls der Testentwickler nicht gleichzeitig der Komponentenentwickler war DCL N AXP

55 5 INTEGRATION UND PORTIERUNG VON STEUERUNGSEXPERIMENTEN IN EINE VERTEILTE EXPERIMENTIERUMGEBUNG (DANIEL RICHTER) 5.4 Ausblick Experimente Das Ziel, die derzeitigen DCL-Experimente zu portieren wurde weitestgehend erreicht. Einzig das Foucault sche Pendel -Experiment konnte nicht als DNA- Experiment verfügbar gemacht werden, da dies aufgrund seiner Komplexität im Rahmen des Bachelorprojektes nicht mehr möglich war. Als neues Experiment kam das LEGO-NXT -Experiment hinzu. Die Steuerung des LEGO-NXT-Roboters geschieht derzeit noch als Fernsteuerung von einer anderen Maschine aus. Eine Ausführung des Experimentsteuerungsprogramms direkt auf der LEGO-NXT-Hardware ist noch nicht möglich, da die Technologie dazu zur Zeit der Experimentimplementierung noch nicht ausgereift genug war. Ebenso gibt es noch kein konkretes Experimentierszenario oder genaue Experimentergebnisse. Weiterführende Arbeiten könnten auch ein Experiment für einen Java- Webdienstverwalter enthalten. Entwicklungswerkzeuge Ein DNA-Experiment- bzw. AXP-Dienstentwickler kann sich während des gesamten Implemetierungsprozesses von Werkzeugen unterstützen lassen, angefangen von Quelltextvorlagen für das Microsoft Visual Studio, über die Erstellung einer Datei für dienstspezifische Parameter und einer Dienstimplementierung, bis zum Test des entwickelten Dienstes direkt in der AXP-Infrastruktur. Der Editor für dienstspezifischen Parameter und die Testschnittstelle für AXP-Dienste funktionieren (mit kleinen Einschränkungen) unabhängig von der Programmiersprache des jeweiligen Dienstes. Erweiterungspotenzial ergibt sich in der Testschnittstelle für AXP-Dienste: Bei der Parametereingabe für aufzurufende Methoden ist derzeit die Eingabe aller Datentypen möglich, die sich aus einem string konvertieren lassen, eine Unterstützung für komplexe Typen oder byte[] wäre denkbar (ebenso die Anzeige der Rückgaben). Auch ist nur das Testen von Diensten möglich, deren Dienstimplementierung vorliegt. Ein möglicher Aufruf bereits installierter Dienste bedarf aber aufgrund der genannten Probleme von.net mit den vom AXP-WSDL-Generator erstellen WSDLs größeren Aufwand. Zudem sind Sicherheitsaspekte - wie die Benutzung des UsernameToken-Protokolls - noch nicht in der Testschnittstelle für AXP-Dienste und der Klassenbibliothek für den Zugriff auf AXP-Akteure aus.net berücksichtigt. DCL N AXP 55

56 Entwicklung einer transnationalen experimentbasierten Lernumgebung im Leonardo-Da-Vinci-Programm der Europäischen Union 6 Portierung von Nutzerschnittstellen für eine verteilte Experimentierumgebung (Peter Kruttke) 6.1 Aufgabenstellung Ziel dieses Teilprojektes war es die vorhandene Nutzungsschnittstelle der DCL Experimentierumgebung auf die Nutzungsschnittstelle des AXP zu portieren. Die vorhandene Nutzerschnittstelle wird im folgenden als DCL-Frontend bezeichnet. Die portierte Nutzerschnittstelle wird als AXP-Frontend bezeichnet. 6.2 Vorgegebenes DCLFrontend Komponenten desdclfrontend Bestandteile des DCL-Frontends waren: DCLWebInterface Das DCLWebinterface diente zur Anzeige der verfügbaren Experimente, konnte Quellcode entgegennehmen und Ergebnisdaten anzeigen. Hierzu benutzte es den DCLExperimentService und den DCLTicketServer, welche wiederum den ResultManager und den Jobmanager für die Ausführung bzw. für das Abrufen der Ergebnisse eines Experiments nutzten. DCLExperiementService Diese Komponente kommunizierte mit dem ExperimentManger um dort die Nutzung eines Experiments anzustoßen, die Position in der Warteschlange eines Experiment abzufragen und den ResultManager um dort die Ergebnisse, die Experimente dort abgespeichert haben, abzufragen. Abfragen wurden jeweils mit einem Ticket, dass der eindeutigen Zuordnung eines Nutzers zu einer Nutzung eines Experiments dient, durchgeführt. Das heißt ein Ticket identifiziert einen Nutzer für die einmalige Nutzung eines bestimmten Experiments. DCLTicketServer Diese Komponente hatte die Aufgabe die oben beschriebenen Tickets zu verwalten und deren Gültigkeit zu prüfen. Im Axp-Frontend wurde das Konzept des Tickets übernommen, da sich der Kontext in dem das Ticket verwendet wird nicht wesentlich geändert hat. Datenbank Die zentrale Datenbank der DCL-Experimentierumgebung verwaltete sämtliche nutzerspezifischen Daten. Darunter fielen Namen, Password, Identifizierungsnummer und Informationen über einem Nutzer. Weiterhin wurde dort auch die Einstellung, welches Aussehen die Nutzerschnittstelle für einen bestimmten Nutzers haben soll, in der Tabelle user-settings, abgelegt. Eine wichtige Tabelle der Datenbank ist experiments. Hier wurden alle in der 56 DCL N AXP

57 6 PORTIERUNG VON NUTZERSCHNITTSTELLEN FÜR EINE VERTEILTE EXPERIMENTIERUMGEBUNG (PETER KRUTTKE) DCL-Experimentieumgebung bereitgestellten Experimente registriert. Die Tabelle jobs registrierte alle, von einem Nutzer, in Benutzung befindlichen Experimente. Das speichern der Tickets geschah in der Tabelle tickets. 6.3 Diskussion der Portierung Die primäre Aufgabe bestand darin, den DCLTicketServer und den DCLExperimentservice, unter Berücksichtigung der bestehenden Funktionalität, an die neue AXP-Experimentierumgebung anzupassen. Hierzu wird zu der Diskussion eine allgemeine Betrachtung vorgenommen und im Anschluss jeder einzelnen Aspekte diskutiert Allgemeine Betrachtung Zu Beginn sei der wichtigste Punkt erwähnt, dass sich ein Experiment im AXP aus einem Erstellung- und Ausführungsdienst zusammensetzt. Der Unterschied zum DCL-Frontend ist, dass das AXP-Frontend kein Wissen über die existierenden Dienste hat. Diese müssen nun durch sporadische oder periodische Anfragen am AXP durch den DeploymentService abgefragt werden. Eine ausführliche Diskussion erfolgt im Abschnitt Ein weiterer zu diskutierender Aspekt ist das Datenbankschema des Axp- Frontends. Aufgrund der veränderten Experimentstrukur kann das vom DCL-Frontend genutzte Schema nicht mehr verwendet werden. Ein weiterer Punkt für die Anpassung ist die Vorgabe eine privilegierten Nutzer einzuführen, der Experimente mit höchster Priorität nutzen kann, sowie ein Problem bei der Abfrage der Ergebnisdaten eines Experiments. Diskutiert wird dies in dem Abschnitt Das Nutzungsverhalten eines Experiments, beschrieben durch die oben benannte Aufteilung, spiegelt sich im wesentlichen in der Methode UseExperiment des DCLExperimentService wieder. Eine Ausführungsstrategie kann vielfach gewählt werden. Hierzu schließt sich wieder eine Diskussion im Abschnitt an. Die Einführung eines Moduses für privilegierte Benutzer, im folgenden privilegierter Modus genannt,der den Erstellungs- und Ausführungsdienst mit der höchsten Priorität ausführt, und die Anzeige der experimentspezifischen Informationen sollten die Gründe für die Anpassungen in der Nutzerschnittstelle sein. Diskutiert wird dies wieder in dem Abschnitt Der Abschnitt Performanz (6.3.8) befasst sich mit der Frage nach dem Aktualisieren der Datenbank und dem Nutzen eines Experiments. Und geht dort näher auf die Frage, warum es die Unterstützung weiterer Werkzeuge geben muss, ein. Weiter Unterpunkte sind Ergebnisdaten im Abschnitt und Sicherheit im Abschnitt Abfrage der Dienste/Speicherung in der Datenbank Die Datenbank hat in diesem Projekt die Aufgabe registrierte Nutzer, Dienstinformationen und die Relation zwischen zwei Diensten zu persistieren. Auch die Tatsache, dass DCL N AXP 57

58 Entwicklung einer transnationalen experimentbasierten Lernumgebung im Leonardo-Da-Vinci-Programm der Europäischen Union es in der Nutzerschnittstelle seitenübergreifende Informationen an zu zeigen gibt und die im Abschnitt vorgestellt Komponente, die auf Daten der Datenbank angewiesen ist, macht die Nutzung einer Datenbank erforderlich. Die Abfrage der im AXP vorhandenen Dienste geschieht durch die Methode ListExperiments des DeploymentService. Diese Methode ist die einzige Informationsquelle eines AXP-Frontends, die Informationen von Dienste bereit stellt. Als Rückgabe wird ein Liste des Typs ServiceInfo zurück gegeben, die alle verfügbaren Dienste repräsentiert und alle Attribute mitliefert die zur Identifikation eines Experiment d.h. dessen Erstellungs- und Ausführungsdienst dienen. Die Attribute sind ServiceId,Name,Description und eine Reihe im Deploymentdescriptor definierten Attribut-Wert-Paare. Die Attribut-Wert-Paare werden als Liste des Typs ServiceProperty in der Klasse ServiceInfo, der die Zeichenketten Name und Value enthält, gekapselt. In der Klasse ServiceInfo wird jedem Name-Attribut ein Value-Wert eindeutig zugeordnet. Die Identifikation des Erstellungs- und Ausführungsdienstes erfolgt durch die Prüfung des Namens auf den Inhalt compil. Ist das nicht der Fall wird angenommen,dass der Dienst ein Ausführungsiondienst ist. Zugehörigkeit von Erstellungs- und Ausführungsdienst wird durch eine Übereinstimmung von dessen Wert, mit dem Attribut ExperimentType, bestimmt. Damit bei der Experimentnutzung das Wissen um die Zugehörigkeit zweier Dienste nicht verloren geht, muss dies in das Datenbankschema aufgenommen werden. So wird die neue Tabelle service order in das Datenbankschema aufgenommen. Eine Erweiterung des DCLTicketServers durch die Methode InsertServicePair(string id1, string id2) ermöglicht das Einfügen dieser Dienstordnung. Weitere Attribut-Wert-Paare sind unter anderem: ImageUrl: Der Pfad zu dem, in der Listung der Experimente angezeigtem, Bild. Location: Der Standort an dem sich das Experiment befindet. ManualUrl: Der Pfad zu dem Dokument, dass eine Beschreibung des Experiments enthält. SampleCode: Eine Beispielanwendung eines Experiment in Form von Quellcode. RenderTypes: Enthält die darzustellenden Ergbnistypen. Alle hier angeführten Attribut-Wert-Paare und die Attribute ServiceId, Name und Description haben ihre spezifische Bedeutung für die Nutzerschnittstelle und werden deshalb mit in die Datenbank und das entsprechende Datenbankschema aufgenommen. Die Schnittstellenerweiterung des TicketServers mit der Methode Listing 10: Einfügen eines Dienstes 1 void InsertAxpExperiment(string experimentname,string propertyname,string id,string description, string foreignkey,string manualurl,string samplecode,string imageurl,string rendertypes,string location) 58 DCL N AXP

59 6 PORTIERUNG VON NUTZERSCHNITTSTELLEN FÜR EINE VERTEILTE EXPERIMENTIERUMGEBUNG (PETER KRUTTKE) stellt dies sicher. Die Aktualisierung der Datenbank, die nicht wie im DCL durch eine externe Komponente angestoßen wurde, muss als Methode im DCLExperimentService enthalten sein, die die abgerufenen Dienste analysiert und in die Datenbank einfügt. Die Anstossung der Aktualisierung wird in den Abschnitten und diskutiert. Listing 11: Abfrage der Dienste am DeploymentService 1 [WebService(Namespace = "http://dcl.hpi.uni-potsdam.de/dclv21")] 2 public class DCLExperimentService : System.Web.Services.WebService 3 { 4 //... 5 private DeploymentService deploymentservice = new DeploymentService( deploymentserviceip); 6 7 [WebMethod] 8 public string[] UpdateExperimentDatabase() 9 { 10 ServiceInfo[] services = deploymentservice.listservices(); 11 // //Analyse der Dienste 13 // for (int i = 0; i < experiments.count; i++) 15 { 16 // ticketmref.insertaxpexperiment(expname1, experiemnttype, id, description, foreignkey, manualurl, samplecode, imageurl, rendertypes, location); 18 } 19 } 20 } Da durch die Beibehaltung der Schnittstelle des DCLExperimentServices und die Methode ListExperiments unverändert bleiben soll, muss es einen Mechanismus geben der auf effizente Art und Weise, die Namen der Experimente zurück gibt. Hierzu wird das Datenbankschema durch die Tabelle start services ergänzt, in der die Dienstidentifikationsnummer der Erstellungsdienste enthalten sind. Die Schnittstelle des TicketServers wird durch die Methode string[] GetStartServiceNames() erweitert, die durch eine SQL-Abfrage in den Tabellen axp services und start services durchführt und die Namen der zu nutzenden Erstellungsdienste zurück gibt. Listing 12: Abfrage der Erstellungsdienste 1 [WebService(Namespace = "http://dcl.hpi.uni-potsdam.de/dclv21")] 2 public class DCLExperimentService : System.Web.Services.WebService 3 { 4 //... 5 [WebMethod] 6 public string[] ListExperiments() 7 { 8 try 9 { 10 return ticketmref.getstartservicenames(); 11 } DCL N AXP 59

60 Entwicklung einer transnationalen experimentbasierten Lernumgebung im Leonardo-Da-Vinci-Programm der Europäischen Union 12 catch (Exception e) 13 { 14 throw new SoapException("Error in ListExperiments : " + e. ToString(), SoapException.ServerFaultCode); 15 } 16 } 17 } Datenbankschema Die im vorhergehenden Abschnitt neu eingeführten Tabellen service order, start services und start services, sowie die folgenden Gründe sind Gründe für die Überarbeitung des Datenbankschemas. Die Einführung eines privilegiert Moduses brachte es mit sich eine neue Tabelle in das Schema einzufügen die alle Nutzeridentifikationsnummern enthält, die einen privilegierten Nutzer kennzeichnen. Diese Tabelle soll super user heißen. Die vorhandene Tabelle users wird durch das Feld priority ergänze. Diese Änderung musste im Zuge der Anforderungen einem Nutzer eine Priorität zuzuordnen ge- macht werden. Die wichtigste Einführung ist die Tabelle ticket service id mapping mit den Feldern ticket, service_id, result_id, endpoint und priority. Sie ist bei der Ausführung eines Experiments wichtig um den Ausführungsschlüssel zu speichern, die dem Ausführungsdienst mitgegeben wird um die vorab erstellten Ausführungsdateien zu identifizieren und auszuführen. Das Feld endpoint speichert die serialisierte Repräsentation der EndPointReference eines Dienstes. Dieses Feld ist notwendig um beim WsrPropertiesService den Status oder die Ergebnisdaten eines Experiments abzufragen. Die Priorität in dieser Tabelle ist entweder die dem Nutzer zugeordnete oder die höchste, wenn der privilegierte Modus verwendet wird. Der zweite Grund für die Speicherung ist, dass der Erstellungs- und Ausführungsdienst mit der gleichen Priorität ausgestattet werden sollen Experimentnutzung Die Benutzung eines Experiments, d.h. die sequenzielle Benutzung des Erstellungsund Ausführungsdienstes, wird durch die Nutzerschnittstelle angestoßen. Hierzu wird die Methode UseExperiment in der Klasse DCLExperimentService aufgerufen. Zuvor wurde im Frontend ein Ticket generiert. Dieses Ticket, der Quellcode, der Name des Experiments sowie die Priorität werden als Parameter der Methode UseExperiment mitgegeben. Die Dienstidentifikationsnummer wird über die Schnittstellenerweiterung string GetCompileIdFromServiceName(string name) des DCLTicketServers angefordert. Eingeleitet wird die Benutzung eines Experiments durch das Instanziieren der Stellvertreterklasse (Proxy) des Erstellungsdienstes. Als Übergabeparameter erhält der Konstruktor eine EndpointReference, die von dem ServiceFactoryService über die Dienstidentifikationsnummer und der Priorität, mit dem der Dienst ausgeführt werden soll, über die Methode createserviceinstance angefordert wird. Als nächstes muss 60 DCL N AXP

61 6 PORTIERUNG VON NUTZERSCHNITTSTELLEN FÜR EINE VERTEILTE EXPERIMENTIERUMGEBUNG (PETER KRUTTKE) Abbildung 11: Die neue Datenbankstruktur des AXP-Frontends die TerminationTime des Dienstes gesetzt werden. Dies geschieht durch die Methode SetTerminationTime die als Übergabeparameter einen Zeitstempel oder eine Zeitspanne entgegen nimmt. Auch hier wird beim Instanziieren des Konstruktors der Klasse WsrLifetimeService die EndpointReference des Dienstes übergeben. Es werden später, vor dem Erstellungs- und Ausführungsvorgang, noch ein Usernametoken angefügt, dessen Bedeutung wird im Abschnitt behandelt. Im folgenden gehe ich davon aus, dass die Aufruflogik eines Experiments in einer dem AXP-Frontend fremden Komponente ausgeführt wird. Wurde die Gültigkeit eines Tickets überprüft, kann davon ausgegangen werden, dass das Experiment einem Nutzer zugeordnet ist. Nun muss einem Ticket ein Dienst zugeordnet werden. Speziell hier dem Erstellungsdienst. Dabei werden die im Abschnitt diskutierten Felder der Tabelle ticket service id mapping belegt. Dies geschieht durch die Schnittstellenerweiterung BindTicketToServiceId(string ticket, string serviceid, string reference,int priority). Der folgende Aufruf der Methode Compile(string code) des Erstellungsdienstes gibt einen Zeichenkette zurück, die den Ausführungsschlüssel enthält. Die Bedeutung wurde im Abschnitt verdeutlicht. Eine weitere berechtigte Frage, warum es eine Speicherung der EndpointReference geben muss, ist die Tatsache, dass die Nutzerschnittstelle sofort nach der Anstossung des Experiments auf die Seite mit der Listung der in Benutzung oder benutzen Experimente zurückkehrt um dort den Zustand eines Experiments anzuzeigen. Diese Anzeigedaten, darunter der Zustand, werden unter Benötigung der Endpointreference im DCLExperiementService abgefragt. Wurde der Erstellungsvorgang erfolgreich abgeschlossen, kann der Vorgang der Ausführung eingeleitet werden. Der Eintrag in die Tabelle ticket service id mapping bleibt vorhanden, da bei einem Fehler die Fehlerdaten als Ergebnis zurückgegeben werden. Für den folgenden Erstellungsdienst wird bei der Anfrage an dem DCL N AXP 61

Zustandsgebundene Webservices

Zustandsgebundene Webservices Zustandsgebundene Webservices Präsentation ausgewählter Problemstellungen der Informatik Markus Oertel oer@uni-paderborn.de Universität Paderborn 25. September 2005 Zustandsgebundene Webservices Seite

Mehr

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 Software Testing Automatisiert Manuell 100% 70% 1 Überwiegender Teil der Testing Tools fokusiert auf automatisiertes Testen Microsoft

Mehr

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com Web Services Java Praktikum SS 2010 Gerald.Ehmayer@borland.com 1 Web Services Einführung Definition, Eigenschaften, Anwendungen... JAX-RPC Überblick, Architektur... JAX Übersicht, Architektur Java Praktikum

Mehr

Java Web Services mit Apache Axis2 Entwickler

Java Web Services mit Apache Axis2 Entwickler Thilo Frotscher, Dapeng Wang, Marc Teufel Java Web Services mit Apache Axis2 Entwickler Vorwort 15 1 Einleitung 25 1.1 Entstehung 26 1.2 Unterstützte Standards 28 1.3 Was beinhaltet Axis2? 29 1.4 Warum

Mehr

White Paper. Embedded Treiberframework. Einführung

White Paper. Embedded Treiberframework. Einführung Embedded Treiberframework Einführung White Paper Dieses White Paper beschreibt die Architektur einer Laufzeitumgebung für Gerätetreiber im embedded Umfeld. Dieses Treiberframework ist dabei auf jede embedded

Mehr

Web Service Entwicklung mit Java. Sven Lindow

Web Service Entwicklung mit Java. Sven Lindow Web Service Entwicklung mit Java Sven Lindow 22.11.2006 Agenda Einleitung SOAP, REST, WSDL, UDDI Web Services mit Java JWSDP JAX-RPC, JAX-WS 2.0 AXIS, AXIS2 Web Services nutzen Google, Ebay Web Services

Mehr

5. Übung zur Vorlesung Service-orientierte Architekturen

5. Übung zur Vorlesung Service-orientierte Architekturen 5. Übung zur Vorlesung Service-orientierte Architekturen Webservices und WSDL SoSe 2011 Anmerkung Hausaufgabe 03 BPMN Auch hier gilt: Layout! Zu Unterschieden zw. BPMN und eepk Relative Aussagen sind geschickter

Mehr

Web Services mit Java

Web Services mit Java Web Services mit Java Neuentwicklung und Refactoring in der Praxis Torsten Langner new technology Markt+Technik Verlag Inhaltsverzeichnis Vorwort 13 Warum ausgerechnet dieses Buch? 13 An wen richtet sich

Mehr

POIS-Praktikum 2007. Prozessimplementierung, RosettaNet PIPs 3A

POIS-Praktikum 2007. Prozessimplementierung, RosettaNet PIPs 3A POIS-Praktikum 2007 Prozessimplementierung, RosettaNet PIPs 3A Manuel Blechschmidt, David Foerster, Michael Leben, Mike Nagora, Jonas Rogge, Paul Römer Gliederung 2 Einleitung Was war unsere Aufgabe? Was

Mehr

Grundlagen des Grid Computing

Grundlagen des Grid Computing Grundlagen des Grid Computing Webservices und Grid Computing Globus Toolkit 4 - Grundlagen ICA Joh.. Kepler Universität t Linz Eine Typische Grid-Applikation (Beispiel) VO Management Service Resource Discovery

Mehr

Web-Services Implementierung mit Java

Web-Services Implementierung mit Java Web-Services Implementierung mit Java J. Heinzelreiter WS 2004/05 Java-APIs für Web-Services (1) Anwendungs-Code JAXR JAXM JAX-RPC SAAJ SOAP/SwA JWSDL WSDL XML/XML-Schema Web-Services/Java - 2 Java-APIs

Mehr

.NET-Networking 2 Windows Communication Foundation

.NET-Networking 2 Windows Communication Foundation .NET-Networking 2 Windows Communication Foundation Proseminar Objektorientiertes Programmieren mit.net und C# Fabian Raab Institut für Informatik Software & Systems Engineering Agenda Grundproblem Bestandteile

Mehr

0. Inhaltsverzeichnis

0. Inhaltsverzeichnis 0. Inhaltsverzeichnis 0. Inhaltsverzeichnis...1 1. Kurze Einführung WebService Architektur...2 1.1 Synchrones Modell:...2 1.2 Asynchrones Modell:...2 1.3 Vorteile:...3 1.4 Voraussetzungen...3 2. Testseite

Mehr

Business Process Execution Language. Christian Vollmer Oliver Garbe

Business Process Execution Language. Christian Vollmer <christian.vollmer@udo.edu> Oliver Garbe <oliver.garbe@udo.edu> Business Process Execution Language Christian Vollmer Oliver Garbe Aufbau Was ist BPEL? Wofür ist BPEL gut? Wie funktioniert BPEL? Wie sieht BPEL aus?

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

Technische Beschreibung: EPOD Server

Technische Beschreibung: EPOD Server EPOD Encrypted Private Online Disc Technische Beschreibung: EPOD Server Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee JKU Linz Institut für

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

Softwareentwicklung mit Enterprise JAVA Beans

Softwareentwicklung mit Enterprise JAVA Beans Softwareentwicklung mit Enterprise JAVA Beans Java Enterprise Edition - Überblick Was ist J2EE Java EE? Zunächst mal: Eine Menge von Spezifikationen und Regeln. April 1997: SUN initiiert die Entwicklung

Mehr

Spezifikationen und Voraussetzung

Spezifikationen und Voraussetzung Projekt IGH DataExpert Yellowbill Adapter Spezifikationen Voraussetzungen Datum : 22.08.2013 Version : 1.0.0.2 22.08.2013 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung...3 2 Architektur...3 2.1 Grundsätze

Mehr

Entwicklung von Web-Anwendungen auf JAVA EE Basis

Entwicklung von Web-Anwendungen auf JAVA EE Basis Entwicklung von Web-Anwendungen auf JAVA EE Basis Java Enterprise Edition - Überblick Prof. Dr. Bernhard Schiefer Inhalt der Veranstaltung Überblick Java EE JDBC, JPA, JNDI Servlets, Java Server Pages

Mehr

Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung. Klaus Kusche, September 2014

Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung. Klaus Kusche, September 2014 Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung Klaus Kusche, September 2014 Inhalt Ziel & Voraussetzungen Was sind abstrakte Datentypen? Was kann man damit grundsätzlich?

Mehr

Eclipse Equinox als Basis für Smart Client Anwendungen. Christian Campo, compeople AG, 5.7.2007 Java Forum Stuttgart 2007

Eclipse Equinox als Basis für Smart Client Anwendungen. Christian Campo, compeople AG, 5.7.2007 Java Forum Stuttgart 2007 Eclipse Equinox als Basis für Smart Client Anwendungen Christian Campo, compeople AG, 5.7.2007 Java Forum Stuttgart 2007 Übersicht Definition / Architektur Smart Client Smart Client mit RCP / Equinox Gesamtfazit

Mehr

Dokumentation zum Projekt Mail-Adapter in SAP PI. 17.01.2011 Sinkwitz, Sven 519707 Theel, Thomas 519696

Dokumentation zum Projekt Mail-Adapter in SAP PI. 17.01.2011 Sinkwitz, Sven 519707 Theel, Thomas 519696 Dokumentation zum Projekt Mail-Adapter in SAP PI 17.01.2011 Sinkwitz, Sven 519707 Theel, Thomas 519696 Inhalt 1. Einleitung... 2 2. Vorgehen... 3 1. Datentyp für die Mail einrichten... 3 2. Message Typen

Mehr

Etablierung serviceorientierter Architekturen mit Web Services

Etablierung serviceorientierter Architekturen mit Web Services Etablierung serviceorientierter Architekturen mit Web Services Vorlesung im (Entwicklung von Serviceangeboten) 1 Agenda Einsatzbereiche von Web Service basierten Angeboten Übersicht zur Java-System Application

Mehr

PowerBridge MSSQL Beta

PowerBridge MSSQL Beta SoftENGINE PowerBridge MSSQL Beta Dokumentation Thomas Jakob 17.04.2011 Inhalt Einrichtung der SQL Umgebung... 3 SQL-Server Installieren... 3 BüroWARE Installieren... 3 PowerBridge-SQL Modus einrichten...

Mehr

Spezifikationen und Voraussetzung

Spezifikationen und Voraussetzung Projekt IGH DataExpert Paynet Adapter Spezifikationen Voraussetzungen Datum : 21.07.08 Version : 1.0.0.2 21.07.2008 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung... 3 2 Architektur... 3 2.1 Grundsätze

Mehr

Dataport IT Bildungs- und Beratungszentrum. HTML- Grundlagen und CSS... 2. XML Programmierung - Grundlagen... 3. PHP Programmierung - Grundlagen...

Dataport IT Bildungs- und Beratungszentrum. HTML- Grundlagen und CSS... 2. XML Programmierung - Grundlagen... 3. PHP Programmierung - Grundlagen... Inhalt HTML- Grundlagen und CSS... 2 XML Programmierung - Grundlagen... 3 PHP Programmierung - Grundlagen... 4 Java - Grundlagen... 5 Java Aufbau... 6 ASP.NET Programmierung - Grundlagen... 7 1 HTML- Grundlagen

Mehr

... Einleitung... 15. 3... Prozessintegration und Integrationsszenarien... 127 3.1... Integrationsszenariomodelle... 128

... Einleitung... 15. 3... Prozessintegration und Integrationsszenarien... 127 3.1... Integrationsszenariomodelle... 128 ... Einleitung... 15 1... Grundlagen der Modellierung von Enterprise Services... 23 1.1... Serviceorientierte Architekturen... 26 1.1.1... Merkmale serviceorientierter Architekturen... 27 1.1.2... SOA

Mehr

Workflow, Business Process Management, 4.Teil

Workflow, Business Process Management, 4.Teil Workflow, Business Process Management, 4.Teil 24. Januar 2004 Der vorliegende Text darf für Zwecke der Vorlesung Workflow, Business Process Management des Autors vervielfältigt werden. Eine weitere Nutzung

Mehr

Web Services: Inhalt

Web Services: Inhalt Web Services Fachseminar Verteilte Systeme 8. April 2002 - Marco Steiner Assistent: Thomas Schoch Professor: Dr. F. Mattern Web Services: Inhalt Bedeutung Gegenwart Architektur SOAP WSDL UDDI Vergleich

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

Neuerungen Analysis Services

Neuerungen Analysis Services Neuerungen Analysis Services Neuerungen Analysis Services Analysis Services ermöglicht Ihnen das Entwerfen, Erstellen und Visualisieren von Data Mining-Modellen. Diese Mining-Modelle können aus anderen

Mehr

Java API for XML Binding

Java API for XML Binding Java API for XML Binding Eine Einführung Tim Speier Fachbereich MNI Fachhochschule Gießen-Friedberg 24. Juni 2010 1 / 27 XM und Java Teil 1: Aufgabenstellung Aufgabenstellung: In einem XML-Dokument werden

Mehr

17 Komponentenbasiertes Software-Engineering

17 Komponentenbasiertes Software-Engineering 17 Komponentenbasiertes Software-Engineering 17.0 Einführung Lernziele Grundlagen, Prinzipien und Probleme des CBSE 17.1 Komponenten und Komponentenmodelle Komponenten und ihre Eigenschaften Komponentenmodelle

Mehr

SAP NetWeaver Gateway. Connectivity@SNAP 2013

SAP NetWeaver Gateway. Connectivity@SNAP 2013 SAP NetWeaver Gateway Connectivity@SNAP 2013 Neue Wege im Unternehmen Neue Geräte und Usererfahrungen Technische Innovationen in Unternehmen Wachsende Gemeinschaft an Entwicklern Ausdehnung der Geschäftsdaten

Mehr

Hauptseminar Internetdienste Prof. F. Schweiggert Sommersemester 2004 Universität Ulm. Web Services. Boto Bako

Hauptseminar Internetdienste Prof. F. Schweiggert Sommersemester 2004 Universität Ulm. Web Services. Boto Bako Hauptseminar Internetdienste Prof. F. Schweiggert Sommersemester 2004 Universität Ulm Web Services Boto Bako Inhaltsverzeichnis 1.Einführung und Motivation...3 2.Verwendete Standards...4 2.1.SOAP...5 2.2.WSDL...6

Mehr

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. WebSphere Application Server Teil 4

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. WebSphere Application Server Teil 4 UNIVERSITÄT LEIPZIG Mainframe Internet Integration Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013 WebSphere Application Server Teil 4 Leistungsverhalten el0100 copyright W. G. Spruth,

Mehr

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

Mehr

JAXR Java API for XML Registries. Jasmin Hatteh

JAXR Java API for XML Registries. Jasmin Hatteh JAXR Java API for XML Registries Jasmin Hatteh Übersicht Web Service Architektur Rollenverteilung Interaktionen Business-Registry UDDI ebxml JAXR Architektur Interaktionen Pakete Was sind Web Services?

Mehr

Server Installation 1/6 20.10.04

Server Installation 1/6 20.10.04 Server Installation Netzwerkeinrichtung Nach der Installation müssen die Netzwerkeinstellungen vorgenommen werden. Hierzu wird eine feste IP- Adresse sowie der Servername eingetragen. Beispiel: IP-Adresse:

Mehr

Auszug aus Axis2 Schulung

Auszug aus Axis2 Schulung Auszug aus Axis2 Schulung Dieses Dokument ist ein Auszug aus unserem Skript zur Axis2- Schulung. Es dient lediglich als Beispiel für unsere Kursunterlagen. Thomas Bayer Hauptstraße 33 75050 Gemmingen Mehr

Mehr

A Generic Database Web Service for the Venice Lightweight Service Grid

A Generic Database Web Service for the Venice Lightweight Service Grid A Generic Database Web Service for the Venice Lightweight Service Grid Michael Koch Bachelorarbeit Michael Koch University of Kaiserslautern, Germany Integrated Communication Systems Lab Email: m_koch2@cs.uni-kl.de

Mehr

ServiceGlobe: Flexible and Reliable Web Service Execution

ServiceGlobe: Flexible and Reliable Web Service Execution ServiceGlobe: Flexible and Reliable Web Service Execution Markus Keidl, Stefan Seltzsam und Alfons Kemper Universität Passau Fakultät für Mathematik und Informatik 94030 Passau @db.fmi.uni-passau.de

Mehr

Friedrich. Kiltz. Java Webservices

Friedrich. Kiltz. Java Webservices Friedrich Kiltz Java Webservices Symbole.NET 379 @Action 279, 423 @Addressing 372 @BindingType 416 @Consumes 87 @Context 82, 88 @CookieParam 82, 88 @DefaultValue 82, 88 @DELETE 87 @Encoded 82, 88 @Endpoint

Mehr

Grid Computing. Einführung. Marc Lechtenfeld. Seminar Grid Computing Sommersemester 2004 Universität Duisburg-Essen

Grid Computing. Einführung. Marc Lechtenfeld. Seminar Grid Computing Sommersemester 2004 Universität Duisburg-Essen * Grid Computing Einführung Marc Lechtenfeld Seminar Grid Computing Sommersemester 2004 Universität Duisburg-Essen Übersicht 1 Problematik 2 Systemanforderungen 3 Architektur 4 Implementation 5 Projekte

Mehr

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen 9 3 Web Services 3.1 Überblick Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen mit Hilfe von XML über das Internet ermöglicht (siehe Abb.

Mehr

Vorbereitung zu Praktikum 3

Vorbereitung zu Praktikum 3 Vorbereitung zu Praktikum 3 Menü-Toolkit und Command Pattern Fallstudie zu Vererbung und Polymorphie: "Menü-Toolkit" Anwenderfreundliche Programme werden mit Menüs gesteuert In objektorientierten Anwendungen

Mehr

Apache Tomcat. Inhalt. Rechner und Netzarchitektur SS 2003. Einleitung. Architektur

Apache Tomcat. Inhalt. Rechner und Netzarchitektur SS 2003. Einleitung. Architektur Apache Tomcat Rechner und Netzarchitektur SS 2003 Johannes Jabornig Daniel Peintner Inhalt Einleitung Was sind Servlets und JSP Vorteile Architektur Catalina Jasper Konnektoren Installation / Konfiguration

Mehr

Dynamische Plug-ins mit Eclipse 3. Martin Lippert (martin.lippert@it-agile.de, www.it-agile.de) Tammo Freese (freese@acm.org)

Dynamische Plug-ins mit Eclipse 3. Martin Lippert (martin.lippert@it-agile.de, www.it-agile.de) Tammo Freese (freese@acm.org) Dynamische Plug-ins mit Eclipse 3 Martin Lippert (martin.lippert@it-agile.de, www.it-agile.de) Tammo Freese (freese@acm.org) Überblick Die Ausgangslage Dynamische Plug-ins Warum? Eclipse 3 Die OSGi-basierte

Mehr

Remote Communications

Remote Communications HELP.BCFESDEI Release 4.6C SAP AG Copyright Copyright 2001 SAP AG. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher

Mehr

Oracle Business Process Analysis Suite. Gert Schüßler Principal Sales Consultant

<Insert Picture Here> Oracle Business Process Analysis Suite. Gert Schüßler Principal Sales Consultant Oracle Business Process Analysis Suite Gert Schüßler Principal Sales Consultant 1 Geschäftsprozesse Zerlegung am Beispiel Kreditvergabe Antrag aufnehmen Antrag erfassen Schufa Kunden

Mehr

Merkblatt: HSM. Version 1.01. Systemvoraussetzungen, Setup und Trouble Shooting. pdfsupport@pdf-tools.com

Merkblatt: HSM. Version 1.01. Systemvoraussetzungen, Setup und Trouble Shooting. pdfsupport@pdf-tools.com Merkblatt: HSM Version 1.01 Systemvoraussetzungen, Setup und Trouble Shooting Kontakt: pdfsupport@pdf-tools.com Besitzer: PDF Tools AG Kasernenstrasse 1 8184 Bachenbülach Schweiz www.pdf-tools.com Copyright

Mehr

KompaSbilität zu Standards (WS- I) Contracts. Interfaces und Generics Umfangreiche AXribuSerung. Mehr Spielraum auf Transportebene

KompaSbilität zu Standards (WS- I) Contracts. Interfaces und Generics Umfangreiche AXribuSerung. Mehr Spielraum auf Transportebene Komponenten WCF (.NET Framework) WCF Verfeinerung und Reifung der ursprünglichen Version Geringere Unterschiede zu ASMX 2.0 (.NET 2.0) + WSE 3.0 Schwerpunkte KompaSbilität zu Standards (WS- I) Contracts

Mehr

Message Oriented Middleware am Beispiel von XMLBlaster

Message Oriented Middleware am Beispiel von XMLBlaster Message Oriented Middleware am Beispiel von XMLBlaster Vortrag im Seminar XML und intelligente Systeme an der Universität Bielefeld WS 2005/2006 Vortragender: Frederic Siepmann fsiepman@techfak.uni bielefeld.de

Mehr

Java Batch Der Standard für's Stapeln

Java Batch Der Standard für's Stapeln Java Batch Der Standard für's Stapeln Berlin Expert Days 18.09.2015 Dirk Weil, GEDOPLAN GmbH Dirk Weil GEDOPLAN GmbH, Bielefeld GEDOPLAN IT Consulting Konzeption und Realisierung von IT-Lösungen GEDOPLAN

Mehr

Web Services Monitoring

Web Services Monitoring Web Services Monitoring Foliensatz zum Vortrag von der OIO Hauskonferenz am 17. Dezember 2009 predic8 GmbH Moltkestr. 40 53173 Bonn www.predic8.de info@predic8.de Ihr Sprecher Thomas Bayer Trainer, Berater,

Mehr

Das Knowledge Grid. Eine Architektur für verteiltes Data Mining

Das Knowledge Grid. Eine Architektur für verteiltes Data Mining Das Knowledge Grid Eine Architektur für verteiltes Data Mining 1 Gliederung 1. Motivation 2. KDD und PDKD Systeme 3. Knowledge Grid Services 4. TeraGrid Projekt 5. Das Semantic Web 2 Motivation Rapide

Mehr

Kundenanforderungen. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 24.05.2013

Kundenanforderungen. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 24.05.2013 Software Komponenten FS13 Gruppe 03 Horw, 24.05.2013 Bontekoe Christian Estermann Michael Moor Simon Rohrer Felix Autoren Bontekoe Christian Studiengang Informatiker (Berufsbegleitend) Adresse Telefon

Mehr

Innovator 11 excellence. DDL importieren. Data-Definition-Language-Dateien in Datenbankschema importieren. HowTo. www.mid.de

Innovator 11 excellence. DDL importieren. Data-Definition-Language-Dateien in Datenbankschema importieren. HowTo. www.mid.de Innovator 11 excellence DDL importieren Data-Definition-Language-Dateien in Datenbankschema importieren HowTo www.mid.de Zweck In Innovator Data excellence können Sie mit dem DDL-Import Ihr physisches

Mehr

Konzept eines Datenbankprototypen. 30.06.2003 Folie 1 Daniel Gander / Gerhard Schrotter

Konzept eines Datenbankprototypen. 30.06.2003 Folie 1 Daniel Gander / Gerhard Schrotter Konzept eines Datenbankprototypen 30.06.2003 Folie 1 Daniel Gander / Gerhard Schrotter Inhalt (1) Projektvorstellung & Projektzeitplan Softwarekomponenten Detailierte Beschreibung der System Bausteine

Mehr

Vorteile von Java und Konvergenz Service Creation mit JAIN Network Management mit JMX Fazit

Vorteile von Java und Konvergenz Service Creation mit JAIN Network Management mit JMX Fazit Hochschule für Technik und Architektur Chur Dr. Bruno Studer Studienleiter NDS Telecom, FH-Dozent bruno.studer@fh-htachur.ch 1 GSM: 079/610 51 75 Agenda Vorteile von Java und Konvergenz Service Creation

Mehr

Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft

Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft Harald Lange sd&m Lübecker Str. 1 22087 Hamburg harald.lange@sdm.de Abstract: Mit der Einführung eines Buchungs-

Mehr

Praktikum Internetprotokolle - POP3

Praktikum Internetprotokolle - POP3 Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik/Rechnernetze 19. Mai 2008 1 Aufgabenstellung Praktikum

Mehr

PrintTalk 2.0, XJDF & WebToPrint

PrintTalk 2.0, XJDF & WebToPrint PrintTalk 2.0, XJDF & WebToPrint Referent: Stefan Meissner (s.meissner@flyeralarm.de) CIP4 Chairman Tools & Infrastructure WG CIP4 Chairman XJDF WG Vernetzung in der Grafischen Industrie. CIP4 & WEB TO

Mehr

Howto. Konfiguration eines Adobe Document Services

Howto. Konfiguration eines Adobe Document Services Howto Konfiguration eines Adobe Document Services (ADS) Inhaltsverzeichnis: 1 SYSTEMUMGEBUNG... 3 2 TECHNISCHE VERBINDUNGEN ZWISCHEN DEN SYSTEMEN... 3 2.1 PDF BASIERENDE FORMULARE IN DER ABAP UMGEBUNG...

Mehr

Java und XML/XML und Java. Mario Jeckle DaimlerChrysler Forschungszentrum Ulm mario.jeckle@daimlerchrysler.com mario@jeckle.de www.jeckle.

Java und XML/XML und Java. Mario Jeckle DaimlerChrysler Forschungszentrum Ulm mario.jeckle@daimlerchrysler.com mario@jeckle.de www.jeckle. Java und XML/XML und Java Mario Jeckle DaimlerChrysler Forschungszentrum Ulm mario.jeckle@daimlerchrysler.com mario@jeckle.de www.jeckle.de XML und Programmiersprachen... Java ist... Programmiersprache

Mehr

PIWIN I. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler I. Vorlesung 3 SWS WS 2007/2008

PIWIN I. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler I. Vorlesung 3 SWS WS 2007/2008 PIWIN I Kap. 7 Objektorientierte Programmierung - Einführung 1 PIWIN I Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler I Vorlesung 3 SWS WS 2007/2008 FB Informatik

Mehr

Abschlussvortrag zur Bachelorarbeit. Konzeption und Aufbau eines Grid Testlabors am Beispiel des Globus Toolkit 4

Abschlussvortrag zur Bachelorarbeit. Konzeption und Aufbau eines Grid Testlabors am Beispiel des Globus Toolkit 4 Abschlussvortrag zur Bachelorarbeit Konzeption und Aufbau eines Grid Testlabors am Beispiel des Globus Toolkit 4 Halit Alagöz Fachgebiet Distributed Virtual Reality (DVR) Lehrgebiet Rechnernetze H. Alagöz

Mehr

EAI - Enterprise Application Integration

EAI - Enterprise Application Integration EAI - Enterprise Application Integration Jutta Mülle WS 2005/2006 EAI - Folie 1 Überblick und Begriffsbildung Zusammenfassung und Ausblick hinweise EAI - Folie 2 Conclusion EAI Enterprise Application Integration

Mehr

Objektorientierte Programmierung. Objektorientierte Programmierung. Klasse. Objekt. Beispiel: Sportfest1. Methode. Eine Einführung mit BlueJ

Objektorientierte Programmierung. Objektorientierte Programmierung. Klasse. Objekt. Beispiel: Sportfest1. Methode. Eine Einführung mit BlueJ Objektorientierte Programmierung Objektorientierte Programmierung Eine Einführung mit BlueJ stellt die Daten, ihre Struktur und ihre Beziehungen zueinander in den Vordergrund. Weniger im Blickpunkt: die

Mehr

E-Business Architekturen

E-Business Architekturen E-Business Architekturen Übung 3b Entwicklung eigener Service-Angebote 01.03.2015 Prof. Dr. Andreas Schmietendorf 1 Ziele der Übung Möglichkeiten zur Serviceimplementierung (ggf. auch Cloud) Umgang mit

Mehr

Komponentenbasierte Softwareentwicklung

Komponentenbasierte Softwareentwicklung Seminar WS04 Komponentenbasierte Softwareentwicklung Karl Pauls Software-Komponente A software component is a unit of composition with contractually specified interfaces and explicit context dependencies

Mehr

Übungsaufgabe Transaktion als Middleware

Übungsaufgabe Transaktion als Middleware Übungsaufgabe Transaktion als Middleware und Java Persistence API Client/Server Abstraktes Komponentenmodell Entscheidende Punkte Erweiterung der Invoke-Methode Context-Verwaltung Transaktionsbehandlung

Mehr

Managed VPSv3 Was ist neu?

Managed VPSv3 Was ist neu? Managed VPSv3 Was ist neu? Copyright 2006 VERIO Europe Seite 1 1 EINFÜHRUNG 3 1.1 Inhalt 3 2 WAS IST NEU? 4 2.1 Speicherplatz 4 2.2 Betriebssystem 4 2.3 Dateisystem 4 2.4 Wichtige Services 5 2.5 Programme

Mehr

Dokumentation zur Verwendung eines SOAP-Webservices in SAP PI

Dokumentation zur Verwendung eines SOAP-Webservices in SAP PI Betriebswirtschaftliche Anwendungen 2: Serviceorientierte Anwendungsintegration Dokumentation zur Verwendung eines SOAP-Webservices in SAP PI Umrechnung von Währungen Steffen Dorn, Sebastian Peilicke,

Mehr

Javadoc. Programmiermethodik. Eva Zangerle Universität Innsbruck

Javadoc. Programmiermethodik. Eva Zangerle Universität Innsbruck Javadoc Programmiermethodik Eva Zangerle Universität Innsbruck Überblick Einführung Java Ein erster Überblick Objektorientierung Vererbung und Polymorphismus Ausnahmebehandlung Pakete und Javadoc Spezielle

Mehr

ESB. Open Source ESB: Mule Flightreservation. Res Gilgen Hochschule Luzern [Wählen Sie das Datum aus]

ESB. Open Source ESB: Mule Flightreservation. Res Gilgen Hochschule Luzern [Wählen Sie das Datum aus] ESB Open Source ESB: Mule Flightreservation Res Gilgen Hochschule Luzern [Wählen Sie das Datum aus] Inhalt 1. Open Source ESB: Mule... 2 1.1. Überblick... 2 1.1.1. Das Beispiel Zeigt:... 2 1.2. Installationsanleitung...

Mehr

Hauptseminar Management von Softwaresystemen. Techniken der System-Integration EAI, Middleware, SOA, CORBA

Hauptseminar Management von Softwaresystemen. Techniken der System-Integration EAI, Middleware, SOA, CORBA Hauptseminar Management von Softwaresystemen Techniken der System-Integration EAI, Middleware, SOA, CORBA Betreuerin: Referent: Ulrike Hammerschall Alexey Krivoborodov Agenda Motivation Arten der Verteilung

Mehr

Inhalt: Version 1.7.5

Inhalt: Version 1.7.5 Inhalt: Objekte ohne Methoden Objekte mit einfachen Methoden Objekte und Methoden mit Parametern Objekte und Methoden mit Rückgabewert Objekte mit einem Array als Attribut Beziehungen zwischen Objekten

Mehr

Höherwertige Schnittstellenkomponenten für den Datenaustausch im Gesundheitswesen

Höherwertige Schnittstellenkomponenten für den Datenaustausch im Gesundheitswesen Höherwertige Schnittstellenkomponenten für den Datenaustausch im Gesundheitswesen C Ohr, M Krasser, Dr. R Brandner Mannheim, 06.09.2010 Agenda Kommunikationsstandards im Gesundheitswesen Notwendigkeit

Mehr

Fortgeschrittene Servlet- Techniken. Ralf Gitzel ralf_gitzel@hotmail.de

Fortgeschrittene Servlet- Techniken. Ralf Gitzel ralf_gitzel@hotmail.de Fortgeschrittene Servlet- Techniken Ralf Gitzel ralf_gitzel@hotmail.de 1 Themenübersicht Ralf Gitzel ralf_gitzel@hotmail.de 2 Übersicht Servlet Initialisierung Attribute und Gültigkeitsbereiche Sessions

Mehr

Fakultät für Elektrotechnik, Informatik und Mathematik Institut für Informatik Fachgebiet Didaktik der Informatik

Fakultät für Elektrotechnik, Informatik und Mathematik Institut für Informatik Fachgebiet Didaktik der Informatik Fakultät für Elektrotechnik, Informatik und Mathematik Institut für Informatik Fachgebiet Didaktik der Informatik Konzeption und prototypische Implementierung eines Knowledge-Servers mit Adaptern zur Integration

Mehr

Service-Orientierte Architekturen

Service-Orientierte Architekturen Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 7: Web Services IV Exkurs über Sicherheitsanforderungen Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha

Mehr

Schedulingund Thread-Ausführer

Schedulingund Thread-Ausführer Schedulingund Thread-Ausführer Scheduling Ein Scheduler arbeitet Programmstücke nach einer festen Zeitspanne oder zu einer fixen Zeitpunkt wiederholt oder einmal ab. Notwendigkeiten für Scheduling sind

Mehr

Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008

Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008 Name: Matrikel-Nr: Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008 Bitte schreiben Sie leserlich und antworten Sie kurz und präzise. 1. Zeichnen Sie das Schichten-Modell eines Computersystems und markieren

Mehr

Einführung in die OPC-Technik

Einführung in die OPC-Technik Einführung in die OPC-Technik Was ist OPC? OPC, als Standartschnittstelle der Zukunft, steht für OLE for Process Control,und basiert auf dem Komponentenmodel der Firma Microsoft,dem Hersteller des Betriebssystems

Mehr

Integration des Troubleticketsystems OTRS bei einem mittelständischen Unternehmen

Integration des Troubleticketsystems OTRS bei einem mittelständischen Unternehmen Integration des Troubleticketsystems OTRS bei einem mittelständischen Unternehmen Präsentation meiner Diplomarbeit Felix J. Ogris fjo@ogris.de 6. Februar 2008 Felix J. Ogris Integration von OTRS 6. Februar

Mehr

Drei-Schichten-Architektur. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 16: 3-Schichten-Architektur 1 Fachkonzept - GUI

Drei-Schichten-Architektur. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 16: 3-Schichten-Architektur 1 Fachkonzept - GUI Universität Osnabrück Drei-Schichten-Architektur 3 - Objektorientierte Programmierung in Java Vorlesung 6: 3-Schichten-Architektur Fachkonzept - GUI SS 2005 Prof. Dr. F.M. Thiesing, FH Dortmund Ein großer

Mehr

DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE

DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE DOKUMENTATION MAAS - MONITORING AS A SERVICE DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE Dokumentation MaaS - Monitoring as a Service Inhalt 1. MaaS - Monitoring as Service... 3 1.1 Einleitung...

Mehr

ANDROID. Analyse der Android Plattform. Andre Rein, Johannes Florian Tietje. 28. Oktober 2010. FH-Gieÿen-Friedberg Android Praktikum

ANDROID. Analyse der Android Plattform. Andre Rein, Johannes Florian Tietje. 28. Oktober 2010. FH-Gieÿen-Friedberg Android Praktikum Analyse der Android Plattform Andre Rein, Johannes Florian Tietje FH-Gieÿen-Friedberg Android Praktikum 28. Oktober 2010 Topics 1 Übersicht Android Plattform Application Framework Activities und Services

Mehr

CaseWare Monitor. ProduktNEWS CaseWare Monitor. Version 4.3. Mehr Informationen zu CaseWare Monitor und unseren anderen Produkten & Dienstleistungen

CaseWare Monitor. ProduktNEWS CaseWare Monitor. Version 4.3. Mehr Informationen zu CaseWare Monitor und unseren anderen Produkten & Dienstleistungen Mit der aktuellen Version hält eine komplett neu konzipierte webbasierte Anwendung Einzug, die sich neben innovativer Technik auch durch ein modernes Design und eine intuitive Bedienung auszeichnet. Angefangen

Mehr

Erstellung eines SharkNet Installers für Windows mit Inno Setup Compiler 5.4.2

Erstellung eines SharkNet Installers für Windows mit Inno Setup Compiler 5.4.2 Erstellung eines SharkNet Installers für Windows mit Inno Setup Compiler 5.4.2 1. Benötigte Software Zur Erstellung des Installers wird folgende Software benötigt. Es wird sich in dieser Dokumentation

Mehr

Anwendung eines Enterprise Java Beans

Anwendung eines Enterprise Java Beans Anwendung eines Enterprise Java Beans EJB Server EJB Container Remote Interface Home Interface EJB Object Der EJB Container kümmert sich um die Kommunikation des Beans mit anderen Komponenten, wobei er

Mehr

PIWIN 1 Übung Blatt 5

PIWIN 1 Übung Blatt 5 Fakultät für Informatik Wintersemester 2008 André Gronemeier, LS 2, OH 14 Raum 307, andre.gronemeier@cs.uni-dortmund.de PIWIN 1 Übung Blatt 5 Ausgabedatum: 19.12.2008 Übungen: 12.1.2009-22.1.2009 Abgabe:

Mehr

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java Willkommen zur Vorlesung Objektorientierte Programmierung Vertiefung - Java Zum Dozenten Mein Name: Andreas Berndt Diplom-Informatiker (TU Darmstadt) Derzeit Software-Entwickler für Web- Applikationen

Mehr

3. Konzepte der objektorientierten Programmierung

3. Konzepte der objektorientierten Programmierung 3. Konzepte der objektorientierten Programmierung 3.1 Basiskonzepte 3.2 Generalisierung / Spezialisierung 3.3 Aggregation 3.4 Assoziation 3.5 Nachrichten 3.6 Polymorphismus 3. Konzepte der Objektorientierung

Mehr

Kompatibilität von Microsoft Exchange Server mit den Microsoft Windows Server-Betriebssystemen

Kompatibilität von Microsoft Exchange Server mit den Microsoft Windows Server-Betriebssystemen Kompatibilität von Microsoft Exchange Server mit den Microsoft Windows Server-Betriebssystemen Whitepaper Veröffentlicht: April 2003 Inhalt Einleitung...2 Änderungen in Windows Server 2003 mit Auswirkungen

Mehr

Elektronische Zustellung WKO / AustriaPro. Status Arbeitspakete 13.12.2011 PL.O.T

Elektronische Zustellung WKO / AustriaPro. Status Arbeitspakete 13.12.2011 PL.O.T Elektronische Zustellung WKO / AustriaPro Status Arbeitspakete 13.12.2011 PL.O.T Agenda Übersicht und Inhalt PL.O.T Arbeitspakete Details zu den Arbeitspaketen AP 3 Spezifikationserweiterungen AP 5 Gateways

Mehr

Proseminar Website-Management-Systeme ZOPE/CMF. Andreas M. Weiner

Proseminar Website-Management-Systeme ZOPE/CMF. Andreas M. Weiner Proseminar Website-Management-Systeme ZOPE/CMF Andreas M. Weiner Technische Universität Kaiserslautern Fachbereich Informatik Arbeitsgruppe Softwaretechnik Betreuer: Dipl. Inf. Christian Stenzel Überblick

Mehr

Instant Grid Stand August 2006

Instant Grid Stand August 2006 Instant Grid Stand August 2006 Instant Grid Stand August 2006 Projekttreffen 22/23.08.2006 Göttingen Andreas Hoheisel (andreas.hoheisel@first.fraunhofer.de) Helge Rosé (helge.rose@first.fraunhofer.de)

Mehr