Werkzeugunterstützung für Oberflächenprototyping mit Webservices

Transkript

1 Gottfried Wilhelm Leibniz Universität Hannover Fakultät für Elektrotechnik und Informatik Institut für Praktische Informatik Fachgebiet Software Engineering Werkzeugunterstützung für Oberflächenprototyping mit Webservices Masterarbeit im Studiengang Informatik von Ursula Beck Prüfer: Prof. Dr. Kurt Schneider Zweitprüfer: Prof. Dr.-Ing. Christian Grimm Betreuer: Dr.-Ing. Daniel Lübke Hannover, 18. Juni 2008

2 Zusammenfassung Eine systematische und umfassende Anforderungsanalyse ist der erste wichtige Schritt für ein erfolgreiches Softwareprojekt. Zur Unterstützung der Anforderungsanalyse können elektronische Oberflächenprototypen eingesetzt werden. Diese bieten eine für Stakeholder leicht verständliche Diskussiongrundlage bei der Erhebung und Validierung von Anforderungen. Die Entwicklung derartiger Prototypen ist allerdings recht aufwändig und damit auch kostenintensiv. Um den Aufwand der Prototypentwicklung zu reduzieren, wird in dieser Arbeit ein Vorgehensmodell zum Prototyping mit Webservices definiert. Das Vorgehensmodell beinhaltet eine Annotation von WSDL-Dateien mit abstrakten Oberflächen- und Workflowbeschreibungen. Diese Annotationen werden dazu verwendet, die Entwicklung von portalähnlichen Oberflächenprototypen auf Basis von Webservices zum Teil zu automatisieren. Dazu werden in dieser Arbeit zunächst Modelle definiert, mit denen die abstrakten Oberflächenbeschreibungen und die Workflows erstellt werden können. Die Basis für die Oberflächenbeschreibungen bilden die in den WSDL-Dateien enthaltenen XML-Schemata. Es werden deshalb Algorithmen entwickelt, mit denen XML-Schemata in abstrakte Oberflächenbeschreibungen transformiert werden können. Die Workflow- und Oberflächenbeschreibungen werden mit der WSDL-Datei eines Webservices zusammen veröffentlicht und können so in verschiedenen Projekten zum Prototyping verwendet werden. Für die Entwicklung der Prototypen werden weitere Algorithmen definiert, mit denen die Annotationen der WSDL-Dateien in HTML-Fragmente transformiert werden können. Mehrere HTML-Fragmente verschiedener Webservices können zu einem Prototyp kombiniert werden. Sowohl der Annotations- als auch der Entwicklungsprozess des Prototypings können durch Werkzeuge unterstützt werden. Mit Hilfe von zwei Referenzimplementierungen wird in dieser Arbeit gezeigt, wie eine solche Werkzeugunterstützung aussehen kann. Außerdem wird ein Prozess für die Auswertung der Prototypen definiert. Das Vorgehensmodell zum Prototyping mit Webservices reduziert den Aufwand und damit die Kosten für die Entwicklung von elektronischen Oberflächenprototypen. ii

3 Inhaltsverzeichnis 1. Einführung Motivation Ziel der Arbeit Gliederung Grundlagen Die Anforderungsanalyse von Softwareprojekten Referenzmodell für die Anforderungsanalyse Klassifizierung von Anforderungen Erhebungsmethoden Probleme in der Anforderungsanalyse Prototyping Allgemeine Ziele des Prototypings Klassifizierung von Prototypen Allgemeines Vorgehensmodell zum Prototyping Service-orientierte Architekturen und Webservices Definition von SOA Der Webservice-Standard Web Services Description Language XML-Schema Portale Definition des Portal-Begriffs Oberflächen von Portalen Zusammenfassung Der Prototyping-Prozess mit Webservices Ziele des Prototypings mit Webservices Anforderungen an das Prototyping mit Webservices Anforderungen an die Prototypen Anforderungen an den Prototyping-Prozess Phasen des Prototyping-Prozesses mit Webservices Zusammenfassung Annotation von WSDL-Dateien Problembeschreibung WSMessageWorkflows Ansätze zur Oberflächengestaltung Bekannte Ansätze Ein- und Zwei-Phasen-Transformation Metamodell für XML-Schemata Oberflächenbeschreibung mit Formularelementen Metamodell für Formularbeschreibungen iii

4 Inhaltsverzeichnis Transformationsalgorithmus XSDToForm Oberflächenbeschreibung mit Präsentationselementen Metamodell für Präsentationsbeschreibungen Transformationsalgorithmus XSDToPresentation Inhalte für Präsentationsbeschreibungen Mapping zwischen Oberflächenelementen Prototyping-Dateien Zusammenfassung Entwicklung eines WS-Prototyps Prozessbeschreibung Aufbau eines WS-Prototyps Portal-Templates Verwendung von AJAX Simulation von Serviceaufrufen WSMessageWorkflow-Kompositionen Auswertung von Prototyping-Dateien Transformation von WSMessageWorkflows in HTML-Fragmente Algorithmus FormToHTML Algorithmus PresentationToHTML Transformation von Mappings Kombination von HTML-Fragmenten zu einer Oberfläche Zusammenfassung Auswertung eines WS-Prototyps Interviews als Auswertungsmethode Qualitätseigenschaften von Webservices Die Demonstration eines WS-Prototyps Erfassen von Kommentaren Konfiguration eines WS-Prototyps Auswertungsbericht Zusammenfassung Referenzimplementierungen AnnotationGenerator WSPrototypEditor Architektur Funktionalität zur Entwicklung eines WS-Prototyps Funktionalität zur Demonstration eines WS-Prototyps Zusammenfassung Ein Anwendungsbeispiel Projektbeschreibung Durchgeführte Tätigkeiten für das Prototyping Erfahrungen aus dem Interview Zusammenfassung Zusammenfassung und Ausblick Kritische Würdigung Ausblick iv

5 Inhaltsverzeichnis 9.3. Zusammenfassung Literaturverzeichnis 103 Abbildungsverzeichnis 107 A. XML-Schemata 109 v

6 1. Einführung 1.1. Motivation Immer mehr Unternehmen stellen zurzeit ihre Unternehmens-IT auf service-orientierte Architekturen (SOA) um. Flexibilität und Wandlungsfähigkeit in Bezug auf die Anpassung der eigenen Geschäftsprozesse werden für den Erfolg eines Unternehmens immer wichtiger. Services - die Softwarebausteine einer SOA - lassen sich schnell und einfach an geänderte Geschäftsprozesse anpassen oder austauschen. Unternehmen können so schneller auf neue Marktsituationen reagieren und verbessern dadurch ihre Wettbewerbsfähigkeit. Auch Services von Partnerunternehmen lassen sich in die eigene IT integrieren, so dass unternehmensübergreifende Geschäftsprozesse effizient unterstützt werden können. Im Zuge der Einführung einer SOA werden neue Endanwendungen für Benutzer entwickelt. Dabei soll die Anzahl der verschiedenen Anwendungen, mit denen ein Benutzer regelmäßig arbeitet, reduziert werden. Häufig existieren in Unternehmen viele verschiedene Anwendungen, von denen jeder Mitarbeiter mehrere zum Ausführen seiner Tätigkeiten benötigt. Um den Benutzer bei seiner täglichen Arbeit besser zu unterstützen und die Arbeitsabläufe effizienter zu gestalten, sollen diese Anwendungen über eine einheitliche Oberfläche zusammengefasst werden. Da die zu unterstützenden Geschäftsprozesse sich oft durch mehrere Abteilungen ziehen, sind verschiedene Benutzergruppen von der Umstrukturierung betroffen. Unternehmensportale, die über eine Weboberfläche zugänglich sind, ermöglichen es, verschiedene Benutzeroberflächen in einer Anwendung zu vereinigen. Auch externe Benutzergruppen können über das Internet diese Unternehmensportale nutzen. Deshalb werden im Rahmen der Umgestaltung der IT- Landschaft eines Unternehmens in Richtung einer SOA häufig derartige Unternehmensportale entwickelt. Besonders für kleine und mittelständische Unternehmen bedeuten die Einführung einer SOA und die damit verbundenen hohen Anfangsinvestitionen ein großes Risiko. Durch die Verwendung bereits existierender Services können Kosten gesenkt werden, da der Implementierungsaufwand reduziert wird. Zeit- und kostenintensiv bleibt allerdings die Entwicklung von neuen Endanwendungen, also z.b. die Entwicklung eines Unternehmensportals. Bei der Entwicklung solcher Anwendungen müssen zum einen die zugrunde liegenden Geschäftsprozesse berücksichtigt werden und zum anderen die Anforderungen der Benutzer an die Oberflächen. Da von der Umstrukturierung verschiedene Abteilungen und Unternehmensbereiche betroffen sind, existieren viele verschiedene Benutzergruppen, die das neue System verwenden werden Im Rahmen der Analysephase (auch als Anforderungsphase bezeichnet) eines SOA-Projekts müssen die Anforderungen der verschiedenen Benutzer erhoben werden. Die Erhebung von Anforderungen, speziell von Oberflächenanforderung, ist eine schwierige und aufwändige Tätigkeit. Benutzer haben Probleme, ihre Vorlieben und Interessen verständlich zu kommunizieren. Zudem setzen sie vieles als selbstverständlich voraus, so dass Anforderungen an die Benutzeroberfläche oft nur unzureichend spezifiziert werden. Diese Unzulänglichkeiten in den Anforde- 1

7 1. Einführung rungen führen dazu, dass ein System entwickelt wird, das nicht den Vorstellungen der Benutzer entspricht. Im schlimmsten Fall fehlen in dem fertig gestellten System sogar bestimmte Interaktionsmöglichkeiten, die ein Benutzer für seine Arbeit benötigt. Eine Nachbesserung in einer späten Projektphase oder gar erst nach Auslieferung der fertigen Software ist schwierig und teuer. Gerade die Benutzerfreundlichkeit ist jedoch ein entscheidendes Kriterium für die Zufriedenheit der Kunden und Benutzer. Elektronische Oberflächenprototypen können helfen, bereits während der Analysephase die Anforderungen präziser zu erfassen. Sie animieren Benutzer dazu, ihre eigenen Erwartungen mit dem Prototyp zu vergleichen und sich zu fehlenden Funktionen zu äußern. Durch diesen Abgleich können Anforderungen identifiziert und Missverständnisse ausgeräumt werden. Die Entwicklung von elektronischen Prototypen ist allerdings mit einem hohen Aufwand verbunden. Vor allem Oberflächenprototypen für Unternehmensportale können sehr umfangreich werden. Da SOA-Projekte für kleine und mittelständische Unternehmen auf Grund ihrer Komplexität ohnehin mit einem hohen finanziellem Risiko verbunden sind, lässt der finanzielle Rahmen die Entwicklung derartig komplexer Prototypen oft nicht zu. Die Prototypen würden jedoch dabei helfen, dass Projektrisiko zu minimieren Ziel der Arbeit Das Ziel dieser Arbeit ist es, ein Vorgehensmodell zu definieren, mit dem Oberflächenprototypen mit Webservices entwickelt werden können. Die Prototypen sollen in der Analysephase von Softwareprojekten zur Unterstützung der Anforderungserhebung eingesetzt werden. Insbesondere soll eine Unterstützung der Anforderungsanalyse von SOA-Projekten geschaffen werden. Dazu ist zu untersuchen, mit welchen Problemen Systemanalytiker während der Anforderungsphase konfrontiert sind, und wie diese durch das Prototyping mit Webservices reduziert werden können. Wichtig ist dabei, dass die Prototypentwicklung mit möglichst wenig finanziellem und zeitlichem Aufwand erfolgen kann. Dadurch soll es auch kleinen und mittelständischen Unternehmen, die nur über ein begrenztes finanzielles Budget verfügen, ermöglicht werden, das Prototyping zu nutzen. Das zu entwickelnde Vorgehensmodell soll deshalb vorhandene Webservices nutzen, die bereits Funktionalität zur Verfügung stellen und auch schon in der Analysephase eines Projekts vorhanden sind. Mit dem Vorgehensmodell sollen auch Webservices externer Anbieter in einen Prototyp integriert werden können. Diese Webservices werden mit Hilfe von WSDL-Dateien beschrieben und veröffentlicht. Es ist deshalb zu untersuchen, ob die Informationen in den WSDL-Dateien ausreichen, um damit schnell und einfach Oberflächenprototypen entwickeln zu können. Wenn nötig, soll eine WSDL-Erweiterung entwickelt werden, mit der sich Oberflächenbeschreibungen für Webservices erstellen lassen. Diese zusätzliche Vorbereitung von WSDL-Dateien soll dann in den Prototyping-Prozess integriert und durch ein Werkzeug unterstützt werden. Mit den zu entwickelnden Prototypen können in der Analysephase verschiedene Ziele verfolgt werden. Die Prototypen können z.b. bei der Auswahl geeigneter Webservices für eine zu entwickelden Anwendnung helfen. Außerdem können sie zur Erhebung und Validierung von Oberflächenanforderungen eingesetzt werden. In dieser Arbeit sollen die Ziele des Prototyping mit Webservices genauer definiert werden. Aufbauend auf diesen Zielen wird der Prototyping- Prozess spezifiziert. Außerdem können daraus Anforderungen an die Eigenschaften der zu 2

8 1. Einführung entwickelnden Prototypen abgeleitet werden. Sowohl die Entwicklung als auch die Auswertung der Prototypen soll durch ein Werkzeug unterstützt werden. In dieser Arbeit sollen die Anforderungen an ein solches Werkzeug definiert und eine Referenzimplementierung dazu entwickelt werden Gliederung Die vorliegende Arbeit ist wie folgt aufgebaut: In Kapitel 2 werden die für das Verständnis dieser Arbeit notwendigen Begriffe und Konzepte vorgestellt. Es wird zunächst eine kurze Einführung in die Analysephase des Softwareentwicklungsprozesses gegeben. Anschließend wird die Methodik des Prototypings erläutert. Außerdem werden Webservices und das Konzept von service-orientierten Architekturen betrachtet. In Kapitel 3 werden zu Anfang die Ziele definiert, die mit dem Prototyping verfolgt werden. Auf Basis dieser Ziele werden Anforderungen an den Prototyping-Prozess und die Prototypen erhoben. Am Ende des Kapitels wird der Prototyping-Prozess definiert. Die einzelnen Phasen dieses Prozesses werden in den darauf folgenden Kapiteln näher erläutert. In Kapitel 4 wird die Annotationsphase des Prototyping-Prozesses vorgestellt. Es werden Metamodelle definiert, mit denen Oberflächen- und Workflowbeschreibungen für Webservices erstellt werden können. Außerdem wird erläutert, wie WSDL-Dateien mit diesen Informationen erweitert werden können. Des Weiteren werden Algorithmen entwickelt, mit denen die Annotation von WSDL-Dateien z.t. automatisiert werden kann. Kapitel 5 beschreibt die Entwicklungsphase des Prototyping-Prozesses. Es wird erläutert, auf welche Weise die Annotationen der WSDL-Dateien bei der Entwicklung eines Prototyps genutzt werden können. Dazu werden Algorithmen definiert, die die abstrakten Oberflächenbeschreibungen in HTML-Elemente transformieren. Außerdem wird der generelle Aufbau der Webservice-Prototypen beschrieben. Des Weiteren werden Anforderungen für eine Werkzeugunterstützung definiert. In Kapitel 6 wird die letzte Phase des Prototyping-Prozesses, die Auswertungsphase, erläutert. Es werden die einzelnen Schritte betrachtet, die ein Systemanalytiker bei der Demonstration und Auswertung eines Prototyps befolgen muss. Zusätzlich werden wichtige Funktionalitäten definiert, die ein Demonstrationswerkzeug besitzen sollte. In Kapitel 7 werden die beiden Referenzimplementierungen vorgestellt, die zur Unterstützung des Prototyping-Prozesses entwickelt wurden. Dieses sind der AnnotationGenerator, der in der Annotationsphase zum Einsatz kommt, und der WSPrototypEditor, der sowohl die Entwicklung als auch die Auswertung von Webservice-Prototypen unterstützt. In Kapitel 8 wird anhand eines praktischen Beispiels für ein Callcenter-Portal die Umsetzbarkeit der entwickelten Konzepte demonstriert. Dabei kommen auch die beiden entwickelten Referenzimplementierungen zum Einsatz. In Kapitel 9 werden die Ergebnisse dieser Arbeit zusammengefasst und kritisch analysiert. Außerdem werden mögliche Erweiterungen und Verbesserungen des Prototyping- Prozesses erläutert. 3

9 2. Grundlagen In diesem Kapitel werden die Grundlagen zum Verständnis dieser Arbeit gelegt. Zunächst wird die Analysephase von Softwareprojekten näher betrachtet. Es werden die Tätigkeiten definiert, die während dieser Projektphase ausgeübt werden und die Probleme erörtert, die dabei auftreten. Anschließend wird Prototyping als Methode erläutert. Es werden verschiedene Arten von Prototypen und ihre Verwendung in der Softwareentwicklung vorgestellt. In den darauf folgenden Abschnitten werden die grundlegenden Eigenschaften und Konzepte von serviceorientierten Architekturen eingeführt. Dabei werden Webservices vorgestellt sowie die wichtigsten Standards aus dem Bereich der Webservice-Architektur, die für diese Arbeit benötigt werden. Des Weiteren werden Unternehmensportale definiert, die eine typische Endanwendung innerhalb von service-orientierten Architekturen darstellen Die Anforderungsanalyse von Softwareprojekten Referenzmodell für die Anforderungsanalyse Die Anforderungsanalyse ist die erste Phase innerhalb eines Softwareentwicklungsprozesses. Sie dient dazu, die Anforderungen an das zu entwickelnde System zu spezifizieren. Definition 1 (Anforderungsanalyse) Die Anforderungsanalyse beinhaltet Aktivitäten, um Anforderungen zu ermitteln, abzustimmen, zu formulieren, zu dokumentieren und zu validieren [Sch07b]. Das in Abbildung 2.1 dargestellte Referenzmodell Requirements Engineering gibt einen Überblick über die Tätigkeiten, die während der Anforderungsanalyse ausgeübt werden. Bevor die einzelnen Tätigkeiten erläutert werden, werden die Rollen definiert, die in die Analysephase involviert sind. Eine Person, die für die Anforderungserhebung zuständig ist und diese aktiv ausführt, wird als Systemanalytiker bezeichnet. Definition 2 (Systemanalytiker) Ein Systemanalytiker ist für die Erhebung von Anforderungen verantwortlich. Alle Personen mit einem Interesse an einem zu entwickelnden System werden unter der Rolle des Stakeholders zusammengefasst. Definition 3 (Stakeholder) Ein Stakeholder ist eine Person, die von einem neu zu entwickelnden System in irgendeiner Weise betroffen ist und damit ein Interesse daran hat. Davis [Dav05] unterscheidet sieben verschiedene Gruppen von Stakeholdern. Hierzu zählen Benutzer, Kunden, das Marketingpersonal, Entwickler, Systemtester, Personen, die durch das neue System ihren Arbeitsplatz verlieren könnten, und das Supportpersonal, das z.b. Schulungen für eine neue Anwendung durchführt. Bei der Anforderungserhebung werden besonders die Interessen von Benutzern und Kunden berücksichtigt. 4

10 2. Grundlagen Abbildung 2.1.: Referenzmodell Requirements Engineering [Sch07b] Definition 4 (Benutzer) Ein Benutzer ist eine Person, die ein zu entwickelndes System nach seiner Fertigstellung benutzen wird. Definition 5 (Kunde) Ein Kunde ist eine Person oder eine Instanz, die ein Projekt in Auftrag gibt. Nachdem die Rollen definiert wurden, werden nun die einzelnen Tätigkeiten, die im Referenzmodell Requirements Engineerings definiert sind, kurz erläutert. Elicitation: Die Elicitation (Erhebung von Rohanforderungen) beinhaltet das Identifizieren von Stakeholder und weiterer Anforderungsquellen. Neben Stakeholdern können z.b. Dokumente oder Altsysteme als Quelle für die Anforderungserhebung dienen. Bei der Elicitation werden aus diesen Quellen die grundsätzlichen Anforderungen an ein zu entwickelndes System erhoben. Interpretation: Die Interpretation von Anforderungen dient dazu, die Informationen, die bei der Elicitation gesammelt werden, zu strukturieren und aufzubereiten. Systemanalytiker müssen aus den vorliegenden Informationen die echten Anforderungen identifizieren. Diese werden klassifiziert und priorisiert, bei Unklarheiten oder fehlenden Anforderungen müssen die Stakeholder erneut befragt werden. Negotiation: Verschiedene Stakeholder können z.t. Anforderungen an ein zu entwickelndes System haben, die sich nicht in Einklang bringen lassen. In diesem Fall muss geklärt werden, wo Kompromisse geschlossen werden können bzw. wie die Anforderungen priorisiert werden können. Das Auflösen von derartigen Inkonsistenzen bezeichnet man als Negotiation. Documentation: Während der gesamten Analysephase werden die erhobenen Anforderungen und Zwischenstände dokumentiert. Es gibt eine Vielzahl von Dokumentationsmethoden und -techniken, um Anforderungen systematisch zu fixieren. Use Cases [Coc05] 5

11 2. Grundlagen z.b. werden zur Dokumentation von funktionalen Anforderungen benutzt, sie zeigen die Interaktion zwischen einem Benutzer oder einem externen System mit dem zu entwickelnden System. Ereignisgesteuerte Prozessketten (EPKs) [NR02] können dazu verwendet werden, komplexe Prozesse und deren Ablauf zu veranschaulichen, Qualitätsmodelle [Sch07a], um Qualitätsanforderungen zu präzisieren und zu dokumentieren. Alle Anforderungen werden in der Anforderungsspezifikation zusammengefasst. Die Anforderungsspezifikation ist das finale Produkt der Analysephase. Sie dient als Referenz bei der Abnahme des zu entwickelnden Systems. Validation & Verification: Die erhobenen und dokumentierten Anforderungen sollen vor der endgültigen Fixierung in der Anforderungsspezifikation auf inhaltliche und formale Aspekte hin geprüft werden. Die Validierung beschreibt die inhaltliche Prüfung. Dabei soll sichergestellt werden, dass die dokumentierten Anforderungen auch tatsächlich den Kundenanforderungen entsprechen. Bei der Verifikation wird geprüft, ob ein neues Dokument konsistent zu vorangegangenen Dokumenten ist. Obwohl diese beiden Tätigkeiten sehr wichtig sind, werden sie eher unsystematisch ausgeübt. Eine Validierung von Anforderungen erfolgt häufig nur auf Basis der Anforderungsspezifikation. Diese enthält jedoch viele formale Notationsmethoden, die für den Kunden schwer verständlich sind. Deshalb findet eine Validierung meistes nur in ungenügendem Maße statt Klassifizierung von Anforderungen Anforderungen beschreiben Eigenschaften, die ein zu entwickelndes System erfüllen muss. Nach IEEE610 [IEE90] ist eine Anforderung wie folgt definiert: 1. Beschaffenheit oder Fähigkeit, die von einem Benutzer zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird. 2. Beschaffenheit oder Fähigkeit, die ein System oder System-Teile erfüllen oder besitzen muss, um einen Vertrag, eine Norm, eine Spezifikation oder andere, formell vorgegebene Dokumente zu erfüllen. 3. Eine dokumentierte Darstellung einer Bedingung oder Fähigkeit gemäß 1 oder 2. Es gibt verschiedene Möglichkeiten, Anforderungen zu strukturieren und zu klassifizieren. Häufig werden Anforderungen in funktionale und nicht-funktionale Anforderungen unterteilt [Som07]. Funktionale Anforderungen beschreiben das Verhalten eines Systems, d.h. die Funktionalität, die es zur Verfügung stellen soll. Alle anderen Anforderungen werden unter dem Begriff der nicht-funktionalen Anforderungen zusammengefasst. Zu den nicht-funktionalen Anforderungen zählen z.b. Beschreibungen, auf welche Weise eine bestimmte Funktionalität erfüllt werden soll. Die Anforderung Das System soll zwei Zahlen addieren wäre z.b. eine funktionale Anforderung, während die Anforderung es soll dazu nicht länger als 1 Sekunde brauchen nicht-funktional ist. Nicht-funktionale Anforderungen werden häufig noch weiter unterteilt. Rupp [Rup04] z.b. unterscheidet die folgenden acht Kategorien von Anforderungen: funktionale Anforderungen technische Anforderungen 6

12 2. Grundlagen Anforderungen an die zu verarbeitenden Informationen Anforderungen an die Benutzerschnittstelle Qualitätsanforderungen Anforderungen an die Durchführung der Entwicklung rechtliche-vertragliche Anforderungen Eine Klassifizierung von Anforderungen hilft, die Analysephase zu systematisieren. Sie kann auch dazu genutzt werden, die Dokumentation der Anforderungen zu strukturieren Erhebungsmethoden Für die Erhebung von Anforderungen existiert eine Reihe von Techniken. Interviews z.b. stellen eine Möglichkeit dar, gezielt mit einzelnen Stakeholdern Anforderungen zu erheben. Workshops hingegen bieten sich an, wenn eine Gruppe von Stakeholdern zu ihren Interessen befragt werden soll. Weitere Techniken sind beispielsweise das Lesen von Dokumenten oder das Beobachten von Benutzern bei ihren Tätigkeiten. Nuseibeh und Easterbrook [NE00] unterteilen Erhebungsmethoden in sechs verschiedene Kategorien: Traditional techniques, wie z.b. Interviews mit Stakeholdern, die Analyse von Dokumenten oder Umfragen mit Hilfe von Fragebögen. Group elicitation techniques, an denen mehrere Stakeholder - auch mit verschiedenen Interessen - gleichzeitig beteiligt sind. Hierzu zählen Brainstorming und Workshops. Prototyping, eine Methode, die besonders dann zum Einsatz kommt, wenn früh Benutzerfeedback benötigt wird oder die Anforderungen sehr wage sind. Prototyping kann mit anderen Methoden kombiniert werden. Model-driven techniques verwenden ein spezifisches Modell der Informationen, die erhoben werden müssen. Dieses Modell leitet durch die Anforderungserhebung. Szenariobasierte Methoden [Mai98] gehören zu dieser Klasse von Erhebungsmethoden. Cognititve techniques beinhalten eine Reihe von Methoden, die ursprünglich für wissensbasierte Systeme entwickelt wurden. Hierzu zählt z.b. die Protokoll-Analyse, bei der ein Experte eine bestimmte Aufgabe ausführt und dabei laut mitdenkt. Ein Beobachter wertet diesen Prozess aus. Contextual techniques entstanden in den 90ern als eine Alternative zu traditionellen und kognitiven Techniken. Die Gesprächsanalyse sowie das Beobachten von Benutzern zählen zu diesen Techniken. Die Technik des Prototypings kommt besonders in Kombination mit Interviews zum Einsatz. Prototypen unterstützen die Interviewtechnik, indem sie eine Basis für ein Gespräch bilden. Durch einen Prototyp werden die interviewten Personen zu einer Meinungsäußerung animiert Probleme in der Anforderungsanalyse Die Anforderungsanalyse ist der erste entscheidende Schritt für ein erfolgreiches Projekt. Die Qualität der Anforderungen hängt maßgeblich von der Qualität der Analyse ab. Es gibt eine Viel- 7

13 2. Grundlagen zahl von Problemen, mit denen fast jeder Systemanalytiker während dieser Phase zu kämpfen hat. Rupp [Rup04] benennt sieben Hauptprobleme der Analysephase: Unklare Zielvorstellungen: Ein zu entwickelndes System wird sehr wahrscheinlich von verschiedenen Benutzergruppen verwendet werden. Diese erledigen verschiedene Aufgaben und haben unterschiedliche Präferenzen und Erfahrungen. Um eine klare Vorstellung von dem zu entwickelnden System zu erhalten, müssen alle Stakeholder identifiziert und ihre spezifischen Anforderungen ermittelt werden. Hohe Komplexität der zu lösenden Aufgabe: Je komplexer ein zu entwickelndes System ist, umso schwieriger wird es, alle Anforderungen zu identifizieren. Die Systemanalytiker müssen die Prozesse verstehen, die von dem zu entwickelnden System unterstützt werden sollen, und sich dazu in für sie z.t. unbekannte Domänen einarbeiten. Kommunikationsprobleme: Zwischen Systemanalytikern und Stakeholdern kommt es häufig zu Verständnisproblemen. Stakeholder benutzen z.b. domänenspezifische Begriffe und setzen ein gewisses Fachverständnis voraus, welches über das des Systemanalytikers hinausgeht. Auf der anderen Seite haben Stakeholder Probleme, systematische Notationsmethoden des Software Engineerings zu verstehen. Dieses Kommunikationsproblem wird als Symmetrie of Ignorance [Fis00] bezeichnet. Dabei kommt hinzu, dass sich beide Rollen nicht bewusst sind, dass sie den jeweils anderen missverstehen. Veränderliche Anforderungen: Auch wenn Anforderungen zu Beginn eines Projekts detailliert festgehalten werden, werden im Laufe der Zeit Änderungen auftreten. Diese Änderungen können in jeder Projektphase auftreten und mehr oder weniger weit reichende Auswirkungen haben. Bereits während der Analysephase sollten daher die Bereiche identifiziert werden, in denen Änderungen am wahrscheinlichsten sind, um später flexibel darauf reagieren zu können. Schlechte Qualität: Schlechte Qualität von Anforderungen äußert sich auf verschiedene Weisen. Mehrdeutigkeiten bei der Dokumentation z.b. führen dazu, dass Annahmen und Interpretationen in die Entwicklung einfließen. Redundanzen können zu Problemen führen, wenn z.b. auftretende Änderungen nicht an allen Stellen vorgenommen werden. Außerdem können Widersprüche innerhalb der Anforderungen bei vielen Benutzern und einer umfangreichen Anforderungsspezifikation schwer zu finden sein. Ein Kernproblem in der Anforderungsanalyse sind ungenaue Angaben mit Interpretationsspielraum. Wenn Anforderungen nicht präzise und detailliert dokumentiert werden, müssen Entwickler viel Nacharbeit leisten, um die fehlenden Informationen zu erhalten. Außerdem besteht die Gefahr, dass sie die Software nach ihren eigenen Vorstellungen entwickeln. Unnötige Merkmale: Zusatzfunktionen, die eigentlich nicht die ursprünglichen Interessen der Stakeholder widerspiegeln, entstehen, wenn Systemanalytiker ihrer Kreativität freien Lauf lassen. Diese Zusatzfunktionen wecken zwar die Begeisterung der Stakeholder können aber zu erhöhtem Aufwand führen. Dadurch können die geforderten Basis-Eigenschaften an das zu entwickelnde System vernachlässigt werden. Ungenaue Planung: Durch ungenügend spezifizierte Anforderungen werden Schätzungen bezüglich des Projektaufwands häufig zu optimistisch vorgenommen. Als Folge davon treten Termindruck und Budgetüberschreitungen auf, die nicht selten das gesamte Projekt gefährden. 8

