UPnP Diplomarbeit

Entwicklung verteilter Gerte und a Anwendungen fur die UPnP Plattform unter besonderer Berucksichtigung automatisch generierter User Interfaces

Jakob S. Doppler

DIPLOMARBEIT

eingereicht amFachhochschul-Masterstudiengang

Digitale Medien in Hagenberg

im Juni 2006

c Copyright 2006 Jakob S. Doppler Alle Rechte vorbehalten

ii

Erklrung aHiermit erklre ich an Eides statt, dass ich die vorliegende Arbeit selbsta stndig und ohne fremde Hilfe verfasst, andere als die angegebenen Quellen a und Hilfsmittel nicht benutzt und die aus anderen Quellen entnommenen Stellen als solche gekennzeichnet habe.

Hagenberg, am 26. Juni 2006

Jakob S. Doppler

iii

InhaltsverzeichnisErklrung a Vorwort Kurzfassung Abstract 1 Einleitung 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Abgrenzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Technische Begriserklrungen a 2.1 Bluetooth . . . . . . . . . . . . . . . . 2.1.1 Technische Details . . . . . . . 2.1.2 Architektur . . . . . . . . . . . 2.1.3 Prole . . . . . . . . . . . . . . 2.1.4 Vergleichbare Funktechnologien 2.2 Service-Plattformen . . . . . . . . . . 2.2.1 JINI . . . . . . . . . . . . . . . 2.2.2 UPnP . . . . . . . . . . . . . . 2.2.3 OSGi . . . . . . . . . . . . . . iii vii viii ix 1 2 2 4 4 4 5 7 7 8 8 11 15 17 17 18 19 19 20 23 26 26

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

3 Gerte a 3.1 Szenario . . . . . . . . . . . . . . . . . . . . . 3.2 Konzept . . . . . . . . . . . . . . . . . . . . . 3.3 UPnP-Technologie . . . . . . . . . . . . . . . 3.4 Implementierung . . . . . . . . . . . . . . . . 3.4.1 Sensor-Hardwaredevice . . . . . . . . . 3.4.2 Webcam Streaming-Server und Client 3.4.3 UPnP-Winamp Media Player . . . . . 3.4.4 MIDI-Device . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

iv

INHALTSVERZEICHNIS 4 Generierung grascher User Interfaces 4.1 Anforderungen im GUI-Design . . . . . . . . . . . . . . 4.2 Anforderungen im Pervasive Computing . . . . . . . . . 4.2.1 Kontext-sensitive und verteilte Anwendungen . . 4.2.2 Gerteeigenschaften . . . . . . . . . . . . . . . . a 4.3 Techniken der GUI-Entwicklung . . . . . . . . . . . . . . 4.3.1 Window Manager und Toolkits . . . . . . . . . . 4.3.2 Web-basierte Entwicklungen . . . . . . . . . . . . 4.3.3 Interaktive GUI-Builder . . . . . . . . . . . . . . 4.4 XML GUI-Sprachen . . . . . . . . . . . . . . . . . . . . 4.4.1 XAML . . . . . . . . . . . . . . . . . . . . . . . . 4.4.2 XUL . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.3 XForms . . . . . . . . . . . . . . . . . . . . . . . 4.4.4 UIML . . . . . . . . . . . . . . . . . . . . . . . . 4.4.5 XIML . . . . . . . . . . . . . . . . . . . . . . . . 4.5 Model-based User Interface . . . . . . . . . . . . . . . . 4.5.1 User Interface Generierung . . . . . . . . . . . . 4.5.2 Projekt Pebbles Personal Universal Controller 4.5.3 Projekt Supple . . . . . . . . . . . . . . . . . . 5 GUI-Builder 5.1 Konzept . . . . . . . . . . . . . . . . . . . . . . 5.1.1 System-Schnittstellen . . . . . . . . . . 5.1.2 Setup . . . . . . . . . . . . . . . . . . . 5.2 Implementierung - PC . . . . . . . . . . . . . . 5.2.1 Entwicklung mit OSGi . . . . . . . . . . 5.2.2 Systemaufbau . . . . . . . . . . . . . . . 5.2.3 GUI-Generator . . . . . . . . . . . . . . 5.2.4 UI-Erweiterungen . . . . . . . . . . . . 5.3 Implementierung - Smart Phone . . . . . . . . 5.3.1 Entwicklung mobiler Java-Anwendungen 5.3.2 Gateway . . . . . . . . . . . . . . . . . . 5.3.3 Mobile Client . . . . . . . . . . . . . . . 6 Fazit 6.1 Erreichte Ziele . . . 6.1.1 Gerte . . . . a 6.1.2 GUI-Builder 6.2 Ausblick . . . . . . .

v 28 29 30 30 31 32 32 32 34 34 35 36 36 38 39 42 44 44 48 53 53 54 56 56 56 58 60 66 70 71 72 74 78 79 79 79 80

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

A Inhalt der CD-ROM 82 A.1 Diplomarbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 A.2 Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 A.3 Anwendungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

INHALTSVERZEICHNIS A.4 Quellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Literaturverzeichnis

vi 83 84

VorwortMit der Fertigstellung der vorliegenden Diplomschrift geht ein weiterer Abschnitt in meinem Leben zu Ende. Der Blick zur ck an den Beginn des u Studiums lsst mich kaum glauben, dass seither f nf Jahre vergangen sind. a u Auch wenn die Zeit an der Fachhochschule Hagenberg mit viel Arbeitsaufwand und Engagement verbunden war, mchte ich sie dennoch nicht missen. o Viele gute Erinnerungen und lehrreiche Erfahrungen in fachlicher als auch in menschlicher Hinsicht tragen zu diesem positiven Eindruck bei. Die Faszination der Technik liegt f r mich in ihrer gestalterischen Schafu fenskraft, die, wenn sie mit Wissen und Gewissen eingesetzt wird, Groartiges vollbringen kann. Ich hoe mit meiner Arbeit einen kleinen Teil zu einem technologischen Fortschritt beizutragen, der in Einklang mit den Bed rfnissen und Werten unserer Gesellschaft steht. Daher scheint es auch u angemessen, jene Personen zu nennen, die mir das Gef hl geben eben dieses u erreichen zu knnen. o Im Rahmen einer mehrjhrigen Forschungsarbeit konnten mit meinem a Projektpartner und Freund Bernhard Wally neue Aspekte einer intelligenten und vernetzten Gertelandschaft beleuchtet werden, wie sie in ein paar a Jahren vielleicht in jedem Haushalt zu nden sein wird. Daf r und f r die u u vielen, teils lustigen Stunden gemeinsamen Wirkens sei ihm gedankt. Auch meinem Betreuer DI Dr. Christoph Schaer, der mir im Laufe meines Diplomstudiums in zahlreichen Gesprchen mit guten Ratschlgen und fachlia a chem Wissen zur Seite gestanden ist, gilt mein besonderer Dank. Die Erkenntnis, dass das Leben neben der Schnheit der Technik auch o noch andere, ebenso wichtige Facetten zu bieten hat, habe ich zweifelsohne meiner Familie und den zahlreichen, guten Freundschaften in Hagenberg und Gallneukirchen zu verdanken. Insbesondere sind hier meine Eltern Regina und Erwin Doppler genannt, die mir in vielen richtungsweisenden Entscheidungen, denen ich im Laufe meines bisherigen Lebens begegnete bin, geholfen haben und mir meine Ausbildung ermglichten. o

vii

KurzfassungGetragen von der rasanten Entwicklung mobiler und eingebetteter Gerte, a bringen einheitliche Kommunikationsstandards eine neue Qualitt f r die a u im Netzwerk verteilten Anwendungen. Es existiert der Wunsch nach intelligenten Diensten, die in der eigenen Umgebung und in verschiedensten Lebenssituationen in Anspruch genommen werden knnen. Ein weitgehend o ungeklrter Aspekt in diesem Zusammenhang sind Automatismen f r die a u Darstellung und Interaktion mit diesen verteilten Diensten. Im Rahmen der vorliegenden Arbeit werden auf Basis der UPnP ServicePlattform verschiedene Gerte und Anwendungen f r ein mgliches Mediena u o steuerungsszenario beleuchtet. Der erste Schwerpunkt liegt in der Entwicklung von Eingabemedien. Anhand eines sensorbasierten Hardwaredevices und einer Kamera mit Bewegungserkennung soll in Verbindung mit einem UPnP-basierten Framework zur Verkn pfung von Gertediensten die Fu a a higkeit zur dynamischen Vernetzung und Ansteuerung anderer, verteilter Gerte demonstriert werden. a Im zweiten Teil werden Anforderungen f r die automatisierte Generieu rung von User Interfaces zur Fernsteuerung der Dienste ermittelt. Der Benutzer soll unabhngig vom Ort und der Plattform des darstellenden Endgea rtes mit den netzwerkbasierten Anwendungen interagieren knnen. Anhand a o zweier Prototypen f r den PC und f r das Smart Phone wird die technische u u Machbarkeit dieses Ansatzes gezeigt.

viii

AbstractAdvances in mobile and embedded technology and communication standards for distributed device computing oer new opportunities for home appliances. This trends reects a deep longing for smart and sophisticated services that help us in everyday life activities. But taking automated representation and interaction with these services into account, there are still a number of open issues. The present thesis deals with research and development of various applications and devices that are based on the UPnP service platform. The rst idea places emphasis on prototyping input devices for a UPnP-based media control framework. Thus methods for integrating a sensor-based device and a monitoring camera for motion detection have to be found. The second part covers research on automated user interface generation for distributed network services. Since users should not be restricted in choosing their favorite environment for application usage, two GUI building applications to remotely control these services were implemented. The rst one is based on the PC platform. The second one tries to employ the remote control metaphor by using a smart phone.

ix

Kapitel 1

EinleitungLngst hat sich das Internet als globales Kommunikationsnetzwerk etabliert. a Waren die Anfnge des Mediums vorrangig von der schnellen Verbreitung a und Beschaung von Informationen geprgt, so kam im Laufe der Zeit ein a weiterer Aspekt zur Geltung: Die Nutzung von automatisierten Dienstleistungen in Echtzeit zeigte neue Qualitten der Vernetzung auf und sicherte a deren nachhaltigen Erfolg. Analog dazu vollzog sich auch im Softwaredesign ein grundlegender Wandel von magefertigten Einzellsungen zu der Idee o von interoperablen Applikationen, die durch die gemeinsame Standardisierung von Technologien getragen wird. Erwhnenswert hierf r ist die univera u selle Beschreibungssprache XML (Extended Markup Language), die f r die u Reprsentation verschiedenster Daten herangezogen wird. a Diese Entwicklung entfacht den Wunsch nach intelligenten Diensten, die auch in der eigenen Umgebung und in verschiedensten Lebenssituationen in Anspruch genommen werden knnen [13]. Der Benutzer soll unabhngig o a 1 interagieren knnen. o von Ort und Zeit mit kontextsensitiven Anwendungen Mglich wird dies durch die zunehmende Verbreitung von Embedded Syo a stems2 und mobilen Endgerten wie dem PDA (Personal Digital Assistant), dem Mobiltelefon oder dem Laptop, die mit Nah- und Fernfunktechnologien ausgestattet sind. In diesem Zusammenhang spricht man von Ubiquitous Computing 3 . Die Begrie bezeichnen die alles durchdringende Vernetzung von intelligenten Gegenstnden des Alltags [40]. Organisationen wie die a a Digital Living Network Association (DNLA)4 beschftigen sich mit den Anforderungen, die es am Weg zur universellen Vernetzung von Gertediensten a im Haushalt zu erf llen gilt und dem mglichen Mehrwert, der daraus geu o neriert werden kann.Kontextsensitive Anwendungen besitzen die Fhigkeit, sich an aktuelle Gegebenheiten a und Umweltein sse anzupassen. u 2 Eingebettete Computersysteme, die f r den Benutzer - meist unsichtbar - Dienste u verrichten und auf spezialisierter Hardware basieren und mit Sensoren ausgestattet sind. 3 auch Pervasive Computing 4 DNLA - http://www.dnla.org1

1

KAPITEL 1. EINLEITUNG

2

1.1

Motivation

