Schlagwort: jfs2011

Veröffentlicht am

Mein Fazit vom Javaforum in Stuttgart #jfs2011 : Things are changing.

Ein Tag, konzentrierte News, Vorträge und viele Bekannte Gesichter (schön, dich wieder mal in Real Life getroffen zu haben @elektrojunge). Mein Fazit vom Javaforum ist gespalten.

Zum einen, viele  gute Vorträge, eine top Organisation, Aussteller, die offensichtlich auch wieder vertärkt Java Entwickler suchen. Aber was gefühlt mein Eindruck war. Irgendwie fehlt die Vision, wie es mit Java weitergehen soll. Seit der Übernahme durch Oracle ist die Szene misstrauisch geworden.

Das zeigte für mich auch der Vortrag „Das nächste große (Java-) Ding. Das hier die Klammer um Java auftauchte, war sicher gewollt. Mittlerweile stößt Java an seine Grenzen, die Erweiterbarkeit ist längst nicht mehr so einfach und die Virtual Machine limitiert manche grammatikalischen Erweiterungen.

Die Idee der JVM wird sicher weiterhin Bestand haben, aber ob auch Java noch die zweistelligen Versionsnummern erleben wird. Ich wage es nicht zu prognostizieren.

Letztlich war ich aber am verblüfftesten von der geringen Zahl an Tracks zum Thema mobile Computing. Mittlerweile gehen knapp 20%  der deutschen Nutzer via Smartphone ins Internet, jeder vierte Haushalt besitzt ein solches Device und der Markt für Tablets boomt gerade. Dann aber nur zwei Tracks dazu anzubieten war mir eindeutig zu wenig.

Es gibt so viele wichtige Aspekte zu berücksichtigen und wenn ein Bereich die Entwickler in den nächsten Jahren verstärkt beschäftigen wird, dann der mobile Endgerätebereich.

(Kleine Anmerkung am Rande: Schon auf dem Weg zum Veranstaltungsort vielen mir viele QR Codes an Litfaßsäulen oder in Schaufenstern auf und auch auf dem Javaforum waren viele QR Codes zu finden. Ein neuer Trend? Ich prognostiziere ja bereits länger dieses Jahr als das Jahr des QR Codes. Mal sehen, ob ich am Ende recht behalte?)

Ansonsten aber, danke für einen hochinteressanten, informativen und sehr gut organisierten Event, den ich nächstes Jahr sicher wieder besuchen werde.

Was ich mitgenommen habe, ein IT-Projekt braucht IT affine Mitarbeiter. Projektmanagement ist ein Full Time Job und kann nicht parallel zum Tagesgeschäft laufen. Mobile Endgeräte dürfen nicht vernachlässigt werden und es muss auch hier ein Bewusstsein für Datenschutz und saubere, sicherheitsbewusste Programmierung existieren. REST und ähnliche Technologien sind ein spannender neuer Ansatz, um Dienste auf mobile Endgeräte zu bringen, ohne komplizierte Zugriffschnittstellen und aufwändige Programmieranforderungen.

Java is here to stay but may leave in a few years.

See you all next year at #jfs2012

Veröffentlicht am

Javaforum Stuttgart 2011 #jfs2011 Live Blogging Vortrag 6

Vortrag 6: Restful API design
Warum REST mehr als HTTP mit XML ist

REST= Representational State Transfer

Representational State Transfer. Bunt.

Als Beispiel wird „ein Büchershop (guess which one)“ genutzt.

Das ganze soll jetzt auf Mobile Endgeräte, „wir brauchen eine App“
Also braucht man eine Api.
die zu implementierenden Schnittstellen sind aus dem „Legacy“ System vorgegeben.
REST möchte:

 

Für eine Web API
http bewusst nutzen

Bedenken, das Web ist ein verteiltes Medium

Vorkenntnisse über APIs sollten minimiert werden (einfache Einarbeitung).

1 Methode ergibt eine REssource
also Buch Nr Buch-ID —-> http://site/api/book/book-id

2 Methoden, eine Ressource

addToCart
getCartInfo

http://site/api/cart/cart-id

Man muss sich immer die Frage stellen, was kommt in die URI, was in die Parameter
Alles was ein „Ding“ ist in die Uri, der Rest in die Parameter
Aktionen entsprechen Methoden

Aktionen auf Ressourcen sind nicht Teil der URI sondern http-Methoden

Dies ist später in
der API Doku zu beschreiben
Übliche Verhaltensmuster sind
GET->Anzeigen
Post Anlegen oder Ergänzen
PUT Anlegen oder Schreiben

Es sind pro Entity mehrere URI möglich

Http Möglichkeiten nutzen, Error Meldungen, Last Sharing etc.

Caching kann im Header eingestellt werden, also nutzen, gerade auch für mobile Geräte.

ETags definieren den Zustand einer Ressource. Auch diese sind sinnvoll!

Links: Echtes REST

 

Link-Semantik definieren

Ressourcen mit Referenzen verknüpfen

Wissen über die API also verlagern in die Link Annotation

Die Art des Links kann in einem Annotation type wie rel definiert werden.

 

Veröffentlicht am