14 2. Grundlagen 2.2. Prototyping Allgemeine Ziele des Prototypings In Softwareprojekten werden vor allem in der Analyse- und in der Entwurfsphase häufig Prototypen entwickelt. Mit Prototypen können verschiedene Ziele verfolgt werden. In der Analysephase können sie z.b. dazu verwendet werden, bestimmte Aspekte des zu entwickelnden Systems zu demonstrieren und Reaktionen von Stakeholdern dazu einzuholen. Eine Anwendungsmöglichkeit in der Entwurfsphase stellt das Austesten verschiedener technischer Lösungsmöglichkeiten dar. Prototypen sind ein mächtiges und nützliches Werkzeug, wenn sie bewusst eingesetzt werden und die Ziele, die mit einem Prototyp verfolgt werden, klar definiert sind. Ist die Absicht, die mit der Demonstration eines Prototyps verfolgt wird, für die Betrachter nicht ersichtlich oder werden zu viele Aspekten gleichzeitig veranschaulicht, so sinkt der Nutzen, der aus einem Prototypen gezogen wird [Sch96]. Definition 6 (Prototyp) Ein Prototyp realisiert bzw. simuliert einen Teil eines neu zu entwickelnden Software-Systems. Eine Studie von Bäumer et.al [BBLZ96] zeigt, dass Prototypen häufig als Kommunikationsmittel zwischen Systemanalytikern und Benutzern eingesetzt werden. In der Analysephase können dadurch die Kommunikationsprobleme, die in Kapitel diskutiert wurden, adressiert und minimiert werden. Mit einem Prototyp können sowohl funktionale und technische Aspekte als auch die Gestaltung von Oberflächen demonstriert werden. Vor allem bei der Spezifikation von Oberflächen sind Prototypen ein sehr nützliches Hilfsmittel. Graphische Benutzeroberflächen werden immer umfangreicher und wichtiger. Häufig müssen bei der Anforderungserhebung für diese Oberflächen die Interessen vieler verschiedener Benutzergruppen berücksichtigt werden. Eine beispielhafte Gestaltung der Oberfläche kann den Prozess der Anforderungserhebung erleichtern und verbessern Klassifizierung von Prototypen In der Literatur gibt es verschiedene Ansätze, Prototypen zu klassifizieren. Am bekanntesten ist die Unterscheidung von Floyd [Flo84] in explorative, experimentelle und evolutionäre Prototypen. Explorative Prototypen werden vor allem in der Analysephase eines Projekts eingesetzt. Sie demonstrieren bestimmte Aspekte des zu entwickelnden Systems, z.b. eine Funktionalität oder die Gestaltung einer Oberfläche. Mit explorativen Prototypen kann die Elicitation und Validierung von Anforderungen unterstützt werden. Experimentelle Prototypen dienen dazu, Konzepte auszuprobieren und die technische Umsetzung und Machbarkeit zu testen. Sie werden meistens in der Entwurfsphase eines Projekts verwendet. Während explorative und experimentelle Prototypen als Hilfsmittel eingesetzt werden, die Teilaspekte eines zu entwickelnden Systems veranschaulichen, werden evolutionäre Prototypen zur Entwicklung eines neuen Systems verwendet. Evolutionäre Prototypen werden in inkrementellen Entwicklungsprozessen erstellt und stetig weiterentwickelt. Sie sind die Bausteine des zu entwickelnden Systems. 9

15 2. Grundlagen Neben den drei Kriterien von Floyd können Prototypen auch anhand der Menge der Anforderungen, die sie abbilden, klassifiziert werden. Man unterscheidet dann zwischen horizontalen und vertikalen Prototypen. Ein horizontaler Prototyp veranschaulicht eine bestimmte Schicht des zu entwickelnden Systems. Oberflächenprototypen z.b. sind horizontale Prototypen. Ein vertikaler Prototyp hingegen zeigt einen Querschnitt durch das gesamte System, wobei von jeder Schicht nur Teilaspekte veranschaulicht werden. Ein weiteres Klassifizierungskriterium stellt das Medium dar, mit dem ein Prototyp erstellt wird. Hierbei lassen sich elektronische Prototypen und Papierprototypen unterscheiden. Rupp [Rup04] zieht zur Klassifizierung von Prototypen diese zwei Kriterien sowie die Möglichkeit der Wiederverwendung heran. Für die Wiederverwendung definiert sie Wegwerfprototypen und evolutionären Prototypen. Letztere entsprechen den evolutionären Prototypen, wie auch Floyd sie kategorisiert. Mit Hilfe dieser drei Kriterien lassen sich theoretisch acht unterschiedliche Klassen bilden. Die unterschiedlichen Klassen von Prototypen eignen sich für bestimmte Zwecke mehr oder weniger gut. In der Anforderungserhebung werden in erster Linie horizontale Wegwerfprototypen eingesetzt. Sollen Oberflächenaspekte veranschaulicht werden, so werden bevorzugt Papierprototypen verwendet, da diese schnell und kostengünstig zu erstellen sind und sich leicht ändern lassen. Zur Demonstration von Funktionalität kommen dagegen eher elektronische Prototypen zum Einsatz. Vertikale Prototypen eignen sich dazu, bestimmte Architekturentscheidungen zu demonstrieren oder zu validieren. Auf Papier werden dabei die Entscheidungen veranschaulicht und diskutiert, während mit einem elektronischen Prototyp die Umsetzbarkeit getestet wird. Vertikale, elektronische Wegwerfprototypen können mit den experimentellen Prototypen von Floyd verglichen werden Allgemeines Vorgehensmodell zum Prototyping Als Prototyping bezeichnet man den Prozess der Entwicklung und Auswertung eines Prototyps. Dieser Prozess soll systematisch und strukturiert aufgebaut sein - ähnlich zu der Entwicklung des eigentlichen Systems. Sommerville [Som07] schlägt dazu ein vierphasiges Vorgehensmodell vor, wie es in Abbildung 2.2 gezeigt wird. Abbildung 2.2.: Allgemeines Vorgehensmodell zum Prototyping nach [Som07] In der ersten Phase des Prototypings werden die Ziele definiert, die mit dem Prototyping erreicht werden sollen. In der Analysephase kann ein Ziel z.b. die Erhebung von Anforderungen an eine Benutzeroberfläche oder die Validierung bestimmter funktionaler Anforderungen sein. Die Ziele sollten so detailliert wie möglich festgelegt werden. Zur Zieldefinition gehört auch die Festlegung des Personenkreises, für den der Prototyp bestimmt ist. 10

16 2. Grundlagen Anhand der definierten Ziele wird in der zweiten Phase eine Funktionsbeschreibung des Prototyps erstellt. Dabei wird entschieden, welche Aspekte in dem Prototyp umgesetzt werden sollen und welche nicht. Es ist wichtig, eine klare Grenze zu ziehen, damit Aspekte, die für die Demonstration des Prototyps nicht benötigt werden, auch nicht entwickelt werden. Sie würden bei einer Demonstration nur vom eigentlichen Zweck ablenken. Die Funktionsbeschreibung des Prototyps stellt quasi die Anforderungsspezifikation für die Prototypentwicklung dar. Auf ihrer Basis wird in der dritten Phase der Prototyp entwickelt. Anschließend folgt die Auswertungsphase des Prototyps. Sie beinhaltet die Demonstration des Prototyps sowie die Auswertung der Ergebnisse, die dabei erzielt werden Service-orientierte Architekturen und Webservices Definition von SOA In der Literatur gibt es eine Vielzahl von Ansätzen, service-orientierte Architekturen zu definieren. Der Bitkom z.b. definiert auf seiner erst vor kurzem veröffentlichten Online-Plattform [Bit08] zum Thema SOA diesen Begriff wie folgt: Eine service-orientierte Architektur (SOA) ist ein Konzept, welche das Geschäft und die IT eines Unternehmens nach Diensten strukturiert, welche modular aufgebaut sind und flexibel zur Umsetzung von Geschäftsprozessen genutzt werden können. Bei dieser Begriffsabgrenzung werden die beiden Sichtweisen, aus denen einen SOA betrachtet werden kann, deutlich - die Business-Sicht und die IT-Sicht. Eine andere Definition von Lübke [Lü08] fokussiert eher die IT-Sicht einer SOA: A Service Oriented Architecture (SOA) is an enterprise-wide distributed software architecture for business applications that consists of services as its elementary software components. Those services are composed according to given business processes, and linked to the processes at run-time. SOA s main design goals are flexibility and maintability in regard to changes affecting these business process. Als letztes sei noch die Definition von Dostal et.al [DJM05] erwähnt, die unter dem Begriff des SOA-Tempels (siehe Abbildung 2.3) bekannt geworden ist. Dostal et.al nennen drei Grundvoraussetzungen, die eine SOA erfüllen muss: Einfachheit, Sicherheit und offene Standards. Des Weiteren definieren sie die folgenden vier Merkmale als tragende Säulen einer SOA: Lose Kopplung: Dienste bzw. Services können von Anwendungen dynamisch gesucht, gefunden und eingebunden werden. Verteiltheit: Dienste und Services können aus unterschiedlichen Unternehmensbereichen und sogar verschiedenen Unternehmen stammen. Verzeichnisdienst: Damit die Services von Anwendungen gefunden werden können, wird ein Verzeichnisdienst benötigt, in dem die verfügbaren Services registriert sind. Dieser Verzeichnisdienst muss alle benötigten Informationen über einen Service zur Verfügung stellen, die eine Anwendung zum Aufruf des Services benötigt. 11

17 2. Grundlagen Abbildung 2.3.: SOA-Tempel nach [DJM05] Prozessorientierte Struktur: Eine SOA unterstützt Geschäftsprozesse des Unternehmens und nicht nur einzelne Aufgaben von Benutzern. Definition 7 (Geschäftsprozess) Ein Geschäftsprozess besteht aus einer zusammenhängenden abgeschlossenen Folge von Tätigkeiten, die zur Erfüllung einer betrieblichen Aufgabe notwendig sind [Sta06]. Die Bausteine einer SOA sind Services. Häufig werden diese Services mit Webservices gleichgesetzt. SOA, als ein Architekturprinzip, ist jedoch nicht an eine spezifische Technologie gebunden. Webservices stellen lediglich eine von mehreren Möglichkeiten dar, eine SOA zu realisieren Der Webservice-Standard Webservices sind zurzeit die am häufigsten verwendete Technologie, um eine SOA zu realisieren. Webservices sind Softwarekomponenten, die über das Internet gefunden und genutzt werden können. In den letzten Jahren wurden vor allem vom World Wide Web Konsortium eine Reihe von Standards geschaffen, um die Interoperabilität von Webservices zu gewährleisten und diese Technologie stetig weiterzuentwickeln. Auf den Seiten des W3Cs finden sich die folgenden zwei Definitionen zu Webservices: A Web service is a software system identified by a URI [RFC 2396], whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML based messages conveyed by Internet protocols. [W3C04b] A Web service is a software system designed to support interoperable machineto-machine interaction over a network. It has an interface described in a machineprocessable format (specifically WSDL). Other systems interact with the Web service 12

18 2. Grundlagen in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards. [W3C04a] Webservices sind für die Kommunikation von Anwendungen untereinander konzipiert, eine Interaktion mit einem Benutzer ist nicht vorgesehen. Webservices sind über eine URI eindeutig identifizierbar und können über diese gefunden und aufgerufen werden. Die zweite Definition des W3Cs verweist bereits auf zwei der drei etablierten Standards innerhalb der Webservice Architektur - WSDL [W3C07b] und SOAP [W3C07a]. Der dritte Standard, welcher allerdings nicht so weit verbreitet ist wie WSDL und SOAP, ist UDDI [OAS04]. WSDL: SOAP: UDDI: WSDL (Web Service Description Language) ist ein XML-Format zur Beschreibung von Webservices. In Kapitel wird eine kurze Einführung in den Aufbau von WSDL-Dokumenten gegeben. SOAP (ursprünglich Simple Object Access Protocol) ist ein Protokoll zum Austausch XML-basierter Nachrichten über ein Netzwerk. SOAP kann mit verschiedenen Transportprotokollen, wie beispielsweise HTTP oder SMTP, benutzt werden. UDDI (Universal Description, Discovery and Integration) ist ein standardisierter Verzeichnisdienst, über den Webservices publiziert und gefunden werden können. Üblicherweise werden die Informationen zu einem Webservices mit Hilfe des WSDL- Formats zur Verfügung gestellt. UDDI besitzt eine SOAP-Schnittstelle, über die sowohl Informationen veröffentlicht als auch abgerufen werden können. Für diese Arbeit wird die folgende Definition für Webservices verwendet: Definition 8 (Webservice) Ein Webservice ist eine Softwarekomponente, die von Anwendungen über ein Netzwerk - typischerweise das Internet - gefunden und aufgerufen werden kann. Die Kommunikation mit einem Webservice erfolgt über SOAP. Für die Schnittstellenbeschreibung des Webservices wird WSDL verwendet. In eine Webservice-Architektur sind im Wesentlichen drei Rollen involviert - ein Serviceanbieter, ein Servicenutzer sowie ein Verzeichnisdienst. Definition 9 (Serviceanbieter) Ein Serviceanbieter ist eine Person oder ein Unternehmen, das Webservices in einem Netzwerk zur Verfügung stellt. Definition 10 (Servicenutzer) Ein Servicenutzer ist eine Anwendung, die einen Webservice aufruft. Im weiteren Sinne wird auch die Person, die mit dieser Anwendung interagiert, als Servicenutzer bezeichnet. Definition 11 (Verzeichnisdienst) In einem Verzeichnisdienst können Serviceanbieter ihre Servicebeschreibungen veröffentlichen. Servicenutzer können innerhalb von Verzeichnisdiensten nach Services suchen. Abbildung 2.4 zeigt diese drei Rollen, die Informationen, die zwischen ihnen ausgetauscht werden, sowie die Standards, die dabei verwendet werden. Ein Serviceanbieter stellt einen Webservice in einem Netzwerk zur Verfügung und veröffentlicht diesen über einen Verzeichnisdienst. Ein Servicenutzer sucht innerhalb eines Verzeichnisdienst nach einem bestimmten Webservice. Er erhält daraufhin einen Verweis auf die WSDL-Datei des Serviceanbieters. Die Kommunikation zwischen dem Servicenutzer und dem Verzeichnisdienst erfolgt über SOAP. Die WSDL-Datei enthält die nötigen Informationen, die der Servicenutzer benötigt, um den Webservice aufzurufen. 13

19 2. Grundlagen Abbildung 2.4.: Webservice-Dreieck nach [DJM05] Web Services Description Language Die Webservice Description Language (WSDL) ist eine Sprache zur Beschreibung der Schnittstellen eines Webservices mit Hilfe eines XML-Formats. WSDL ist mittlerweile in der Version 2.0 beim W3C standardisiert [W3C07b]. Die meisten verfügbaren Webservices werden aber noch mittels der Version 1.1 [W3C01] beschrieben. WSDL-Dateien werden fast immer generiert. Die meisten verfügbaren Werkzeuge unterstützen zurzeit nur den Standard der Version 1.1. Für diese Arbeit wird daher die Version 1.1 zugrunde gelegt. Mit einer WSDL-Datei können die folgenden Informationen zu einem Webservice veröffentlicht werden: die Methoden, die der Webservice anbietet die Parameter, die diese Methoden benötigen die Rückgabewerte der Methoden die physikalische Adresse des Webservices das Protokoll für den Datenaustausch Eine WSDL-Datei enthält keine semantische Beschreibungen über einen Service an sich oder die einzelnen Methoden des Services. Lediglich über ein so genanntes <documentation> Element können beschreibende Informationen zu den einzelnen WSDL-Elementen hinzugefügt werden. Listing 2.1 zeigt den schematischen Aufbau einer WSDL-Datei der Version 1.1. Im Folgenden werden die einzelnen Elemente einer WSDL-Datei erläutert: definition: types: Das <definition>-element ist das Wurzelelement einer WSDL-Datei. Dieses Element enthält sämtliche Definitionen eines WSDL-Dokuments. Das <types>-element ist ein Container für Datentyp-Definitionen. Diese beschreiben die Eingabeparameter und Rückgabewerte der Methoden des Webservices. Üblicherweise werden Datentypen mit Hilfe von XML-Schemata definiert. Der WSDL Standard schreibt jedoch kein bestimmtes Format vor. 14

20 2. Grundlagen <?xml version ="1.0"? > < d e f i n i t i o n s > <types >... < / types > <message> <part >... < / part > </ message> <porttype > <operation > <input >... < / input > <output >... < / output > </ operation > </ porttype > <binding > <operation > <input >... < / input > <output >... < / output > </ operation > </ binding > <service > <port >... < / port > </ service > </ d e f i n i t i o n s > Listing 2.1: Aufbau einer WSDL-Datei message: porttype: operation: binding: Ein <message>-element enthält die abstrakte Definition einer Nachricht, die der Webservice empfangen oder senden kann. Jedes <message>-element besitzt ein oder mehrere <part>-elemente, welche die Eingabeparameter bzw. Rückgabewerte beschreiben. Diese <part>-elemente referenzieren die Datentypen, die innerhalb des <types>-elements definiert sind. Ein <porttype> definiert eine abstrakte Menge von Operationen, die der Webservice anbietet. Jede Operation wird durch ein <operation>-element definiert. Eine Operation beschreibt eine Funktionalität, die der Webservice zur Verfügung stellt. Dazu werden mit Hilfe der <message>-elemente, die Nachrichten definiert, die bei einem Operationsaufruf mit einem Webservice ausgetauscht werden. Es können vier Interaktionsmuster definiert werden. One-way: Die Client-Anwendung schickt eine Nachricht an den Webservice. Request-response: Der Webservice erhält eine Anfrage und sendet eine Antwort an die aufrufende Anwendung zurück. Solicit-response: Der Webservice sendet eine Nachricht und erhält darauf hin eine Antwort vom Empfänger dieser Nachricht. Notification: Der Webservice versendet eine Nachricht. Innerhalb eines <binding>-elements wird für einen <porttype> das konkrete Übertragungsformat festgelegt. Für einen <porttype> können mehrere Bindings spezifiziert werden. Typischerweise wird das SOAP-Binding verwendet, das die Nachrichten im SOAP-Format überträgt, alternativ kann z.b. HTTP GET oder 15

21 2. Grundlagen port: service: HTTP POST als Binding spezifiziert werden. Ein <port> definiert für ein bestimmtes <binding> eine konkrete Netzwerk- Adresse. Ein <port> beschreibt also einen Endpunkt, an dem ein Webservice mit einem bestimmten Protokoll aufgerufen werden kann. Das <service>-element fasst mehrere Ports zu einem Service zusammen. Neben den standardmäßig vorhandenen Elementen besteht die Möglichkeit, das WSDL-Format an definierten Stellen um neue Elemente und Informationen zu erweitern. Dazu muss lediglich ein neuer Namesraum eingeführt werden, in dem die neuen Elemente deklariert sind. Tabelle 2.1 gibt einen Überblick über die Stellen, an denen Erweiterungselemente in eine WSDL- Datei eingefügt werden können. Erweiterbares Element definitions definitions/types definitions/service definitions/service/port definitions/binding definitions/binding/operation definitions/binding/operation/input definitions/binding/operation/output definitions/binding/operation/fault Mögliche Verwendung Definition von zusätzlichen Informationen, die den gesamten Webservice betreffen, z.b. Quality of Service Parameter Definition von Datentypen in einem anderen Format als XML-Schemata Definition von zusätzlichen Beschreibungen zu einem Service Festlegen einer konkreten Endpunktadresse mit einem bestimmten Protokoll Definition eines Protokolls für alle Operationen Sematische Beschreibung einer Operation Semantische Beschreibung von Eingabeparameter Sematische Beschreibung von Rückgabewerte Semantische Beschreibung von Fehlermeldungen Tabelle 2.1.: Erweiterbare Elemente des WSDL-Formats Der Erweiterungsmechanismus von WSDL wird häufig zur Spezifiktion von neuen Bindings benutzt. Das SOAP-Binding oder das HTTP GET & POST Binding zeigen beispielhaft diesen Verwendungszweck. Eine weitere Einsatzmöglichkeit des Erweiterungsmechanismus ist die Anreicherung der WSDL-Datei um semantische Informationen. WSDL-S (Web Service Semantics) [W3C05] z.b. verfolgt den Ansatz, WSDL-Elemente mit Hilfe von Domänenmodellen um semantische Beschreibungen zu ergänzen. Neben den funktionalen Aspekten ist die Aushandlung von so genannten Service Level Agreements (SLAs) in service-orientierten Architekturen von entscheidender Bedeutung, wenn Services von Drittanbietern genutzt werden. Ein Service Level Agreement ist ein Vertrag zwischen einem Dienstanbieter (in diesem Fall dem Serviceanbieter) und einem Dienstnutzer (hier der Servicenutzer), der in messbaren Werten die Güte der Leistung festsetzt, die der Anbieter mindestens erfüllen muss [WBL02]. Innerhalb von SLAs werden Quality of Service Parameter (QoS-Parameter) spezifiziert, wie beispielsweise die Kosten eines Serviceaufrufes oder die durchschnittliche Reaktionszeit des Services beim Aufruf einer Operation. 16

22 2. Grundlagen Es existieren eine Reihe von WSDL-Erweiterungen, die es erlauben, bestimmte QoS-Parameter bereits mit der WSDL-Datei zusammen zu veröffentlichen. D Ambrogio [D A06] definiert eine umfassende Sammlung von QoS-Parametern, die mit Hilfe der so genannten Q-WSDL Erweiterung in WSDL-Dokumente eingefügt werden können. Das WS-QoS Framework [TGRS04] stellt eine weitere Möglichkeit dar, Webservices um Quality of Service Parameter zu ergänzen XML-Schema XML-Schema (XSD) [W3C04c] ist eine Sprache, die zur Definition der inhaltlichen Struktur von XML-Dokumenten verwendet wird. XML-Schema-Dokumente sind XML-Dateien mit einem <schema>-element als Wurzelelement. Innerhalb dieses <schema>-elements können Elemente und Typen definiert werden, die in einem Instanzdokument zu diesem Schema verwendet werden dürfen. Ein Instanzdokument ist ein XML-Dokument, das einem bestimmten Schema entspricht. Man bezeichnet ein solches XML-Dokument als schemakonform. <xsd:schema xmlns:xsd=" targetnamespace=" <xsd:element name="name" type="xsd:string"/> <xsd:complextype name="deadresse"> <xsd:sequence> <xsd:element name="name" type="xsd:string"/> <xsd:element name="strasse" type="xsd:string"/> <xsd:element name="ort" type="xsd:string"/> <xsd:element name="plz" type="xsd:decimal"/> </xsd:sequence> <xsd:attribute name="land" type="xsd:nmtoken" fixed="de"/> </xsd:complextype> <xsd:element name="rechnungsadresse" type="deadresse"/> </xsd:schema> Listing 2.2: Ein einfaches XML-Schema [W3C04c] Listing 2.2 zeigt ein einfaches XML-Schema, in dem ein Element Name definiert wird, das den einfachen Datentyp string besitzt. Außerdem wird ein komplexer Typ DeAdresse definiert und ein Element Rechnungsadresse, welches diesen Typ besitzt. XSD besitzt eine Vielzahl eingebauter, einfacher Datentypen und eine Reihe von komplexen Typen, die zur Definition neuer Datentypen verwendet werden können. Einfache Datentypen sind z.b. Zeichenketten wie string oder token, nummerische Datentypen wie beispielweise int, double oder float, Datentypen, die eine Zeit oder ein Datum angeben - hierzu zählen z.b. date und duration - und noch einige weitere. Die komplexen Typen bieten die Möglichkeit, neue Datentypen zu definieren. Es werden an dieser Stelle die wichtigsten und am häufigsten benutzten komplexen Typen kurz vorgestellt. Für eine ausführliche Einführung in XML-Schema sei auf die Spezifikation des W3Cs verwiesen [W3C04d]. sequence: Innerhalb einer <sequence> werden mehrere Elemente zu einem neuen Element zusammengefasst. Diese müssen in der vorgegebenen Reihenfolge in einem Instanzdokument auftreten. In Listing 2.2 wird ein komplexer Typ DeAdresse mit Hilfe des <sequence>-elements definiert. Er repräsentiert eine Adresse, die aus einem Namen, einer Straße, einem Ort und einer Postleitzahl besteht. 17

23 2. Grundlagen all: choice: restriction: extension: Ein <all>-element definiert genau wie ein <sequence>-element eine Gruppe von Elementen. Die Elemente einer <all>-gruppe können in einem Instanzdokument jedoch in einer beliebigen Reihenfolge auftreten. Jedes Element darf zudem nur höchsten einmal vorhanden sein. Innerhalb von <choice>-elementen können beliebige Elemente definiert werden. In einem Instanzdokument darf genau eins dieser Elemente vorhanden sein. Mit Hilfe eines <restriction>-elements ist es möglich, neue Datentypen als eine Einschränkung bereits bestehender Typen zu definieren. Dazu wird ein base- Attribut angegeben, welches den Basistyp referenziert, der eingeschränkt werden soll. Es können sowohl die eingebauten einfachen Datentypen als auch selbstdefinierte Typen eingeschränkt werden. Listing 2.3 zeigt die Einschränkung des eingebauten integer-typs. Es wird ein neuer Typ meininteger definiert, dessen Wertebereich auf Zahlen zwischen und begrenzt ist. Eine Erweiterung wird ebenfalls auf einem Basistyp definiert. Erweiterungen können einen bestehenden Typ z.b. um neue Attribute oder Elemente erweitern. Listing 2.4 zeigt die Erweiterung des in Listing 2.2 definierten Typs DeAdresse um ein neues Element TelefonNummer. <xsd:simpletype name="meininteger"> <xsd:restriction base="xsd:integer"> <xsd:min-inclusive value="10000"/> <xsd:max-inclusive value="99999"/> </xsd:restriction> </xsd:simpletype> Listing 2.3: Einschränkung eines Basistyps [W3C04c] <xsd:complextype name="deadressemittelefon"> <xsd:extension base="deadresse"> <xsd:element name="telefonnummer" type="xsd:integer"/> </xsd:extension> </xsd:complextype> Listing 2.4: Erweiterung eines komplexen Typs Elemente innerhalb eines Schema-Dokuments können mit Häufigkeitsbeschränkungen versehen werden. Die Attribute minoccurs und maxoccurs geben an, wie oft ein Element mindestens auftreten muss und wie häufig es höchstens vorhanden sein darf. Beide Attribute müssen mit positiven ganzen Zahlen (einschließlich Null) versehen werden, für maxoccurs kann auch der Wert unbounded angegeben werden. Der Wert unbounded spezifiziert, dass das Element in einem Instanzdokument beliebig oft auftreten darf. Der Standardwert für die beiden Attribute minoccurs und maxoccurs ist 1. Alle innerhalb eines XML-Schemas definierten Elemente und Typen gehören zu einem Namesraum. Dieser wird über das Attribut targetnamespace innerhalb des <schema>-elements festgelegt und als Zielnamesraum bezeichnet. Jeder Namesraum ist über eine URI eindeutig bestimmt. In Listing 2.2 ist der Zielnamesraum über die URI definiert. Mit Hilfe des Konzepts von Namesräumen können Elemente und Typen mit gleichen Namen, 18

24 2. Grundlagen die aus unterschiedlichen Schemata stammen, identifiziert werden. Dazu werden so genannte QNames (qualifizierte Namen) benutzt. Ein QName besteht aus einem optionalen prefix, welches einen Namesraum referenziert und einem localpart, der den lokalen Namen angibt. Ein Beispiel für einen QName ist der Bezeichner xsd:string, der in Listing 2.2 öfter benutzt wird. Das Präfix xsd ist mit der URI verknüpft. Diese definiert den Namesraum des XML-Schemas. Der Datentyp string ist also in diesem Namensraum definiert. Über ein <import>-element können Namesräume in ein XML-Schema importiert werden. Die innerhalb dieses Schemas definierten Typen und Elemente können dann wie die lokal definierten Datentypen verwendet werden Portale Definition des Portal-Begriffs Der Portalbegriff hat sich in den letzten Jahren einem stetigen Wandel unterzogen. Anfangs wurden so genannte Einstiegsseiten in das Internet, wie sie z.b. Yahoo oder AOL anbieten, als Portale bezeichnet. Kennzeichnend für derartige Portale war eine Strukturierung der Seite nach Themenbereichen sowie eine Suchfunktion. Später kam die Möglichkeiten hinzu, die Portale individuell an eigene Vorlieben anzupassen, also die Oberfläche sowie die Navigationsmöglichkeiten zu personalisieren. Portale, wie die von Yahoo oder AOL, werden heute meistens als Internetportale bezeichnet. Definition 12 (Internetportal) Ein Internetportal ist eine Einstiegsseite in das Internet, die nach Themenbereichen strukturiert ist, eine Suchfunktion zur Verfügung stellt und sich personalisieren lässt. Mit einem Internetportal wird das Ziel verfolgt, Benutzern die Navigation und das Finden von Informationen im Internet zu erleichtern. Mit der Zeit haben immer mehr Unternehmen den Nutzen des Internets als Werbe- und Präsentationsplattform sowie als unterstützendes Medium zur Abwicklung ihrer Geschäftsprozesse erkannt. Im Laufe dieser Entwicklung entstand eine neue Generation von Portalen, die so genannten Unternehmensportale. Unternehmensportale waren anfangs recht statische Webseiten, die überwiegend Informationen zur Verfügung stellten. Nach und nach wurden die Unternehmensportale jedoch erweitert und in die Geschäftprozesse der Unternehmen integriert. Im Zuge der Verbreitung von service-orientierten Architekturen werden Unternehmensportale heute immer häufiger als zentrale Anwendung in einem Unternehmen eingesetzt. Solche Portale werden auch als Prozessportale bezeichnet, sie sind meistens sehr komplex und haben einen großen Funktionsumfang. Das Fraunhofer Institut für Arbeitswirtschaft und Organisation definiert Unternehmensportale wie folgt: Ein Unternehmensportal ist eine Applikation, welche basierend auf Webtechnologien einen zentralen Zugriff auf personalisierte Inhalte sowie bedarfsgerecht auf Prozesse bereitstellt [KGHV04]. Unternehmensportale adressieren anders als Internetportale einen weitaus kleineren Benutzerkreis. Dieser besteht meistens aus den Mitarbeiter des Unternehmens sowie Kunden oder Geschäftspartnern. Unternehmensportale lassen sich anhand der Benutzergruppe, für die sie bestimmt sind, in zwei Klasse unterteilen. Intranet-Portale sind Portale, die nur den Mitarbeitern 19

25 2. Grundlagen des Unternehmens zur Verfügung stehen, während Extranet-Portale auch für externe Benutzergruppen über das Internet verfügbar sind. Typische Merkmale eines Unternehmensportals sind Single-Sign-On (einmalige Anmeldung für alle Anwendungen) Datenaustausch zwischen heterogenen Anwendungen eine homogene Benutzeroberfläche Oberflächen von Portalen Portale basieren auf Webtechnologien. Die Benutzerschnittstelle eines Portals ist meistens ein Webbrowser. Eine Portaloberfläche besteht aus mehreren Bereichen, in denen die verschiedenen Anwendungen des Portals angeordnet sind. Trotz der Heterogenität der Anwendungen soll eine Portaloberfläche einheitlich wirken und in das Unternehmensbild passen. Abbildung 2.5.: Ein klassisches Portal-Layout Abbildung 2.5 zeigt den klassischen Aufbau einer Portaloberfläche. Der Inhaltsbereich ist in mehrere kleine Bereiche unterteilt. Diese werden oft als Portlets bezeichnet. Für die Strukturierung der Inhalte von Portalen wird in den meisten Fällen HTML (Hypertext Markup Language) verwendet. Das Layout kann mit Hilfe von CSS (Cascading Stylesheets) gestaltet werden. 20

26 2. Grundlagen 2.5. Zusammenfassung In diesem Kapitel wurden die grundlegenden Begriffe und Konzepte, die für das Vorgehensmodell zum Prototyping benötigt werden, eingeführt. Dazu wurde zunächst die Analysephase von Softwareprojekten vorgestellt. Außerdem wurde das generelle Konzept des Prototyping in Softwareprojekten sowie die Ziele, die damit verfolgt werden, erläutert. Des Weiteren wurden service-orientierte Architekturen und die Webservice-Technologie vorgestellt. Eine Möglichkeit, im Rahmen einer SOA prozessorientierte Endanwendungen für Benutzer zu entwickeln, stellen Portalanwendungen dar. Es wurde definiert, was unter einem Unternehmensportal zu verstehen ist und wie die Oberflächen für solche Portale im Allgemeinen gestaltet sind. 21

