verteilte web-anwendungen mit ruby ruben schempp anwendungen 1 29.05.2007

Verteilte Web-Anwendungen mit RubyRuben Schempp

Anwendungen 1

29.05.2007

Verteilte Web-Anwendungen mit Ruby 229.05.2007

GliederungGliederung

Motivation Verteilte Web-Anwendungen

Definition Beispiele Gemeinsamkeiten

Szenario Ausrichtung Anforderungen Abgrenzungen

Technologien Ruby

Fazit Zusammenfassung Ausblick


MotivationMotivation

Computer unterstützen gemeinsames Arbeiten Benötigt Verteilte Anwendungen/Systeme Setzt einfachen, flexiblen Zugang zum System voraus

Verteilte Anwendungen im Bereich des Collaborative Workplace, z.B. Leitstand Informationszentrale Gaming

Flexible Darstellung von Informationen auf Clients Browser Verschiedene, heterogene Endgeräte

Schwerpunkt Infrastruktur (u. Architektur) Technologie-Grundlage für ein Szenario


Verteilte Web-Anwendungen – Verteilte Web-Anwendungen – DefinitionDefinition Anwendung basierend auf Verteiltem System

Verbund von Rechnern zu einem Gesamtsystem Transparente Architektur Rechner dienen derselben Sache

Web-Anwendung Dargestellt durch Browser


Verteilte Web-Anwendungen – Verteilte Web-Anwendungen – BeispieleBeispiele


Verteilte Web-Anwendungen – Verteilte Web-Anwendungen – Gemeinsamkeiten Gemeinsamkeiten Kontext der Aufgaben

Web 2.0 Entsprechend ähnliche technische Umsetzung

Frontend Web-Oberfläche Evtl. Google-Maps API

Backend Web-Server Datenbank Verteiltes Informationssystem


Verteilte Web-Anwendungen – Verteilte Web-Anwendungen – InformationssystemInformationssystem

System bzw. Werkzeug (nach Prof. Raasch)

SpeicherungWiedergewinnungVerknüpfung & Auswertung

… von Informationen


Szenario – ThemaSzenario – Thema

Bereich des Collaborative Workplace Leitstand Informationszentrale Einsatzleitstelle

Konkret beispielsweise Verteiltes Informationsystem Leitstand Google-Maps Karte mit Einblendung der aktuellen Position von

Einsatzfahrzeugen der Polizei (Vogelperspektive) Verschiedene Endgeräte

Festinstallationen Mobile Endgeräte unterschiedlicher Art


Szenario – ThemaSzenario – Thema

Leitstand Zentrale Überblick Gemeinsames Arbeiten Fernab des Geschehens oder

vor Ort Tätigkeiten

Verwaltung/Koordination Informationen sammeln Gezielt steuern…eines Einsatzes und der

Einsatzkräfte vor Ort


Szenario – Szenario – Funktionale AnforderungenFunktionale Anforderungen Sammeln … Aufbereiten … Speichern/Loggen … Zur Verfügung stellen …

von Informationen über Positionen von Personen/Einsatzkräften/Fahrzeugen Integriert in eine Umgebung/Kartenmaterial Andere Point-of-Interests Zusätzliche Informationen für Orte (Temperatur, …) …

Usability Einfache/Intuitive Bedienbarkeit bei hohem Stresspegel


Szenario – Szenario – Nichtfunktionale AnforderungenNichtfunktionale Anforderungen

Aspekte des Systems Verfügbarkeit Fehlertoleranz Skalierbarkeit Persistenz Zugriffsrechte Architektur/Aufbau

Kommunikationsmodell Middleware? Remote Procedure Call vs. Blackboard/Tupel Spaces?


Szenario – Szenario – Nichtfunktionale AnforderungenNichtfunktionale Anforderungen

Erweiterbarkeit durch Komponenten Services Anbindung an / Integration in andere Systeme

Unterschiedliche Endgeräte Mobilität/Verbindung Ressourcen Betriebssysteme Programmiersprachen Schnittstellen

…


Szenario – AbgrenzungSzenario – Abgrenzung

Keine Schwerpunkte sollen sein Sicherheit/Rechte Transaktionen Persistenz Wearable Computing Ausgefeilte Sensorik …?


Szenario –Szenario –Bestandteile des SystemsBestandteile des Systems

Client Verbindung Browser Hardware

Große Multi-Touchdisplays für Zentrale(n)

Mobile Geräte Server

Webserver Datenbank (Web-)Services Anwendungslogik


TechnologienTechnologien Unterschiedliche Architekturtypen

Bestehende Arbeiten Middleware (Lars Burfeindt) Architekturtypen (Roman Bartnik) …

In Frage kommen Web2.0

Ajax (Asynchonous JavaScript and XML) Google Maps

Java (Google Web Toolkit) Virtual Machine Frameworks

Ruby Ruby on Rails JRuby Frameworks


Ruby – Die SpracheRuby – Die Sprache

Open Source Verwandt mit Smalltalk, Python

und Perl Rein objektorientiert Stark und dynamisch typisiert Reguläre Ausdrücke Lexical Closures (z.B. Blöcke) Klar strukturierte, orthogonale

(Skript-) Sprache Klassen und Objekte zur Laufzeit erweiterbar: hohe

Dynamik


Ruby – Die VorteileRuby – Die Vorteile

Smalltalk kann viel, Ruby auch Die vielleicht produktivste Sprache Kein Kompilieren notwendig Metaprogrammierung & Reflection sind einfach Einsatz und Eignung von Ruby on Rails? Einsatz von JRuby?

Ist zu Prüfen Evtl. Einsatz von JVM und bestehenden Java Frameworks

möglich → Vorteile für Architektur, dynamische Inhalte


Fazit – ZusammenfassungFazit – Zusammenfassung

Szenario Einsatzleitzentrale: Darstellung von aktuellen

Informationen (Position,…) in Kartenmaterial Ziel

Szenario durch verteilte Web-Anwendung unterstützen

Mittel der Wahl Architektur Ruby Ajax?


Fazit – AusblickFazit – Ausblick

Analyse und Wahl geeigneter Technologien Design einer Architektur

Bekanntes und Bewährtes? Eignung eines Blackboards? Integration von Google Maps?

Erstellung eines Prototypen Realisierung eines Kern-Systems für eine

Einsatzleitzentrale auf Basis von Ruby


Quellen / LiteraturQuellen / Literatur

Lars Burfeindt, Diplomarbeit http://users.informatik.haw-hamburg.de/~ubicomp/arbeiten/diplom/burfeindt.pdf

Roman Bartnik, Diplomarbeit http://users.informatik.haw-hamburg.de/~ubicomp/arbeiten/diplom/bartnik.pdf

Horst Mund, Diplomarbeit http://users.informatik.haw-hamburg.de/~ubicomp/arbeiten/diplom/mund.pdf

Andreas Piening, Masterprojekthttp://users.informatik.haw-hamburg.de/~ubicomp/projekte/master06-07-aw/piening/folien.pdf

Ruben Schempp, Bachelorarbeit http://users.informatik.haw-hamburg.de/~ubicomp/arbeiten/bachelor/schempp.pdf

A. Tanenbaum, Computer Networks, Prentice Hall 2003 J. Raasch, Folien Vorlesung „Architektur von

Informationssystemen“, HAW-Hamburg Google.com – Google Docs, Spreadsheets, Maps & Labs


Ende / DiskussionEnde / Diskussion

Gibt es noch Fragen …?

verteilte web-anwendungen mit ruby ruben schempp anwendungen 1 29.05.2007

Documents