Der Grundstein f r die Realisierung der Vision einer pervasiven Umgebung u scheint mit den fortschreitenden Entwicklungen von mobilen und EmbeddedTechnologien gelegt. Ein weitgehend ungeklrter Aspekt hingegen sind Stana dards und Automatismen f r die Darstellung und Interaktion mit verteilten u Diensten. Service-Plattformen wie Universal Plug and Play (siehe Kapitel 2.2.2) sind plattformunabhngige Software-Bibliotheken, die dem Entwickler die a groe Verantwortung hinsichtlich einheitlicher Gerteschnittstellen und aua tomatischer Erkennung der Netzwerkdienste abnehmen und diese von einem beliebigen Ort aus fernsteuerbar und uberwachbar machen. Sie treen jedoch keine Entscheidungen hinsichtlich der Reprsentation der Interaktionsdaten. a Aus diesen Uberlegungen entsteht die Idee sowohl Eingabegerte f r den a u Einsatz in einem Mediensteuerungsszenario zu entwickeln, als auch Forschung in Richtung der automatisierten Generierung von User Interfaces zur Fernsteuerung von verteilten Gerten zu betreiben. Erstere ist Teil eines a lang ersehnten Wunsches, den PC als vorrangiges Interaktionsmedium f r u computerisierte Dienste ablsen zu knnen. In diesem Zusammenhang wird o o ein Weg gesucht, um Sensorik und die Bewegungserkennung einer Kamera als Auslser zur Steuerung verteilter Netzwerkdienste nutzen zu knnen. o o Die zweite Idee befasst sich mit Interaktionen, in denen ein Display hingegen notwendig und sinnvoll ist. Hierf r muss ein Konzept zur automatiu sierten Generierung von User Interfaces im Kontext verteilter Gerte und a Anwendungen erstellt werden. Mglich wird dies durch die Architektur von o UPnP. Wird ein neues Gert dem Netzwerk hinzugef gt, werden alle intera u essierten Teilnehmer dar ber informiert und erhalten eine funktionale Beu schreibung der Gertedienste. Diese Beschreibung kann genutzt werden, um a ein Interface zur Steuerung des Gertes darzustellen. a Da die Problemstellung der automatisierten Generierung von User Interfaces nicht alleine auf die Domne der verteilten Netzwerke beschrnkt a a ist, gibt es einige, vielversprechende Anstze. Mehrere XML-basierte Spraa chen und GUI-Building Systeme (siehe Kapitel 4) bieten Lsungsanstze o a auf verschiedenen Abstraktionsebenen an. Diese reichen von einer konkreten Beschreibung und Positionierung der Steuerelemente bis hin zu einer Verkn pfung zwischen den Interaktionsdatentypen der Gertefunktion und u a abstrakten Elementen, denen abhngig von den Vorgaben der Plattform eine a andere grasche Reprsentation zukommt. a

1.2

Abgrenzung

Ziel der Arbeit ist die Nutzung der UPnP Service-Plattform zur Erstellung netzwerkbasierter Gerte, die in einen Wohn- und Arbeitsraum integriert a

KAPITEL 1. EINLEITUNG

3

werden knnen und entweder passiv Informationen uber Personen in der o Umgebung beziehen oder als physisches Interaktionsmedium einsetzbar sein sollen. Zudem m ssen, um im Netzwerk verteilte Gertedienste unter einem u a gemeinsamen User Interface Standard ansprechen zu knnen, bestehende o User Interface-Auszeichnungssprachen und GUI-Building Systeme zur Fernsteuerung einer UPnP-Gertelandschaft evaluiert werden. a Anhand prototypischer Implementierungen soll der Einsatz der Technologie in einem Mediensteuerungsszenario gerechtfertigt werden. Dazu zhlen a mit einem Sensormodul und einer Kamera zur Bewegungserkennung mehrere UPnP-fhige Gerte. Weiters soll die Generierung grascher User Interfaces a a zur Fernsteuerung der verteilten Anwendungen am PC und f r die Smart u Phone-Plattform demonstriert werden. Die Arbeit ist in zwei Bereiche unterteilt. Der erste befasst sich mit den technischen Vorrausetzungen und der Erstellung der Gerte. Im zweiten Teil a werden die Ergebnisse der Recherche zur automatisieren User Interface Generierung anhand zweier Prototypen beleuchtet. Die Schwerpunkte umfassen jeweils zwei Kapitel: Kapitel 2 stellt die technischen Vorraussetzungen f r die Arbeit mit den u Gerten vor. Es wird der Funkstandard Bluetooth beleuchtet und die Wahl a UPnP als bevorzugte Service-Plattform vorgestellt. Kapitel 3 versucht mit einem pervasiven Szenario die Intention der Arbeit zu erklren und beleuchtet anhand der entwickelten Gerte den ersten Teil a a der Implementierung. Kapitel 4 beschftigt sich mit vorhandenen Systemen und XML-Spracha denitionen rund um das Thema einer generischen Beschreibung und Generierung von graschen Benutzeroberchen. a Kapitel 5 demonstriert und dokumentiert die praktische Anwendbarkeit einer generischen Mediensteuerung f r verteilte Gerte anhand zweier prou a totypischer GUI-Builder Anwendungen f r PC und Smart Phone. u Kapitel 6 ist eine Zusammenfassung der gewonnenen Erkenntnisse und wagt einen Ausblick in die nahe Zukunft.

Kapitel 2

Technische Begriserklrungen a2.1 Bluetooth

Durch den Bedarf einer kosteng nstigen Technologie mit niedrigem Energieu verbrauch als Ersatz f r kabelgebundene Kommunikation, wurde 1994 von u dem Mobilfunkunternehmen Ericsson die Bluetooth-Technologie1 ins Leben gerufen. Das rege Interesse namhafter Hersteller wie IBM, Intel und Nokia f hrte zur Gr ndung des Entwicklerkonsortiums Bluetooth Special Interest u u Group (Bluetooth SIG)2 und zur Erhebung von Bluetooth zum Industriea standard gem IEEE3 802.15.1. Wenngleich auch die chendeckende Eina f hrung von Anfang an in einer allgemeinen Euphorie prognostiziert wurde, u vergingen einige Jahre bevor die Akzeptanz gegeben und eine gen gende u Verbreitung an Endgerten mit Bluetooth-Hardware gegeben war. a

2.1.1

Technische Details

Die Daten bertragung bei Bluetooth erfolgt uber das lizenzfreie ISM-Freu quenzband im Bereich zwischen 2,400 GHz und 2,480 GHz [31]. Da dieses Band jedoch von einer Vielzahl an Funktechnologien, darunter auch der WLAN-Standard (IEEE 802.11) oder die Schnurlostelefonie, genutzt wird, braucht es ein robustes Verfahren um die Ubertragungsqualitt zu gewhrleia a sten. Diese Robustheit wird durch ein Frequenzsprungverfahren (Frequency Hopping) garantiert. Darunter versteht man den Wechsel des Trgersignals a alle 625 s zwischen den bei Bluetooth denierten 79 Frequenzstufen im 1-MHz Abstand. Die maximale Ubertragungsrate liegt dabei in den Versionen 1.1 und 1.2 bei 723,1 kbit/s und in der verbesserten Version 2.0 EDRBluetooth - http://www.bluetooth.com/ Bluetooth SIG - https://www.bluetooth.org/ 3 IEEE (Institute of Electrical and Electronics Engineers) - http://ieee.org- eine Institution zur Standardisierung von Computertechnologien2 1

4

KAPITEL 2. TECHNISCHE BEGRIFFSERKLARUNGENWAE WAP TCP/UDP vCard/vCal OBEX RFCOMM L2CAP IP PPP SDP TCS BINAT Command

5

AUDIO

HCI

LMP Baseband Bluetooth Radio

Abbildung 2.1: Bluetooth Stack Architektur (siehe [31]).

(Enhanced Data Rate) bei 2,1 Mbit/s. Um der Anforderung einer kosteng nstigen und energiesparenden Funktechnologie gerecht zu werden, wurden u drei Leistungsklassen f r verschiedene Einsatzzwecke geschaen. Klasse 1u Gerte sind f r eine Reichweite von bis zu 100 m bei einer Leistung von a u 100 mW konzipiert. Am anderen Ende liegen Klasse 3-Gerte mit 1 m und a 1 mW. Die breite Palette der Unterhaltungselektronik und mobilen Endgerte arbeitet mit Klasse 2-Chips bei einem Verbrauch von 2,5 mW und einer a Reichweite bis zu 10 m [31]. In einem Bluetooth Netzwerk (Piconet) knnen sich bis zu 65.000 Gerte o a benden, von denen jedoch nur acht aktiv sein d rfen. Ein Master-Gert u a sorgt f r sie Synchronisation der sieben Slaves. Ein Bluetooth-Teilnehmer u kann sich in mehreren Netzwerken aufhalten, wodurch eine netzwerk beru greifende Kommunikation mglich wird. Der Zusammenschluss mehrerer Pio conets bezeichnet man als Scatternet.

2.1.2

Architektur

Der Bluetooth Protokollstack wurde von der Bluetooth SIG entworfen und enthlt eine Sammlung hierarchisch angeordneter Protokolle (siehe Abbila dung 2.1). Erklrte Designziele waren eine bindende Richtlinie f r die Ima u plementierung von Bluetooth-Gerten und maximale Interoperabilitt durch a a die Wiederverwendung lterer Kommunikationsprotokolle in den hheren a o Schichten. Die Protokolle werden in vier grundlegende Schichten eingeteilt [31] (siehe Tabelle 2.1.2).

KAPITEL 2. TECHNISCHE BEGRIFFSERKLARUNGEN Protocol Layer Bluetooth Core Protocols Cable Replacement Protocol Telephony Control Protocols Adopted Protocols Protocols Baseband, LMP, L2CAP, SDP RFCOMM TCS Binary, AT-commands PPP, TCP/UDP/IP, OBEX, WAP, vCard, cCal, IrMC, WAE

6

Tabelle 2.1: Bluetooth-Architektur Protokollschichten (siehe [5]).

Core Protocols: Das Baseband sorgt f r die physikalische Verbindung u und die Synchronisation der Netzwerkteilnehmer mittels des zuvor erwhna ten Frequenzsprungverfahrens. Echtzeitkritische Audiodaten werden ebenfalls ohne zustzlichen Overhead uber dieses Protokoll ubertragen. Das Link a Manager Protocol (LMP) ist f r den Verbindungsaufbau zwischen den Blueu tooth-Gerten sowie Authentizierung und Verschl sselung zustndig. Das a u a Logical Link Control and Adaption Protocol (L2CAP) fungiert als Vermittlungsschicht zwischen hherliegenden Protokollen und dem Host Controller o Interface (HCI). Gerte- und Dienstinformationen knnen nach erfolgreicher a o Verbindung mit dem Simple Discovery Protocol (SDP) abgefragt werden. Cable Replacement Protocol - RFCOMM: Zur Emulation des seriellen Daten bertragungskanal RS232 wurde die RFCOMM -Schnittstelle u geschaen. Dadurch knnen eine groe Anzahl an hherliegenden Protokolo o len ohne Anpassungsaufwand auch uber Bluetooth Funk betrieben werden. Telephony Control Protocols: Auf Empfehlung der International Telecommunication Union (ITU-T) ossen AT-Steuerkommandos (AT-commands) in die Bluetooth-Spezikation mit ein. Das zustzliche Telephony a Control Protocol - Binary (TCS Binary) zeichnet sich f r den Verbindungsu aufbau von Daten- und Sprach bertragung verantwortlich. u Adopted Protocols: Um mit IP basierten Protokollen wie TCP und UDP kommunizieren zu knnen, wurde das Point-to-Point Protokoll (PPP) o entwickelt. Es verwaltet den Paketversand des Bluetooth-Gertes und era mglicht die Darstellung von Internetinhalten mit dem Wireless Applicao tion Protocol (WAP) und der aufbauenden Wireless Application Environment (WAE) Anwendungen. Object Exchange (OBEX) ist der InfrarotSpezikation entnommen und ermglicht den schnellen Austausch von Obo jekten ohne den Transportkanal, in diesem Fall RFCOMM, zu denieren. Ein Verwendungszweck ist das Synchronisieren von Kalendern (vCal) und das Austauschen von Business Cards (vCard).

KAPITEL 2. TECHNISCHE BEGRIFFSERKLARUNGEN

7

2.1.3

Prole

Im Vergleich zu anderen Funktechniken wie WLAN, die einmal speziziert werden und eine starre Auslegung verlangen, lebt die Bluetooth-Spezikation vor allem durch ihre hochgradige Flexibilitt und Erweiterbarkeit. Vera antwortlich daf r ist der vielschichtige Aufbau der Bluetooth-Architektur. u Um den verschiedenartigen Anwendungsmglichkeiten f r unterschiedliche o u Gerteklassen gerecht werden zu knnen, bedarf es eines komponentenbaa o sierten Ansatzes, der es durch einfachen Austausch von Protokollen schat, die gew nschten Szenarien abzudecken. Aufbauend auf einem generischen u Protokollstack setzen spezischere Protokolle auf, die in einer Vererbungshierarchie angeordnet sind [20]. Prole sind Kombinationen dieser Komponenten, die bestimmte R ckschl sse auf den Aufbau und die Zusammensetu u zung des Bluetooth Protokollstacks zulassen. Die Interoperabilitt zwischen a zwei Bluetooth-Gerten ist von der Unterst tzung der gemeinsamen Prole a u abhngig. Beim Verbindungsaufbau tauschen die Teilnehmer diese aus und a ermitteln, ob sie zueinander kompatibel sind. Es existiert eine Vielzahl an Prolen, die unter anderem die Synchronisation und Vernetzung, den Austausch von Daten und Dokumenten, die Ein- und Ausgabe auf Endgerten (FAX, Drucker) oder die Ubertragung von a Audiodaten uber Headset und Mobiltelefon denieren. Erwhnenswert ist in a diesem Zusammenhang eine Reihe an Prolen, die f r die Mediensteuerung u interessant sind. Das Personal Area Network -Prol deniert, wie sich alle in Reichweite bendlichen Gerte zu einem Ad-Hoc PAN-Netzwerk zusama menschlieen knnen und Zugang zu einem LAN erhalten. Einen weiteren o Schritt in Richtung Vernetzung von Diensten geht die Bluetooth SIG mit dem Entwurf f r das Extended Service Discovery Protocol (ESDP), das zur u Erkennung von UPnP Gerten herangezogen werden soll. Die Liste der Proa le ist einer stndigen Vernderung unterworfen und wird von der Bluetooth a a SIG verwaltet4 .

