Bachelorarbeit für die Prüfung zum Bachelor of Science

Größe: px
Ab Seite anzeigen:

Download "Bachelorarbeit für die Prüfung zum Bachelor of Science"

Transkript

1 Johannes Gutenberg-Universität Mainz Institut für Physik, Mathematik und Informatik Studiengang Bachelor Informatik Bachelorarbeit für die Prüfung zum Bachelor of Science Konzeption und Realisierung von hoch-interaktiven Rich Interactive Applications (RIAs) mit Microsoft Silverlight (am Beispiel einer Projektmanagementsanwendung mit IBM ILOG Gantt) Bachelorand: Andreas Congiu Matrikelnummer: Fachbereich: 08 Informatik Betreuer (Universität): Herr Dr. Thomas Hillebrand Betreuer (IPSWAYS) Herr Dipl.-Phys. Marc Lucas Abgabedatum: 26. August 2010

2 Eidesstattliche Erklärung Hiermit erkläre ich eidesstattlich, dass ich die vorliegende Bachelorarbeit Konzeption und Realisierung von hoch-interaktiven Rich Interactive Applications (RIAs) mit Microsoft Silverlight selbständig und ohne fremde Hilfe angefertigt habe. Ich habe dabei nur die in der Arbeit angegebenen Quellen und Hilfsmittel benutzt. Die Arbeit wurde in gleicher oder ähnlicher Form noch keiner anderen Prüfung vorgelegt und auch noch nicht veröentlicht. Ort, Datum Unterschrift

3 Inhaltsverzeichnis I Theoretische, konzeptionelle und technische Grundlagen 1 1 Einleitung Motivation und Aufgabenstellung Aufbau des Dokuments Abgrenzung Grundlagen und Einführung in die Basistechnologien Rich Internet Applications Was sind RIAs? Denitionsversuch und Merkmale RIA-Frameworks Kritik Web Services und Service-orientierte Architekturen Verzeichnisdienste WSDL SOAP REST WCF RIA Services Zusammenfassung Microsoft Silverlight Das Silverlight Plugin Architektur, Browserintegration und Deployment Entwicklungsumgebungen und SDKs Visuelle Schicht: XAML Controls XAML-Grundlagen Layout Ressourcen, Styles und Templates Silverlight Animationen Logische Schicht: Code-Behind-Dateien Dependency Properties I

4 INHALTSVERZEICHNIS Eventhandling und Routed Events Commands Data Binding Binding in XAML Binding in der Anwendungslogik Datenvalidierung Kommunikation mit dem Server Weitere Features Sicherheit Marktverbreitung Zusammenfassung II Konzeption und Realisierung der Beispielanwendung 62 4 Zum Grundverständnis der Anwendungsdomäne 63 5 Funktionale und Nichtfunktionale Anforderungen 66 6 Entwurf IBM ILOG Gantt for.net Gesamtarchitektur: Das Model-View-ViewModel-Entwurfsmuster Komponenten der Anwendung Entwurf zur Realisierung der Funktionalitäten Datenmodell und Datenhaltung Implementierung Umsetzung des Model-View-ViewModel-Musters Model ViewModel View Serveranbindung und Datenspeicherung Kommunikation mit dem Server Datenspeicherung Erläuterungen zu sonstigen Klassen UserControls der Anwendung Die Hauptanwendung App.xaml Deployment Evaluation Umsetzung der Anforderungen II

5 INHALTSVERZEICHNIS 8.2 Zusammenfassung und Fazit III Anhang 129 A Zusätzliche Abbildungen und Listings i A.1 WSDL-Datei des verwendeten Web Service i A.2 Klassendiagramm GanttWebServiceSoapClient vi A.3 Funktion zum Auslesen einer Gantt-Projekt-Datei vi A.4 Klassendiagramm der Praxisanwendung xi B Verzeichnisse Literaturverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Listingverzeichnis C Abkürzungen und Begrie D CD-Inhalt E Quellcode Übersicht F CD xii xvi xvi xix xx xxiv xxvi xxvii xxix III

6 Teil I Theoretische, konzeptionelle und technische Grundlagen 1

7 Kapitel 1 Einleitung 1.1 Motivation und Aufgabenstellung Die Inhalte des Internets und die Form ihrer Präsentation auf Websites haben sich in den letzten Jahren grundlegend verändert. Das sogenannte Web 2.0 ermöglicht den Besuchern eine Form von Interaktion durch und mit dynamischen Internetseiten, welche in Aussehen und Inhalt von den Nutzern selbst mit einem kollaborativen Verständnis geprägt werden können. Geschah dies in den Anfangsstadien des Mitmachweb hauptsächlich durch (zum Groÿteil serverabhängige) Techniken wie PHP und ASP.NET in Kombination mit JavaScript und Ajax, gewinnen heute rein Client-basierte Internetanwendungen zunehmend an Bedeutung. Insbesondere die Rich Internet (oder Interactive) Applications (kurz RIAs) erlauben es, komplexere und stark interaktive Programme auf Internetseiten zu platzieren und damit den Anwendern reichhaltigere Möglichkeiten anzubieten. RIAs und insbesondere deren zu Grunde liegende Frameworks sind technisch und konzeptionell an einem Punkt angelangt, der sie (nicht nur für Unternehmen) in vielen Bereichen interessant macht. Dabei haben diese Anwendungen heute nicht nur einen unterhaltenden (Flash-Games), kommerziellen (interaktive Werbebanner) oder visualisierenden (Streaming-Videos, Präsentation von Multimedia) Gedanken. Sie haben das Potential eine eigene Art von Programmen hervorzurufen und der Webnutzung einen neue Richtung zu geben, indem die Ausführungsumgebung einer Anwendung nicht mehr ein spezischer Rechner des Endanwenders, sondern das Web an sich ist. Die Entwicklung und insbesondere der Markt der Rich Internet Applications sind zwar nicht in allen Bereichen vollständig ausgereift, jedoch existieren dort solide Grundlagen. Die technischen Möglichkeiten, welche die einzelnen Frameworks bieten, stehen denen von klassischen Desktopanwendungen nur in wenigen Punkten nach. Schnell hintereinander auftretende Versionsveröentlichungen der RIA-Plugins und Software-Development-Kits belegen, dass sie für 2

8 1.2 Aufbau des Dokuments die groÿen Frameworkanbieter (wie Adobe, Sun, Microsoft) eine hohe Priorität am Markt haben. Mit stetig zunehmender Akzeptanz und Verbreitung der einzelnen Plugins setzt sich eine Technik durch, die selbst für anspruchsvolle, in betrieblichem Umfeld eingesetzte Programme (sog. line-of-business-anwendungen), exible und dennoch mächtige Lösungen mitbringt. Dabei können RIAs sowohl leichtgewichtigere, webbasierte Anwendungen ergänzen oder gar komplett ersetzen, als auch Desktop-Applikationen im täglichen Umgang ablösen. Diese Arbeit soll beschreiben, auf welche Weise sich hoch interaktive Rich Internet Applications mit Microsoft Silverlight konzipieren und realisieren lassen. Dazu werden zunächst die grundlegenden Techniken zur Implementierung einer Silverlight-Anwendung erläutert. Anschlieÿend wird dargestellt, was RIAs (speziell Microsoft Silverlight) zu leisten vermögen bzw. wo ihre Schwächen liegen. Nach der Herausarbeitung der wichtigsten Geschäftsprozesse einer Projektmanagementanwendung, setzt ein praxisnahes Beispielprogramm die diskutierten Techniken, Anforderungen und Modelle exemplarisch um. Im Zuge des Entwurfs muss ein Konzept entwickelt werden, welches die Komponenten der Anwendung und ihre Gesamtarchitektur berücksichtigt. Dazu ist es u.a. nötig, weitere Funktionalität in Form von Web Services bereitzustellen. Eine Beschreibung der Implementierung auf Serverseite wird hier bewusst ausgelassen. Der Fokus dieser Arbeit liegt auf der clientseitigen Realisierung der Benutzeroberäche, deren Geschäftslogik, sowie er Kommunikation mit dem Server unter Verwendung von Web Services. Zur weiteren Unterstützung kommt das IBM Framework ILOG Gantt for.net (Kapitel 6.1) zum Einsatz, welches einige vorgefertigte, hoch-interaktive Silverlight-Controls zur Planung und Bearbeitung von Gantt-Diagrammen (S. 63) bereitstellt. Das Framework wird im Rahmen der Arbeit technisch und funktional kurz erläutert. 1.2 Aufbau des Dokuments Die Arbeit gliedert sich in zwei Bereiche. Im ersten, theoretischen, konzeptionellen und technischen Teil, werden die Grundlagen, Modelle, Konzepte und der Mehrwert von Rich Internet Applications insbesondere von Microsoft Silverlight 4 erläutert. Es wird allgemein auf die Basistechnologien und Grundlagen eingegangen. Neben technischen Merkmalen von Silverlight (z.b. Architektur des Frameworks, funktionelle und logische Schichten, Abgrenzung zur Windows Presentation Foundation) stehen die Kommunikation mit dem Server (über Web Services), Sicherheitsaspekte und die Oberächen-Entwicklung mit Silverlight im Vordergrund. Unter Nutzung der Library IBM ILOG Gantt for.net wird im Praxisteil ein Editor für 3

9 1.3 Abgrenzung Projektablaufsdiagramme (Gantt-Diagramme) innerhalb der.net Umgebung implementiert. Des Weiteren werden die Verwendung des Model-View-ViewModel-Entwurfsmusters mit Silverlight und die Konzepte einer Service-orientierten Architektur (SOA) zur Realisierung von line-of-business Aplications mit erhöhten Anforderungen beschrieben. Der zweite Teil behandelt das oben genannte Praxisbeispiel einer hoch-interaktiven RIA zum Projektmanagement mit Gantt-Diagrammen, deren allgemeinen bzw. speziellen Anforderungen und Besonderheiten, sowie Architekturentwurf und Realisierung mit Silverlight in Kombination mit IBM ILOG Gantt. Die im ersten Teil erarbeiteten Konzepte sollen hier exemplarisch eine praxisnahe Anwendung nden. Als Programmiersprache wird C# verwendet. Zusätzlich kommt.net und Silverlight Version 4.0 zum Einsatz. IBM ILOG Gantt for.net liegt hier ebenfalls in Version 4.0 vor. 1.3 Abgrenzung Für das Verständnis der Implementierung und der hier gezeigten Codefragmente werden Grundkenntnisse in C# und.net vorausgesetzt. Wissen über Markup-Sprachen wie XML ist ebenfalls von Vorteil. Realisierung und Bereitstellung der genutzten Web Services sollen aufgrund der umfangreichen Thematik nicht detailliert erläutert werden. 4

10 Kapitel 2 Grundlagen und Einführung in die Basistechnologien 2.1 Rich Internet Applications Das Internet diente ursprünglich zum globalen Transport von Dokumenten und Informationen über ein Netzwerk verschiedenster Rechner. Das Abrufen oder Bereitstellen von Daten (hauptsächlich einfacher Textdokumente) galt lange Zeit als Hauptfunktion des World Wide Web. Seit etwa Mitte der 1990er wurden weitere Möglichkeiten zur simplen Datenveränderung über das Internet populär. Reine HTML-basierte Internetseiten waren weit verbreitet, jedoch wurden bald speziellere Anforderungen benötigt. Internetseiten, generiert aus vielen dynamischen Komponenten in Zusammenarbeit zahlreicher Technologien (z.b. JavaScript, PHP, CSS, Datenbanken, Web Services), bereichern die Landschaft der Internetanwendungen in heutiger Zeit erheblich. HTML ist jedoch noch immer das endgültige Darstellungsformat der Internetseite beim Benutzer. Für die Interpretierung des HTML-Dokumentes ist dabei stets der Browser verantwortlich. HTML leidet an beschränkten Möglichkeiten hinsichtlich Vielfalt der Seiten. Die fehlende Multimediaintegration, gestiegene Anforderungen und eine relativ geringe Komplexität und Ranesse der Webanwendungen im Vergleich zu normalen Desktop-Applikationen beförderten neue Technologien. Heute sind vereinzelte Java- oder Flash-basierte Teilkomponenten, die HTML nicht als Beschreibungssprache nutzen, sondern nur als Plattform, nicht mehr aus dem Internet wegzudenken und erönen eine neue Dimension für Webanwendungen. Einerseits bestehen gehobene Ansprüche des Nutzers hinsichtlich seines Wunsches nach Informationen, Unterhaltung und Interaktion mit der Internetseite, andererseits lassen sich 5

11 2.1 Rich Internet Applications gegenwärtig auch bei Unternehmen umfassendere Anforderungen an repräsentative Internetangebote (wie auch an Softwareprodukte allgemein) ausmachen. Diese Trends führten zur Entwicklung von sog. rich clients. Ein erster Schritt in diese Richtung waren Skriptsprachen wie JavaScript. In heutiger Zeit reicht deren Funktionalität aber häug nicht aus. Umfangreiche und komplexere Anwendungen sind damit nur bedingt realisierbar. Problematisch ist auch die relativ geringe Leistungsfähigkeit des Browser als Laufzeitumgebung dieser Skripte. Bei Entwicklern von Internetseiten kam der Wunsch auf, die Vorteile der klassischen Desktopanwendung mit denen des Internets zu vereinen. Tabelle 2.1 gibt dazu eine allgemeine Übersicht der wichtigsten Merkmale beider Paradigmen. klassische HTML-Internetseite Oberäche und Funktionalität sind relativ einfach. Keine maximale Ausnutzung der Arbeitsäche (d.h. kein Vollbild). Statuslos, d.h. für Server muss bei jeder Anfrage die Identität des Aufrufers neu geklärt werden. Statuserhaltung ist Aufgabe der Webseitenentwickler. Nach Benutzerinteraktion in der Regel vollständiger Seitenneuaufbau. Kurzzeitiges Verschwinden der Seite. Nutzung nur online. Internetseite kann nicht erreichbar sein Weitgehend standardisierte, einheitliche und etablierte Techniken (z.b. (X)HTML, CSS, PHP, JavaScript, XML). Plattformunabhängig und ressourcenschonend auf Clientseite. Server und Datenbank kontrollieren Daten. Eingeschränkte Möglichkeiten bei visueller Gestaltung, Benutzerinteraktionen, Hardwarekomponentennutzung des Clients. Keine direkte Kommunikation der Webanwendung zu anderen Internetseiten: serverto-server über Netwerkprotokolle. klassische Desktopanwendung Oberäche beliebig dynamisch gestaltbar und der jeweiligen Programmsituation angepasst (auch Vollbildmodus). Sehr viele Möglichkeiten. Statusbewusst. Lokale Instanz der Anwendung hat genaue Informationen zum aktuellen Zustand. Partielle Veränderung von Teilen der Ober- äche ohne Unterbrechung und/oder Serveranfrage. Allgemein auch ohne Internetverbindung ausführbar. Sehr vielfältige (häug auch standardisierte) Techniken, Vorgehensweisen und Methoden. Systemabhängig und ggf. gehobene Ansprüche an Ressourcen (z.b. besondere Hardwareanforderungen) auf Nutzerseite. Lokaler Speicher für Daten unter Kontrolle des Betriebssystems. Geregelter Zugang und Zugri zu nahezu allen Bereichen des Systems. Kommunikation mit anderen Prozessen, Anwendungen, Systemen über viele Kanäle möglich. 6

12 2.1 Rich Internet Applications klassische HTML-Internetseite Gröÿere potentielle Erreichbarkeit von Kunden. Einfache Distribution der Software über Seitenbesuch. klassische Desktopanwendung Eingeschränkter Kundenkreis, abhängig von System und Software. Vertriebsmöglichkeit durch Programminstallation aus einer Datei, von CD/DVD oder anderen portablen Quellen. Tab. 2.1: Vergleich von Web- und Desktopanwendungen Rich Internet Applications (RIAs) versuchen diese Lücke zu schlieÿen, indem eine Schnittmenge der zwei Anwendungsparadigmen gebildet wird. So sollen die Vorzüge beider Ansätze vereint und jeweilige Nachteile ausgegrenzt werden. Abb. 2.1: Einordnung der RIA-Technologie Obwohl die ersten Ansätze des heutigen RIA-Gedankens schon ab 1996 bestanden 1, dauerte es noch einige Jahre, bis die ersten Frameworks marktreif und für die Entwicklung von anspruchsvollen Anwendungen interessant waren. Schon 1996 versuchte Microsoft mit den ActiveX-Controls, Komponenten applikationsunabhängig zu machen, um diese beispielsweise im Internet Explorer zu nutzen. Die ActiveX- Technologie scheiterte jedoch an Systemabhängigkeiten und Sicherheitsrisiken (Janowicz, 2006). Andererseits erfreute sich Macromedia 2 Flash als reiner Videoplayer ohne groÿe Interaktionsmöglichkeiten (Version 1 im Jahre 1997) wachsender Beliebtheit. Die Wiedergabe von bewegten Flash-Inhalten steigerte die Fähigkeit Multimedia-Inhalte auf Internetseiten darzustellen. Mit Version 4 des Flash-Players 1999 (Adobe, 2010) wurden Schleifen und bedingte Anweisungen ermöglicht, welche grundlegende, minimal-interaktive Flash-Anwendungen zulieÿen. Ein 2002 von Jeremy Allaire 3 veröentlichtes Whitepaper (Allaire, 2002) beschreibt erstmals Anforderungen an Webapplikationen, die mit bisherigen Techniken nicht realisierbar waren 1 Damals noch mit anderen Namen und Zielen, z.b. Microsofts ActiveX (1996), Microsoft Remote Scripting (1998) oder Forester Research: X Internet (2000) 2 Später Adobe 3 Chief Technology Ocer bei Adobe 7

13 2.1 Rich Internet Applications und die zur Veröentlichung von Adobe Flash MX (Version 6) führten damals noch als next-generation rich Client bezeichnet. Der folgende Auszug daraus beschreibt die Grundgedanken des neuen Ansatzes, der bereits viele Aspekte der heute verfügbaren RIAs berücksichtigt. Rich Client technologies should: 1. Provide an efficient, high-performance runtime for executing code, content and communications. (...) 2. Integrate content, communications, and application interfaces into a common environment. (...) 3. Provide powerful and extensible object models and interactivity. (...) 4. Enable rapid application development through components and re-use. (...) 5. Enable the use of web and data services provided by application servers. (...) 6. Embrace connected and disconnected clients. (...) 7. Enable easy deployment on multiple platforms and devices. (...) Flash MX 6 kann somit als erstes, ernstzunehmendes Framework zur Entwicklung von Rich Internet Applications betrachtet werden, da mit dem Flash-Plugin im Browser nun einfache, interaktive, jedoch von Skriptsprachen unabhängige Programme auf Internetseiten clientseitig ausgeführt werden konnten Was sind RIAs? Denitionsversuch und Merkmale Eine allgemeingültige Denition einer Rich Internet Application ist schwierig zu nden, da ein breites Spektrum der Nutzung möglich ist. 4 Genauso wie für klassische Desktopanwendungen, gilt auch für eine RIA, dass sie vom Benutzer angewendet wird, um eine gewisse Funktion zu erreichen. Schon die wörtliche Übersetzung besagt, dass es sich um eine reichhaltige Internet- Anwendung handelt, welche über die Möglichkeiten einer klassischen Internetseite (basierend z.b. auf Skriptsprachen und statischen Inhalten) weit hinausgeht. Die Identizierung einer RIA kann anhand verschiedener Merkmale erfolgen, die jedoch auch zum Teil für klassische Desktopapplikationen und Webanwendungen typisch sind: Ein Ablauf im Browser macht die Anwendung theoretisch relativ plattformunabhängig. Voraussetzung ist die Verfügbarkeit des RIA-Plugins für das System bzw. den Browser und eine Internetverbindung. 4 Selbst die Bezeichnung ist nicht unumstritten: Scott Barnes (Microsoft) spricht lieber von Rich Internet Applications, während Ryan Stewart (Adobe) Rich Interactive Application vorzieht (vgl. o.a., 2007). Beide Begrie bezeichnen aber das Selbe, wobei die Variante Rich Internet Application häuger verwendet wird. 8

14 2.1 Rich Internet Applications Es ist ein Browser-Plugin zur Ausführung nötig, aber es ndet keine Installation der spezischen RIA-Anwendung selbst auf dem Clientrechner statt. Es erfolgt kein Seitenneuaufbau nach einer Aktion (d.h. lokale Statuserhaltung) und wenige kommunikations-bedingte Verzögerungen treten auf. Der Server hat nur eine unterstützende Rolle als Datenlieferant. Die Rechenlast liegt beim Client. Für Nutzer ist die Serverkommunikation unsichtbar (auch ohne aktiven Benutzerbefehl). So werden Serveranfragen durch häuge Seitenaufrufe stark reduziert. RIAs nutzen Kontrollelemente und Funktionen die aus Desktopapplikationen bekannt sind z.b. Buttons, Listen. Menüs. Umfassende und gewohnte Bedienmöglichkeiten (Drag and Drop, Tastaturbedienung) stehen dort zur Verfügung. Häug werden RIAs nach dem SOA-Ansatz (siehe Kapitel 2.2) entwickelt und es entstehen damit modular gekapselte Serviceschichten. Entwickler können vorgefertigte Framework-Komponenten nutzen oder aus diesen neue kreieren und somit funktional und graphisch anspruchsvolle Ideen umsetzen. Richer user experience, d.h. in der Regel native Unterstützung für Multimediawiedergabe und interaktive Verwendung der RIA. Eine Indexierung durch Suchmaschinen (z.b. für dynamische Inhalte) ist nur eingeschränkt möglich. Dies kann natürlich auch positiv bewertet werden, falls nicht öentliche Daten enthalten sind. Identisches look and feel auf allen Systemen, da die Laufzeitumgebung unverändert bleibt. Deploymentkosten und -aufwand sind durch zentrale Bereitstellung der Anwendung auf einem Server reduziert. Neue Versionen stehen dem Nutzer bei Programmstart automatisch zur Verfügung und manuelle Updates sind weitgehend unnötig. Nur das Plugin selbst muss ggf. von Hand aktualisiert werden. Eingeschränkte Hardwarenutzung einer RIA auf dem ausführenden Rechner. Eingeschränkte Rechte der Anwendungen bzw. Ablauf in einer abgeschlossenen Umgebung (Sandbox). (Vgl. Pfeil, 2009, S. 2) Hinzuzufügen ist auch, dass RIAs relativ virenresistent, jedoch gegen bösartige Nutzung anfällig sind. Da die Anwendung isoliert von anderen Nutzern ausgeführt wird, ist das Potential 9

15 2.1 Rich Internet Applications Abb. 2.2: Allgemeine Übersicht der Integration einer RIA für einen Angri auf den Client selbst niedriger. Bei solider Implementierung hat der Benutzer nur eine graphische Oberäche und deren Funktionalität ohne kritischen Code. Daten und die Sicherheitsrelevanten Programmanteile liegen auf Serverseite, welche in der Regel durch umfassende Maÿnahmen geschützt sind. Weitere Aspekte zur Sicherheit (speziell von Silverlight) werden in Kapitel 3.9 behandelt. Eine technische Beschreibung der Gesamtarchitektur von Rich Internet Applications (speziell Silverlight) wird in Kapitel 3 gegeben. Abbildung 2.2 gibt eine simple Übersicht, wie eine RIA veröentlicht ist. Die Anwendung selbst ist in einer Internetseite gekapselt und wird vom Plugin im Browser ausgeführt. Über Netzwerkprotokolle steht die RIA mit einem Server in Verbindung. Das Grundkonzept der hier beschriebenen Ebenen und Komponenten ist recht allgemein und unterscheidet sich für die verschiedenen RIA-Frameworks meist nur geringfügig RIA-Frameworks Neben Silverlight, dem hier ein eigenes Kapitel gewidmet ist, sind folgende alernative Plattformen und Frameworks zu nennen: Adobe Flash/Air/Flex ist die bisher am weitesten verbreitete Technik, da es das älteste aller Frameworks ist. Entwicklungssprache ist das objektorientierte ActionScript. Die Ausführung der Programme erfolgt mit dem Adobe Flash Player. Nutzbar ist Flash mittlerweile mit den meisten Systemen (abgesehen von einigen mobilen Geräten). Mehrheitlich wird es für Präsentation mit geringer Interaktion (z.b. reine Ersetzung von Websites ohne zusätzliche Funktionalität, dafür mit erweitertem optischen Eindruck), Werbung und Spiele benutzt. Echte RIAs im Sinne eines Ersatzes von Desktopanwendungen sind relativ selten, da die Vorteile von Flash in der Darstellung von bewegten Animationen und allgemein Multimedia liegt. OpenLaszlo ging aus diesem Framework hervor und nutzt die gleichen Prinzipien, legt 10

16 2.1 Rich Internet Applications aber Wert auf ein quelloenes Software Developement Kit. JavaFX ist oziell seit Ende 2008 für Entwickler und Nutzer verfügbar. Es baut auf die Java Technologie und deren Laufzeitumgebung auf und ist in der aktuellen Version 1.2 verfügbar für Windows ab XP und Mac OS X (Version 10.5, nur Intel-Prozessoren). OpenSolaris und Linux-Versionen benden sich im Beta-Status. Unterstützte Browser sind der Microsoft Internet Explorer ab Version 6.0, Mozilla Firefox und Safari von Apple (jeweils ab Version 3). Entwickelt werden die Anwendungen mit der deklarativen Sprache JavaFX Script und Java. Kompiliert wird zunächst in bytecode, welcher dann beim Client mit der JRE ausgeführt wird (bzw. als Java Web Start oder Java Applet). Vorteil dieses Frameworks ist die relativ weit verbreitete Java-Umgebung. Skriptbasierte Frameworks, die intensiv z.b. Ajax und JavaScript nutzen, ermöglichen auch die Realisierung von RIAs. Beispiele hierfür sind das Google Web Toolkit, ZK, Google Gears und Curl. Der Vorteil dieser Varianten besteht darin, dass keine zusätzliche Software nötig ist (auÿer natürlich JavaScript unterstützende Browser). Nachteilig ist die geringe Performanz und der hohe Entwicklungsaufwand bei komplexeren Anwendungen. HTML5 ist zwar noch kein ozieller Standard, ermöglicht aber eine umfangreichere Multimediaeinbindung in Internetseiten als beim Vorgänger. Jedoch ist eine komplexe Interaktion allein auf HTML5 beruhend nicht möglich. Der Fokus dieser Entwicklung liegt auf der Erweiterung der Multimediafähigkeiten von Internetseiten. Der Browser fungiert hier als Ausführungsumgebung und interpretiert den Code. Auch hier wird auÿer einem unterstützenden Browser keine zusätzliche Software vorausgesetzt Kritik Das Konzept der Rich Internet Applications hat zwar praktische und technische Vorteile, jedoch fallen auch negative Faktoren auf, die den Einsatz einschränken oder bei speziellen Anforderungen diesen auch fragwürdig erscheinen lassen. Nachteilige Punkte sind z.b. Zur Nutzung ist ein Plugin nötig. Dies erfordert einen (wenngleich geringen) Installationsaufwand beim Benutzer und erzwingt eine Bindung an das Produkt. Vergleicht man die Installation aber mit der einer klassischen Desktopanwendungen ist der Umfang zur Nutzung der Software recht gering. Für mobile Endgeräte kann das Plugin eine Hürde darstellen, da Hersteller dort häug ein eigenes Betriebssystem verwenden, für das sie einen Kundensupport berücksichtigen müssen, der Software von Fremdherstellern mit einschlieÿen muss. Zusätzlich sind durch das Plugin neue Sicherheitslücken möglich. 11

