Web-Hybride Mobile Applikation – Nearby. Namics.

Idee

Im Rahmen des lab.namics von Team Andi im November 2009 wollten wir (Olaf Egner und Hilar Lütolf) herausfinden, was mit Mobil-Hybriden Applikation möglich ist.

Nearby. Namics.

Bei Nearby. Namics. handelt es sich um eine Mobile Web-Hybride Applikation. Das bedeutet, dass diese Applikation vollständig auf einem herkömmlichen Webserver liegt und zu keiner Zeit auf dem Handy installiert werden muss – genau wie bei „normalen“ Web Applikationen. Der Unterschied liegt nun darin, dass diese Web-Hybriden Applikationen mit Hilfe von speziellen Javascript-Libraries auf gewisse Hardware-Funktionen des Geräts zugreifen können.

Nearby. Namics. verwendet (sofern vom Gerät unterstützt) die Lokalisierung und zeigt an, abhängig von der Position des Benutzers, welcher Namics Standort geografisch am nächsten liegt – gemessen an der Luftlinie.

Dazu greift Nearby. Namics. auf das navigator.geolocation-Objekt zu. Das Gerät nützt dann in aller Regel die jeweils genaueste Methode zur Ermittlung der eigenen Position (Geolocation), z.B. das GPS-Modul, Netz-basierte Techniken oder die IP-Adresse.

Zusätzlich besteht die Möglichkeit, die eigene Position an den Nearby-Server zu senden, dort abzuspeichern und gleichzeitig die aktuelle Position des (wiederum gemessen an der Luftlinie) nächstgelegenen Mitarbeiters angezeigt zu erhalten. Voraussetzung hier ist, dass mindestens ein Mitarbeiter vor weniger als 1 Stunde ebenfalls seine Position an den Server gesendet hat.

875-IMG_0692.PNG
876-IMG_0700.PNG

Mit Nearby. Namics. konnte aufgezeigt werden, das Web Applikationen die eingebauten Lokalisierungs-Methoden von Geräten auf einfache Weise nutzen können – auch ohne Google und Co. Für die weitere Entwicklung liegt eine ganze Reihe von Ausbau- und Erweiterungskonzepten in unserer Lab-Schublade, z.B. die gegenseitige Kontaktaufnahme per SMS/Chat oder die Visualisierung der Bewegungslinien unserer Consultants.

Die Umsetzung von Nearby. Namics. erfolgte im Übrigen mit jQTouch.

Hybrid vs. Native und Co.

Mit Hybriden Applikationen bezeichnen wir Software, die mittels im Internet bewährter Technologien wie HTML, CSS und JS auf Funktionen des Mobiltelefons zugreift.

Generell haben wir festgestellt, dass die bisher bekannte Kategorie der Hybriden Applikationen sinnvollerweise aufgeteilt wird in zwei Unterkategorien Native-Hybrid und Web-Hybrid, was zu den neu 4 folgenden Kategorien führt:

  • Native Applikationen (z.B. Google Earth für iPhones)
  • Native-Hybride Applikationen (z.B. Namics-Wortmarken-App für iPhones)
  • Web-Hybride Applikationen (z.B. Nearby. Namics.)
  • Web Applikationen (z.B. roomNOW)

Im Unterschied zu Web-Hybriden Applikationen werden Native-Hybride in der Entwicklungsumgebung der Handset-Familie entwickelt, besitzen aber als Frontend ebenfalls eine Website in HTML, CSS und JS. Die native Softwarekomponente bildet hier die Zwischenschicht, um auf mehr Hardware-Funktionen zugreifen zu können (z.B. dank dem Einsatz von PhoneGap), als dies bei einer Web-Hybriden Applikation möglich wäre.

Weitere Anwendungsmöglichkeiten beim Zugriff einer reinen Webseite auf interne Funktionen z.B. beim iPhone: Bewegungssensoren der Geräte, anhand derer z.B. zwischen Hoch- und Querformat gewechselt werden kann (bei Nearby. Namics. ebenfalls umgesetzt). Weitere Funktionen wie z.B. das Auslesen des Adressbuchs, Abspielen von Tönen und Vibration sowie das Verwalten des Adressbuchs bleiben (vorerst) den beiden nativen Applikations-Kategorien vorenthalten, zumindest gemäss unserem aktuellen Kenntnissstand.

Unzufrieden mit der Suche auf Ihrem Internet-Auftritt? Google Mini hilft!

Ich ertappe mich oft, wie ich bei einer Website-Suche das Vorurteil hege, ohnehin nicht auf die gewünschten Informationen zu stossen – und daher die öffentliche Google Websuche verwende. Wahrscheinlich bin ich nicht der Einzige, der sich an Google gewöhnt hat und daher erwartet, dass jede Suche so zu funktionieren hat. Diese Annahme bestätigt sich denn auch in von uns durchgeführten Usability Tests und Analytics-Daten: Immer mehr User suchen bestimmte Inhalte auf einer Seite über die angebotene Suchfunktion. Häufig finden sie aber die gewünschten Inhalte nicht, da die eingesetzten Suchmaschinen schlicht und einfach entweder nichts taugen oder schlecht konfiguriert sind. Die Lösung? Google Mini ;)