2.1.4

Vergleichbare Funktechnologien

Im den letzten Jahren entwickelte sich rund um die Idee des Mobile Computing und die dadurch gewonnene Ortsunabhngigkeit ein kompetitives Gea schft. Neben Bluetooth drngen eine Menge ahnlicher Technologien auf den a a Markt und eine steigende Anzahl an multifunktionalen Endgerten mit una terschiedlichsten Anforderungen tragen ihren Teil dazu bei, dass die Wahl nicht immer leicht fllt. Waren die Grenzen zwischen Wireless LAN und a Bluetooth anfangs noch relativ klar deniert, kann eine Uberschneidung mit Technologien wie ZigBee, Near Field Communication (NFC) und Radio Fre4 Eine aktuelle Liste der Bluetooth Prol-Spezikationen ndet sich unter http:// bluetooth.com/Bluetooth/Learn/Technology/Specications/. Eine Liste der Entw rfe ist unu ter https://www.bluetooth.org/spec/ abrufbar


8

quency Identication (RFID) nur schwer geleugnet werden5 . Dies ruft auch unweigerlich Probleme in der Standardisierung durch die IEEE auf den Plan, wie sie im aktuellen Formatstreit um Ultra Wide Band (UWB), das als Basis f r das zuk nftige drahtlose USB gilt, ersichtlich sind. Bluetooth wird denu u noch an den Spezikation der beiden gegenstzlichen Konsortien WiMedia a 6 und dem UWB Forum7 mitwirken, verspricht UWB doch groe Alliance Daten bertragungsraten bei niedrigstem Energieverbrauch. u

2.2

Service-Plattformen

Technologien wie Jini 8 und Universal Plug and Play (UPnP)9 wurden entwickelt, um Ordnung in die heterogene Landschaft verteilter Gerte und a Dienste zu bringen und die gegenseitige Kommunikation zu ermglichen. o Neben der einheitlichen Kommunikationsschnittstelle ist auch die automatisierte Ad-Hoc-Vernetzung und Diensterkennung (Service Discovery) ein vorrangiges Ziel10 . Unter Ad-Hoc versteht man in der Informatik-Terminologie die Vernetzung meist mobiler Gerte ohne das Vorhandensein einer festen a Infrastruktur. Die Konzepte und Unterschiede der beiden Standards werden im folgenden Kapitel nher erlutert. Im Anschluss wird mit OSGi ein a a generisches Service-Framework Open Service Gateway Initiative (OSGi)11 vorgestellt, das die beiden konkurrierenden Netzwerk-Technologien in einem gemeinsamen Standard zu vereinen versucht.

2.2.1

JINI

Allgemeines Jini wurde 1999 als verteilte Netzwerktechnologie schon viele Jahre vor UPnP ins Leben gerufen. Die Architektur wurde von Sun entworfen und verwendet gngige Java-Technologien [35]. Jini kann auf einem beliebigen Netza werkprotokoll aufsetzen, ist aber an eine vorhandene Laufzeitumgebung, die Java Virtual Machine (JVM), und dadurch an die Konzepte der Programmiersprache Java gebunden. Dies ist ein entscheidender Nachteil im Vergleich zur generischeren Auslegung des Konkurrenten UPnP (siehe Kapitel 2.2.2) Auf Basis der Virtual Machine setzten Jinis eigene Netzwerkprotokolle und das Java Remote Methode Invocation-Modell (RMI) f r den Aufruf von u entfernten Objekten im Netzwerk auf. Die Jini-Bibliothek umfasst die oberenEine Gegen berstellung verschiedener Wireless-Technologien und deren Einsatzzwecke u ndet sich unter http://bluetooth.com/Bluetooth/Learn/Technology/Compare/ 6 WiMedia Alliance - http://www.wimedia.org 7 UWB Forum - http://www.uwbforum.org/ 8 Jini - http://www.jini.org 9 UPnP - http://www.upnp.org/ 10 Ein Uberblick uber bestehende Protokolle zur Diensterkennung nden sich in [25] 11 OSGi - http://osgi.org/5


9

Java Spaces

Other Services

Lookup

Discovery & Join

Jini

RMI

Java Virtual Machine

Abbildung 2.2: Jini Architektur (siehe [24]).

Schichten: das Discovery-Managment, den dar ber liegenden Lookup-Service u und die Applikationsschicht, die sich in Client-Anwendungen, den dazugehrigen Services und unabhngigen Netzwerkservices genannt JavaSpaces o a gliedert (siehe Abb. 2.2). Kommunikationsmodell Das Jini-Kommunikationsmodell wird von drei Komponenten getragen. Ein Service Provider, im Java Jargon auch als Djinn bezeichnet, stellt einem Netzwerk seine Dienste zur Verf gung. Dazu wird f r jeden Dienst ein u u Dienstobjekt und eine Liste von Attributen mit Serviceinformationen in einer speziell daf r vorgesehenen Java-Klasse erstellt. Dienstobjekte stellen u f r den Service Provider ein Interface zur Verf gung, mit der er seine Fu u a higkeiten prsentieren kann. Der Service Provider sendet diese Information a an einen Lookup Service und wird dort registriert. Jeder Lookup Service ist ebenfalls ein Dienst und die Anlaufstelle f r Jini-Clients die nach Services u Ausschau halten. Will ein Client einen Service in Anspruch nehmen, so erhlt er aus dem Index des Lookup Services die bentigte Information, um a o den Dienst am Service Provider eigenstndig aufrufen zu knnen. a o Die Kommunikation zwischen den Teilkomponenten (Abb. 2.3) wird in die Phasen Discovery, Join, Lookup und Service Call eingeteilt: Discovery: Eine Netzwerkkomponente oder ein Service nutzen das Multicast Request Protocol um beim Start nach Jini Netzwerken und speziell Lookup Services suchen und durchsuchen zu knnen. o Das Multicast Announcement Protocol ndet beim Start eines neuen Lookup Services Verwendung, damit dieser potentiellen Clients seine Verf gu barkeit mitteilen kann. Auch beim Ausfall und neuerlichen Eintreten eines Lookup Services in das Jini-Netzwerk kommt dieses Protokoll zum Einsatz. Das Unicast Discovery Protocol wird von Netzwerkteilnehmern verwen-

KAPITEL 2. TECHNISCHE BEGRIFFSERKLARUNGENLookup Service

10

Re fe re nc e ku p

Di ov sc nd ya er

Se rv ice

Lo o

in Jo

Client

Service Call

Service Provider

Abbildung 2.3: Das Jini-Kommunikationsmodell (vereinfachte Darstellung aus [24]).

det, um gezielt mit einem Lookup Service kommunizieren zu knnen. Als o Vorraussetzung f r eine erfolgreichen Discovery-Prozess gilt die Netzwerkunu terst tzung von Multicast und Broadcast-Nachrichten. u Join: Diese Phase beschreibt die Prozedur der Service-Registrierung bei verschiedenen Lookup Services. Der Service Provider meldet ein Dienstobjekt und die Attributliste an und gibt bekannt, uber welche Zeitdauer der Dienst dem Netzwerk zur Verf gung steht. Um die Netzlast zu reduzieren u knnen mehrere Lookup Services auch in logische Gruppen zusammengefasst o werden, die der Service Provider einheitlich mit einer Mulitcast Discovery Nachricht ansprechen kann. Jeder Dienst wei welcher Gruppe er zugeordnet ist. Lookup: Mit Lookup bezeichnet man den Vorgang den ein Client anstt, o wenn er auf der Suche nach einem Dienst ist. Wird er bei einem Lookup Service f ndig, so erhlt er eine Kopie des Dienstobjektes. F r die Kommuniu a u kation wird eine RMI-Verbindung hergestellt, die das dynamisch Laden von Programmteilen und das Ausf hren von nicht-lokalen Prozessen auf einer u anderen Virtual Machine erlaubt. Service Call: Mit dem Erhalt des Dienstobjektes bekommt der Client die Mglichkeit, direkt mit dem Service Provider zu kommunizieren und den o Service in Anspruch zu nehmen. Weitere Konzepte Eventing: Ahnlich dem UPnP-Modell knnen sich Objekte als Service o Listener bei einem Dienst eintragen und werden beim Eintreten eines Ereignisses uber die Zustandsnderung informiert. a


11

Leasing: In Jini wird die temporre Nutzung der Ressourcen eines Sera vices als Leasing bezeichnet. Ein Client kann nach Absprache mit dem Service Provider einen Zeitrahmen denieren, in dem er den Dienst in Anspruch nehmen darf. Wird bis zum Ablaufs des Abonnements keine Erneuerung der Vereinbarung beantragt, so gibt der Provider die Ressourcen wieder frei.

2.2.2

UPnP

Allgemein Universal Plug and Play ist eine oene, verteilte Netzwerkarchitektur, die automatischen Verbindungsaufbau, Steuerung und Datenaustausch zwischen Gerten im Heim- und Oce-Bereich auf Basis von TCP/IP und Interneta technologien ermglicht. Die Entwicklung des Gertesteuerungssystems wird o a von namhaften Firmen unterst tzt und versucht die Charakteristika des Plug u and Play-Paradigmas auf bestehenden Netzwerkstandards umzusetzen und mit verteilter und unabhngiger Applikationslogik zu verbinden. Ein beliebia ges Gert kann somit dynamisch einem Netzwerk hinzugef gt werden, seine a u Dienste oerieren und uber die Verf gbarkeit und Serviceleistungen anderer u Gerte lernen. Die Merkmale von UPnP umfassen: a Automatische Gerte- und Serviceerkennung, Konguration und Intea gration (zero conguration). Abstraktion der Netzwerktopologie zugunsten einer einfachen Bedienung ( invisible networking). Plattform-, protokoll- und gerteunabhngige Kommunikation und Daa a tenaustausch. Bedingt durch die Flexibilitt der Architektur ist auch eine Anpassung a von Technologien und Mediengerten mit nicht IP-konformen Protoa kollen mglich. Der Implementierungsaufwand f r herstellerspezische o u Gertetreiber ist damit ebenfalls uber ssig, da standardisierte Proa u tokolle verwendet werden und dem Entwickler im Gegensatz zu Jini die freie Wahl der Programmiersprache und des Betriebssystems garantieren. Das UPnP Forum ist ein Konsortium das sich mit dem Design der Weiterentwicklung der UPnP-Kommunikation zwischen den Produkten verschiedener Hersteller beschftigt. Praktisch alle namhaften Firmen in der ITa Branche sind in diesem Forum vertreten12 . Komponenten Die UPnP-Architektur deniert zwei Komponententypen - das Gert (Dea vice) und die Steuerinstanz (Control Point).12

UPnP Implementers Corporation - http://www.upnp-ic.org/


12

Gert: Ein UPnP-Gert beinhaltet Dienste (Services) und kann in einer a a rekursiven Anordnung wieder Subgerte (Embedded Devices) mit Diensten a enthalten. Ein mgliche Anwendung wre eine multifunktionale Stereoano a lage, die sich aus verschiedenen Teilgerten wie CD-Player, Mini-Disk, Kasa settendeck, Radio und Uhr zusammensetzt. Diese bieten dem Benutzer abstrakte Services an (Multimedia-Steuerung, Zeitanzeige, Wecker). Diese Services enthalten wiederum Zustandsvariablen (state variables) und Aktionen (actions), die auf dem Gert ausgef hrt werden knnen (Ein- und Ausschala u o ten, Starten und Stoppen eines Mediengertes, Setzen und Auslesen der a Zeit). Die funktionale Beschreibung dieser Eigenschaften ist in einer XMLDokumentenhierarchie im Gert festgehalten, und wird im Netzwerk bea kanntgegeben. Ausgehend von einem zentralen Dokument mit allgemeinen Gerteeigenschaften sind uber relative Verweise weitere Service-Dokumente a referenziert. Der untenstehende Code zeigt Teile der XML-Beschreibung eines Licht-Dienstes. Auallend ist dabei die Kombination aus Zustandsvariable und zugehriger Getter und Setter -Zugrisaktion zum Setzen und o Auslesen des Variablenwertes, wie sie in UPnP sehr hug zu nden ist. a Jeder Ein- und Ausgabeparameter einer Aktion ist an eine denierte Zustandsvariable gebunden.1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