17 2.2 Web Services und Service-orientierte Architekturen Es lassen sich keine neuen Anwendungsfenster auÿerhalb der RIA anzeigen. Alles spielt sich innerhalb des Browsers ab. Die Laufzeitumgebung der RIAs führt ihre Anwendungen in der Regel in einem begrenztem Umfeld (Sandbox, siehe Kapitel 3.9) aus, welche den Zugri auf Systemressourcen (z.b. Hardware- oder Programmzugrie) stark einschränkt. Zum Start einer RIA muss JavaScript im Browser aktiviert sein. Die Ressourcenbelastung liegt beim Client und nur zu kleinem Teil auf dem Server. Oftmals sind im Vergleich zu klassischen Internetseiten erhöhte Anforderungen des Plugins an die Rechnerleistung zu stellen. Nicht alle Anwender können diese Voraussetzungen erfüllen. Die Ladezeit der umgebenden Internetseite ist vergröÿert, denn selbst simple Rich Internet Applications sind relativ groÿe Dateien, die schnell einige hundert Kilobyte erreichen. Eine Breitbandverbindung zum Internet ist daher sinnvoll. Die Indizierung von RIA-Inhalten durch Suchmaschinen ist bisher nicht vollständig möglich, da die Anwendungen und ihre Inhalte von auÿen nicht zugreifbar sind. Lediglich die umliegende Internetseite ist zugänglich. Für Silverlight existieren Möglichkeiten diese Problematik zu korrigieren (siehe Shetty, 2009). Auf Entwicklerseite von RIAs ist ein herstellerspezischer initialer Lernaufwand der neuen Techniken nötig. Auch aktuelle Neuentwicklungen der Plugins, die sehr schnell vorangetrieben werden, müssen im Auge behalten werden (vgl. den raschen Veröentlichungs- Rhythmus von Silverlight-Versionen in Abbildung 3.13). Die erstrebenswerte Standardisierung von Rich Internet Applications (z.b. durch das W3C) ist nicht einfach, da viele Hersteller und Interessengruppen daran teilhaben. Dem Benutzer ist häug nicht klar, dass es sich bei einer RIA um eine im Browser eingebettete Anwendung handelt, die gewisse Restriktionen oder eine veränderte Bedienung mit sich bringt. Standardfunktionen wie das Anfertigen eines Ausdruckes oder das setzen von Lesezeichen können hier zu Irritationen führen und eine gewissen Eingewöhnung erfordern. Bei der Entwicklung einer RIA sollte daher auf solche Aspekte geachtet werden. 2.2 Web Services und Service-orientierte Architekturen Eine Service-orientierte Architektur (oder service-oriented architecture, kurz SOA) ist eine dynamische Menge von abstrakten Designprinzipien einer verteilten Softwarearchitektur. Sie ist 12

18 2.2 Web Services und Service-orientierte Architekturen nicht an bestimmte Technologien gebunden, sondern relativ plattform- und programmiersprachenunabhängig. Wichtigstes Merkmal ist das Service-orientierte Paradigma: es gibt Dienste (Services) die spezische Funktionen kapseln und implementieren. Dabei gilt: Alle Funktionen in einem realen System (...) lassen sich als Services darstellen und aus Services aufbauen. (Masak, 2007, S. 17) Oder kürzer: Alles was aus- oder durchgeführt werden kann ist ein Service. (Masak, 2007, S. 17) Hierbei hat jeder Dienst mindestens einen Provider, der als Lieferant den Kunden oder Nutzern den Service anbietet. Auÿerdem gilt: die Funktionalität und die Randbedingungen eines jeden Services sind vorab deniert. Die Dienste müssen also hinsichtlich aller Nutzungsaspekte hinreichend gut beschrieben sein, damit sie sinnvoll verwendet werden können (funktionale Beschreibung). Daneben existiert auch eine nichtfunktionale Beschreibung, die für die Suche und Entdeckung essentiell sein können (z.b. Providername, Servicezeiten, Verfügbarkeit, Nutzungseinschränkungen etc.) Für beide Beschreibungen stellen Web Services eine standardisierte Schnittstelle bereit (siehe WSDL, Kapitel 2.2.2) um eine Kommunikation und Interaktion nach auÿen hin mit bestehenden Systemen zu ermöglichen. Eine SOA-Anwendung ist modular aus einzelnen, lose gekoppelten Diensten zusammengesetzt (orchestriert). Dies gewährleistet es im Optimalfall, exibel auf mögliche Änderungen des Marktes bzw. der Programmanforderungen zu reagieren, indem bestehende Dienste anderer Anwendungen wiederverwendet oder ausgetauscht werden können. Daraus resultiert eine leichte Wartung und damit verbunden eine Entwicklungs- und Kostenersparnis. Dies sind wichtige Merkmale der SOA. Die verteilte Architektur ermöglicht es, ein weites Spektrum an Plattformen und Systemen miteinander zu verbinden, ohne dabei groÿe Anpassungen an Altsystemen vorzunehmen. Für webbasierte Anwendungen kann dies ein erheblicher Vorteil sein. In diesem Bereich gehören Web Services zum Fundament datengetriebender Dienste und Anwendungen. (Vgl. Papazoglou, 2007, S. 253) Ein Web Service ist ein über ein Netzwerk bereitgestelltes, selbstbeschreibendes Softwaremodul, welches auf Anweisung anderer Applikationen hin Aufgaben erledigt, Probleme löst oder Transaktionen ausführt. Da ein solcher Dienst auf automatisierte Anfragen ausgerichtet ist, wird er fast ausschlieÿlich als Kommunikationspartner von Maschinen verwendet. Der Aufruf geht zwar von einer Interaktion des Nutzers aus, jedoch wird die Anfrage stets vom System getätigt beispielsweise in einer optimierten und standardisierten Form. 13

19 2.2 Web Services und Service-orientierte Architekturen Dabei bauen Web Services auf den XML-Standard auf und verwenden weitere Technologien wie SOAP, WSDL und UDDI, die in den folgenden Kapiteln behandelt werden. Die Dienste sind aufgrund ihres Ursprungs im Bereich der Webanwendung zustandslos und erfüllen letztendlich stets den Zweck eines Datenaustauschs. Dadurch kann leicht eine lose Kopplung (siehe S. 78) erreicht werden, was eine Wiederverwendbarkeit des Dienstes ermöglicht. Ein Service kann zudem synchron oder asynchron implementiert werden und unterstützt i.d.r. auch Fehlermeldungen. Als de facto-standard sind die Kommunikationsprotokolle HTTP(S), SMTP und FTP am weitesten verbreitet, da diese Protokolle von nahezu allen Systemen unterstützt werden und das Koniktpotential mit einer Firewall sehr niedrig ist. Es ist aber zu beachten, dass die Leistungsfähigkeit dieser Übertragungsart geringer ist, als bei binären Protokollen 5, welche einen höheren Verarbeitungsaufwand benötigen (z.b. durch Analysierungsund Umwandlungsprozesse der empfangenen Antwortdokumente zum Herauslösen der darin enthaltenen Informationen). Um einen Web Service zu Realisieren, werden zwei wichtige Komponenten benötigt: eine Schnittstellenbeschreibung und die Funktionsimplementierung selbst. Der Konsument des Dienstes benötigt für den Nachrichtenaustausch die standardisierte Schnittstelle, welche die konkrete Implementierung des Services verbirgt. Zur Nutzung eines Web Services sind zusammengefasst mehrere Schritte notwendig, welche in Abbildung 2.3 aufgeführt sind. Abb. 2.3: Das Prinzip der Web Services (Quelle: nach Martin, 2009) 5 Beispielsweise ist HTTP in den oberen ISO/OSI-Schichten angesiedelt ist. 14

20 2.2 Web Services und Service-orientierte Architekturen Die Schritte, welche nötig sind um einen Web Service zu verwenden, könnten etwa wie folgt ablaufen: 1. Der Verfasser eines Dienstes veröentlicht eine Beschreibung seines Web Services in einem Verzeichnisdienst. 2. Ein Konsument sucht dort nach seinen Wünschen entsprechenden, potentiellen Diensten. 3. Das Diensteverzeichnis liefert eine Referenz (URI) auf das WSDL-Dokument des Dienstes auf dem Server/Provider des Anbieters. 4. Der Konsument fordert die Schnittstellenbeschreibung beim Anbieter an. 5. Der Dienstnutzer kann aufgrund des WSDL-Dokuments eine spezische Anfrage an den bereitgestellten Web Service senden. Im Folgenden sollen die wichtigsten Komponenten der Web Services näher beleuchtet werden Verzeichnisdienste Der Verfasser eines Web Services stellt die zugehörige Beschreibung einem Verzeichnisdienst zur Verfügung. Diese sind Kataloge, welche Referenzen zu verschiedensten Diensten sammeln und anbieten. Die am weitesten verbreiteten Abfragesprachen zur Interaktion mit diesen sind UDDI (Universal Description, Discovery and Integration) und die Web Service Inspection Language (WS-Inspection). Eingebunden in eine Service-orientierte Architektur ermöglichen es Verzeichnisdienste, dynamisch lose gekoppelte Dienste zu orchestrieren und damit die SOA- Landschaft zu füllen. Öentliche Verzeichnisse werden jedoch kaum noch genutzt, da Unternehmen ihre Dienste meist nur intern anbieten und häug essentielle Informationen z.b. zur Qualität des Dienstes oder zur Verfügbarkeit fehlen. (Vgl. Papazoglou, 2007, S. 177)) WSDL Die Web Service Description Language (WSDL) ist eine XML-basierte Sprache welche Adresse, Funktion und Benutzung des Dienstes darlegt. Sie ermöglicht die funktionale und nichtfunktionale Beschreibung. In einer abstrakten Schnittstellenbeschreibung werden verwendete Datentypen, Operationen und Nachrichten angegeben, die der Web Service unterstützt. Daneben werden in der konkreten Schnittstellenbeschreibung die zuvor denierten Operationen auf real existierende Operationen referenziert. Die WSDL enthält weder Quality-of-Service Informationen (Dienstgüte) noch Taxonomien (Klassizierung, Katalogisierung). Da solche 15

21 2.2 Web Services und Service-orientierte Architekturen Daten aber vor allem in betrieblichem Umfeld häug vorausgesetzt werden, existieren einige Zusatz-Spezikationen die Web Service Erweiterungen mit deren Hilfe die geforderten Ansprüche realisiert werden können (z.b. WS-Security oder WS-Policy). Der W3C-Status zur aktuellen WSDL Version 2.0 ist der einer Empfehlung (W3C Recommendation). Häug wird jedoch Version 1.1 verwendet. (Vgl. Papazoglou, 2007, S. 147) SOAP Das Simple Object Access Protocoll (SOAP) ist ein XML-basiertes Protokoll um Informationen zwischen Web Services auszutauschen. SOAP Nachrichten bestehen aus: Envelope: Umschlag, der die nächsten beiden Teile enthält und eine Nachricht von anderen abgrenzt. Er deniert zudem die verwendete SOAP-Spezikation. Header: Der optionale Kopfteil der Nachricht enthält weitere ergänzende Nachrichtenspezi- sche Daten (z.b. Sicherheits- oder Strategierichtlinien). Body: Enthält die eigentlichen Daten (message payload) im wohlgeformten XML Format (Erklärung dazu in der Fuÿnote auf S. 27), d.h. alles was sich als XML-Dokument abbilden lässt, kann in einer Nachricht übermittelt werden. Beispielsweise lassen sich Variablen und Objekte durch eine hierarchischen Baumstruktur repräsentieren (siehe Kapitel 6.5). Das Übertragungsprotoll ist dabei frei wählbar, jedoch meist HTTP. SOAP unterstützt auch Fehlernachrichten mit Fehlerdaten. Das Protokoll kann jedoch nicht den eigentlichen Web Services aktivieren, denn dieser wartet immer auf Anfragen. Auch können weder Nachrichten gruppiert werden, noch ist eine Referenzierung von Objekten möglich. Ein Transport von Teilobjekten ist ausgeschlossen. Eine Kommunikationsvariante von SOAP ist der Extensible Markup Language Remote Procedure Call (XML-RPC). XML-RPC ist strukturell simpel aufgebaut und damit relativ schnell zu verstehen, lässt aber nur eine synchrone Übermittlung zu. Alternativ kann der sog. documentstyle verwendet werden, welcher wohlgeformte XML-Dokumente nach festem Schema deniert. Hier ist auch eine asynchrone Übertragung möglich, da durch Identizierer Antworten eindeutige zu Anfragen zugeordnet werden können. (Vgl. Papazoglou, 2007, S. 119)) REST Representational State Transfer (REST) ist ein Architekturstil für verteilte Informationssysteme wie das Internet. Es ermöglicht, jede Ressource des Dienstes mit einer eigenen URL 16

22 2.2 Web Services und Service-orientierte Architekturen über HTTP zu adressieren. Dies stellt sicher, dass auf einfache, standardisierte Art für eine Vielzahl von Clientsystemen ein Web Service zur Verfügung gestellt werden kann, ohne eine Transportschicht wie SOAP nutzen zu müssen. Ein REST-konformer Service (RESTful Service) ist zustandslos. Die übermittelte HTTP-Botschaft enthält alle semantischen Informationen zur Einordnung einer Nachricht. Das Antwortdokument ist üblicherweise eine einfache XML-basierte Struktur, JSON und/oder ein HTML-Dokument Desweiteren können wohldenierte Operationen auf die bereitgestellten Ressourcen angewendet werden: GET fordert die angegebene Information vom Server an, PUT setzt oder ändert eine gegebene Ressource auf dem Server, POST fügt neue Daten zu einer Information hinzu, DELETE dient zum Löschen von Daten. REST ist aufgrund der zu Grunde liegenden Struktur und Anwendungsweise als Rückbesinnung auf ursprüngliche Ansätze einer einfachen, weiträumig nutzbaren Kommunikationsinfrastruktur im Internet zu sehen. (Vgl. Scribner & Seely, 2009, S. 2f) WCF RIA Services Microsoft bietet (insbesondere zur Entwicklung von RIAs) die Windows Communication Foundation Rich Internet Applications Services (kurz WCF RIA Services) für Systeme in einer.net integrierten Umgebung an. Dieses Framework deckt die Kommunikationsschicht einer Anwendung (mid-tier) ab und bietet umfassende Möglichkeiten der Datenkontrolle, Datenänderung und Datensteuerung. Sie soll vor allem die Entwicklungszeit von Silverlight- und ASP.NET Programmen verkürzen, indem schnell und ezient Code für datengetriebene Anwendungen erzeugt und verwendet werden kann. Beispielsweise generieren die Dienste aus ausgewählten Entities einer Datenbank alle Datenobjektklassen sowie den Kommunikationscode auf Server- und Clientseite. Die WCF RIA Services halten dabei sowohl den nötigen Programmode in der Präsentationsschicht, als auch in der Applikationslogik aktuell, sobald sich an der Kommunikationsinfrastruktur eine Komponente ändert, indem sie die genutzten Entity-Mengen überwachen und aktiv werden. (Vgl. Wahlin, 2010) Durch die solide Integration in bestehende Microsoft-Umgebungen (ASP.NET, Silverlight, SQL-Server) verkürzt sich der Entwicklungsaufwand von Internetanwendungen, da viele wiederkehrende Elemente wie z.b. die Authentizierung, Datenvalidierung und Sicherheitsaspekte bereits automatisch unterstützt werden. Das Framework ist zudem in hohem Maÿe in Visual Studio integriert. Es bringt Projektvorlagen mit, die ein Grundgerüst für line-of-business- Anwendungen in Silverlight bilden können. Diese Vorlagen besitzen schon von Beginn an 17

23 2.2 Web Services und Service-orientierte Architekturen Funktionen und Inhalte wie z.b. komfortable Navigationsstrukturen, Benutzerlogin und diverse UI-Oberächen (Views). Vieles kann mit der Maus über Assistenten und Menüs geändert werden, ohne selbst Programmcode anzupassen. (Vgl. Microsoft, 2010c) Zusammenfassung Eine Service-orientierte Architektur hat das Potential, groÿe Entwicklungs- und Wettbewerbsvorteile zu erzeugen. Sie kann jedoch nicht alle Probleme lösen und bedarf einer sorgfältigen Planung und Ausführung. Web Services bilden das Fundament einer verteilten Architektur insbesondere im Bereich der Webapplikationen. Die Technologie der Web Services ist aufgrund ihrer Flexibilität und normierten Benutzung bestens für die Realisierung einer SOA geeignet, denn sie vereinfacht die Kommunikation zwischen verschiedenen Systemen und beruht auf anerkannten sowie weit verbreiteten Standards des W3C. Auch RIAs passen sehr gut in dieses Konzept. Bedingt durch den Ablauf im Browser und den damit verbundenen eingeschränkten Rechten einer RIA auf dem Nutzersystem, wird ein zentraler Server zur Datenhaltung und Datenkommunikation benötigt. Dieser muss Schnittstellen und Funktionen anbieten, um den Anforderungen verschiedenster Applikationen Genüge zu tun. 18

24 Kapitel 3 Microsoft Silverlight Silverlight ist ein Framework zur Erstellung von.net-basierten und in Internetseiten integrierten Rich Internet Applications. Auch zur Ausführung einer Silverlightanwendung wird ein Browser-Plugin benötigt, welches das Programm in einem Container innerhalb der Internetseite startet und zeichnet. Wie andere RIA-Frameworks auch, bietet das Plugin umfangreichere Möglichkeiten als HTML oder JavaScript an. Dabei bringt Silverlight mit.net eine ausgereifte, mächtige und weit verbreitete Programmierplattform mit, die es erlaubt clientseitigen Code in C# oder VisualBasic zu schreiben. Das Framework ist nicht nur eine Oberäche um reichhaltige, interaktive Inhalte im Web zu präsentieren. Es bietet auch das Potential, zur Entwicklung von diversizierten, plattformübergreifenden, in Netzwerke eingebundene Anwendungen, die ihre Daten und Services aus verschiedenen Quellen beziehen (Microsoft, 2010b). Das Silverlight-Framework bildet eine reduzierte und speziell auf die Bedürfnisse einer RIA angepasste Teilmenge der Windows Presentation Foundation (WPF) ab. Die WPF und Silverlight beruhen auf gleichen Architekturen und stellen ähnliche Techniken, Funktionen und Eigenschaften bereit. Beispielsweise wird die Benutzeroberäche einer Silverlightanwendung ebenfalls durch XAML (Kapitel 3.4) beschrieben, während prozeduraler, objektorientierter Code in sog. Code-Behind-Dateien für die nötige Funktionalität sorgt. Dabei begrenzt Silverlight jedoch die Entwicklung, indem bestimmte Komponenten der windows-basierten WPF darin (aus Leistungs-, Kompatibilitäts- und Ausführungsgründen) für den Entwickler nicht zur Verfügung stehen. Die im Plugin enthaltene Silverlight Laufzeitumgebung ist eine reduzierte Version der.net Common Language Runtime (CLR), welche u.a. essentielle Kernklassen, garbage collection sowie Unterstützung für Generics und Threading mitbringt. Die angepasste CLR ist insbesondere daraufhin entwickelt worden, eine kompakte Form der.net-umgebung zu repräsentieren und die Programme schnell und ezient auszuführen. Das Silverlight-Plugin ist beim Down- 19

25 load nur sechs Megabyte groÿ. 1 Die Einschränkungen, die Silverlight inhaltlich mit sich bringt, beziehen sich z.b. auf fehlende ADO.NET-Klassen, ein nur in Ansätzen bestehendes Modell für Commands, reduzierte Funktionalität der Trigger (siehe Kapitel bzw. S. 38) und eine geringere Menge bereitgestellter Controls (wie baumartige Strukturen oder Kontextmenüs) als die WPF. Microsoft versäumte es jedoch nicht, die wichtigsten Grundlagen zur Erstellung eigener Komponenten mit einzubeziehen, sodass die Entwickler benötigte Programmteile selbst realisieren können. Daneben stellen Unternehmen und Programmierer aus aller Welt ihre eigens entwickelten Silverlight-Klassen zur Verfügung nicht zuletzt aus wirtschaftlichen Interessen. Ein Beispiel wäre IBM ILOG Gantt for.net. Eine detaillierte Dierenzierung der beiden Modelle würde hier den Rahmen sprengen, weshalb auf (Wintellect, 2009) verwiesen wird. Tabelle 3.1 stellt jedoch kurz die wichtigsten Dierenzen dar. Silverlight Webbasiert Auch auf nicht-windows Betriebssystemen ausführbar Unterstützt gängigste Browser für Windows und Mac Plugin benötigt XAML als Beschreibungssprache der Benutzeroberäche enthält reduzierte Menge an Elementen Zur Wiedergabe von Medien wird keine zusätzliche Software benötigt WPF Desktop-Anwendung Benötigt Microsoft Windows ab XP mit.net-laufzeitumgebung XBAP-Anwendungen 2 arbeiten nur im Internet Explorer.NET-Laufzeitumgebung benötigt XAML hat Zugri auf groÿe Control- Bibliothek Medienwiedergabe erfordert Installtion des Windows Media Players Tab. 3.1: Vergleich von Silverlight und WPF (Nach: Wildermuth, 2007, S. 19)) Die im Jahre 2007 veröentlichte Version 1 von Silverlight basierte noch in vollen Umfang auf JavaScript und war nicht in die.net-umgebung integriert, sodass die Möglichkeiten der Entwicklung auf einfache skriptbasierte Anwendungen mit wenigen Animationen und multimedialen Fähigkeiten sehr beschränkt war. Aus diesem Grunde folgte bereits ein knappes Jahr später die zweite Version, welche nun durch die Integration in.net, die Einführung von XAML zur Oberächenbeschreibung sowie der common language runtime (CLR) und erweiterten Funktionen zur Medienwiedergabe dramatische Veränderungen in den Möglichkeiten mit sich brachte. Silverlight war mit diesem 1 Zum Vergleich: die volle Standard-.NET Laufzeitumgebung hat einen Umfang von rund 48 MB 2 Eine XAML Browser Application (XBAP) ist eine WPF-Anwendung, die über das Web geladen und vom Browser gestartet wird. Auch hier wird auf dem Client eine installierte.net-laufzeitumgebung benötigt. 20

26 3.1 Das Silverlight Plugin Schritt zu einem relativ mächtigen Werkzeug im Gegensatz zu rein scriptbasierten Frameworks geworden. Mitte 2009 brachte Microsoft Version 3 auf den Markt, welche wiederum mit erweitertem Funktionsumfang aufwartete. Beispielsweise wurde dort das Konzept der out-of-browser-applications eingeführt, mit dem es möglich wurde, Silverlightanwendungen auch ohne geöneten Browser zu starten (ähnlich einer klassischen Desktopanwendung). Zahlreiche weitere Features weckten so das Interesse vieler Entwickler. Daher ist es nicht verwunderlich, dass Microsoft die Entwicklung des Frameworks schnell vorantreibt, denn der rasch fortschreitende Markt der RIAs ist in den Augen Vieler die Zukunft des Internets, da sie versuchen, vermeintliche Schwächen klassischer Internetanwendungen zu korrigieren. Weniger als ein Jahr später erschien im April 2010, gleichzeitig mit.net 4.0 Silverlight in Version 4. Neue Funktionen, die dort hinzukamen, sind u.a. eine lang erwartete Druckfunktion, Kontextmenüs über die rechte Maustaste, Kompatibilität mit sog. multitouch- Eingabegeräten, Webcam- und Mikrofonunterstützung sowie Verbesserungen der allgemeinen Leistungsfähigkeit. Jede neu veröentlichte Silverlight-Version rückte funktional näher an die Windows Presentation Foundation. Allerdings bleibt zu beachten, dass Silverlight ein browserbasiertes Plugin bleibt und somit stets im Umfang (zu.net) reduziert sein wird. Die Abwärtskompatibilität der Versionen ist ab Silverlight 3 stets gegeben. 3.1 Das Silverlight Plugin Das zur Ausführung von Silverlightanwendungen benötigte Plugin steht als kostenloser Download bei Microsoft zur Verfügung. Lädt ein Anwender eine Seite, die das Plugin benötigt, erhält der Nutzer den Link zum Herunterladen der Installationsdatei. Wird diese anschlieÿend ausgeführt und der Browser neu gestartet, lässt sich das besuchte Silverlightprogramm direkt verwenden. Abbildung 3.1 zeigt die von den unterschiedlichen Silverlightversionen unterstützten Browser und Betriebssysteme. Ein X kennzeichnet nicht verwendbare Kongurationen. Die minimalen Hardwareanforderungen sind wie folgt: x86 oder x64 Prozessor mit 500 MHz und Unterstützung für SSE-Instruktionen, sowie 128 MB Arbeitsspeicher. Für Linux- und FreeBSD-Systeme entwickelt das Communityprojekt Moonlight (ein Teil des Mono Projects 3 ) in Zusammenarbeit mit Microsoft und Novell eine.net-laufzeit- und Entwicklungsumgebung und das Silverlightplugin für Unix-basierte Rechner. Moonlight ist derzeit kompatibel mit Silverlight 2 und soll im Laufe des Jahres 2010 auch Anwendungen für 3 21

27 3.2 Architektur, Browserintegration und Deployment Abb. 3.1: Silverlight Kompatibilitätsmatrix (Quelle nach: (Tesar, 2009, S. 8) und (Wikipedia.org, 2010)) Silverlight 3 ermöglichen. Der Browser Opera wird derzeit nur inoziell unterstützt, soll aber, neben weiteren Plattformen in zukunftigen Silverlightversionen, ebenfalls integriert werden. Zudem ist eine Portierung des Plugins auf mobile Endgeräte (Mobiltelefone, Tablet PCs) geplant. Windows Phone 7 nutzt Silverlight bereits genauso, wie Nokias Betriebssystem Symbian für die herstellereigenen Smartphones (Virki, 2008). Eine Portierung auf die Android- Plattform ist wahrscheinlich (vgl. Foley, 2010). Ob Apple die mobilen Produkte iphone und ipad für Rich Internet Applications wie Flash und Silverlight önet oder in naher Zukunft auf HTML5 setzt, ist zur Zeit fraglich (can/ap/apn, 2010). 3.2 Architektur, Browserintegration und Deployment Microsoft Silverlight setzt die mehrschichtige Architektur der Windows Presentation Foundation fort, indem die graphische Benutzeroberäche von der Logik getrennt wird. Die daraus resultierenden Schichten erlauben eine bessere Kapselung der Komponenten, als es beispielsweise bei klassischen Windows-Forms-Anwendungen der Fall war. Abb. 3.2: Vereinfachte Silverlight-Architektur 22