27 3. Der Prototyping-Prozess mit Webservices In diesem Kapitel werden zunächst die Ziele definiert, die mit dem Prototyping mit Webservices verfolgt werden. Dazu werden die charakteristischen Eigenschaften von Projekten erfasst, in denen das Prototyping zum Einsatz kommen soll. Außerdem wird anhand des Referenzmodells Requirements Engineering untersucht, welche der Tätigkeiten der Analysephase mit dem Prototyping unterstützt und verbessert werden können. Aufbauend auf den Zielen werden Anforderungen an die zu entwickelnden Prototypen und an den Prototyping-Prozess formuliert. Dabei werden die verschiedenen Rollen definiert, die in den Prototyping-Prozess involviert sind. Am Ende des Kapitels wird der Prozess in drei Phasen unterteilt. Dabei wird der Informationsfluss zwischen den Phasen erläutert. Die einzelnen Phasen werden in den Kapiteln 4, 5 und 6 detailliert beschrieben Ziele des Prototypings mit Webservices Das Prototyping mit Webservices soll die Anforderungserhebung in Softwareentwicklungsprojekten, insbesondere in SOA-Projekten unterstützen. Als SOA-Projekte werden Projekte bezeichnet, in denen eine SOA-Anwendung entwickelt wird. Lübke [Lü08] definiert SOA- Anwendungen wie folgt: An SOA Application is a software system that is realised by composing services from a given pool of available services together with necessary front-ends for endusers. An application is therefore a subset of available services: the services are composed to fulfil a certain business need at a given time. SOA-Anwendungen basieren also auf Services, unterstützen die Geschäftsprozesse eines Unternehmens und stellen Schnittstellen für Benutzer zur Verfügung. Für diese Arbeit wird die Art der Anwendungen, deren Entwicklungsprozess durch das Prototyping unterstützt werden soll, noch etwas weiter eingeschränkt. Lübke macht keine Aussage darüber, wie die Benutzerschnittstellen einer SOA-Anwendung aussehen. Auch die Services werden nicht weiter spezifiziert. Das Vorgehensmodell zum Prototyping soll auf Anwendungen zugeschnitten sein, bei denen die Services durch Webservices realisiert sind. Für die Benutzeroberflächen wird ein Unternehmensportal oder eine portalähnliche Anwendung vorausgesetzt. Es werden dazu SOA-Portalanwendungen definiert. Definition 13 (SOA-Portalanwendung) Eine SOA-Portalanwendung ist eine SOA-Anwendung mit einer Benutzerschnittstelle, deren Oberfläche wie ein Portal aufgebaut ist. In der Einführung dieser Arbeit wurde erläutert, dass vor allem kleinere und mittlere Unternehmen bei der Einführung einer SOA auf bereits vorhandene Webservices zurückgreifen können, um das Projektrisiko zu minimieren. In der Analysephase eines Projekts muss dazu geklärt werden, welche der zur Verfügung stehenden Webservices sich für die Integration in die zu entwickelnde Anwendung eignen. Dazu muss die von einem Webservice angebotene Funktionalität mit den Anforderungen im Projekt verglichen werden. Das Prototyping soll diesen Pro- 22

28 3. Der Prototyping-Prozess mit Webservices Abbildung 3.1.: Referenzmodell Requirements Engineering mit Prototyping-Unterstützung zess unterstützen. Dazu sollen Prototypen erstellt werden, mit denen Stakeholdern die Funktionalität eines Webservices veranschaulicht werden kann. Auf diese Weise sollen in Gesprächen mit den Stakeholdern potentielle Webservicekandidaten für die Integration in eine SOA- Portalanwendung diskutiert und ausgewählt werden können. Ein weiteres Ziel, das mit dem Prototyping verfolgt wird, ist die Reduzierung von Kommunikationsproblemen zwischen Systemanalytikern und Stakeholdern. In SOA-Portalprojekten müssen Anforderungen von einer heterogenen Benutzergruppe identifiziert und spezifiziert werden. Dazu müssen Systemanalytiker die Arbeitsabläufe der Benutzer analysieren. Dies ist eine schwierige und zugleich sehr wichtige Aufgabe, da die Zufriedenheit von Benutzern ein entscheidendes Kriterium für den Projekterfolg ist. Ein Benutzer, der mit seinen Arbeitsabläufen vertraut ist, setzt jedoch viele Anforderungen als selbstverständlich voraus. Dadurch entstehen die als Symmetrie of Ignorance bezeichneten Kommunikationsprobleme (siehe Kapitel 2.1.4) zwischen Systemanalytikern und Benutzern. Die Prototypen sollen dabei helfen, die vorausgesetzten Anforderungen eines Benutzers zu identifizieren. Ein Benutzer vergleicht einen Prototyp mit seinen Erwartungen an das neue System. Er wird dadurch animiert, sich zu Eigenschaften des Prototyps zu äußern, die nicht seinen Erwartungen entsprechen. Mit dem Prototyping soll sowohl die Elicitation als auch die Validierung von Benutzeranforderungen erleichtert werden. Das dritte Ziel, das mit dem Prototyping verfolgt wird, ist das Ziel, die zugrunde liegenden Geschäftsprozesse, die mit einer SOA-Portalanwendung unterstützt werden sollen, besser zu verstehen und präziser zu erfassen. Dazu sollen die Prozesse in einem Prototyp visualisiert werden, um z.b. zu klären, an welchen Stellen Benutzerinteraktionen notwendig sind. Auf diese Weise lassen sich benötigte Schnittstellen für einen Webservice identifizieren. Außerdem können die Daten spezifiziert werden, die ein Service verarbeiten können bzw. zur Verfügung stellen muss. Es soll auch möglich sein, das Zusammenspiel verschiedener Webservices in einem Prototyp zu demonstrieren. Die Validierung von Anforderungen ist eine Tätigkeit der Analysephase, für die es sehr wenig Unterstützung gibt. Nach Jones [Jon98] ist die Validierung mit Prototypen die effektivste Methode, um Fehler in Anforderungen aufzudecken. Erhobene Anforderungen sollen deshalb in den 23

29 3. Der Prototyping-Prozess mit Webservices Prototypen umgesetzt werden können, damit sie durch Stakeholdern validiert werden können. Das Prototyping mit Webservices unterstützt in der Analysephase also vor allem die Elicitation und Validierung von Anforderungen. Darüber hinaus kann das Prototyping auch bei anderen Tätigkeiten in dieser Phase nützlich sein. Während der Entwicklung eines Prototyps werden z.b. die Anforderungen interpretiert, die in dem Prototyp ungesetzt werden sollen. Dabei werden Unklarheiten und unvollständige Anforderungen identifiziert, da diese die Prototypentwicklung behindern. In Abbildung 3.1 ist noch einmal das Referenzmodell des Requirements Engineering dargestellt. Für jede Tätigkeit werden die Ziele benannt, die mit dem Prototyping mit Webservices vefolgt werden Anforderungen an das Prototyping mit Webservices Anforderungen an die Prototypen In diesem Kapitel werden die Anforderungen an die zu entwickelnden Prototypen spezifiziert. Um in einem Prototyp die Anforderungen von Stakeholdern mit der zur Verfügung gestellten Funktionalität eines Webservices vergleichen zu können, muss ein Prototyp die Funktionalität des Webservices veranschaulichen. Die Prototypen soll deshalb auf Basis von Webservices entwickelt werden. Anhand von Benutzeroberflächen soll gezeigt werden können, welche Funktionalität ein Webservice zur Verfügung stellt und wie diese von einem Benutzer verwendet werden kann. Dabei sollen mögliche Interaktionsabfolgen mit dem Webservice veranschaulicht werden können. Außerdem soll ersichtlich sein, welche Daten ein Webservice zur Verfügung stellt und welche er als Eingabeparameter benötigt. Es sollen also Oberflächenprototypen entwickelt werden, deren Oberflächen zu Webservices passen und mit denen sich Maskenabfolgen visualisieren lassen. Diese Maskenabfolgen sollen die Interaktionsmöglichkeiten mit einem oder mehreren Services veranschaulichen. Eine Oberfläche passt zu einer output-nachricht eines Webservice, wenn sie die Daten dieser Nachricht darstellt. Zu einer input-nachricht passt eine Oberfläche, wenn sie ein Eingabeformular präsentiert, aus dessen Daten die Nachricht verfasst werden kann. In beiden Fällen kann man auch sagen, die Oberfläche repräsentiert die Nachricht des Webservices. Da mit dem Prototyping insbesondere die Anforderungserhebung in SOA-Portalprojekten unterstützt werden soll, sollen die Prototypen eine Portaloberfläche präsentieren. Es soll möglich sein, zu demonstrieren, auf welche Weise Daten zwischen den einzelnen Anwendungen in diesem Portal ausgetauscht werden können. Prototypen, die die in diesem Kapitel spezifizierten Anforderungen erfüllen, werden als WS-Prototypen bezeichnet. Definition 14 (WS-Prototyp) Ein WS-Prototyp ist ein elektronischer Oberflächenprototyp, der auf Basis von Webservices entwickelt wird. Die Oberfläche des Prototyps ist wie ein Portal gestaltet. Auf ihr können mehrere Webservices gleichzeitig visualisiert werden. Mit einem WS- Prototyp lassen sich Interaktionsmöglichkeiten von Benutzern mit Webservices demonstrieren. Um mit einem WS-Prototyp verschiedene Webservices miteinander vergleichen zu können, sollen die Webservices leicht und schnell austauschbar sein. Idealerweise lässt sich der Prototyp während einer Demonstration entsprechend konfigurieren. Neben funktionalen Aspekten können auch Aspekte, die die Dienstqualität von Webservices betreffen, für eine SOA-Portalanwendung von Bedeutung sein. Vor allem, wenn Webservices von 24

30 3. Der Prototyping-Prozess mit Webservices externen Anbietern in eine SOA-Portalanwendung integriert werden sollen, müssen häufig Service Level Agreements zwischen dem Servicenanbieter und dem Servicenutzer ausgehandelt werden. Ein WS-Prototyp soll deshalb Auskunft über Qualitätseigenschaften der verwendeten Webservices geben Anforderungen an den Prototyping-Prozess Um die Anforderungen an den Prototyping-Prozess mit Webservices zu spezifizieren, werden in diesem Abschnitt die Rollen definiert, die in das Prototyping involviert sind. Dazu werden die folgenden Fragen beantwortet: Welche Rollen sind in den Prototyping-Prozess involviert? Welche Ziele verfolgen diese Rollen (in der Analysephase) und welche Tätigkeiten üben sie dabei aus? Mit welchen Problemen haben die beteiligten Rollen zu kämpfen? Wie kann das Prototyping diese Rollen beim Erreichen ihrer Ziele unterstützen? Tabelle 3.1 gibt einen Überblick über die am Prototyping beteiligten Rollen. Dabei sind sowohl Rollen aufgeführt, die aktiv an der Erstellung und Auswertung eines Prototyps beteiligt sind, sowie Rollen, die den Prototyp verwenden oder indirekt einen Nutzen aus ihm ziehen. Ein WS-Prototyp wird auf Basis von Webservices entwickelt. Dabei sollen auch unbekannte Webservices verwendet werden können. Um einen Webservice in einen Prototyp zu integrieren, muss bekannt sein, welche Funktionalität der Service zur Verfügung stellt und wie Oberflächen, die zu diesem Service passen, gestaltet werden können. WSDL-Dateien, welche häufig die einzige Informationsquelle zu Webservices sind, stellen jedoch keine Oberflächenbeschreibungen zur Verfügung (siehe Kapitel 2.3.3). Es wird deshalb die Rolle des Webserviceanalytikers (WS-Analytiker) definiert. Ein WS- Analytiker ergänzt WSDL-Dateien um zusätzliche Informationen, die für das Prototyping benötigt werden. WSDL-Dateien sollen zum einen um Oberflächenbeschreibungen ergänzt werden, die die Darstellungsmöglichkeit einer Webservicenachricht beschreiben. Zum anderen sollen Workflowbeschreibungen erstellt werden, mit denen die Funktionalität der Services näher spezifiziert wird. Mit den Workflowbeschreibungen sollen Interaktionsabfolgen zwischen einem Benutzer und einem Webservice definiert werden können. Die Anreicherung der WSDL-Dateien mit diesen Informationen wird in dieser Arbeit als Annotation oder Prototyping-Annotation von WSDL-Dateien bezeichnet. Definition 15 (Webserviceanalytiker) Ein Webserviceanalytiker (WS-Analytiker) annotiert WSDL-Beschreibungen von Webservices. Dabei fügt er den WSDL-Dateien Oberflächen- und Workflowbeschreibungen hinzu. Ein Workflow beschreibt eine Interaktionsabfolge zwischen einem Benutzer und einem Webservice. Die Rolle des WS-Analytikers kann von verschiedenen Personen ausgefüllt werden. Serviceanbieter können die WSDL-Dateien annotieren und diese Annotationen zusammen mit der WSDL- Beschreibung veröffentlichen. Da die Serviceanbieter aber zunächst keinen direkten Nutzen aus den Annotationen ziehen, werden sie die zusätzliche Arbeit vermutlich nicht leisten wollen. WS-Analytiker sind daher sehr wahrscheinlich Personen, die nicht an der Entwicklung des zu annotierenden Webservices beteiligt waren. Deshalb wird die Annotation von WSDL-Dateien in den Prototyping-Prozess mit einbezogen. Sie ist eine wesentliche Voraussetzung für das Proto- 25

31 3. Der Prototyping-Prozess mit Webservices Rolle Prototypentwickler Beschreibung erstellt und ändert einen WS-Prototyp interpretiert Anforderungen und setzt diese in einem WS- Prototyp um Webserviceanalytiker bereitet Webservices für das Prototyping vor annotiert dazu WSDL-Dateien mit Oberflächen- und Workflowbeschreibungen muss unbekannte Webservices anhand von WSDL- Dateien verstehen Systemanalytiker erhebt Anforderungen für ein (SOA-)Projekt nutzt einen WS-Prototyp zur Elicitation und Validierung in Gesprächen mit Stakeholdern wertet Ergebnisse des Prototypings aus Benutzer möchte, dass seine Arbeitsabläufe in dem neu zu entwickelnden System optimal unterstützt werden muss einem Systemanalytiker seine Anforderungen vermitteln kann an einem WS-Prototyp fehlende oder missverstandene Anforderungen aufdecken Kunde möchte Geschäftsprozesse des Unternehmens mit einer SOA-Portalanwendung besser unterstützen ist entscheidungsbefugt bei der Auswahl von Webservices Serviceanbieter stellt Webservices zur Verfügung, die zum Prototyping verwendet werden können veröffentlicht Schnittstellenbeschreibung und Beschreibungen zu Qualitätseigenschaften der angebotenen Webservices Anwendungsentwickler implementiert ein neu zu entwickendes System nutzt einen WS-Prototyp zum besseren Verständnis der Anforderungen Tabelle 3.1.: Rollen im Prototyping-Prozess 26

32 3. Der Prototyping-Prozess mit Webservices typing mit Webservices. WS-Analytiker sollen bei der Annotation von WSDL-Dateien durch ein Werkzeug unterstützt werden. Das Werkzeug soll so viele Informationen wie möglich automatisch aus WSDL-Dateien extrahieren und den Annotationsprozess so weit es geht automatisieren. Die Annotationen selbst sollen so gestaltet sein, dass sie sich in verschiedenen Projekten verwenden lassen. Durch die Annotation von WSDL-Dateien wird die Entwicklung eines WS-Prototyps erleichtert. Eine Person, die einen WS-Prototyp während der Analysephase eines SOA-Portalprojekts entwickelt, wird als Prototypentwickler bezeichnet. Definition 16 (Prototypentwickler) Ein Prototypentwickler erstellt einen WS-Prototyp für eine SOA-Portalanwendung. Er benutzt dazu Webservices, die von WS-Analytikern annotiert wurden. Prototypentwickler müssen zunächst Webservices finden, die die bereits erhobenen Anforderungen an das zu entwickelnde System erfüllen. Anschließend entwickeln sie für jeden Webservice Oberflächen und Maskenabfolgen. Mehrere dieser Webservices stellen sie dann zu einem WS-Prototyp zusammen. Da die Prototypen während der Analysephase erstellt werden, muss die Entwicklung schnell und einfach erfolgen. Prototypentwickler sollen deshalb bei der Entwicklung eines WS-Prototyps durch ein Werkzeug unterstützt werden. Das Werkzeug soll WSDL-Dateien und die von WS-Analytikern erstellten Annotationen analysieren und auswerten können. Für eine schnelle Entwicklung des Prototyps ist es hilfreich, die Entwicklung soweit wie möglich zu automatisieren. Aus den Annotationen der WSDL-Dateien sollen also nach Möglichkeit Oberflächen und Maskenabfolgen direkt generiert werden können. Die Demonstration eines WS-Prototyps wird von Systemanalytikern durchgeführt. Sie verwenden den Prototyp zur Erhebung und Validierung von Anforderungen in Gesprächen mit Stakeholdern. Systemanalytiker müssen dabei die Reaktionen der Stakeholder auf den Prototyp festhalten, um diese später auszuwerten. Hierbei soll eine Unterstützung durch ein Interviewwerkzeug zur Verfügung gestellt werden, mit dem die Kommentare zu einem WS-Prototyp erfasst werden können. Dieses Werkzeug soll außerdem die Auswertung der Demonstrationsergebnisse unterstützen. Die Ergebnisse des Prototypings fließen in die Anforderungen eines Projekts ein. Auch Anwendungsentwickler profitieren daher vom Prototyping mit Webservices. Definition 17(Anwendungsentwickler) Ein Anwendungsentwickler ist eine Person, die an der Implementierung der SOA-Portalanwendung beteilig ist, für die ein WS-Prototyp erstellt wird. Anwendungsentwickler ziehen den Nutzen des Prototypings aus einer höheren Qualität der Anforderungen. Außerdem können sie einen WS-Prototyp dazu verwenden, die in der Anforderungsspezifikation dokumentierten Anforderungen anhand des Prototyps nachzuvollziehen. Ein WS-Prototyp kann z.b. als Entwurfsgrundlage für die Gestaltung einer Portaloberfläche dienen oder als Referenz bei der Schnittstellendefinition von neu zu entwickelnden Webservices Phasen des Prototyping-Prozesses mit Webservices Der Prototyping-Prozess wird auf Basis der Ziele und Anforderungen in drei Phasen unterteilt. In Abbildung 3.2 sind diese drei Phasen sowie der Informationsfluss zwischen den Phasen mit Hilfe der Flow-Notation [SL05] dargestellt. Die erste Phase wird als Annotationsphase bezeichnet. Sie umfasst die Vorbereitung von 27

33 3. Der Prototyping-Prozess mit Webservices Abbildung 3.2.: Informationsfluss im Prototyping-Prozess Webservices für das Prototyping. Diese Phase soll für jeden Webservice nur einmal durchlaufen werden. Das Ergebnis der Annotationsphase sind Prototyping-Dateien. Sie enthalten Oberflächen- und Workflowbeschreibungen für einen Webservice. Eine Prototyping-Datei wird in einem XML-Format erstellt und mit der WSDL-Datei des jeweiligen Webservices verlinkt. Durch die Verwendung der Annotationen wird der Aufwand bei der Entwicklung eines WS- Prototyps reduziert. Die zweite Phase des Prototyping-Prozesses ist die Entwicklungsphase eines WS-Prototyps. Diese Phase ist in die Analysephase eines SOA-Portalprojekts integriert. Mit Hilfe von annotierten WSDL-Dateien und auf Basis der bereits erhobenen Anforderungen von Stakeholdern erstellen Prototypentwickler einen WS-Prototyp. Sie können dabei beliebige Webservices von unterschiedlichen Anbietern miteinander kombinieren. Die dritte Phase wird als Auswertungsphase bezeichnet. Der zuvor erstellte Prototyp wird während dieser Phase den Stakeholdern des Projekts präsentiert. Die Ergebnisse, die bei der Auswertung erzielt werden, fließen in die Anforderungen ein. Außerdem können die Ergebnisse dazu verwendet werden, den WS-Prototyp zu modifizieren. Eine Veränderung des Prototyps macht Sinn, wenn dieser zu weiteren Auswertungen genutzt werden soll. Ein typisches Anwendungsszenario wäre z.b. die Validierung der in einer ersten Auswertung erhobenen Anforderungen. 28

34 3.4. Zusammenfassung 3. Der Prototyping-Prozess mit Webservices In diesem Kapitel wurden die Ziele für das Prototyping mit Webservices definiert. Mit Hilfe der zu entwickelnden WS-Prototypen soll die Auswahl geeigneter Webservices für eine SOA-Portalanwendung unterstützt werden, es sollen Kommunikationsproblemen zwischen Stakeholdern und Systemanalytikern bei der Anforderungserhebung minimiert werden, das Erfassen von Oberflächenanforderungen soll verbessert werden und die Darstellung von Arbeitsabläufen von Benutzern soll ermöglicht werden, um Systemanalytikern das Verständnis dieser Arbeitsabläufe zu erleichtern. Auf Basis der Ziele wurden Anforderungen an die Prototypen und den Prototyping-Prozess erhoben. Der Prozess wurde daraufhin in drei Phasen unterteilt: Die Annotationsphase, in der WSDL-Dateien mit zusätzlichen Informationen für das Prototyping versehen werden, um die Entwicklung von WS-Prototypen zu erleichtern. Die Entwicklungsphase, die in die Analysephase eines Projekts integriert ist und die Entwicklung eines WS-Prototyps umfasst. Die Auswertungsphase, die ebenfalls während der Analysephase eines Projekts stattfindet, und die die Präsentation und Auswertung eines WS-Prototyps beinhaltet. In den folgenden Kapiteln werden die einzelnen Phasen des Prototyping-Prozesses genauer definiert und beschrieben. 29

35 4. Annotation von WSDL-Dateien In diesem Kapitel wird die Annotationsphase des Prototyping-Prozesses vorgestellt. Es wird zunächst erläutert, warum die Informationen in WSDL-Dateien nicht ausreichen, um damit schnell und einfach oberflächenintensive Prototypen zu entwickeln. Abbildung 4.1.: Die Annotationsphase des Prototyping-Prozesses Anschließend werden Modelle definiert, mit denen sich die fehlenden Informationen erstellen und mit den WSDL-Dateien verknüpfen lassen. Es wird dazu ein Metamodell definiert, mit dem Workflows auf Basis von Webservicenachrichten modelliert werden können. Des Weiteren werden Metamodelle zur Beschreibung von XML-Schemata und Oberflächenelementen vorgestellt. Auf Basis dieser Modelle werden Transformationsalgorithmen definiert, mit denen für die Nachrichten eines Webservices abstrakte Oberflächenbeschreibungen erzeugt werden können. Die Algorithmen können dazu verwendet werden, den Annotationsprozess z.t. zu automatisieren. Es wird dazu erläutert, welche Informationen sich generieren lassen und an welchen Stellen WS-Analytiker manuell in den Prozess eingreifen müssen. Am Ende des Kapitels wird eine WSDL-Erweiterung vorgestellt, mit der sich Oberflächen- und Workflowbeschreibungen zusammen mit einer WSDL-Dateien veröffentlichen lassen Problembeschreibung Webservices stellen häufig eine große Anzahl von Operationen mit unterschiedlicher Funktionalität zur Verfügung. Ein Prototypentwickler muss entscheiden, welche dieser Operationen er in einem WS-Prototyp verwenden will. Dazu muss er zunächst herausfinden, welche Funktionalität eine Operation zur Verfügung stellt. Eine WSDL-Datei gibt jedoch lediglich darüber Aufschluss, welche Parameter für den Aufruf einer Operation benötigt werden und welche Rückgabewerte diese liefert. Semantische Beschreibungen von Operationen sind nicht Bestandteil des WSDL- Formats. Der Zweck einer Operation kann daher meisten nur ihrem Namen entnommen werden. 30

36 4. Annotation von WSDL-Dateien Webserviceanbieter haben die Möglichkeit, die verschiedenen Elemente in einer WSDL-Datei zu dokumentieren, um ihre Webservices auch für Menschen verständlicher zu beschreiben. Jede Operation kann mit einem solchen Dokumentationselement versehen werden. Webserviceanbieter machen jedoch von dieser Möglichkeit nur selten Gebrauch. In der WSDL-Datei des Amazon-Webservices [Ama04] z.b. ist keine einzige Operation dokumentiert. Werden für Operationen sprechende Namen verwendet, so liefern diese meistens einen Hinweis darauf, für welchen Zweck die Operation verwendet werden kann. Der Operationsname AddToCart eines Online-Bestellservices z.b., lässt darauf schließen, dass mit der entsprechenden Operation Artikel in einen Warenkorb gelegt werden können. Stammen die Webservices aus einer bekannten Domäne, wie die des Online-Handels, helfen die Operationsnamen häufig beim Verständnis von WSDL-Dateien. Ist ein Prototypentwickler aber mit Webservices aus einer ihm fremden Domäne konfrontiert oder werden weniger sprechende Namen verwendet, so kann er den Operationen wahrscheinlich nicht einfach eine Bedeutung zuordnen. Häufig wird bei einer Kommunikation mit einem Webservice nicht nur eine Operation aufgerufen, sondern es sind mehrere Operationsaufrufe hintereinander, in einer bestimmten Reihenfolge erforderlich. Allgemein bezeichnet man die Abfolge von mehreren Arbeitsschritten als einen Workflow [DJM05]. Da für das Prototyping Workflows auf Basis von Webservicenachrichten beschrieben werden, werden diese als WSMessageWorkflows bezeichnet. Definition 18 (WSMessageWorkflow) Ein WSMessageWorkflow ist ein Workflow, der durch eine Folge von Webservicenachrichten definiert ist. Ein WSMessageWorkflow ist kein automatisierter Workflow, sondern es sind Benutzerinteraktionen innerhalb des Workflows erforderlich. Deshalb wird ein WSMessageWorkflow mit Hilfe von Oberflächen modelliert, welche die Webservicenachrichten visualisieren. Ein WSMessage- Workflow kann daher beim Prototyping mit Webservices dazu verwendet, Oberflächenmasken und deren Abfolgen zu modellieren. Mit dem WSDL-Format ist es jedoch nicht möglich, einen WSMessageWorkflow zu beschreiben. Jede in einer WSDL-Datei definierte Operation ist unabhängig von den anderen, d.h. es lässt sich nur eine Abfolge von maximal zwei Nachrichten festlegen (siehe hierzu Kapitel 2.3.3). Die Business Process Execution Language (BPEL) [BBE + 07] hat sich in den letzten Jahren als Standard etabliert, um Geschäftsprozesse auf Basis von Webservices zu modellieren und auszuführen. Mit BPEL lassen sich Operationen von mehreren Webservices zu einem Workflow kombinieren. BPEL ist jedoch eine sehr komplexe Sprache, die häufig dafür kritisiert wird, zu kompliziert zu sein, um damit schnell und einfach Prozessabläufe zu modellieren. Für das Prototyping mit Webservices ist es jedoch wichtig, dass Workflows sowohl einfach als auch schnell modelliert und ausgewertet werden können. Von daher ist BPEL zum Modellieren von WSMessageWorkflows nicht geeignet. In dieser Arbeit wird deshalb ein einfaches Modell entwickelt, mit dem sich WSMessage- Workflows erstellen lassen. Für einen Webservice können damit in der Annotationsphase des Prototyping-Prozesses Workflowbeschreibungen definiert und mit den WSDL-Dateien verknüpft werden. Die Workflowbeschreibungen erleichtern den Prototypentwicklern die Arbeit, indem sie typische Prozesse für einen Webservice definieren und beschreiben. Sie können bei der Entwicklung eines WS-Prototyps dazu genutzt werden, die zu verwendenden Operationen zu identifizieren und die Reihenfolge von Oberflächenmasken für einen Workflow festzulegen. Ein Prototypentwickler muss bei der Entwicklung eines WS-Prototyps nicht nur die Reihenfolge von Oberflächenmasken bestimmen, sondern er muss auch entscheiden, wie die einzelnen Oberflächen gestaltet werden. Dabei ist wichtig, dass die Oberflächen zu den Webservicenach- 31

37 4. Annotation von WSDL-Dateien richten passen. In WSDL-Dateien sind jedoch keine Informationen enthalten, die Auskunft darüber geben, wie ein Eingabeformular für eine Nachricht oder die Präsentation des Inhalts einer Nachricht aussehen könnte. Ohne zusätzliche Annotationen stehen Prototypentwicklern also nur die innerhalb einer WSDL-Datei definierten Datenstrukturen der Nachrichten zur Verfügung. Beim WSDL 1.0 Standard sind diese Datenstrukturen durch XML-Schemata beschrieben. Damit ein Prototypentwickler nicht bei jeder Entwicklung eines WS-Prototyps erneut die XML- Schema-Beschreibungen der Webservicenachrichten analysieren muss, werden die WSDL- Dateien um Oberflächenbeschreibungen erweitert. Für jede Nachricht eines Webservices soll eine solche Oberflächenbeschreibung definiert werden können. Dabei werden Inhalt und Layout voneinander getrennt modelliert, um mit einer Oberflächenbeschreibung verschiedene Nachrichteninhalte darstellen zu können. Die Oberflächenbeschreibungen werden ebenso wie die WSMessageWorkflow-Beschreibungen mit der WSDL-Datei eines Webservices verknüpft und veröffentlicht. Sie werden daher ebenfalls in der Annotationsphase des Prototyping-Prozesses von WS-Analytikern erstellt. In den folgenden Unter-Kapiteln werden Modelle für WSMessageWorkflow- und Oberflächenbeschreibungen vorgestellt. Außerdem werden Algorithmen definiert, mit denen sich XML- Schemata in diese Beschreibungen transformieren lassen WSMessageWorkflows Ein WSMessageWorkflow definiert einen Workflow auf Basis von Webservicenachrichten. Die einzelnen Arbeitsschritte in einem WSMessageWorkflow werden durch Oberflächen visualisiert, die diese Nachrichten repräsentieren. Innerhalb der Abfolge dieser Oberflächen finden Benutzerinteraktionen und Webserviceaufrufe statt. (a) Workflow mit zwei Arten von Links (b) Workflow mit einer Link-Art Abbildung 4.2.: Modellierungsvarianten von Workflowbeschreibungen auf Basis von Webservicenachrichten Die einfachste Art einen Workflow mit Webservicenachrichten darzustellen, ist in Abbildung 4.2(a) veranschaulicht. Für jede Webservicenachricht wird dabei eine separate Oberfläche erstellt. Bei dieser Art der Modellierung existieren zwei Arten von Links zwischen den Oberflächen. Die durchgezogenen Pfeile in Abbildung 4.2(a) stellen Operationsaufrufe des Webservices dar, der gestrichelte Pfeile repräsentiert einen Übergang zwischen zwei Oberflächen, bei dem keine Interaktion mit dem Webservice erfolgt. Zwei Oberflächen, die durch einen solchen Link verbunden sind, können in einer Client-Anwendung zu einer Oberfläche zusammengefasst werden. Dies ist in Abbildung 4.2(b) dargestellt. Innerhalb eines WSMessageWorkflow repräsentiert jeder Link einen Operationsaufruf. Es werden also nur solche Modelle wie das in Abbildung 4.2(b) modelliert. In Abbildung 4.3 ist das Metamodell für WSMessageWorkflows als UML- Klassendiagramm [Obj07] dargestellt. Ein WSMessageWorkflow besteht aus einer Menge von 32