< actionList > < action > < name > SetPower < argumentList > < argument > < name > Power < r e l a t e d S t a t e V a r i a bl e> Power < direction > in < action > < name > GetPower < argumentList > < argument > < name > Power < r e l a t e d S t a t e V a r i a bl e> Power < direction > out < serviceStat eT a bl e > < stateVariable sendEvents = " yes " > < name > Power < dataType > boolean

KAPITEL 2. TECHNISCHE BEGRIFFSERKLARUNGENUPnP Vendor UPnP Forum UPnP Device Architecture GENA HTTPMU UDP IP SSDP HTTPU SOAP HTTP TCP GENA

13

Abbildung 2.4: Aufbau der UPnP Architektur (siehe [22]).

Control Point: Der Control Point erlaubt die Entdeckung und Steuerung der Gerte. Er liest die Gertebeschreibungen aus, um Informationen uber a a die Dienste zu erhalten, kann Statusabfragen ttigen, Statusnderungen vora a nehmen und Aktionen aufrufen um Dienste in Anspruch zu nehmen. Aufbau der UPnP-Stack Architektur Aufbauend auf der IP-Adressierung in der Vermittlungsschicht des OSI/ISOReferenzmodells [36] setzt sich der UPnP-Stack aus folgenden, in Abb. 2.4 ersichtlichen, Protokollen und Technologien zusammen. Als Transportprotokoll f r die Kommunikation kommt wahlweise TCP oder das ungesicherte u UDP zum Einsatz. Darauf aufbauend werden Protokolle f r die speziellen u Anforderungen von UPnP bereitgestellt. Auf der UDP Seite sind dies HTTP Multicast over UDP (HTTPMU), HTTP Unicast over UDP (HTTPU) und die darin gekapselten Protokolle Generic Event Notication Architecture (GENA) und Simple Service Discovery Protocol (SSDP), die f r die Gerteerkennung zustndig sind. Das u a a bekanntere Protokoll HTTP wird auf der Basis von TCP f r die Prsenu a tation und Beschreibung bentigt. Simple Object Access Protocol (SOAP) o k mmert sich um den Steuervorgang und HTTP und GENA zusammen sind u f r die Benachrichtigungen (eventing) im UPnP-Kommunikationsmodell zuu stndig. a UPnP Networking Im Folgenden werden die einzelnen Phasen des in Abb. 2.5 dargestellten UPnP-Kommunikationsmodells beschrieben. Eine ausf hrliche Beschreibung u von UPnP ndet sich unter [38]. Addressing: Eine Voraussetzung f r die automatische Gerteerkennung u a ist die Adressierung der Gerte. Diese erfordert das Vorhandensein eines a

KAPITEL 2. TECHNISCHE BEGRIFFSERKLARUNGENAddressing

14

Discovery

Description

Control

Eventing

Presentation

Abbildung 2.5: Die einzelnen Phasen des UPnP Networking Modells (in Anlehnung an [38]).

DHCP-Clients am Gert. Der Client sucht beim Anschluss an das Netza werk nach einem DHCP Server und bekommt nach der Anmeldung eine IP Adresse zugewiesen. Ist keine Unterst tzung von DHCP gegeben, so muss u das Device AutoIP verwenden. Discovery: Nachdem das Device erreichbar ist, beginnt es eigenstndig a seine Dienstleistungen, die eingebetteten Gerte und deren Services im Netza werk mit Multicast discovery messages anzubieten. Control Points hingegen suchen aktiv nach Gerten. Auch beim Verlassen des Netzwerkes muss eine a Multicast-Mitteilung generiert werden, um alle Netzwerkteilnehmer zu informieren. Description: Nach der Identizierung eines Gertes hat ein Control Point a nur wenig Information uber dessen Beschreibung. Er kennt die URL, die zu einer detaillierten Gertebeschreibung f hrt. Darin sind gem einem a u a denierten XML-Schema folgende Informationen enthalten: Herstellerspezische Angaben wie Modellname, Modellnummer, Seriennummer, Herstellername und URLs zu Webseiten. Information uber die eigenen Services und die der eingebetteten Ge rte. a URLs f r die zeitgleichen Betriebsphasen der Steuerung, des Eventu managements und der Prsentation (control, eventing, presentation). a Beschreibung der Aktionen und Zustandsvariablen, die mit einem Service in Verbindung stehen. Control: Mit dem Abschluss der Description ist das UPnP-Netzwerk betriebsbereit. Ein Control Point kann nun ihm bekannte Serviceleistungen in Anspruch nehmen und Zustnde an den Gerten abfragen. In Form von a a


15

XML-SOAP Nachrichten werden Aktionsaufrufe an die Gerte-URL gea schickt. Das Gert arbeitet diese Befehle ab und reagiert mit Zustandsa anderungen. Eventing: Wenn sich ein Control Point als Listener bei einem Gert regia striert, so wird er durch ausgelste Events uber Anderungen von Statusvao riablen informiert. F r die Anmeldung an einem Service sendet er eine Subu scription Message an das Gert. Wenn das Abonnement angenommen wird, a deniert der Service die zeitliche Begrenzung und sendet diese Information an die Steuerinstanz zur ck. Um eine Weiterf hrung des Abonnements durch u u eine erneute Benachrichtigung oder die K ndigung vor der abgelaufenen Zeit u muss sich der Control Point selbst k mmern. Event-Nachrichten werden im u XML-Format GENA erstellt. Um Szenarien mit mehreren Control Points realisieren zu knnen, werden alle Abonnenten uber alle Eventvariablen und o deren Anderungen informiert. Dabei ist nicht relevant ob die Zustandsna derung aufgrund eines externen Aktionsaufrufes oder innerhalb des Gertes a zu Stande kommt. Presentation: Bei vielen Gerten ist eine Prsentations-URL enthalten, a a die in einem Control Point oder einem Webbrowser darstellen werden kann. Die HTML-Seite kann vom Hersteller frei gestaltet werden und kann auch als einfaches Userinterface dienen, das dem Benutzer die Steuerung des Gertes a und der Dienste erlaubt. Fazit UPnP wird aufgrund der Unterst tzung vieler Software- und Unterhaltungsu elektronikkonzerne mit groer Wahrscheinlichkeit zu einer Schl sseltechnou logie im Bereich der verteilten Heimnetzwerke heranwachsen. Es fehlt jedoch noch an konkreten Szenarien, die dem Endkunden die Vorteile verdeutlichen.

2.2.3

OSGi

Die Spezikation zu OSGi (Open Service Gateway Initiative) wird von der OSGi Alliance 13 , einem Zusammenschluss bedeutender Hard- und Softwarehersteller, darunter Sun Microsystems, IBM und Ericsson, getragen. Das OSGi-Framework deniert eine oene Service-Plattform f r vernetzte Dienu ste, die sowohl f r industrielle Anwendungen als auch f r den Einsatz beim u u Endkunden und in mobilen Umgebungen geeignet ist. Das Framework setzt auf einer Java Virtual Machine-Umgebung auf und wird folgenden Anforderungen gerecht (vgl. [37]):13

OSGi und OSGi Alliance - http://www.osgi.org/


16

Komponentenbasierte Architektur: Aufbauend auf einem Framework f r die Java-Plattform knnen modulare Softwareanwendungen (Bundles) u o installiert werden, die spezialisierte Services zur Verf gung stellen. u Integration bestehender Protokollstandards: Der generische Ansatz der OSGi Service-Denition erlaubt die Integration und Kommunikation mit bestehenden Standards verteilter Gerte und Dienste. Auch f r UPnP, Jini a u und Webservices sind Schnittstellen vorhanden. Dynamisches Management: OSGi-Bundles knnen zur Laufzeit admio nistriert werden. Die Funktionalitt f r die Installation, das Starten und das a u Stoppen von Bundles zur Laufzeit ist integraler Bestandteil des Systems. Integriertes Sicherheitsmodell: Die Softwarearchitektur von OSGi ermglicht eine strikte Trennung von Kompetenzen. Im Bundle-Kontext uno terscheidet man zwischen privaten Ressourcen und solchen, die uber eine oene Schnittstelle zur Verf gung gestellt werden und auch von anderen u Bundles benutzt werden d rfen. u

Kapitel 3

Gerte a3.1 Szenario

Um die Tauglichkeit von UPnP als Service-Plattform unter Beweis stellen zu knnen, m ssen vorher Anforderungen f r prototypische Implementierungen o u u deniert werden. Es soll geklrt werden, inwiefern die Technologie in einem a Mediensteuerungsszenario genutzt werden kann. Mit Blick auf die vielfla tige Unterhaltungselektronik eines Haushaltes ist schnell ein reichhaltiges Einsatzgebiet gefunden. So mchte man beispielsweise auch whrend der K chenarbeit nicht o a u auf den Musikgenuss verzichten m ssen. Zustzlich zur Stereoanlage im u a Wohnzimmer ist das Aufstellen eines weiteren Elektronikgertes, nur f r a u das Musikhren, jedoch alles andere als platzsparend und konomisch. Hinzu o o kommt, dass die jahrelang gepegte Mp3-Sammlung am PC im Arbeitszimmer ohnehin dem Radio vorgezogen wird. Obwohl die Inhalte uber das Netz werk auf einen PC mit Bildschirm in die K che ubertragen werden knnten, u o ist die Bedienung mehr als m hsam. Das Hantieren mit einer Maus passt in u keiner Weise zu den Ttigkeiten in der K che. Ein in die Wand integriertes a u Touchpanel w rde hier Abhilfe schaen, die Nutzung scheitert jedoch an der u Software des Medienplayers, dessen GUI mit den kleinen Bedienelementen nicht f r ein solches Szenario ausgelegt ist. u Zudem mchte man auch die Inhalte anderer, im Haus verteilter Gerte o a und Anwendungen in einem gemeinsamen Display darstellen und fernsteuern knnen, ohne sich uber deren Standorte Gedanken machen zu m ssen. o u Ebenso wie in diesem Fall nden sich in einem Haushalt viele Beispiele, in denen ein nahtloses Zusammenspiel zwischen Elektronikgerten Sinn maa chen w rde. Die Stereoanlage, der Fernseher, der DVD-Player und auch das u Raumlicht knnten unter einem gemeinsamen Standard und den entspreo chenden technischen Vorrausetzungen alle von einem mobilen Smart Phone aus gesteuert werden. Dar ber hinaus ernen mit Sensoren ausgestattete u o Embedded-Gerte und Bewegungsdetektoren neue Mglichkeiten, um Aba o

17

KAPITEL 3. GERATE

18

lufe zu automatisieren. Steht eine Person am Morgen auf, knnte dies von a o Drucksensoren am Boden registriert werden und eine Gebudesteuerung ina formieren, die das Licht in allen vordenierten Rumen einschaltet. Verlsst a a der Bewohner das Haus und geht zur Arbeit, wird eine Uberwachungskamera mit Bewegungsdetektor aktiviert, die, sobald eine Bewegung registriert wird, eine E-Mail mit einem Standbild der Kamera an den Benutzer schickt.

3.2

Konzept

Alle diese Szenarien zeigen, dass Mediengerte durch die Unterst tzung vera u teilter Netzwerke nicht mehr nur als eigenstndige Dienste betrachtet wera den knnen, sondern gerade durch ihre vielfltigen Vernetzungsmglichkeio a o ten eine neue Servicequalitt bieten. Die drahtlosen und netzwerkfhigen a a Gerte hierf r sind mit PCs, PDAs, Touchpanels und Mobiltelefonen vora u handen. Auch Unterhaltungselektronik wird vermehrt mit Netzwerkfunktionalitt ausgestattet. Mit einer gemeinsamen Service-Plattform f r die a u Dienste wird eine Trennung zwischen dem Standort eines Gertes und desa sen grascher Reprsentation zur Fernsteuerung mglich. Die Inhalte der a o verschiedenen Anwendungen knnten dann uber ein gemeinsames, an das o Darstellungsgert angepasstes, User Interface gesteuert werden. Aus diesen a Ideen ergeben sich mehrere Komponenten, die zum Aufbau solcher Szenarien bentigt werden: o Gerte: F r das oben erwhnte Szenario m ssen UPnP-fhige Harda u a u a und Softwaregerte gefunden oder selbst entwickelt werden. a GUI-Builder: Genauso wie mit UPnP ein gemeinsames Steuerprotokoll f r verteilte Gerte vorhanden ist, muss ein Weg zur automatiu a sierten Generierung von User Interfaces zur Fernsteuerung der Netzwerkgerte gefunden werden. Der Ansatz sollte sowohl auf mobilen a Endgerten als auch auf PC-Systemen angewendet werden knnen. a o Framework zur Kopplung verteilter Gerte: Auf Basis von UPnP a als Service-Plattform muss ein System zur Verkn pfung von verteilu ten Gertediensten geschaen werden. Damit kann ein UPnP-fhiges a a Sensorgert etwa Drucksensorwerte zur Steuerung der Bedienelemente a eines Medienplayers liefern. Mglich wird dies durch die dezentrale o Architektur des Torem Frameworks [39], einer UPnP-Controlpoint Instanz, die Gerte im Netzwerk nden und ansteuern kann. Torem a erlaubt es dem Benutzer mit einem graschen Editor ereignisorientierte Zustandsvariablen und Ein- und Ausgabeparameter von UPnPAktionen miteinander zu verkn pfen, um Szenarioablufe zu denieren u a (siehe Abb. 3.1).