28 3.2 Architektur, Browserintegration und Deployment Die sog. visuelle Ebene umfasst die Benutzeroberäche mit der der Nutzer interagiert und kommuniziert. Sie wird durch die deklarative Beschreibungssprache XAML (siehe Kapitel 3.4) erzeugt und beinhaltet keinerlei oder nur geringe Anteile der Funktionalität und Programmlogik. Diese bendet sich hauptsächlich in prozeduralen, C#- oder VisualBasic-basierten Codedateien (sog. Code-Behind-Dateien, siehe Kapitel 3.5), welche die funktionelle Logik implementieren. Abbildung 3.2 verdeutlicht diesen Zusammenhang modellhaft. Silverlight verwendet zwei Programmiermodelle: Die JavaScript API und den des managed code für.net. Erstere ist verantwortlich für die Integration der Applikation in den Browser bzw. die Internetseite und den initialen Programmstart. Die managed code-api ist wiederum Teilmenge des.net-frameworks und verwaltet durch die CLR u.a. die Code-Behind-Dateien. Die Kernkomponenten der Silverlight Plattform werden in Tabelle 3.2 beschrieben. Neben den zwei auf der managed code API beruhenden Hauptbestandteilen existiert zusätzlich der JavaScript-basierte Installer und Updater. Komponente core-presentationframework.net-framework für Silverlight Installer & Updater Beschreibung Komponenten und Funktionen der Benutzeroberäche, inklusive XAML, Verarbeitung der Benutzereingabe, Medienwiedergabe, Vektorgraphiken, Texte, Animationen, Digital Rights Management (DRM), Data Binding usw. Teilmenge des.net-frameworks mit Bibliotheken und Klassen für Datenintegration, Netzwerkbasisklassen, uvm. Die CLR ist ebenso Teil dieser Kompononente. Eine JavaScript-Logik zur vereinfachten Installation bzw. automatischen Aktualisierung des Silverlightplugins oder der Silverlightanwendungungen. Tab. 3.2: Kernkomponenten der Silverlight Plattform (Quelle: Microsoft, 2010b) Abbildung 3.3 zeigt wie die beschriebenen Komponenten in die Silverlight-Architektur eingebettet sind. Auf die übrigen Details der Abbildung soll nicht näher eingegangen werden, um den Rahmen dieser Bachelorarbeit nicht zu sprengen. Wie zuvor bereits beschrieben, basiert die Silverlight-Laufzeitumgebung auf einer reduzierten Form der.net-plattform und nutzt ähnliche Kernklassen und Bibliotheken wie die WPF. Das Silverlightplugin bündelt diese Komponenten und bindet sie in eine Browserumgebung ein. Dort arbeitet es in einem abgeschlossenen Bereich mit restriktiven Sicherheits- und Systemzugriseigenschaften, der Sandbox. Diese limitierte Umgebung schränkt die Silverlightanwendung insofern ein, dass sie bestimmte Rechte, die klassische Desktop-Applikationen besitzen können, nicht gewährt. So darf das 23

29 3.2 Architektur, Browserintegration und Deployment Abb. 3.3: Übersicht der Silverlight Architektur (Quelle: Microsoft, 2010b)) Programm beispielsweise weder beliebig Datenträger beschreiben und lesen, noch erhält es Zugri auf bestimmte Funktionen die etwa das Betriebssystem anbietet (Nutzerkonten, Systemvariabeln, etc.). Eine genauere Beschreibung der Sandbox erfolgt in Kapitel 3.9. Um dennoch Daten ablegen zu können, wird jeder im Plugin ausgeführten Anwendung ein virtueller, begrenzter Bereich der Festplatte zugeordnet (Isolated Storage), wo nur dieses Programm Zugri hat. Neben einer Verbindung zu einem Web Service und dem Isolated Storage, ist die einzige Möglichkeit für eine Silverlightanwendung, Dateien auÿerhalb der Sandbox zu Laden oder Speichern über einen Benutzerdialog, wobei eine Interaktion des Anwenders (und somit eine gewisse Kontrolle) stattndet. Eine Silverlightanwendung kann, nachdem sie kompiliert und in einer komprimierten, vom Plugin extrahier- und ausführbaren XAP-Datei 4 vorliegt, auf einer HTML-Internetseite veröentlicht werden. Dazu wird in einem <object>-tag u.a. der Typ type="application/x-silverlight-2" sowie die XAP-Datei als Quelle in einem weiteren Parameter <param name="source" value="clientbin/mysilverlightapp.xap"/> angegeben. Andere, im <object>-tag denierte Angaben beziehen sich z.b. auf die Gröÿe des Silverlight- 4 Der Server muss diesen Datentyp zulassen. 24

30 3.2 Architektur, Browserintegration und Deployment containers im Browserfenster oder die Update-Adresse bei Microsoft für das Plugin selbst. Listing 3.1 demonstriert eine Veröentlichung der Silverlightanwendung MySilverlightApp auf einer Internetseite. In der Regel wird der dortige Quelltext von der Entwicklungsumgebung erzeugt und muss nur geringfügig manuell konguriert werden. Näheres zum Deployment erläutert Kapitel < object data =" data : application /x - silverlight -2, " type =" application /x - silverlight -2 " width =" 100% " height =" 100% " > 2 < param name =" source " value =" ClientBin / MySilverlightApp. xap "/ > 3 <param name =" onerror " value =" onsilverlighterror " / > 4 <param name =" background " value =" white " / > 5 <param name =" minruntimeversion " value =" " / > 6 <param name =" autoupgrade " value =" true " / > 7 <a href =" http :// go. microsoft. com / fwlink /? LinkID =149156& v = " style =" text - decoration : none " > 8 <img src =" http :// go. microsoft. com / fwlink /? LinkId = " alt =" Get Microsoft 9 </a > 10 </ object > Silverlight " style =" border - style : none "/ > Listing 3.1: Deployment einer Silverlightanwendung in einer HTML-Internetseite Abbildung 3.4 verdeutlicht den Sachverhalt auf einer höheren Ebene sowie die Verknüpfungen der verschiedenen Systeme und Komponenten untereinander. Das im Browser ablaufende Silverlight Plugin lädt auf dem Anwendungsrechner das eigentliche Programm (zusammengefasst in der XAP-Datei) vom Server. Dieser beherbergt die Silverlightanwendung an sich und leitet Anfragen der RIA (etwa an Datenbanken) weiter. Abb. 3.4: Übersicht zum Deployment einer Silverlightanwendung Das Plugin selbst wird mit JavaScript gestartet 5. Ebenso überprüft die weiter oben im <head> eingebundene Datei Silverlight.js die Verfügbarkeit des Silverlightplugins, bzw. fordert zu 5 Durch eine Anpassung des JavaScript-Codes und unter Nutzung der Application-Klasse von Silverlight mit ihren Events, kann beispielsweise ein individueller Ladebildschirm implementiert werden (MacDonald, 2009, S. 192). 25

31 3.3 Entwicklungsumgebungen und SDKs dessen Installation auf, falls es noch nicht vorhanden ist. Scheitert eine Silverlightanwendung an einem internen Fehler, wird dieser gleichfalls durch eine JavaScript-Routine onsilverlighterror an die Fehlerkonsole des Browsers weitergeleitet (siehe auch <object>-parameter des Silverlight-Containers). Eine detaillierte Beschreibung der Möglichkeiten und Vorgänge des Deployment ndet sich beispielsweise bei (Tesar, 2009) oder (MacDonald, 2009). Über die JavaScript API der Silverlight Plattform ist auch eine durch managed code gesteuerte dynamische Generierung von DOM-Objekten des Browsers möglich, sodass eine Silverlightanwendung auch auf die HTML-Elemente der umschlieÿenden Seite zugreifen und diese manipulieren kann. In der Regel ist eine Entwicklungsumgebung für die Generierung des <object>-elements und der JavaScript-Dateien verantwortlich, sodass die Programmierer dies nicht manuell erledigen müssen. 3.3 Entwicklungsumgebungen und SDKs Wie bei anderen Bereichen der Softwareentwicklung ist eine Entwicklungsumgebung (IDE) zwar nicht nötig, jedoch aus Ezienzgründen sehr zu empfehlen, da von dieser häug wiederkehrende Aufgaben und Funktionen übernommen werden, die den Entwicklungsalltag erleichtern. Für Silverlight und.net allgemein ist Microsoft Visual Studio eine weit verbreitete IDE, die maÿgeblich zur Produktivität (nicht nur) der Programmierer erhöht. Um eine Silverlight 4 Anwendung zu implementieren, werden folgende Komponenten von Microsoft zur Verfügung gestellt: Microsoft Silverlight 4 Tools für Visual Studio 2010 stellt Vorlagen und Addons für die Entwicklungsumgebung sowie nötige Bibliotheken bereit. Ohne dieses Paket ist die Entwicklung von Silverlightanwendungen nicht möglich. Das Microsoft Silverlight 4 SDK enthält Onlinedokumentationen, Onlinebeispiele, Bibliotheken und Tools für die Entwicklung. Diese Komponente wird von den Silverlight 4 Tools ebenfalls installiert. Das optionale Paket Silverlight 4 Toolkit bringt zusätzliche, den Funktionsumfang der Standardinstallation vergröÿernden Funktionen und Klassen mit (z.b. neue Controls). Expression Blend 4 RC ist ein XAML-Editor und Werkzeug zur Gestaltung der Anwendungsoberäche von Silverlight und WPF-Anwendungen. 26