Was kann denn eine Google Mini?

i-19be7abadec11c149159bdb2dc4c5bca-google-mini.jpg

Die Google Mini ist ein 19 Zoll Hard- und Softwarebundle und bietet neben einer ausgereiften und vertrauten Volltextsuche einige weitere wirklich gute Funktionen:

  • Dank dem XML Suchinterface kann die Google Suche in beliebige bestehende Webseiten integriert werden, auch parallel in mehreren (beliebige Anzahl Kollektionen).
  • Mit Keymatches (eigenständig definierbare Treffer zu bestimmten Suchbegriffen) kann den Suchenden geholfen werden, die richtigen und wichtigen Informationen schnell zu finden. Beispiel: gibt jemand einen Produktenamen ein, erscheint der Keymatch dazu oberhalb der restlichen Treffer und ist optisch hervorgehoben.
  • Die Google Mini durchsucht mehr als 200 Dateiformate und bietet eine Textvariante des jeweiligen Inhalts an.
  • Eine Suchanwendung kann mittels Onebox Modulen ausgebaut werden. So können z.B. bei einem Treffer zu einer Produktseite detaillierte Informationen zu diesem Produkt bereits in der Resultatliste angezeigt werden. Beispiele zu Onebox Modulen auf der öffentlichen Google Suche: Lokale Wetterprognosen oder Treffer aus dem Branchenverzeichnis von Google.
  • Sofern notwendig kann die Google Mini in bestehende Sicherheitslösungen integriert werden.
  • Was kostet eine Google Mini?

    Eine Google Mini gibt es ab circa CHF 4’000.- inklusive Lizenz und Wartung für 2 Jahre, also für CHF 2’000.- pro Jahr. Der Aufwand für eine Integration in eine Webseite beläuft sich auf circa CHF 15’000-30’000. Darin eingeschlossen sind Design von Suchmaske und Resultateliste, Implementierung, initiale Konfiguration sowie Inbetriebnahme der Google Mini.

    Bei Interesse oder spezifischen Fragen einfach Kontakt aufnehmen, oder unten kommentieren. Gerne stelle ich die Google Mini (oder auch die grössere Google Search Appliance) auch im Live-Einsatz vor.

    Übrigens, Namics ist bereits seit 2005 zertifizierte Google Enterprise Professional Partnerin und in der Schweiz damit bislang alleine. Und natürlich machen wir Google Mini / Google Search Appliance Projekte auch in Deutschland :)

    i-2ea90484bc7cfd2118c62dc1b3335006-logo_gep.gif

    Spring Web Flow

    Freitag, 11. Mai, JavaOne

    Spring Web Flow

    Kurz beschrieben: Spring Web Flow ermöglicht einem Entwickler das Konfigurieren eines Workflows (oder eines mehrseitigen Formulars) mit einem für Spring typischen XML Dokument. Das an der Session gezeigte Beispiel (eine Telefonbuchsuche) wies ein JSF Frontend auf und bestach mit einer Einfachheit die einem zum Austesten der Spring Komponente ermutigte.

    Drei Schritte sind notwendig um in einer Webapp Spring Work Flow zu verwenden:

    • 1. Web Anwendung wie gehabt aufsetzen
    • 2. Webflow konfigurieren (webflow-config.xml, dazu ein Unterverzeichnis flows mit den eigentlichen Workflows)
    • 3. Implementierung des Flows (beim Beispiel search-flow.xml im Unterverzeichnis flows)

    Eine Workflow Konfiguration hat mehrere „States“ (einer davon ist der Start State), zwischen den States wird mit „Transitions“ gewechselt. Welche Transition von welchem State zum andern State möglich ist, wird in der Konfiguration genau hinterlegt. Die Transitionen respektive deren Auslöser werden direkt mit den Elementen in der View verknüpft.

    Zum Schluss wurden noch Erweiterungen, die in Spring Web Flow 1.1 erhalten sein werden, angekündigt: neu sollen unter anderem Flows vererbt, Annotationen verwendet und das Security Framework Acegi integriert werden können.

    Dank der Auslagerung in eigene Konfigurationsdokumente (und der Möglichkeit Workflows als so genannte Subflows zu schachteln) dürfte die Konfiguration auch komplexerer Abläufe (bei installierter Spring IDE auf grafisch) recht komfortabel sein.

    Auch in Zeiten von Ajax und clientseitiger Logik dürfte diese Komponente zur Unterstützung „traditioneller“ Webapps eine willkommene Ergänzung sein, zumal diese „Web 1.0″ Webapps auch weiterhin ihre Daseinsberechtigung haben dürften – dies zumindest meine Meinung :-).

    Ajax Sicherheitsaspekte und Garbage Collecting

    Donnerstag, 10. Mai, JavaOne 2007

    You Are Hacked: Ajax Security Essentials for Enterprise Java Technology Developers

    Diese Session behandelte, wie schon der Name vermuten lässt, die potentiellen „neuen Risiken“ die zu den „alten Risiken“ hinzukommen wenn man eine Webapp „Ajax enabled“. Und wartete auch mit ein paar Tipps auf, wie man diesen begegnen kann.

    Das Hauptproblem dieser neuen „Rich Internet Applications“ ist, dass durch die Verlagerung von Applikationslogik auf den Client (weg von „thin“ Browser Interfaces hin zu „thick“) der geneigte Hacker automatisch mehr über die Anwendung erfährt. Die Logik und die Methoden sind nun nicht mehr hinter einem Service auf dem Server verborgen; durch den Export dieser – damit vom Client via Javascript aufrufbar – sind diese nun sichtbar und machen es einem Hacker einfacher die Anwendung zu inspizieren, Methoden auszuprobieren und auszutricksen.

    • Javascript Bibliotheken unter Verwendung eines „Obfuscators“ (ersetzt sprechende Methoden- und Variablennamen mit „kryptischen“) schwerer lesbar machen.
    • Ajax nur dort einsetzen wo wirklich sinnvoll. Bei Login Seiten zum Beispiel nicht Popups, sondern eigene „plain old“ Login Seiten verwenden. Dies auch, um wegen des zeitweiligen Wechels von http auf https nicht mit der „same origin policy“ der Browser in Konflikt zu geraten und umschiffen zu müssen.
    • Input Validierung (auf dem Server, sich NICHT auf den Client verlassen!).
    • Output encoding.
    • Referer und Token (zum Beispiel API Key) Checks durchführen.
    • Einsatz von CAPTCHAs.
    • Die Lebenszeit von Sessions so kurz wie möglich, so lange wie nötig halten.
    • Verwendung von Black- und Whitelists.
    • Anzahl Requests und Bandbreiten limitieren.
    • Monitoring der Anwendung.

    Das grosse Problem sei, dass Sicherheits Aspekte beim Entwickeln einer Anwendung oftmals – um schneller vorwärts zu kommen – vernachlässigt werden. Erst nach der ersten Attacke kümmert man sich darum: man stopft genau das offengelegte Loch. Und dann das nächste Loch und so weiter. Sicherheit sollte daher von Anfang an ein Thema sein!

    Zusammengefasst hat diese Session wohl nicht viel neues zu Tage gefördert; wird dadurch aber der eine oder andere Sinn für diese Probleme geschärft, hat sich der Besuch sicherlich gelohnt.

    Garbage-Collection-Friendly Programming

    Die zeitweise etwas abgehobene Session mit drei Leuten des Garbage Collector Teams von Sun dürfte manchem Kenner viele Einsichten über Garbage Collector Strategien etcetera beschert haben. Da ich mich nicht zu den GC Profis zählen tu, möchte ich mich auf ein paar Punkte beschränken die ich mir fortan (wenn nicht schon bereits bisher) zu Herzen nehmen möchte. Für Interessierte treibe ich gerne die Slides auf (was auch für die andern Vorträge gilt).

    Das (mit einem Schmunzeln) erklärte Ziel der Session war es, dass die Entwickler ihre Codes und nicht das GC Team den ihrigen anpassen muss :-).

    • Das Allozieren neuer (kleiner) Objekte ist effizient, nur zu also.
    • Der Garbage Collector kann mit kurzlebigen immutable Objekten besser umgehen als mit langlebigen mutables.
    • Explizites Garbage Collecting sollte vermieden werden, ausser man tut dies sehr bewusst und die Performance der Anwendung ist zu jenem Zeitpunkt nicht kritisch.
    • Finally Block benützen um unbenötigte Referenzen abzuräumen.
    • Achtung bei Inner classes, diese haben implizite Referenzen auf ihre „Mutterobjekte“.
    • Hat die Anwendung ein Memory Leak, kann man sich mit jmap ein Class Histogramm anzeigen lassen.

    ArcGIS und Google Web Toolkit

    Donnerstag, 10. Mai, JavaOne 2007

    Heute habe ich die längere Mittagspause nochmals richtig nutzen wollen um im JavaOne Pavilion die vielen Stände der Aussteller abzuklappern…

    ESRI

    Am meisten Zeit habe ich dabei bei ESRI verbracht, der Anbieterin der Mapserver Architektur ArcGIS. ArcGIS besteht aus den drei Layern Applikationen (Desktop, Server, Mobile), dem Developer Layer (dort findet man die so genannten ArcObjects) und dem Datenlayer (mit Daten von zum Beispiel Tele Atlas oder Navteq).

    Mapping Dienstleister verfügen oftmals nicht über einen selbst entwickelten Mapserver, sondern bieten Lösungen mit weiterentwickelten Produkten wie eben diesem ArcGIS an. So ein Mapserver verfügt – neben dem Visualisieren der Mapdaten – auch über Funktionen wie etwa Routing oder Umkreissuche. Hat man einen solchen ArcGIS Server zur Verfügung, wurden mir zwei Möglichkeiten vorgeführt wie man diesen verwenden kann (natürlich gibt es noch mehrere).

    Einerseits kann man sich in die Admin Oberfläche des Mapservers einloggen und einen Wizard „Create new map“ starten, der einem in wenigen Schritten den verfügbaren Kartenausschnitt, den Maptyp, die verfügbaren Actions (Stichwortsuche, Routing etcetera) und Datensets auswählen lässt. Ist der Wizard beendet, liegt eine Webapp vor die auf dem selben Server oder – nach dem Herunterladen des WAR Files – auf einem anderen Server deployed werden kann. Oder man erstellt seine Map mit einem WYSIWYG Editor der ein JSP mit JSF Tags generiert. Die vom ESRI Mitarbeitenden „selbst generierte“ Map liess einem auf dem Stadtgebiet von Bagdad Start- und Zielort von Militärkonvoys setzen, worauf der Mapserver eine Route „um gefährliche Gebiete herum“ vorschlug. Ausgewählt werden konnte auch der Fahrzeugtyp, so hätte der Mapserver bei Panzern etwa andere Strassen gewählt als bei kleineren Patrouillenfahrzeugen.

    Auch von ESRI gibts es Developer Ressourcen, namentlich das „ESRI Developer Network (EDN)„. Damit kommt man an Ressourcen um eigene Maps in Desktop- oder Webanwendungen zu integrieren. Leider gibt es das nicht kostenlos, die jährliche Gebühr beträgt USD 1500.-.

    Ein ganz interessantes Produkt von ESRI ist „ArcWeb Services 2006„, damit lassen sich eigene Maps mittels unterschiedlicher APIs (SOAP, REST, JavaScript und anderen) Maps in die eigene Anwendung integrieren. Auch dieses Angebot ist aber nicht gratis.

    Googles Web Toolkit

    Am Stand von Google wurden neben dem Verteilen eines Merkblatts für eine allfällige Bewerbung und der Visitenkarte eines Recruiters auch Google Checkout und der brandneue „Google Web Toolkit“ vorgestellt. Leider fiel eine angekündigte Demonstration des GWT wegen zeitweiliger Netzwerkprobleme ins Wasser. Kurz beschrieben bietet der GWT dem Java Entwickler die Möglichkeit OHNE Javascript Kenntnisse Ajax Applikationen zu erstellen. Dazu kommt GWT mit einer Fülle vorgefertigter Elemente die vom Entwickler einfach in dessen Anwendung integriert werden können.

    Weitere Aussteller

    Des weiteren war ich noch an den Ständen von SoftwareFX, wo man mir eine CD mit „Chart FX for Java“ überreichte, bei Interface21 (bei der Verlosung von Büchern und eines TomTom ging ich leider leer aus), Terracotta (da suchte ich – entgegen anderslautender Ankündigungen – vergeblich nach jemanden der sich gut mit DWR auskannte), Canoo aus Basel (der Anbieterin von ULC, wo sich der Herr am Stand an Jürgs Blogeintrag erinnert hat, einem Framework für die Entwicklung von GUIs für „Java Rich Internet Applications“), Altova (der Herstellerin von XMLSpy), der Eclipse Foundation (Version 3.3, „Europa“, folgt im Juni), der java.net Community, beim freundlichen Spielzeugroboter WowWee und IBM, wo ich mir ein Tool für Data modelling zeigen liess.

    Veröffentlicht unter Mobile

    Location API, Stress und DWR

    Mittwoch, 9. Mai, JavaOne 2007

    Hinweis: im JavaOne TODAY Newsletter vom Mittwoch wurde der Ablageort sämtlicher Slides der Speeches von JavaOne 2007 publiziert: http://www.cplan.com/javaone2007/contentcatalog (Zugangsdaten über mich).

    Bring Map and Navigation Capabilities to Your Location-Based Applications with JSR 293, Location API 2.0

    Zu Beginn der Session wurden ein paar nette Zahlen serviert: LBS sei die am schnellsten wachsende Sparte im Wireless Bereich, mehr als 85% aller Subscriber seien an solchen Dienstleistungen interessiert (naja). Ende 2008 würden 25 Prozent aller WCDMA Geräte GPS tauglich sein; also: los gehts! Aber es gibt Hürden: die Lokalisierung und das Mapping. Genau hier setzen die beiden JSR 179 und 293 (Erweiterung von 179) an.

    Die Location 2.0 API soll folgende Funktionen regeln:

    • Geocoding (Adresse -> Koordinaten; aber auch Reverse, Koordinaten -> Adresse)
    • Mapping (Das Anzeigen einer Karte)
    • Navigation (Routing)
    • Landmark exchange (einheitliches Format zum Austausch von POIs)

    Typische Einsatzgebiete für Anwendungen, die auf Location Based Services basieren, liessen sich folgendermassen kategorisieren: Sicherheit, POI Navigation, Verkehr, Social Networking, Sport und Fitness sowie Gaming. Und eine Map bestehe immer aus einer Kombination von Inhalten der Typen Area (das von der konkreten Map abgedeckte Gebiet), Landmarks (der auf der Map angezeigten POIs), Location (Standort des Subjekts/Objekts) und Route. Was genau auf der Karte dargestellt wird, unterscheide sich aufgrund der „Operation“ auf welcher die aktuelle Map basiert; einerseits können einer Map die darzustellenden Informationen mitgegeben werden. Andererseits kann die Map alle in jenem Umkreis verfügbaren Informationen darstellen.

    Eine auf dem Location API basierende Anwendung funktioniert nun (grob) nach dem folgenden Muster: die Klasse ProviderManager bietet den Zugriff auf vorhandene ServiceProvider, von welchen es drei Typen gibt: Geocoding, Map und Navigation. Alle drei Typen erweitern das Interface ServiceProvider und bieten eigene, ihrem Zweck dienende, Methoden an.

    Mehr Infos dazu auf jcp.org.

    Stress Your Web App Before It Stresses You: Tools and Techniques for Extreme Web Testing

    Leider konnte der etwas reisserische Titel zumindest meine Erwartungen nicht erfüllen; die beiden redegewandten und zu Scherzen aufgelegten Brasilianer beschränkten sich neben den üblichen Testtipps (teste NICHT oder zumindest nicht nur die einfachen Fälle etcetera) auf die Vorstellung und Demonstration von Apaches JMeter. Für jemanden der das Tool bisher nicht kannte sicherlich interessant, für mich soweit aber nix neues, leider.

    Erwähnenswert an dieser Stelle vielleicht noch das JMeter nicht nur zum parallelen Zugriff und Testen von Webapps verwendet werden kann, sondern auch Tests gegen DB, Mail und andere Server fahren kann.

    Hands-on DWR

    DWR (Direct Web Remoting) kurz beschrieben: man kann damit sehr schnell und einfach bestehende Java Services oder Controller Klassen als Javascript Bibliotheken exportieren und diese dann mit Ajax ansprechen. Drei Schritte sind dazu notwendig:

    • 1. dwr.jar in Classpath aufnehmen
    • 2. Im web.xml ein DWR Servlet hinzufügen
    • 3: DWR mittels dwr.xml konfigurieren

    Fertig. DWR wird im Übrigen mit einem WAR File geliefert, welches Beispiele und die Dokumentation enthält.

    Das dies wirklich so einfach funktioniert wies tönt, habe ich bereits selbst ausprobieren können; die POI Layers Anwendung von namics verwendet DWR um per Ajax die POIs auf die Map zu kriegen und – demnächst – um auch neue POIs hinzuzufügen.

    Was bei DWR sicherlich von grossem Interesse ist: die Sicherheit. Dieser wird bei DWR grosse Bedeutung beigemessen; grundsätzlich tut DWR daher nichts was man nicht explizit zulässt. So kann man zum Beispiel die Methoden einer Klasse einzeln freigeben und die exportierten Domainklassen (die Return Werte und Übergabeparameter der freigegebenen Methoden), sofern nicht Java Sprachumfang, müssen für den Export ebenfalls freigegeben werden.

    Nachdem DWR 1 nun seit etwa 2 Jahren existierte, wurde vor circa 2 Wochen DWR 2 lanciert. Grösste Neuerung dabei ist das sogenannte „Reverse Ajax“. Damit kann der Server die „verbundenen“ Browser über sogenannte Scriptsessions (ein fünfter Scope wenn man so möchte) über neue Daten informieren und diese auch mit Daten versorgen. Auch hier wurde der Sicherheit natürlich grossen Stellenwert beigemessen (Stichwort Cross Site Scripting).

    Beeindruckend war das Schiffe-Versenken Spiel realisiert mit Ajax, an der Session haben sie das zu dritt (ein Teilnehmer aus dem Publikum gesellte sich ohne Vorankündigung noch dazu) live demonstriert.

    DWR hat im Übrigen auch eine eingebaute Unterstützung für Accessability; sogenannte „Pluggable Notifiers“ informieren den Benutzer etwa bei Veränderungen mittels Ton oder lassen ein Feld aufblinken. Es können auch eigene solche Notifiers entwickelt werden.

    JPA 2.0 und Tele Atlas

    Mittwoch, 9. Mai, JavaOne 2007

    Java Persistence 2.0

    Die Java Persistence API 1.0 wurde zusammen mit EJB 3.0 eingeführt – Version 2.0 soll bestehende Schwachpunkte und Bugs ausmerzen sowie fehlende Kompontenten nachliefern. Angestrebt wird dazu ein neuer JSR, der unter anderem folgende an der Session angesprochene Punkte behandelt haben wird.

    • Mehr Flexibilität bei der Gestaltung des zu persistierenden Modells (namentlich unter anderem Embeddables, Ordered lists und multiple Accesstypen pro Klasse)
    • Verbesserungen beim O/R mapping (One-to-many, Single table versus Joined subclasses Strategie)
    • Erweiterte Querying Möglichkeiten (weitere Operatoren und Funktionen oder etwa Beinflussung des Polymorphismus beim SELECT Statement durch Angabe der erlaubten Typen)
    • Criteria queries (hier soll zum Beispiel von Hibernate gelernt werden)
    • Validierung und Wertebereiche (@Required, @Length etcetera)

    Der JSR soll demnächst veröffentlicht und die Expertengruppe im Juni 2007 gegründet werden. Ziel ist es, Java Persistence API 2.0 mit EE 6.0 zu realisieren.

    JavaOne Pavillon

    Heute schaute ich am Stand von Tele Atlas, neben Navteq dem andern grossen Anbieter von Mapdaten, vorbei. Im Grossen und Ganzen gesehen funktionieren die beiden Konkurrenten in ihrem Kerngeschäft (Erfassung von Strassendaten und POIs) identisch, beide erfassen die Strassen mit eigenen Fahrzeugen (ausgerüstet unter anderem mit Kameras) welche ständig unterwegs sind. Allerdings war Tele Atlas „alleine“ am Stand, Navteq hingegen hatte einige Partnerfirmen (Autodesk, deCarte und andere) um sich geschart.

    Zwei Angebote von Tele Atlas wurden mir näher vorgestellt: zum einen der „Tele Atlas DeveloperLink“ und zum andern den „Tele Atlas ContentLink„. Ersteres bietet Entwicklern – ohne Kosten – unter anderem den Zugang zu Beispieldaten, weiterführenden Informationen technischer Natur und Diskussionsforen. Der ContentLink von Tele Atlas (offenbar erst seit circa 2 Monaten online) bietet einem Map Anbieter die Möglichkeit nach weiteren Mapinhalten für seine Mapping Anwendung zu suchen. Die POI Datensätze, die auf der ContentLink Webseite gelistet werden, werden direkt von Dritten angeboten und können nach Abschluss einer Vereinbarung mit diesen heruntergeladen und verwendet werden.

    Profiling mit NetBeans

    Mittwoch, 9. Mai, JavaOne 2007

    Anmerkung: nachdem ich gestern alle Notizen in einem Eintrag zusammengefasst habe (und dieser dadurch etwas lange wurde), werde ich die nächsten Einträge jeweils nur noch einem oder zwei Themen widmen.

    Quick and Easy Profiling with Integrated Tools

    Das Ziel der Session in einem Satz zusammengefasst: Profiling mit der IDE, ohne auf ein separates Tool zurückgreifen zu müssen. Die Beispiele wurden allesamt mit NetBeans 5.5 oder mit der bereits verfügbaren Preview (M9) von 6.0 gezeigt, welche auf der Homepage zum Download bereitliegt.

    Der in NetBeans integrierte Profiler bietet Hand die drei typischen Problemklassen zu analysieren: Threading (zu wenige versus zu viele Threads), CPU Belastung und Memory Leaks. Der Profiler kann mit einem Wizard gestartet werden, wo man den gewünschten Profiling Task wählt. Der Einstieg fällt mit der Auswahl von sogenannten Profiling Roots einfach – man wählt zum Beispiel aus, welche Methoden untersucht werden sollen. Alternativ können auch sämtliche Methoden aller Klassen untersucht werden, was der Performance des ausgeführten Programms aber sehr zu schaffen macht.

    In einem der gezeigten Beispiele wurde durch die Auswahl von bestimmten Methoden etwa eine Reduktion der instrumentalisierten Methoden von circa 19’000 auf deren knapp 200 realisiert. Läuft die Anwendung, kann man sich einen Snapshot anzeigen lassen und kann von der Auswertung per Mausklick direkt in den Source Code wechseln. Der Profiler kann nicht nur mit der lokalen JRE verwendet werden, es können auch Server eingerichtet und damit darauf laufende Anwendungen untersucht werden.

    Eindrücklich die vorgetragene Case Study: eine Anwendung von Sun, über ungefähr 4 Jahre entwickelt mit circa 150’000 Lines of code, wies im Live Betrieb ein Memory Leak auf. Dank dem „Generation Count“ des Profilers wurde eine Inner Class namens „BackgroundProcess“ als Quelle des Ungemachs identifiziert und modifiziert, so dass die Anwendung fortan keine Memory Leaks mehr in sich barg.

    NetBeans 6.0, welches noch in diesem Jahr lanciert werden soll (Preview Version wie eingangs erwähnt bereits erhältlich), wird im Profiling Bereich noch weiter ausgebaut sein, nachfolgend einige Merkmale:

    • Integration von JMeter
    • Profiling Points, weiterer Verfeinerungsgrad des Profilings, in ihrer Anwendung vergleichbar etwa mit Break Points beim Debuggen
    • Integration von HeapWalker (Visualisierung/Offenlegung des Heaps)
    • „Areas of Interest“ – High Level Visualisierung des Speicherverbrauchs
    • Dynamic attaching/detaching des Profilers
    • NetBeans 6.0 wird den Profiler bereits in der Standardversion enthalten
    • Profiling von JSPs

    Weiterführende Informationen und unter anderem einen Blog findet man auf der Homepage des NetBeans Profiler Teams.

    JavaOne 2007, Tag 1

    Ich habe diese Woche die Möglichkeit erhalten, die JavaOne Konferenz in San Francisco zu besuchen; ich möchte in den nächsten vier Tagen an dieser Stelle über die aufgeschnappten Informationen berichten und diese so einem grösseren Publikum zugänglich machen.

    Dienstag, 8. Mai

    Open Java: Imagine the Possibilities (Opening session)

    „Don’t be shy“, nutze die Möglichkeiten der Konferenz und versuche mit möglichst vielen Leuten ins Gespräch zu kommen. Dies die ersten Worte – well, mit 10-15 Tausend Anwesenden natürlich schier unbegrenzte Möglichkeiten! Danach folgte die Darlegung des Hauptanliegens der diesjährigen JavaOne und deren Slogan „Open Possibilities“. Kurz zusammengefasst: das Ziel ist es, mittels Java das Internet respektive Rich applications und Multimedia Inhalte auf Mobile Devices zu kriegen. Flächendeckend, grenzenlos und überall. Im Kontext dieses ehrgeizigen Ziels folgten mehrere Announcements mit Vertretern der jeweiligen Köpfe bei Sun und deren Partnern.

    Los gehts

    • Glassfish: das bestehende Projekt soll „aufgebohrt“ und der Fokus auf Multimedia gerichtet werden. Als Partner hat Sun dazu Ericsson an Bord geholt, mit der Kombination Open Source, Ericsson und Glassfish soll der Enduser Multimedia Inhalte immer und überall zur Hand haben. Auf dem Demovideo wurden etwa auf dem Handheld Musik von zu Hause gestreamt oder dem Sohn das Abspielen des von ihm angeforderten Films verweigert :-).
    • Verbesserung im Bereich Realtime Java, java.lang.Thread -> javax.realtime.RealtimeThread. Als „Partner“ wurde hier der CIO von Nasdaq, dessen Trading Software auf Java läuft, auf die Bühne geholt – die „Quizfrage“, ob Nasdaq 4, 17, 39 oder 89 Transaktionen pro Sekunde zu bewältigen hat, wurde mit der Summe dieser Zahlen beantwortet ;-). Gegenwärtig arbeitet Nasdaq zusammen mit Sun an einer neuen Version der Trading Software, bei welcher die erneuerte Java Realtime API zum Einsatz kommen soll.
    • Ebenfalls wurde mit Sony eine Kooperation bei dessen Blu-Ray Technologie angekündigt; da sollen mit Hilfe von Java FX (siehe unten) etwa interaktive Menus über einen Film gelegt oder gar Spiele integriert werden.
    • Netbeans 6 mit Fokus Rich Internet Applications wurde ebenfalls auf bald angekündigt, mit Plugin Funktionalität für andere Sprachen wie etwa JRuby, Javascript und C++. Besonders hervorgehoben wurde die starke Unterstützung der Entwicklung von Anwendungen für mobile Endgeräte.
    • Besonderen Anklang fand die Verkündung dass OpenJDK nun verfügbar sei (die Webpage werde noch angepasst) und ein sogenanntes Governing Board (bestehend aus 5 Personen), dessen Aufgabe die Lenkung und Steuerung der Community sein wird, gewählt wurde. OpenJDK wird unter GPLv2 lizenziert, was durch die dadurch breite Abstützung auf einer grossen Community ein grosses Mass an Kompatibilität garantiere.
    • Faster, faster, faster: das Thema der Performance wird gross geschrieben, auf Herbst 2007 wurde die schnellste je verfügbare JRE angekündigt.
    • Java goes Scripting: Ankündigung der JavaFX Produktefamilie mit starkem Endnutzer Fokus. Bestandteile sind vorerst Java FX Script, eine in der SE integrierten Scripting Sprache zur einfachen Erstellung von Rich Internet Applications. Java FX Script gibt es bereits als Preview Release, die dazugehörigen Tools sollen demnächst lanciert werden.
    • Java FX Mobile: ebenfalls in der SE integrierte Unterstützung speziell für Mobile Devices. Partner in diesem Bereich ist Yahoo!, neben einer Websuche und E-Mail soll auch Flickr speziell für Java FX Mobile Devices hergerichtet werden, fortan sollen Handies also nicht mehr nur Fotos an Flickr senden, sondern diese auch anzeigen.

    PayPal: New Solutions for Java Developers

    Als Erstes wurden ein paar Fakten geliefert: Gründung 1998, >140 Millionen Accounts, Milliardenumsatz. Und das Beste: E-Commerce wächst! Aber: „Checkout on the web stinks“, dies die Ausgangslage.

    Das grösste Problem sei, dass die überwiegende Mehrheit aller Shops für den Abschluss einer Transaktion einen Login auf der Seite oder – wenn noch nicht vorhanden – das Anlegen eines Profils verlangen. Bei diesem Schritt gingen viele Kunden verloren; verhindert werden könne dies, wenn man dem Kunden alternative Zahlungsmethoden anbietet und so das Vorhandensein eines Accounts nicht mehr zwingend sei.

    Paypal bietet dazu zwei Möglichkeiten: eine mittels HTTP Post, und, für fortgeschrittene Ansprüche und Einbindung in Software mit Hilfe einer API: Paypal Checkout Express. Das ganze läuft mit 3 API Calls ab – beim ersten Call wird ein Token ausgemacht und der User wird auf eine Paypal Login Seite umgeleitet. Mit dem zweiten Aufruf werden die User Daten von Paypal abgeholt und der dritte und letzte Call schliesst die Transaktion ab.

    Mit Hilfe der Digital Money Platform von Paypal kann man noch einen Schritt weiter gehen, unterstützt werden unter anderem auch das Überweisen von Beträgen an Zielkonti, die Suche nach Transaktionen, die Abfrage von Kontoständen, das Verwalten von Zahlungen und bald auch Wiederkehrende Zahlungen.

    Für die Verwendung dieser Funktionalitäten sind API Credentials notwendig. Neben der bisherigen auf SOAP basierenden Lösung gibt es neu auch eine RESTful Version. Infos dazu gibts auf http://paypal.com/developer.

    Navteq und Partner, JavaOne Pavillion

    Am Mittagstisch hatte ich mich aus purem Zufall just neben eine Dame von Autodesk gesetzt, welcher ich gleich nach dem Essen an den Stand von Navteq folgte mich nach dem Essen an den Navteq Stand mitnahm. Autodesk kannte ich bisher nur als Anbieter der CAD Software AutoCAD, bietet darüber hinaus aber auch Produkte im Bereich Location Based Services an. In dieser Produktefamilie etwa den „Family Minder“, mit dem die Eltern, dank spezieller mobiler Endgeräte, sich den aktuellen Standort ihrer Sprösslinge anzeigen lassen können. Auch bietet Navteq eine Developer Schnittstelle an, die unter anderem für Geocodierung verwendet werden kann. Mehr Infos dazu unter http://www.autodesk.com/lsdevprogram.

    Mit den Leuten von Navteq selbst habe ich mich über das Zustandekommen Ihrer Daten (v.a. Strassenkarten und geocodierte Adressen) unterhalten. Es ist tatsächlich so, dass circa 600 professionelle Vermesser permanent für Navteq auf den Strassen unterwegs sind und diese (samt POIs) so in den Datenbestand von Navteq aufnehmen. Des weiteren tut sich aber auch bei Navteq etwas in Richtung Location Based Services, so sollen sich User von Mobile Devices Dienstleistungen und Restaurants etc. in Städten, in der Näher ihrer aktuellen Position, anzeigen lassen können. Auf meine Frage hin wie die Position der Personen bestimmt werden soll (in Städten ist die Lokalisierung mittels GPS nicht ohne weiteres möglich), kam die sogenannte „WiFi enabled“ Lokalisierung zur Sprache, bei welcher aufgrund des Access Points, über den sich der User gerade im Internet bewegt, die Position des Nutzers bestimmt wird. Um an solche Daten (vorerst nur Nordamerika) heranzukommen, ist Navteq eine Kooperation mit der Firma Skyhook Wireless eingegangen. Leider hat die Person am Stand plazes nicht gekannt, staunte aber nicht schlecht als ich ihm sagte dass alle Locations in den USA, wo ich bisher Zugang ins Internet fand, bei plazes bereits bekannt waren.

    Ebenfalls am Stand von Navteq mit dabei war deCarta, Anbieterin eines draggable Mapservers mit sehr weitreichenden Konfigurationsmöglichkeiten. So können etwa die Farben bestimmter Mapinhalte oder auch die Schriftart bestimmt werden. Als Beispiel in Europa hat man mir http://www.herold.at gezeigt – die gelben Seiten für Österreich. Mein Gesprächspartner am Stand war übrigens der Referent des Vortrags „Developing Web 2.0 Mapping Applications“, welcher leider bereits ausgebucht war und ich darum nicht habe besuchen können. Geoff, so sein Name, verpasste mir darauf eine Schnellbleiche seines Vortrags. Interessanterweise hatte er Endoxon nicht gekannt, beim Rumspielen mit der Karte auf local.ch hat er dann aber recht interessiert „ah, digital zoom“, „vectors“ und andere Dinge gemurmelt :-). Insgesamt zeigte er sich natürlich erfreut über die aktuell hohe Brisanz des Themas Mapping und meinte dass das Javascript API von Google hier vorallem „Schuld“ sei daran, zuvor sei es in diesem Bereich lange eher ruhig gewesen.

    Integration Gets All Mashed Up: Bridging Web 1.0 and Web 2.0 Applications

    Der erste Satz des Referenten: Mashup ist nicht gleich Google Maps mit irgendwas! :-) Und bald würden Enterprise mashups stark an Bedeutung zunehmen. Bei dieser Art von Mashups geht es darum, Daten meist interner Applikationen durch den Anwender (weg vom Coden, hin zum Zusammenfügen) mittels Wizards zu konkreten Fragestellungen fallbezogen kombinieren zu lassen. Web 1.0/2.0 darum, weil diese internen Applikationen meist in „1.0 Form“ vorliegen, die Mashups aber „2.0“ sein sollen.

    Die Nachteile von Web 1.0 (wenn es um die Wiederverwendung der Inhalte oder Funktionalitäten geht): meist starke Kopplung und Aufwand. Handkehrum ist eine sehr lose Kopplung bei Web 2.0 der Fall. Bezüglich Syndication wurde angeraten das gut standardisierte Atom dem den Geschmäckern der Entwickler ausgesetzten RSS vorzuziehen.

    Wie dies mit den Widgets genau aussehen soll, wurde nicht eingehender besprochen; ein sehr einfaches Beispiel hat der Referent allerdings mit dem „Kapow Mashup Server“ vorgeführt.

    Die folgende Grafik zeigt auf, wie diese Enterprise Mashups funktionieren sollen.

    mashups.jpg

    Um diese zu ermöglichen, müssen einfach gesagt alle alten Applikationen mit sogenannten „Widget Enabler“ ausgestattet werden. Diese ermöglichen dem Endnutzer (resp. den Widget Builder) bei der Erstellung der Mashups auf die Daten und Funktionalitäten der Applikationen zuzugreifen.