KAPITEL 3. GERATE

19

Abbildung 3.1: Torem - Ein Framework zur Kopplung verteilter UPnPGerte. Der Benutzer kann aus allen vorhandenen Gerte und zustzlichen a a a Kontrollusskomponenten, wie If -Bedingungen und Schleifen eine Ereigniskette denieren [39].

3.3

UPnP-Technologie

Als Grundlage f r die Entwicklung der Gerte und GUI-Builder Steueranu a wendung wird eine Bibliothek bentigt, die die Besonderheiten der UPnPo Technologie abstrahiert und die Implementierung von Gerten und Controla point-Instanzen ermglicht. Die Cyberlink UPnP Bibliotheken1 des japao nischen Programmierers Satoshi Konno ist in den Programmiersprachen u a C/C++ und Java verf gbar. Zustzliche Beispielanwendungen und ein rudimentrer Controlpoint zum Steuern der Gertedienste sind ebenfalls vora a handen. Die Java-Variante dieser Bibliothek wurde f r die Entwicklung ausu gewhlt, da sie schon mehreren Revisionen unterzogen wurde und eine ubera sichtliche und gut abstrahierte Klassenstruktur bietet.

3.4

Implementierung

F r das Szenario werden Eingabegerte und verteilte Anwendungen benu a o tigt. UPnP speziziert trotz der breiten Herstellerunterst tzung zum geu1

Cyberlink UPnP Bibliotheken http://www.cybergarage.org/net/

KAPITEL 3. GERATE

20

gebenen Zeitpunkt wenige Gerte-Standards2 , die f r die Mediensteuerung a u von Interesse sind. Neben Standards f r Scanner, Drucker, Modems und u Router passen eine Uberwachungskamera und eine AV MediaServer/MediaRenderer-Architektur [12] besser in das Konzept. Mit dem Philips SL300i3 stand ein WLAN-Client zur Verf gung, der Audio- und Videoformate vom u PC auf den Fernseher streamen kann. Das Produkt implementiert jedoch nur die wichtigsten der spezizierten Funktionen und ist damit nur eingeschrnkt a bedienbar. Mit Hilfe softwarebasierter Adapter konnte weitere Hardware UPnP-fhig gemacht werden. Dazu zhlen ein mit acht Drucksensoren ausa a gestatteter Mikrocontroller mit LAN-Anschluss und ein Streaming-Server, der das Video einer Webcam zu einem Client ubertragen kann und dort Be wegungsdetektion ermglicht. Auch der MIDI-Protokollstandard4 und der o Winamp Media Player konnten mit UPnP-Funktionalitt gekapselt werden. a

3.4.1

Sensor-Hardwaredevice

Anforderungen Um ein alternatives Eingabegert f r das Steuerungsszenario zu erhalten, a u wurde nach einer Mglichkeit zur Integration von Sensoren gesucht. Dazu o wird ein hardwarenahes System bentigt, das den Anschluss von Sensorik an o einen Analog-Digital Wandler erlaubt und die gemessenen Spannungswerte der Sensoren ins UPnP-Netzwerk exportieren kann. Um die Anbindung an das Netzwerk zu ermglichen, sollte eine schlanke C/C++-Bibliothek gefuno den werden, die einen UPnP-Stack f r performanceschwache Systeme imu plementiert. In netzwerktechnischer Hinsicht muss das Gert einen TCP/IP a Stack integrieren und den Zugri uber ein LAN-Modul mit RJ45-Anschluss oder eine WLAN-Schnittstelle erlauben. Im besten Falle sollte das Gert a auch geringen Stromverbrauch garantieren oder mit Batterie betrieben werden. Hinsichtlich frei verf gbarer Software wurden folgende UPnP-Bibliotheu ken f r die Entwicklung in Betracht gezogen: u Intel Software for UPnP Technology: Intels UPnP-Implemenu tierung5 ist eine Sammlung an Softwarepaketen f r die Entwicklung und das Testen UPnP-fhiger Anwendungen. Das Authoring Toolsa Paket enthlt einen automatisierten Device-Builder, der anhand funka tionaler XML-Gertebeschreibungen portablen Programmcode in C aUPnP Gerte-Standards - http://www.upnp.org/standardizeddcps/ a Philips Streamium (UPnP AV MediaRenderer) - http://www.streamium.philips.com/ 4 Musical Instrument Digital Interface (MIDI) ist ein Steuerprotokoll f r digitale Muu sikinstrumente, wird aber auch f r Mediensteuerungen und k nstlerische Installationen u u gerne eingesetzt. - http://www.midi.org/ 5 Intel Software for UPnP Technology - http://www.intel.com/cd/ids/developer/ asmo-na/eng/downloads/upnp/3 2

KAPITEL 3. GERATE

21

generiert. Jedoch ist dieser Code nur f r Microsoft Windows, Pocketu PC und Linux ausgelegt. Linux UPnP-SDK: Ein UPnP-SDK f r Linux6 wird als Open Source u Software zur Verf gung gestellt. Die Einarbeitungszeit in ein Embeddedu Linux System ist f r den kleinen Teil des Szenarios allerdings nicht u gerechtfertigt. Cyberlink: Neben der Java-Variante wird von Cyberlink auch eine C++und eine C-Bibliothek bereitgestellt. Aufgrund der umfassenden Klassenstruktur und der mehrfachen Threads kann die C++-Implementierung nicht auf einem hardwarenahen System eingesetzt werden. Die C-Bibliothek hingegen ist dezidiert f r mehrere Embedded-Systeme u ausgelegt. Doch auch hier konnte f r die unterst tzten Betriebssyu u 7 und uTRON 8 kein bekanntes Hardwareboard gefunsteme T-Engine den werden. Auf der Suche nach entsprechender Hardware stellte sich heraus, dass kein greifbares Gesamtsystem die Anforderungen hinreichend erf llt und in u kurzer Zeit die Erstellung eines Prototyp ermglicht: o AVR Embedded Internet Toolkit: Mit dem Embedded Internet u u Toolkit 9 konnte ein System gefunden werden, das ausdr cklich f r Industral Control und Home Appliances ausgelegt ist und neben einen TCP/IP-Stack auch aufbauende Protokolle, wie DHCP, HTTP und FTP unterst tzt. Jedoch sind die Anforderungen C++-basierter UPnPu Bibliotheken f r einen Mikrocontroller mit 128Kb dynamischem Flashu Speicher und 1MB Festspeicher zu wenig, um Features wie XMLVerarbeitung, das Steuerprotokoll SOAP und die Multi- und BroadcastProtokolle f r die automatische Gerteerkennung zu unterst tzen. Eine u a u Portierung der Cyberlink C-Bibliothek auf die gngige ARM -Mikroa prozessorarchitektur10 wre mit einigem Zeitaufwand allerdings denka bar. Sindrion: Sindrion ist eine verteilte Systemarchitektur rund um einen Chip mit niedrigem Energieverbrauch, der von der Firma Inneon11 mit dem Ziel eines kosteng nstigen Sensornetzwerkes entwickelt wurde u [30]. Im Sindrion-Konzept wird explizit auch die Integration in dieLinux UPnP-SDK - http://upnp.sourceforge.net/ Embedded OS: T-Engine - http://www.t-engine.org/ 8 Embedded OS: uTRON - http://www.utron.net/ 9 AVR Embedded Internet Toolkit - http://www.atmel.com/dyn/resources/prod documents/doc2493.pdf 10 Die ARM-Architektur ist ein Designspezikation f r eine Reihe an 32-bit Mikroprou zessoren, die dem RISC-Konzept folgen. - http://www.arm.com/ 11 Inneon - http://www.inneon.com/de/7 6

KAPITEL 3. GERATE

22

UPnP-Serviceplattform erwhnt. Demnach ist ein Sindrion Wirelessa Transceiver eine Gert, das einen reduzierten UPnP-Stack implemena tiert und Kontakt zu einer Terminal-Software hlt, die den fehlenden a Teil der Netzwerkkommunikation ubernimmt und so in Kombination ein vollwertiges UPnP-Gert reprsentiert [21]. Der Ansatz von Sina a drion erscheint vielversprechend. Allerdings bendet sich die Technologie noch in der Entwicklungsphase. Sun SPOT: Das Forschungsprojekt Sun SPOT 12 der Sun Microsya stems Laboratories13 ist ein Batterie betriebenes Hardwaregert zum Anschluss von Sensoren. Das ARM-basierte Mikroprozessorboard ist mit Solarzellen und mit einem drahtlosen Funksender nach dem Standard IEEE 802.15.414 ausgestattet und kann als Informationsquelle in intelligenten Netzwerken eingesetzt werden. Die Besonderheit des Konzeptes liegt in der Kombination aus robuster Hardware und Suns hauseigener, objektorientierter Programmiersprache Java, die mit CLDC 1.1 den Standard einer vollwertigen, mobilen Virtual Machine implementiert. Als Termin f r die Produktreife von Sun SPOT wird aber u erst der Sommer 2006 angegeben. Systemaufbau Schlielich wurde ein prototypisches Hardwaredevice der Firma Ubitronix 15 eingesetzt. Das Gert basiert auf einem Texas Instrument MSP430 -Mikroa a controller16 , der einen 8-Port Analog-Digital Wandler integriert. Zustzlich ist ein mit dem Lantronix XPort 17 ein Ethernet-Modul angebracht, das die Netzwerkkommunikation ermglicht. Am Gert wurden acht Drucksensoren o a angebracht und so konguriert, dass der Wandler je nach Druckstrke einen a skalierten Wert zwischen 0 und 4000 zur ck liefert. Mit einem proprietren, u a TCP/IP-basierten Kommunikationsprotokoll kann das Gert im Netzwerk a angesprochen werden. Es deniert eine Folge an Befehlen im Byte-Format um die acht Sensorwerte auslesen zu knnen. o Ein Zyklus einer Sensorabfrage (Abb. 3.2) sieht vor, dass zuerst ein request-Befehl an das Gert gesendet wird. Das Hardwaredevice besttigt a a diese Anfrage (acknowledge) und teilt dem PC mit, dass es Daten senden will (send). Ist der PC damit einverstanden (ack), sendet das Gert die era mittelten acht Sensorwerte mit je 2 Byte Lnge zur ck (sensordata). Trotz a uSUN Spot - http://www.sunspotworld.com/ Sun Microsystems Laboratories - http://research.sun.com/ 14 IEEE 802.15 WPAN Task Group 4 ist ein Arbeitsgruppe zur Spezizierung von Kurzstrecken-Funktechnik in Wireless Personal Area Networks - http://www.ieee802.org/ 15/pub/TG4.html 15 Ubitronix - http://www.ubitronix.com/ 16 Texas Instrument MSP430 Mikrocontroller - http://www.ti.com/msp430 17 Lantronix XPort http://www.lantronix.com/device-networking/embedded-device-servers/xport.html13 12

KAPITEL 3. GERATErequest ack send ack sensordata ack

23

PC

Hardware Device

Abbildung 3.2: Die Abbildung zeigt die Befehlskette einer Sensorabfrage zwischen dem PC und dem Hardware-Modul.

des aufwendigen Protokolls, das nicht nur f r die Sensorabfrage entworfen u wurden, zeigte sich der Prototyp als robustes Eingabegert, das auch nach a tagelangem Einsatz noch einwandfrei funktioniert. F r die Integration ins UPnP-Netzwerk wurde eine Adapteranwendung u am PC implementiert, die eine persistente Verbindung zum Hardwaredevice hlt und auf eine GetSensor-Aktionsanfrage eines UPnP-Controlpoints a die acht Sensorwerte ermittelt und in Form eines XML-formatierten Strings zur ck liefert. u Mit dieser Implementierung wurde die UPnP-Welt des Szenarios um ein physisches Eingabegert bereichert. Welche Funktionen die Sensoren erf la u len, ist Teil des Mappings zwischen zwei UPnP-Diensten, wie sie im ToremFramework deniert werden kann. So kann unter anderem folgendes Verhalten festgelegt werden: Wenn der Wert des Sensors1 kleiner 2000 ist, dann soll der Play-Befehl eines Medienplayers ausgef hrt werden. Ein erweiteru tes Szenario knnte auch eine Passwortabfrage anhand einer bestimmten o Abfolge an gedr ckten Sensoren realisieren. Mit dem Hardwaredevice ist die u Integration vieler, weiterer Sensortypen, wie Temperatur-Sensoren, DistanzSensoren, Magnetfeld-Sensoren, etc. denkbar, da sie am gleichen Gert ana gebracht werden knnen und die Bedeutung eines Sensors erst durch dessen o semantische Verkn pfung deniert wird. u