32 3.4 Visuelle Schicht: XAML Expression Blend erleichtert dabei vor allem den GUI-Designern die Arbeit, indem sie unterstützt durch die IDE die Oberäche der Anwendung entwerfen und realisieren. Dazu ist es den Gestaltern überlassen, ob sie direkt XAML-Code schreiben oder ob sie das Werkzeug die nötigen Codefragmente generieren lassen. Expression Blend lässt sich nahezu vollständig ohne Programmierkenntnisse (in XAML oder C#) bedienen. 3.4 Visuelle Schicht: XAML Die Extensible Application Markup Language (XAML) ist wie der Name schon andeutet eine wohlgeformte 6, XML-basierte Beschreibungssprache zur Oberächengestaltung von WPFoder Silverlightanwendungen. Eingeführt in.net Version 3.0 etablierte sich XAML schnell als Nachfolgemodell zu der bis dahin üblichen Herangehensweise der GUI-Erstellung über prozeduralen Programmcode in C# (bzw. C/C++). Diese Art der Trennung von Benutzeroberächendesign und -logik bringt einige Vorteile mit sich. Dennoch ist eine reine C#-Realisierung einer Oberäche weiterhin möglich, da XAML lediglich ein Format zur Serialisierung von Objekten ist (Huber, 2008, S. 143). Zur Laufzeit werden aus den dort angegebenen Elementen.NET-Objekte erzeugt. Im traditionellen Entwicklungsprozess wird häug schon zu Beginn das äuÿere Erscheinungsbild einer Anwendung entworfen. Dies ist in der Regel Aufgabe eines oder mehrerer Designer mit gestalterischen Kenntnissen zur Verbesserung der user-experience (UX-Design). Ist diese Arbeit abgeschlossen, wird das Ergebnis den Programmentwicklern meist in Form einer Bilddatei übergeben, welche die GUI nach diesem Entwurf realisieren. Sie erledigen also im Grunde nochmals die Arbeit der gestalterischen Abteilung, wobei es häug zu Konikten oder Abweichungen kommen kann (insbesondere bei visuell komplexen Anwendungen). XAML bietet hier einen Lösungsansatz, indem sich beide Gruppen ein gemeinsames Austauschformat teilen. Die Benutzeroberäche wird weiterhin vom Team der GUI-Entwickler mit Designwerkzeugen (Kapitel 3.3, Expression Blend) entworfen, das Ergebnis jedoch dann in XAML exportiert. Sie stellen den Entwicklern das Frontend zur Verfügung, welche es dann mit der nötigen Funktionalität und Logik versehen. Dieser Arbeiten können natürlich auch in umgekehrter Reihenfolge oder parallelisiert durchgeführt werden. Die durch die Trennung von visueller und logischer Schicht mit XAML weiter entstehenden Vorteile sind z.b.: Es werden neue Möglichkeiten des Software Engineerings erlaubt. Beispielsweise hat sich 6 Wohlgeformt heiÿt: 1. Die XAML-Datei hat genau ein Wurzelelement, das alle anderen Elemente einschlieÿt. 2. Auf ein önendes Element folgt stets ein schlieÿendes Element, oder es wird explizit ein leeres Element mit einem /> am Ende angegeben. 3. Die Elemente müssen überschneidungsfrei verschachtelt sein. 27

33 3.4 Visuelle Schicht: XAML für die Architektur von WPF- und Silverlight-Anwendungen das Model-View-ViewModel- Muster (Kapitel 6.2) bewährt. Da XAML kürzer, besser strukturiert und damit leichter zu lesen ist als prozeduraler Code, lässt sich die GUI zeitnah implementieren. XAML ist relativ leicht zu erlernen, da es an bekannte Konzepte wie XML und HTML angelehnt ist. Ein Designer mit Erfahrung in webbasierten Beschreibungssprachen kann sich schnell darin zurechtnden. Gegenüber einer prozeduralen Oberächenimplementierung in C# entstehen durch XAML keine Leistungsnachteile, da XAML lediglich eine alternative Repräsentation von.net Objekten ist. XAML-Dateien können zur Laufzeit dynamisch geladen werden, um die darin enthaltenen Objekte in der Anwendung zu Nutzen. Die folgenden Abschnitte erläutern die wesentlichen Aspekte zur GUI-Erzeugung in Silverlight und geben einen Einblick in XAML Controls Eine Benutzeroberäche lässt sich mit Silverlight aus sog. Controls zusammensetzen. Dies sind vordenierte (built-in) Bausteine der GUI, wie etwa Schaltächen (Button), Auswahlboxen (CheckBox, RadioButton), Listen (ListBox, ComboBox, StackPanel), Tabellen oder Gitternetze (Grid). Viele dieser Elemente geben nach einer Benutzerinteraktion ein visuelles Feedback. Beispielsweise ändert sich das Aussehen eines Button-Controls, sobald man mit der Maus darüber fährt. Eine fertige Anwendungsoberäche wird aus verschiedensten built-in-controls (also vom Framework bereitgestellte Elemente) und aus eigens für einen spezischen Zweck kreierten Controls zusammengebaut (z.b. ein erweitertes Calendar-Control zur Anzeige eines Kalenders). Die Grundlagen objektorientierter Programmierung gelten auch hier, sodass jedes Element der GUI durch eine entsprechende Klasse im Quelltext repräsentiert werden kann. Die Basisklasse Control erbt von FrameworkElement und erweitert diese um einige wichtige Attribute bzw. Properties (Properties werden in Kapitel genauer behandelt). Dies sind z.b Background Width/Height oder Margin/Padding. Die in den Controls enthalten Properties sind in der Regel selbsterklärend und dienen meist der visuellen Anpassung an eigene Bedürfnisse. Zudem werden einige logische Attribute bereitgestellt, z.b. IsTabStop oder IsEnabled. 28

34 3.4 Visuelle Schicht: XAML Abbildung 3.5 zeigt exemplarisch einige der wichtigsten Silverlight-Controls. Diese Controls sind im Allgemeinen lookless, d.h. die Logik, welche sie bereitstellen, ist nicht an ihr Äuÿeres gebunden. Ihr Erscheinungsbild ist daher fast beliebig veränderbar, ohne ihre Logik zu beeinussen. Abb. 3.5: Übersicht der wichtigsten Controls Mit dem Silverlight-Toolkit existieren bereits viele vorgefertigte Controls zur Gestaltung der Anwendungen. Obwohl sich das Aussehen dieser mit Hilfe von Styles, Triggern und Templates individuell anpassen lässt, ist es dennoch manchmal nötig eigene Controls zu erstellen. Die ist etwa der Fall, wenn mit den Bestehenden eine gewünschte Funktionalität nicht realisierbar ist. Es lassen sich zwei Arten von Controls entwickeln, Custom Controls und User Controls. Custom Controls unterstützen Templates und haben somit dasselbe lookless-verhalten wie die Controls von WPF und Silverlight. Es ist dann besonders geeignet, wenn es äuÿerlich stark verändert werden soll, aber gleichzeitig die eigentliche Funktionalität beibehält. Nach dem Erstellen eines Custom Controls liegt mindestens eine Code-Behind-Datei (*.cs) mit einer von Control abgeleiteten Klasse vor. Ebenso existiert eine.xaml-datei, welche das Default- Template (das standardmäÿige, äuÿere Erscheinungsbild) des Controls beschreibt. Auch wenn man bestehende Controls erweitern (also Aussehen und Funktion von ihnen erben) will, erstellt man ein Custom Control. Eigene User Controls dagegen leiten direkt von der Klasse UserControl ab und bieten keine Unterstützung für Templates. Man erstellt ein User Control, falls man in einer Anwendung mehrere Controls zu einem einzigen gruppieren möchte, um Komplexität zu kapseln oder diese Gruppe an anderer Stelle wiederzuverwenden. Ein Beispiel hierfür wäre etwa ein 29

35 3.4 Visuelle Schicht: XAML Visitenkarten-User-Control, welches mehrere formatierte Text-Blöcke (Adressangaben) und ein Bild zusammenfasst. Listet man diese Controls (beispielsweise zum Drucken eines Adressbuchs) auf, verwendet man mehrere der erstellten User Controls mit jeweils anderen Personendaten. Dies ermöglicht es, bestehende Komponenten wiederzuverwenden. (Huber, 2008, S. 897, 928f) XAML-Grundlagen Hinweis Die hier genannten Funktionen und Objekte stehen häug für die WPF und Silverlight gleichermaÿen zur Verfügung. Wenn in den folgenden Kapiteln also von Silverlight die Rede ist, gilt das Gleiche in der Regel auch für die WPF. Der Umkehrschluss gilt nicht unbedingt. Ein gültiges XAML-Dokument, bestehend aus einem roten Rechteck der Gröÿe 140x90 Pixel hinter einem Button mit der Aufschrift OK, wird in Listing 3.2 beschrieben. Man kann leicht das erzeugte Ergebnis in Abbildung 3.6 aus der XAML-Datei ableiten. 1 < UserControl 2 xmlns =" http: // schemas. microsoft. com / winfx /2006/ xaml / presentation " 3 xmlns:x =" http: // schemas. microsoft. com / winfx /2006/ xaml " 4 xmlns:d =" http: // schemas. microsoft. com / expression / blend /2008 " 5 xmlns:mc =" http: // schemas. openxmlformats. org / markup - compatibility /2006 " 6 mc:ignorable =" d" 7 x:class =" Examples. MainPage " 8 Width =" 640 " Height =" 480 " > 9 <! -- begin surface definition --> 10 <Grid x:name =" LayoutRoot " Background ="# FFAAAAAA " > 11 < Rectangle 12 Fill =" Red " 13 HorizontalAlignment =" Center " 14 VerticalAlignment =" Center " 15 Width =" 140 " Height =" 90 " 16 / > 17 < Button Content =" OK " 18 x:name =" btnok " 19 Click =" btnok_clicked " 20 HorizontalAlignment =" Center " 21 VerticalAlignment =" Center " 22 Width =" 66 " / > 23 </ Grid > 24 </ UserControl > Listing 3.2: Ein gültiges XAML-Dokument für Silverlight Im Beispiel 3.2 werden zur Laufzeit die Elemente UserControl, Button und Rectangle den entsprechenden.net Klassen zugeordnet und von diesen dann Instanzen erzeugt. Das XAML- 30

36 3.4 Visuelle Schicht: XAML Abb. 3.6: Die von Listing 3.2 erzeugten Elemente Attribut Content des Button-Elements wird dabei von Silverlight auf die passende Content- Property (Kapitel 3.5.1) der Button-Klasse abgebildet. Auf die gleiche Weise lassen sich über diese Attribute auch Events zuordnen. Hier wird bei einem Click-Event beispielsweise die Methode btnok_clicked in der Code-Behind-Datei aufgerufen (siehe Kapitel 3.5.2) 7. Diese als Attribut-Syntax 8 bezeichnete Zuweisung ist die simpelste Deklarierungsmöglichkeit von Werten in XAML. Die Zuordnung zwischen XAML und C# erfolgt dabei mit in Attributen des Wurzelelements (UserControl) angegebenen Namespaces durch das Attribut xmlns. Der XAML-Parser durchsucht dazu alle im Projekt referenzierten Assemblies und erstellt Objekte der gesuchten Klassen. Im Beispiel werden Instanzen der Klassen UserControl, Grid, Rectangle und Button aus dem Namespace System.Windows.Controls erzeugt. In den Attributen des Wurzelelements benden sich weiterhin Referenzen zu Schemadenitionen, verwendenten Namespaces und Bibliotheken. Das Konzept der XAML wird mit jeder neuen Veröentlichung einer.net-version mächtiger. Es existieren zahlreiche Eigenschaften, die die Entwicklungsarbeit leichter machen. Da deren Beschreibung aber den Rahmen dieser Arbeit sprengen würde, werden in hier nur ausgewählte Merkmale beschrieben und erläutert. 7 Die zugehörige Code-Behind-Datei wird durch x:class=examples.mainpage deniert. In diesem Fall bezeichnet Examples den Namespace der Anwendung und MainPage die Code-Behind-Klasse mit dem Konstruktor MainPage(). 8 Mit Hilfe von Markup-Extensions gibt es eine weitere Möglichkeit Objekte einer Property zuzuweisen, indem beispielsweise mit einem Data Binding ein bereits existierendes Objekt referenziert wird. Siehe dazu Kapitel

37 3.4 Visuelle Schicht: XAML Layout Es muss bei Entwurf und Realisierung von webbasierten Oberächen darauf geachtet werden, dass Browserfenster keine feste Gröÿe haben. Die GUI-Elemente sollten entweder dynamisch dem zur Verfügung stehenden Bereich angepasst werden, oder eine fest denierte Gröÿe im Sichtbereich besitzen. Silverlight bietet hierfür umfassende Möglichkeiten der Layoutgestaltung über eine Menge von Panels (Container), welche verschiedene Kindelemente enthalten dürfen. Da diese Containerklassen alle von Panel abgeleitet werden (welches wiederum ein FrameworkElement ist) verfügt es über Properties wie Width, Height, Margin und Padding (bekannt z.b. aus CSS) sowie die Horizontal- bzw. VerticalAlignment und Visibility- Eigenschaften. Damit lassen sich nahezu alle gewünschten Anordnungen und Positionierungen realisieren. Für komplexere Fälle existieren Transformationen. Die wichtigsten Panel-Klassen werden im Folgenden kurz erläutert. Das Canvas ist das einzige Panel, in dem die Elemente absolut positioniert werden. Dazu werden die Properties Bottom, Left, Right und Top bereitgestellt, die den jeweiligen Abstand zur Kante in logischen Einheiten 9 angeben. Für exible Layouts ist das Canvas daher ungeeignet, jedoch kann es bei xen Gröÿen sehr gut als Zeichenbereich etwa für geometrische Formen genutzt werden. Ein StackPanel stapelt seine Kindelemente horizontal oder vertikal. Dies ist für gleichmäÿige Strukturen sehr vorteilhaft. Beispielsweise kann so leicht eine Reihe von Buttons in einer Toolbar angeordnet werden. Das Grid ist eines der wichtigsten und vielseitigsten Containerelemente, denn es erlaubt zahlreiche exible Kongurationen. Es deniert Zeilen und Spalten mit variabler oder fester Gröÿe, zu denen sich die Kindelemente einordnen. In der Praxis verwendet man eine Vielzahl ineinander verschachtelter Panels um das gewünschte Aussehen zu erreichen Ressourcen, Styles und Templates Beim Entwickeln von Benutzeroberächen ist es von Bedeutung, dass die Anwendung ein konsistentes Design und Farbschema verwendet. Ressourcen, Styles und Templates verschaen hier Abhilfe, indem sie zentral deniert und von anderen Elementen verwendet werden. So kann das äuÿere Erscheinungsbild der Silverlight-Applikation bei Änderungen eektiv aktualisiert werden, ohne mehrere Kopien des gleichen XAML-Codes in den Dateien zu ersetzen. 9 Diese Werte sind geräteunabhängig, sodass die Elemente auf jedem Monitor gleich groÿ dargestellt werden. Bei einer Auösung von 96dpi entspricht eine logische Einheit (= 1/96 Inch) genau einem Pixel. 32

38 3.4 Visuelle Schicht: XAML Zudem steigert dies die Übersichtlichkeit der Quelltexte. Logische Ressourcen sind Objekte, die nachdem sie separat deklariert wurden, in der Anwendung referenziert werden können. Häug sind dies Instanzen von Brush, Color, Bilder oder die später beschriebenen Styles. Ressourcen müssen nicht unbedingt visuelle Objekte, sondern können auch logische Elemente wie Converter oder Validatoren sein. Dadurch kann vermieden werden, dass identischer XAML-Code an mehreren Stellen verwendet wird. Man deniert stattdessen zentral Ressourcen und referenziert diese dann dort, wo sie benötigt werden. Üblicherweise werden logische Ressourcen applikationsweit deniert, d.h. in der Haupt-XAML- Datei der Anwendung (App.xaml). Möchte man mehrere Anwendungen im gleichen Design erstellen, lassen sich Ressourcen sich auch in einer separaten Datei auslagern, welche dann in den jeweiligen Oberächen referenziert wird. Das Praxisbeispiel verwendet diese Methode des resource dictionary, in dem (zentral und applikationsweit) Stile für Schaltächen oder Farbverläufe angegeben werden. Es heiÿt dictionary, da jede darin abgelegte Ressource durch einen eindeutigen Schlüssel identiziert ist. Zur Denition einer logischen Ressource, wird ein Objekt zur Resources-Property eines Elements (oder dem resource dictionary) hinzugefügt. Kindelemente können diese mit der StaticResource-Markup-Extension referenzieren. In Beispiel 3.3 wird lokal eine Color-Ressource deniert, die als Hintergrundfarbe über den im zwingend notwendigen x:key-attribut eindeutig denierten Identikator von einem Grid verwendet wird. 1 < UserControl 2 xmlns =" http: // schemas. microsoft. com / winfx /2006/ xaml / presentation " 3 xmlns:x =" http: // schemas. microsoft. com / winfx /2006/ xaml " 4 x:class =" MySilverlightApplication. MainPage " 5 Width =" 640 " Height =" 480 " > 6 7 <! -- definition of the resources --> 8 < UserControl. Resources > 9 <Color x:key =" BackgroundColor " ># FF </ Color > 10 </ UserControl. Resources > <! -- begin surface definition --> 13 <Grid x:name =" LayoutRoot " > 14 <Grid. Background > 15 < SolidColorBrush Color ="{ StaticResource BackgroundColor }"/ > 16 </ Grid. Background > 17 < Button Content =" Button " > 18 < Button. Foreground > 19 < SolidColorBrush Color ="{ StaticResource BackgroundColor }"/ > 20 </ Button. Foreground > 21 </ Button > 22 </ Grid > 23 </ UserControl > Listing 3.3: Ressourcendenition und Referenzierung 33

39 3.4 Visuelle Schicht: XAML Das Button-Element verwendet ebenfalls die selbe Ressource als Vordergrundfarbe der Beschriftung. Da diese Property aber nur Objekte vom Typ SolidColorBrush entgegen nimmt, muss eine solche mit der Color-Ressource instanziert werden. Ressourcen werden in Silverlight nur einmal instanziert. Jeder Zugri auf diese ist also ein Zugri auf dieselbe Instanz. Bei bestimmten Objekten kann es zu Problemen 10 führen, mehrere Referenzierungen auf eine einzelne Ressource zu setzen. Um Fehler zu vermeiden, sollte in solchen Fällen das x:shared-attribut der Ressource auf false gesetzt werden, damit es für jede Referenzierung neu instanziert wird. Sollten sich die Ressourcen zur Laufzeit verändern (z.b. der Hintergrund wechselt die Farbe), würde dies von den referenzierten Elementen nicht bemerkt werden. DynamicResources wie sie in der WPF angeboten werden, existieren in Silverlight nicht. Eine mögliche Lösung wäre es, stattdessen Data Binding zu benutzen, wie es in Kapitel 3.6 beschrieben ist. Binäre Ressourcen sind in der Regel nicht ausführbare Dateien, die zusammen mit der Anwendung ausgeliefert werden und Teil dieser sein können. Dies können Bilder, Symbole, Programmbibliotheken oder Lokalisierungsdateien (für unterschiedliche Länder und Kulturen) sein. Häug werden diese Dateien als binäre Datenströme in eine Assembly kompiliert (als sog. eingebettete Ressourcen). Zur Laufzeit können diese dann ausgelesen werden (vgl. Huber, 2008, S. 530). Mit einem Style lassen sich gruppierte Werte für mehrere Properties denieren. Objekten kann somit eine Instanz der Klasse Style zugewiesen werden, die verschiedenen Attributen des Objektes verschiedene Werte setzt. Ein Style ist am besten mit einer CSS-Klasse vergleichbar, welche einem Element ein neues Aussehen oder Verhalten zuweist. Eingesetzt als logische Ressource, tragen Styles ebenfalls zur strukturierten und konsistenten Oberächengestaltung bei. Die Style-Klasse deniert einen Setter mit den Attributen Property und Value zum Setzen der Werte. Listing 3.4 und Abbildung 3.7 zeigen die Verwendung exemplarisch. 1 < UserControl 2 xmlns =" http: // schemas. microsoft. com / winfx /2006/ xaml / presentation " 3 xmlns:x =" http: // schemas. microsoft. com / winfx /2006/ xaml " 4 x:class =" MySilverlightApplication. MainPage " 5 Width =" 640 " Height =" 480 " > 6 7 < UserControl. Resources > 8 <! -- style for larger buttons --> 9 <Style x:key =" bigbtnstyle " TargetType =" Button " > 10 < Setter Property =" FontSize " Value =" 16 " / > 10 Ein Element darf nur einmal im sog. Element Tree vorkommen. Näheres dazu in (Huber, 2008, S. 195). Einfache Objekte wie Brush und Color sind nicht dieser Objekthierarchie und können daher mehrfach verwendet werden. 34

40 3.4 Visuelle Schicht: XAML 11 < Setter Property =" Foreground " Value =" Red " / > 12 </ Style > 13 <! -- inherit and extend styles --> 14 <Style x:key =" bigemphasizedbtnstyle " TargetType =" Button " BasedOn ="{ StaticResource bigbtnstyle }" > 15 < Setter Property =" FontWeight " Value =" Bold " / > 16 </ Style > 17 <! -- common button style definition --> 18 <Style TargetType =" Button " > 19 < Setter Property =" Foreground " Value =" Green " / > 20 </ Style > 21 <! -- common style definition for an control --> 22 <Style x:key =" commonstyle " TargetType =" Control " > 23 < Setter Property =" Control. RenderTransform " > 24 < Setter. Value > 25 < RotateTransform Angle =" 10 " / > 26 </ Setter. Value > 27 </ Setter > 28 </ Style > 29 </ UserControl. Resources > <! -- apply styles --> 32 <Grid x:name =" LayoutRoot " > 33 < Button Content =" Button A" Style ="{ StaticResource bigbtnstyle }" / > 34 < Button Content =" Button B" Style ="{ StaticResource bigemphasizedbtnstyle }" / > 35 < Button Content =" Button C" / > 36 < Button Content =" Button D" Style ="{ StaticResource commonstyle }" / > 37 < TextBox Text =" TextBox " Style ="{ StaticResource commonstyle } / > 38 < CheckBox Content =" CheckBox " Style ="{ StaticResource commonstyle }"/ > 39 </ Grid > 40 </ UserControl > Listing 3.4: Verwendung von Styles Hinweis Um die Beispiele übersichtlich zu halten, werden in den Listings einige Layoutdenitionen (z.b. HorizontalAlignment oder Margin) auÿer Acht gelassen, sodass das Kopieren und Ausführen des Codes zu einer abweichenden Darstellung führen könnte. Die denierten Styles müssen in Silverlight einen TargetType angeben, wo der Typ des den Style benutzenden Elements bestimmt wird, damit die zugehörigen Setter auch tatsächlich in die entsprechende Property umgesetzt werden können. Die ersten drei werden einem Button-Objekt zugewiesen, weshalb der TargetType auf Button gesetzt wird. Die vierte Stylede- nition bleibt allgemein, indem der Typ als Control (von welchem alle Silverlight-Elemente abgeleitet werden), gesetzt wird. Die Setter innerhalb der jeweiligen Styleangaben setzen - entsprechend der Angabe im Property-Attribut und des Values - die Eigenschaften der den Style referenzierenden Elemente. Zur Referenzierung wird wie schon bei den logischen Resourcen üblich ein Binding an einen eindeutigen x:key angegeben Beispielsweise erhält Button A 35

41 3.4 Visuelle Schicht: XAML eine vergröÿerte, rote Schrift aus dem Style bigbtnstyle, während Button B einen Style bigemphasizedbtnstyle verwendet der auf bigbtnstyle basiert und diesen um einen weiteren Setter ergänzt. Durch diesen wird die Schrift zusätzlich noch fett gezeichnet. Button C macht explizit keine Styleangabe, jedoch wurde in der dritten Styledenition oben der TargetType auf Button gesetzt, ohne dabei ein x:key zu vergeben. Dadurch referenzieren alle Elemente vom Typ Button automatisch diesen Style und Button C hat eine grüne Schrift. Die Elemente der unteren Reihe erben alle von der Klasse Control und können daher mit der vierten Styledenition commonstyle referenziert werden, welcher die Objekte um 10 Grad dreht. Abb. 3.7: Durch Styles veränderte Controls Ein Template deniert das spezische Aussehen für ein Control oder für Daten. In Silverlight werden drei Arten von Templates Unterschieden: ItemsPanelTemplate - deniert das Panel, das von einem ItemsControl (z.b. eine ListBox), für das Layout der darin enthaltenen Items verwendet wird. Üblicherweise wird hierfür ein StackPanel genutzt, mit dem diese gestapelt werden. DataTemplate - deniert das Aussehen für Daten einer Klasse, damit alle Objekte dieser Klasse in der Anwendungsoberäche visuell repräsentiert werden können. Ein DataTemplate wird dann beispielsweise als Vorlage für einzelne Items einer ListBox verwendet ControlTemplate - beschreibt das allgemeine Aussehen eines Controls, welches komplett von der Logik getrennt ist. (Vgl. Huber, 2008, S. 586) Das ControlTemplate soll hier nun näher erläutert werden, da es essenziell für eine individuelle Anwendungsoberäche ist. In Listing 3.5 wird erneut eine Ressource erstellt, die ein ControlTemplate für einen Button deniert. Dazu erhält die Schaltäche ein komplett neues Aussehen - die Funktionalität bleib allerdings bewahrt. Wie im Codeausschnitt ersichtlich besteht der Button aus einer grauen Umrandung, deren Inhalt einen roten Hintergrund hat. Zusätzlich wird der Text Red Button angezeigt. Beim Testen fällt allerdings auf, dass die 36

42 3.4 Visuelle Schicht: XAML Schaltäche weder wie gewohnt ihr Aussehen beim Klicken verändert, noch ist es möglich einen neuen Text über die Content-Property zu setzen dieses Verhalten wurde ja nicht deniert. Abbildung 3.8 zeigt das Ergebnis in Button A. 1 < UserControl. Resources > 2 < ControlTemplate x:key =" RedButtonTemplate " TargetType =" Button " > 3 < Border BorderBrush =" Gray " BorderThickness =" 2" CornerRadius =" 10 " Background =" Red " > 4 < TextBlock Foreground =" White " Text =" Red Button " / > 5 </ Border > 6 </ ControlTemplate > 7 </ UserControl. Resources > 8 9 <Grid x:name =" LayoutRoot " Background =" White " > 10 < Button Template ="{ StaticResource RedButtonTemplate }" Content =" My New Button " / > 11 </ Grid > Listing 3.5: Ein einfaches Template Abb. 3.8: Ein Button mit einfachem (A) und verbessertem (B) Template Der ContentPresenter wird von allen Controls benötigt, die eine Content-Property (also weitere eigenen Kindelemente) anbieten. Vereinfacht gesagt, gibt er Silverlight an, wo die Inhalte hineingehören (MacDonald, 2009, S.452). Fügt man diesen in das Template ein, lässt sich über die Content-Property des Buttons wieder der Inhalt setzen. Ähnlich verhält es sich bei den Template Bindings. Sie ermöglichen es Werte aus dem das Template verwendende Control zu lesen, und diese im Template anzuwenden. Listing 3.6 korrigiert die Einschränkungen aus dem vorherigen Beispiel, indem ein ContentPresenter und mehrere Template Bindings hinzugefügt werden. Button B in Abbildung 3.8 hat nun die gewünschten Eigenschaften. 1 < UserControl. Resources > 2 < ControlTemplate x:key =" RedButtonTemplate " TargetType =" Button " > 3 < Border BorderBrush =" Gray " BorderThickness =" 2" 4 CornerRadius =" 10 " Background =" Red " > 5 < ContentPresenter 6 Content ="{ TemplateBinding Content }" 7 Margin ="{ TemplateBinding Padding }" 8 / > 9 </ Border > 10 </ ControlTemplate > 11 </ UserControl. Resources > <Grid x:name =" LayoutRoot " Background =" White " > 37

43 3.4 Visuelle Schicht: XAML 14 < Button Template ="{ StaticResource RedButtonTemplate }" 15 Content =" My New Button " 16 HorizontalAlignment =" Center " VerticalAlignment =" Center " 17 Padding =" 14,15,14,14 " / > 18 </ Grid > Listing 3.6: Das verbesserte Template Um eine visuelle Veränderung des erstellten Elements nach Benutzerinteraktion (z.b. nach einem Mausklick) zu erreichen, verwendet Silverlight sog. Visual States, die jeweils ein spezielles Aussehen denieren, je nachdem in welchem Zustand (Disabled, IsMouseOver, Clicked, etc.) sich das Control bendet. Visual States werden üblicherweise in Zusammenhang mit Animation verwendet. Die aus der Windows Presentation Foundation bekannte Funktionalität der Trigger, zur Denition von dynamischen Aktionen in XAML, die zur Laufzeit stattnden und auf Bedingungen reagieren, steht standardmäÿig in Silverlight nicht zur Verfügung. Mit der Installation von Expression Blend 3 (oder höher) wird allerdings der Namespace System.Windows.Interactivity hinzugefügt, welcher sog. Behaviors und Actions einführt. Diese kapseln ein allgemeines Verhalten für Funktionalitäten des User Interfaces (z.b. das Starten einer Animation oder dem Aufrufen einer Verknüpfung). Ebenso lassen sich komplexere Verhalten realisieren die beispielsweise das Scrollen über ein Mausrad ermöglichen. Der Vorteil dieser Variante gegenüber einer Implementierung von Events in der logischen Schicht ist zum einen die Möglichkeit der Wiederverwendung der Codefragmente an anderer Stelle und zum anderen vereinfacht es dem Oberächendesigner die Arbeit indem die gewünschten Behaviors einfach per Drag&Drop in Expression Blend den Controls zugeordnet werden. Sie erlauben eine saubere, modulare und zentrale Art der Implementierung von Funktionalität. Dieses Thema soll aufgrund des recht umfangreichen Konzepts hier nicht näher erläutert werden Silverlight Animationen Ein wichtiges Designmerkmal von interaktiven Rich Internet Applications ist die visuelldynamische Reaktion der GUI-Komponenten auf Benutzerinteraktionen. Selbst kleine, kaum bemerkenswerte Veränderungen eines Buttons nachdem die Maus darüber fährt, bereichern die Anwendung ungemein. Fehlen diese Animationen wirkt das Programm häug statisch und unvollständig. Eine Schaltäche, die nach einem Klick den Eindruck erweckt nach hinten zu gleiten, lässt sie realistisch aussehen und macht die Bedienung intuitiv. Zur Realisierung solcher graschen Feinheiten bietet Silverlight die Animations. Diese beruhen auf drei Prinzipien: Silverlight Animationen sind zeitbasiert. Der Entwickler setzt den Initialzustand, den 38

44 3.5 Logische Schicht: Code-Behind-Dateien Endzustand und die Dauer der Animation. Silverlight berechnet daraus die nötigen Zwischenschritte für einen weichen Übergang. Eine Silverlight Animation verändert Properties über einen Zeitraum. Jeder Datentyp erfordert eine eigene Animationsklasse. Um einen double-wert zu animieren, wird beispielsweise die DoubleAnimation-Klasse verwendet. Für einen Farbübergang kommt analog eine ColorAnimation zum Einsatz. Silverlight bietet eine Vielzahl von Möglichkeiten zur Gestaltung von Animation, die hier nicht alle betrachtet werden sollen. In der Regel unterstützt Expression Blend bei deren Erstellung, indem dort automatisch der nötige XAML-Code generiert wird, nachdem der Designer die Animation mit Hilfe der Funktionen der Entwicklungsumgebung anpasst. So lassen sich leicht individuelle Animationen mit einem einfachen Werkzeug realisieren. Silverlight kann dabei auch von der Hardware unterstützt werden, indem die Grakkarte zum Zeichnen der Animationen oder cachen der Bitmaps genutzt wird. 3.5 Logische Schicht: Code-Behind-Dateien Wie in Kapitel 3 bereits angeklungen, besteht das Programmiermodell von Silverlight grundlegend aus zwei Schichten: der visuellen Schicht, deniert durch XAML-Dateien, und der logischen (oder funktionalen) Schicht, die prozeduralen Programmcode zur Steuerung der Anwendung enthält. Letztere, Code-Behind genannten Dateien, bilden das ausführbare Programm. Üblicherweise existiert zu jeder XAML-Datei eine entsprechende Code-Behind-Datei mit konventionsgemäÿ gleichem Namen wie das XAML-Dokument (allerdings mit der Endung.cs oder.vb), in der die für die Oberäche gewünschte Funktionalität bereitgestellt wird. Eine leere Silverlight-Anwendung wird in Listing 3.7 und 3.8 beschrieben. In der XAML- Datei MainPage.xaml deniert das Wurzelelement UserControl im x:class-attribut die zugehörige Code-Behind Datei bzw. die bei der Erstellung zu instanzierende Klasse MainPage (in der Datei MainPage.cs), welche von UserControl abgeleitet ist. Der dortige Konstruktor ruft zunächst eine automatisch generierte Methode InitializeComponent() auf, die die in der XAML mit x:key oder x:name benannten Elemente mit den in der logischen Schicht erzeugten Objekten verknüpft 11. Denn: in XAML verwendete Controls repräsentieren Klassen, welche erst zur Laufzeit in der logischen Schicht instanziert werden. Sind diese erzeugt worden, kann beliebiger Code folgen, der die XAML-Elemente als normale Objekte verwendet und so die Anwendung mit Funktionalität ausstattet. 11 Dazu stellt die Klasse UserControl die Methode FindName(string name) zur Verfügung, die im XAML- Objektbaum nach den mit name benannten Elementen sucht. 39

45 3.5 Logische Schicht: Code-Behind-Dateien 1 < UserControl <!-- schema definitions removed --> 2 x:class =" SilverlightApplication1. MainPage " > 3 4 <Grid x:name =" LayoutRoot " Background =" White " > 5 </ Grid > 6 </ UserControl > Listing 3.7: XAML einer leeren Silverlight-Anwendung 1 using System ; 2 (...) 3 4 namespace SilverlightApplication1 5 { 6 public partial class MainPage : UserControl 7 { 8 public MainPage () 9 { 10 // auto generated : required to initialize variables 11 InitializeComponent () ; 12 } } 15 } Listing 3.8: Code-Behind Datei einer leeren Silverlight-Anwendung Um die in XAML denierten Elemente im prozeduralen Code anzusprechen, wird diesen mit dem x:name- bzw. x:key-attribut ein eindeutiger Identier vergeben. x:key und x:name sind nicht identische Begrie. x:key wird ausschlieÿlich in Ressourcenwörterbüchern, x:name für alle Bereiche von XAML verwendet. Listing 3.9 zeigt ein CheckBox-Control in XAML, das mit mycheckbox einen eindeutigen Namen hat. In der zugehörigen Code-Behind-Datei des XAML-Dokuments ist das Control über diesen Identier als instanziertes Objekt erreichbar. Der Quelltext aus Listing 3.10 setzt exemplarisch den Haken der Box, sobald das Programm geladen wird. Alternativ kann dies auch direkt in XAML durch das Attribut IsChecked=true erreicht werden. Der XAML-Parser erzeugt entsprechend zur Laufzeit in der logischen Schicht ein neues Objekt vom Typ CheckBox und setzt das IsChecked-Attribut auf true. 1 < UserControl <!-- schema definitions removed --> 2 x:class =" SilverlightApplication1. MainPage " > 3 4 <Grid x:name =" LayoutRoot " Background =" White " > 5 < CheckBox x:name =" mycheckbox " Content =" CheckBox " HorizontalAlignment =" Left " 6 </ Grid > 7 </ UserControl > VerticalAlignment =" Top "/ > Listing 3.9: CheckBox in XAML mit eindeutigem Identier 40

46 3.5 Logische Schicht: Code-Behind-Dateien 1 using System ; 2 (...) 3 4 namespace SilverlightApplication1 5 { 6 public partial class MainPage : UserControl 7 { 8 public MainPage () 9 { 10 // auto generated : required to initialize variables 11 InitializeComponent () ; 12 mycheckbox. IsChecked = true ; 13 } } 16 } Listing 3.10: Code-Das IsChecked-Attribut wird gesetzt Dependency Properties Mit der Windows Presentation Foundation führte Microsoft ein neues property model ein, welches auch in Silverlight zum Einsatz kommt. Die sog. Dependency Properties erweitern einfache Properties von.net-objekten so, dass neue, mehrschichtige 12 und dynamische Benutzeroberächen mit Data Binding, Animationen und Styles diese ezient und korrekt einsetzen können. Z.B. wurde eine Prioritätsmodell benötigt, welches Animationen (während sie ablaufen) stets aktuelle Werte liefert, und andere gleichzeitig zugreifende Prozesse hinten anstellt. Daher stammt auch der Name ein Dependency Property (in deutscher Literatur und von Microsoft gerne als Abhängigkeitseigenschaft bezeichnet) hängt von mehreren property providern ab, die alle ihrer eigene Priorität haben (dynamic value resolution, (vgl. MacDonald, 2009, S. 107f, 110). Vorteile gegenüber klassisch implementierten Properties, sind z.b. ein integrierte Benachrichtigungsmechanismus für Änderungen, Default-Werte, Vererbung des Wertes über den Logical Tree oder Metadaten (Huber, 2008, S. 389). Die meisten der Elemente von Silverlight und WPF sind als Dependency Properties implementiert; ihre Nutzung erfolgt wie gewohnt über gekapselte getter und setter, die die Properties von der sog. Property Engine erhalten. Festzuhalten ist hier, dass bestimmte Funktionen und Elemente von XAML Dependency Properties benötigen. 12 Gemeint ist hier eine mögliche Überschneidung oder Überlappung von Elementen der GUI. 41

47 3.5 Logische Schicht: Code-Behind-Dateien Abb. 3.9: Vereinfachtes Konzept der Routed Events Eventhandling und Routed Events Aufgrund der mehrschichtigen Benutzeroberäche wurde auch ein neues Modell der Events entworfen. Die Routed Events erlauben einem Event, von einem ursprünglichen Initiator ausgehend, entlang dessen Elementhierarchie (dem visual tree) nach oben hin aufgegrien zu werden. Das als event bubbling bezeichnete Verhalten wird z.b. für den Fall benötigt, dass ein Mausklick auf ein in einen Button integriertes Image auch das Click-Ereignis der Schaltäche auslösen soll und nicht nur auf der Image-Komponente registriert wird. Abbildung 3.9 zeigt dies exemplarisch. Auf dem Image-Element in Abbildung 3.9 wird ein MouseClick-Event gefeuert, welcher zunächst den Elementbaum nach oben wandert (bubbling), bevor er wieder als PreviewMouse- Click-Event nach unten weitergereicht wird (tunneling). Auf diese Weise kann jedes beteiligte Control das Click-Ereignis behandeln (sie agieren als sog. listener oder Abonnenten des Events). Ist eine Unterbrechung dieses Routings auf anderen Hierarchie-Ebenen gewünscht, kann der Event durch setzen des Handled-Attribut jederzeit abgebrochen werden. Silverlight verwendet allerdings nur stark reduzierte Routed Events: Tunneling ist beispielsweise genauso wenig möglich wie ein Routing für das einfache Click-Ereignis (vgl. Microsoft, 2010a). In der Regel stellt dies allerdings kein Hindernis bei der Entwicklung von Programmen dar, denn es lassen sich (wie bei.net gewohnt) Event-Handler in der logischen Ebene denieren, die solche Ereignisse durch die CLR behandeln. Ein zusätzlicher Unterschied zu WPF-Anwendungen besteht im Ursprung der Events. Auf klassischen Desktop-Anwendungen reagiert die Anwendung direkt auf einen Maus- oder Tastaturevent. Da Silverlight als Plugin einer Webseitenanwendung ausgeführt wird, ist registriert der Browser zunächst die z.b. durch Mausklicks ausgelösten Events und leitet diese an die Silverlight API weiter. Dort angekommen kann darauf reagiert werden. Im Normalfall muss 42

48 3.5 Logische Schicht: Code-Behind-Dateien sich der Silverlightentwickler nicht um diesen Umstand kümmern. Listing 3.11 und 3.12 demonstrieren die Registrierung eines Events via XAML auf einem Button-Control und die Behandlung des Ereignisses im prozeduralen C#-Code der logischen Schicht, indem dort die Beschriftung der Schaltäche verändert wird. Silverlight stellt für jeden Event, in XAML ansprechbare Attribute bereit, in denen eine Methode der Code-Behind-Datei angegeben werden kann. Der XAML-Parser erstellt bei der Kompilierung die Eventhandler und registriert sie auf die jeweiligen Objekte und referenzierten Methoden. 1 < Button x:name =" mybutton " Content =" push me " Click =" Button_Click "/ > Listing 3.11: Dem Click-Event eines Buttons wird eine Methode zugewiesen 1 private void Button_Click ( object sender, System. Windows. RoutedEventArgs e) 2 { 3 mybutton. Content = " Button clicked!"; 4 } Listing 3.12: Code-Behind Datei mit aufzurufender Methode Commands Der Nachteil des Eventmodells ist eine starke Bindung zwischen Auslöser und Verarbeiter (bzw. listener) eines Ereignisses. Üblicherweise wird auf ein solches direkt in der zugehörigen Code-Behind-Datei mit Programmtext reagiert, der die gewünschte Funktionalität erfüllt. Möchte man die Silverlightanwendung mit Hilfe eines modernen Softwareentwurfsmusters (Kapitel 6.2) verwirklichen, kann diese enge Bindung von groÿem Nachteil sein. Ein Command kapselt eine Funktionalität und fügt häug benötigte Routinen hinzu, die eine manuelle Implementierung von Event-behandelndem Code üblicherweise mit sich bringt. Dadurch können Aktionen gekapselt, zu einem gewissen Grad abstrahiert und vom Kontext losgelöst werden. Typisch für ein Command wären Funktionen wie cut, copy und paste oder eine globale Beenden-Funktion, die an mehreren Stellen der Anwendung aufgerufen und verwendet werden können. Diese Aktionen lieÿen sich auch über Eventhandler realisieren, jedoch müsste dann umfangreicher, teils wiederkehrender und identischer Code beispielsweise zur Steuerung der (De-)Aktivierung von mehreren Buttons oder Menüeinträgen, implementiert werden. Die Commands übernehmen diese Aufgaben und halten den Status der Controls, die sie verwenden stets aktuell. 43

49 3.5 Logische Schicht: Code-Behind-Dateien Commands sind seit Silverlight 4 für Button und HyperlinkButton möglich. Sie reagieren standardmäÿig nur auf ein Mausklick oder nach Betätigung der Enter-Taste auf einem fokussiertem, Commands unterstützenden Control. Um mit einem Command auf andere, evtl. selbst denierte Events zu reagieren, wird die Bibliothek System.Windows.Interactivity benötigt, welche mit Microsoft Expression Blend 3 (und höher) installiert wird. Darin enthalten sind EventTrigger Denitionen, die ein beliebiges Event (z.b. MouserOver, KeyDown) an ein Command oder eine Methode binden 13. Im Gegensatz zur WPF besitzt Silverlight für Commands allerdings keine integrierte Unterstützung für Tastenkürzel (sog. shortcuts), welche klassisch über Events realisiert werden können. Eigens erstellte Commands müssen das Interface ICommand implementieren. Darin sind zwei Methoden (Execute, CanExecute) mit jeweils einem Objektparameter und ein Event (CanExecuteChanged) deniert. Execute(object param) kapselt und beinhaltet die Funktionalität des Commands und stellt sie für alle Aufrufer bereit. Die Routine wird von den an den Command gebundenen Controls aufgerufen, sobald diese ein Click-Event registrieren oder mit Enter aktiviert werden und führt daraufhin eine Aktion aus. Der Parameter könnte z.b. den Sender (also Auslöser) der Aktion beinhalten. Die Execute-Methode würde dann in ihrer Logik überprüfen, wer der Aufrufer war und entsprechend darauf reagieren. CanExecute(object param) ist für den Zustand des Commands verantwortlich und steuert die Verfügbarkeit dessen für die Aufrufer. An diesen getter wird häug das IsEnabled- Attribut eines Controls gebunden. Liefert CanExecute true, ist der Command von den Buttons, Menüeinträgen etc. ausführbar und diese sind automatisch aktiviert. Ansonsten wird false zurückgegeben und die Elemente sind im deaktivierten Zustand. Der Event CanExecuteChanged ermöglicht diesen Automatismus, indem er jedes mal manuell gefeuert werden muss, sobald sich die logischen Gegebenheiten des Commands ändern. Durch ihn werden die gebundenen Controls über den neuen Zustand informiert. Listings 3.13, 3.14 und 3.15 demonstrieren exemplarisch die Implementierung und Verwendung einer eigenen Command-Klasse. 1 public class MyWorkCommand : ICommand 2 { 3 public event EventHandler CanExecuteChanged ; 4 5 public bool CanExecute ( object parameter ) 6 { 7 // if (...) 8 return true ; // or false 9 } public void Execute ( object parameter ) 12 { 13 // do some work 14 } 13 Näheres dazu z.b. bei (o.a., 2010) 44

50 3.5 Logische Schicht: Code-Behind-Dateien 15 } Listing 3.13: ICommand wird von MyWorkCommand implementiert 1 using System ; 2 (...) 3 4 namespace SilverlightApplication1 5 { 6 public partial class MainPage : UserControl 7 { 8 // define command to bind in XAML 9 public ICommand DoSomeWorkCommand { get ; set ;} public MainPage () 12 { 13 // auto generated : required to initialize variables 14 InitializeComponent () ; 15 DoSomeWorkCommand = new MyWorkCommand () ; 16 // command is now ready for action 17 } } 20 } Listing 3.14: Der Command wird in der Code-Behind-Datei instanziert 1 < Button Content =" dosomework " Command ="{ Binding DoSomeWorkCommand }" / > Listing 3.15: Dem Button wird ein MyWorkerCommand zugewiesen Zunächst wird wie oben beschrieben das Interface ICommand durch den spezischen Command MyWorkerCommand implementiert. Die Execute-Methode beinhaltet Code für eine beliebige Funktionalität. In der Code-Behind-Datei der Anwendung wird der Command deniert, instanziert und durch den getter aus XAML via Data Binding (Kapitel 3.6) ansprechbar. Im Command-Atttribut des Buttons wird dann der Command mit der Schaltäche im XAML-Code verknüpft. Für den Button referenziert Silverlight automatisch IsEnabled an CanExecute des Commands. Für andere Controls muss dies explizit in XAML angegeben werden. Zu beachten ist hier, dass kein Event deniert ist, der die Aktion bzw. den Command auslöst Silverlight übernimmt diese Aufgabe. Eine weitere Beschreibung der Verwendung von Commands erfolgt im zweiten Teil dieser Bachelorarbeit. 45

51 3.6 Data Binding 3.6 Data Binding Eine Anwendung ohne grundlegende Daten ist sehr selten kaum eine kommt ohne sie aus. Silverlight stellt ein ausgereiftes Modell zur dynamischen Datenanbindung der logischen und visuellen Ebene zur Verfügung. Wie zuvor bereits beschrieben können in XAML gesetzte Attribute von Controls Werte entgegennehmen. Bisher waren dies (bis auf Listing 3.15) stets statische Daten wie einfache Strings (Text, Content), boolesche oder Zahlenwerte (Width, Margin). Für RIAs kann es erforderlich sein, auch komplexere Objekte (sog. Data Objects) und dynamische Werte (z.b. ein formatiertes Datum) an ein Element zu binden. Das Data Binding von Silverlight (und das noch mächtigere der WPF 14 ) ermöglichen es, eine (Dependency) Property eines Elements an den Wert einer anderen Property zu binden. Anders ausgedrückt ist Data Binding... (...) ein Prozess der Silverlight mitteilt, den Wert einer Property von einem Quellobjekt entgegen zu nehmen und diesen zu verwenden um die Property eins Zielobjekts zu setzen. (Vgl. MacDonald, 2009, S. 542) Das Konzept des Data Binding ist ein recht umfangreiches Thema, welches hier nur in seinen grundlegendsten Aspekten wiedergegeben werden kann. Auf Merkmale wie ValueConverter, DataTemplates, das Binding an LINQ-Ausdrücke oder an Resourcen, muss hier aus verständlichen Gründen verzichtet werden. In den folgenden Kapiteln wird das Data Binding anhand von simplen Beispielen veranschaulicht und teilweise im zweiten Teil der Arbeit vertieft Binding in XAML Das einfachste Binding ist das element to element Binding von in XAML denierten Controls. Auf diese Weise kann ein Element das Attribut eines anderen auslesen und übernehmen. So kann beispielsweise ein Slider-Control mit einer TextBox verknüpft werden, die die aktuelle Position des Schiebers als (Zahlen-)Wert wiedergibt. Listing 3.16 demonstriert das Vorgehen, indem ein solches Beispiel implementiert wird. 1 < Slider x:name =" mysider " Width =" 100 " Height =" 20 " Maximum =" 100 " Value =" 75 " / > 2 < TextBox Width =" 40 " Height =" 24 " Text ="{ Binding ElementName = myslider, Path = Value }" / > Listing 3.16: Data Binding zweier Elemente in XAML Die Schiebereglerposition des Sliders wird im Attribut Value festegelegt. Die TextBox bindet dynamisch an diesen Wert, indem für das Text-Attribut eine Bindinganweisung verwendet wird. 14 Z.B. untersützt Silverlight kein Binding zu ADO.NET DataSet-Klassen. 46

52 3.6 Data Binding Allgemein lautet die Syntax: {Binding <OPTIONS>}, wobei <OPTIONS> die Instanz eines eindeutig bezeichneten Objekts ist, oder über Parameter wie ElementName, Path, Converter, Mode, Source usw. das Binding genauer angepasst werden kann. Im Beispiel wird das XAML- Element mit dem Namen myslider gebunden; genauer dessen Value-Attribut. Startet man die Anwendung und bewegt den Slider, zeigt die TextBox stets die aktuelle Position an. Gibt man stattdessen dort einen Zahlenwert ein, verschiebt sich der Schieber nicht. Dieses Verhalten resultiert aus der standardmäÿigen Verwendung des Modus' OneWay-Binding. In Silverlight existieren drei Modi, die über den Mode-Paremeter der Bindinganweisung gesetzt werden können (MacDonald, 2009, S. 547). Abbildung 3.10 verdeutlicht den Zusammenhang modellhaft. Abb. 3.10: Silverlights Data Binding und Bindingsmodi (Quelle: nach Huber, 2008, S. 627)) OneWay Die Ziel-Property wird aktualisiert, wenn sich die Quell-Property ändert. TwoWay Sobald sich eine der beteiligten Properties ändert, wird auch die andere geändert. OneTime Die Ziel-Property wird bei der Erstellung einmalig, basierend auf dem Wert der Source-Property, gesetzt. Änderungen werden weiterhin nicht beachtet. Besteht andererseits die Anforderung, ein komplexeres Objekt (wie es durch Listing beschrieben wird 3.17, das exemplarisch einen Adressbucheintrag wiederspiegelt), an ein Element der Benutzeroberäche zu binden, kann wie folgt vorgegangen werden: 1 public class Person 2 { 3 public String Name { get ; set ;} 4 public int TelNumber { get ; set ;} 5 private long _ID ; 6 } Listing 3.17: Klassendenition eines Adressbucheintrages 47

53 3.6 Data Binding Die Klasse Person deniert zwei öentliche Attribute, auf welche mit gettern und settern zugegrien werden kann (ein Binding benötigt logischerweise public properties). In der Code- Behind-Datei wird die Klasse instanziert und mit einigen Werten versehen. 1 using System ; 2 (...) 3 4 namespace SilverlightApplication1 5 { 6 public partial class MainPage : UserControl 7 { 8 // define person to bind in XAML 9 public Person MyPerson { get ; set ;}; public MainPage () 12 { 13 // auto generated : required to initialize variables 14 InitializeComponent () ; 15 MyPerson = new Person () ; 16 MyPerson. Name = " Andreas "; 17 MyPerson. TelNumber = ; 18 } } 21 } Listing 3.18: Instanziierung und Veröentlichung eines Objekts in der Code-Behind-Datei Statt nun im XAML-Code wieder über die Bindingparameter ElementName und Path zu gehen, wird hier das DataContext-Attribut des hierarchisch übergeordneten Controls verwendet. 1 <Grid DataContext ="{ Binding MyPerson }" > 2 < TextBox Text ="{ Binding Name }" / > 3 < TextBox Text ="{ Binding TelNumber }" / > 4 </ Grid > Listing 3.19: XAML für ein Object-Binding Durch diese Anweisung erhalten alle Kindelemente des Grids Zugri auf das in DataContext denierte Objekt. Die beiden TextBoxes können direkt die öentlichen Attributwerte der Objektinstanz MyPerson lesen und setzen (vgl. die Implementierung des MainViewModel- Bindings in Teil Zwei der Arbeit). Um den Zugri auf ein anderes Objekt als es im DataContext angegeben wurde zu forcieren, können natürlich die o.g. Parameter (z.b. Path) verwendet werden Binding in der Anwendungslogik Ebenso wie in XAML lässt sich das Data Binding auch in der logischen Schicht mit prozeduralem Programmcode realisieren. Dies kann für die Fälle vorteilhaft sein, in denen der 48

54 3.6 Data Binding DataContext ebenfalls dynamisch ist und der jeweiligen Programmsituation angepasst werden soll. Silverlight stellt mit der Klasse Binding ein Instrument zur Verfügung, das Binden von Daten komplett über die Code-Behind-Dateien zu lösen, was aber selten die optimale Wahl ist, denn: die logische Schicht sollte möglichst wenig von der Oberäche wissen, um einem modularen, mehrschichtigen Programmaufbau treu zu bleiben. In den meisten Fällen genügt es, das in XAML mit einem Namen denierte Element in der Code-Behind-Datei anzusprechen, um dort objektorientiert das DataContext-Attribut neu zu setzen. Dennoch muss die funktionale Ebene das Data Binding in vielen Situationen unterstützen. So ist es z.b. äuÿerst wichtig, einen Benachrichtigungsmechanismus für gebundene Objekte zur Verfügung zu stellen, der die GUI auf Änderungen der Datengrundlage hinweist, sodass diese stets die aktuellsten Werte anzeigt und nicht statisch auf den Anfangswerten verharrt. Für diesen Zweck müssen gebundene Objekte, ihre Änderungen verkünden, indem das Interface INotifyPropertyChanged von diesen Klassen implementiert wird. 15 Dieser Vertrag deniert einen PropertyChangedEventHandler, welcher bei Änderungen gefeuert werden sollte. Normalerweise geschieht dies im setter der jeweiligen Property, direkt nach dem Setzen des neuen Wertes. Listing 7.3 auf S. 103 zeigt exemplarisch das Vorgehen für einen solchen Fall Datenvalidierung Das Data Binding von Silverlight reagiert auf ungültige Daten gleichgültig, indem diese ignoriert werden. Soll der Benutzer beispielsweise eine Zahlenreihe eingeben, tippt stattdessen aber auch (versehentlich) Buchstaben ein, so muss die Anwendung auf irgendeine Art darauf reagieren. Üblicherweise wird dem Benutzer ein zweckdienlicher Hinweis angezeigt, sodass er die Eingaben korrigieren kann. Alternativ kann auch ein interner Prozess gestartet werden, der versucht den Fehler zu beseitigen, indem etwa ein ausgereiftes Exception-Handling implementiert wird. Zum Zwecke der Datenvalidierung hat Silverlight ein einfaches System, welches erneut nicht so mächig ist wie das der WPF, aber dennoch eine stabile Fehlerbehandlung ermöglicht. Die Controls, die dieses Feature (ohne Zusatzarbeit) unterstützen sind TextBox, PasswordBox, CheckBox, RadioButton, ListBox und ComboBox (MacDonald, 2009, S. 549). Sie stellen den Binding Parameter ValidatesOnException zur Verfügung, der mit einem booleschen Wert belegt werden kann. Wird es true gesetzt, erhält das Control beim Auftauchen einer Exception (etwa ausgelöst im setter eines Property, bei falscher Dateneingabe) einen roten Rahmen mit 15 Einige höhere Klassen von Silverlight realisieren dieses bereits, so z.b. die ObservableCollection; jedoch nicht die weit verbreitete generische List. 49

55 3.7 Kommunikation mit dem Server einem Hinweis auf den Fehler (siehe Abbildung 3.11). Abb. 3.11: Geglückte und fehlgeschlagene Validierung Eine weitere Option ist der Parameter NotifyOnValidationError. Wird er auf true gesetzt, feuert Silverlight bei Validierungs-Fehlern automatisch den Event BindingValidationError, der dann wiederum in der Code-Behind-Datei aufgefangen oder verarbeitet werden kann. Zusätzlich steht dem Silverlightentwickler die Validation-Klasse zur Verfügung, welche die Fehler gesammelt und zusammengefasst anzeigt 3.7 Kommunikation mit dem Server Das Rückgrat einer jeden Rich Internet Application, sind die dahinter liegenden Data Services. Verwendet eine Silverlightanwendung ein oder mehrere Web Services, benden sich diese entweder auf dem gleichen Server wie die Host-Internetseite, oder das Programm erhält Daten von externen Anbietern und ihrer Services. Aus Sicherheitsgründen ist es Silverlightanwendungen zunächst nicht gestattet, Dienste anzufragen, die nicht vom eigenen Server angeboten werden (sog. cross-domain calls). Da dies den Betrieb einer Webanwendung extrem einschränkt, kann die Restriktion durch Anlegen einer XML-Datei namens clientaccesspolicy.xml, welche Richtlinien zum Umgang mit fremden Domains enthält, gesteuert werden. Fordert eine Silverlightanwendung Daten von einem Server an, wird zunächst im Root-Verzeichnis des angeforderten Servers nach diesem Dokument gesucht 16. Erlaubt der Server der Anwendung den Zugri nicht, oder existieren keine Richtliniendokumente, wird die Verbindung von Silverlight verweigert. Eine einfache clientaccespolicy.xml, welche keine Restriktionen setzt und HTTP-Anfragen von allen Domains zu allen eigenen Unterverzeichnissen erlaubt ist in Listing 3.20 beschrieben. Auf eine Erklärung der einzelnen Elemente einer solchen Datei soll hier verzichtet werden. 1 ï¾ <? xml version =" 1.0 " encoding ="utf -8 "? > 2 <access - policy > 3 <cross - domain - access > 4 < policy > 16 Ist clientaccesspolicy.xml nicht vorhanden, wird nach einer Datei crossdomain.xml gesucht, welche ursprünglich für Flash-Anwendungen entwickelt wurde und den gleichen Zweck erfüllt. 50

56 3.7 Kommunikation mit dem Server 5 <allow - from http - request - headers ="*" > 6 < domain uri ="*" / > 7 </ allow - from > 8 <grant - to > 9 < resource path ="/" include - subpaths =" true " / > 10 </ grant - to > 11 </ policy > 12 </ cross - domain - access > 13 </ access - policy > Listing 3.20: Eine simple clientaccesspolicy.xml (Quelle: nach Microsoft, 2010d) Benötigt man Daten von einem Server, der so den Zugri verbietet, bleibt als einzige Möglichkeit einen serverseitigen Proxy-Web Service zu implementieren. Dieser bendet sich auf dem gleichen Host wie die Anfragende Anwendung. Der Dienst agiert als eine Art Vertreter der Silverlightanwendung, der die Anfragen an den restriktiven Server weiterleitet. Da ein Web Service die cross-domain policy nicht beachtet, zudem auf einem (vermeintlich sicheren) Server läuft und nicht im Browser, wird die Anfrage vom Server beantwortet und Silverlight erhält die geforderten Daten über den Proxy-Service. Abbildung 3.12 zeigt zusammengefasst die möglichen Varianten einer cross-domain-anfrage. Abb. 3.12: Web Service-Anbindung in Silverlight (Quelle: nach MacDonald, 2009, S. 681) Die Verwendung eines Proxy-Dienstes ist aufgrund der zusätzlichen Zwischenstation v.a. aus Gründen der Leistungsfähigkeit für gröÿere Datenmengen problematisch. Auch die zusätzliche Zeit für die Implementierung und Verizierung des Services muss beachtet werden. Überwindet man die Hürde der cross-domain accessibility, besteht die einfachste Möglichkeit einen bestehenden Web Service in das Programm zu integrieren, über den von Visual Studio 51

57 3.8 Weitere Features angebotenen Assistenten. Gibt man dort die Adresse des Dienstes und einige weitere Optionen an, erzeugt die IDE automatisch die nötigen Verbindungsklassen zum Zugri auf den Service. Beispielsweise zeigt Listing 7.16 aus Teil zwei eine solche Anfrage an den Server über diese Referenzierungsklasse. Alternativ stellt Silverlight (bzw. das.net-framework) zahlreiche Bibliotheken und Klassen bereit, die Webanfragen durchführen und bearbeiten können; z.b. WebRequest, WebResponse, HttpContext etc. Dabei ist zu beachten, dass Serveranfragen von Silverlightanwendungen stets asynchron ablaufen. Das heiÿt: wird ein Dienst aufgerufen, blockiert das Programm nicht, indem es auf eine Antwort des Services wartet. Dazu wird ein Event auf das Completed- bzw. Error-Ereignis der Anfrage registriert, welcher nach erfolgreicher (oder fehlgeschlagener) Serverantwort gefeuert wird. Dort kann dann entsprechend reagiert und das Ergebnis verarbeitet werden. Eine detaillierte Implementierung und Beschreibung einer asynchronen Serviceverbindung wird im zweiten Teil gegeben. 3.8 Weitere Features Neben den bisher genannten Funktionen und Merkmalen soll hier nun kurz auf weitere erwähnenswerte Features von Silverlight 4 eingangen werden. Viele davon, sind vor allem für multimedialastige Anwendungen interessant, andere können auch gut im kommerziellen Umfeld zum Einsatz kommen. Merkmal out-of-browser trusted apps Beschreibung Eine Silverlightanwendung lässt sich auf Wunsch lokal auf dem Rechner des Nutzers installieren (Windows und Mac OS). Sie verhält sich danach nicht anders, als liefe sie im Browser ab. Das Programm wird in der gesicherten Umgebung der Sandbox installiert und ausgeführt und kann über eine Verknüpfung im Startmenü oder auf dem Desktop starten (äquivalent auf Mac). Zur Implementierung dieser Funktion sind nur wenige Zeilen notwendig. Benötigt eine Silverlightanwendung umfassendere Rechte als ihr normalerweise eingeräumt wird, kann sie durch den Benutzer als trusted application eingestuft werden, sodass diese beispielsweise mehr Speicherplatz innerhalb der Sandbox erhält, Zugri auf Teile des Dateisystems des Nutzers (Eigene Dateien) hat oder im Vollbildmodus Tastaturbefehle entgegennimmt. Ein solch höher priviligierte Anwendung ist ähnlich der Ausführung einer.exe-datei. 52

58 3.8 Weitere Features Merkmal Multimediafunktionen Druckfunktion Deep Zoom Controls des Silverlight Toolkit multithreading Beschreibung Es existieren Controls und Funktionen die eine Wiedergabe von (hochauösenden) Audio- und Videodaten ermöglichen und digitales Rechtemanagement (DRM) unterstützen. Seit Version 4 können auch Webcam, Mikrofon und erweiterte Eingabegeräte (Multitouch, Stylus) in einer Silverlightanwendung verwendet werden. Ebenfalls in Version 4 wurde eine lang erwartete Druckfunktion bereitgestellt, die es den Entwicklern ermöglicht individuelle Druckausgaben der Anwendung zu erstellen. Eine Funktion, die vor allem in multimedialastigen Anwendungen zum Einsatz kommen kann, ist Deep Zoom für Bildergalerien. Das besondere an der fertigen Galerie ist die Präsentationsform: der Benutzer kann mit Hilfe einer interaktiven Zoomfunktion die Bilder dynamisch verkleinert/vergröÿert betrachten, welche automatisch in der besten Auösung gerendert und ggf. vom Server nachgeladen werden. Ein Beispiel kann z.b. auf der Seite des Hard Rock Cafes 17 betrachtet werden. Die Silverlight Tools bzw. das optionale, die Entwicklung erweiternde Silverlight Toolkit und die Bibliotheken, welche mit Microsoft Expression Blend installiert werden, vergröÿern die Menge der Controls beachtlich. Darunter ist beispielsweise, eine ausgefeilte Darstellung von Graphen und Diagrammen, Funktionen für Drag and Drop, das aufklappbare Accordion, Controls für hierarchische Elemente (tree views) oder ein visuelles Ratingsystem (z.b. 1 bis 5 Sterne). Eine Übersicht dieser Komponenten ndet sich bei den Silverlight Toolkit Samples von Microsoft 18. Silverlight lässt (im Gegensatz zu anderen RIAs) parallele Prozesse auf der CPU zu und ermöglicht so die Implementierung von rechenintensiven Aufgaben. Unter der Haube nutzt Silverlight multithreading intensiv z.b. zum Durchführen von Animationen, Transformationen oder Übergängen. Das Plugin kann daher auch im Hinblick auf simple physikalische Simulationen, groÿe Datenmengen, Spieleprogrammierung, cloud computing oder dem semantischen Web (Web 3.0, (vgl. Schibrowski, 2007)) interessant sein, da threads optimiert und im Hintergrund ausgeführt werden können (vgl. Czernicki, 2008a,b)

59 3.9 Sicherheit Merkmal deep linking Lokalisierung Beschreibung Für den Laien ist es oft schwierig das Prinzip des Programms innerhalb eines anderen Programms (RIA im Browser) zu verstehen. Eine kleine Abhilfe verschat die Möglichkeit, die Silverlightanwendung mit Hilfe des Browsers zu steuern, d.h. zur Navigation die Vor- und Zurück-Buttons zu benutzen oder Hyperlinks auch auf Elemente innerhalb der RIA zu verweisen. Auf diese Weise wird ein vertrautes Konzept der Browsernutzung bewahrt (vgl. Pfeil, 2009, S. 40). Silverlight übernimmt weitgehend das Konzept der WPF zur Lokalisierung einer Anwendung für verschiedene Sprachen und Kulturen. 3.9 Sicherheit Grundlage eines sicheren Programms ist seine Aktualität durch regelmäÿige Updates. Das Silverlightplugin aktualisiert sich selbstständig; ebenfalls die damit entwickelten Anwendungen im Internet und als out-of-browser-application beim ersten Zugri auf eine neue Version. Dabei verbleiben nie Reste einer alten Version auf dem System - es existiert immer nur eine Version des Plugins oder Programms. Zur Installation des Silverlightplugins sind Administratorrechte notwendig. Eine Silverlightanwendung kann in drei verschieden Sicherheitsmodi ausgeführt werden. Standardmäÿig im Browser die Anwendung agiert als Teil einer Internetseite und unterliegt den gleichen Einschränkungen wie andere Webinhalte des Browsers. Out Of Browser: Sandboxed Vor der lokalen Installation wird eine Bestätigung des Nutzers eingefordert. Dieser Modus unterliegt den gleichen Einschränkungen der Sandbox wie Anwendungen, die innerhalb des Browsers laufen. Out Of Browser: Trusted Applications Die installierte Anwendung hat nach Nutzerbestätigung zusätzliche Rechte in einer ausgeweiteten Umgebung. Aus der Perspektive der Sicherheit hat eine solche Anwendung ähnliche Privilegien wie eine.exe-datei. Sie hat z.b. Zugri auf die Benutzerdokumente (Eigene Dateien o.ä.) und kann andere COM-Objekte aufrufen. Einer solchen Anwendung sollte nur insofern vertraut werden, wie man der ursprünglichen Herkunftswebseite vertraut. Die Einschränkungen bzw. Besonderheiten der Sandbox (ohne erhöhte Rechte) werden im 54

60 3.9 Sicherheit Folgenden kurz erläutert. OpenFileDialog/SaveFileDialog Silverlight kann Dateien auÿerhalb der Sandbox nur lesen oder schreiben, wenn der Nutzer diese durch einen expliziten Standard-Dateiauswahldialog bestätigt. Für gespeicherte Dateien vergibt das Plugin die Kennzeichnung, dass diese aus dem Internet stammen. Isolated Storage Silverlightanwendungen ist es erlaubt Daten in einem speziellen Bereich des Dateisystems abzulegen. Ähnlich wie bei Cookies hat jeweils nur die eigene Domain der RIA Zugri auf diesen Bereich, welcher ein Gröÿenlimit von 1 MB, nach Bestätigung durch den Benutzer bis zu 100 MB, hat. Vollbildmodus Soll die Anwendung den ganzen Bildschirm ausfüllen (randlos, ohne Fensteroder Startleiste), wird der Nutzer kurzzeitig mit Press ESC to exit full screen mode und der Adresse der Website benachrichtigt. Das Programm kann eine Beendigung des Vollbildmodus' nicht verhindern und währenddessen auch nicht auf Tastatureingaben (auÿer ESC) reagieren. Dies soll sog. spoong verhindern. In einer out-of-browser-anwendung mit normalen Fenster darf das Programm dessen Gröÿe und Position nur nach Bestätigung des Nutzers programmatisch ändern (als Mittel gegen click jacking attacks, wo das Fenster sich genau dort hinbewegt wo sich die Maus bendet). Manuell kann natürlich das Programm klassisch am Rahmen gepackt und verändert werden. Rechtsklick Wenn die Silverlightanwendung keine Events der rechten Maustaste auängt, zeigt das Plugin in jedem Fall einem Kontextmenü mit Einstellungen an. Dort kann der Nutzer die Pluginversion sehen und z.b. den Isolated Storage sowie verschiedene Berechtigungen der Anwendung verwalten. Wie in Kapitel 3.7 bereits beschrieben, werden Netzwerkzugrie des Silverlightplugins über policy les geregelt. Dieses Konzept kommt auch bei den out-of-browser-applications zum tragen und kann (auÿer bei trusted tpplications!) nicht umgangen werden. Zusätzlich zu HTTP(S) anfragen, erlaubt Silverlight die Verwendung von TCP und UDP sockets, welche in der clientaccesspolicy.xml speziziert werden müssen. Für Cross-Site-Scripting-Attacken (XSS), bei denen ein Angreifer versucht Code auszuführen, der vermeintlich vom Opfer selbst stammt, ist Silverlight weniger anfällig. Probleme durch XSS entstehen in traditioneller HTML-Entwicklung häug dadurch, dass bösartige Strings in Markup-Elemente injiziert werden und diese daraun ohne Validierung oder Escaping ausgeführt werden. Da XAML selten durch Kombination von einzelnen Strings, dynamisch in der Programmlogik aufgebaut wird, sind solche Attacken bei Silverlight recht ungebräuchlich. Z.B. würde ein Silverlightentwickler einen String im Programm anzeigen in dem er Zeile 1 statt eine Kombi- 55

61 3.10 Marktverbreitung nation wie in Zeile 2 aus Listing 3.21 verwendet. 1 textblock. Text = attackerstring ; 2 XamlReader. Load (" < TextBlock Text ='" + attackerstring + " '/>"); Listing 3.21: Sicherheitsrisiken durch Silverlight Im ersten Ansatz wird der String nicht geparsed oder ausgeführt, sondern nur im Textelement angezeigt. Die zweite Zeile zeigt eine Anfälligkeit für XSS bei der Verwendung von dynamisch geladenen XAML-Teilen. Aber auch die XAP-Dateien selbst sind nicht automatisch sicher. Da deren Adresse lesbar im HTML-Quelltext steht, können diese runtergeladen und der Inhalt durch Önen mit einem Komprimiertool betrachtet werden. Die darin enthaltenen DLLs, welche die clientseitige Logik der Silverlightanwendung kapseln, sind durch.net-obfuscators mit genügend Ausdauer für Angreifer decompilierbar, lesbar und beliebig veränderbar. Daher sollten darin keinesfalls sensitive Informationen wie Nutzernamen, Passwörter oder öentliche Schlüssel enthalten sein. Sicherheitsrelevante Programmlogik ist auf dem eigenen Server, in einem vertrauten Umfeld am besten aufgehoben und gehört nicht in clientseitigen Code. Silverlight bietet neben Bibliotheken zur Sicherung von Services über Netzwerke, auch Klassen zur Erhaltung der Integrität und Privatsphäre der Anwendung. HTTPS kann beispielsweise für XAP-Dateien an sich verwendet werden, oder auch für Serviceanfragen der RIA. Unter dem Namespace System.Security.Cryptography benden sich Klassen zur Verschlüsselung und für verschiedene Hashing-Verfahren (AES, SHA1, SHA256, HMAC Signaturen). (Vgl. Kramer, 2010; Esposito, 2008; Collins, 2009) Marktverbreitung Die Technologie der Rich Internet Applications steht noch relativ am Anfang der Entwicklung. Die folgenden Statistiken zeigen jedoch eine zunehmende Akzeptanz auf Anwenderseite über die letzten Jahre. Dies spiegelt sich auch durch steigende Zahlen der RIAs selbst wieder, denn ein Plugin wird erst dann vom Nutzer installiert, wenn es für eine Anwendung benötigt wird. Folgende Punkte sind auch in Zukunft treibende (Wachstums-)Kräfte der RIAs (Noda & Helwig, 2005) und tragen zu deren weiteren Verbreitung und Entwicklung bei: 1. Steigende Verfügbarkeit des Breitbandnetzes als infrastrukturelle Voraussetzung für inhaltlich gröÿere Webanwendungen. 2. Zunehmende Akzeptanz des Internets als Kommunikationsmedium 56

62 3.10 Marktverbreitung 3. Wachsende nutzbare Rechenleistung auch beim Endanwender (nicht nur auf Serverseite) ermöglichen die Verlagerung von technischen Resourcen auf die Seite des Nutzers. 4. Technische Vorteile, neue Entwurfsmuster und Modelle können hier konsequent zum Einsatz kommen und weitere Vorteile mit sich bringen, z.b. SOA, Web Services, XML, n-tier-architektur. 5. Bessere Möglichkeiten der Distribution von Software 6. Häug starke Benutzer(inter)aktivität gewünscht und z.t. auch für anspruchsvollere und komplexere Möglichkeiten der Nutzung von Software benötigt. (Diese soll und kann auch in Webanwendungen vorkommen.) 7. Kürzere Entwicklungszeiten und geringere Kosten durch leistungsfähige Entwicklungssoftware. 8. Viele Big Player ziehen bei der Entwicklung von RIA-Frameworks mit: Microsoft, Adobe, Java. 9. Potentiell mehr Kunden mit plattformunabhängigen, browserbasierten Anwendungen erreichbar. (Vgl. Pfeil, 2009, S.40) Abb. 3.13: Verfügbarkeit von RIA-Plugins (Statistik: nach StatOwl, 2010, Stand: Juni/Juli 2010) Es nicht verwunderlich, dass die alten Hasen, das RIA-Plugin Adobe Flash und Java, auf über 95% bzw. knapp 80% der Anwendersysteme, seit geraumer Zeit installiert sind. Vor allem 57

63 3.10 Marktverbreitung als Videoplayer und Werbeäche ist Flash von vielen Internetseiten nicht mehr wegzudenken. Die Java Laufzeitumgebung wird ebenfalls für einige wichtige Bedien- und Visualisierungsmerkmale von Internetseiten benötigt, sodass diese überwiegend zur Standardausstattung eines Internetnutzers gezählt werden kann. Die Statistiken (siehe Abbildungen 3.13 und 3.14) belegen auch, dass seit Veröentlichung Ende 2007, Silverlight eine stetig zunehmende Verbreitung und Akzeptanz ndet. Im Juni 2010 waren bereits über 50% der Anwendungsechner fähig, Silverlightprogramme auszuführen. Dabei fand die neuste Version 4 sehr schnell Verbreitung, denn es dauerte nur wenige Wochen bis Silverlight 3 von der aktuelleren Version überholt wurde. Hauptgrund dafür ist die automatische Updatefunktion, was auf eine regelmäÿige Nutzung von Silverlightanwendungen schlieÿen lässt. Anzumerken ist aber auch, dass mehr als ein Drittel aller Nutzer noch kein Plugin für Microsofts RIA installiert haben. Steigende Nutzerzahlen durch einen nach oben gerichteten Trend der Pluginverfügbarkeit deuten aber auf eine zukünftig positive Entwicklung hin. Hinweis Die Datenbasis beider statistischen Quellen beruht auf Besucherstatistiken von Internetseiten. Berücksichtigt wurden alle Betriebsysteme und Browser in verschiedenen Untersuchungszeiträumen. Riastats.com bewertet täglich durchschnittlich 14 Millionen Browserinformationen in einen Netzwerk von ca. 111 Internetseiten (unbekannter nationaler Herkunft) aus verschiedenen Themenbereichen. Die Datenerhebung umfasst einen Zeitraum von 30 Tagen im Juni/Juli StatOwl.com sammelt Daten von etwa 28 Millionen monatlichen Seitenbesuchen aus einem Netzwerk von überwiegend in den USA gehosteten Websites. Diese werden als e-commerce (ca. 32%), corporate (ca. 29%) und content-delivery (Blogs, Nachrichtenseiten, etc. ca. 20%) klassiziert. 19% der Seiten stammen aus sonstigen Bereichen. Zu beachten ist daher, dass die Zahlen je nach Datenquelle voneinander abweichen können und bloÿ eine grobe Tendenz angeben. 58

64 3.10 Marktverbreitung Abb. 3.14: Versionsverbreitung einzelner Frameworks (Statistik: nach Riastats, 2010, Stand: Juni/Juli 2010) 59

65 3.11 Zusammenfassung 3.11 Zusammenfassung Mit Silverlight hat Microsoft einen groÿen Schritt in den Markt der Rich Internet Applications gewagt und kann sich dort mit wachsender Fan- und Entwicklergemeinde behaupten. Das Framework ist in hohem Maÿe in die.net-umgebung integriert, versucht dabei aber weitgehend plattformunabhänig zu bleiben (sowohl für den Anwendungsprovider, als auch für den Endbenutzer). Die Plattform verspricht dynamische und exible Lösungen mit einem hohen Grad an Wiederverwendbarkeit einzelner Komponenten. Seit Version 3, spätestens jedoch mit Version 4 Anfang 2010, etabliert sich Microsoft Silverlight als Werkzeug zur Realisierung von interaktiven und komplexen Anwendungen, eingebettet in Standard-konforme Internetseiten und vertraute Umgebungen. Die Platorm macht es für Entwickler einfacher, reichhaltige, interaktive und in Netzwerke eingebundene Programme zu entwickeln. Obwohl es auch ohne Silverlight mit verschiedenen Werkzeugen des Webs möglich ist solche Applikationen zu realisieren, ist dort häug von Schwierigkeiten mit inkompatiblen Plattformen, Datenformaten, Browsern und Protokollen auszugehen. Eine interaktive Webanwendung, die perfekt auf einem System und Browser läuft, kann sich in anderen Umgebungen völlig anders verhalten oder komplett versagen. Unter Benutzung zahlreicher heutiger Tools, Protokolle und Technologien, ist es häug ein kostspieliges Bemühen, Anwendungen zu entwickeln, die gleichzeitig folgende Anforderungen erfüllen: Identisches Aussehen und Funktion auf allen Browsern und Systemen, sodass überall die Selbe user-experience erreicht wird. Integration von Daten und Services aus verschiedenen Netzwerken und Orten unter Zuhilfenahme vertrauter Techniken, Bibliotheken und Funktionen. Realisierbarkeit einer reichhaltigen, hoch-interaktiven, multimedial geprägten und gleichzeitig komfortabel zugänglichen Benutzeroberäche Silverlight macht es für Entwickler relativ einfach solche Anwendungen zu realisieren, denn das Framework überwindet viele Hindernisse der derzeitigen Technologien. Gleichzeitig stellt es eine Vielzahl an Werkzeugen und Methoden zur Verfügung, um solche Programme zu ermöglichen (Microsoft, 2010b). Gerade für, mit dem.net-framework vertraute, Entwickler kann Silverlight eine interessante weil auf bestehende Konzepte aufbauende Technik sein. Da das Plugin und die darin zu Grunde liegenden Konzepte aber weitgehend plattformunabhängig sind, bietet sich Silverlight für viele Bereiche clientseitiger Webanwendungen an. Das RIA-Framework von Microsoft bietet nicht nur eine Lösung für Anwendungen im Internet. Auch unternehmens-interne Intranet-Netzwerke können davon protieren, indem Softwa- 60

66 3.11 Zusammenfassung re dort verteilt und veröentlicht wird, anstatt aufwendig, lokal auf dem Arbeitsplatzrechner der Angestellten installiert zu werden. Auf diese Weise können Kosten sinken und Updates erreichen schnell und eektiv den Anwender. Es ist allerdings kritisch anzumerken, dass vor allem die Entwicklung unterstützende Werkzeuge (Expression Blend, WCF RIA Services) stark auf die.net-umgebung zentriert sind und wenig Spielraum für alternative Lösungen bieten. Zwar bemüht sich Microsoft auch konzernfremde Möglichkeiten zu unterstützen 19, jedoch ist eine aktive Zusammenarbeit nicht auszumachen. Obwohl die Entwicklung und Bereitstellung von Tools, Werkzeugen und Anwendungen in der Regel nicht mit zusätzlichen Restriktionen verbunden ist, bleibt Silverlight das Produkt eines kommerziellen Anbieters und wird daher nie völlig frei einsetzbar sein. Erreichen RIAs als potentielle Softwarepakete von und für kommerzielle Lösungen im Unternehmensbereich eine breitere Akzeptanz, werden diese zukünftig maÿgeblich die Softwarelandschaft verändern. Die dafür notwendigen Voraussetzungen eines leistungsfähigen Entwicklungsframeworks werden von Silverlight gröÿtenteils bereits erfüllt. 19 Microsoft kündigte an, keine Klagen patentrechtlicher Natur gegen das Mono-Project oder damit entwickelte Anwendungen einzureichen. 61

67 Teil II Konzeption und Realisierung der Beispielanwendung 62

68 Kapitel 4 Zum Grundverständnis der Anwendungsdomäne Dieser Teil behandelt den Entwurf einer hoch-interaktiven, line-of-business-ria mit IBM ILOG Gantt for.net im Rahmen einer SOA-Architektur. Es wird versucht, anhand der zuvor erarbeiteten Konzepte und technischen Grundlagen, eine reichhaltige Webanwendung zu planen und entwickeln. Die dazu nötigen Überlegungen werden in den folgenden Kapiteln erläutert. Die Software soll ein allgemeines Projektmanagement realisieren. Die zeitliche Planung, Verwaltung und Visualisierung von Projekten und deren Ressourcen durch sog. Gantt-Diagramme 1 wird durch die fertige Anwendung möglich sein. Eine nanzielle Seite der Projektplanung (Projektkosten) sowie dessen Aquisition werden hier auÿer Acht gelassen, da diese nicht zur Demonstration der in dieser Arbeit dargestellten Konzepte nötig sind. Der hier beschriebene Entwurf konzentriert sich auf die Kern-Prozesse und Dienste. Ein Gantt-Projekt muss im wesentlichen vier Elemente berücksichtigen: Aktivitäten, Beziehungen, Ressourcen und Ressourcenreservierungen. Komponente Aktivitäten (activities, tasks) Funktion Stellen die Aufgaben eines Projekts dar. Eine Aktivität wird anhand eines Zeitraums, beginnend ab einer Startzeit deniert und grasch durch einen Balken dargestellt. Aktivitäten können auch Meileinsteine eines Projektes sein und/oder als kritisch gekennzeichnet werden, falls die Aufgabe bestimmte Kriterien erfüllt.. 1 Benannt nach dem Unternehmensberater Henry L. Gantt ( ) 63

69 (cons- Komponente Beziehungen traints) Ressourcen Reservierungen Funktion Bedingungen legen Abhängigkeiten zwischen zwei Aktivitäten fest. Beispielsweise muss Aktivität A abgeschlossen sein, bevor Aktivität B begonnen werden darf. Die Darstellung der Beziehungen erfolgt durch die Aktivitätem verbindende Linien und Peile. Ressourcen repräsentieren Menschen, technisches Equipment oder beliebige andere Objekte, die zur Erfüllung der Aktivitäten benötigt werden. Diese bearbeiten und beenden Aktivitäten nach einem gewissen (oft von anderen Variablen abhängigen) Zeitraum und schlieÿen diese damit ab. Im Gantt- Diagramm kann an Stelle des Aktivitätsplans auch eine Übersicht zur Belastung der Ressourcen durch Aktivitäten erfolgen. Um Ressourcen mit Aktivitäten zu belegen werden Reservierungen verwendet. Eine Ressource kann dabei häug nur eine Aktivität gleichzeitig bearbeiten, während Aktivitäten durchaus von mehreren Ressourcen erfüllt werden können. Tab. 4.1: Hauptkomponenten eines Gantt-Diagramms Ein tabellarisches Gantt-Diagramm stellt die zeitliche Abfolge von Projektaktivitäten grasch (in Form von Balken auf einer Zeitachse) dar. Diese Teilaufgaben werden zeilenweise in der ersten Spalte aufgelistet. Rechts daneben folgt ein Kalender in dem die Aktivitäten zeitlich in Form eines waagerechten Balkens platziert sind. Die Länge des Balkens entspricht der benötigten Zeit zur Erfüllung dieser Aktivität. Abhängigkeiten zwischen den Aktivitäten werden durch sie verbindende Linien und Pfeile deutlich gemacht. Weitere Spalten enthalten z.b. textuelle Informationen wie Zeiträume (Start- und Enddatum der Aktivität) und benötigte menschliche bzw. technische Ressourcen. Damit das Projekt auch in der Realität umgesetzt werden kann, ist es nötig die Kapazitäten der Ressourcen (entstanden durch ihnen zugewiesene Aktivitäten) zu überwachen. Menschliche Kräfte sind beispielsweise nur zu regulären Arbeitszeiten (Wochentags von 9 bis 17 Uhr) verfügbar und können nicht zwei Aktivitäten gleichzeitig bearbeiten, während bei technischen Geräten (etwa Computeranlagen) auch Wartungszeiten eingeplant werden müssen. Die ressourcenbezogene Ansicht des Gantt-Diagramms dient somit auch der Überwachung des Arbeitseinsatzes und der Produktivität. Auf diese Weise können nicht nur personelle und technische Kapazitätsengstellen erkannt, sondern auch Leerlaufzeiten bzw. Unterlastungen verhindert und korrigiert werden. (Wegmann & Winkelbauer, 2006) 64

70 Aktivitäten und Ressourcen besitzen dabei durchaus auch eine hierarchische Struktur. Ebenso lassen sich einzelne Phasen des Projekts gruppiert zu einer groÿen Eltern-Aktivität zusammenfassen. Abbildungen 4.1 und 4.2 zeigen zwei einfache, exemplarische Gantt-Diagramme. Abb. 4.1: Ein einfaches Gantt-Diagramm mit kritischen Vorgängen. (Quelle: Wegmann & Winkelbauer, 2006, S. 108) Abb. 4.2: Personenspezisches Gantt-Diagramm für Wegmann. (Quelle: Wegmann & Winkelbauer, 2006, S. 117) 65

71 Kapitel 5 Funktionale und Nichtfunktionale Anforderungen In diesem Kapitel werden die qualitativen und quantitativen Eigenschaften der Beispielanwendung beschrieben. Die Anforderungen ergeben sich teilweise bereits aus der oben aufgeführten Erklärung der Gantt-Diagramme. Hauptaugenmerk der Anwendung ist es, eine visuelle Übersicht über das Projekt darzustellen, in der durch Beziehungen verknüpfte Aktivitäten, sowie deren Ressourcen editierbar sind. Die Anordnung der Elemente in der aktivitätsbezogenen Ansicht orientiert sich dabei stark an der klassischen Darstellung von Gantt-Diagrammen: eine zeilenweise Anordnung der Aufgaben (durch Balken visualisiert), welche entlang einer Zeitachse, je nach ihrer Anordnung und Dauer im Projektzeitplan, horizontal in Gröÿe und Position variabel sind. Klassizierbare Abhängigkeiten zwischen diesen sollen durch entsprechende Linien und Pfeile deutlich gemacht werden. Die ressourcenorientierte Darstellung erfolgt ähnlich der der Aktivitäten: die Ressourcen werden zeilenweise aufgelistet. Dahinter folgen jeweils die zugeordneten Aktivitäten in einem Kalender. Um die Darstellung übersichtlich zu halten, wird es daher notwendig sein die Ansicht zur Arbeitsbelastung der Ressourcen (die Kapazitätsplanung) von der Aktivitätsansicht zu trennen. Dazu muss ein Mechanismus bereitgestellt werden, der zwischen der Ressourcen bezogenen Ansicht und der Aktivitätsansicht wechselt. Ein Ziel dieser Arbeit ist es, das Praxisbeispiel unter Nutzung von Microsoft Silverlight und IBM ILOG Gantt for.net zu realisieren. Zu den Anforderungen gehören daher neben den oensichtlichen Grundfunktionen wie Projekteditierung und eine Speicherung der Daten auch daraus resultierende technische Funktionalitäten und Geschäftsprozesse, z.b. die Anbindung 66

72 an einen oder mehrere Web Service(s). Da die RIA über das Internet genutzt wird, werden an die Datenhaltung spezielle Ansprüche gestellt. Die Speicherung der Projektdaten kann sowohl lokal auf dem Rechner des Benutzers erfolgen als auch zentral auf einem Server, der von der Anwendung über Web Services erreicht wird. Da eine Gantt-Projektdatei nicht nur von der Rich Internet Application genutzt, sondern durchaus auch durch andere Software bearbeitet oder gelesen werden kann (z.b. Microsoft Project), ist es von Vorteil die Daten in einem XML-Format mit festem Schema abzulegen. Diese Exportierung ermöglicht eine standardisierte Verbreitung von Projekten an verschiedene Ziele. Näheres dazu in Kapitel 6.5. Das Programm hebt sich insbesondere durch eine erleichterte Benutzung mittels hoher Interaktivität der verschiedenen Elementen von klassischen Internetseiten ab, die nur schwer einen solchen Funktionsumfang bereitstellen können. Aus Desktop-Applikationen bekannte Funktionen wie ein Kontextmenü über die rechte Maustaste oder ein Verschieben von Aktivitätsbalken zur Veränderung von Start- bzw. Enddatum bereichern die Webanwendung und machen sie leicht zugänglich. Zur eigentlichen Editierung eines Projektes durch einen Benutzer müssen zumindest folgende, allgemeine Anwendungsfälle berücksichtigt werden, die im Use Case Diagramm aus Abbildung 5.1 dargestellt sind. Die drei dabei auftretenden Akteure sind der Benutzer, der ausführende Rechner der RIA und der zugehörige Web Server mit welchem die Anwendung in Verbindung steht. Neues Projekt erstellen führt zu einer leeren Projektdatei, die mit Elementen gefüllt und zur weiteren Bearbeitung gespeichert werden kann. Dieser Vorgang erfolgt zunächst nur lokal auf Nutzerseite. Die Editierung eines Projektes impliziert zuvor das Önen vorhandener Projektdaten 1. Dies kann über einen Dateiauswahldialog oder ähnliches geschehen. Soll lokal keine Datei geönet werden, wird ein Projekt über einen Web Service vom Server angefragt. Das Programm lädt die Projektdaten, bereitet sie für die Darstellung vor und zeigt sie wie oben beschrieben an. Die editierbaren Komponenten sind Aktivitäten, (evtl. zugeordnete) Ressourcen und deren Beziehungen zueinander, sowie alle damit implizierten Informationen (z.b. Startzeit, Dauer, Art und ggf. Bearbeitungsfortschritt der Aufgaben, Vorgänger- oder Nachfolgeaktivitäten, zusätzliche Anmerkungen). Sie werden überwiegend mit der Maus angepasst, in bestimmten Fällen ist jedoch eine Tastatureingabe vorzuziehen (z.b. bei der Benennung der Aktivitäten). Dazu werden verschiedene Dialogfelder angeboten, die die 1 Dazu sollte die angeforderte Datengrundlage für die Dauer der Bearbeitung für andere Benutzer gesperrt werden. 67

73 Abb. 5.1: Vereinfachtes Use Case Diagramm der wichtigsten Programmfunktionen jeweiligen Eigenschaften anpassen. Neben der Veränderung bestehender Elemente müssen auch neue hinzugefügt werden können - die RIA kontrolliert dabei die Korrektheit der Eingaben und erhält die Konsistenz der geänderten Projektdaten bevor etwa ein Projekt auf dem Server gespeichert wird. Da die Planung der Ressourcen und der Aktiviäten gleichzeitig in einer Ansicht unübersichtlich werden kann, soll der Benutzer die Möglichkeit haben zwischen der ressourcenbezogenen Ansicht (Kapazitätsplanung) und der Aktivitätsansicht zu wechseln. Damit einhergehend muss es möglich sein, den visuellen Projektbaum derart zu verschieben und dessen Gröÿe zu variieren, so dass der Benutzer optimal damit arbeiten kann. Der Prozess der Editierung an sich benötigt im einfachsten Fall keine Kommunikation mit einem Server, da die Änderungen zunächst lokal erfolgen. Persistierung: Nach Abschluss der Bearbeitung müssen die Änderungen am Projekt gespeichert werden 2. Verschiedene Exportierungsformate fördern dabei die System- und 2 Folgt man einem alternativen Ansatz, kann jede vom Benutzer getätigte Änderung auch direkt an den Server übertragen werden, anstatt das vollständige Projekt am Ende der Bearbeitung dort abzubilden. Vorteil dieser Variante ist, dass auch mehrere Nutzer gleichzeitig an einem Projekt arbeiten können und die Verände- 68

74 Programmunabhängigkeit. Aus Sicht der Geschäftsprozesse ist dies ein wichtiger Punkt, denn die Übertragung zum Server geschieht typischerweise über einen Web Service. Programmeinstellungen: Zur komfortableren Benutzung und Anpassung an die Bedürfnisse des jeweiligen Nutzers, lassen sich einige Aspekte der Bedienung bzw. des Aussehens der Anwendung verändern. Diese individuellen Optionen sollten zentral auf dem Server gespeichert werden, damit die Anpassungen von jedem beliebigem ausführenden Rechner bei Programmstart geladen werden können. Ein Benutzerprol beinhaltet dabei für alle im System registrierten Anwender die jeweils spezischen Einstellungen. Login/Logout zur An- bzw. Abmeldung eines Nutzers am System. Eine zusätzliche Anforderung ist auch die Folgende: Aktivitäten oder Aufgaben besitzen eine hierarchische Struktur um Parent-Child-Beziehungen wiederzugeben. Dies ist etwa dann nötig, wenn Aktivitäten zu einer Gruppe zusammengefasst werden müssen; beispielsweise für einzelne Projektphasen. Die Elemente des Gantt-Diagramms, also Aktivitäten, Beziehungen und ihre Ressourcen sollen durch den Benutzer leicht über Eingabemasken und interaktive Bedienelemente editierbar sein. Beispielsweise können die Dauer bzw. die Start- und Endzeit einer Aktivität durch ein Vergröÿern oder Ziehen am Aktivitätsbalken verändert werden. Alternativ lassen sich diese Werte auch in der zugehörigen Tabellenspalte oder in Dialogfenstern mit Tastatureingaben anpassen. Zur besseren Übersicht über die Aufgaben soll der Maÿstab der Zeitleiste variabel sein. Damit kann das Projekt in gewünschtem Detailgrad skaliert werden, um z.b. nicht nur den ungefähren Startzeitraum einer Aktivität innerhalb eines Monats, sondern auch die genaue Uhrzeit am Starttag sichtbar zu machen. Mögliche Benutzereinstellungen die ein Anwender vornehmen kann sind z.b. Automatisches Önen des Dialoges zur Editierung einer Aktivität oder Ressource, direkt nachdem eine neue Zeile dem Diagramm hinzugefügt wurde. Automatische Laden einer Beispieldatei nach Programmstart. Erlauben der Anpassung von Spaltengröÿen und -anordnung. Anzeige von Hilfslinien auf der Zeitachse für aktivitäts- oder ressourcenorientierte Ansichten. Anzeige von Tooltips während des Verschiebens einer Aktivität oder Ressource entlang der Zeitachse rungen direkt verfolgen können. Nachteil ist der hohe Bedarf an leistungsfähiger Kommunikationsinfrastruktur und eine stabile Datenverarbeitung. 69

75 ... Hinweis Einige der hier beschriebenen Anforderungen und Funktionen sind in der Implementierung der Beispielanwendung aus Zeitgründen nicht realisiert worden. Darunter fallen z.b. die Unterstützung für mehrere Benutzer und Rollen (Normalnutzer, Administrator) durch einen Login-Vorgang sowie das Exportieren der Projekte in unterschiedliche Dateiformate. Diese Funktionen tragen nicht zum grundlegenden Verständnis einer Service-orientierten RIA-Architektur bei. Es wurde jedoch bemüht, den Entwurf so zu gestalten, dass neue Merkmale der Software leicht integriert werden können. Des Weiteren entfällt eine detaillierte Beschreibung der serverseitigen Komponenten, da der Fokus dieser Arbeit auf der Rich Internet Application selbst liegt. 70

76 Kapitel 6 Entwurf Die Implementierung des Prototypen soll an einem praxisnahen Beispiel eine Service-orientierte, hoch-interaktive Rich Internet Application und deren Architektur vermitteln. Aus diesem Grund wurde das Projektmanagement auf die oben beschriebenen Grundfunktionen beschränkt und einige Vereinfachungen vorgenommen, um sich auf die wesentlichen Aspekte einer solchen RIA zu konzentrieren. Auÿerdem wurde auf die detaillierte Beschreibung der serverseitigen Services verzichtet. Der Prototyp konzentriert sich auf die Implementierung der Kernprozesse und -dienste und nicht auf die gesamte SOA-Architektur. Da Silverlight Teil des.net-frameworks ist, sind beim Entwurf der Anwendung auf die dortigen Funktionen, Möglichkeiten und Restriktionen zu achten. Als Programmiersprache soll C# verwendet werden. 6.1 IBM ILOG Gantt for.net Bevor mit dem Entwurf der Anwendung begonnen wird, ist hier nun eine kurze Übersicht über IBM ILOG Gantt for.net 4.0 gegeben, damit in Kapitel 6.5 die technischen Grundlagen des Datenmodells näher erläutert werden können. Auf eine detaillierte oder vollständige Beschreibung wird hier verzichtet, denn die Möglichkeiten die mit diesem Framework dargeboten werden sind sehr vielfältig. In den Kapiteln 6.5 und 7 wird näher auf einzelne verwendete Klassen des Frameworks eingegangen. Weitere Themen können z.b. in (IBM, 2009a) und (IBM, 2009c) nachgelesen werden. IBM ILOG Gantt for.net beherbergt Komponenten mit Visualisierungsmöglichkeiten für Gantt-Diagramme und eine umfassende Logik zu deren Steuerung und Anpassung. Die für die Silverlight-Plattform verwendbaren Klassen und Controls sind in Bezug auf Funktion und 71

77 6.1 IBM ILOG Gantt for.net Umfang zu denen der für WPF ebenfalls verfügbaren ILOG Gantt Version reduziert, bieten aber immer noch eine ausreichende Menge an Möglichkeiten. Beispielsweise steht der XML- Serialisierer für Gantt-Projektmodelle in Silverlight nicht zur Verfügung und muss in der Beispielanwendung manuell erstellt werden. Das Framework bietet viele Eigenschaften, Funktionen und Möglichkeiten, deren detaillierte Beschreibung nicht Ziel dieser Arbeit sein soll. Dennoch sind für dessen Verwendung einige Merkmale erwähnenswert, die im Folgenden erläutert werden. Abb. 6.1: Die Klassen der ChartControls Die Bibliotheken stellen u.a. die zwei wichtigen Controls GanttChart und ScheduleChart zur Verfügung, mit denen Gantt-Diagramme aktivitätsorientiert bzw. ressourcenorientiert dargestellt werden können. Die Klassen leiten von HierarchyChart ab, dessen Verwendung auf S. 101 beschrieben ist. Abbildung 6.1 zeigt die in den Klassen enthaltenen Properties und Methoden. Sie bieten z.b. Optionen zum Anpassen der Darstellung oder Events, die gefeuert werden sobald der Nutzer das Gantt-Diagramm editiert. Einige der Properties werden in den Folgenden Kapitel näher erläutert. Zur besseren Übersicht wurde das Klassendiagramm um 72

78 6.1 IBM ILOG Gantt for.net diverse, in diesem Kontext unwichtige Elemente reduziert. Die Visualisierung der beiden Diagramme orientiert sich dabei an den klassischen, oben beschriebenen, Vorstellungen vom Aussehen eines Gantt-Diagrammes. Die Charts sind modular aufgebaut und bestehen (visuell) aus den Komponenten Table, welche links zeilenweise Aktivitäts- oder Ressourceninformationen auisten und GanttSheet bzw. ResourceSheet, die rechts davon die zugehörigen Aktivitäts- oder Ressourcen-Balken entlang einer Zeitachse beinhalten. Bei ILOG Gantt for.net existieren zudem Klassen, welche die Entitäten aus den Anforderungen repräsentieren können. Dies sind beispielsweise SimpleActivity oder SimpleResource. Sie können grundlegende Attribute und Logik einer solchen Entität beinhalten (z.b. Name, StartTime, EndTime, Duration, Parent, ismilestone, etc.). Umfassendere Möglichkeiten der Projektplanung bieten jedoch die Scheduling-Klassen SchedulingActivity, SchedulingResource usw., welche unter Berücksichtigung eines Kalenders (z.b. WorkCalendar für gängige tägliche Arbeitszeiten) automatisch zeitlich angeordnet und für das Projekt optimiert werden können. Dieses Leveling der Entitäten lässt sich natürlich beeinussen. Beispielsweise wird der vollständige Zeitplan des Gesamtprojekts jedesmal erneut berechnet, falls sich die Dauer einer einzelnen Aufgabe verändert. ILOG kalkuliert die nötigen zeitlichen Veränderungen an anderen Aktivitäten automatisch und führt sie aus. Die Property Duration der SchedulingActivity-Klasse repräsentiert in diesem Zusammenhang die Arbeitszeit, welche benötigt wird, um die Aufgabe komplett zu beenden. Bei deren Berechnung wird der zu Grunde liegende Kalender, welcher Arbeits- und Freizeiten deniert, berücksichtigt. So kann es beispielsweise vorkommen, dass man eine dreistündige Aufgabe für Freitag, 15 Uhr ansetzt, die dann aber im Projektplan nicht um 18 Uhr am selben Tag endet, sondern erst am kommenden Montag (nach dem Wochenende) um 9 Uhr, da die Aktivität mit arbeitsfreien Zeiten überschneidet. Im Standard-Kalender hat jeder Arbeitstag (Montag bis Freitag) eine achtstündige Schicht von 8 bis 17 Uhr mit einer Mittagspause von 12 bis 13 Uhr. Abbildung 6.2 gibt eine Übersicht aller öentlichen Attribute der Scheduling Klassen von ILOG Gantt for.net. Die Funktion der Properties ist in den meisten Fällen bereits am Namen ersichtlich und soll daher i.a. hier nicht weiter erläutert werden. Die wichtigsten Attribute der SchedulingActivity-Klasse sind StartTime (die Startzeit der Aktivität, EndTime bzw. Duration (zum Festlegen einer Aufgabendauer), IsCritical, IsMilestone und IsSummary (zur teilweise durch ILOG selbst geregelten, automatischen Typisierung einer Aktivität) sowie das geerbte Parent-Attribut für Hierarchien. Eine Instanz vom Typ SchedulingResource beinhaltet u.a. eine Property für die Aktivitäten, 73

79 6.1 IBM ILOG Gantt for.net Abb. 6.2: Übersicht der Scheduling Klassen von ILOG Gantt 74

80 6.1 IBM ILOG Gantt for.net zu welchen sie mittels Reservierungen 1 zugeordnet wurde. Das bedeutet, dass jede Ressource des Projektes auch stets darüber Bescheid weiÿ, wo und wie sie im Projekt eingeplant wurde. Das ProjectSchedulingModel (siehe weiter unten) hält dabei die Informationen stets aktuell und konsistent. Die Klasse SchedulingConstraint repräsentiert eine Beziehung zwischen genau zwei SchedulingActivity-Instanzen. Diese werden in den Attributen FromActivity bzw. ToActivity referenziert, wobei der Typ der Relation durch einen enum-wert gesetzt wird. Eine SchedulingReservation spiegelt die Reservierung einer Ressource wider. Sie ist logischerweise nur dann gültig, wenn sowohl deren Property Activity, als auch Resource gesetzt wurden. Daneben ist leicht zu erkennen, dass sowohl Aktivitäten als auch Ressourcen von einer Klasse erben, die ein Parent-Attribut einer Activity deniert, sodass beide Klassen von hierarchischer Struktur sein können. Damit ist es möglich die in den Anforderungen benötigte Parent-Child- Beziehungen umzusetzen. Das Parent-Attribut nimmt in diesem Kontext eine Aktivität vom Typ SchedulingActivity entgegen. Ebenso erben alle hier beschriebenen Klassen von GanttData, welches das PropertyChanged- Event bereitstellt um beispielsweise Elemente der Benutzeroberäche auf Änderungen der Daten aufmerksam zu machen. Hinweis Entgegen der Beschreibung der SchedulingResource-Klasse in der Dokumentation von IBM ILOG Gantt for.net, war es nicht möglich eine hierarchische Beziehung zwischen Ressourcen herzustellen. Auch ein von IBM mitgeliefertes Beispielprogramm unterstützt dies nicht. Weiterhin sind im Diagramm verschiedene enum-typen dargestellt. Z.B. gibt ActivityConstraintType über die Art einer Beziehung zwischen zwei Aktivitäten Auskunft. Der ResourceType beschreibt eine Ressource näher und LagFormat deniert für das Leveling der Diagramme verwendete Werte. Diese Typen werden in der Praxisanwendung nicht explizit verwendet, weshalb eine genauere Beschreibung hier nicht nötig ist. Verwaltet werden diese Klassen und Funktionen im ProjectSchedulingModel, einer Klasse die die Entitäten und ihre Beziehungen zueinander beherbergt und verwaltet. Das Klassendiagramm ist in Abbildung 6.3 gegeben und zeigt öentlich zugängliche Elemente. Die Klasse berechnet die optimalen Zeitpläne und verwaltet das Projekt. Sie dient zudem als Grundlage für den Gantt- bzw. ScheduleChart und wird in der Silverlight Beispielanwen- 1 In diesem Kontext als ReadOnlyCollection, da Reservierungen vom ProjectSchedulingModel und nicht von den Ressourcen selbst verwaltet werden. 75

81 6.1 IBM ILOG Gantt for.net dung verwendet und an diese referenziert, sodass die Diagramme daraus erzeugt und visuell dargestellt werden können. Die wichtigsten Properties des ProjectSchedulingModels werden geerbt: die Listen Activities, Resources, Constraints und Reservations. Daneben bietet es einige Optionen zum Gantt-Diagramm, wie ein automatisches Berechnen der optimalen Aufgabenzeiten (AutomaticResourceLeveling vom Typ bool) oder ein Projektweit gültiges StartDate (Startdatum des Projekts), anhand dessen alle Aufgaben ausgerichtet werden. Mit den Methoden Begin- bzw. EndScheduleSession() sollen hier erwähnt werden, denn mit ihnen kann kurzzeitig das automatische Leveling der Aufgaben temporär unterbunden bzw. wieder gestartet werden, um beispielsweise manuell eine Aktivität zu editieren. Denn bei einem solchen Vorgang ist es wünschenswert, dass die endgültige Einpassung in das Gantt-Projekt erst dann vorgenommen wird, wenn die Aktivität auch wie gewünscht bearbeitet und festgelegt wurde. Ansonsten würde das ProjectScheduleModel ständig versuchen, die Aufgabe (mit möglicherweise unvollständigen Daten) passend im Diagramm unterzubringen. Ein weiteres Feature das das Framework mit sich bringt ist eine hohe Interaktivität der Controls: Komponenten wie Aufgaben, Ressource oder Beziehungen sind intuitiv mit der Maus veränder- und verschiebar. Die Ansicht des Projektplans lässt Abb. 6.3: Die ProjectSchedulingModel-Klasse sich bei gedrückter Maustaste bewegen, sodass der Nutzer navigieren und sich leicht orientieren kann. Zur Anpassung des Aussehens der Controls von IBM ILOG Gantt for.net bietet das Framework einerseits vorgefertigte Templates und Styles. Andererseits sind auch benutzerdeniert Möglichkeiten gegeben um die Ansicht des Projektplans visuell nach eigenen Wünschen zu verändern (z.b. Aussehen der Aktivitätsbalken, allgemeine Diagrammhintergründe, Darstellung der Beziehungen durch Pfeile, Spaltendenitionen, alternierende Zeilenhintergrundfarbe, Mauszeiger usw.). Eigene visuelle Anpassungen am Gantt-Diagramm werden in Kapitel beschrieben. Als Kritikpunkt zu diesem Framework ist anzumerken, dass bei gröÿeren Projekten die Leistungsfähigkeit der Anwendung leidet und manche Aktionen verzögert ausgeführt werden. Al- 76

82 6.2 Gesamtarchitektur: Das Model-View-ViewModel-Entwurfsmuster lerdings lieÿ sich nicht genau feststellen, ob dies an den zahlreich verwendeten Silverlight- Komponenten von ILOG Gantt liegt oder an den dortigen, zu Grunde liegenden Datenstrukturen. 6.2 Gesamtarchitektur: Das Model-View-ViewModel Entwurfsmuster Für eine Silverlightanwendungen bieten sich verschiedene, mehrschichtige Software- Entwurfsmuster an, die hier kurz vorgestellt werden. Gemeinsam ist allen ihre n-tier Architektur, sowie die Möglichkeit eine serverseitige Ebene hinzuzufügen, dabei jedoch möglichst eine lose Kopplung aller Schichten zu erhalten. 1. Das Model-View-Controller (MVC)-Muster verwendet drei voneinander getrennte Ebenen. Das Model kapselt Daten und interne Systemzugrie, die Ansicht (View) ist die Benutzeroberäche und der Controller ist die programmgesteuerte Schnittstelle zwischen Ansicht, Modell und Benutzereingabe, welche gegenseitige Zugrie steuert und reglementiert. Dieses Muster funktioniert jedoch für deklarative Benutzeroberächen wie bei Silverlight nicht optimal, da XAML ebenfalls einen Teil der Schnittstelle zwischen der Eingabe und der Ansicht denieren kann (da Datenbindung, Trigger und Zustände in XAML deklariert werden können). Es kommt zu einer nicht erwünschten Vermischung der Schichten. 2. Model-View-Presenter (MVP) ist ein anderes, häug verwendetes Muster, ähnlich des MVC. Im MVP-Muster ist jedoch der Presenter für das Festlegen und Verwalten des Zustands einer Ansicht verantwortlich. Genau wie MVC passt MVP nicht hundertprozentig zu Silverlight, da ebenfalls die deklarative Datenbindung von XAML, z.b. Trigger und Statusverwaltung enthalten könnte. 3. Das Model-View-ViewModel (MVVM) ist eine Anpassung des MVC- und MVP- Musters, welches aus deren Schwächen aber den Stärken von XAML (insbesondere des dortigen Data Binding-Konzepts) hervorgegangen ist. Die View ist eine Mischung aus XAML mit nur sehr geringen Anteilen an Code-Behind-Dateien und stellt reine ansichtspezische Logik, wie die Steuerung von Animationen oder Stylezuweisungen bereit. Das ViewModel liefert die zugehörige Steuerungslogik und bildet eine Brücke zum Model. Es ermöglicht der Ansicht (View), sich deklarativ an das ViewModel zu binden und so die bereitgestellten Komponenten zu nutzen. Das Model stellt wiederum die Daten dar und ist besonders wichtig, da es den Zugri auf die Daten umschlieÿt, und zwar unabhängig davon, ob der Zugri durch einen Satz von Webdiensten oder eine andere Form des 77

83 6.2 Gesamtarchitektur: Das Model-View-ViewModel-Entwurfsmuster Datenabrufs erfolgt. Es ist komplett vom ViewModel getrennt, sodass das Datenmodell, die View und das ViewModel jeweils isoliert von den anderen Ebenen getestet werden können. In der Praxis erlaubt das MVVM es, dass Designer kaum oder gar keinen Code schreiben müssen, um sich voll auf den Oberächenentwurf zu konzentrieren, während Programmierer für ViewModel und Model verantwortlich sind. Das MVVM geht auf Martin Fowler zurück, der 2004 erste Ansätze und Gedanken, damals unter dem Begri des Presentation Model, veröentlichte (Fowler, 2004). (Vgl. Wildermuth, 2009) Eine enge Kopplung zwischen den Schichten einer Anwendung entsteht, wenn eine Ebene Informationen darüber hat, wie eine andere ihre Arbeit ausführt. Müssen Anpassungen in einer Schicht gemacht werden, müsste in allen gekoppelten Ebenen die Änderung synchronisiert werden und sie hätte globale Auswirkungen. Dies ist vor allem dann kritisch, falls eine modulare und gekapselte Architektur erwünscht ist, die möglichst austauschbare oder wiederverwendbare Komponenten nutzen soll. Problematisch kann es ebenfalls sein, Komponententests auf den einzelnen Anwendungsschichten durchzuführen, um sie separat zu validieren. Diese Punkte sprechen für eine lose Kopplung, bei der die Ebenen nur über wenige Schnittstellen miteinander in Verbindung stehen. Das MVVM-Entwurfsmuster bietet sich daher als ideale Architektur für das Praxisbeispiel an. Abbildung 6.4 verdeutlicht das Model-View- ViewModel für Silverlight sowie die Beziehungen der Ebenen untereinander. Die View enthält überwiegend XAML-Code zur reinen Oberächenbeschreibung und wird nur geringfügig durch eine eigene Code-Behind-Datei im klassischen Sinne unterstützt. Spezi- sch für die einzelne View kann dort in den *.cs-dateien, Programmlogik zur Steuerung von visuellen Elementen der Oberäche implementiert werden. Wird das MVVM-Muster strikt befolgt, ndet sich dort kein Code, auÿer der vom Framework erzeugten Initialisierungslogik (z.b. InitializeComponent()). Das MVVM ist jedoch eine Richtlinie, keine zu befolgende Regel. So kann es im Einzelfall durchaus angebracht sein, in den Code-Behind-Dateien weitere Programmlogik anzugeben. Steuerung, Entgegennahme von Eingaben, Weitergabe der Daten, Validierung und die Eventbehandlung von Benutzeraktionen (und einigen Model-Ereignissen) übernimmt das ViewModel, welches lose über Silverlights Data Binding-Mechanismen an die Ansicht gebunden ist. Dazu werden im ViewModel öentliche Properties bereitgestellt, die (bei Bedarf) im XAML- Code der View referenziert werden. Auf diese Weise hat das ViewModel keine Kenntnisse über ansichtsspezische Merkmale, sodass eine beliebige View daran gebunden werden kann. Es stellt die Werte nur zur Verfügung, ohne zu wissen wer/was sie benutzt. Beispielsweise kann eine Hauptoberäche für Silverlight erstellt werden und zusätzlich eine WPF-basierte für andere Zwecke (z.b. Administration). 78

84 6.2 Gesamtarchitektur: Das Model-View-ViewModel-Entwurfsmuster Abb. 6.4: Das Model-View-ViewModel für Silverlight Möchte man die Anwendung um eine kompaktere, für mobile Endgeräte nutzbare (Windows Phone 7) Ansicht erweitern, benutzt man ebenfalls das selbe ViewModel und wählt daraus die benötigten Properties zur Anzeige der reduzierten Oberäche. Die Steuerungsebene ist also einerseits (nur) ein Bindeglied zwischen Oberäche und Daten, leistet aber andererseits die wichtige Aufgabe der Kontrolle und behält insgesamt den verwaltenden Überblick über die Anwendung, indem es dort Daten validiert und weiterleitet. Alle ViewModel-Klassen sollten so implementiert werden, dass sie auch ohne die View instanziiert und somit getestet werden können. (Thomas Claudius Huber, 2007). Anschaulich gesprochen hält das ViewModel alle Fäden zusammen und dirigiert das Zusammenspiel der einzelnen Akteure ähnlich dem Halten der Fäden eines Marionettenspielers. Das Model kapselt das zu Grunde liegende Datenmodell und stellt es für das ViewModel bereit. In diesem sind z.b. business objects und Schnittstellen für den Zugri auf Web Services enthalten. Ein das Model beschreibendes Interface hält dazu alle notwendigen Attribute, Methoden und Events fest und kann bei Bedarf für andere Implementierungen verwendet werden (z.b. Tests). Diese Schnittstelle wird vom ViewModel benutzt und bildet die Kommunikationsbasis zwischen den beiden Ebenen ohne dabei dem Aufrufer spezische Prozesskenntnisse zu vermitteln. 79

85 6.2 Gesamtarchitektur: Das Model-View-ViewModel-Entwurfsmuster Die im Interface denierten öentlichen Methoden geben jedoch keine Daten zurück denn sie sind mit der Signatur public void gekennzeichnet. Stattdessen lösen sie entsprechende Ereignisse für Erfolg oder Fehlschlagen des Prozesses aus, welche vom ViewModel abonniert werden. Die Resultate der Methoden sind in den übermittelten Parametern der Events enthalten (Event-Arguments) und so auf Empfängerseite erreichbar. Dieses Verhalten ermöglicht eine zeitlich versetzte Ausführung, um der Silverlight-Anforderung für asynchrone Netzwerkaktivität nachzukommen (siehe Abb. 6.8 und 6.9). Auch hier hat das Model also keinerlei Wissen, welche Komponenten auf die Events reagieren, sodass eine lose Kopplung auf beiden Seiten vorliegt. (Vgl. Wildermuth, 2009) Alternativ zur Weitergabe von Daten über die EventArgs kann auch in jeder Methode des Models, die vom ViewModel aufgerufen wird, die Instanz des ViewModels als Parameter übergeben werden. Anstatt die errechneten Daten über einen Event weiter zu reichen, können diese so direkt in das ViewModel geschrieben werden. Der Nachteil an dieser Lösung, ist die entstandene Bindung, da eine Instanz des ViewModels übermittelt wird und das Model damit über die Steuerungslogik Bescheid weiÿ. Kommt ein anderes ViewModel zum Einsatz muss das Model auch mit diesem umgehen können. Ein Nachteil des MVVM-Musters ist die wachsende Komplexität der Codestruktur, denn es ist deutlich mehr Quelltext zu entwerfen und schreiben als bei reinen Code-Behind-Dateien. Jede Aktion muss sorgfältig untersucht und auf die einzelnen Schichten verteilt werden. Gleichzeitig steigt jedoch das Abstraktionsniveau der Anwendung, indem die Komponenten leicht austauschbar sind und sich ggf. durch andere ergänzen lassen. Des Weiteren ist nicht gesichert, dass die Oberächendesigner (und Expression Blend) auch in Zukunft mit immer komplexeren Data Binding-Denitionen umzugehen wissen. Die Arbeitsteilung zwischen dieser Gruppe und den Programmierern der Logik kann daher in manchen Fällen nicht gewährleistet werden. Ebenfalls kritisch anzumerken ist eine Unterstützung und Kompatibilität des MVVM durch Controls von Drittherstellern, welche häug eigene Steuerungslogik kapseln anstatt sie, wie das Entwurfsmuster fordert, im ViewModel unterzubringen. (Thomas Claudius Huber, 2007) Anhand dieser Überlegungen zeigt Abbildung 6.5 die daraus resultierenden vier notwendigen Schichten des Praxisbeispiels. Die austauschbare View wird via Silverlights Data Binding an das ViewModel gebunden. Dieses steht wiederum über das Interface des Model (IModel) mit diesem in Verbindung, welches alle benötigten Daten bereitstellt und ggf. vom Server neue empfängt. Der Service-orientierte Ansatz einer Silverlightanwendung erlaubt dem Model die Verwendung von Web Services zur serverseitigen Datenbeschaung im Sinne einer SOA. Der Client ist dabei Konsument und löst die Anfrage aus. Wird die Antwort dann empfangen, muss sie in der 80

86 6.2 Gesamtarchitektur: Das Model-View-ViewModel-Entwurfsmuster Abb. 6.5: MVVM-Schichten der Beispielanwendung Regel erst, beispielsweise aus einem XML-Dokument heraus, in verwendbare Objekte umgewandelt und in das bestehende Datenmodell integriert werden. Das Model der Praxisanwendung erhält z.b. einen string mit XML-Struktur von einem datengetriebenen Service. Die Zeichenkette beinhaltet u.a. alle Aktivitäten, Ressourcen, Beziehungen und Reservierungen des angeforderten Gantt-Projekts (siehe Kapitel 7.1.1). Liegt ein bekanntes Schema des XML-Dokuments vor, werden daraus dann die einzelnen Entitäten herausgelesen und, umgewandelt als C#-Objekte, instanziert. Die ProjectSchedulingModel- Klasse, welche die Gantt-Diagrammdaten verwaltet, kann daraufhin mit den übermittelten Daten erstellt werden und das Projekt letztendlich den GanttCharts bzw. ChartControls zur Verfügung stellen. Abbildung 6.6 zeigt exemplarisch den stark vereinfachten Ablauf der Initialisierung eines Gantt-Projekts aus einer XML-Datei, welche von einer XML verarbeiteten Komponente gelesen bzw. geschrieben wird. Abb. 6.6: Vereinfachter Ablauf des Projektinitialisierungsprozesses Ein wichtiges Konzept, ohne das die Realisierung des MVVM mit Silverlight nur schwer umzusetzen ist, sind die Commands. In Code-Behind-Dateien werden normalerweise die von den Elementen der GUI gefeuerten Events behandelt und so auf (Benutzer-)Aktionen reagiert. Das neue Entwurfsmuster fordert nun dies aufzugeben, um die Trennung der Schichten nachzukommen. Da eine einfache Umleitung der Events in den Code-Behind-Dateien an andere 81

87 6.3 Komponenten der Anwendung Teile der Anwendung zwar möglich (wie bei o.a. (2010) beschrieben), aber weniger vorteilhaft wäre, bietet sich das Modell der Commands an. Mit diesen lässt sich Funktionalität abstrahieren, kapseln und dort unterbringen wo sie benötigt wird. Mit Hilfe der in den Interactivity-Namespaces (siehe S. 44) eingeführten EventTriggern können Commands an beliebige Events und Controls gebunden werden und sind nicht nur an Buttons oder HyperlinkButtons angewiesen. Die Commands, kann man leicht in die Ebene des ViewModel integrieren. Sollen andere ViewModels für ein Programm eingesetzt werden, sind in der Regel abweichende Aktionen und Funktionalitäten gewünscht, sodass die Commands nicht isoliert von diesem betrachtet werden müssen. Ein Command selbst erhält somit auch (indirekt über das ViewModel) Zugri auf das genutzte Model und auf die GUI, sodass alle benötigten Informationen erreichbar sind. 6.3 Komponenten der Anwendung Das Praxisbeispiel kann (unabhängig von den Schichten des MVVM) in einzelne Komponenten aufgeteilt werden, die sich im modellhaften Komponentendiagramm (Abbildung 6.7) wiedernden. Diese werden im Folgenden erläutert. Die dort nicht dargestellten Helferklassen und der ViewModelLocator sind für die Beschreibung der restlichen Komponenten und des MVVM nicht von groÿer Relevanz. Letztere Klasse wird vom MVVM Light Toolkit (S. 96 erzeugt und kann bei Bedarf mehrere ViewModels verwalten und bindet bzw. wählt das für die View passendste aus. Abb. 6.7: Komponentendiagramm der Anwendung 82

Web 2.0 Architekturen und Frameworks

Web 2.0 Architekturen und Frameworks Web 2.0 Architekturen und Frameworks codecentric GmbH Mirko Novakovic codecentric GmbH Quality Technische Qualitätssicherung in Software-Projekten mit Fokus auf Performance, Verfügbarkeit und Wartbarkeit

Mehr

Web 2.0 à la Microsoft Neuigkeiten aus der.net-welt - ein Überblick

Web 2.0 à la Microsoft Neuigkeiten aus der.net-welt - ein Überblick 1 Web 2.0 à la Microsoft Neuigkeiten aus der.net-welt - ein Überblick W3L AG info@w3l.de 2007 2 Inhaltsverzeichnis Was ist Web 2.0? Zusammenhänge Microsoft ASP.NET AJAX Silverlight zurück 3 Was ist Web

Mehr

Sicherheit in Rich Internet Applications

Sicherheit in Rich Internet Applications Sicherheit in Rich Internet Applications Florian Kelbert 14.02.2008 Seite 2 Sicherheit in Rich Internet Applications Florian Kelbert 14.02.2008 Inhaltsverzeichnis Grundlagen Ajax und Mashups Adobe Flash-Player

Mehr

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

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

Mehr

Entwicklung und Integration mobiler Anwendungen. Oracle Deutschland B.V. & Co. KG

Entwicklung und Integration mobiler Anwendungen. <Speaker> Oracle Deutschland B.V. & Co. KG Entwicklung und Integration mobiler Anwendungen Oracle Deutschland B.V. & Co. KG Global Users (Millions) Der Trend ist eindeutig. Trend zu mobilen Endgeräten Wachstum des mobilen Datenverkehrs

Mehr

Apollo Überblick. Klaus Kurz. Manager Business Development. 2007 Adobe Systems Incorporated. All Rights Reserved.

Apollo Überblick. Klaus Kurz. Manager Business Development. 2007 Adobe Systems Incorporated. All Rights Reserved. Apollo Überblick Klaus Kurz Manager Business Development 1 Was ist Apollo? Apollo ist der Codename für eine plattformunabhängige Laufzeitumgebung, entwickelt von Adobe, die es Entwicklern ermöglicht ihre

Mehr

Agenda. Ingo Ebel (ie007) Benjamin Müller (bm032) Was ist AJAX? Sicherheit Vor- und Nachteile. AJAX Frameworks. Wozu benötigt Client/Server

Agenda. Ingo Ebel (ie007) Benjamin Müller (bm032) Was ist AJAX? Sicherheit Vor- und Nachteile. AJAX Frameworks. Wozu benötigt Client/Server AJAX Agenda Ingo Ebel (ie007) Was ist AJAX? Wozu benötigt Client/Server Sicherheit Vor- und Nachteile Benjamin Müller (bm032) AJAX Frameworks GWT ATF Ingo Ebel - ie007 2 Web 2.0 Ingo Ebel - ie007 3 Ingo

Mehr

Web Service Entwicklung mit Java. Sven Lindow

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

Mehr

Basistechnologien: Web-Services

Basistechnologien: Web-Services Alexander Rudolf Cloud-Computing Seminar Hochschule Mannheim WS0910 1/29 Basistechnologien: Web-Services Alexander Rudolf Hochschule Mannheim Fakultät für Informatik alexander.rudolf@stud.hs-mannheim.de

Mehr

Eine Taxonomie und Bewertung von Cloud Computing Diensten aus Entwicklersicht

Eine Taxonomie und Bewertung von Cloud Computing Diensten aus Entwicklersicht Eine Taxonomie und Bewertung von Cloud Computing Diensten aus Entwicklersicht Universität der Bundeswehr München Mario Golling und Michael Kretzschmar Fakultät für Informatik E-Mail: mario.golling@unibw.de

Mehr

Software Engineering II (IB) Serviceorientierte Architektur

Software Engineering II (IB) Serviceorientierte Architektur Serviceorientierte Architektur Prof. Dr. Oliver Braun Fakultät für Informatik und Mathematik Hochschule München SS 2015 Webservices Ziel: flexible programmatische Zusammenarbeit zwischen Servern Bereitstellung

Mehr

Rechnernetze Projekt SS 2015

Rechnernetze Projekt SS 2015 30/03/15 Seite 1 Aspektorientierte Programmierung logische Aspekte (Concerns) im Programm separieren Crosscutting Concerns (Ziel: generische Funktionalitäten über mehrere Klassen hinweg zu verwenden -

Mehr

Datenbank-basierte Webserver

Datenbank-basierte Webserver Datenbank-basierte Webserver Datenbank-Funktion steht im Vordergrund Web-Schnittstelle für Eingabe, Wartung oder Ausgabe von Daten Datenbank läuft im Hintergrund und liefert Daten für bestimmte Seiten

Mehr

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

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

Mehr

Client/Server-Systeme

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

Mehr

1. Software-Plattform Android Android. Was ist Android? Bibliotheken, Laufzeitumgebung, Application Framework

1. Software-Plattform Android Android. Was ist Android? Bibliotheken, Laufzeitumgebung, Application Framework 1. Software-Plattform Android Android Was ist Android? Plattform und Betriebssystem für mobile Geräte (Smartphones, Mobiltelefone, Netbooks), Open-Source Linux-Kernel 2.6 Managed Code, Angepasste Java

Mehr

TM1 mobile intelligence

TM1 mobile intelligence TM1 mobile intelligence TM1mobile ist eine hochportable, mobile Plattform State of the Art, realisiert als Mobile BI-Plug-In für IBM Cognos TM1 und konzipiert als Framework für die Realisierung anspruchsvoller

Mehr

Lastenheft. Zielbestimmungen. Produkteinsatz. swp11-4. 3. Mai 2011. Franz Teichmann, Robert Röÿling swp11-4 3. Mai 2011

Lastenheft. Zielbestimmungen. Produkteinsatz. swp11-4. 3. Mai 2011. Franz Teichmann, Robert Röÿling swp11-4 3. Mai 2011 Lastenheft swp11-4 3. Mai 2011 Zielbestimmungen In der heutigen Geschäftswelt stehen mittelständische Unternehmen vor dem Dilemma, einerseits interne und externe Kommunikation in angemessener Weise gewährleisten

Mehr

09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten

09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten Aktuelle Themen der Wirtschaftsinformatik Zusammenfassung 09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten 1 Serverseitige Webprogrammierung

Mehr

Bin ich fit für myconvento?

Bin ich fit für myconvento? Bin ich fit für myconvento? Sie planen den Einsatz unserer innovativen Kommunikationslösung myconvento und fragen sich gerade, ob Ihr Rechner die Anforderungen erfüllt? Hier erfahren Sie mehr. Inhalt Was

Mehr

.NET-Objekte einfach speichern Michael Braam, Senior Sales Engineer InterSystems GmbH

.NET-Objekte einfach speichern Michael Braam, Senior Sales Engineer InterSystems GmbH Make Applications Faster.NET-Objekte einfach speichern Michael Braam, Senior Sales Engineer InterSystems GmbH Agenda Vorstellung InterSystems Überblick Caché Live Demo InterSystems auf einen Blick 100.000

Mehr

Web und Mobile Apps Programmieren mit Dart

Web und Mobile Apps Programmieren mit Dart Web und Mobile Apps Programmieren mit Dart Marco Jakob Kalaidos Fachhochschule Schweiz majakob@gmx.ch Abstract: Bisher war es kaum realistisch, im Anfängerunterricht mobile oder webbasierte Applikationen

Mehr

A Generic Database Web Service for the Venice Lightweight Service Grid

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

Mehr

Byte-Taxi. Bedienungsanleitung. Seite 1 von 8

Byte-Taxi. Bedienungsanleitung. Seite 1 von 8 Byte-Taxi Bedienungsanleitung Seite 1 von 8 Inhaltsverzeichnis 1. Beschreibung 3 2. Systemvoraussetzungen 4 3. Installationsanleitung 5 4. Bedienung 6 5. Infos & Kontakt 8 Seite 2 von 8 1. Beschreibung

Mehr

Cross-Platform Apps mit HTML5/JS/CSS/PhoneGap

Cross-Platform Apps mit HTML5/JS/CSS/PhoneGap Cross-Platform Apps mit HTML5/JS/CSS/PhoneGap Proseminar Objektorientiertes Programmieren mit.net und C# Florian Schulz Institut für Informatik Software & Systems Engineering Einführung Was hat Cross-Plattform

Mehr

3 Anwendungsarchitektur und Entwicklungsumgebung

3 Anwendungsarchitektur und Entwicklungsumgebung 21 3 Anwendungsarchitektur und Bei den Entwicklern von Web-basierten Dialogsystemen hat sich im Laufe der Zeit eine Vorgehensweise im Design von Anwendungen entwickelt, dies es ermöglicht, flexible Web-Dialoge

Mehr

Openlaszlo. Rich Internet Application Platform

Openlaszlo. Rich Internet Application Platform Rich Internet Application Platform ist eine Anwendungsplattform open source zero install Software Amazon Shopping in einem RIA Beispiel Ubiquitous Internet Wie kommts? 60 Prozent der Deutschen online Anwendungen

Mehr

Web Services: Inhalt

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

Mehr

Das Interceptor Muster

Das Interceptor Muster Das Interceptor Muster Implementierung des Interceptor Musters basierend auf OSGi and Friends Benjamin Friedrich Hochschule für Technik und Wirtschaft des Saarlandes Praktische Informatik - Entwurfsmuster

Mehr

Web Services and Semantic Web - Introduction to Web Services. von Andreas Weiler

Web Services and Semantic Web - Introduction to Web Services. von Andreas Weiler Web Services and Semantic Web - Introduction to Web Services von Andreas Weiler Definitionen Beispiele Technologien Vorteile Kritik Abschlussbeurteilung Fragen? Definition von IBM: Web services are a new

Mehr

Integrating Architecture Apps for the Enterprise

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

Mehr

VS12 Slide 1. Verteilte Systeme. Vorlesung 12 Sebastian Iwanowski FH Wedel

VS12 Slide 1. Verteilte Systeme. Vorlesung 12 Sebastian Iwanowski FH Wedel VS12 Slide 1 Verteilte Systeme Vorlesung 12 Sebastian Iwanowski FH Wedel Mögliche Plattformen für Web Services VS12 Slide 2 VS12 Slide 3 Java-Software für verteilte Systeme J2EE: Java 2 Enterprise Edition

Mehr

360.NET. Jan Schenk Developer Evangelist Web/Live Microsoft Deutschland

360.NET. Jan Schenk Developer Evangelist Web/Live Microsoft Deutschland 360.NET Jan Schenk Developer Evangelist Web/Live Microsoft Deutschland Was ist.net? Eine Strategie Eine Plattform Eine Laufzeitumgebung Eine Software-Sammlung Ein Set von Services Warum so ein Framework?

Mehr

Einsatz von Applikationsservern. Untersucht am Beispiel des Sybase Enterprise Application Server

Einsatz von Applikationsservern. Untersucht am Beispiel des Sybase Enterprise Application Server Einsatz von Applikationsservern Untersucht am Beispiel des Sybase Enterprise Application Server Architektur von Datenbanksystemen Client / Server Modell (2 Schichten Modell) Benutzerschnittstelle Präsentationslogik

Mehr

Visual Studio LightSwitch 2011

Visual Studio LightSwitch 2011 1 Visual Studio LightSwitch 2011 Vereinfachte Softwareentwicklung im Eiltempo W3L AG info@w3l.de 2012 2 Agenda Motivation Softwareentwicklung im Eiltempo Was ist LightSwitch? Merkmale Zielgruppe LightSwitch

Mehr

Inhalt. 1 Übersicht. 2 Anwendungsbeispiele. 3 Einsatzgebiete. 4 Systemanforderungen. 5 Lizenzierung. 6 Installation.

Inhalt. 1 Übersicht. 2 Anwendungsbeispiele. 3 Einsatzgebiete. 4 Systemanforderungen. 5 Lizenzierung. 6 Installation. Inhalt 1 Übersicht 2 Anwendungsbeispiele 3 Einsatzgebiete 4 Systemanforderungen 5 Lizenzierung 6 Installation 7 Key Features 8 Funktionsübersicht (Auszug) 1 Übersicht MIK.bis.webedition ist die Umsetzung

Mehr

Version 4.4. security.manager. Systemvoraussetzungen

Version 4.4. security.manager. Systemvoraussetzungen Version 4.4 security.manager Systemvoraussetzungen Version 4.4 Urheberschutz Der rechtmäßige Erwerb der con terra Softwareprodukte und der zugehörigen Dokumente berechtigt den Lizenznehmer zur Nutzung

Mehr

Entwicklung von Web-Anwendungen auf JAVA EE Basis

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

Mehr

JavaScript Frameworks für Mobile

JavaScript Frameworks für Mobile JavaScript Frameworks für Mobile MoBI Expertenrunde Usability, 1. März 2012 doctima GmbH JavaScript Frameworks für Mobile MoBI 1.3.2012 Edgar Hellfritsch Inhalt Native App-Entwicklung Klassische Web-Entwicklung

Mehr

Business Process Execution Language. Christian Vollmer Oliver Garbe

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

Mehr

.NET und wieder eine Middleware Architektur?

.NET und wieder eine Middleware Architektur? .NET und wieder eine Middleware Architektur? Volker Birk CCC ERFA Ulm vb@ebios.de Volker Birk, vb@ebios.de 1 .NET na und?.net soll die Architektur im Internet werden meint Microsoft. Genau so wie Windows?.NET

Mehr

Inhalt. 1 Übersicht. 2 Anwendungsbeispiele. 3 Einsatzgebiete. 4 Systemanforderungen. 5 Lizenzierung. 6 Installation.

Inhalt. 1 Übersicht. 2 Anwendungsbeispiele. 3 Einsatzgebiete. 4 Systemanforderungen. 5 Lizenzierung. 6 Installation. Inhalt 1 Übersicht 2 Anwendungsbeispiele 3 Einsatzgebiete 4 Systemanforderungen 5 Lizenzierung 6 Installation 7 Key Features 8 Funktionsübersicht (Auszug) Seite 2 von 14 1. Übersicht MIK.starlight bietet

Mehr

Softwareentwicklung mit Enterprise JAVA Beans

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

Mehr

Vorwort... 11 Azure Cloud Computing mit Microsoft... 12 Danksagungen... 13 Kontakt zum Autor... 13

Vorwort... 11 Azure Cloud Computing mit Microsoft... 12 Danksagungen... 13 Kontakt zum Autor... 13 Inhaltsverzeichnis Vorwort... 11 Azure Cloud Computing mit Microsoft... 12 Danksagungen... 13 Kontakt zum Autor... 13 Einleitung... 15 Zielgruppe... 16 Aufbau... 16 Inhalt der einzelnen Kapitel... 17 Systemanforderungen...

Mehr

IT-Sicherheit mobiler Applikationen zur Unterstützung von Geschäftsprozessen. Bachelorarbeit

IT-Sicherheit mobiler Applikationen zur Unterstützung von Geschäftsprozessen. Bachelorarbeit IT-Sicherheit mobiler Applikationen zur Unterstützung von Geschäftsprozessen Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftswissenschaft der

Mehr

SOA mit.net: Vom Geschäftsprozess zur Lösung

SOA mit.net: Vom Geschäftsprozess zur Lösung SOA mit.net: Vom Geschäftsprozess zur Lösung Manfred Steyer Aktuelles Buch.Net 4.0 Update ISBN 978-3866454439 http://tinyurl.com/net4update 1 Kontakt [www] www.softwarearchitekt.at [mail] Manfred.Steyer@SoftwareArchitekt.at

Mehr

Die nächste Revolution in der modelgetriebenen Entwicklung?

Die nächste Revolution in der modelgetriebenen Entwicklung? Die nächste Revolution in der modelgetriebenen Entwicklung? Me Johannes Kleiber Software Engineer bei FMC Johannes.Kleiber@fmc-ag.com Themen Überblick Window Workflow Foundation Workflows modellieren WF

Mehr

Workflow, Business Process Management, 4.Teil

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

Mehr

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java

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

Mehr

Hochschule Darmstadt Fachbereich Informatik

Hochschule Darmstadt Fachbereich Informatik Hochschule Darmstadt Fachbereich Informatik 6.3 Systemarchitektur 430 6.3 Systemarchitektur Drei Schichten Architektur Die "Standardtechniken" des Software-Engineering sind auch auf die Architektur einer

Mehr

Professionelles CMS mit ZOPE und ZMS. Niels Dettenbach - www.syndicat.com. Content Management mit ZMS

Professionelles CMS mit ZOPE und ZMS. Niels Dettenbach - www.syndicat.com. Content Management mit ZMS Professionelles CMS mit ZOPE und ZMS Niels Dettenbach - www.syndicat.com Content Management mit ZMS Was ist professionelles CMS? (1/2) strikte Trennung von Inhalt (Content) und Layout / Design hält sich

Mehr

1 Installationen. 1.1 Installationen unter Windows

1 Installationen. 1.1 Installationen unter Windows 1 Installationen Dieses Kapitel beschreibt die Installationen, die für die Nutzung von PHP und MySQL unter Windows, unter Ubuntu Linux und auf einem Mac mit OS X notwendig sind. 1.1 Installationen unter

Mehr

Inhaltsverzeichnis .NET 3.5. WPF, WCF, LINQ, C# 2008, VB 2008 und ASP.NET AJAX. Herausgegeben von Holger Schwichtenberg ISBN: 978-3-446-41045-9

Inhaltsverzeichnis .NET 3.5. WPF, WCF, LINQ, C# 2008, VB 2008 und ASP.NET AJAX. Herausgegeben von Holger Schwichtenberg ISBN: 978-3-446-41045-9 sverzeichnis Walter Doberenz, Matthias Fischer, Jana Frank, Thomas Gewinnus, Jörg Krause, Patrick A. Lorenz, Jörg Neumann, Holger Schwichtenberg.NET 3.5 WPF, WCF, LINQ, C# 2008, VB 2008 und ASP.NET AJAX

Mehr

Smartphone Entwicklung mit Android und Java

Smartphone Entwicklung mit Android und Java Smartphone Entwicklung mit Android und Java predic8 GmbH Moltkestr. 40 53173 Bonn Tel: (0228)5552576-0 www.predic8.de info@predic8.de Was ist Android Offene Plattform für mobile Geräte Software Kompletter

Mehr

Geschäftsbereich Mobile Services Was ist Android?

Geschäftsbereich Mobile Services Was ist Android? Geschäftsbereich Mobile Services Was ist Android? Hinter Hoben 149 53129 Bonn www.visionera.de Ansprechpartner: Arno Becker arno.becker@visionera.de +49 228 555 1111 +49 160 98965856 Einleitung Android

Mehr

NEWpixi* API und die Umstellung auf REST. Freitag, 3. Mai 13

NEWpixi* API und die Umstellung auf REST. Freitag, 3. Mai 13 NEWpixi* API und die Umstellung auf REST Fakten NEWpixi* API Technik REST-basierend.NET Webservice IIS Webserver Release 31. August 2013, zusammen mit dem NEWpixi* ELI Release Legacy API und erste NEWpixi*

Mehr

Implementierung von Geschäftsprozessen in der Verwaltung mit Hilfe von SOA

Implementierung von Geschäftsprozessen in der Verwaltung mit Hilfe von SOA E-Gov Fokus Geschäftsprozesse und SOA 31. August 2007 Implementierung von Geschäftsprozessen in der Verwaltung mit Hilfe von SOA Im Vortrag werden die Vor- und Nachteile von Geschäftsprozessen in der öffentlichen

Mehr

- Entwurfsphase: Entwurfsbeschreibung Gesamtsystem - Version: 1.0

- Entwurfsphase: Entwurfsbeschreibung Gesamtsystem - Version: 1.0 Projektbezeichnung Projektleiter Verantwortlich - Entwurfsphase: Entwurfsbeschreibung Gesamtsystem - Version: 1.0 MSP-13 - Integration eines Semantischen Tagging Systems in Microsoft Sharepoint Martin

Mehr

Inhaltsverzeichnis. Teil 1 Node.js... 1

Inhaltsverzeichnis. Teil 1 Node.js... 1 xiii Teil 1 Node.js... 1 1 Was ist Node.js? 3 1.1 Die Zeitalter des Webs................................... 3 1.1.1 1990 bis 2000: Das Web 1.0....................... 3 1.1.2 2000 bis 2010: Das Web 2.0.......................

Mehr

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

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

Mehr

Inhaltsverzeichnis. Enterprise Java im Überblick. Technologien der Java2 Enterprise Edition

Inhaltsverzeichnis. Enterprise Java im Überblick. Technologien der Java2 Enterprise Edition Inhaltsverzeichnis Vorwort 13 I Enterprise Java im Überblick 1 Bedeutung von Enterprise Java und IBM WebSphere 21 1.1 Enterprise Java 23 1.1.1 Anforderungen 23 1.1.2 E-Business 30 1.1.3 Java 36 1.2 IBM

Mehr

SEQIS 10 things API Testing

SEQIS 10 things API Testing SEQIS 10 things API Testing SEQIS 10 things API Testing Herzlich Willkommen! Reinhard Salomon SEQIS Geschäftsleitung SEQIS 10 things Programm 2014 20.03.14 Business Analyse Einführung in den BABOK Guide

Mehr

Datenhaltung für Android. Model First

Datenhaltung für Android. Model First Datenhaltung für Android Model First Frederik Götz, Johannes Tysiak 26.05.2011 Unser Ziel! 26.05.2011 Datenhaltung in Android - Model First» Frederik Götz, Johannes Tysiak 2 Agenda Android Quickstart Datenhaltung

Mehr

Präsentation Von Laura Baake und Janina Schwemer

Präsentation Von Laura Baake und Janina Schwemer Präsentation Von Laura Baake und Janina Schwemer Gliederung Einleitung Verschiedene Betriebssysteme Was ist ein Framework? App-Entwicklung App-Arten Möglichkeiten und Einschränkungen der App-Entwicklung

Mehr

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

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

Mehr

Mobile Application Development

Mobile Application Development Mobile Application Development Android: Einführung Jürg Luthiger University of Applied Sciences Northwestern Switzerland Institute for Mobile and Distributed Systems Lernziele Der/die Kursbesucher/in kann

Mehr

Leichtgewichtige Web 2.0-Architektur für komplexe Business-Anwendungen Nicolas Moser PRODYNA AG

Leichtgewichtige Web 2.0-Architektur für komplexe Business-Anwendungen Nicolas Moser PRODYNA AG 05.07.2012 Leichtgewichtige Web 2.0-Architektur für komplexe Business-Anwendungen Nicolas Moser PRODYNA AG Agenda 01 Einführung 02 Architektur 03 Lösungen 04 Zusammenfassung 2 2 Agenda 01 Einführung 02

Mehr

Java Script für die Nutzung unseres Online-Bestellsystems

Java Script für die Nutzung unseres Online-Bestellsystems Es erreichen uns immer wieder Anfragen bzgl. Java Script in Bezug auf unser Online-Bestell-System und unser Homepage. Mit dieser Anleitung möchten wir Ihnen einige Informationen, und Erklärungen geben,

Mehr

5. Übung zur Vorlesung Service-orientierte Architekturen

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

Mehr

1. Software-Plattform Android Android. Was ist Android? Managed Code, Angepasste Java Virtual Machine

1. Software-Plattform Android Android. Was ist Android? Managed Code, Angepasste Java Virtual Machine 1. Software-Plattform Android Android Was ist Android? Plattform und Betriebssystem für mobile Geräte (Smartphones, Mobiltelefone, Netbooks), Open-Source Linux-Kernel ab 2.6, aktuell 3.8 Managed Code,

Mehr

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221 Oracle 10g und SQL Server 2005 ein Vergleich Thomas Wächtler 39221 Inhalt 1. Einführung 2. Architektur SQL Server 2005 1. SQLOS 2. Relational Engine 3. Protocol Layer 3. Services 1. Replication 2. Reporting

Mehr

Einführung in Betriebssysteme

Einführung in Betriebssysteme Einführung in Betriebssysteme APPLE ios Entwicklung von ios Entwickelt auf der Basis von MacOS X UNIX Vorgestellt am 9.1.2007 Zusammen mit iphone Markenname von Cisco Internetwork Operating System Für

Mehr

WPF. Übersicht. Komponenten & Frameworks Seite 1

WPF. Übersicht. Komponenten & Frameworks Seite 1 Übersicht - W indows P resentation F oundation - Werkzeug zur Entwicklung grafischer Benutzeroberflächen - deklarative Definition erfolgt mit der Beschreibungs- Sprache: XAML - XAML - Extensible Application

Mehr

Ajax & GWT. Kurs: User Interfaces und ihre Evaluierung Dozent: Manfred Thaller WS 2012/2013 Referent: Rafael Kalina

Ajax & GWT. Kurs: User Interfaces und ihre Evaluierung Dozent: Manfred Thaller WS 2012/2013 Referent: Rafael Kalina Ajax & GWT Kurs: User Interfaces und ihre Evaluierung Dozent: Manfred Thaller WS 2012/2013 Referent: Rafael Kalina Ajax Technisches Verfahren, bei dem Browser aktualisierte Inhalte nicht mehr synchron

Mehr

AJAX SSL- Wizard Referenz

AJAX SSL- Wizard Referenz AJAX SSL- Wizard Referenz Version 1.0.2+ - 04.04.2011 Präambel Die vorliegende Dokumentation beschreibt den AJAX basierten SSL- Wizard der CertCenter AG. Der SSL- Wizard kann mit wenigen Handgriffen nahtlos

Mehr

Managed VPSv3 Was ist neu?

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

Mehr

Programmieren I. Die Programmiersprache Java. www.kit.edu. Institut für Angewandte Informatik

Programmieren I. Die Programmiersprache Java. www.kit.edu. Institut für Angewandte Informatik Programmieren I Die Programmiersprache Java KIT Universität des Landes Baden-Württemberg und nationales Großforschungszentrum in der Helmholtz-Gemeinschaft www.kit.edu Eigenschaften von Java Java ist eine

Mehr

Benutzerdokumentation Web-Portal

Benutzerdokumentation Web-Portal GRUPP: SWT0822 Benutzerdokumentation Web-Portal Yet Another Reversi Game Martin Gielow, Stephan Mennicke, Daniel Moos, Christine Schröder, Christine Stüve, Christian Sura 05. Mai 2009 Inhalt 1. Einleitung...3

Mehr

Profil von Michael Wettach

Profil von Michael Wettach Profil von Tätigkeiten Konzeption und Implementierung von: Desktop Anwendungen Web Anwendungen Serviceorientierten Architekturen Komplexen Datenbankbankanwendungen Technische Beratung IT-Projektleitung

Mehr

Workflow Systeme mit der Windows Workflow Foundation

Workflow Systeme mit der Windows Workflow Foundation Studiengang Electronic Business (EB) Diplomarbeit (280000) Workflow Systeme mit der Windows Workflow Foundation externe Betreuung durch Christoph Müller vorgelegt bei Prof. Dr. Michael Gröschel von Hans-Martin

Mehr

Nächste Generation von Web-Anwendungen mit Web Intents

Nächste Generation von Web-Anwendungen mit Web Intents Nächste Generation von Web-Anwendungen mit Web Intents Willie Chieukam adorsys GmbH & Co. KG 1 Erkennen Sie den? Willie Chieukam Senior Software Entwickler/Berater seit 7 Jahren aktiv noch immer mit fragendem

Mehr

Python Programmierung. Dipl.-Ing.(FH) Volker Schepper

Python Programmierung. Dipl.-Ing.(FH) Volker Schepper Python Programmierung Kontaktdaten Homepage: http://wwwlehre.dhbw-stuttgart.de/~schepper/ Email: Volker. Schepper [A@T] yahoo.de Vorlesung Skriptsprachen Vorlesung: 06.03.2013 13.03.2013 20.03.2013 27.03.2013

Mehr

greenpaper 15. rich internet applications zum einsatz bringen.

greenpaper 15. rich internet applications zum einsatz bringen. Marken und Märkte aktivieren. Mit emotionaler Intelligenz als Basis exzellenter Ideen, die durchschlagend Erfolg versprechen com Icons 2011 24 Themen um die Sie sich für nächstes Jahr kümmern sollten greenpaper

Mehr

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

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

Mehr

Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java

Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java Präsentation zur Diplomarbeit von Übersicht Java 2 Enterprise Edition Java Servlets JavaServer Pages Enterprise JavaBeans Framework

Mehr

Erweiterung eines generischen Frameworks um Webservice-Fähigkeit

Erweiterung eines generischen Frameworks um Webservice-Fähigkeit Erweiterung eines generischen Frameworks um Webservice-Fähigkeit Entwurf und Implementierung Bachelor-Thesis Zur Erlangung des Hochschulgrades Bachelor of Science an der vorgelegt von: Studienbereich:

Mehr

Remote Communications

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

Mehr

1. Java Grundbegriffe

1. Java Grundbegriffe 1. Java Grundbegriffe Geschichte von Java Programmieren mit Java Interpretieren vs. Kompilieren Java Byte-Code Jave Virtual Machine Arbeitsmaterialien Allgemeine Informatik 2 SS09 Folie 1.1 Java, eine

Mehr

Mobile: Die Königsfrage

Mobile: Die Königsfrage Mobile: Die Königsfrage - Native App,Mobile Website oder doch Responsive Design? - Native App oder Mobile Website? Wer am Boom der mobilen Anwendungen teilhaben möchte, hat im Prinzip zwei Möglichkeiten:

Mehr

Java Web Services mit Apache Axis2 Entwickler

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

Mehr

0. Inhaltsverzeichnis

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

Mehr

Inhalt. 1 Übersicht. 2 Anwendungsbeispiele. 3 Einsatzgebiete. 4 Systemanforderungen. 5 Lizenzierung. 6 Installation.

Inhalt. 1 Übersicht. 2 Anwendungsbeispiele. 3 Einsatzgebiete. 4 Systemanforderungen. 5 Lizenzierung. 6 Installation. Inhalt 1 Übersicht 2 Anwendungsbeispiele 3 Einsatzgebiete 4 Systemanforderungen 5 Lizenzierung 6 Installation 7 Key Features 8 Funktionsübersicht (Auszug) 1 Übersicht MIK.starlight bietet individuelle

Mehr

eclipse - Entwicklungsumgebung und mehr ETIS SS05

eclipse - Entwicklungsumgebung und mehr ETIS SS05 eclipse - Entwicklungsumgebung und mehr ETIS SS05 Gliederung Motivation Geschichte Architektur Platform Runtime Eclipse Platform Java Development Tools (JDE) Plugin Development Environment (PDE) Zusammenfassung

Mehr

modern - sharp - elegant

modern - sharp - elegant modern - sharp - elegant Das Konzept für Ihre Webseite Wir sind Ihnen gerne bei der Konzeption Ihrer neuen Webseite behilflich. Gemeinsam mit Ihnen analysieren wir Ihre Anforderungen, erarbeiten die Ziele

Mehr

Integration in die Office-Plattform. machen eigene Erweiterungen Sinn?

Integration in die Office-Plattform. machen eigene Erweiterungen Sinn? Integration in die Office-Plattform machen eigene Erweiterungen Sinn? Agenda Apps Warum eigentlich? Apps für Office Apps für SharePoint Entwicklungsumgebungen Bereitstellung Apps Warum eigentlich? Bisher

Mehr

AM BeIsPIel Der DAsInvestMent.coM MoBIl WeB APP

AM BeIsPIel Der DAsInvestMent.coM MoBIl WeB APP AM BeIsPIel Der DAsInvestMent.coM MoBIl WeB APP 2 Inhalt Warum ist es sinnvoll eine spezielle Applikation für mobile Geräte zu entwickeln? Seite 5 Welche Möglichkeiten der Umsetzung gibt es? 6 Mobile Applikation

Mehr

SIEBEL OPEN UI. Rhein-Main-Handel GmbH. Bankhaus Goldbaum GmbH & Co. KG. Standort: Düsseldorf. Standort: Frankfurt ilum:e informatik ag

SIEBEL OPEN UI. Rhein-Main-Handel GmbH. Bankhaus Goldbaum GmbH & Co. KG. Standort: Düsseldorf. Standort: Frankfurt ilum:e informatik ag SIEBEL OPEN UI Rhein-Main-Handel GmbH Standort: Düsseldorf Bankhaus Goldbaum GmbH & Co. KG ilum:e informatik ag Standort: Mainz Forschungszentrum Medizin Internationale Telecom AG Chemielabor GmbH Standort:

Mehr

DCOM und.net. B. Sc. Tobias Buchloh. Seminar Software-Entwurf Fachgebiet Software Engineering, Institut für Angewandte Informatik Universität Hannover

DCOM und.net. B. Sc. Tobias Buchloh. Seminar Software-Entwurf Fachgebiet Software Engineering, Institut für Angewandte Informatik Universität Hannover DCOM und.net B. Sc. Tobias Buchloh Seminar Software-Entwurf Fachgebiet Software Engineering, Institut für Angewandte Informatik Universität Hannover 2004-12-21 Gliederung Motivation Einordnung (D)COM.NET

Mehr

XML Grundlagen Sommersemester 2013

XML Grundlagen Sommersemester 2013 XML Grundlagen Sommersemester 2013 Die Lehrveranstaltung wird studienbegleitend durch eine Hausarbeit und eine Präsentation mit Diskussion geprüft. Die Themen der folgenden Liste werden im Rahmen der Lehrveranstaltung

Mehr

Netzwerk Technologien in LabVIEW

Netzwerk Technologien in LabVIEW Netzwerk Technologien in LabVIEW von Dirk Wieprecht NI Germany Hier sind wir: Agenda Agenda Bedeutung des Ethernet für die Messtechnik Ethernet-basierende Technologien in LabVIEW Low Level- TCP/IP Objekt

Mehr