38 4. Annotation von WSDL-Dateien Abbildung 4.3.: Metamodell für WSMessageWorkflows WSViews und eine Menge von WSLinks. Eine WSView repräsentiert eine Oberfläche und ein WSLink einen Link zwischen genau zwei dieser Oberflächen. Jede WSView visualisiert ein oder mehrere Nachrichten eines Webservices, die so genannten Message Elemente. Mit einem WSMessageWorkflow können sowohl rein sequentielle Abfolgen von Oberflächenmasken als auch alternative Pfade modelliert werden. (a) Verzweigung (b) Vereinigung Abbildung 4.4.: Kontrollflussstrukturen in WSMessageWorkflow Graphen Formal gesehen ist ein WSMessageWorkflow ein gerichteter Graph mit einem definierten Anfangsknoten. Die Menge der Knoten wird durch die Menge der WSViews gebildet, die Kantenmenge durch die WSLinks. Abbildung 4.4 zeigt den möglichen Kontrollfluss in einem WSMessageWorkflow. Ein Knoten kann mehrere ausgehende Kanten besitzen und er kann das Ziel von mehreren Kanten sein. Besitzt ein Knoten, wie in Abbildung 4.4(a) veranschaulicht, mehrere ausgehende Kanten so bezeichnen wir ihn als Verzweigungsknoten. Ein Verzweigungsknoten modelliert eine Oberfläche, die mehrere Navigationsmöglichkeiten anbietet. Die ausgehenden Links repräsentieren dementsprechend verschiedene Operationsaufrufe. Je zwei ausgehende Links eines Verzweigungsknoten stellen paarweise unterschiedliche Webserviceoperationen dar. Ist ein Knoten, wie in Abbildung 4.4(b) gezeigt, das Ziel von mehreren Kanten, so wird dieser 33

39 4. Annotation von WSDL-Dateien Knoten als Vereinigungsknoten bezeichnet. Ein Vereingungsknoten modelliert eine Oberfläche, die von mehreren anderen Oberflächen aus erreicht werden kann. Alle Kanten, die in einem Vereinigungsknoten enden, repräsentieren dieselbe Webserviceoperation. Es wird gefordert, dass in einem WSMessageWorkflow keine zwei WSView-Elemente existieren, die dieselbe Menge von Message-Elementen repräsentieren. Innerhalb einer Maskenabfolge in einer Client-Anwendung kann eine Oberfläche jedoch mehrfach auftreten. In einem WS- MessageWorkflow wird die Modellierung einer solchen Wiederholung von Oberflächen durch die Definition von WSLinks ermöglicht, mit denen ein Zyklus modelliert wird. Abbildung 4.5.: Ein Zyklus in einem WSMessageWorkflow Graph In Abbildung 4.5 ist ein WSMessageWorkflow mit einem Zyklus dargestellt. Eine mögliche Maskenabfolge, die durch diesen Workflow modelliert wird, ist z.b. die Folge View_1, View_2, View_3, View_5, View_2, View_4. Theoretisch lässt sich ein Zyklus beliebig oft durchlaufen. Auf die Definition einer Abbruchbedingung wird dennoch verzichtet, da bei einer Maskenabfolge aus dem Kontext und dem zugrunde liegenden Prozess hervorgehen sollte, in welchem Fall der Zyklus durchlaufen und wann er unterbrochen wird. Jeder WSLink eines WSMessageWorkflows kann mit einer Bedingung, einem so genannten condition Attribut, versehen werden. Mit Hilfe des condition Attributs kann ein Link näher beschrieben werden. Es sollte eine kurze, semantische, für Menschen verständliche Beschreibung der Navigationsmöglichkeit beinhalten. In WSMessageWorkflows werden keine Rückwärtsschritte in einer Maskenabfolge modelliert. Für die Rückwärtsnavigation in einem Client ist kein Operationsaufruf eines Webservices erforderlich. Es findet lediglich der Übergang zwischen zwei Oberflächen statt. Die WSLinks in einem WSMessageWorkflow stellen jedoch immer Operationsaufrufe dar. Ob und wann in einem Client eine vorausgegangene Oberfläche aufgerufen wird, ist deshalb für die Semantik der Workflows nicht interessant. Mit einem WSMessageWorkflow können nicht nur Maskenabfolgen für einen einzelnen Webservice modelliert werden, sondern es sind auch Workflows darstellbar, die Nachrichten von verschiedenen Webservices nutzen. Auf diese Weise können Workflows für Geschäftsprozesse definiert werden, die durch mehrere Webservices unterstützt werden. Die Modellierung eines Workflows mit mehreren Webservices unterscheidet sich nicht von der Modellierung mit nur einem Service. Es muss lediglich der Bezug der Message-Elemente zu einem Webservice- Element mit modelliert werden. In der Annotationsphase des Prototyping-Prozesses werden zunächst nur Workflows für einen Webservice erstellt, die mit einer einzelnen WSDL-Dateien verlinkt werden können. WS- Analytiker wissen nicht, welche Webservices später in einem Projekt miteinander kombiniert 34

40 4. Annotation von WSDL-Dateien werden sollen. Die Annotationen sollen aber wieder verwendbar sein und sich in unterschiedlichen Projekten nutzen lassen. Deshalb wird in der Annotationsphase darauf verzichtet, WS- MessageWorkflows zu definieren, die mehrere Webservices verwenden. Prototypentwickler können in der Entwicklungsphase des Prototyping-Prozesses WSMessageWorkflows einzelner Webservices dazu benutzen, einen neuen, zusammengesetzten Workflow zu erstellen. Ein WSMessageWorkflow kann sehr komplex werden, wenn viele alternative Maskenabfolgen modelliert werden. Der entsprechende Graph enthält in diesem Fall viele Verzweigungs- und Vereinigungsknoten. Jeder WSMessageWorkflow mit mehr als einer möglichen Maskenabfolge lässt sich auch als eine Menge von sequentiellen Workflows darstellen. Für jeden Pfad durch den zugehörigen Graphen wird dafür ein eigener WSMessageWorkflow definiert. Ob ein komplexer oder mehrere, einfache WSMessageWorkflows definiert werden, sollte von der Semantik der abzubildenden Prozesse abhängig gemacht werden. Die Operationen eines Webservices unterstützen bestimmte Abläufe in einem Geschäftsprozess. Stellen zwei Pfade in einem WS- MessageWorkflow unabhängige Abläufe dar, deren Tätigkeiten vielleicht sogar von verschiedenen Benutzer ausgeführt werden, so sollten diese besser als zwei separate WSMessage- Workflows modelliert werden. Repräsentieren zwei oder mehrere Pfade jedoch Workflows eines Geschäftsprozesses, die im selben Kontext vom selben Benutzer ausgeführt werden, so sollten diese mit Hilfe von Verzweigungsknoten innerhalb eines einzigen WSMessageWorkflows modelliert werden. <porttype name="wsorderport"> <operation name="keywordsearchrequest"> <input message="typens:keywordsearchrequest"/> <output message="typens:keywordsearchresponse"/> </operation> <operation name="addshoppingcartitemsrequest"> <input message="typens:addshoppingcartitemsrequest"/> <output message="typens:shoppingcartresponse"/> </operation> <operation name="getdetails"> <input message="typens:showdetailsrequest"/> <output message="typens:showdetailsresponse"/> </operation> <operation name="submitshoppingcart"> <input message="typens:submitshoppingcartrequest"/> <output message="typens:submitshoppingcartresponse"/> </operation> </porttype> Listing 4.1: Auszug aus einer WSDL-Datei eines Online-Bestellservices In Listing 4.1 ist der Ausschnitt einer WSDL-Datei eines Online-Bestellservices dargestellt. Dieser Online-Bestellservice soll im weiteren Verlauf als Beispiel dienen, um die Konzepte zur Modellierung von WSMessageWorkflows und Oberflächenbeschreibungen zu veranschaulichen. Der Beispiel-Service ist auf der Grundlage des AmazonSearchServices [Ama04] entstanden. Die WSDL-Datei dieses Services wurde an einigen Stellen angepasst, um die jeweils wichtigen Aspekte des Annotations-Prozesses zu betonen. Der Online-Bestellservice ermöglicht die Suche von Artikel, die Abfrage von Detailinformationen zu einem bestimmten Artikel sowie das Befüllen und das Bestellen eines Warenkorbs. Abbildung 4.6 zeigt einen WSMessageWorkflow zu dem in Listing 4.1 gezeigten Ausschnitt der WSDL-Datei. Es werden vier WSViews sowie zwei alternative Pfade modelliert. Die Message Elemente des Webservices, die von den einzelnen Oberflächen repräsentiert werden, sind aus 35

41 4. Annotation von WSDL-Dateien Abbildung 4.6.: Ein WSMessageWorkflow für den Online-Bestellservice Übersichtlichkeitsgründen nicht dargestellt. Die erste Oberfläche ( SearchForm ) zeigt ein Suchformular, das die KeywordSearchRequest -Nachricht darstellt. Die zweite Oberfläche, die SearchResults -Oberfläche repräsentiert die Antwortnachricht des Webservices, die KeywordSearchResponse -Nachricht, sowie die beiden input-nachrichten ShowDetailsRequest und AddShoppingCartItemsRequest. Auf der SearchResults -Oberfläche hat ein Benutzer also die Wahl zwischen zwei Navigationsalternativen. Über den Link ShowDetails gelangt er zur Detailseite eines bestimmten Artikels. Dieser Link repräsentiert die GetDetails -Operation des Webservices. Die Oberfläche Details visualisiert dementsprechend die ShowDetailsResponse -Nachricht. Wählt ein Benutzer statt des GetDetails -Links den Link AddToCart1, so legt er einen Artikel in den Warenkorb. Mit diesem Link wird die AddShoppingCartItemsRequest -Operation modelliert. Dieselbe Operation wird in dem WSMessageWorkflow noch ein zweites Mal dargestellt. Von der Details -Oberfläche aus hat ein Benutzer ebenfalls die Möglichkeit, den dort angezeigten Artikel in den Warenkorb zu legen. Die Oberfläche ShoppingCart zeigt den aktuellen Warenkorb. Von hieraus kann ein Benutzer über den Link OrderCart, der die SubmitShoppingCart -Operation modelliert, den Warenkorbinhalt bestellen. Er bekommt daraufhin eine Bestellbestätigung ( FulfilmentConfirmation ) angezeigt, die die Antwort des Webservices, die SubmitShoppingCartResponse - Nachricht, visualisiert. 36

42 4. Annotation von WSDL-Dateien 4.3. Ansätze zur Oberflächengestaltung Bekannte Ansätze Mit Hilfe von WSMessageWorkflows kann eine Reihenfolge von Webservicenachrichten definiert werden, zu denen beim Prototyping Oberflächen erstellt werden können. Es fehlen nun noch Informationen darüber, wie diese Oberflächen im Einzelnen gestaltet werden können, d.h. welchen Inhalt sie darstellen und wie sie diesen präsentieren. Als Basis für die Gestaltung der Oberflächen dienen die XML-Schemata, mit denen die Webservicenachrichten definiert sind. Um den Aufwand beim Prototyping so gering wie möglich zu halten, sollen sowohl in der Annotationsphase als auch bei der späteren Entwicklung eines WS-Prototyps so viele Informationen wie möglich generiert werden. Es existieren bereits einige Ansätze, die sich mit der (automatischen) Transformation von XML-Schemata in Oberflächen befassen. Im Folgenden werden die wichtigsten dieser Konzepte kurz vorgestellt und auf ihre Eignung für das Prototyping mit Webservices hin untersucht. Die Webservices User Interface Initiative (WSUI) [Anu01] entwickelte im Jahr 2001 ein Konzept, das Webservices um zusätzliche Interaktions- und Präsentationsinformationen anreichern sollte. Ihr Ziel war es, einen Standard zu schaffen, der es ermöglicht, Webservices einfach und schnell zur Laufzeit in Webseiten zu integrieren. Standard XML-Technologien wie XSLT, XPath und XHTML sollten die Basis für diesen Standard bilden. Von der WSUI existieren nur noch ein paar vereinzelte Artikel, die Webseite, sowie die damals online gestellte Draft-Spezifikation sind nicht mehr verfügbar. Die Ideen dieses Ansatzes können daher nicht in das Prototyping Vorgehensmodell einfließen. XsdTransformer [Moe08] ist ein Projekt, welches mit Hilfe eines XSLT-Stylesheets XForms Komponenten für ein gegebenes XML-Schema generiert. Diese Komponenten können in eine XHTML-Seite eingebettet werden. Für die Generierung werden eine Reihe verschiedener Transformationsvorschriften verwendet. Das xsdtransformer-projekt arbeitet auf einem einzelnen XML-Schema. WSDL-Dateien enthalten jedoch häufig eine Reihe von Schemata, welche einander referenzieren. Um das xsdtransformer-konzept zu nutzen, wäre es denkbar, diese verschiedenen Schemata in einem Vorverarbeitungsschritt zu einem einzigen Schema zu kombinieren. In diesem Fall müssten allerdings Namensräume bei der Transformation berücksichtigt werden, um Namenskonflikte zu vermeiden. Das XSLT-Stylesheet des xsdtransformers arbeitet jedoch ohne Namensräume. Ebenfalls problematische für den in dieser Arbeit gewählten Ansatz ist die Verwendung von XHTML und XForms als Zielsprache der Generierung. Um die Webservices auf einer Webseite zu integrieren und flexibel austauschen zu können, wird für das Prototyping mit Webservices ein AJAX-Framework benutzt. Das verwendete Framework GWT, das in Kapitel vorgestellt wird, kann keine XHTML-Komponenten integrieren. In [LLK04] wird beschrieben, wie XML-Schemata in Java Swing Oberflächen transformiert werden können. Für SOA-Portalanwendungen mit Weboberflächen sind Java Swing Oberflächen jedoch nicht die beste Wahl für das Oberflächen-Prototyping. Ein weiteres Konzept, das sich mit der Erzeugung von Oberflächen aus WSDL-Dateien befasst, ist das Web Services Graphical User Interface (WSGUI) Konzept [KKM03]. Dieser XML-basierte Ansatz verfolgt die Idee, den Elementen von Webservicenachrichten abstrakte Oberflächenkomponenten zuzuordnen. Diese können zur Generierung von konkreten Dialogkomponenten genutzt werden. Das Ziel dieses semi-automatischen Konzepts ist es, dass Anwendungsentwickler schnell und einfach Oberflächendialoge für die Kommunikation mit einem Webservice 37

43 4. Annotation von WSDL-Dateien erstellen können. Der Fokus liegt dabei auf der Generierung von Formularen und weniger auf der Präsentation der Antwortnachrichten. Für die Generierung von Oberflächen werden so genannte GUI Deployment Descriptoren (GUIDD) erstellt. In einer GUIDD-Datei kann jedem Element einer Webservicenachricht eine formcomponent zugeordnet werden. FormComponents beschreiben mit Hilfe von XForms- Komponenten sowie einigen weiteren Attributen ein Oberflächenelement. FormComponents können mit einer WSGUI-Engine in konkrete Sprachen transformiert werden. Das WSGUI-Konzept wurde in den letzte Jahren stetig weiterentwickelt und um Werkzeugunterstützung ergänzt. Für das Erstellen der GUIDD-Dateien existiert ein Editor, der Unterstützung bei dieser Tätigkeit bietet [Spi06]. Die meiste Arbeit beim Erstellen dieser Dateien muss allerdings manuell geleistet werden. Dynvoker [SKS + 06] ist ein Projekt der Universität Dresden, welches verschiedene Bibliotheken zur Unterstützung des WSGUI-Konzeptes bereitstellt. U.a. wurde in diesem Projekt eine WSGUI-Engine entwickelt, die GUIDD-Komponenten in XForms-Komponenten transformiert. Neben der Generierung von XForms-Komponenten aus GUIDD-Dateien kann die zur Verfügung gestellte Software z.t. auch XForms Komponenten direkt aus XML-Schema Elementen generieren. Dieser Transformationsansatz wird in [SS07] beschrieben. Das WSGUI-Prinzip unterscheidet sich von den anderen hier vorgestellten Ansätzen durch die Einführung einer zusätzlichen Abstraktionsschicht, den GUIDD-Dateien. Mit diesen Dateien können XML-Schemata um zusätzliche Informationen angereichert werden, die bei der Generierung von Oberflächen genutzt werden können. Die Oberflächen sind dadurch weniger generisch, der Transformationsprozess wird allerdings aufwändiger Ein- und Zwei-Phasen-Transformation Die im letzten Kapitel vorgestellten Ansätze zur Transformation von XML-Schemata in Oberflächenbeschreibungen lassen sich anhand der Anzahl von Transformationsschritten in zwei Klassen unterteilen. Ein-Phasen-Transformation Bei der Ein-Phasen-Transformation wird ein XML-Schema direkt in eine konkrete Zielsprache wie beispielsweise HTML transformiert. Das xsdtransformer- Konzept sowie der Ansatz zur Generierung von Java Swing Oberflächen gehören zu dieser Klasse von Transformationen. Das Prinzip einer Ein-Phasen-Transformation ist in Abbildung 4.7(a) veranschaulicht. Zwei-Phasen-Transformation Bei einer Zwei-Phasen-Transformation wird aus einem XML- Schema zunächst ein Zwischenprodukt erzeugt. Dieses wird anschließend in eine konkrete Oberfläche transformiert. Das WSGUI-Prinzip lässt sich in diese Klasse von Transformationen einordnen. Die GUIDD-Dateien stellen das Zwischenprodukt dar. Das Prinzip einer Zwei-Phasen-Transformation wird in Abbildung 4.7(b) verdeutlicht. Der einphasige Ansatz erscheint auf den ersten Blick weniger aufwändig als der zweiphasige. Mit Hilfe eines XSLT-Stylesheets können z.b. HTML-Elemente aus einem Schema generiert werden, die direkt in einen WS-Prototyp integriert werden können. Eine solche Transformation könnte entweder in der Annotationsphase oder in der Entwicklungsphase des Prototyping- Prozesses erfolgen. 38

44 4. Annotation von WSDL-Dateien (a) Ein-Phasen-Transformation (b) Zwei-Phasen-Transformation Abbildung 4.7.: Transformationsprinzipien für die Erzeugung von Oberflächen aus XML- Schemata Werden die Oberflächen bei der Annotation erstellt, so können sie mit den WSDL-Dateien verknüpft und in verschiedenen Prototypen verwendet werden. Der Nachteil dieses Verfahrens ist, dass bereits im Vorfeld eine gewisse Menge von unterschiedlichen Oberflächen erzeugt werden muss, um verschiedene Inhalte einer Webservicenachricht zu präsentieren. Es können so schnell sehr viele verschiedene Oberflächenbeschreibungen entstehen, die die Auswahl bei der Prototypentwicklung erschweren. Zudem muss bereits in der Annotationsphase eine konkrete Oberflächensprache verwendet werden. Dadurch wird ein Prototyp auf diese Sprache beschränkt. Die zweite Möglichkeit, eine einphasige Transformation beim Prototyping zu verwenden, besteht darin, die Transformation erst in der Entwicklungsphase durchzuführen. In diesem Fall erhöht sich jedoch nicht nur der Aufwand der Prototypentwicklung, es geht auch der Vorteil verloren, Oberflächenbeschreibungen wieder zu verwenden. Werden die Oberflächen erst bei der eigentlichen Entwicklung eines Prototyps aus den XML-Schema Informationen erstellt, so müssen verschiedene Prototypentwickler immer wieder die gleiche Arbeit leisten. Mit dem zweiphasigen Ansatz werden diese Probleme vermieden. In der Annotationsphase können abstrakte Oberflächenbeschreibungen für jede Webservicenachricht erstellt werden. Diese Beschreibungen können mit den WSDL-Dateien verlinkt und so von verschiedenen Prototypentwicklern genutzt werden. Die Prototypentwickler sind zudem auf keine konkrete Sprache festgelegt. Die abstrakten Oberflächenbeschreibungen können in unterschiedliche Sprachen transformiert werden. Durch die zweiphasige Transformation wird außerdem die Darstellung verschiedener Nachrichtenstrukturen durch eine Oberflächenbeschreibung ermöglicht. In den abstrakten Oberflächenbeschreibungen können z.b. optionale Elemente gekennzeichnet werden. Im zweiten Transformationsschritt kann dann entschieden werden, ob die optionalen Elemente erzeugt werden oder nicht. Auch für die Darstellung verschiedener Nachrichteninhalte wird beim zweiphasigen Ansatz nur eine Oberflächenbeschreibung benötigt. Die abstrakte Oberflächenbeschreibung kann so gestaltet werden, dass sie lediglich eine Strukturbeschreibung der Oberfläche enthält. Die Inhalte werden in einem separaten Datendokument gespeichert. Im zweiten Transformationsschritt 39

45 4. Annotation von WSDL-Dateien lassen sich dadurch verschiedene Datendokumente mit einer Oberflächenbeschreibung kombinieren. Aufgrund der gerade erläuterten Vorteile wird für das Prototyping mit Webservices ein zweiphasiger Transformationsansatz gewählt. WS-Analytiker erstellen in der Annotationsphase des Prototyping-Prozesses abstrakte Oberflächenbeschreibungen und Datendokumente für jede Webservicenachricht. Sie führen also den ersten Transformationsschritt aus. Die abstrakten Beschreibungen und Datendokumente werden mit den WSDL-Dateien verlinkt und in der Entwicklungsphase des Prototyping-Prozesses in konkrete Oberflächen transformiert. Durch diesen Prozess wird der Aufwand der Prototypentwicklung reduziert werden. Beide Transformationsschritte werden soweit wie möglich automatisiert. Um das Prototyping für SOA- Portalanwendungen zu unterstützen, wird als Zielsprache für die konkreten Oberflächen in dieser Arbeit HTML verwendet. Die abstrakten Beschreibungen können aber auch in andere Oberflächensprachen wie z.b. Java Swing transformiert werden. In Abbildung 4.8 ist das Prinzip der Transformation von WSDL-Dateien in HTML-Oberflächen dargestellt, das beim Prototyping mit Webservices verwendet wird. Abbildung 4.8.: Transformationsprinzip für das Prototyping mit Webservices Das WSGUI-Prinzip, das eine zweiphasige Transformation verwendet, wurde dafür konzipiert, dass Benutzer einzelne Operationen eines Webservices dynamisch nutzen können. Für das Prototyping ist es jedoch wichtig, dass die Darstellung einer Webservicenachricht individuell angepasst werden kann und dass verschiedene Nachrichten auf einer Oberfläche kombiniert werden können. Des Weiteren sollen Korrespondenzen zwischen Datenelementen verschiedener Webservicenachrichten durch Oberflächenelemente abgebildet werden können, um den Datenaustausch innerhalb von Workflows zu modellieren. Das GUIDD-Format ist für diesen Zweck nicht geeignet. In dieser Arbeit wurde deshalb ein Metamodell für Oberflächenbeschreibungen entwickelt, das speziell an die Anforderungen für das Prototyping angepasst wurde. Für jede Nachricht ei- 40

46 4. Annotation von WSDL-Dateien Abbildung 4.9.: Metamodell für WSMessageWorkflows mit Oberflächenbeschreibungen nes Webservices lässt sich mit diesem Modell eine Oberflächenbeschreibung definieren. Abbildung 4.9 zeigt das Metamodell der WSMessageWorkflows, das um Oberflächenbeschreibungen erweitert wurde. Eine Oberflächenbeschreibung besteht aus einer Menge von UIElements, die sich in zwei Kategorien einteilen lassen. FormElements sind Elemente, die eine Benutzereingabe ermöglichen, PresentationElements hingegen stellen Inhalte dar. In den folgenden Kapiteln werden FormElements und PresentationElements genauer definiert. Zuvor wird noch eine Formalisierung von XML-Schemata vorgenommen. Diese wird benötigt, um Transformationsalgorithmen zu definieren, mit denen XML-Schema Beschreibungen in die Oberflächenbeschreibungen transformiert werden können Metamodell für XML-Schemata XML-Schemata sind die Ausgangsbasis für das Erstellen von Oberflächenbeschreibungen für Webservicenachrichten. Es wird deshalb zunächst eine formale Definition des Aufbaus und der Struktur von XML-Schemata vorgenommen. Das in Abbildung 4.10 dargestellte Metamodell eines XML-Schemas ist auf der Basis des Metamodells von Lübke [Lü08] entstanden. Ein XML-Schema besteht aus Datentypen, so genannten DataTypes, und Elementen (Elements), welche in einem Instanzdokument zu diesem Schema vorkommen dürfen. Jedes Element repräsentiert genau einen der Datentypen des Schemas. Datentypen können entweder einfache Typen (SimpleTypes) oder komplexe Typen (ComplexTypes) sein. 41

47 4. Annotation von WSDL-Dateien Abbildung 4.10.: Metamodell für XML-Schemata Die einfachen Datentypen lassen sich in vier Klassen unterteilen: StringTypes bezeichnen Datentypen, die einfache Zeichenketten darstellen. NumericalTypes sind Datentypen, die einen nummererischen Typ, wie beispielsweise integer oder long repräsentieren. Alle Typen, die eine Zeit- oder Datumsangabe darstellen, werden als CalendarTypes bezeichnet. Schließlich gibt es noch Datentypen, die ein beliebiges Binärformat repräsentieren. Zu diesem BinaryType gehören die Datentypen base64binary und hexbinary des XML-Schemas. Der Datentyp anytype des XML-Schemas lässt sich keiner der vier Klassen zuordnen, da er beliebigen Inhalt darstellen kann. In der Tabelle 4.4 sind die eingebauten Datentypen des XML-Schemas den vier Klassen von einfachen Datentypen des Metamodells zugeordnet. Die Klassen werden bei der Transformation von XML-Schema-Elementen in Oberflächenelemente verwendet. Alle Elemente einer Klasse lassen sich durch gleiche oder ähnliche Oberflächenelemente repräsentieren. Neben den einfachen Datentypen können in einem Schema komplexe Datentypen definiert werden. Diese bestehen aus einer Menge von anderen Datentypen, die als subelements bezeichnet werden. In einem Sequence-Typ darf jedes Subelement mit einer beliebigen Häufigkeit auftreten. Bei einem All-Typ hingegen ist die Kardinalität jedes Subelements auf 0 oder 1 beschränkt. Ein Choice-Typ definiert eine Menge von Subelementen, von denen in einem Instanzdokument nur eins vorhanden sein darf. Ein komplexer Datentyp kann Attribute enthalten. Ein Attribute repräsentiert einen einfachen Datentyp. Im Prinzip ist ein Attribut nichts anderes als ein Subelement, das mit einer Häufigkeit von 0 oder 1 in einem komplexen Datentyp auftreten kann. 42

48 4. Annotation von WSDL-Dateien Datentyp im Metamodell StringType NumericalType CalendarType BinaryType eingebaute Datentypen des XML-Schemas string, normalizedstring, token, boolean, Name, QName, NCName, anyuri, language, ID, IDREF, IDREFS, ENTITY, ENTITIES, NOTATION, NMTOKEN, NMTOKENS byte, unsignedbyte, integer, positiveinteger, negativeinteger, nonnegativeinteger, nonpositiveinteger, int, unsignedint, long, unsignedlong, short, unsignedshort, decimal, float, double time, datetime, duration, date, gmonth, gyear, gyearmonth, gday, gmonthday base64binary, hexbinary, Tabelle 4.1.: Zuordnung der eingebauten Datentypen des XML-Schemas zu den Datentypklassen des Metamodells 4.5. Oberflächenbeschreibung mit Formularelementen Metamodell für Formularbeschreibungen Oberflächenelemente werden in Formular- und Präsentationselemente unterteilt. In diesem Kapitel werden zunächst die Formularelemente definiert, mit denen sich Oberflächenelemente für Benutzereingaben modellieren lassen. Dazu wurde ein Metamodell für Formularbeschreibungen entwickelt, das in Abbildung 4.11 dargestellt ist. FormElements, die Elemente zur Benutzereingabe, werden in Formularen, so genannten Forms zusammengefasst. Jedes FormElement besitzt ein label, das einen Bezeichner für das Eingabeelement enthält. Der Wert, den ein Benutzer in ein Formularelement eingibt, wird in dem Attribut value gespeichert. Mit dem Attribut maxvaluecount kann festgelegt werden, wie oft ein FormElement in einem Formular maximal vorhanden sein darf. Das Attribut minvaluecount gibt an, wie oft ein Element mindestens vorhanden sein muss. Ist der Wert des Attributs minvalue- Count 0, so ist das entsprechende Eingabeelement ein optionales Element. Der Wert dieses Eingabeelements muss in den Formulardaten also nicht zwingend vorhanden sein, d.h. ein Benutzer braucht dieses Feld nicht auszufüllen. Standardmäßig sind die Werte der beiden Attribute minvaluecount und maxvaluecount auf 1 gesetzt. Formularelemente lassen sich in mehrere Klassen unterteilen. Ein TextInput-Element stellt einen ein- oder mehrzeiligen Eingabebereich dar, in den ein Benutzer eine beliebige Zeichenkette eingeben kann. Über das Attribut rowcount wird die Anzahl der Eingabezeilen bestimmt. Ein SelectableElement ist ein Element, das ein Benutzer auswählen kann. Eine Checkbox beispielsweise gehört zu der Klasse der SelectableElements. Ein spezielles SelectableElement ist ein CalendarElement. Dieses ermöglicht einem Benutzer, ein bestimmtes Datum oder eine vorgegebene Zeit auszuwählen. Mit den SelectableElements können nur einfache Auswahlelemente modelliert werden. Um eine Menge von Elementen zu modellieren, von denen mehrere ausgewählt werden können, werden SelectionList-Elemente verwendet. Eine SelectionList besitzt eine items Liste. Jedes Element in dieser Liste ist ein Formularelement. Mit dem Attribut selectableitemcount wird die maximale Anzahl der Elemente festgelegt, die aus einer Auswahlliste in den Formulardaten vorhanden sein dürfen. Die letzte Klasse von Formularelementen 43

49 4. Annotation von WSDL-Dateien Abbildung 4.11.: Metamodell für Formularbeschreibungen sind BinaryUpload-Elemente. Diese ermöglichen es einem Benutzer, Daten im Binärformat in ein Formular einzugeben, also z.b. eine Graphik hochzuladen. Formularelemente können zu logischen Gruppen zusammengefasst werden. Dazu wird das Element InputGroup benutzt. Eine InputGroup kann zudem in Verbindung mit einer Selection- List oder einem SelectableElement dazu verwendet werden, die Auswahlmöglichkeit von einer zusammengehörigen Menge von Eingabeelementen zu modellieren. Neben den FormElements besitzt jedes Formular ein Submission-Element. Ein Submission- Element stellt ein Eingabeelement dar, über das ein Benutzer seine Eingaben in ein Formular bestätigt und sie zur weiteren Verarbeitung frei gibt Transformationsalgorithmus XSDToForm In der Annotationsphase des Prototyping-Prozesses sollen Formularbeschreibungen für Webservicenachrichten aus den XML-Schema Beschreibungen der Nachrichtenstruktur generiert werden. Dafür wurden Transformationsvorschriften entwickelt, mit denen die Datentypen eines XML-Schemas in Formularelemente transformiert werden können. In Listing 4.2 ist der Basis-Algorithmus XSDToForm für die Transformation eines Schema Elements in ein Formular dargestellt. Im Folgenden werden die einzelnen Transformationsvorschriften des Basis-Algorithmus erläutert: 1. Jedes Element eines XML-Schemas wird auf Basis seines Datentyps in ein FormElement transformiert. Das FormElement erhält ein label, das aus dem Namen des Elements ge- 44