Javaforum Stuttgart 2011 #jfs2011 Live Blogging Vortrag 5

Vortrag 5:
Safety First, Android sicher programmieren!

@elektrojunge on stage

Es gibt Dinge zu beachten, die nur für mobile Endgeräte gelten.
Android ist strukturiert wie ein Orchester mit vielen „Spielern“, verschiedensten Komponenten, die erst zur Laufzeit miteinander verknüpft durch die „Intents“ die Messengerkomponenten. Wie kann ich nun diese Komponenten absichern, wenn Intents schief laufen.

Es gibt das grobgranulare Sicherheitsmodell basierend auf der Sicherheit des Linux Kernels, der die Prozesse isoliert.
Desktop hat Single UID
Android hat UID per Application
Applikationen, die mit dem gleichen Schlüssel signiert sind, können mit der gleichen UID laufen.
Die Kommunikation zwischen Apps läuft über eine Binder IPC

Weiterer Schutz->Sandboxing von Applikationen
Ich kann nur meine eigenen Ressourcen ansprechen.
Jede App läuft in einer eigenen Instanz der Dalvik VM.
Kommunikation über spezielle Interfaces.

Weiterer Sicherheitsmechanismus
Signieren von Applikationen
Verantwortlich für die Signatur ist der Entwickler
Zertifizierung durch Entwickler und in Verantwortung des Entwicklers
Vertrauen in Entwickler durch Erstellung guter Anwendungen

Daneben Feingranulares Sicherheitskonzept
Basiert auf Permissions
Permissions schränken die Möglichkeiten ein, was Prozesse tun können.
Benutzer erkennt das an den angegebenen Rechten, die die App bei der Installation fordert.

Es gibt:
System permissions Erlaubnis auf Systemdienste zuzugreifen (z.B) Kalender oder Adressbuch
Custom permissions
Permission groups
Permission trees

Definiert werden die Permissions im Android Manifest.
Informationen über Apps und laufende Prozesse kann über PackageManager oder ActivityManager
PackageManager -> Installierte Programme
ActivityManager -> Laufende Programme

Wo sind die Verantwortlichkeiten des Entwicklers?

Per Default kann eine App vom „Umfeld“ nichts sehen.

Component wird exportiert durch android:exported im Intentsfilter

Intents sind vergleichbar mit Messengerobjekten
Niemals sensitive Daten in einen Intent
Ebenso von Anfang an angeben, wer den Intent sehen können soll.
Intentfilter filtern keine schädlichen Intents!
Ein Angreifer kann die Priorität seiner Intentfilter erhöhen.
Bei Intentfiltern spezifische Aktionen und Kategorien angeben und Datenfilter

Activities

Benuten von Activity android:permissions = „de.otw.android.HARM_USER_DATA“

Die Permissions werden in startActivity() bzw. startActivityforResult() geprüft.

Services

Client-> Intent.setComponent() um den Service eindeutig zu identifizieren.

Achtung bei der Verwendung von Binder Interface.

Genehmigung für ServiceConnection im Package Manager prüfen, vor dem Austausch sensitiver Daten.

Server: Genehmigung mit erzwingen
Feingranularere Zugriffskontrolle durch Verwendung von Binder und Context Hilfsfunktionen

Broadcast Receiver

Receiver: Wiederum eine Genehmigung erzwingen

Sender: Immer darüber nachdenken, wer den Intent empfangen können soll. Also einfordern einer Permission und Definieren des Empfängers des Intents.

Don’t user sticky broadcasts for sensitive data!

ContentProvider

Achtung, beim Verwenden eines ContentProvider intern, android:exported=“false“ explizit setzen.
Lese und Schreibrechte trennen
android:readPermission
android;writePermission

TAg schränkt zur Compiletime uri Zugriffe ein.

Mitkönne erlaubte Pfade für uri Zugriffe angegeben werden.

Tips:
Jegliche empfangene Daten aus einem Intent prüfen
SQL Statement und Daten die es enthält klar trennen.

Selection fields final machen um Kontaminierung aus Zufall zu vermeiden

Selektionen komplett vermeiden, Content_uris verwenden.

File I/O

Files, DB und geteilte Preferenzen könne mit Berechtigung installiert werden

Bei Zugriffsberechtigungen auf Datenbanken immer an die Konsequenzen denken und immer den User fragen.
Daten auf SD Karte NIE unverschlüsselt ablegen.

IMMER DRAN DENKEN Nutzerdaten SICHER speichern.

So wenig Permissions wie möglich, anstelle einer Permission manchmal besser ein Dialog.

Veröffentlicht am

Javaforum Stuttgart 2011 #jfs2011 Live Blogging Vortrag 4

Vortrag 4:

Java in der Cloud – Aktuelle Möglichkeiten und Entwicklungen

Was ist die Cloud?
Infrastructure as Service
Virtuelle Server, vergleichbar mit Virtualisierung

Manage Everything yourself
Player sind z.B. Amazon Webservices
VMWare
Platform as a Service
Virtual App Server
werden meist von den Providern gemanagt.
Skalierung wird vom Anbieter gemanagt.
Beispiele Cloudfoundry oder Google App Engine