3.4.2

Webcam Streaming-Server und Client

F r die Entwicklung eines weiteren Eingabegertes wurde eine Streaming u a Server/Client-Architektur entworfen, die das Video einer serverseitig angeschlossenen Webcam im Netzwerk bereitstellt. Die Idee ist, einen UPnPbasierten Server zu schaen, dessen Konguration im Netzwerk vorgenommen werden kann. Neben der Mglichkeit zum Auslesen und Setzen der o URL des Videostreams kann der Servers vom Netzwerk aus gestartet und gestoppt werden. Ein ebenfalls UPnP-fhiger Client besitzt dieselben Mga o lichkeiten, allerdings zum Empfang des Videosteams. Der Streaming Client

KAPITEL 3. GERATE

24

ermittelt uber UPnP automatisch das Vorhandensein eines Servers, liest dessen Videostream-URL aus und nutzt sie, um sich selbst zu kongurieren und zu starten. Zustzlich ist am Client eine simple Bewegungserkennung a (motion detection) implementiert, die auf Anderungen des Videobildes reagiert und diese Information uber zwei Wege auch einem UPnP-Controlpoint zugnglich macht. Zum einen ist eine ereignisorientierte boolsche Variable a MotionDetected deniert, die R ckmeldung uber den aktuellen Status des u Videobildes. Als zweite Manahme wird zum Zeitpunkt der Bewegung das Bild des aktuellen Videoframes abgespeichert und uber einen Webserver zu gnglich gemacht, dessen URL wiederum mit der UPnP-Aktion GetLastMoa tionImage bekanntgegeben wird. Systemaufbau F r die Implementierung der Streaming-Architektur wurde das Java Meu u dia Framework 18 (JMF, Version 2.1.1e), eine Java-basierte Bibliothek f r die Medienverarbeitung, herangezogen. JMF ermglicht den Zugri auf die o Daten, der am PC angeschlossenen Audio- und Videohardware und abge speicherter Medienformate. Durch die Entwicklung von Plugins knnen Ano derungen in den Datenstrmen der Verarbeitungskette vorgenommen wero den, die sich aus einer Datenquelle, einem Prozessor und einer Datensenke zusammensetzen. Sowohl Datenquelle als auch Datensenke sind abstrakte Bezeichnungen f r Ein- und Ausgabeinstanzen. Dazu zhlen neben Geru a a ten wie Videokamera und Bildschirm ebenso ein Netzwerkstream oder eine Mediendatei. Der Streaming Server und der Client verwenden eine annhernd identia sche Klassenstruktur, die in drei Bereiche unterteilt ist: net.digidop.upnp.device.rtpapp: Dieses Packet deniert das Zustandsmodell der Applikation, die Anbindung an das Netzwerk als UPnP-Gert. F r den Client ist zustzlich auch eine UPnP-Controla u a point integriert, der zur Aundung des Servers bentigt wird. o net.digidop.upnp.device.rtpserver.business: Diese Schicht deniert Business-Objekte zum Aufbau der JMF-Verarbeitungskette, der Instanzierung des medienverarbeitenden Prozessors und der Generierung einer graschen Komponente f r das Videovorschaubild. u net.digidop.upnp.device.rtpserver.ui: Das Packet enthlt Klasa sen f r das GUI und die Kongurationsoptionen, die auch uber das u Netzwerk gendert werden knnen. a o18

Java Media Framework API - http://java.sun.com/products/java-media/jmf/

KAPITEL 3. GERATE

25

Bevor eine Verarbeitung am Client erfolgt, muss der Processor konguriert werden. Anhand der vom Server ermittelten Multicast 19 -URL des Videostreams wird ein MediaLocator angelegt, der zusammen mit einem globalen Manager eine Instanz des Processors erzeugt. Im Anschluss kann eine Liste an beliebigen Plugins in die Verarbeitungskette eingegliedert und die Datensenke an eine GUI-Applikation angebunden werden. Der einfache Motiondetection-Algorithmus FxMotionDetection reagiert auf die durchschnittliche Intensittsnderungen eines Bildes. Hat sich der ermittelte Wert a a im Vergleich zum vorgehenden Videoframe stark verndert, wird eine Bewea gung registriert und die MotionDetected-Zustandsvariable auf TRUE gesetzt. Sobald der Algorithmus im nchsten, zehnten Frame keine Bewegung mehr a registriert, wird der Wert wieder auf FALSE gesetzt.1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

/* * Berechnung von d i v i d e d S u m o f D i f f e r e n c es als Durchschnitt sw e rt * der Intensit ts n de r un g zweier Frames mit Abstand 10 a a */ if (( frameCount % 10) == 0) { if ( motionDetecte d ) { motionDetecte d = false ; } else { clientDevice . trackingVar . setValue ( " FALSE " ); } } if ( d i v i d e d S u m o f D i f f e r e n ce s > treshold && ! motionDetecte d ) { motionDetecte d = true ; clientDevice . trackingVar . setValue ( " TRUE " ); }

Die Verarbeitung des RTP-Streams20 erfolgt mir 15 Bildern pro Sekunde. Der Algorithmus f r die Bewegungserkennung ist sehr einfach aufgebaut. u Die Flexibilitt des Systems erlaubt es aber, dass mit wenig Aufwand ein a robusteres Verfahren, das etwa auch gegen Helligkeitsschwankungen resistent ist, implementiert werden kann. Auch die Nutzung von videobasiertem Tracking scheint in diesem Kontext denkbar. Mit dem Streaming Server (siehe Abb. 3.3) und Client wurde eine kosteng nstige Variante einer Uberu wachungskamera geschaen, die ohne zustzlichen Kongurationsaufwand a betrieben werden kann.Multicast bezeichnet in der Netzwerkkommunikation eine Nachrichten bertragung u von einem Punkt zu einer Gruppe. In IPv4 ist hierf r der Adressbereich 224.0.0.0 bis u 239.255.255.255 (Klasse D) reserviert 20 Das Real-Time Transport Protocol ist ein Protokoll zur kontinuierlichen Ubertragung von audiovisuellen Daten (Streams) uber IP-basierte Netzwerke 19

KAPITEL 3. GERATE

26

Abbildung 3.3: Die Abbildung zeigt die UPnP-fhige Streaming Server a Applikation mit dem Videobild der Webcam. Im rechten Bild ist das Fenster f r die Webcam-Einstellungen zu sehen. u

3.4.3

UPnP-Winamp Media Player

Um auch ein Gert zum Abspielen von Musik anzusteuern zu knnen, wurde a o der Winamp Media Player 21 in der Version 2.91 mit einem Softwareadap ter an UPnP angebunden. Neben der Uberlegung ein umfangreiches C++basiertes Plugin auf Basis der Winamp SDK22 und der Cyberlink UPnPBibliothek zu entwickeln, wurde mit httpQ 23 ein netzwerkbasiertes Plugin gefunden, das die Funktionen von Winamp uber den Zugri via HTTP GET URL ermglicht. Daf r wurde in Java ein Adapter entwickelt, der o u diese Funktionen ins UPnP-Netzwerk exportiert und Steuerzugrie in den httpQ -Befehlssatz umsetzt. Neben der Steuerung der Abspielelemente kann auch die Zeit, die Lautstrke und Auskunft uber die geladene Playlist und a den aktuellen Song ermittelt und gesetzt werden. In der Klasse HttpQAdapter sind alle Befehle deniert und knnen mit processCmd ausgef hrt o u werden. F r das Starten des Players wird etwa folgender String aus dem u Play-Befehl und einem geforderten Passwort zusammengesetzt und ausgef hrt: http://localhost:4800/play?p=pass. u

3.4.4

MIDI-Device

F r die Ubertragung von MIDI-Steuerbefehlen wurde mit Hilfe des LoopBe1 u MIDI-Treibers24 , einer virtuellen MIDI-Kabelverbindung am PC, ein UPnPAdapter f r das Windows Betriebsystem entwickelt. Damit knnen alle softu o21 22

Winamp Media Player - http://httpq.sourceforge.net/ Winamp Plugin Development Center- http://www.winamp.com/nsdn/winamp/plugins/ 23 httpQ Network Protocol - http://httpq.sourceforge.net/ 24 LoopBe1 Virtual MIDI Driver - http://www.nerds.de/en/loopbe1.html

KAPITEL 3. GERATE

27

warebasierten Klangerzeuger wie Reaktor25 angesprochen werden. Der Adapter sendet mit Hilfe der Java-MIDI API javax.sound.midi Steuerbefehle an die virtuelle Schnittstelle LoopBe1. Wird der Treiber in einem Klangerzeuger als MIDI-Eingabegert ausgewhlt, so leitet er die eintreenden a a Befehle direkt an dieses weiter. Uber die installierten MIDI-Treiber der Soundkarte des PCs knnen auch externe Gerte angesprochen werden. o a Das MIDI-Protokoll deniert eine Reihe an Steuernachrichten mit unterschiedlicher Parameteranzahl. Mit dem Befehlen NOTE_ON und NOTE_OFF und dem Parameter der Tonhhe kann beispielsweise ein Tastendruck auf o einem Klavier simuliert werden. Die Tondauer wird durch das Zeitintervall zwischen den beiden NOTE-Befehlen festgelegt. Diese Funktionalitt wird in a einem UPnP-Gert gekapselt, das eine SetNote-Aktion implementiert. Als a Eingabeparameter verlangt sie einen MIDI-kompatiblen Tonhhenparameo ter zwischen 0 127. Ist das virtuelle MIDI-Gert an einen Klangerzeuger a gekoppelt, wird ein Tastendruck mit der Dauer von 100 ms simuliert. Dies f hrt bei den Kongurationen der meisten virtuellen Synthesizer zur Ausu gabe eines Tons. Obwohl mit diesem Ansatz bislang nur ein Teil des MIDI-Protokolls implementiert ist, demonstriert es die Integration eines breiten Spektrums an zustzlicher Hard- und Software, die mit diesem Protokoll arbeiten. Vor ala lem hinsichtlich neuer Eingabemedien scheint dieses Konzept interessant, da zahlreiche MIDI-Controller mit integrierten Tasten, Drehknpfen, Touchpao nels und Schiebereglern f r die Steuerung verteilter Gerte bereitst nden u a u und nicht nur im musikalischen Kontext verwendet werden knnten. Ein o Beispiel f r solche Gerte sind alternative Controller-Produkte26 der deutu a schen Firma Dpfer27 . o

Native Instruments Reaktor - http://www.native-instruments.com/index.php?id= reaktor5 us 26 Eine Liste alternativer MIDI-Controller - http://www.stoelshome.de/alt controller/ alt midi controller.html 27 Dpfer MIDI-Controller - http://www.doepfer.de/home d.htm o

25

Kapitel 4

Generierung grascher User InterfacesEine groe Herausforderungen in der Softwareentwicklung ist das Design von Schnittstellen zwischen Mensch und Maschine. Erklrtes Ziel beim Enta wurf eines Interfaces ist es, Daten und Funktionalitten einer Applikation a in einer abstrahierten Form zu prsentieren und dem Benutzer einfache Ina teraktionsmglichkeiten anzubieten. In diesem Zusammenhang befasst sich o der Human-Computer Interface (HCI) Forschungsbereich neben traditionellen graschen Oberchen (Graphical User Interface oder einfach GUI ) f r a u Endgerte mit Display auch mit alternativen, physischen Eingabegerten a a unter dem Begri Tangible Interfaces, die nicht Gegenstand der vorliegenden Arbeit sein sollen. Vielmehr soll erlutert werden, warum das Design a und die Implementierung von GUIs auch Jahrzehnte nach deren Aufkommen keine triviale Aufgabe darstellt [27]. Die Bringschuld des Softwareentwicklers besteht darin, User Interfaces unter Ber cksichtigung der Benutzererwartung, hinsichtlich der Bedienung u einer Software, zu gestalten. Abhngig von verschiedenen Faktoren wie dem a Alter des Benutzers und dem IT-Vorwissen kann dies zu den unterschiedlichsten Bed rfnissen f hren. Ein Graker, dessen tgliches Arbeitswerkzeug u u a ein Bildbearbeitungsprogramm ist, sucht nach Wegen um wiederkehrende Ablufe standardisieren zu knnen und schnellstmglichen Zugri auf alle a o o ihm zur Verf gung stehenden Funktionen zu haben. Ein Anfnger hingeu a gen mchte aller Voraussicht nach schrittweise in das Programm eingef hrt o u werden und wenige f r ihn wichtige Operationen ausf hren knnen, ohne u u o sich in einer Ansammlung von Men eintrgen und Mehrfachbelegungen von u a Buttons zu verlieren. Unterst tzung im Entwicklungsprozess erfhrt der Programmierer dabei u a von Seiten psychologischer Studien hinsichtlich dem Nutzerverhalten und der Gebrauchstauglichkeit der Software. Diese Art der Evaluierung durch Beobachtung von Benutzern und ihren Gewohnheiten wird durch den Be28