50 4. Annotation von WSDL-Dateien Listing 4.2: Basis-Algorithmus XSDToForm transformxsdtoform(schemanode n){ if(n has StringType or n has NumericalType) generatetextinput(n); if(n has CalendarType) generatecalendarelement(n); if(n has BinaryType) generatebinaryupload(n); if(n has SequenceType or n has AllType){ inputgroup = generateinputgroup(n); for(all subelements e of n) inputgroup.add(transformxsdtoform(e)); } if(n has ChoiceType){ selectionlist = generateselectionlist(n); for(all subelements e of n) selectionlist.additem(transformxsdtoform(e)); selectionlist.setselectableitemcount = 1; } } bildet wird. 2. StringTypes und NumericalTypes werden in TextInput-Elemente transformiert. 3. Ein CalendarType wird zu einem CalendarElement. 4. Ein BinaryType wird in ein BinaryUpload-Element umgewandelt. 5. Für jeden Sequence-Typ und jeden All-Typ wird eine InputGroup erzeugt. Jedes Subelement wird entsprechend der Transformationsvorschriften behandelt. 6. Ein Choice-Typ wird in eine SelectionList transformiert. Der Wert des Attributs selectableitemcount wird auf 1 gesetzt. 7. Attribute werden wie einfache Datentypen entsprechend des Wertes ihres type-attributs transformiert. Mit dem Basis-Algorithmus XSDToForm können Webservicenachrichten in einfache Formularbeschreibungen transformiert werden. Alle Formularelemente einer Nachricht werden dazu in einem Form-Element zusammengefasst. Das Formular erhält gemäß den Regeln des Metamodells noch ein SubmissionElement. In Listing 4.3 ist das XML-Schema der SubmitShoppingCartRequest -Nachricht des Online- Bestellservice abgebildet. Eine SubmitShoppingCartRequest -Nachricht, die an den Webservice geschickt wird, muss entweder die Kundennummer oder die persönlichen Daten eines Kunden enthalten. Für diese Nachricht wird mit dem Algorithmus XSDToForm das in Abbildung 4.12 als UML-Objektdiagramm dargestellte Eingabeformular erzeugt. Bei der Transformation mit dem Basis-Algorithmus XSDToForm gehen einige Informationen des XML-Schemas verloren. Die Transformationsvorschriften berücksichtigen z.b. keine Kardinalitäten. Die Information, dass die Angabe des Geschlechts im Gegensatz zur Angabe des Geburtstags optional ist, ist in der Formularbeschreibung nicht mehr enthalten. Auch Vorgabewerte, wie z.b. die Einschränkung, dass bei der Geschlechtsangabe nur die beiden Werte Female und Male erlaubt sind, gehen verloren. 45

51 4. Annotation von WSDL-Dateien <xsd:complextype name="submitshoppingcartrequest"> <xsd:choice> <xsd:element name="customerid" type="xsd:string" /> <xsd:element name="customerdetails" type="personaldata" /> </xsd:choice> </xsd:complextype> <xsd:complextype name="personaldata"> <xsd:sequence> <xsd:element name="name" type="xsd:string"/> <xsd:element name="gender" minoccurs="0" type="gendertype" /> <xsd:element name="address" type="addresstype" /> <xsd:element name="birthday" type="xsd:date" /> </xsd:sequence> <xsd:complextype name="addresstype"> <xsd:sequence> <xsd:element name="street" type="xsd:string" /> <xsd:element name="city" type="xsd:string" /> <xsd:element name="postalcode" type="xsd:decimal" /> </xsd:sequence> </xsd:complextype> <xsd:simpletype name="gendertype"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="female" /> <xsd:enumeration value="male" /> </xsd:restriction> </xsd:simpletype> Listing 4.3: Nachrichtenformat für die input-nachricht SubmitShoppingCartRequest der Operation SubmitShoppingCart des Online-Bestellservices Abbildung 4.12.: Mit dem Basis-Algorithmus XSDToForm erzeugte Formularbeschreibung für die SubmitShoppingCartRequest -Nachricht des Online-Bestellservices 46

52 4. Annotation von WSDL-Dateien Diese Angaben sind aber für das Prototyping wichtig. Bei der Auswahl eines Webservices müssen die Daten, die zum Aufruf einer Operation benötigt werden, mit den vorhandenen Daten auf Anwenderseite verglichen werden. Ob diese zueinander passen oder nicht, ist ein entscheidendes Kriterium für die Auswahl von Webservices. Um entscheiden zu können, ob die Daten zueinander passen, muss bekannt sein, welche Daten auf jeden Fall in einer Nachricht an einen Webservice vorhanden sein müssen. Lässt der Webservice zudem nur bestimmte Werte als Eingabe zu, so müssen auch diese Werte mit den Werten der Daten auf Anwenderseite verglichen werden. Für das Prototyping sollen daher optionale Elemente und solche mit bestimmten Wertebereichen kenntlich gemacht werden können. Der Basis-Algorithmus XSDToForm wurde daher um die folgenden Transformationsvorschriften erweitert: 8. Kardinalitäten werden in einem XML-Schema durch die Attribute minoccurs und maxoccurs festgelegt. Der Wert dieser beiden Attribute wird in die Attribute minvaluecount und maxvaluecount des entsprechenden Formularelements transformiert. Das Attribut maxvaluecount kann also neben einem numerischen Wert auch den Wert unbounded erhalten. 9. Beschränkungen des Wertebereiches eines einfachen Datentyps können in XML- Schemata durch so genannte enumerations festgelegt werden. Enumerations werden in eine SelectionList mit einem selectableitemcount von 1 transformiert. Alle möglichen Werte aus der Enumeration werden dazu in ein SelectableElement umgewandelt. Diese werden der items Liste der SelectionList hinzugefügt. Eine weitere Möglichkeit mit XML-Schemata den Wertebereich eines numerischen Datentyps zu beschränken, ist die Angabe von mininclusive und maxinclusive Werten. Auch für diese Beschränkung kann ein SelectionList erzeugt werden. 10. In einem XML-Schema können Listentypen definiert werden. Listentypen sind einfache Datentypen, in denen eine bestimmte Menge von Werten enthalten sein darf. Die möglichen Werte der Liste können ebenfalls durch eine enumeration beschränkt sein. Ist dies der Fall, so kann ein Listentyp in eine SelectionList transformiert werden. Das Attribut selectableitemcount erhält den Wert der maximalen Listenlänge. Diese ist im XML-Schema durch das Attribut maxlength bestimmt. Mit dem erweiterten Algorithmus XSDToForm kann für die SubmitShoppingCartRequest - Nachricht das in Abbildung 4.13 dargestellte Formular erzeugt werden. Die Änderungen gegenüber der Transformation mit dem Basis-Algorithmus sind hervorgehoben. Für die Eingabe des Geschlechts wird statt eines einfachen Texteingabefelds eine Auswahlliste mit zwei SelectableElements erzeugt. Außerdem wird das Attribut minvaluecount auf 0 gesetzt, weil das Gender Element im Schema als optionales Element deklariert ist. Beide Änderungen sind für das Prototyping von Vorteil. Texteingabefelder suggerieren, dass beliebige Inhalte an den Webservice geschickt werden können. Wird stattdessen eine Auswahlliste dargestellt, so kann beim Prototyping gezeigt werden, dass nur bestimmte Dateneingaben bei der Nutzung des Webservices möglich sind. Die Angabe eines optionalen Elements ermöglicht es, dem Stakeholder zu zeigen, dass er die Daten für dieses Eingabefeld nicht zwingend benötigt, um den Webservice nutzen zu können. Bei der Annotation von WSDL-Dateien können WS-Analytiker mit Hilfe des erweiterten XSD- ToForm-Algorithmus Formularbeschreibungen für alle input-nachrichten eines Webservices erstellen. Diese Transformation lässt sich automatisieren und durch ein Werkzeug unterstützen. Die generierten Formularbeschreibungen können von WS-Analytikern modifiziert werden, um 47

53 4. Annotation von WSDL-Dateien Listing 4.4: Erweiterter Algorithmus XSDToForm transformxsdtoform(schemanode n){ if(n has StringType or n has NumericalType or n has CalendarType){ if(n hasrestrictedvalues) selectionlist = generateselectionlist(n); for (all values v of n) selectionlist.additem(generateselectableelement(v)); if(n is ListType) selectionlist.setselectableitemcount = listlength; else selectionlist.setselectableitemcount = 1; }... } z.b. Informationen hinzuzufügen, die nicht automatisch erzeugt werden können oder die nicht in den Schemata vorhanden sind. WS-Analytiker können z.b. die Label-Beschriftungen anpassen oder den Wert für das Attribut maxrowcount eines Texteingabefelds festlegen. Außerdem können sie ergänzenden Text in die Oberflächenbeschreibung einfügen. Dazu benötigen sie Präsentationselemente, die im nächsten Kapitel definiert werden. Abbildung 4.13.: Mit dem erweiterten Algorithmus XSDToForm erzeugte Formularbeschreibung für die SubmitShoppingCartRequest -Nachricht des Online-Bestellservices 4.6. Oberflächenbeschreibung mit Präsentationselementen Metamodell für Präsentationsbeschreibungen Präsentationselemente sind Oberflächenelemente, die Inhalte darstellen. Sie werden in einem WS-Prototyp in erster Linie zur Darstellung der output-nachrichten eines Webservices benötigt. Sie können aber auch dazu verwendet werden, um Formularbeschreibungen für input- Nachrichten um zusätzlichen Text zu ergänzen. Wie bei der Beschreibung der Formularelemen- 48

54 4. Annotation von WSDL-Dateien te wird in diesem Kapitel zunächst ein Metamodell für Präsentationsbeschreibungen definiert. Anschließend wird ein Algorithmus vorgestellt, mit dem sich XML-Schemata in Präsentationsbeschreibungen transformieren lassen. Mit einer einzigen Präsentationsbeschreibung für eine Webservicenachricht sollen alle schemakonformen Instanzdokumente für diese Nachricht dargestellt werden können. Bei der Darstellung sollen sowohl verschiedene Strukturen als auch unterschiedliche Inhalte berücksichtigt werden. Abbildung 4.14.: Metamodell für Präsentationsbeschreibungen Abbildung 4.14 zeigt das Metamodell für Präsentationsbeschreibungen. Eine Präsentationsbeschreibung besteht aus einzelnen Präsentationselementen, so genannten PresentationElements. Jedes Präsentationselement stellt bestimmte Daten dar. Diese werden in einem separaten XML-Dokument gespeichert und über einen XPath-Ausdruck referenziert. Jedem PresentationElement kann mit dem Attribut dataxpath ein XPath-Ausdruck zugeordnet werden. Da ein XPath-Ausdruck, je nachdem wie das Datendokument gestaltet ist, eine unterschiedliche Menge von Daten zurückliefern kann, erhält ein Präsentationselement außerdem ein Attribut maxvaluecount. Dieses gibt an, wie viele Daten für das jeweilige Element maximal auf einer Oberfläche dargestellt werden dürfen. Alternativ zu einem separaten Datendokument können die Inhalte für ein Präsentationselement auch direkt in einer Präsentationsbeschreibung festgelegt werden. Dazu wird ein Content-Element benutzt. Ein Content-Element besitzt ein data-attribut, in dem die darzustellenden Inhalte gespeichert werden können. Content-Elemente können nicht nur Daten enthalten, sondern die Inhalte können bereits in einer bestimmten Zielsprache modelliert und formatiert werden. Mit dem type-attribut kann der Typ des Inhalts festgelegt werden. Der Wert TEXT zeigt an, dass ein Content-Element nur Daten enthält. Der Wert HTML kann verwendet werden, um für einen WS-Prototyp die Daten bereits mit HTML-Tags zu versehen. Präsentationselemente werden in zwei Klassen unterteilt. Textelemente (TextElements) sind 49

55 4. Annotation von WSDL-Dateien Elemente, die einen Text, also ein Wort, einen Satz oder einen längeren Textabschnitt darstellen. Ein BinaryElement dagegen stellt Binärdaten dar. Binäre Daten können noch genauer spezifiziert werden. Bilddateien oder Graphiken können als Graphic-Elemente modelliert werden. Für Graphic-Elemente kann die Höhe und die Weite mit den Attributen height bzw. width festgelegt werden. Außerdem können Audio- und Video-Elemente definiert werden. Häufig werden Daten auf Oberflächen mit Hilfe von Tabellen strukturiert. Das Metamodell für Präsentationsbeschreibungen stellt deshalb ein Element Table zur Verfügung, mit dem Tabellen modelliert werden können. Für eine Tabelle wird eine PresentationGroup erstellt, die eine Zeile der Tabelle repräsentiert. Eine PresentationGroup enthält eine Menge von Präsentationselementen, von denen jedes in einer eigenen Spalte dargestellt wird. Die Elemente in einer Spalte können dabei so oft wiederholt werden, wie es das maxvaluecount-attribut des jeweiligen Elements zulässt. Mit dem Attribut maxrowcount kann die maximale Anzahl von Zeilen für eine Tabelle werden. Dieser Wert überschreibt einen möglichen größeren Wert eines maxvaluecount-attributs eines der Gruppenelemente. Eine PresentationGroup kann auch dazu verwendet werden, eine logische Gruppe von Präsentationselementen zu modellieren. Um den XML-Schema Datentyp Choice abbilden zu können, wurde ein SwitchElement definiert. Ein SwitchElement besitzt eine Liste von values. Diese referenzieren PresentationElements von denen genau ein Element auf einer Oberfläche dargestellt werden darf. Jedes Präsentationselement gehört zu einer Oberflächenbeschreibung, die durch ein UIDescription-Element modelliert wird. Ein UIDescription-Element referenziert über das Attribut data ein XML-Datendokument, in dem die darzustellenden Inhalte für die Präsentationsbeschreibung gespeichert werden Transformationsalgorithmus XSDToPresentation Präsentationsbeschreibungen für das Prototyping werden ebenso wie Formularbeschreibungen aus den XML-Schemata einer WSDL-Datei erzeugt. Der Algorithmus XSDToPresentation, der in Listing 4.5 dargestellt ist, definiert die folgenden Transformationsvorschriften: 1. Jeder StringType, jeder NumericalType und jeder CalendarType wird in ein TextElement transformiert. 2. Ein BinaryType wird in ein Image-Element umgewandelt. 3. Jeder Sequence- und jeder All-Typ wird in eine PresentationGroup transformiert. Die Subelemente werden entsprechend den Transformationsvorschriften behandelt und der Gruppe hinzugefügt. 4. Ein Choice Typ wird in ein SwitchElement transformiert. Alle Subelemente werden entsprechend der Transformationsvorschriften umgewandelt und der value Liste hinzugefügt. 5. Der Wert des Attributs maxoccurs wird in das Attribut maxvaluecount übertragen. 6. Der Datentyp anytype wird in ein einfaches TextElement transformiert. Von den Kardinalitäten wird bei der Transformation nur die obere Grenze berücksichtigt. Die Angabe von optionalen Elementen ist nicht erforderlich, da ein Kunde selber entscheiden kann, welche der Daten, die ein Webservice liefert, er nutzen möchte und welche nicht. Optionale Elemente sind nur dann interessant, wenn der Kunde bestimmte Daten immer auf der Ober- 50

56 4. Annotation von WSDL-Dateien Listing 4.5: Basis-Algorithmus XSDToPresentation transformxsdtopresentation(schemanode n){ if(n has StringType or n has NumericalType or n has CalendarType) generatetextpresentation(n); if(n has BinaryType) generateimagepresentation(n); if(n has SequenceType or n has AllType){ presentationgroup = generatepresentationgroup; for(all subelements v of n) presentationgroup.add(transformxsdtopresentation(v)); } if(n has ChoiceType){ switchelement = generateswitchelement(n); for(all subelements v of n) switchelement.addvalue(transformxsdtopresentation(v)); } if(n has anytype) generatetextpresentation(n); } fläche angezeigt haben möchte, diese Elemente innerhalb der WSDL-Datei jedoch als optional gekennzeichnet sind. Aus einer WSDL-Datei geht jedoch nicht hervor, in welchen Fällen der Webservice ein optionales Element zurückliefert und in welchen nicht. Hierüber kann lediglich der Webserviceanbieter Auskunft geben. Da die Annotation für das Prototyping in den meisten Fällen jedoch von einer dritten Person vorgenommen wird, sind diese Informationen nicht ohne zusätzlichen Aufwand verfügbar und werden deshalb nicht berücksichtigt. Binäre Datentypen werden in Graphic-Elemente transformiert, da anzunehmen ist, dass häufig Bilddateien in einem solchen Element übertragen werden. Um andere binäre Präsentationselemente zu erstellen, können die mit dem Algorithmus erzeugten Präsentationsbeschreibungen manuell überarbeitet werden. Möglich wäre es auch, zusätzliche Regeln zu definieren, die z.b. den Namen des jeweiligen Datentyps auf bestimmte Schlüsselwörter wie Image oder Video hin prüfen. Für alle Elemente, die das Wort Video im Namen enthalten, könnte dann ein Videostatt ein Graphic-Element erstellt werden. Der Datentyp anytype ist für das Prototyping ungeeignet, da keine Aussage darüber gemacht wird, was für Daten in der Nachricht des Webservices enthalten sind. Solange jedoch nicht bekannt ist, was für Daten der Webservice zurückliefert, macht es keinen Sinn, eine Struktur für die Darstellung zu bestimmen. Deshalb werden Elemente mit dem Datentyp anytype in ein TextElement transformiert. Listing 4.6 zeigt die Struktur der KeywordSearchResponse -Nachricht des Online- Bestellservices. Diese Nachricht enthält die Ergebnisse einer Suchanfrage. Mit dem Basis- Algorithmus XSDToPresentation wird die in Abbildung 4.15 als UML-Objektdiagramm dargestellte Präsentationsbeschreibung erzeugt. Der Basis-Algorithmus XSDToPresentation erzeugt sehr einfache Präsentationsbeschreibungen. Es können z.b. keine Tabellen erstellt werden. Für die dargestellte Beispiel-Präsentation würde es sich anbieten, die Suchergebnisse, die in der KeywordSearchResponse -Nachricht enthalten sind, in einer Tabelle darzustellen. Die Liste der Suchergebnisse wird durch eine Sequence modelliert. Diese enthält nur ein Element - das Product Element - das aber mit einer beliebigen Kardinalität vorhanden sein darf. Es kann also eine Tabelle modelliert werden, in der 51

57 4. Annotation von WSDL-Dateien <message name="keywordsearchresponse"> <part name="return" type="typens:productinfo"/> </message> <xsd:complextype name="productinfo"> <xsd:all> <xsd:element name="totalresults" type="xsd:string" /> <xsd:element name="searchresults" type="productlist" minoccurs="0" /> </xsd:all> </xsd:complextype> <xsd:complextype name="productlist"> <xsd:sequence> <xsd:element name="product" type="producttype" maxoccurs="unbounded"/> </xsd:sequence> </xsd:complextype> <xsd:complextype name="producttype"> <xsd:all> <xsd:element name="productid" type="xsd:string"/> <xsd:element name="productname" minoccurs="0" type="xsd:string" /> <xsd:element name="availability" minoccurs="0" type="xsd:int" /> <xsd:element name="ourprice" minoccurs="0" type="xsd:string" /> <xsd:element name="image" minoccurs="0" type="xsd:anyuri" /> </xsd:all> </xsd:complextype> Listing 4.6: Nachrichtenformat für die output-nachricht KeywordSearchResponse der Operation KeywordSearchRequest des Online-Bestellservices Abbildung 4.15.: Mit dem Basis-Algorithmus XSDToPresentation erzeugte Präsentationsbeschreibung für die KeywordSearchResponse -Nachricht des Online- Bestellservices 52

58 4. Annotation von WSDL-Dateien Abbildung 4.16.: Mit dem erweiterten Algorithmus XSDToPresentation erzeugte Präsentationsbeschreibung für die KeywordSearchResponse -Nachricht des Online- Bestellservices jedes Produkt in einer neuen Zeile dargestellt wird. Jedes Subelement des ProductType wird dabei in einer eigenen Spalte dargestellt. Der ProductType ist ein All-Typ. Jedes Subelement dieses Typs darf also höchstens einmal in einem Instanzdokument vorhanden sein. Außerdem sind alle Subelemente einfache Datentypen. Die Beschränkung der Kardinalität von Subelementen einer Sequence auf 1 und die Bedingung, dass alle Subelemente einfache Datentypen sein müssen, ist eine Voraussetzung für das Erstellen einer Tabelle. Bei anderen Datenstrukturen würden verschachtelte Tabellen erzeugt werden, die schnell sehr unübersichtlich werden. Die folgende Transformationsvorschrift erweitert den Basis-Algorithmus um eine Regel, mit der Tabellen erzeugt werden können: 7. Ein All-Typ oder ein Sequence-Typ, dessen Subelemente einfache Datentypen sind, wird in eine Tabelle transformiert, falls die Kardinalität jedes Subelements auf maximal 1 beschränkt ist. Der ProductType der KeywordSearchResponse-Nachricht enthält außerdem ein Element Image mit dem Datentyp anyuri. Es ist anzunehmen, dass der Webservice an dieser Stelle eine URL zurückliefert, die auf ein Bild für das Produkt verweist. Der Basis-Algorithmus wird daher noch um eine weitere Transformationsvorschrift erweitert, die auf dieser Annahme beruht: 8. Ein Element mit dem Datentyp anyuri, dessen Name eine der Zeichenketten image, graphic, jpeg, png beinhaltet, wird in ein Image-Element transformiert (die Liste der Zeichenkette kann selbstverständlich noch um weitere Elemente erweitert werden). In Abbildung 4.16 ist die Präsentationsbeschreibung für die KeywordSearchResponse - Nachricht dargestellt, die mit dem erweiterten Algorithmus XSDToPresentation erzeugt wird. 53

59 4. Annotation von WSDL-Dateien Listing 4.7: Erweiterter Algorithmus XSDToPresentation transformxsdtopresentation(schemanode n){ if(n has SequenceType or n has AllType){ if(each subelement has SimpleType) if(maxvaluecount of each subelement <= 1){ table = generatetable(n); row = table.addrowelement(); for (all subelements v of n) row.addcolumn(transformxsdtopresentation(v)); } } if(n has Type anyuri and name is ImageName) generateimageelement(n);... } Die Änderungen gegenüber der Basis-Transformation sind hervorgehoben. Für das Schema Element Image wurde statt eines Textelements ein Graphikelement erzeugt. Die Produktliste wird statt in einer Präsentationsgruppe in einer Tabelle dargestellt. Mit dem Algorithmus XSDToPresentation können für alle output-nachrichten eines Webservices Präsentationsbeschreibungen erstellt werden. Auch dieser Vorgang lässt sich automatisieren. Die Präsentationsbeschreibungen enthalten zunächst nur Elemente, um die Daten, die vom Webservice kommen, darzustellen. WS-Analytiker können diese Beschreibungen um zusätzliche Präsentationselemente erweitern. Für diese können sie entweder eigene XPath-Ausdrücke definieren und die Daten in einem Datendokument speichern, oder die Elemente direkt mit Inhalten füllen. Für die zweite Möglichkeit können sie das Content-Element des Präsentationsmodells benutzen. Neben der Definition von zusätzlichen Präsentationselementen kann es manchmal auch sinnvoll sein, einige der mit dem Algorithmus erzeugten Elemente aus der Präsentationsbeschreibung zu löschen. Webservicenachrichten können z.b. Elemente enthalten, die für einen Benutzer nicht relevant sind, sondern nur Informationen für die verarbeitende Anwendung enthalten. Wenn WS-Analytiker solche Elemente identifizieren können, sollten sie diese aus einer Präsentationsbeschreibung entfernen Inhalte für Präsentationsbeschreibungen Damit eine Präsentationsbeschreibung in eine konkrete Oberfläche transformiert werden kann, wird ein XML-Dokument benötigt, das die darzustellenden Daten enthält. Der Inhalt dieses XML- Dokuments entspricht im Wesentlichen der Nachricht, die ein Webservice versendet. Die Datendokumente sollen ebenfalls in den Annotationen der WSDL-Dateien enthalten sein, damit Prototypentwickler nicht für jeden Webservice, den sie in einem Prototyp verwenden wollen, den entsprechenden Service aufrufen müssen. Datendokumente können während der Annotationsphase auf zwei Weisen erstellt werden. WS- Analytiker können einen Webservice aufrufen und die XML-Daten aus der Antwort des Service extrahieren. Die zweite Möglichkeit besteht darin, die Datendokumente mit Hilfe der XML- Schema Beschreibung der Nachrichten zu erzeugen. Werden die Nachrichten mit Hilfe der 54

60 4. Annotation von WSDL-Dateien Schema-Beschreibungen erstellt, können sie individuell angepasst werden. Zudem werden keine realen Eingabedaten benötigt, um die Nachrichten zu erhalten. Listing 4.8: Algorithmus XSDToXML transformxsdtoxml(schemanode n){ if (n has SequenceType or n has AllType){ for (all subelements v of n) transformxsdtoxml(v); } if(n has ChoiceType){ transformxsdtoxml(n.firstsubelement())); for (all other subelements v of n) generatecomment(transformxsdtoxml(v)); } if(n has StringType) generatestringcontent(n); if(n has NumericalType) generatenumericalcontent(n); if(n has CalendarType) generatedatecontent(n); if(n has BinaryType) generateimagedescription(n); if(n.gettype() == anyuri && n.getname() is ImageName) generateimagedescription(n); if(n has AnyType) generateanytypecontent(); } In dieser Arbeit wurde deshalb der Algorithmus XSDToXML definiert, der in Listing 4.8 dargestellt ist. Mit diesem Algorithmus kann für jedes Element eines XML-Schemas ein gültiges Instanzdokument erzeugt werden. Dieser Transformationsprozess lässt sich ebenfalls automatisieren. Allerdings können bei einer Generierung eines Instanzdokuments nur sehr einfache Daten erzeugt werden. Die Inhalte können nur auf Basis der Elementname und Datentypen des Schemas gebildet werden. Sie müssen daher im Nachhinein von WS-Analytikern angepasst werden, damit sie zur Entwicklung eines Prototyps verwendet werden können. Für jeden StringType des Schemas wird ein XML-Element erzeugt, dessen Inhalt aus dem Elementnamen bzw. dem Datentypnamen besteht. Numerische Typen werden in ein XML-Element transformiert, dessen Inhalt eine für diesen Datentyp gültige Zahl enthält. Für einen Calendar- Type wird eine Datumsangabe erzeugt. Für das Prototyping ist es nicht unbedingt erforderlich, dass Graphiken, Video- oder Audiodateien verwendet werden. Meistens reicht es aus, zu wissen, an welchen Stellen ein solches Element platziert werden kann. Deshalb wird für alle binären Datentypen ein Datenelement mit einem Textinhalt erzeugt. Der Inhalt dieser Elemente enthält eine Beschreibung, aus der hervorgeht, was für ein Typ von Binärdaten eigentlich in dem Element enthalten sein sollte. Für einen binären Datentyp kann also z.b. der Inhalt hier wird ein Bild angezeigt erstellt werden. Für ein Element mit dem Datentyp anytype wird ebenfalls eine kurze Erklärung als Inhalt erstellt, aus der hervorgeht, dass an dieser Stelle beliebige Daten in einer Webservicenachricht enthalten sein können. Elemente eines Schemas können in einem Instanzdokument nicht nur mit unterschiedlichem Inhalt, sondern auch mit unterschiedlicher Häufigkeit vorhanden sein. Eine Berücksichtigung 55

61 4. Annotation von WSDL-Dateien <?xml version="1.0" encoding="utf-8"?> <best:productinfo xmlns:best=" <best:totalresults>totalresults</best:totalresults> <best:searchresults> <best:product> <best:productid>productid</best:productid> <best:productname>productname</best:productname> <best:availability>3</best:listprice> <best:ourprice>ourprice</best:ourprice> <best:image>hier wird ein Bild angezeigt</best:image> </best:product> <best:product>... </best:product> <best:product>... </best:product> </best:searchresults> </best:productinfo> Listing 4.9: Mit dem Algorithmus XSDToXML erzeugtes Instanzdokument für die KeywordSearchResponse -Nachricht des Online-Bestellservices von Kardinalitäten kann bei der Implementierung des Algorithmus XSDToXML z.b. durch einen Eingabeparameter erreicht werden. Mit diesem kann festgelegt werden, wie oft ein Element maximal erzeugt werden darf. Für einen Choice-Typ werden alle Subelemente in das Datendokument übernommen. Außer das erste Element werden alle in einen Kommentar gefasst. Bei der Annotation von WSDL-Dateien kann es Sinn machen, mehr als ein Datendokument für eine Nachricht zu erstellen. Wenn ein WS-Analytiker z.b. weiß, dass ein Service für einen bestimmten Eingabeparameter eine ganz bestimmte Nachricht zurücksendet, so kann er diese zusätzlich erstellen und in den Prototyping-Dateien verlinken. Er sollte diese dann in den Annotationen der WSDL-Dateien entsprechend dokumentieren. In Listing 4.9 ist ein generiertes Beispieldokument für die KeywordSearchResponse-Nachricht des Online-Bestellservices abgebildet. Das Produktelement, dessen Attribut maxoccurs den Wert unbounded hat, wurde drei Mal erzeugt. Hat ein WS-Analytiker eine Präsentationsbeschreibung um zusätzliche Elemente erweitert, die er mit einem XPath-Ausdruck versehen hat, so muss er für diese Elemente ebenfalls Daten zur Verfügung stellen. Er kann die Inhalte für diese Elemente in das generierte Datendokument einfügen oder ein separates Dokument erstellen. Fügt er die Daten in das vorhandene Element ein, so sollte er diese mit einem Hinweis kennzeichnen, dass die Daten nicht vom Webservice stammen Mapping zwischen Oberflächenelementen Mit den bisher vorgestellten Algorithmen werden Präsentations- und Formularbeschreibungen für Webservicenachrichten unabhängig voneinander erstellt. Für jede Nachricht des Webservices wird eine eigene Oberflächenbeschreibung definiert. Zwischen den Elementen verschiedener Webservicenachrichten können jedoch Korrespondenzen existieren. Eine Teilmenge der Daten, aus denen eine input-nachricht gebildet wird, kann z.b. auch zur Bildung einer anderen input-nachricht erforderlich sein. Außerdem können bestimmte Daten, die für eine input- Nachricht benötigt werden, in output-nachrichten eines Webservices enthalten sein. Innerhalb eines Workflows können derartige Korrespondenzen zwischen Datenelementen die Gestaltung 56