Software as a service

Software aus der Cloud meist ebenso relevant für User wie Entwickler
Beispiele: Salesforce
Google Mail

Cloud Modelle:

Public -> Für die Öffentlichkeit verfügbar

Private -> Nur für eine Organisation verfügbar

Community -> Für mehrere Organisationen verfügbar

Hybrid -> Kombination verschiedener Modelle

Warum Cloud überhaupt machen

Public Cloud: Zahl nur, was du brauchst
Billige Art, Lastspitzen zu behandeln
Transparentes Kostenmodell

Private Cloud:
Besser Verwendung der Ressourcen
Kosten können abgerechnet werden
Der nächste Schritt nach der Virtualisierung

Business Agility
Deployment von Anwendungen per Maus Klick
Testumgebungen sehr einfach und günstig. Zahlen nur beim Testen.
Die Anwendung skaliert automatisch

Werner Vogels (CTO Amazon) sagt: Ihre Ingenieure brauchen 70% der Zeit für Skalierbarkeit und Technologie-> Deshalb Cloud

Plattform der Zukunft
Ausfallsicherheit, Automatische Verteilung, neue Computer einzurichten wird trivial
Günstige Systeme mit hoher Verfügbarkeit und Datenhaltungssicherheit
Sieht so aus wie Google, Amazon, Facebook

Wie sieht das für den Java Entwickler aus

Wie gehe ich mit Lastspitzen um? Ich brauche mehr App Server Instancen
Nach dem Peak müssen sie auch wieder gestoppt werden
Elastic Scaling als Stichwort
Was der Entwickler am Ende hat:
Eine Werkzeug, das eine Anwendung nimmt und daraus eine VM erzugt, mit der gesamten nötigen Infrastruktur.
Diese kann dynamisch hoch und runter skalieren.

Wir benötigen Werkzeuge zur Installation der Software
Die Infrastruktur verwalten
Benutzer einrichten

Tools sind z.B. Puppet, Chef etc.
Quasi eine Factory für VMs
Für lokale Installationen existiert „Vagrant“
Vorteile: Sehr flexibel
Arbeitet für jetwede Infrastruktur und Anwendung
Arbeitet auf komplexen Installationen mit versch. Komponenten
Verschiedene Anwendungen können auf verschiedene Knoten deployt werden.

Aber noch besser geht es:

Anwendung auf einer PaaS Umgebung also Plattform as a Service deployen
Vorteil: Nützlicher, da ein Server sowieso installiert werden müssten
Automatische Skalierung
Zusätzliche Dienste im Angebot

Aber:
Weniger flexibel
Vordefiniertes Entwicklungsmodell
Lernkurve für das Programmiermodell
Existierender Code ggf. schwer zu migrieren.

Mogliche PaaS Plattformen
Google App Engine
Java Unterstützung aber sehr restriktive Umgebung mit Java Classes White List
Fokus auf NoSQL

Begrenzung der startbaren Applikationen
Limit auf Antwortzeit (30sec)
Kein Zugriff auf OS oder Server

Daher wurden spezielle Frameworks entwickelt
(Gaelyk for Groovy)

Aber besser laut Vortragendem

Amazon Elastic Beanstalk

Basierend auf der EC2 Infrastruktur
plus Auto Scaling und S3
Dazu Linux, OpenJDK und Tomcat

Zur Zeit im Betatest im Osten der USA
Es gibt Eclipse Plugin
Es unterstützt Versionsverwaltung für Applications, sowie Elastic Scaling
Einfaches Monitoring ist eingebaut
Detailierte Kontrolle über die Umgebung ist möglich.
Zugang aufs OS und Tomcat Logs

Spring basierte Demoanwendung ist vorhanden und es existiert ein Relational Database Service (RDS) für enterprise scale MySQL und andere Amazon Web Services
Skalierungseinheit 1 VM = 1 Server

Weiterer Ansatz
VMWare Cloud Foundry
Open Source Projekt bei GitHub unter der Apache2 Lizenz

Sehr neu, noch ohne kommerzielle Angebote

Kann Ruby, Java und Node.js laufen lassen
Verschiedene Frameworks werden unterstützt
Kann überall gehostet werden, wird von der Community erweitert, z.B. Support für Erlang, PHP, Python

Es existiert ein Eclipse Plugin
Es unterstützt elastic scaling…. Ok, man kann es bauen.
Aehnlich normalen EJB Umgebungen mit Tomcat und MySQL
Läuft auf ubuntu
es teilen sich n Server eine virtuelle Maschine, damit geht die Skalierung feingranularer.
Angebotene Dienste sind
RDB Service
Key Value Store
Document Store
Messaging Service
Mehr kommt
Es gibt auch eine API zum Erstellen der eigenen Services

Zusammenfassend
Cloud wird aus drei Gründen kommen: Kosten, Business Agility, Platform of the Future
Google App Engine Pionier aber veraltet

Amazon Beanstalks: Standing on the shoulde of Giants

Cloudbees: Für Entwickler

Spannend scheint CloudFoundry: Open Source mit einer grossen aktiven Community, lauffähig auf ubuntu!