KAPITEL 4. GENERIERUNG GRAFISCHER USER INTERFACES 29 gri Usability geprgt. Zustzliche Schwierigkeiten knnen sich durch die a a o Einbeziehung Kontext-sensitiver Informationen in die Anwendung ergeben. Je mehr unvorhersehbare Anwendungsbereiche und Gerteumgebungen gea geben sind, desto vielschichtiger sind die Abhngigkeiten, die es in der Softa ware und dem GUI-Design vorab zu bedenken gilt. Dadurch werden eine Reihe wichtiger Fragen aufgeworfen. Im Mittel punkt dieser Uberlegungen steht die Suche nach uberzeugenden Methoden um konsistente und benutzerfreundliche Schnittstellen entwickeln zu knnen: o 1. Welche allgemeing ltigen Qualittskriterien sind im GUI-Design deu a niert und wie knnen sie angewandt werden? o 2. Welche Anforderungen werden bei der GUI-Entwicklung an den Entwickler herangetragen? 3. Welche gesonderten Anforderungen werden durch die Verbreitung mobiler Endgerte, ubiquitrer Technologien und die Ad-hoc-Vernetzung a a generiert? 4. Welche unterst tzenden Konzepte und Werkzeuge kommen in der Prau xis zum Einsatz?

4.1

Anforderungen im GUI-Design

In [27] werden allgemeine Aspekte aufgelistet, die es beim Design jedes graschen Interfaces zu beachten gilt: Standards und Richtlinien: Ebenso wie in anderen Disziplinen haben sich auch im Interface-Design bewhrte Konzepte durchgesetzt, die sich als a Richtlinien f r heutige GUI-Applikationen etabliert haben. Dazu zhlen Fenu a ster, Men leisten und Besttigungs-Dialoge ebenso, wie Layout-spezische u a Konventionen. Das Schlieen einer Applikationen oder das Onen einer Datei, werden als Hauptfunktionen in verschiedenen Applikationen an der gleichen Stelle zu nden sein. Dem Benutzer wird dadurch die Mglichkeit gegeo ben, sich an bereits erlernten Metaphern orientieren zu knnen. Das selbsto verstndliche Vorhandensein von Maus, Tastatur und einer graschen Obera che bei PC-Systemen zeigt, dass sich aus den Ideen zu Eingabegerten a a schnell Standards entwickeln knnen. o F r die grasche Aufbereitung, die das Layout der Komponenten, den u Schriftsatz und die Farbwahl beinhaltet, werden von allen wichtigen Betriebssystemherstellern wie Microsoft1 und Apple2 Guidelines deniert. Neben einem konsistenten Look and Feel ist dies auch auf die Tatsache zur cku zuf hren, dass das moderne Betriebsystem grundlegende Zeichenoperationen uMicrosoft User Interface Design and Development - http://msdn.microsoft.com/ui/ Apple Human Interface Guidelines - http://developer.apple.com/documentation/ UserExperience/Conceptual/OSXHIGuidelines/2 1

KAPITEL 4. GENERIERUNG GRAFISCHER USER INTERFACES 30 mit Hilfe eigener Window Manager zur Verf gung stellt. Eine Vielzahl weiter u Publikationen beschftigt sich mit Richtlinien f r Interaktionsdesign [8, 34] a u und auch f r grasches Design [4]. Aufgrund der Vielfalt und Komplexitt u a von Softwaresystem und dem unvorhersehbaren Nutzerverhalten lassen sich diese Anstze nicht in einer allgemeing ltiger Theorie postulieren. Gutes a u Design liegt demnach zu einem groen Teil noch immer in den Hnden des a Designers. Anpassungsfhigkeit und Hilfestellung: Trotz des Bestrebens robua ste, einfach zu bedienende Software zu entwickeln, kann es zu Situationen kommen, in denen eine Fehlerbehandlung unvermeidlich ist. Die Art wie der Benutzer davon in Kenntnis gesetzt wird, ist ein Indikator f r die Qualitt u a der Anwendung. Programmatische Fehlermeldungen stehen hier in starkem Gegensatz zum Versuch, dem Benutzer die Handhabung der Software zu erklren oder im besten Fall die entstandene Problematik programmintern zu a lsen. Ein schwerwiegender Irrtum wre es, in diesem Zusammenhang vom o a Fehlverhalten des Benutzers zu sprechen, da das oberste Prinzip die Unterst tzung des Benutzers in seiner Ttigkeit sein soll [8]. Die Internationalisieu a rung von Anwendungen ernet besseren Zugang zu spezischen Benutzero gruppen und verlangt mehr als nur die Ubersetzung von Textinhalten. Auch externe Faktoren wie lokale Kulturein sse, soziale und rechtliche Gegebenu heiten, spezielle Zahlenformate und Layoutbedingungen m ssen ebenso wie u Anforderungen f r Zielgruppen mit besonderen Bed rfnissen ber cksichtigt u u u werden. Um eine gute Handhabung eines Interfaces zu erreichen, muss das Navigationskonzept schl ssig und die Anordnung der Elemente konsistent u sein. Der Benutzer muss zudem jederzeit uber den Zustand des Systems in formiert sein, die Kontrolle haben und bei Interaktionen in k rzester Zeit u Feedback erhalten.

4.24.2.1

Anforderungen im Pervasive ComputingKontext-sensitive und verteilte Anwendungen

Das Aufkommen mobiler Endgerte und eingebetteter, smarter Technoloa gien erweitert mit ebenso groer Tragweite den Horizont der computeri sierten Wahrnehmungswelt, wie einst der Ubergang zwischen dem Zeitalter des zentralisierten Mainframe-Computing hin zur Ara des Desktop-PCs. Die Erfassung Kontext-sensitiver Informationen durch Gerte, die mit Sensoren a ausgestattet sind, erlaubt heute schon eine engere Bindung der Anwendung an die unmittelbare Umgebung (location-based services). Bis der Wunschtraum einer ubiquitren Welt nach Mark Weiser [40], in der der Benutzer a keinen unmittelbaren Kontakt mehr zu technischen Gerte hlt, Wirklicha a keit werden kann, m ssen essentielle Fragen hinsichtlich Energieversorgung, u

KAPITEL 4. GENERIERUNG GRAFISCHER USER INTERFACES 31 einheitliche Kommunikationsstandards und auch dem Design solcher intelligenter Gegenstnde geklrt werden. a a Durch die Mobilitt wird das Paradigma der verteilten Anwendung und a spontaner Vernetzung gestrkt. Die physische Trennung von Applikationsa logik und grascher Reprsentation erlaubt es auch leistungsschwachen Gea rten aufwendige Aufgaben zu erledigen. Diese knnen im Hintergrund von a o Serverdiensten abgearbeitet werden und m ssen lediglich f r die Synchroniu u sation der Information des GUI-Client sorgen.

4.2.2

Gerteeigenschaften a

Die gestiegene Performance und Speicherkapazitt bei mobilen Gerten era a laubt die Darstellung grascher Inhalte auf Farbdisplays, die bis vor kurzem noch Desktop-Systemen vorbehalten waren. Mobile Betriebsysteme wie u Windows Mobile3 und Symbian4 und system bergreifende Entwicklungsplattformen wie Microsoft .NET5 und die Java 2 Platform, Micro Edition u u (J2ME)6 bieten mit graschen Toolkits Unterst tzung f r einfache GUIProgrammierung. Eine weitere Eigenschaft der neuen Gerteklassen sind spezialisierte Eina und Ausgabehardware. Auf Seiten der Interaktionstechniken reicht die Palette von wandgroen Displays uber ber hrungsempndlichen Touch Screens u und PDAs mit Bedienstift (stylus) bis hin zu Mobiltelefonen mit mehrfachbelegten Funktionstasten und Joystick oder Richtungstaste f r die Navigau tion. Durch Wegfall von Maus und Tastatur muss die Navigation durch das User Interface anders ausgelegt sein. Am Beispiel einer einfachen Texteingabe lsst sich der Paradigmenwechsel leicht erklren. Durch die Popularia a tt des Short Message Services (SMS ) zeigt sich, dass es dem Konsumenten a selbst am Mobiltelefon ein Bed rfnis ist, Texte zu verfassen. Das neue Beu dienungskonzept, das f r wenigen Tasten mehrfache Buchstabenbelegungen u erfordert, wird trotz der oensichtlichen Nachteile in Kauf genommen. Am PDA ist die selbe Funktionalitt in mehrfacher Ausf hrung vorhanden: Der a u Bedienstift kann dazu benutzt werden, um Zeichen, die auf einer im Display sichtbaren Tastatur aufgereiht sind, anzuwhlen. Eine neue Form der Intera aktion bieten die Zeichenerkennung per Handschrift. Als weitere Mglichkeit o bieten sich externe Eingabegerte wie das Virtual Laser Keyboard7 an, das a mittels einer Laserprojektion ein Standard-Tastaturlayout auf die Tischoberche zeichnet. Auch die Forschung mit Spracherkennung und Analyse von a Videobildern mittels integrierter Kamera lassen auf zuk nftige, alternative uWindows Mobile - http://www.microsoft.com/windowsmobile/ Symbian OS - http://www.symbian.com/ 5 .NET Compact Framework - http://msdn.microsoft.com/netframework/programming/ netcf/ 6 Java Micro Edition - http://java.sun.com/javame/ 7 Virtual Laser Keyboard - http://www.virtual-laser-keyboard.com/4 3

KAPITEL 4. GENERIERUNG GRAFISCHER USER INTERFACES 32 Interaktionstechniken hoen. Alle Gerte verf gen mittlerweile uber Farbdisplays in unterschiedlichen a u Ausf hrungen. Die Ausung und Skalierung des Displays hat ebenfalls siu o gnikante Auswirkungen auf die Anzahl und Anordnung der graschen Elemente die in einem GUI dargestellt werden knnen [26]. Die Bandbereite o reicht von kleinen Mobiltelefon-Displays bis zu hochausenden Bildschiro men. Trotz des Vorhandenseins gemeinsamer, grascher Toolkits kann aufgrund der Varianten bei Ein- und Ausgabegerten nicht jeder grasche Inhalt a gleich reprsentiert werden. Erschwerend kommt noch hinzu, dass nicht eina mal gemeinsame Gerteklassen uber gleiches Hardwarelayout verf gen und a u Standards in dieser, bedingt durch den groen Wettbewerb, heterogenen Landschaft nur sehr schwer Fu fassen. Die Entwicklung von Plattform- bergreifenden Applikationen in pervau siven Umgebungen erfordert neue Konzepte im Umgang mit Software und deren grascher Darstellung. Rapid Prototyping [9], die schnelle und teilautomatisierte Entwicklung von (prototypischen) Implementierungen, ist dabei ebenso ein Thema wie Techniken zur abstrakten Beschreibung und Modellierung von Funktionalitt einer Applikation. Auf Basis dieser Anstrengungen a knnen Versuche zur automatisierten Generierung grascher Benutzerobero chen unternommen werden. a

4.34.3.1

Techniken der GUI-EntwicklungWindow Manager und Toolkits

Eine Reihe an Konzepten f hrt zu den heute angewandten und weit verbreiu teten Techniken in der Entwicklung grascher User Interfaces. Zu den groen Errungenschaften der Window Manager zhlt die Tiefenstaelung und Skaa lierbarkeit von Fenstern, die schnelles Wechseln zwischen parallel laufenden Anwendungen ermglichen. Window Manager sind Teil des Betriebsyo stems und bieten grundlegende grasche Operationen (Zeichnen, Updaten des Bildschirms) und Schnittstellen f r die Ereignisbehandlung an. Aufbauu end auf diesem abstrakten Modell stellen grasche Toolkits ein meist komponentenbasiertes Framework f r einfaches Arbeiten mit konkreten GUIu Elementen in einer bestimmten Programmiersprache zur Verf gung. Sie geu whrleisten bis zu einem gewissen Grad Konsistenz hinsichtlich der Ereiga nisbehandlung und dem Zeichnen der graschen Komponenten und d rfen u daher keinen starken Anderungen in der Programmbibliothek(API ) unterworfen sein.

4.3.2

Web-basierte Entwicklungen

In der Web-Entwicklung f hrte ein Zusammenspiel aus der Seitenbeschreiu bungssprache HTML, der Layoutbeschreibung CSS und Client- und server-