62 4. Annotation von WSDL-Dateien der Oberflächen beeinflussen. Stehen bestimmte Daten in einem Workflow einmal zur Verfügung, so müssen sie nicht noch einmal an anderer Stelle von einem Benutzer eingegeben werden. Außerdem müssen Elemente verschiedener Nachrichten, die die gleichen Daten repräsentieren, auf einer Oberfläche nur einmal dargestellt werden. Für den Online-Bestellservice wurde in Kapitel 4.2 ein WSMessageWorkflow zum Bestellen eines Artikels definiert. Dieser enthält fünf Oberflächenmasken. Sowohl für die Anfrage nach den Detailinformationen als auch für das Hinzufügen eines Artikels zum Warenkorb wird eine Artikelnummer benötigt. In den Oberflächenbeschreibungen zu den beiden Nachrichten Get- Details und AddShoppingCartItemsRequest ist deshalb jeweils ein Eingabeelement für die Artikelnummer vorhanden. Da diese beiden Nachrichten jedoch auf einer Oberfläche dargestellt werden, würde es ausreichen, ein Eingabeelement für Artikelnummer auf dieser Oberfläche zu erstellen. Innerhalb des Workflows wird außerdem zunächst eine Suche nach Produkten ausgeführt. Die Antwort des Webservices auf die Suchanfrage enthält eine Liste von Produkten, in der für jedes Produkt u.a. die Artikelnummer enthalten ist. Soll eines dieser Produkte in den Warenkorb gelegt, oder sollen Detailinformationen dazu abgerufen werden, so muss die Artikelnummer nicht von einem Benutzer eingeben werden. Sie kann aus den vorhandenen Daten übernommen werden. Können solche Korrespondenzen zwischen Webservicenachrichten eines Workflows identifiziert werden, so können damit die Arbeitsabläufe der Benutzer vereinfacht werden. Daten können nicht nur innerhalb der Nachrichten eines Webservices ausgetauscht werden, sondern auch zwischen verschiedenen Webservices. Bei der Annotation von WSDL-Dateien sollen zunächst die Korrespondenzen innerhalb der Nachrichten eines einzelnen Webservices identifiziert und modelliert werden. Die Korrespondenzen werden anhand der XML-Schemata ermittelt, mit denen die Nachrichtenstrukturen definiert sind. Da sie sich auf die Gestaltung der Oberflächen auswirken, werden sie mit Hilfe von Oberflächenelementen modelliert. Das Metamodell für Oberflächenbeschreibungen wird dazu um ein Mapping-Element erweitert. Ein Mapping bildet ein Oberflächenelement auf ein anderes ab. Für jedes Mapping wird eine Richtung definiert. Bei einem Mapping zwischen einem Präsentations- und einem Formularelement wird das Präsentationselement auf das Formularelement abgebildet. Die Richtung zeigt an, dass die Daten, die mit dem Präsentationselement dargestellt werden, möglichen Eingabewerten des Formularelements entsprechen. Bei Mappings zwischen Eingabeelementen ist die Richtung bedeutungslos, es ist also egal, in welche Richtung das Mapping erstellt wird. Abbildung 4.17 zeigt das um Mapping-Elemente erweiterte Metamodell für Oberflächenbeschreibungen. Mappings können theoretisch zwischen beliebigen Elementen erstellt werden. Sie machen aber nur dann Sinn, wenn die Nachrichten, zu denen diese Elemente gehören, innerhalb eines Workflows vorkommen. Bei der Annotation von WSDL-Dateien werden Mappings daher für einen WSMessageWorkflow definiert. Um Mappings zu identifizieren, kann die XML-Struktur der Webservicenachrichten herangezogen werden. Es werden zwei Mapping-Regeln definiert, anhand derer ein Mapping erkannt werden kann: 1. Zwischen Elementen von zwei Webservicenachrichten, die durch das gleiche XML- Schema-Element beschrieben sind, wird ein Mapping definiert. 2. Zwischen zwei Elementen von zwei Webservicenachrichten, deren XML-Schema- 57

63 4. Annotation von WSDL-Dateien Abbildung 4.17.: Metamodell für Mappings Elemente den gleichen Namen und den gleichen Datentyp haben, wird ein Mapping definiert. Mit beiden Mapping-Regeln können theoretisch Mappings erzeugt werden, die semantisch nicht korrekt sind. In einem XML-Schema kann z.b. ein Element Adresse definiert sein, das in zwei verschiedenen Nachrichten des Webservices verwendet wird. Ob diese Adresse in beiden Fällen dieselbe reale Adresse darstellt, geht aus der XML-Schema-Struktur nicht hervor. Diese Frage kann letztlich nur der Webserviceanbieter beantworten. Eventuell kann aus der Sematik der Webserviceoperationen geschlossen werden, ob zwei solche Elemente identisch sind. Die zweite Mapping-Regel ist noch etwas unsicherer als die erste. Datentypen wie beispielsweise string und integer werden sehr häufig zur Definition von Elementen verwendet. Darüber hinaus gibt es auch eine Reihe von Elementnamen, die öfter in einem XML-Schema benutzt werden. Hierzu zählen z.b. Begriffe wie id oder name. Es kann nicht vorausgesagt werden, wie hoch die Wahrscheinlichkeit ist, dass z.b. zwei lokal definierte Elemente mit dem Namen id und dem Datentyp string tatsächlich dieselben Daten repräsentieren. Bei spezifischeren Elementnamen, beispielsweise bei der Verwendung von productid statt id, steigt die Wahrscheinlichkeit, dass die Daten von zwei Elementen mit diesem Namen dieselben realen Daten repräsentieren. Da die Definition von Mappings für viele verschiedene Nachrichten sehr aufwändig ist, sollen Mappings genau wie Oberflächenbeschreibungen generiert werden können. Es wird dazu ein Algorithmus definiert, mit dem sich für einen WSMessageWorkflow alle potentiellen Mappings identifizieren und generieren lassen. Damit der Algorithmus auf der Basis von Oberflächenbeschreibungen arbeiten kann, werden jedem UIElement zwei weitere Attribute hinzugefügt, mit denen das repräsentierte Element des XML-Schemas sowie dessen Datentyp identifiziert werden können. Das schemaelement-attribut referenziert mittels eines XPath-Ausdrucks das modellierte Schema-Element und das datatype-attribut gibt den Datentyp an. In Listing 4.10 ist der Algorithmus zur Erzeugung von Mappings abgebildet. Um das Risiko zu minimieren, dass semantisch nicht korrekte Mappings erzeugt werden, kann der Algorithmus um eine Liste kritischer Elementnamen ergänzt werden. Für die Namen in dieser Liste kann das Erzeugen von Mappings nach der zweiten Regel unterbunden werden. Generell sollten automatisch erzeugte Mappings von WS-Analytikern sorgfältig auf semantische Korrektheit überprüft werden. Diese Überprüfung ist jedoch weitaus weniger aufwändig als das manuelle 58