KAPITEL 4. GENERIERUNG GRAFISCHER USER INTERFACES 33 seitigen Scriptsprachen (Javascript, PHP, Perl) zum kommerziellen Durchbruch. Diese Sprachen m ssen nicht kompiliert sondern lediglich zur Laufzeit u interpretiert werden und ernen durch leicht verstndliche Anstze einem o a a groen Personenkreis Zugang zur Programmierung. Ein Nachteil liegt in der prozeduralen Abarbeitung des Programmcodes und der fehlenden Trennung zwischen Datenhaltung, Prsentationslogik und Applikationslogik (Modela View-Controller oder MVC ). Der groen Erfolg von webbasierten Dienstleistungen f hrte dazu, dass f hrende objektorientierte Programmiersprachen u u mit eigenen Scriptsprachen aufwarten und dadurch das MVC-Prinzip bestrken. Microsofts .NET Plattform arbeitet hier mit C# und Active Server a Pages (ASP). In der Java-Domne erf llen Java Server Pages und Servlets a u diese Aufgabe. Ein groer Nachteil von Webapplikationen liegt in dem zustandlosen u Transportprotokoll HTTP8 begr ndet, das die Verbindung zwischen Client und Server nur f r den Zeitraum eines Request/Response-Zyklus oen u hlt. Dadurch ist die grasche Oberche gezwungen, bei jeder Interaka a tion, die Datenzugri auf den Server verlangt, die Inhalte neu zu laden. Neue in Browser integrierte Technologien wie Asynchronous JavaScript and XML (Ajax) [2], die vermehrte Verwendung von Web Services9 und SOAP als XML- und HTTP-basierte Remote Procedure Call-Variante (RPC) versuchen diesen Nachteil mit Hilfe asynchroner Daten bertragung im Hinu tergrund ungeschehen zu machen. Auch proprietre Rich Client Plattfora men wie die Macromedia Flash Platform10 [19], arbeiten in dieser Hinsicht mit persistenten Verbindungen. Beispielhafte Anwendungen hierf r u sind die Kartographie-Software Google Maps11 und Services basierend auf der Online-Fotodatenbank Flickr12 . Mobiles Web Die fortschreitende Entwicklung mobiler Endgerte ermglicht die Nutzung a o von Webinhalten und Rich Media-Applikationen auch zunehmend auf Smart Phones und PDAs. Mehrere vielversprechende Konzepte versuchen bestehende Technologien auf mobile Plattformen zu portieren. In [41] wird die Idee eines zuk nftigen, einheitlichen User Interfaces f r dynamische, webbau u sierte Services erlutert: a The next logical step in this evolution is to extend the browser to become the UI container for the smart phone platform. Moving on from the rich media and application platform just described,8 Das Hypertext Transfer Protocol wurde durch die Internet Engineering Task Force speziziert (IETF) http://www.ietf.org/rfc/rfc2616.txt. 9 Web Services (Spezikation der W3C) - http://www.w3.org/2002/ws/ 10 Macromedia Flash Platform - http://www.adobe.com/de/platform/ 11 Google Maps - http://maps.google.com/ 12 Flickr Services - http://www.ickr.com/services/

KAPITEL 4. GENERIERUNG GRAFISCHER USER INTERFACES 34 by adding the ability to interact with the underlying smart phone hardware and le system, the Web browser can become the engine for the smart phone UI. Drei Methoden wurden als richtungsweisend identiziert: Die mobile Java-Plattform J2ME, in den Browser integrierte XML GUI-Sprachen wie XUL (siehe Kapitel 4.4.2) und standardisierte und proprietre Auszeicha nungssprachen und Scriptsprachen namens Macromedia Flash, JavaScript und das Vektorgrakformat SVG.

4.3.3

Interaktive GUI-Builder

GUI-Builder Werkzeuge gehen Hand in Hand mit dem eigentlichen Ziel der graschen Programmierung. Mit Hilfe eines Modellierwerkzeuges wird die Oberche aus elementaren Teilen wie Fenster, Button, Textfeld, etc. zusama mengesetzt und anschlieend in editierbaren Programmcode f r die objeku torientierte Zielsprache konvertiert. Je nach Ausma der Bindung zwischen der Grakbibliothek der Programmiersprache und Entwicklungsumgebung (Integrated Development Environment (IDE)) knnen Ereignisbehandlung, o Anderungen von Layout-Eigenschaften und auch die Datenanbindung an das Interface integrativer Bestandteil des GUI-Builders sein. Visual Studio bietet eine solche Entwicklungsumgebung f r die eigenen Programmiersprachen u # und Visual Basic. Auch f r die Java GUI-Bibliotheken Abstract Winu C dow Toolkit (AWT) und Swing stellen mehrere Entwicklungsumgebungen GUI-Builder zur Verf gung. u

4.4

XML GUI-Sprachen

XML als Metasprache mit baumartiger Gliederung eignet sich sehr gut zur Denition von Auszeichnungssprachen, die die komponentenbasierte Struktur und hierarchische Anordnung von graschen Elementen beschreiben. Es existiert eine Vielzahl an XML GUI-Dialekten, die auf unterschiedlichen Abstraktionsebenen ein grasches Interface f r verschiedene Aufgabengebiete u spezizieren. Das gemeinsame Ziel ist die automatische GUI-Generierung anhand einer Beschreibung, die auf einer Plattform in einer Entwicklungsumgebung mit Hilfe einer Programmiersprache oder in der Laufzeitumgebung eines Programms oder Frameworks in ein konkretes Interface-Rendering verwandelt werden muss. Mit Microsoft XAML, Mozilla XUL und XForms werden drei User Interface Description Languages (UIDL) vorgestellt, die eine starke Bindung zu konkreten GUI-Komponenten und dadurch zum Endresultat des GUIBuilding Prozesses haben. UIML und XIML bieten eine generischere Denition eines graschen Interfaces. Dies macht eine gerte- und plattformua nabhngige Beschreibung mglich, verlangt aber im Gegenzug mehr Aufa o

KAPITEL 4. GENERIERUNG GRAFISCHER USER INTERFACES 35 wand und Intelligenz bei der Auswertung der enthaltenen Information durch Transformatoren und wissensbasierte Systeme und stellt vorab kein konkretes Rendering mit vordenierten GUI-Elementen in Aussicht.

4.4.1

XAML

WinFX13 ist der Name von Microsofts .NET basierter Programmierschnittstelle, die die Basis f r Applikationsentwicklungen im kommenden Betriebsu system Windows Vista bildet und in vier Bereiche gegliedert ist. Neben dem Kommunikationsmodell Windows Communication Foundation (WCF), dem Programmiermodell Windows Workow Foundation (WF) und sicherheitsund authentizierungsrelevanten InfoCard-Komponenten ist die Windows Presentation Foundation (WPF) f r die grasche Aufbereitung in Vista zuu stndig. Als Teil dieses Subsystems wurde die Extensible Application Mara kup Language (XAML) als XML-basierte Beschreibungssprache f r User Inu terfaces konzipiert. Ziel ist die Trennung von Logik und Prsentationsschicht, a sowie die nahtlose Zusammenarbeit mit bestehenden .NET-Technologien. So kann die Ereignisbehandlung, etwa ein Button-Klick, in externe C# oder VB.NET Codefragmente ausgelagert werden, die in XAML referenziert werden. Innerhalb des Dokuments knnen auch Layouteigenschaften und eino fache visuelle Eekte wie Transparenz festgelegt werden. Dar ber hinaus u ist XAML als deklarative Sprache zur Darstellung folgender multimedialer Inhalte, die Anlehnung an bestehenden Standards nehmen, angedacht14 : Layout: Ahnlich HTML und dem Portable Document Format (PDF) soll es mit Flow-Format und Fixed-Format Dokumenten Unterst tzu ung f r verschiedene Text- und Objektlayoutdenitionen und inteu grierte Steuerelemente f r deren Betrachtung geben. u Vektorgrak und Multimedia: Die Denition von 2D und 3DVektorgraken sowie die Steuerung von Animationen und die Integration von Audio und Video erinnern an das Flash-Format SWF und die XML-basierten W3C-Standards SVG (Scalable Vector Graphics) f r u 2D Graken und das Prsentationsformat SMIL (Synchronized Mula timedia Integration Language). Daten Anbindung: Direkte Anbindung an Datenquellen wie Webservices und anderen XML-Daten ist ohne programmatischen Mehraufwand mglich. o Technologieubergreifendes Formularwesen - In XAML festge legte Oberchen knnen sowohl f r die Interface-Generierung von a o u Webanwendungen als auch f r Desktop-Applikationen eingesetzt weru13 14

WinFX API - http://msdn.microsoft.com/winfx/technologies/default.aspx XAML - http://www.xaml.net/

KAPITEL 4. GENERIERUNG GRAFISCHER USER INTERFACES 36 den und ersetzen damit unterschiedliche Technologien wie Windows Forms und das webbasierte Formularwesen in ASP.NET.

4.4.2

XUL

XML User Interface Language (XUL)15 ist eine von Mozilla spezizierte GUI-Sprache, die in Mozillas Browser Firefox, dem Email-Client Thunderbird und weiteren Projekten zum Einsatz kommt und von der Gecko Rendering Engine verarbeitet wird. XUL wurde zur schnellen Entwicklung plattformunabhngiger Benutzeroberchen entwickelt und versucht mit Hilfe a a von Technologien wie XML-Transformationen, CSS und JavaScript den Implementierungsaufwand f r grasche Oberchen, der durch die Mischung u a dieser verschiedenen Standards entsteht, zu minimieren. Zustzlich wird an a der Gecko Laufzeitumgebung gearbeitet, die in Kombination mit serverseitigen Webarchitekturen wie PHP und JSP und der Programmiersprache Java, die Entwicklung von GUI-Anwendungen mit dynamischem Inhalt auch auerhalb des Webbrowser-Kontextes erlaubt. Obwohl XUL kein Standard ist, der von einer Dachorganisation getragen wird, beschftigen sich mehrere a 16 und Anwendungen17. Mit der ErProjekte mit XUL Implementierungen ndung von XUL versucht Mozilla dem durch lange Perioden der Stagnation geprgten Prozess de

UPnP Diplomarbeit

Text of UPnP Diplomarbeit

UPnP AV Architecture:1upnp.org/specs/av/UPnP-av-AVArchitecture-v1.pdf · In most (non-AV) UPnP scenarios, a Control Point controls the operation of one or more UPnP devices in order

UPnP Device Architecture 1.1

UPnP DLNA White Paper

TR-069 UPnP DM Proxy Management GuidelinesA UPnP Control Point that interacts with UPnP devices supporting at least one of the UPnP Device Management services. UPnP DM Device A UPnP

UPnP TM Remote UI

UPnP 1.0 簡介

UPnP Device Architecture Tutorial

UPnP Forum Organization

Abusing Universal Plug and Play - UPnP Hacks: s topics and goals I UPnP history I UPnP protocol stack I debunk common misconceptions about UPnP I show errors in UPnP design I show

UPnP™ Implementers Corporation Update Karen M. Stash President UPnP™ Implementers Corp

UPnP – Язык Цифрового Дома

Upnp device

UPnP Printer Architecture

UPnP Forum Marketing Committee Update Andrew Liu Co-chair UPnP Forum MC Intel Corporation

UPnP Printing

UPnP AV Architecture:2

UPnP AV Tutorial

UPnP AV WC Status Update (UPnP Summit 2003) John Ritchie – Intel Geert Knapen – Philips UPnP AV Co-chairs

Cours UPnP

UPnP™ Device Architecture 1 - CoverPagesxml.coverpages.org/UPnP-DA101-20030506.pdf1 Introduction What is UPnP™1 Technology? UPnP™ technology defines an architecture for pervasive

UPnP AV Architecture:1

UPnP Technical basics · UPnP Technical basics: UPnP Device Architecture (UDA) July 2014. ... USN: advertisement UUID Multicast address Port usually 1900 DLNA: port 1900 is mandatory

UPnP+ and the Internet of Thingsupnp.org/resources/documents/UPnP Forum_IoT Beijing Workshop.pdf · UPnP+ and the Internet of Things July 2015 UPnP Forum ... (Bluetooth, ZigBee, Z-Wave,

Capítulo 5 DISPOSITIVO UPNP - bibing.us.esbibing.us.es/.../11954/fichero/6+-+CAP.5+-+Dispositivo+UPnP.pdf · CONTROL E INTEGRACIÓN DE ROVIO BAJO UPNP Dispositivo UPnP 81 las descripciones

UPnP AV WC Status Update (UPnP Summit 2002)

OPEN CONNECTIVITY FOUNDATION, INC. UPnP …openconnectivity.org/wp-content/uploads/2016/03/OCF-UPnP...PDX\127875\200109\TFH\17357778.1. OPEN CONNECTIVITY FOUNDATION, INC. UPnP ® CERTIFICATION

UPnP Device Architecture Generic 20000710

UPnP™ Device Architecture 1 - GitHub Pagestrinea.github.io/doc/upnp/UPnP-arch-DeviceArchitecture-v1.1.pdf · *Note: The UPnP Forum in no way guarantees the accuracy or completeness

UPnP Qos Architecture v3

UPnP QoS Architecture:2 · may use any UPnP device as a container for the services defined by UPnP QoS. The Control Points and QoS Management Entities must look for UPnP QoS Services

Documents

UPnP Diplomarbeit

Text of UPnP Diplomarbeit