64 4. Annotation von WSDL-Dateien Listing 4.10: Algorithmus GenerateMappings generatemappings(wsmessageworkflow wf){ messagelist = wf.getallpresentedmessages(); for(each pair of messages m1, m2){ UIElementList1 = m1.getuielements(); for(uielement1 : UIElementList1){ UIElementList2 = m2.getuielementlist(); for(uielement2 : UIElementList2){ if(!uielement1.ispresentationelement &&!uielement2.ispresentationelement){ if(uielement1.getschemaelement() == uielement2.getschemaelement()){ generatemapping(uielement1, uielement2); } else if(uielement1.getname() == uielement2.getname() && uielement.getdatatype() == uielement2.getdatatype()){ generatemapping(uielement1, uielement2); } }}}} <xsd:complextype name="detailsrequest"> <xsd:all> <xsd:element name="productid" type="xsd:string"/> <xsd:element name="getmedia" type="xsd:boolean" minoccurs="0"/> </xsd:all> </xsd:complextype> Listing 4.11: Nachrichtenformat für die ShowDetailsRequest -Nachricht des Online- Bestellservices Abbildung 4.18.: Mapping zwischen der KeywordSearchResponse - und der GetDetails - Nachricht des Online-Bestellservices 59

65 4. Annotation von WSDL-Dateien Erstellen von Mappings. Listing 4.11 zeigt einen weiteren Ausschnitt der WSDL-Datei des Online-Bestellservices. Das Schema-Element DetailsRequest beschreibt die Struktur der ShowDetailsRequest - Nachricht. Innerhalb dieses Elements ist ein XML-Element mit dem Namen ProductId und dem Datentyp string definiert. Auch innerhalb der Struktur der KeywordSearchResponse - Nachricht, die in demselben Workflow verwendet wird, wird ein lokales Element mit dem Namen ProductId und dem Datentypen string definiert (siehe Listing 4.6). Der Algorithmus GenerateMapping erzeugt für diese beiden Elemente ein Mapping, das in Abbildung 4.18 dargestellt ist. Neben den Mappings, die auf der Struktur von XML-Schemata beruhen, können auch Korrespondenzen zwischen Schema-Elementen existieren, die keinen definierten Regeln folgen. Solche Mappings, die nicht anhand der XML-Struktur zu erkennen sind, sondern nur aus der Semantik des Services hervorgehen, können nicht automatisch identifiziert werden. Ein WS- Analytiker kann, wenn er mit der Semantik der Webserviceoperationen vertraut ist, derartige Mappings für einen Workflow manuell erstellen. Damit verbessert er die Qualität der Annotationen und erleichtert den Prototypentwicklern die Arbeit Prototyping-Dateien WSMessageWorkflows, Oberflächenbeschreibungen, die Mappings zwischen Elementen dieser Beschreibungen sowie die Daten für die Präsentationselemente bilden zusammen die Bausteine für das Prototyping. Damit diese Daten bei der Entwicklung eines WS-Prototyps verwendet werden können, werden sie in XML-Dokumenten gespeichert und mit den WSDL-Dateien verknüpft. Dazu wird eine Prototyping-Datei erstellt, die alle Komponenten enthält. Abbildung 4.19.: Komponenten einer Prototyping-Datei In Listing 4.12 ist ein Auszug des Prototyping-Schemas, das zum Speichern von Prototyping- Dateien verwendet wird, dargestellt. Alle Komponenten für das Prototyping werden in separaten Dateien gespeichert und in der Prototyping-Datei verlinkt. Diese Modularisierung ermöglicht es, dass die einzelnen Komponenten unabhängig voneinander erstellt und ausgetauscht werden können. Eine vollständige Prototyping-Datei enthält mindestens eine WSMessageWorkflow- Beschreibung, eine Oberflächenbeschreibung für jede Nachricht des Webservices sowie 60

66 4. Annotation von WSDL-Dateien ein Dokument mit Beispieldaten für jede output-nachricht. Darüber hinaus können weitere Workflowbeschreibungen, Mappings für die Workflows und zusätzliche Dokumente mit Beispieldaten definiert werden. Mehr als eine Oberflächenbeschreibung pro Nachricht darf jedoch nicht vorhanden sein. In Abbildung 4.19 sind die einzelnen Komponenten, aus denen eine Prototyping-Datei besteht, dargestellt. Für Oberflächenbeschreibungen und WSMessageWorkflows mit Mappings wurden ebenfalls XML-Schemata definiert. Diese sind, genau wie das vollständige Prototyping-Schema, im Anhang dargestellt. Um eine Prototyping-Datei mit einer WSDL-Datei zu verknüpfen, wird der Erweiterungsmechanismus des WSDL-Formats genutzt. Dieser wurde in Kapitel erläutert. Da sich die Erweiterungen auf mehrere Elemente des WSDL-Formats beziehen ein WSMessageWorkflow referenziert z.b. mehrere Message-Elemente wird die Erweiterung am <definition>-element vorgenommen. In das <definition>-element wird dazu ein <Prototyping>- Element eingefügt. Um die Prototyping-Dateien flexibel ändern und austauschen zu können, wird ein <Import>-Element verwendet, über das innerhalb des <Prototyping>-Elements eine externe Prototyping-Datei verlinkt wird. <?xml version="1.0" encoding="utf-8"?> <schema xmlns=" targetnamespace=" xmlns:tns=" xmlns:form=" xmlns:pres=" elementformdefault="qualified"> <element name="prototyping"> <complextype> <choice> <sequence> <element name="wsmessageworkflow" type="tns:wsmessageworkflowtype" minoccurs="0" maxoccurs="unbounded" /> <element name="formui" type="tns:uidescription" minoccurs="0" maxoccurs="unbounded" /> <element name="presentationui" type="tns:uidescription" minoccurs="0" maxoccurs="unbounded" /> <element name="sampledata" type="tns:sampledatatype" minoccurs="0" maxoccurs="unbounded" /> </sequence> <element ref="tns:import" /> </choice> </complextype> </element> </schema> Listing 4.12: Auszug aus dem XML-Schema für Prototyping-Dateien Zusammenfassung In diesem Kapitel wurde erläutert, wie WSDL-Dateien erweitert werden können, um die Entwicklung von WS-Prototypen zu erleichtern. Dazu wurden Prototyping-Dateien definiert, die in der Annotationsphase des Prototyping-Prozesses von WS-Analytiker erstellt werden. Für jeden Webservice kann eine Prototyping-Datei mit der WSDL-Beschreibung des Services verknüpft 61

67 4. Annotation von WSDL-Dateien werden. Die Prototyping-Dateien enthalten Workflow- und Oberflächenbeschreibungen, sowie Beispielnachrichten des Webservices. Für die Workflowbeschreibungen wurden WSMessageWorkflow Modelle definiert, mit denen mehrere Webservicenachrichten zu einem Ablauf kombiniert werden können. Für jede Nachricht eines Webservice kann mit Hilfe der in diesem Kapitel definierten Algorithmen XSDToForm und XSDToPresentation eine abstrakte Oberflächenbeschreibung erzeugt werden. Zwischen den Elementen verschiedener Oberflächenbeschreibungen können Mappings definiert werden, die den möglichen Datenaustausch zwischen Oberflächen bzw. Webservicenachrichten modellieren. Im nächsten Kapitel wird erläutert, wie die Annotationen der WSDL-Dateien bei der Entwicklung eines WS-Prototyps verwendet werden können, um den Entwicklungsaufwand zu minimieren. 62

68 5. Entwicklung eines WS-Prototyps In diesem Kapitel wird die Entwicklungsphase des Prototyping-Prozesses vorgestellt, in der ein WS-Prototyp erstellt wird. Abbildung 5.1.: Die Entwicklungsphase des Prototyping-Prozesses Es wird zunächst ein Überblick über die Aktivitäten dieser Phase gegeben. Anschließend wird der generelle Aufbau eines WS-Prototyps beschrieben. Die in der Annotationsphase erstellten Prototyping-Dateien werden in der Entwicklungsphase verwendet, um den Aufwand für die Entwicklung eines WS-Prototyps zu reduzieren. Es wird erläutert, wie die einzelnen Komponenten einer Prototyping-Datei den Entwicklungsprozess unterstützen können. Dazu werden Transformationsalgorithmen definiert, mit denen WSMessageWorkflows und abstrakte Oberflächenbeschreibungen in HTML-Oberflächen transformiert werden können. Damit Prototypentwickler die Möglichkeit haben, in einem WS-Prototyp komplexere Abläufe mit mehreren Webservices darzustellen, werden WSMessageWorkflow-Kompositionen definiert Prozessbeschreibung Die Entwicklungsphase des Prototyping-Prozesses ist in die Analysephase eines SOA- Portalprojekts integriert. Die Prototypentwickler sollen auf der Basis der bereits erhobenen Anforderungen einen WS-Prototyp erstellen, den Systemanalytiker zur weiteren Elicitation und Validierung von Anforderungen nutzen können. In Abbildung 5.2 sind die Tätigkeiten der Entwicklungsphase als UML-Aktivitätsdiagramm dargestellt. Die Entwicklungsphase beginnt mit einer Zieldefinition, bei der die allgemeinen Ziele des Prototypings mit Webservices (siehe Kapitel 3.1) für jedes Projekt präziser erfasst und priorisiert werden. Die Zieldefinition beeinflusst die Entwicklung des Prototyps. Sollen mit dem Prototyp z.b. verschiedene Webservices gegeneinander abgegrenzt werden, so muss der Prototyp zunächst die funktionalen Unterschiede der Webservices aufzeigen können. Auf die Gestaltung der einzelnen Oberflächen wird in diesem Fall vermutlich weniger Wert gelegt. Ist hingegen 63

69 5. Entwicklung eines WS-Prototyps Abbildung 5.2.: Der Entwicklungsprozess eines WS-Prototyps bereits eine Serviceauswahl erfolgt, so kann ein Ziel des Prototyping sein, die Oberflächengestaltung im Detail festzulegen. Nach der Zieldefinition müssen Webservices gefunden werden, mit denen der Prototyp entwickelt werden soll. Es gibt verschiedene Quellen, aus denen die Prototypentwickler diese Services beziehen können. Bei einem Kunden können bereits Webservices existieren, die in die neu zu entwickelnde Anwendung integriert werden sollen. Ist dies nicht der Fall, so können Webservice-Kataloge herangezogen werden, in denen nach geeigneten Webservices gesucht werden kann. Idealerweise ist ein Service-Katalog verfügbar, in dem Webservices mit Annotationen für das Prototyping veröffentlicht sind. So ein Katalog kann nach und nach aufgebaut und öffentlich oder unternehmensintern verfügbar gemacht werden. Können keine geeigneten Webservices gefunden werden, so können die Prototypentwickler selbst Services definieren. Dafür reicht es aus, die Schnittstellenbeschreibungen der Services mit Hilfe einer WSDL-Datei festzulegen. Die WSDL-Datei muss anschließend noch mit den Annotationen für das Prototyping versehen werden. Dadurch wird der Entwicklungsprozess etwas aufwändiger als bei der Verwendung bereits annotierter WSDL-Dateien. Mit einem Werkzeug, das die in Kapitel 4 vorgestellten Transformationsalgorithmen implementiert, lassen sich Oberflächenbeschreibungen und Beispielnachrichten aber schnell erzeugen. Da die Prototypentwickler die WSDL-Dateien selbst erstellt haben, sollten sie auch WSMessageWorkflows für diese Services definieren können. Eine systematische Unterstützung für das Suchen geeigneter Webservices wird in dem in dieser Arbeit definierten Vorgehensmodell nicht zur Verfügung gestellt. Es gibt bereits eine Reihe von Ansätzen, die sich mit der Suche von Webservices auf Basis von Anforderungen beschäftigen. Beispielhaft sei an dieser Stelle auf das Framework von Pathnak et al. [PKCH05] zur semantischen Suche verwiesen und auf den Ansatz von Zhu und Baily [Bai06]. Mit letzterer Methode können Webservices nicht nur nach funktionalen Aspekten gesucht werden, sondern es können auch Anforderungen an die Kosten für die Nutzung berücksichtigt werden. Nachdem die Prototypentwickler geeignete Webservicekandidaten ermittelt haben, müssen sie die WSMessageWorkflows auswählen, die die darzustellenden Prozesse am besten unterstützen. Um komplexere Geschäftsprozesse in einem WS-Prototyp zu visualisieren, kann es nötig sein, neue WSMessageWorkflows zu definieren. Dabei können auch Workflows verschiedener Webservices miteinander kombiniert werden. Haben Prototypentwickler die passenden WSMessageWorkflows ausgewählt bzw. erstellt, müs- 64

70 5. Entwicklung eines WS-Prototyps sen sie die Oberflächen für diese Workflows entwickeln. Bei dieser Tätigkeit sollen sie durch ein Werkzeug unterstützt werden, das aus den abstrakten Oberflächenbeschreibungen der Prototyping-Dateien HTML-Fragmente generieren kann. Für jede WSView eines WSMessage- Workflow soll ein HTML-Fragment generiert werden können. Die generierten HTML-Fragmente können von Prototypentwicklern anschließend modifiziert werden, bevor sie zu einem Prototyp zusammengestellt werden. Prototypentwickler können z.b. das Layout festlegen oder zusätzliche Beschreibungen in die generierten Fragmente einfügen. Zusätzlich zu den Oberflächen für die einzelnen Workflows wird ein HTML-Grundgerüst benötigt, in das die HTML-Fragmente der einzelnen Services integriert werden können. Die Entwicklung des HTML-Grundgerüsts kann parallel zur Entwicklung der HTML-Fragmente für die Workflows erfolgen Aufbau eines WS-Prototyps Portal-Templates Das HTML-Grundgerüst, das für einen WS-Prototyp benötigt wird, wird als Portal-Template bezeichnet. Es besteht aus mehreren Bereichen, in denen jeweils ein Workflow dargestellt werden kann. Diese so genannten Service-Areas können z.b. durch einfache <div>-elemente realisiert werden. Definition 19 (Portal-Template) Ein Portal-Template ist eine HTML-Seite, die in mehrere Bereiche unterteilt ist. Diese HTML-Seite bildet das Grundgerüst eines WS-Prototyps. Definition 20 (Service-Area) Eine Service-Area ist ein Bereich eines Portal-Templates, in dem ein WSMessageWorkflow dargestellt wird. Jedes Portal-Template kann aus mehreren Service- Areas bestehen. Die HTML-Fragmente in den einzelnen Service-Areas sollen unabhängig voneinander ausgetauscht und modifiziert werden können. Diese Eigenschaft ist wichtig, damit bei der Auswertung des Prototyps gezielt bestimmte Navigations- und Oberflächenaspekte eines einzelnen Workflows diskutiert werden können. Die Navigation in einem Prototyp wird durch die Verlinkung der HTML-Fragmente ermöglicht. Um die Service-Areas voneinander unabhängig zu halten, bietet sich die Verwendung von AJAX für einen WS-Prototyp an. Im Folgenden wird eine kurze Einführung in diese Technologie gegeben und erläutert, wie sie in einem WS-Prototyp verwendet werden kann Verwendung von AJAX Asynchronous JavaScript and XML (kurz: AJAX) [Gar05] ist eine Technologie, die es ermöglicht, innerhalb von HTML-Seiten eine HTTP-Anfrage auszuführen, ohne die gesamte Seite neu laden zu müssen. In Abbildung 5.3(a) ist die klassische Methode des Ausführens einer HTTP-Anfrage dargestellt. Solange die Anfrage in Bearbeitung ist, kann ein Benutzer keine Interaktionen auf der Oberfläche vornehmen. Wird jedoch die AJAX-Technologie benutzt, so wird die Anfrage im Hintergrund ausgeführt (Abbildung 5.3(b)). Sobald die Daten geladen wurden, werden sie auf der Oberfläche dargestellt. In der Zwischenzeit kann ein Benutzer weiterhin auf der Oberfläche interagieren und z.b. bereits weitere HTTP-Anfragen auslösen. 65

71 5. Entwicklung eines WS-Prototyps (a) Klassische Methode für HTTP-Anfragen (b) HTTP-Anfragen mit AJAX Abbildung 5.3.: HTTP-Anfragen ohne und mit Verwendung von AJAX (nach [Gar05]) 66

72 5. Entwicklung eines WS-Prototyps Die Verwendung der AJAX-Technologie in einem WS-Prototyp bietet einige Vorteile für die Demonstration des Prototyps. In jeder Service-Area können individuelle Aktionen ausgeführt werden, ohne dass die anderen Bereiche davon betroffen sind. So kann z.b. unabhängig von einander zwischen den HTML-Fragmenten verschiedener Workflows navigiert werden. Außerdem ist es möglich, einen Workflow in einer Service-Area auszutauschen, ohne dass dabei die gesamte Oberfläche neu geladen werden muss. Die Verwendung eines AJAX-Frameworks als Grundlage für einen WS-Prototyp bietet noch weitere Vorteile. Der Prototyp kann durch das Framework mit einem Demonstrationswerkzeug verbunden werden. Im Hintergrund können beliebige Aktionen ausgeführt werden, während der Client weiterhin den eigentlichen Prototyp zeigt. Der Prototyp kann so z.b. mit einer Interviewfunktion versehen werden, die das Erfassen von Kommentaren bei einer Demonstration ermöglicht. Die Kommentare können auf dem Server gespeichert werden. Des Weiteren können die Algorithmen zur Transformation der abstrakten Oberflächenbeschreibungen in HTML-Fragmente auf dem Server implementiert werden. Dadurch wird es ermöglicht, HTML-Fragmente für einen WS-Prototyp aus der Oberflächenansicht heraus generieren zu lassen. In Kapitel 7.2 wird anhand einer Referenzimplementierung gezeigt, wie ein AJAX-Framework für die Gestaltung eines Entwicklungs- und Demonstrationswerkzeugs für einen WS-Prototyp verwendet werden kann Simulation von Serviceaufrufen In einem WS-Prototyp werden WSMessageWorkflows dargestellt. Die Links in den WSMessageWorkflows modellieren Operationsaufrufe eines Webservices. Diese Operationsaufrufe sollen beim Prototyping simuliert werden. Die Simulation hat mehrere Vorteile, sowohl für die Entwicklung als auch die Demonstration des Prototyps. Bei der Entwicklung wird Implementierungszeit gespart, da keine technischen Voraussetzungen geschaffen werden müssen, die den Aufruf von Webservices ermöglichen. Außerdem können mit simulierten Serviceaufrufen gezielt bestimmte Situationen modelliert werden. Für die Demonstration eines WS-Prototyps hat die Simulation den Vorteil, dass kein Internetzugang benötig wird. Eine Demonstration wird wahrscheinlich häufig bei einem Kunden erfolgen. Es kann nicht sichergestellt werden, dass dort ein Internetzugang vorhanden ist, bzw. dass der Aufruf von Webservices aus dem Netz des Kunden heraus ohne zusätzlichen administrativen Aufwand möglich ist. Zudem können bei manchen Webservices durch den Aufruf von Operationen Kosten anfallen oder es werden bestimmte Aktionen auf Serviceseite ausgelöst, die für das Prototyping nicht benötigt werden. Des Weiteren besteht das Risiko, dass ein Service während einer Demonstration nicht verfügbar ist oder dass unerwartete Fehlermeldungen bei der Kommunikation mit einem Service auftreten. Ein Nachteil, der durch die Simulation entsteht, ist der, dass die Nachrichten u.u. nicht denen entsprechen, die ein Service auf eine bestimmte Anfrage zurückliefert. Werden in den XML- Schemata, die die Struktur der Webservicenachrichten definieren, z.b. viele optionale Elemente oder Choice-Konstrukte verwendet, so kann man nicht voraussagen, wie die Antwortnachricht des Webservices auf eine bestimmte Anfrage aussieht. Um dieses Problem zu beheben, kann ein Prototypentwickler den Webservice während der Entwicklung aufrufen. Die Nachrichten, mit denen der Service auf eine Anfrage antwortet, können zur Simulation verwendet bzw. mit den simulierten Nachrichten verglichen werden. Für die Simulation von Webservicenachrichten können die in den Prototyping-Dateien zur Verfügung gestellten XML-Datendokumente verwendet werden. Alternativ kann ein Prototypent- 67

73 5. Entwicklung eines WS-Prototyps wickler mit Hilfe des Algorithmus XSDToXML selbst Nachrichten erstellen bzw. generieren lassen. Die generierten Nachrichten enthalten jedoch, wie in Kapitel 4.7 erläutert wurde, nur sehr einfache, generische Inhalte. Die Inhalte müssen manuell angepasst werden, um damit aussagekräftige Oberflächen erstellen zu können. Diese Anpassung sollte bei den Nachrichten, die in den Annotationen der WSDL-Dateien enthalten sind, bereits von einem WS-Analytiker vorgenommen wurden sein, so dass einem Prototypentwickler diese Arbeit erspart wird WSMessageWorkflow-Kompositionen Bei der Annotation von WSDL-Dateien werden WSMessageWorkflows auf Basis der Nachrichten eines einzelnen Webservices erstellt. In SOA-Portalanwendungen werden jedoch häufig Service-Kompositionen verwendet. Eine Service-Komposition ist eine Kombination von mehreren Webservices, die einen Geschäftsprozess unterstützt. Sollen Service-Kompositionen in einem Prototyp dargestellt werden, weil sie z.b. Benutzerinteraktionen erfordern, so müssen WSMessageWorkflow-Beschreibungen erstellt werden, die diese Service-Kompositionen abbilden. Dazu können neue WSMessageWorkflows aus Kombinationen bereits existierender WSMessageWorkflow-Beschreibungen gebildet werden. Eine solche Kombination von WSMessageWorkflows wird als WSMessageWorkflow-Komposition bezeichnet. Definition 21 (WSMessageWorkflow-Komposition) Eine WSMessageWorkflow-Komposition beschreibt einen WSMessageWorkflow, der auf Basis von Nachrichten mehrerer verschiedener Webservices gebildet wird. Abbildung 5.4.: Prinzip für das Erstellen von WSMessageWorkflow-Kompositionen Um eine WSMessageWorkflow-Komposition zu erstellen, kann ein WSMessageWorkflow als Ausgangsbasis gewählt werden. In diesen Workflow können andere WSMessageWorkflows integriert werden oder es kann eine Verlinkung in einen anderen WSMessageWorkflow erstellt werden. Dazu wird an der Stelle, an der ein zweiter WSMessageWorkflow eingebunden werden soll, ein Verzweigungsknoten erstellt. Dieser vereinigt eine WSView des ersten Workflows mit einer WSView des zweiten Workflows. Die durch den neuen Knoten repräsentierte WSView kann anschließend soweit modifiziert werden, dass sie nur noch Nachrichten darstellt, die in dem kombinierten Workflow benötigt werden. In Abbildung 5.4 ist das Prinzip für die Bildung einer WSMessageWorkflow-Komposition veranschaulicht. Der erste farblich schwarz hervorgehobene Knoten View2B stellt den Verzweigungsknoten dar. Um aus einem verzweigten Pfad wieder in den Basis-Workflow zurückzugelangen, wird ein Vereinigungsknoten erstellt. Dazu 68

74 5. Entwicklung eines WS-Prototyps muss ein neuer WSLink gebildet werden, der die beiden Workflows miteinander verbindet. Der Ausgangsknoten dieses Links muss modifiziert werden. Die WSView, die durch diesen Knoten dargestellt wird, muss die input Nachricht der Operation darstellen, die durch den neuen Link modelliert wird. In der in Abbildung 5.4 dargestellten WSMessageWorkflow-Komposition wurde ein solcher neuer Link erstellt, der aus dem zweiten Workflow wieder in den ersten zurückführt. Der neue Linkt sowie die modifizierte WSView sind in der Darstellung hervorgehoben. Prinzipiell können auch WSMessageWorkflow-Kompositionen erstellt werden, ohne einen existierenden Workflow als Ausgangsbasis zu verwenden. Für die modifizierten Views einer WSMessageWorkflow-Komposition können und sollten neue Mappings erstellt werden. Mit diesen Mappings wird der Datenaustausch modelliert, der zwischen den Webservices möglich ist Auswertung von Prototyping-Dateien Transformation von WSMessageWorkflows in HTML-Fragmente Bei der Entwicklung eines WS-Prototyps sollen die Annotationen der WSDL-Dateien verwendet werden, um den Entwicklungsaufwand zu reduzieren. Die HTML-Fragmente, die in einem WS- Prototyp verwendet werden, sollen deshalb soweit wie möglich aus den WSMessageWorflow- Beschreibungen und den abstrakten Oberflächenbeschreibungen generiert werden. In Abbildung 5.5 ist das Transformationsprinzip für einen WSMessageWorkflow in HTML-Fragmente dargestellt. Für jede WSView wird ein HTML-Fragment erzeugt. Abbildung 5.5.: Transformation eines WSMessageWorkflows in HTML-Fragmente Bei der Transformation einer einzelnen WSView in ein HTML-Fragment müssen alle von dieser View dargestellten Nachrichten berücksichtigt werden. Für jede dieser Nachrichten sollte in den Annotationen für das Prototyping eine abstrakte Oberflächenbeschreibung vorhanden sein. Jede abstrakte Oberflächenbeschreibung kann in HTML-Elemente transformiert werden. Diese können als HTML-Teil-Fragmente bezeichnet werden. Bei diesem Transformationsschritt sollen die Mappings berücksichtigt werden, die für den Workflow definiert sind. Alle HTML-Teil- Fragmente einer WSView werden zu einem HTML-Fragment kombiniert. In Abbildung 5.6 ist dieses Prinzip für die Transformation einer WSView in ein HTML-Fragment veranschaulicht. In den folgenden Kapiteln wird erläutert, wie die Elemente der abstrakten Oberflächenbschreibungen im Einzelnen in HTML-Elemente transformiert werden können. Außerdem wird ein Prinzip für die Berücksichtigung von Mappings definiert. 69

75 5. Entwicklung eines WS-Prototyps Abbildung 5.6.: Transformation einer WSView in ein HTML-Fragment Algorithmus FormToHTML Mit dem Algorithmus FormToHTML, der in Listing 5.1 dargestellt ist, können Formularelemente der abstrakten Oberflächenbeschreibungen in HTML-Formularelemente transformiert werden. Dabei werden folgende Transformationsregeln angewandt: 1. Ein Form-Element wird in ein HTML-Formular <form action="xxx"> transformiert. Da beim Prototyping die Webserviceaufrufe simuliert werden, wird das action-attribut mit einem Platzhalter gefüllt. 2. Submission-Elemente werden in HTML-Submit-Elemente transformiert <input type="submit"... >. 3. Ein TextInput-Element, dessen rowcount-attribut den Wert 1 hat, wird in ein einfaches Texteingabefeld <input type="text"... > transformiert. Für alle mehrzeiligen TextInput-Elemente wird ein <textarea>-element erzeugt. Die Zeilenanzahl der Textarea wird auf den Wert des Attributs rowcount gesetzt, die Spaltenanzahl wird standardmäßig auf 40 festgesetzt. 4. Ein SelectableElement wird in eine Checkbox <input type="checkbox"... > transformiert. Der Wert des label-attributs wird als value für die Checkbox gesetzt. 5. BinaryInput Elemente werden in Datei-Upload-Felder <input type="file"... > transformiert. 6. Eine SelectionList, deren items alle SelectableElements sind, wird in eine Auswahlliste <select> transformiert. Für jedes Item der SelectionList wird ein <option>-eintrag erzeugt. Auswahllisten in HTML erlauben entweder die Auswahl eines einzigen Elements oder beliebig vieler Elemente. Ist der Wert des Attributs selectableitemcount des SelectionList Elements größer als 1, wird eine Auswahlliste mit Mehrfachauswahl erzeugt. 7. Eine SelectionList, bei der mindestens eins der Items aus einem zusammengesetzten Element besteht, wird in eine Gruppe von Radiobuttons <input type="radio"... > oder eine Gruppe von Checkboxen <input type="checkbox"... > transformiert. Für ein zusammengesetztes Element (also eine InputGroup) wird bei dieser Transformation nur eine Auswahlmöglichkeit erzeugt. Es kann also nur die gesamte Gruppe ausgewählt werden. Die Gruppenelemente werden nach den für sie gültigen Transformati- 70

76 5. Entwicklung eines WS-Prototyps Listing 5.1: Algorithmus FormToHTML transformformelementtohtml(uielement ui){ if(uielement is SubmissionElement) generatehtmlsubmitelement(uielement); if(uielement is InputGroup){ divelement = generatehtmldivelement(uielement); for(groupelement : uielement.getgroupelements()) divelement.add(transformformelementtohtml(groupelement); } if(uielement is TextInput){ if(uielement.getrowcount() == 1) generatehtmltextinputelement(uielement); else generatehtmltextarea(uielement); } if(uielement is SelectableElement) generatehtmlcheckbox(uielement); if(uielement is BinaryInput) generatehtmlfileupload(uielement); if(uielement is CalendarElement){ generatehtmlselectionlist("day"); generatehtmlselectionlist("month"); generatehtmlselectionlist("year"); } if(uielement is SelectionList){ if(uielements.getitemlist() contains InputGroup){ if(uielement.selectableitemcount() == 1){ for(item : uielement.getitemlist()){ generatehtmlradiobutton(item); transformformelementtohtml(item); }} else{ for(item : uielement.getitemlist()){ generatehtmlcheckbox(item); transformformelementtohtml(item); }} } else{ sellist = generatehtmlselectionlist(uielement); for(item : uielement.getitemlist()) sellist.addoption(item); if(selectableitemcount > 1) sellist.setmultipleselection(true); } } } onsregeln transformiert. Eine SelectionList wird in eine Gruppe von Radiobuttons transformiert, falls das Attribut selectableitemcount den Wert 1 hat. Für alle anderen Fälle werden Checkboxen erzeugt, da diese eine Mehrfachauswahl zulassen. 8. Für ein CalendarElement werden drei Auswahllisten erstellt, mit denen, die Auswahl eines Datums möglich ist: eine Liste für den Tag, eine für den Monat und eine für das Jahr. 9. Jedes optionale Element wird mit einem class-attribut versehen, das den Wert optional erhält. Dieses kann zu Formatierungszwecken und zur Identifikation von optionalen Elementen bei einer Demonstration des Prototyps verwendet werden. 71

77 5. Entwicklung eines WS-Prototyps 10. Für alle Eingabeelemente wird ein Label erstellt. Dieses wird aus dem label-attribut des jeweiligen FormElements erzeugt. 11. GroupInput-Elemente werden in einem <div>-element zusammengefasst. Mit dem Transformationsalgorithmus werden lediglich die benötigten Eingabeelemente erzeugt. Es wird kein Layout erstellt, das eine übersichtliche Anordnung der Elemente vornimmt. Wird der Algorithmus FormToHTML in einem Werkzeug implementiert, das die Prototypentwicklung unterstützt, so können Prototypentwickler sich also zunächst nur die erforderlichen HTML- Elemente für eine Oberfläche generieren lassen. Eine Gestaltung des Layouts müssen sie manuell oder mit entsprechenden Webdesign-Tools vornehmen. Abbildung 5.7 zeigt die Browserdarstellung des mit dem Algorithmus FormToHTML erzeugten HTML-Fragments für die SubmitShoppingCartRequest -Nachricht des Online-Bestellservices. Die HTML-Elemente wurden in einer einfachen Tabelle angeordnet. Abbildung 5.7.: Browserdarstellung des mit dem Algorithmus FormToHTML erzeugten Eingabeformulars der Nachricht SubmitShoppingCartRequest des Online- Bestellservices Algorithmus PresentationToHTML Bei der Transformation von Präsentationsbeschreibungen in HTML-Elemente wird ein XML- Dokument benötigt, das die darzustellenden Daten beinhaltet. Dieses ist normalerweise bereits in den Prototyping-Annotationen vorhanden. Ein Algorithmus, der die Transformation von Präsentationsbeschreibungen in HTML-Elemente durchführt, bekommt die Oberflächenbeschreibung und das Datendokument als Eingabe. Listing zeigt den Algorithmus PresentationToHTML, der nach folgenden Regeln arbeitet: 72

78 5. Entwicklung eines WS-Prototyps 1. Der Inhalt eines Content-Elements, dessen type-attribut den Wert HTML hat, wird direkt in ein HTML-Fragment übernommen. Bei dem Wert TEXT für das Attribut type werden die Daten in ein Paragraph-Element <p>...</p> eingefügt. 2. Für jedes PresentationElement, das nicht aus weiteren Elementen zusammengesetzt ist, wird der XPath-Ausdruck des dataxpath-attributs ausgewertet. Die Daten zu diesem Ausdruck werden aus dem XML-Datendokument geladen. Diese Daten werden mit dem Label des Präsentationselement versehen und in das HTML-Fragment übernommen. 3. Table-Elemente werden in eine HTML-Tabelle <table> transformiert. 4. Eine PresentationGroup wird in ein <div>-element transformiert. Für jedes dieser <div>-elemente wird eine eindeutige Id generiert, die zu Formatierungszwecken genutzt werden kann. 5. Die Daten eines TextElements werden in einem Absatzelement <p>...</p> eingeschlossen. Es wird zunächst das label dargestellt, das mit einem Doppelpunkt vom Inhalt dieses Elements getrennt wird. 6. Ein Graphic-Elemente wird in ein <img... >-Element transformiert. Das src-attribut dieses Elements bleibt leer, das alt-attribut wird mit dem Text aus dem Datendokument gefüllt. 7. Audio- und Video-Elemente werden in ein <object... >-Element transformiert. Innerhalb dieses Elements wird ebenfalls ein alternativer Text angegeben, der die Daten aus dem XML-Dokument präsentiert. 8. Für jedes SwitchElement wird standardmäßig das erste Element der value-liste erzeugt. 9. Alle Elemente werden so oft transformiert, wie Daten für das jeweilige Element vorhanden sind, höchstens jedoch so oft, wie es ihr maxvaluecount-attribut zulässt. Listing 5.2: Algorithmus PresentationToHTML transformpresentationelementtohtml(uielement ui, XMLData sampledata){ if(uielement has ContentElement) if(content.gettype() == "HTML") selectcontent(uielement); else generatehtmlparagraphelement(content); if(uielement is TableElement) generatehtmltable(uielement, sampledata); if(uielement is PresentationGroup){ divelement = generatehtmldivelement(uielement, sampledata); for(groupelement : uielement.getgroupelements) divelement.add(transformpresentationelementtohtml(groupelement, sampledata)); } if(uielement is TextElement) generatehtmlparagraphelement(uielement, sampledata); if(uielement is Graphic) generateimageelement(uielement, sampledata); if(uielement is Audio or Video) generateobjectelement(uielement, sampledata); if(uielement is SwitchElement){ firstvalue = uielement.getfirstvalue(); transformpresentationelementtohtml(firstvalue, sampledata); } } 73

79 5. Entwicklung eines WS-Prototyps Abbildung 5.8.: Browserdarstellung der mit dem Algorithmus PresentationToHTML erzeugten Oberfläche für die KeywordSearchResponse -Nachricht des Online- Bestellservices Ebenso wie mit dem FormToHTML-Algorithmus werden mit dem PresentationToHTML- Algorithmus lediglich die benötigten HTML-Elemente erzeugt, ohne dabei ein Layout zu erstellen. Um die einzelnen Elemente kenntlich zu machen, werden die Inhalte durch Absätze oder <div>-elemente voneinander getrennt. Abbildung 5.8 zeigt die Browserdarstellung der KeywordSearchResponse-Nachricht, die mit dem PresentationToHTML-Algorithmus erzeugt wurde Transformation von Mappings Mit einem WS-Prototyp soll demonstriert werden können, an welchen Stellen innerhalb eines Workflows Daten ausgetausch werden können. Dazu werden in der Annotationsphase Mappings erstellt. Diese definieren korrespondierende Elemente für einen Workflow, also Elemente, die den gleichen Inhalt darstellen. Um die Mappings bei der Transformation eines Workflows in HTML-Fragmente zu berücksichtigen, wurden die folgenden zwei Mapping-Regel definiert: 1. Mappings zwischen zwei Formularelementen werden berücksichtigt, wenn die beiden Formularelemente des Mappings zu derselben WSView gehören. In diesem Fall wird nur eins der beiden Formularelemente erzeugt. 2. Mappings zwischen Präsentations- und Formularelementen werden zwischen beliebigen WSViews eines Workflows berücksichtigt. Allerdings muss das Formularelement des Mappings entweder derselben WSView zugeordnet sein wie das Präsentationselement oder es muss zu einer WSView gehören, die in der zeitlichen Reihenfolge nach der WSView auftritt, die das Präsentationselement darstellt. Nur wenn diese Bedingung erfüllt ist, sind die gemappten Daten auf dem Client vorhanden und können in das Formularfeld übernommen werden. Um ein Mapping zwischen einem Präsentations- und einem Formula- 74

80 5. Entwicklung eines WS-Prototyps Listing 5.3: Algorithmus MappingToHTML transformmappingstohtml(wsmessageworkflow wf){ for(mapping : wf.getmappings()){ sourceviewlist = wf.getwsviewsthatpresent(mapping.getsource()); targetviewlist = wf.getwsviewsthatpresent(mapping.gettarget()); for(sourceview : sourceviewlist){ for(targetview : targetviewlist){ }}}} if(targetview == sourceview){ if(mapping.getsource() is FormElement) targetview.addformmapping(mapping); else targetview.adddatamapping(mapping); } else if(targetview.proceeds(sourceview) && mapping.getsource() is PresentationElement){ targetview.adddatamapping(mapping); } relement in ein HTML-Element zu transformieren, kann das Formularelement entsprechend der Regeln des FormToHTML-Algorithmus erzeugt werden. Die Daten des Präsentationselements werden als Vorgabewerte in dieses Formularfeld gesetzt. Ein gemapptes Element wird auf der Oberfläche der WSView dargestellt, für die das Formularelement definiert ist. In Listing 5.3 ist der Algorithmus MappingToHTML dargestellt, der zum Erstellen von HTML- Elementen für Mappings verwendet werden kann Kombination von HTML-Fragmenten zu einer Oberfläche Mit den bisher vorgestellten Transformationsalgorithmen wird für jede WSView eine separate Oberfläche erzeugt. Einem Benutzer werden diese Oberflächen nacheinander präsentiert. Nach jedem Webserviceaufruf wird also eine neue Oberfläche dargestellt. Für einen Benutzer kann es zur Unterstützung seiner Arbeit manchmal hilfreich sein, eine neue Oberfläche in einer alten zu integrieren, also praktisch zwei Oberflächen zu einer zusammenzufassen. Abbildung 5.9 veranschaulicht die zwei möglichen Varianten der Darstellung von zwei Oberflächen. Es können dabei nicht nur komplette Oberflächen miteinander kombiniert werden, sondern es ist auch möglich, nur bestimmte Elemente einer Oberfläche noch einmal auf einer anderen zu wiederholen. (a) Getrennte Darstellung von zwei Oberflächen (b) Kombination einer neuen Oberfläche mit einer bereits vorhandenen Oberfläche Abbildung 5.9.: Darstellungsvarianten von Maskenabfolgen 75

81 5. Entwicklung eines WS-Prototyps Abbildung 5.10.: Ausschnitt aus dem Metamodell für WSMessageWorkflows mit referencedelements Um eine solche Kombination von Oberflächen, wie sie in Abbildung 5.9(b) dargestellt ist, zu modellieren, werden referencedelements definiert. Mit Hilfe von referencedelements lassen sich Elemente, die für eine Oberfläche definiert sind, auf einer anderen Oberfläche wiederholen. Abbildung 5.10 zeigt das Metamodell für WSMessageWorkflows, in dem referencedelements modelliert sind. Jede WSView besitzt eine Liste von UIElements, welche die zu referenzierenden Elemente enthält. Beim Modellieren von referencedelements ist zu beachten, dass nur solche Elemente von einer WSView referenziert werden dürfen, die in einem WSMessageWorkflow bereits vorhanden sind. Ein UIElement ist ab dem Zeitpunkt in einem WSMessageWorkflow vorhanden, zu dem die Oberfläche, für die es definiert ist, das erste Mal dargestellt wird. Alle Oberflächen, die in einem WSMessageWorkflow danach aufgerufen werden, können also das jeweilige Element referenzieren. Mit Hilfe von referencedelements lässt sich z.b. das Nachladen von Daten modellieren. Dazu werden alle UIElements einer WSView von der nachfolgenden WSView referenziert. Für einen Benutzer stellt sich die Abfolge dieser zwei Oberflächen wie in Abbildung 5.9(b) veranschaulicht dar. Alle Elemente der ersten Oberfläche bleiben auch nach dem Webserviceaufruf vorhanden, die neuen Daten werden zusätzlich angezeigt. Prototypentwickler können das Referenzieren von Elementen dazu benutzen, bereits modellierte WSMessageWorkflows individuell anzupassen. Ob Elemente auf verschiedenen Oberflächen wiederholt dargestellt werden sollen, hängt in ersten Linie von Benutzeranforderungen ab. Da ein WS-Analytiker diese im Allgemeinen in der Annotationsphase des Prototyping-Prozesses nicht kennt, wird er zunächst einen allgemeinen Workflow ohne referencedelements modellieren. Prototypentwickler dagegen sollten Benutzer und deren Arbeitsabläufe analysieren und die allgemeinen Oberflächen entsprechend anpassen. 76

82 5.5. Zusammenfassung 5. Entwicklung eines WS-Prototyps In diesem Kapitel wurde die Entwicklungsphase des Prototyping-Prozesses vorgestellt. Ein WS- Prototyp, der in dieser Phase entwickelt wird, besteht aus einem Portal-Template und HTML- Fragmenten. HTML-Fragmente visualisieren die WSMessageWorkflows, die in dem Prototyp dargestellt werden. Um das Erstellen der HTML-Fragmente zum Teil zu automatisieren, wurden Algorithmen definiert, mit denen die abstrakten Oberflächenbeschreibungen aus den Annotationen der WSDL-Datein in HTML-Fragmente transformiert werden können. Um komplexe Prozesse mit mehr als einem Webservice darstellen zu können, wurden WSMessageWorkflow- Kompositionen definiert. Diese lassen sich durch Kombination einfacher WSMessageWorkflows erstellen. Im nächsten Kapitel wird erläutert, wie ein WS-Prototyp während der Analysephase eines SOA- Portalprojekts ausgewertet werden kann. 77

83 6. Auswertung eines WS-Prototyps In diesem Kapitel wird die Auswertungsphase des Prototyping-Prozesses erläutert. In der Auswertungsphase wird ein zuvor entwickelter WS-Prototyp den Stakeholdern eines SOA- Portalprojekts demonstriert. Abbildung 6.1.: Die Auswertungsphase des Prototyping-Prozesses Die Demonstration dient dazu, die Anforderungen an die zu entwickelnde SOA- Portalanwendung zu erheben, präziser zu erfassen und zu validieren. In diesem Kapitel wird gezeigt, wie Interviews als Auswertungsmethode verwendet werden können. Dazu werden Kommentarklassen vorgestellt, die in einem Interview helfen können, die Reaktionen und Kommentare eines Stakeholders systematisch zu erfassen. Für die Auswertung der Interviewergebnisse werden verschiedene Report-Varianten vorgestellt. Mit diesen können spezifische Auswertungsberichte für die unterschiedlichen Rollen im Prototyping-Prozess erstellt werden Interviews als Auswertungsmethode Prototyp für Interview vorbereiten Prototyp modifizieren Interview durchführen Interview auswerten Interview vorbereiten Abbildung 6.2.: Der Auswertungsprozess eines WS-Prototyps Ein WS-Prototyp soll die Anforderungserhebung in SOA-Portalprojekten verbessern. Er wird deshalb nach seiner Entwicklung verschiedenen Stakeholder des Projekts demonstriert. Es gibt 78

84 6. Auswertung eines WS-Prototyps verschiedene Möglichkeiten, eine solche Demonstration durchzuführen. Die Demonstration kann z.b. in einem Workshop erfolgen, in dem mehrere Stakeholder mit verschiedenen Interessen anwesend sind. Eine andere Möglichkeit der Auswertung stellen Gruppengespräche dar, in denen der Prototyp einer kleinen Gruppe von Stakeholdern mit gleichen oder ähnlichen Interessen präsentiert wird. Außerdem können Interviews zwischen einem Systemanalytiker und einem Stakeholder als Auswertungsmethode verwendet werden. Workshops eignen sich vermutlich eher weniger zur Demonstration. Ein WS-Prototyp ist ein elektronischer Oberflächenprototyp und muss deshalb an einem Bildschirm präsentiert werden. Bei einer größeren Gruppe von Betrachtern könnte der Bildschirminhalt theoretisch projiziert werden. Bei einer entfernten Projektion verlieren die Betrachter jedoch schnell den Bezug zu den Elementen des Prototyps. Einzelne Aspekte der Oberfläche z.b. können dann nur schwer diskutiert werden. Auch bei einer kleineren Gruppe bleibt das Problem bestehen, dass der Prototyp auf einem Bildschirm präsentiert werden muss, vor dem alle Betrachter Platz haben. Mehr als zwei bis drei Personen dürfen also auch bei einem Gruppengespräch nicht anwesend sein. Da solche kleinen Gruppengespräche ähnlich zu einem Interview aufgebaut sind, werden in dieser Arbeit Interviews als die zu empfehlende Demonstrationsmethode für die Auswertung von WS- Prototypen vorgestellt. Vor einem Interview ist zu überlegen, ob der Prototyp von einem Systemanalytiker vorgeführt wird oder ob ein Stakeholder mit dem Prototyp direkt interagiert. Da ein WS-Prototyp bei einer Demonstration zum Teil konfigurierbar sein soll, muss er mit einem Werkzeug demonstriert werden, das diese Konfiguration ermöglicht. Einem Stakeholder ist dieses Werkzeug nicht vertraut. Deshalb sollte ein Systemanalytiker den Prototyp vorführen. Abbildung 6.2 zeigt den Prozess der Auswertung eines Prototyps im Rahmen eines Interviews. Die Auswertung wird von einem Systemanalytiker vorgenommen. Dieser muss sich zunächst mit dem Prototyp vertraut machen, sofern er nicht selbst an seiner Entwicklung beteiligt war. Es ist wichtig, dass der Systemanalytiker über alle Entwurfsentscheidungen des Prototyps informiert ist. Er muss wissen, warum bestimmte Webservices gewählt wurde, welcher Zweck mit den Maskenabfolgen verfolgt wird oder welche Daten für einen Webserviceaufruf benötigt werden. Nur wenn er diese Informationen kennt, kann er eine systematische Auswertung des Prototyps in einem Interview durchführen. Neben der Vorbereitung des Prototyps ist eine generelle Vorbereitung auf ein Interview erforderlich. Hierzu gehört die Auswahl einer Referenzperson aus einer Gruppe von Stakeholdern, das Festlegen der konkreten Ziele für dieses Interview sowie die Entwicklung eines Durchführungsplans. Alexander und Stevens [AS02] geben einen Überblick darüber, welche Aspekte bei der Planung eines Interviews berücksichtigt werden sollten. Nach einem Interview müssen die Ergebnisse ausgewertet und analysiert werden. Dazu ist es wichtig, dass ein Systemanalytiker die Reaktionen der Stakeholder während des Interviews möglichst präzise erfasst. Aufzeichnungen eines Interviews durch ein Video oder einen Tonmitschnitt lassen sich detaillierter auswerten als Mitschriften. Die Auswertung dieser Aufzeichnungen ist aber auch zeitaufwändiger. Zudem ist für einen Mitschnitt eines Interviews die Erlaubnis des Interviewten sowie des Kunden erforderlich. Weiterhin ist zu bedenken, dass sich ein Stakeholder durch eine solche Aufzeichnung gehemmt fühlen könnte. Die Reaktionen der Stakeholder auf einen Prototyp werden daher häufig in schriftlicher Form fixiert werden müssen. Dazu soll ein Interviewwerkzeug zur Verfügung stehen, mit dem die 79

85 6. Auswertung eines WS-Prototyps Kommentare direkt an einem Prototyp erfasst werden können. Die Ergebnisse eines Interviews fließen zum einen in die Gestaltung der Anforderungen ein, zum anderen können sie dazu verwendet werden, den Prototyp für weitere Auswertungen anzupassen. Anpassungen und weitere Auswertungen können z.b. erforderlich sein, wenn der Prototyp zu Validierungszwecken eingesetzt werden soll. Anforderungen von Stakeholdern aus einem ersten Interview könnten dazu in einem Prototyp umgesetzt werden. Anschließend kann der modifizierte Prototyp den Stakeholdern noch einmal präsentiert werden Qualitätseigenschaften von Webservices Sollen die beim Prototyping verwendeten Webservices später in der zu entwickelnden Anwendung eingesetzt werden, so sind nicht nur funktionale Aspekte der Webservices relevant. Vor allem, wenn verschiedene Webservices mit ähnlicher Funktionalität zur Verfügung stehen, wird ein Kunde Qualitätseigenschaften zur Auswahl eines Services heranziehen. Bei der Demonstation eines WS-Prototyps ist es deshalb nützlich, wenn dem Kunden Auskunft zu Qualitätsparametern der verwendeten Webservices gegeben werden kann. Es gibt eine Reihe von Qualitätsaspekten, die für einen Webservice spezifiziert werden können. Die meisten Kunden werden zunächst die Kosten interessieren, die bei der Nutzung eines Services anfallen. Anhand dieser Kosten können sie abwägen, ob der Einsatz des Services rentabel ist oder ob vielleicht doch eine Neuentwicklung in Betracht gezogen werden soll. Des Weiteren können bei einigen Anwendungen Performance Aspekte relevant sein. Zu diesen gehören z.b. Daten zur durchschnittlichen Reaktions- oder Verarbeitungszeit eines Webservices. Je nachdem, zu welchem Zweck ein Webservice genutzt werden soll, können auch Sicherheitsaspekte eine Rolle spielen. In Tabelle 6.1 sind die wichtigsten, am häufigsten verwendeten Qualitätseigenschaften von Webservices zusammengefasst. Qualitätseigenschaft Execution Price Execution Time Availability Reliability Security Beschreibung Kosten für die Nutzung des gesamten Services oder einzelner Operationen die Ausführungszeit einer Operation, also die Zeit, die ein Webservice braucht, um eine Anfrage zu bearbeiten die Wahrscheinlichkeit, dass ein Webservice zu einem bestimmten Zeitpunkt erreichbar ist die Zuverlässigkeit, dass ein Webservice eine Anfrage korrekt bearbeitet beinhaltet verschiedene Sicherheitsaspekte wie z.b. Verschlüsselung von Daten und Nachrichten oder Authentifizierungsmechanismen Tabelle 6.1.: Wichtige Qualitätseigenschaften von Webservices Webserviceanbieter können und sollten Qualitätsbeschreibungen ihres Services zusätzlich zu den Funktionalitätsbeschreibungen veröffentlichen. Während sich zur Beschreibung der 80

86 6. Auswertung eines WS-Prototyps Funktionalität jedoch der WSDL-Standard etabliert hat, gibt es für die Definition von Qualitätseigenschaften eine Reihe von unterschiedlichen XML-Formaten. WSMO [BLK + 05], WS- Policy [W3C06] oder WSOL [TPP02] sind nur einige der Möglichkeiten, die Webserviceanbietern zur Verfügung stehen. In [RP06] wird ein kurzer Überblick über die am weitesten verbreiteten Beschreibungssprachen für Qualitätseigenschaften gegeben. Aufgrund dieser vielen verschiedenen Formate ist es schwierig, eine systematische Auswertung von Qualitätsbeschreibungen vorzunehmen. Häufig werden von Serviceanbietern zudem keine Informationen zu Qualitätsaspekten ihrer Services bereitgestellt. Beim Prototyping können Qualitätsbeschreibungen daher nur manuell ausgewertet werden. Dabei sollen nach Möglichkeit die in Tabelle 6.1 definierten Aspekte berücksichtigt werden, sofern sie von Webserviceanbietern zur Verfügung gestellt werden. Die Daten zu den Qualitätseigenschaften sollten in einem Demonstrationswerkzeug für einen WS-Prototyp abrufbar sein Die Demonstration eines WS-Prototyps Erfassen von Kommentaren Die Reaktionen von Stakeholdern auf einen Prototyp stellen das Ergebnis des Prototypings dar. Auf ihrer Basis werden neue Anforderungen an die zu entwickelnde Anwendung formuliert oder bereits erhobene Anforderungen überarbeitet und präzisiert. Das Erfassen der Reaktionen und Kommentare eines Stakeholders während einer Demonstration eines WS-Prototyps ist deshalb sehr wichtig. Da in einem WS-Prototyp verschiedene Webservices und HTML-Fragmente demonstriert werden, ist es hilfreich, die Kommentare mit einem Bezug zu diesen Elementen zu erfassen. Dadurch wird die Auswertung der Kommentare nach einem Interview erleichtert. In einem Interview muss die Dokumentation der Kommentare und Reaktionen eines Stakeholders meistens sehr schnell erfolgen. Es ist wenig Zeit für ausführliche Notizen. Deshalb soll die Interviewführung und das Erfassen von Kommentaren durch ein Interviewwerkzeug unterstützt werden. Dieses Werkzeug soll gleichzeitig als Demonstrationswerkzeug für einen WS-Prototyp dienen. Dadurch wird es möglich, dass Kommentare direkt an den einzelnen Elementen eines WS-Prototyps notiert werden können. Es werden dazu Kommentarklassen gebildet, die den verschiedenen Elementen eines WS-Prototyps zugeordnet werden. In Abbildung 6.3 sind die Komponenten eines WS-Prototyps mit den entsprechenden Kommentarklassen dargestellt. Jeder Kommentar wird genau einem Element zugeordnet. Die folgenden Kommentarklassen wurden identifiziert: WSComment: Diese Klasse umfasst alle Kommentare, die sich auf die generellen Eigenschaften eines Webservices beziehen. Hierzu gehören sowohl Kommentare zu funktionalen Aspekten als auch zu Qualitätseigenschaften eines Webservices. Kommentare zu funktionalen Aspekten können z.b. fehlende Operationen oder nicht passenden Eingabeparameter beschreiben. Kommentare zu Qualitätseigenschaften können beispielsweise die Kosten für die Nutzung eines Webservices betreffen. WorkflowComment: Kommentare dieser Klasse beziehen sich auf Arbeitsabläufe und die damit verbundene Abfolge von Masken. Unter diese Kategorie fallen z.b. Änderungswünsche eines Benutzers in Bezug auf die Navigationsmöglichkeiten. Auch Aussagen über fehlende Masken oder die Anforderung, bestimmte Oberflächen zusammenzufassen, gehören zu dieser Kategorie von Kommentaren. 81

87 6. Auswertung eines WS-Prototyps Abbildung 6.3.: Komponenten eines WS-Prototyps mit Kommentarklassen ViewComment: Zu dieser Klasse gehören Kommentare, die sich auf eine einzelne Oberfläche beziehen. Diese Art von Kommentare betrifft z.b. die Anordnung von Elementen auf einer Oberfläche oder die Art der Umsetzung eines Formularelements (ein Benutzer hätte vielleicht lieber eine Auswahlliste statt eines einfachen Eingabefelds). TemplateComment: Die Klasse TemplateComment umfasst alle Aussagen zur Gestaltung des Templates. Hierzu gehören Reaktionen auf das Layout sowie zur Anordnung von Workflows in den einzelnen Service-Areas. GeneralComment: In diese Klasse fallen alle Kommentare, die sich keiner der anderen Klassen zuordnen lassen. Die Zuordnung eines Kommentars zu einem Element des Prototyps sollte in einem Demonstrationswerkzeug soweit wie möglich automatisiert erfolgen. Eine zumindest semi-automatische Zuordnung kann erreicht werden, wenn für jede Kommentarklasse eine eigene Menüfunktion erstellt wird. Zusätzlich kann ein Demonstrationswerkzeug so gestaltet werden, dass sich die Kommentarfunktion für Kommentare der Klassen WSComment, WorkflowComment und View- Comment in den einzelnen Service-Areas des Prototyps aufrufen lässt. Auf diese Weise kann ein Kommentar dem Element zugeordnet werden, das gerade in der Service-Area dargestellt ist. In Abbildung 6.4 ist ein Entwurf für die Kommentarfunktion eines Demonstrationswerkzeugs dargestellt. Auf der linken Seite des geöffneten Kommentardialogs kann die Kategorie für einen zu erstellenden Kommentar ausgewählt werden. Innerhalb des Demonstrationswerkzeugs existieren verschiedenen Menüpunkte, über die die Kommentarfunktion aufgerufen werden kann. Anhand des Menüpunkts, über den der Kommentardialog geöffnet wird, wird die Vorauswahl der Kommentarklasse bestimmt. In dem dargestellten Beispiel wurde der Kommentardialog in einer Service-Area aufgerufen. Deshalb ist die Klasse ViewComment selektiert. Ein Kommentar, der mit dem gerade geöffneten Dialog erstellt wird, wird dem HTML-Fragment zugeordnet, das gerade in der entsprechenden Service-Area dargestellt ist. 82

88 6. Auswertung eines WS-Prototyps Abbildung 6.4.: Entwurf für die Kommentarfunktion eines Demonstrationswerkzeugs Konfiguration eines WS-Prototyps Es gibt mehrere Gründe dafür, warum ein WS-Prototyp zu einem gewissen Maße während einer Demonstration konfigurierbar sein sollte. Mit einem WS-Prototyp sollen z.b. verschiedene Webservices präsentiert werden können. Dafür ist es hilfreich, wenn die Services während der Demonstration gegeneinander austauschbar sind. Sollen Anforderungen für den generellen Aufbau der Portal-Seite erhoben werden, macht es Sinn, dass verschiedene Varianten von Portal-Templates präsentiert werden können. Generell ist die Konfiguration eines WS-Prototyps hilfreich, wenn ein Systemanalytiker direkt in einem Interview die Anforderungen eines Stakeholders validieren will. Passen die Maskenabfolgen eines WS-Prototyps z.b. nicht zu den Arbeitsschritten eines Benutzers, so wäre es nützlich, wenn der Systemanalytiker ihm alternative Maskenabfolgen präsentieren könnte. Die Konfigurationsmöglichkeiten eines WS-Prototyps sollen über ein Werkzeug gesteuert werden und schnell und einfach ausführbar sein. In einem Interview mit einem Stakeholder darf ein Systemanalytiker nicht mehrere Minuten an einem WS-Prototyp rumbasteln, um diesen zu ändern. Dadurch würde er das Interview stören und ein Stakeholder würde sich in dieser Zeit überflüssig vorkommen. Für jeden Konfigurationsschritt sollen deshalb nur ein paar Mausklicks erforderlich sein. Die möglichen Konfigurationspunkte eines WS-Prototyps lassen sich anhand der Komponenten identifizieren, aus denen ein Prototyp besteht. Diese sind in Abbildung 6.3 dargestellt. Im Folgenden wird erläutert, auf welche Weise diese verschiedenen Komponenten während einer Demonstration konfiguriert werden können. Konfiguration des Portal-Templates: An einem Portal-Template kann das Layout geändert werden, d.h. die Anzahl, die Größe und die Anordnung der Service-Areas kann variiert werden. Die einfachste Möglichkeit, diese Konfigurationsmöglichkeit zu realisieren, be- 83

89 6. Auswertung eines WS-Prototyps steht darin, mehrere Templates zur Verfügung zu stellen, die gegeneinander ausgetauscht werden können. Für das Prototyping ist es nicht erforderlich, dass Service-Areas in einer exakten Größen dargestellt und an ganz bestimmten Positionen platziert werden. Deshalb kann mit einer überschaubaren Menge an Templates eine Vielzahl von Gestaltungsmöglichkeiten abgedeckt werden. Konfiguration eines Workflows: Workflows, die in einer Service-Area dargestellt werden, sind durch die Anzahl der HTML-Fragmente und der Links zwischen diesen HTML- Fragmenten charakterisiert. Neue HTML-Fragmente können während einer Demonstration eines Prototyps nicht ohne Aufwand erstellt werden. Bei der Entwicklung eines WS- Prototyps können jedoch mehrere alternative HTML-Fragmente erstellt werden. Mit Hilfe von alternativen Links, können die verschiedenen Oberflächen dann während einer Demonstration präsentiert werden. Konfiguration eines HTML-Fragments: Die Konfiguration eines HTML-Fragments bedeutet, dass Änderungen am HTML-Code vorgenommen werden müssen. Diese Änderungen sollen, genau wie alle anderen Konfigurationen, über ein Werkzeug erfolgen. Eine hilfreiche Funktion für das Anpassen eines HTML-Fragments stellt die Möglichkeit dar, optionale Elemente auf der Oberfläche ein- und auszublenden. Alle optionalen Elemente müssen dazu mit einer entsprechenden Markierung versehen werden. Das Ein- und Ausblenden von Elementen kann bei Masken, die sehr viele Elemente enthalten, hilfreich sein. Austausch von Workflows: Für einen Webservice können verschiedene Workflows definiert werden, die während der Demonstration gegeneinander ausgetauscht werden können. Durch die Verwendung eines AJAX-Frameworks ist es möglich, Workflows von einem Server zu laden. In jeder Service-Area können so verschiedene Workflows demonstriert werden. Austausch von Webservices Auf die gleiche Weise wie sich Workflows austauschen lassen, lassen sich auch komplette Webservices gegeneinander austauschen Auswertungsbericht Nach einer Demonstration eines WS-Prototyps muss ein Systemanalytiker die Ergebnisse der Demonstration auswerten. Bei der Auswertung helfen ihm die Kommentare, die er während der Demonstration erfasst hat. Aus den Ergebnissen werden Anforderungen an die zu entwickelnde Anwendung formuliert. Außerdem können die Ergebnisse dazu verwendet werden, den WS- Prototyp für eine erneute Auswertung anzupassen. Für die Auswertung ist es hilfreich, wenn ein Demonstrationswerkzeug die erfassten Kommentare in einem Report zusammenfasst. Außerdem sollten die Kommentare an den einzelnen Komponenten, auf die sie sich beziehen, dargestellt werden können. In einem Report zu einem WS-Prototyp können nicht nur die Kommentare eines Interviews dokumentiert werden, sondern auch Daten zu den verwendeten Webservices und Workflows. Ein Report soll von einem Demonstrationswerkzeug automatisch erstellt werden können. Er enthält deshalb nur Informationen, die in einem WS-Prototyp zur Verfügung stehen und automatisch ausgewertet werden können. In Abbildung 6.5 ist der Aufbau eines Reports dargestellt. Ein Report besteht aus mehreren Report-Elementen. Folgende Elemente können vorhanden sein: 84

90 6. Auswertung eines WS-Prototyps Abbildung 6.5.: Komponenten eines WS-Prototyp-Reports WebserviceReport: Zu jedem Webservices, der in einem WS-Prototyp verwendet wird, kann ein WebserviceReport erstellt werden. In diesem können Daten zum Serviceanbieter, eine kurze Beschreibung des Services, Qualitätseigenschaften (Preis, Bearbeitungszeit, Verfügbarkeit, Zuverlässigkeit, Sicherheitsaspekte) sowie eine Demoadresse enthalten sein. Außerdem können alle Kommentare der Kategorie WSComment, die zu diesem Service gehören, aufgelistet werden. Ein WebserviceReport kann sowohl für Webservices erstellt werden, die in einem Prototyp verwendet werden, als auch für alternative Webservices. Dafür werden in einem Report used und notused WebserviceReports unterschieden. TemplateReport: In einem TemplateReport werden Informationen über das verwendete Template dokumentiert. In diesem Teilbereich eines Reports kann z.b. ein Screenshot des Portal-Templates dargestellt werden. Außerdem können alle Kommentare der Klasse TemplateComment diesem Report-Element zugeordnet werden. WorkflowReport: Ein WorkflowReport stellt Informationen zu einem Workflow dar. Er enthält eine kurze Beschreibung des Workflows sowie alle Kommentare der Kategorien Workflow- Comment und ViewComment. Ein WorkflowReport kann für benutzte sowie alternative Workflows erstellt werden. Dieser Teil eines Reports enthält alle Kommentare der Kategorie GeneralCom- Comment: ment. Mit der vorgestellten Report-Struktur können verschiedene Arten von Reports erstellt werden. Für jede Rolle, die in den Prototyping-Prozess involviert ist, können die für diese Rolle interessanten Aspekte zusammengefasst und dokumentiert werden. Tabelle 6.2 gibt eine Übersicht über die möglichen Report-Varianten und ihren Verwendungszweck. 85

91 6. Auswertung eines WS-Prototyps Report enthaltene Elemente Verwendungszweck Kompletter Report Interview- Report alle Kommentare und der TemplateReport Webservice- Report Webserviceanbieter: Anpassen eines Webservices an Kundenanforderungen Kunden- Report Template- Report alle Report-Elemente, notused Webservices und Workflows nur dann, wenn Kommentare vorhanden sind WebserviceReport (mit Kommentaren) für einen bestimmten Webservice, WorkflowReport (mit Kommentares) für alle Workflows dieses Webservices WebserviceReport ohne Kommentare für alle verwendeten und alternativen Webservices TemplateReport mit Kommentaren Systemanalytiker: Auswertung eines Interviews Interviewter Stakeholder: Validieren der dokumentierten Kommentare, um zu prüfen, ob ein Systemanalytiker die Aussagen korrekt erfasst hat Kunde: Vergleich und Auswahl von Webservices Prototypentwickler: Anpassen eines WS-Prototyps Tabelle 6.2.: Report-Varianten für die verschiedenen Rollen im Prototyping-Prozess 6.5. Zusammenfassung In diesem Kapitel wurde die letzte Phase des Prototyping-Prozesses - die Auswertungsphase - vorgestellt. Als Auswertungsmethode für einen WS-Prototyp wurden Interviews mit Stakeholdern empfohlen. Die Demonstration eines WS-Prototyps in einem Interview soll durch ein Werkzeug unterstützt werden. Mit einen solchen Interviewwerkzeug sollen Kommentare direkt an den Elementen eines WS-Prototyps dokumentiert werden können. In diesem Kapitel wurde erläutert, auf welche Weise sich eine solche Kommentarfunktion realisieren lässt. Dazu wurden Kommentarklassen erstellt, die den Elementen eines WS-Prototyps zugeordnet wurden. Für die Auswertung wurde des Weiteren eine allgemeine Struktur für einen Report definiert. Ein Report für einen WS-Prototyp ist aus mehreren Elementen aufgebaut, die sich in verschiedenen Varianten miteinander kombinieren lassen. Diese Struktur ermöglicht es, verschiedene Reports für die einzelnen Rollen, die in den Prototyping-Prozess involviert sind, zu erstellen. In einem Interview sollen zu einem Webservice, der in einem Prototyp verwendet wird, auch Qualitätseigenschaften dargestellt werden können. Die Kosten für die Nutzung eines Webservices, die Verfügbarkeit und Zuverlässigkeit sowie Sicherheits- und Performanceaspekte wurden als wichtige Qualitätskriterien für einen Webservice definiert. 86

92 7. Referenzimplementierungen Zur Unterstützung des Vorgehensmodells zum Prototyping mit Webservices wurden zwei Werkzeuge implementiert, die in diesem Kapitel vorgestellt werden. Die Werkzeuge dienen als Referenzimplementierung, um zu zeigen, auf welche Weise die entwickelten Konzepte umgesetzt werden können. Der AnnotationGenerator wird in der Annotationsphase des Prototyping- Prozesses verwendet. Der WSPrototypEditor kommt in der Entwicklungs- und in der Auswertungsphase zum Einsatz. Zusammen bieten die beiden Werkzeuge Unterstützung für alle drei Phasen des Prototyping-Prozesses AnnotationGenerator Der AnnotationGenerator implementiert die Algorithmen XSDToForm, XSDToPresentation und XSDToXML. Ein Benutzer des AnnotationGenerators kann über eine graphische Oberfläche eine WSDL- Datei laden. Für diese WSDL-Datei kann er sich eine Prototyping-Datei generieren lassen. Der AnnotationGenerator erstellt bei diesem Prozess für jede Nachricht der WSDL-Datei eine abstrakte Oberflächenbeschreibung und für die output-nachrichten zusätzlich ein XML- Datendokument. Jede generierte Oberflächenbeschreibung wird in einer separaten XML-Datei gespeichert. Diese XML-Dateien sind schemakonform zu dem in dieser Arbeit entwickelten XML-Schema für Oberflächenbeschreibungen. Alle generierten Komponenten werden vom AnnotationGenerator in einer Prototyping-Datei verlinkt. Diese ist gemäß dem XML-Schema für Prototyping-Dateien aufgebaut, das in Kapitel 4.9 vorgestellt wurde. Allerdings werden vom AnnotationGenerator noch keine Mappings generiert. Diese müssen hinterher manuell in die generierten Dateien eingefügt werden. Der AnnotationGenerator erstellt weiterhin eine Kopie der WSDL-Datei. In dieser Kopie wird die generierte Prototyping-Datei verlinkt. Für alle Verlinkungen werden relative Pfade angegeben. Die generierten Komponenten sowie die Kopie der WSDL-Datei werden in einem Ordner des Dateisystems gespeichert. Ein Benutzer des AnnotationGenerators kann neben der WSDL-Datei eine WSMessageWorkflow-Datei laden. Diese Datei wird dann ebenfalls in der Prototyping-Datei verlinkt. WS-Analytiker können den AnnotationGenerator während der Annotationsphase des Prototyping-Prozesses nutzen, um sich für eine WSDL-Datei abstrakte Oberflächenbeschreibungen und XML-Datendokumente generieren zu lassen. Die generierten Elemente können sie anschließend mit einem XML-Editor ihrer Wahl bearbeiten und anpassen. 87

93 7. Referenzimplementierungen Abbildung 7.1.: Screenshot des AnnotationGenerators 7.2. WSPrototypEditor Architektur Das zweite Werkzeug zur Unterstützung des Prototyping-Prozesses ist eine Kombination aus Entwicklungs- und Interviewwerkzeug. Der so genannte WSPrototypEditor kann sowohl zur Erstellung eines WS-Prototyps als auch zur Demonstration und Auswertung eingesetzt werden. Der WSPrototypEditor unterstützt in der Entwicklungsphase die Auswertung von Prototyping- Dateien, das Erstellen von HTML-Fragmenten und die Integration dieser HTML-Fragmente in ein Portal-Template. Die Interviewfunktion ermöglicht das Erfassen und die Auswertung von Kommentaren nach den in Kapitel definierten Kategorien. Der WSPrototypEditor wurde mit Hilfe des Google Web Toolkits [gwt08] in der Version 1.4 entwickelt. Das Google Web Toolkit (kurz: GWT) ist ein Ajax-Framework mit einem integrierten Java-to-Javascript Compiler. Webanwendungen können mit diesem Framework komplett in Java erstellt werden. Abbildung 7.2 zeigt die Architektur des WSPrototypEditors. Der Editor besteht aus einem Client und einem Server. Diese kommunizieren über so genannte Remote Procedure Calls miteinander. Die Remote Procedure Calls sind eine vom GWT zur Verfügung gestellte Funktionalität, die 88

94 7. Referenzimplementierungen Abbildung 7.2.: Architektur des WSPrototypEditors es ermöglicht, dass komplette Java-Objekte zwischen dem Client und dem Server ausgetauscht werden können. Der Server beinhaltet die komplette Logik des Editors. Außerdem besitzt er drei Schnittstellen zum Anbinden externer Datenspeicher. Im Service-Katalog werden annotierte WSDL-Dateien sowie die verlinkten Prototyping-Dateien und deren Komponenten gespeichert. Außerdem können in diesem Speicher WSMessageWorkflow-Kompositionen abgelegt werden. Der Template- Katalog, der über die zweite Schnittstelle angebunden wird, beinhaltet eine Auswahl von Portal- Templates. Im dritten externen Speicher, dem Projekt-Katalog, werden die Projekte gespeichert, die mit dem WSPrototypEditor erstellt werden. Jeder WS-Prototyp, der entwickelt wird, wird in einem WS-Projekt gespeichert. Zurzeit sind alle drei Speicher durch Ordner des Dateisystems realisiert. Es ist jedoch relativ einfach möglich, sie z.b. gegen eine Datenbank auszutauschen. Der Client besteht im Wesentlichen aus einer Weboberfläche. Er stellt eine gemeinsame Schnittstelle für Prototypentwickler und Systemanalytiker zur Verfügung. Die Weboberfläche ist ähnlich zu einer Desktop-Anwendung aufgebaut. Es existiert ein Menü sowie eine Toolleiste, über die die Funktionen, die der Editor zur Verfügung stellt, genutzt werden können. Die Funktionalitäten, die der Editor anbietet, werden in den zwei folgenden Unter-Kapiteln näher erläutert. Portal-Templates, die in dem WSPrototypEditor verwendet werden sollen, müssen ein paar Regeln erfüllen, damit sie vom Editor korrekt erkannt werden. Der gesamte Template-Inhalt muss in einem <div>-element eingeschlossen sein, das die Id Template besitzt. Jede Service- Area muss ebenfalls durch ein <div> gebildet werden, das mit einer bestimmten Id versehen sein muss. Diese Id muss dem Schema ServiceArea[zähler] entsprechen. Neben diesen Elementen kann ein Portal-Template beliebigen HTML-Code enthalten. Auch Stylesheets zur Gestaltung des Templates können verwendet werden. Somit ist es möglich, mit Hilfe von Webdesign-Tools komplexe Portal-Templates zu erstellen, die im WSPrototypEditor verwendet werden können. In Abbildung 7.3 ist die Struktur eines WS-Projekts dargestellt. Der eigentliche WS-Prototyp besteht aus einem Portal-Template und HTML-Fragmenten. Da bei der Demonstration eines WS-Prototyps aber auch Informationen zu den verwendeten Webservices zur Verfügung gestellt werden sollen, wird eine Projekt-Datei erstellt. In dieser werden alle benötigen Daten in einem XML-Format gespeichert. In einer Projekt-Datei sind folgende Informationen abgelegt: 89

95 7. Referenzimplementierungen Abbildung 7.3.: Struktur eines WS-Projekts eine Referenz auf das verwendete Template Referenzen auf die benutzten WSMessageWorkflows sowie die Webservices, die in diesen Workflows verwendet werden eine Liste mit Referenzen auf alternative Webservices die Zuordnung zwischen einer Service-Areas und dem WSMessageWorkflow, der in der jeweiligen Service-Area dargestellt wird Referenzen auf alle HTML-Fragmente, die in einer der Service-Areas dargestellt werden Kommentare aus einem Interview Metainformationen zum Projekt, wie z.b. eine kurze Beschreibung und das Erstellungsdatum Der WSPrototypEditor implementiert die Algorithmen FormToHTML und PresentationToHTML. Für einen WSMessageWorkflow können damit die benötigten HTML-Fragmente generiert werden. Jedes HTML-Fragment wird als separate Datei gespeichert. Diese Modularisierung vereinfacht die Anpassung der HTML-Fragmente. Ein Prototypentwickler kann jedes einzelne HTML- Fragment mit einem HTML-Editor seiner Wahl bearbeiten. Er kann dabei die Mappings manuell hinzufügen und eine Gestaltung des Layouts vornehmen Funktionalität zur Entwicklung eines WS-Prototyps Bei der Entwicklung eines WS-Prototyps wird zunächst ein neues WS-Projekt erstellt. Diesem Projekt wird ein Portal-Template zugeordnet, das die Basis für den Prototyp bildet. Außerdem können dem Projekt eine beliebige Anzahl an Webservices und WSMessageWorkflow- Kompositionen hinzugefügt werden. Der Editor stellt verschieden Ansichten für die Templateund Serviceauswahl zur Verfügung. Eine Template-Vorschau ermöglicht es, alle Templates aus dem Template-Katalog in der Browseransicht zu betrachten. Für die Auswahl von Webservices und Workflow-Kompositionen steht eine Serviceauswahl- Ansicht zur Verfügung. Abbildung 7.4 zeigt einen Screenshot dieser Ansicht. In der 90

96 7. Referenzimplementierungen Serviceauswahl-Ansicht werden alle Webservices und WSMessageWorkflow-Kompositionen aus dem Servicekatalog aufgelistet. Zu jedem Service und jeder Workflow-Komposition können Detailinformationen abgerufen werden. Bei einem Webservice beinhalten diese Informationen den Namen des Serviceanbieters, eine Beschreibung des Services sowie einen Überblick über alle verfügbaren WSMessageWorkflows dieses Webservices. Für eine WSMessageWorkflow- Komposition werden Informationen zu den verwendeten Webservice sowie eine Beschreibung der Komposition angezeigt. Die Webservices und WSMessageWorkflow können in der Serviceauswahl-Ansicht einem WS-Projekt zugeordnet werden. Abbildung 7.4.: Screenshot der Serviceauswahl-Ansicht des WSPrototypEditors Die Standardansicht des WSProtototypEditors ist eine Vorschau-Ansicht, die einen WS- Prototyp in der Browseransicht zeigt. In allen Bereichen des Portal-Templates, die der Editor als Service-Area identifiziert, kann zwischen einer Editier-Ansicht und einer HTML-Ansicht hin und her gewechselt werden. In der Editier-Ansicht wird eine Liste aller verfügbaren WSMessageWorkflows für das Projekt angezeigt. Nach der Auswahl eines Workflows werden die HTML- Fragmente des gewählten Workflows in der HTML-Ansicht dargestellt. Mit Hilfe einer Navigationsfunktion kann durch die einzelnen Fragmente des Workflows navigiert werden. Abbildung 7.5.: Screenshot der Vorschauansicht des WSPrototypEditors 91

97 7. Referenzimplementierungen Abbildung 7.5 zeigt einen Screenshot der Vorschau-Ansicht. Dargestellt ist ein WS-Prototyp mit zwei Service-Areas. In der linken Service-Areas ist die Editier-Ansicht zu sehen, in der rechten Service-Area wird gerade die HTML-Ansicht dargstellt Funktionalität zur Demonstration eines WS-Prototyps Der WSPrototypEditor kann als Demonstrations- und Interviewwerkzeug für einen WS-Prototyp verwendet werden. In der Vorschau-Ansicht des Editors kann ein WS-Prototyp präsentiert werden. Der WSPrototypEditor ist mit einer Kommentarfunktion ausgestattet, die entsprechend des Entwurfs aus Kapitel implementiert ist. Die Kommentarfunktion kann aus jeder Service-Area heraus aufgerufen werden. In den Service-Areas befindet sich dazu eine Toolleiste. Diese bietet neben dem Aufruf Kommentarfunktion auch die Möglichkeit, die Auswahl des WSMessageWorkflows in der ServiceArea zu ändern. Außerdem enthält sie zwei Buttons zur Navigation zwischen den HTML-Fragmenten. Abbildung 7.6 zeigt einen Screenshot, in dem die Toolleiste einer Service-Area und ein geöffneter Kommentardialog zu sehen sind. Abbildung 7.6.: Screenshot der Kommentarfunktion des WSPrototypEditors Um allgemeine Kommentare oder Kommentare zum Template zu erstellen, kann die Kommentarfunktion über eine Toolleiste im oberen Bereich des Editors aufgerufen werden. In dieser Toolleiste ist jeweils ein Button für Template-Kommentare und für allgemeine Kommentare vorhanden. Jenachdem über welchen dieser beiden Buttons der Kommentardialog aufgerufen wird, ist die jeweilige Kommentarkategorie im Dialog vorausgewählt. Wird der Kommentardialog aus einer Service-Area heraus aufgerufen, ist die Kategorie View vorselektiert. Ein Kommentar wird dem HTML-Fragment zugeordnet, das gerade in der Service-Area dargestellt ist. Alterna- 92

98 7. Referenzimplementierungen tiv kann er auch dem Workflow oder dem Webservice zugeordnet werden, zu dem das HTML- Fragment gehört. Da die Möglichkeit besteht, innerhalb einer Service-Area zwischen Editier- und HTML-Ansicht zu wechseln, können in einem Interview WSMessageWorkflows oder sogar komplette Webservices in einer Service-Area ausgetauscht werden. Dafür sollten die alternativen Workflows aber bereits bei der Prototypentwicklung vorbereitet werden. Der WSPrototypEditor bietet zwar die Möglichkeit an, HTML-Fragmente auch während eines Interviews generieren zu lassen, dabei werden aber HTML-Fragmente ohne Layout-Informationen erzeugt. Da in einem Interview keine Zeit vorhanden ist, um die generierten Fragmente manuell anzupassen, sollten diese bereits im Vorfeld erstellt und gestaltet werden. Während einer Demonstration ist es auch möglich, das Portal-Template auszutauschen. In diesem Fall müssen allerdings die WSMessageWorkflows erneut den Service-Areas zugeordnet werden. Eine automatische Übernahme wird vom WSPrototypEditor nicht unterstützt. Der WSPrototypEditor bietet die Möglichkeit, alle optionalen Elemente eines HTML-Fragments hervorzuheben. Optionale Elemente werden beim Generieren der HTML-Fragmente mit der CSS-Klasse optional gekennzeichnet. Ein Systemanalytiker kann innerhalb einer CSS-Datei des WSPrototypEditors selbst einstellen, auf welche Weise die Elemente dieser Klasse hervorgehoben werden sollen. Für die Auswertung eines Interviews stellt der WSPrototypEditor eine Report-Funktion zur Verfügung. Mit dieser Funktion kann ein Report generiert werden, dessen Struktur im Wesentlichen der in Kapitel 6.4 definierten Struktur für Reports entspricht. Allerdings werden keine Informationen zu Qualitätseigenschaften eines Webservices erstellt. Der WSPrototypEditor hat diese Daten nicht zur Verfügung. Auch Screenshots können mit der Report-Funktion nicht erstellt werden. Ein Report wird als Pdf-Dokument in dem WS-Projekt gespeichert, für das er erstellt wurde Zusammenfassung In diesem Kapitel wurden mit dem AnnotationGenerator und dem WSPrototypEditor zwei Werkzeuge vorgestellt, mit denen das Prototyping mit Webservices unterstützt werden kann. Der AnnotationGenerator reduziert den Aufwand der Annotationsphase. Er kann abstrakte Oberflächenbeschreibungen und XML-Datendokumente für eine WSDL-Datei generieren. Diese fasst er in einer Prototyping-Datei zusammen, die er mit einer Kopie der WSDL-Datei verlinkt. Der WSPrototypEditor unterstützt die Entwicklungs- und Auswertungsphase eines WS- Prototyps. Mit dem Editor lassen sich WSMessageWorkflows auf einem Portal-Template anordnen und automatisch in HTML-Fragmente transformieren. Für die Auswertung eines WS- Prototyps wird eine Kommentarfunktion zur Verfügung gestellt, die in einem Interview genutzt werden kann. Außerdem existiert eine Reportfunktion, mit der ein Auswertungsbericht für ein Interview generiert werden kann. 93

99 8. Ein Anwendungsbeispiel Um die Anwendbarkeit der Konzepte dieser Arbeit zu demonstrieren, wurde ein fiktives SOA- Projekt mit einem realen Hintergrund entworfen, in dem das Prototyping eingesetzt wurde. In diesem Kapitel wird das Anwendungsbeispiel kurz beschrieben. Es wird erläutert, welche Schritte des Prototypings durchlaufen und welche Beobachtungen dabei gemacht wurden Projektbeschreibung In diesem Abschnitt wird zunächst die Ausgangsbasis für das Anwendungsbeispiel beschrieben. Diese resultiert aus einer realen Situation in einem Callcenter einer Telekommunikationsfirma. Im Anschluss daran wird das fiktive SOA-Projekt, das für diese Ausgangslage konstruiert wurde, vorgestellt. Dabei wird erklärt, in welchem Rahmen und zu welchem Zweck das Prototyping eingesetzt wurde. Die folgende Beschreibung der IST-Situation wurde nach einem Telefoninterview mit einem Mitarbeiter des Callcenters (dieser wird im Folgenden als M. bezeichnet) erstellt. Zusätzlich zu der Beschreibung von M. lagen einige Screenshots der drei Anwendungen vor, mit denen M. zurzeit Arbeit. Beschreibung der IST-Situation Im Callcenter einer Telekommunikationsfirma wird für jedes Kundenproblem ein Ticket erstellt. Das Ticket dient zur internen Bearbeitung von Kundenaufträgen. Ein Ticket enthält im Wesentlichen die Kundendaten, eine Problembeschreibung sowie die bisher durchgeführten Massnahmen zur Problembehebung. Ruft ein Kunde im Callcenter an, so öffnet sich bei M. am Bildschirm das Ticketsystem, in das er die Daten und die Problembeschreibung des Kunden einträgt. Während des Gespräches mit dem Kunden hat M. die Möglichkeit, diverse Messungen auf der Leitung des Kunden durchzuführen. Dazu benutzt er eine zweite Anwendung, in die er die Daten des Kunden manuell übertragen muss. Außerdem kann M. innerhalb des Ticketsystems alte Tickets des Kunden einsehen. Wenn ein Gerät des Kunden defekt ist, kann M. einen Gerätetausch veranlassen. Dazu verwendet er ein drittes System, in das er ebenfalls die Kunden- und Gerätedaten übertragen muss. M. wurde während des Telefoninterviews gefragt, an welchen Stellen er mit der momentanen IT-Unterstützung nicht zufrieden ist. Die Kritikpunkte von M. betrafen zum einen die manuelle Übertragung von Daten zwischen den drei Systemen und zum anderen die Dialogführung im Ticketsystem. 94

100 8. Ein Anwendungsbeispiel Beschreibung des SOA-Projekts Auf Basis der realen Ausgangssituation wurde das folgende, fiktive Projekt entworfen: Im Rahmen eines SOA-Projekts soll für das Callcenter eine neue Anwendung entwickelt werden, die alle drei zurzeit verwendeten Systeme zusammenfasst. Das neue System interagiert mit verschiedenen Webservices, die zur internen Verwaltung und Verarbeitung von Kundenund Ticketdaten verwendet werden. Auch der Austausch von Geräten und die Durchführung von Leitungsmessungen sollen durch Webservices unterstützt werden. Mit Hilfe eines WS-Prototyps sollen die Anforderungen an die neu zu entwickelnde Anwendung erhoben werden. Dabei sollen die benötigten Schnittstellen der Webservices identifiziert und Anforderungen an die Benutzeroberfläche erhoben werden. Des Weiteren sollen die Unklarheiten beseitigt werden, die nach der Auswertung des Telefongesprächs mit M. entstanden sind Durchgeführte Tätigkeiten für das Prototyping Tabelle 8.1 gibt einen Überblick über die Tätigkeiten, die zur Entwicklung und Auswertung eines WS-Prototyps durchgeführt wurden. Für die Annotation der WSDL-Dateien wurde der AnnotationGenerator eingesetzt. Die Entwicklung und die Auswertung des Prototyps wurde mit dem WSPrototypEditor unterstützt. Tätigkeit Telefoninterview mit C. Identifizieren von Webservices und erstellen der Schnittstellenbeschreibungen für diese Services (4 Services wurden identifiziert) Erstellen von Oberflächenskizzen auf Papier Erstellen von WSMessageWorkflows und Annotation der erstellten WSDL- Dateien mit dem AnnotationGenerator Definition einer WSMessageWorkflow-Komposition Entwicklung eines Portal-Templates anhand der Oberflächenskizzen Erstellen eines rudimentären WSPrototyps mit dem WSPrototypEditor (dieser enthält zunächst nur die generierten HTML-Fragmente) Anpassen der generierten HTML-Fragmente Interviewvorbereitung Interviewdurchführung Interviewauswertung (nur Nachbearbeitung der Kommentare) Gesamtzeit Dauer 00:30 h 06:00 h 00:45 h 00:45 h 00:30 h 00:20 h 00:20 h 03:00 h 00:45 h 00:35 h 00:15 h 13:45 h Tabelle 8.1.: Durchgeführte Arbeitsschritte zum Prototyping mit Webservices für ein fiktives SOA-Projekt 95

101 8. Ein Anwendungsbeispiel Der entwickelte Prototyp umfasst insgesamt acht Oberflächen, von denen allerdings nur drei relativ viele HTML-Elementen enthalten. Die anderen stellen einfache Eingabemasken mit zwei oder drei Eingabeelementen dar oder sie präsentieren Bestätigungsmeldungen eines Webservices. Abbildung 8.1 zeigt einen Screenshot der Oberfläche für die Ticketbearbeitung, die zu den drei komplexen Oberflächen gehört. Abbildung 8.1.: Screenshot einer Oberflächenmaske für das Anwendungsbeispiel, dargestellt im WSPrototypEditor Mit mehr als einem Arbeitstag erscheint der Aufwand für die Prototypentwicklung auf den ersten Blick recht hoch. Während der Vorbereitung und Entwicklung entstanden jedoch einige Elemente, die auch ohne das Prototyping in einem SOA-Projekt hätten erstellt werden müssen. Nach dem Telefoninterview mit M. wurden zunächst die benötigten Webservices für die neu zu entwickelnde Anwendung identifiziert. Diese Tätigkeit hat mit ca. sechs Stunden viel Zeit in Anspruch genommen, obwohl die Services nur grob spezifiziert wurden. Aufwändig war vor allem das Ermitteln von einzelnen Methoden, Parametern und Rückgabewerten der Services. Wenn vorhandene Webservices verwendet werden können, entfällt dieser Aufwand. Dafür muss dann Zeit investiert werden, um die WSDL-Beschreibungen der vorhandenen Services zu verstehen. Schnittstellenbeschreibungen für Webservices, die im Rahmen des Prototyping-Prozesses erstellt werden, lassen sich jedoch beispielsweise in der Entwurfsphase eines SOA-Projekts weiterverwenden. Der benötigte Aufwand kann daher nicht allein dem Prototyping zugeordnet werden. Neben der Definition der WSDL-Beschreibungen hat das Anpassen der generierten HTML- 96