Results for category "Entwicklung"

42 Articles

Build and deploy your Xtext DSL with Maven Tycho

A few days ago I finished my bachelor thesis with the title Integrating Xtext in an existing Software development process. I developed a domain specific language with Xtext and some extensions for easily adding new generators as new Eclipse plug-ins.

After finishing the thesis I added a Maven Tycho based build configuration. The build configuration can be easily deployed to TeamCity, Hudson or any other build server of your choice. I assume that you have already developed an Xtext based DSL and you know a little bit about OSGi and Maven.

The complete project source code can be found at https://github.com/schakko/xtext-plugin-with-maven-tycho

Preparations

First of all you should think about a sensible directory structure. I use the following organization

  • /plugins contains your Eclipse based plug-ins
  • /features contains the Eclipse features for bundling your plug-ins
  • /releng is used for the release engineering process and holds the project for the p2 update site
  • /pom.xml is the master POM for your complete project.

Directory structure of your DSL project

Set up the master pom.xml

Every pom.xml inside the subdirectories inherits from the master pom.xml. The configuration defines all modules of your project, sets the needed plug-in repositories and plug-ins. The most interesting part of the lifecycle configuration is, that the xtend-maven-plugin is not executed in generate-sources but generate-resources. This is needed as the MWE2 workflow of your DSL project has to be executed first. If you have both plug-ins inside the generate-sources phase the xtend-maven-plugin will be called first, resulting in a ClassNotFoundException as the DSL infrastructure is not generated yet. So the compilation of Xtend is moved to generate-resources which is executed after generate-sources phase. Another solution would be moving the xtend-maven-plugin to every child pom but this means duplicate configuration code.

Set up your DSL project

pom.xml

The pom.xml contains the plug-in for executing the MWE2 workflow. Notice that your <workflowDescriptor> must begin with src/ or you will receive the message Cannot create a resource for…. All the other stuff is straight forward. The packaging type eclipse-plugin is introduced by the tycho-maven-plugin.

build.properties

The file build.properties contains the source and binary folders. This is important, as tycho-maven-plugin uses this file as reference for compiling and packaging the sources. The xtend-gen directory must be added.

META-INF/MANIFEST.MF

It is important, that your Bundle-Version must end with the suffix .qualifier, e.g. 1.0.0.qualifier. The string is automatically replaced with the build date.

Set up your test project

Copy generated files

At first the two automatic generated files from src-gen (*InjectorProvider.java and *UiInjectorProvider.java) must be copied to the src folder if you want use the xtend-maven-plugin. The Xtend Maven plug-in does not allow (at least in version 2.2.1) any additional source pathes so that none class in src-gen can be found by xtend-maven-plugin. Remove the src-gen directory from your Eclipse classpath too.

pom.xml

The pom.xml for the test project uses a different Xtend version because I ran into heavy problems with the xtend-maven-plugin using the ValidatorHelper. Referencing the ValidatorHelper class results in a GenericSignatureFormatError. Sven Efftinge mentioned yesterday that the bug should be fixed in the latest snapshot.

The packaging type must be eclipse-test-plugin.

pom.xml of your test project

build.properties

Include the xtend-gen directory and make sure that the src-gen directory is not included because of the xtend-maven-plugin problem.

META-INF/MANIFEST.MF

The MANIFEST.MF uses the Import-Package statement for importing Mockito. See the next section how to set up this dependency.

Creating a dependency project

I used Mockito as mocking framework inside my tests. Adding this dependency is a little bit tricky:

  • Adding the mockito-all-1.9.5.jar to your Eclipse build path does not work. Maven does not know anything about your .classpath settings.
  • Adding a dependency to the pom.xml means that the compilation with Maven would work but not the installation on the client because there is no OSGi package for Mockito available.
  • Converting the mockito package to an OSGi package is not ideal. Every dependeny must be repackaged.

A much better solution is including the required JAR files inside an own OSGi package. I took the idea from the atlassian-connector project.

New Plug-in project

Create a new Eclipse plug-in project, create a folder lib and copy the  mockito-all-1.9.5.jar inside.

pom.xml

Nothing new, just use eclipse-plugin as packaging type.

build.properties

Your build.properties must include the lib directory.

META-INF/MANIFEST.MF

Here comes the interesting part. We use Bundle-ClassPath to define the additional path to the mockito JAR file. Every package inside this JAR file is re-exported via Export-Package.

Include the mockito framework in an OSGi bundle

Set up your UI project

pom.xml

The pom.xml must use the packaging type eclipse-plugin.

build.properties

I added the schema and icons directory and plugin.xml. This depends on your needs.

META-INF/MANIFEST.MF

Nothing new.

Set up your feature projects

Features are bundles which consist of different plug-ins. Lars Vogel made a good tutorial which you can use for more information

We need to create two features:

  • A runtime/core feature with your DSL and UI plug-in
  • A test feature with the test and dependencies plug-in

pom.xml

Create a pom.xml and use the packaging type eclipse-feature.

Configure the core feature

Set up your update site

The update site contains every feature the user can install. Lars wrote a tutorial about this but my needs were different. I wanted to deploy the content on a local webserver with a simple copy command.

To do so, generate a new update site project inside your releng directory and add a category definition (in Eclipse: Plug-in Development > Category Definition).

category.xml

The category.xml contains the features which are available through he update site. First of all, add a new category named “Xtext” and assign both of your previously created features to this category.

pom.xml

The packaging must be eclipse-repository. I use the copy-maven-plugin for copying the update site to the local webserver.

Configure the update site for your features

Run it local

With all these settings the project can be build inside Eclipse without m2e plug-in and on the command line. Go to the command line and execute mvn install:

Successful build on command line

Move it to your build server

Create  a new configuration in your TeamCity instance and add a Maven buildstep. I pass the -DupdateSite.target parameter for specifying the destination directory of the update site.

Configure the Maven build step in your TeamCity instance

Install your plug-ins

Enter the path to your update site and you will see your installable Xtext DSL

Install your Xtext DSL in Eclipse

TeamCity: Make the NuGet repository available without authentication

Task for today was making the NuGet repository of TeamCity available in our local network. Sounds easier as it was as our TeamCity instance is available from the Internet but you can only access the rontend with valid domain credentials (LDAP/Active Directory authentication). Enabling the guest account feature in TeamCity would have mean a small security break in our concept.

Here is the success-story how to enable the NuGet repository for local accesss without authentication and without enabling the TeamCity guest account:

Creating a new proxy instance

One of our Apache servers got the order to act as reverse proxy for the NuGet repository. The reverse proxy was running inside an own virtual host (nuget.mydomain.local) and was registered in our local DNS.
The configuration looked like this:


<VirtualHost *:443>
 SSLEngine on
 SSLProxyEngine on

ServerAdmin admin@mydomain.local
 ServerName nuget.mydomain.local
 ServerAlias nuget.mydomain.de

LogLevel warn
 ErrorLog logs/nuget.mydomain.local-error_log
 CustomLog logs/nuget.mydomain.local-access_log combined

# Map other source to FeedService URL
ProxyPass / https://teamcity.mydomain.local:443/guestAuth/app/nuget/v1/FeedService.svc/
ProxyPassReverse / https://teamcity.mydomain.local:443/guestAuth/app/nuget/v1/FeedService.svc/

</VirtualHost>

Adding a domain proxy user

With the configuration above we still have the problem that there is no user who can access the repository without credentials. So we need to add a domain user, let me call it teamcity-nugetfeed-proxy-user. For security reasons this account has a very long random generated password and is only used for providing the NuGet feed.

Using the domain proxy user in our Apache configuration

We have to add a Basic Authorization header in our Apache configuration so that every access between the proxy and TeamCity is authenticated.


RequestHeader set Authorization "Basic <Base64(teamcity-nugetfeed-proxy-user:$password)>"

The phrase <Base64(teamcity-nugetfeed-proxy-user:$password)> must be replaced by an base64-encoded string with format $username:$password.

After restarting the Apache you should be able to use the NuGet stream in Visual Studio. Look at the Apache logs for occuring errors.

TeamCity is failing – NuGet return “File contains corrupted data”

Till yet you are able read the stream but TeamCity will fail downloading your repository files. The reason is easy: The FeedService.svc returns an XML file which contains absolute pathes mapping to teamcity.mydomain.local and not nuget.mydomain.local. So again we have no authorization and the error File contains corrupted data occurs because of the TeamCity login dialogue.

We have to rewrite the content of the FeedService.svc replacing every occurence of teamcity.mydomain… with nuget.mydomain…
At first I tried mod_proxy_html but in the end using mod_substitute was the only solution that worked.


# Rewrite FeedService URL
 Substitute "s|https://teamcity.mydomain.local/guestAuth/app/nuget/v1/FeedService.svc|https://nuget.mydomain.local|i"
# Rewrite repository access
Substitute "s|https://teamcity.mydomain.local/guestAuth/repository|https://nuget.mydomain.local/repository|i"

# Execute every substitution only for XML/HTML
 AddOutputFilterByType SUBSTITUTE text/html
 AddOutputFilterByType SUBSTITUTE text/xml
 AddOutputFilterByType SUBSTITUTE application/atom+xml

# Map local repository path to remote repository
 ProxyPass /repository https://teamcity.mydomain.local:443/guestAuth/repository
 ProxyPassReverse /repository https://teamcity.mydomain.local:443/guestAuth/repository

# Unset gziped accepted encoding
RequestHeader unset Accept-Encoding

After restarting everything should work fine.

The complete configuration is now


<VirtualHost *:443>
 SSLEngine on
 SSLProxyEngine on

ServerAdmin admin@mydomain.local
 ServerName nuget.mydomain.local
 ServerAlias nuget.mydomain.de

LogLevel warn
 ErrorLog logs/nuget.mydomain.local-error_log
 CustomLog logs/nuget.mydomain.local-access_log combined

# Rewrite FeedService URL
 Substitute "s|https://teamcity.mydomain.local/guestAuth/app/nuget/v1/FeedService.svc|https://nuget.mydomain.local|i"
 # Rewrite repository access
 Substitute "s|https://teamcity.mydomain.local/guestAuth/repository|https://nuget.mydomain.local/repository|i"

# Map local repository path to remote repository
 ProxyPass /repository https://teamcity.mydomain.local:443/guestAuth/repository
 ProxyPassReverse /repository https://teamcity.mydomain.local:443/guestAuth/repository
 # Map other source to FeedService URL
 ProxyPass / https://teamcity.mydomain.local:443/guestAuth/app/nuget/v1/FeedService.svc/
 ProxyPassReverse / https://teamcity.mydomain.local:443/guestAuth/app/nuget/v1/FeedService.svc/

# Execute every substitution only for XML/HTML
 AddOutputFilterByType SUBSTITUTE text/html
 AddOutputFilterByType SUBSTITUTE text/xml
 AddOutputFilterByType SUBSTITUTE application/atom+xml

RequestHeader set Authorization "Basic <Base64(teamcity-nugetfeed-proxy-user:$password)>"

 # Unset gziped accepted encoding
 RequestHeader unset Accept-Encoding
</VirtualHost>

Eclipse: "No persistence.xml file found in project"

Für mein aktuelles Projekt setze ich u.a. JPA/EclipseLink, Maven und Spring. Damit der Build-Prozess von Maven und das automatische Deployen in den Tomcat-Container von Eclipse funktioniert, musste ich ein paar Änderungen an der .settings/org.eclipse.wst.common.component durchführen:

<?xml version="1.0" encoding="UTF-8"?>
<project-modules id="moduleCoreId" project-version="1.5.0">
    <wb-module deploy-name="YourProject">
        <wb-resource deploy-path="/" source-path="/src/main/webapp"/>
	<wb-resource deploy-path="/WEB-INF" source-path="/src/main/resources"/>
        <wb-resource deploy-path="/WEB-INF/classes" source-path="/src/main/java"/>
        <wb-resource deploy-path="/WEB-INF/classes" source-path="/src/test/java"/>
        <wb-resource deploy-path="/WEB-INF/classes" source-path="/src/test/resources"/>
        <property name="context-root" value="YourProject"/>
        <property name="java-output-path" value="/YourProject/target/classes"/>
    </wb-module>
</project-modules>

Nach dem nächsten Start von Eclipse bekam ich nun folgenden, nichts-sagenden Fehler vom Eclipse-JPA-Plugin: No persistence.xml file found in project.. Pustekuchen, denn unter src/main/resources/META-INF/persistence.xml war die Datei zu finden und auch im Classpath so eingerichtet. Nach einigem hin und her probieren habe ich dann die (absolut bescheuerte) Lösung für das Problem gefunden.

Der Inhalt des ressource-Ordner muss nach /WEB-INF/classes kopiert werden, und zwar an vierter Stelle:

        <wb-resource deploy-path="/WEB-INF/classes" source-path="/src/main/java"/>
        <wb-resource deploy-path="/WEB-INF/classes" source-path="/src/main/resources"/>

Die Logik dahinter ist mir schleierhaft, da ja davon eigentlich auszugehen ist, dass das JPA-Plugin die persistence.xml aus dem Classpath anzieht.

Debugging von C-Applikationen unter Linux

Da ich gegenwärtig an libopenranked von etqw-openranked arbeite und ich vermute, dass ich meine Erkenntnisse nach einiger Zeit wieder vergesse, gibt es hier die Kurzfassung.

Damit bei einem Segmentation Fault eine Core-Dump erzeugt wird, muss

ulimit -c unlimited

aufgerufen. Damit wird festgelegt, dass der Core-Dump beliebig groß sein darf.

Mit

gdb a.out core
backtrace

lassen sich die letzten Ausführungsschritte der Applikation anzeigen.

Mit

apt-get install valgrind
valgrind --tool=memcheck --leak-check=yes ./a.out

lässt sich überprüfen, welche Funktionen potenzielle Memory Leaks erzeugen, die wiederum zu einem Segmentation Fault führen können.

Daily Hack: Manuell aus RSSPopper eine OPML erstellen

Am Mittwoch habe ich meinen Urlaub angetreten und mir meine OPML-Datei, die ich in meinem Firmen-Outlook eingerichtet  habe, per E-Mail zugeschickt, so dass ich auf meinem Privat-Notebook in meiner Urlaubszeit immer noch die News als RSS durchschauen kann.
Heute Abend wollte ich dann die OPML-Datei aus Outlook Web Access in Liferea einspielen. Leider gab es ein Problem: über OWA konnte ich (warum auch immer) den Anhang meiner E-Mail nicht herunterladen. Mein Rechner war auch aus, so dass ich die OPML-Datei nicht erneut erstellen konnte.
Glücklicherweise werden die Feeds von RSSPopper im Profilverzeichnis unter Anwendungsdaten/RSSPopper gespeichert. An mein Server-Profil kam ich leicht heran, kopierte mir dann die Datei feeds.xml und schraubte mir auf die Schnelle ein XPath-Ausdruck, den ich auf der Kommandozeile mit xqilla rsspopper_to_opml.xquery ausführte.

<opml version="1.0">
  <head>
    <title>Feeds</title>
  </head>
  <body>
    <outline text="Feeds">
    {
	let $d := fn:doc("/home/ckl/Desktop/feeds.xml")/feeds
        for $x in $d/feed
            return
		<outline title="{$x/Title}" xmlUrl="{$x/Link}" />
    }
</outline>
</body>
</opml>

Entwickeln mit Scrum/Agilo

Wegen eines privaten Projekts habe ich in den letzten paar Tagen eine kleine Entwicklungsumgebung aufgebaut. Dazu dient mir auf meinem Notebook eine VirtualBox (Ubuntu 10.04, Tomcat, MySQL 5.2, Apache 2, Trac + Agilo, SVN) als Deployment- und Entwicklungsplattform. Die Installation des ganzen Environments erledigte ich recht schnell anhand von http://wiki.ubuntuusers.de/Trac und http://www.agile42.com/cms/pages/download-install/

Nachdem ich mich mit Agilo ein bißchen auseinandersetzte, stellte ich fest, dass das Anlagen von Teams nicht funktionierte, die Fehlermeldung

 An error occurred while getting None from the database: no such table: agilo_sprint

war mehr als eindeutig: bei der Installation von Agilo wurden in meiner Version drei Tabellen schlichtweg nicht erstellt.
Nach kurzer Suche wurde ich fündig und legte mit sqlite3 trac.db die fehlenden Tabellen für die Benutzer manuell an:

CREATE TABLE agilo_team (
  name text,
  description text,
  UNIQUE (name)
);
CREATE TABLE agilo_team_member (
  name text,
  team text,
  description text,
  ts_mon real,
  ts_tue real,
  ts_wed real,
  ts_thu real,
  ts_fri real,
  ts_sat real,
  ts_sun real,
  UNIQUE (name)
);
CREATE TABLE agilo_calendar_entry (
  date integer,
  teammember text,
  hours real,
  UNIQUE (date,teammember)
);

agilo_calendar_entry wurde ebenfalls nicht angelegt, wie ich später feststellte.

Weiterhin stellte ich fest, dass beim Erstellen eines Sprints der Fehler

AttributeError: 'NoneType' object has no attribute 'toordinal'

auftrat. Google sei dank fixte ich das Problem, indem ich bei den Sprint-Daten Start- und Endzeitpunkt manuell eintrug. Anscheinend funktioniert das Feld Duration in days in der Sprint-Administration noch nicht so ganz.

Soweit dazu, eventuell gibt es ja die ein oder andere Person, die ebenfalls über diese beiden Fehler stolpert.

Für mich als Scrum-Neuling – produktiv hatte ich diese Entwicklungsmethode noch nicht eingesetzt – wurde ich beim näheren Betrachten der Optionen von Agilo erst einmal erschlagen. Deshalb folgt hier eine grobe Auflistung der Begrifflichkeiten und Funktionalitäten, wie sie in der Standard-Installation definiert sind.

  • Ticket-Typen
    • Requirement sind Tickets, die auf die Fragen Welches Problem zu lösen ist und warum es zum Problem wird. Requirements sollen SMART (Simple, Measurable, Achievable, Realistic and Traceable) sein. Nachdem ein Requirement angelegt wurde, kann über “Edit” 0..n User Stories zugewiesen werden.
    • User Story ist ein Ticket, das beschreibt was der Benutzer mit dem System erreichen will und warum (Nutzen dieser Funktionalität). Nachdem eine User-Story angelegt ist, kann über “Edit” auf einen neuen Task verwiesen werden. Eine User Story kann 0..n Tasks besitzen.
    • Tasks sind Tickets, die eine Aufgabe, die von einem Team Member zu erledigen ist, detailiert erklärt. Jeder Task soll ausführlich sein und sich auf eine Aufgabe beziehen.
  • Backlog
    • Das Product Backlog beinhaltet die User Stories und darunter jeweils die Requirements, die einer User Story zugeordnet sind.
    • Das Sprint Backlog beinhaltet die Requirements (und die User Story bzw. Tasks die dem Requirement zugewiesen worden sind) und offene Bugs. Es werden nur die Requirements/Tasks angezeigt, die dem Sprint zugewiesen worden sind.
    • Sprint bezeichnet den Zeitraum, in dem mehrere Tasks/Requirements gelöst werden. Im Administrations-Interface müssen jeweils neue Sprints mit Start- und End-Datum angelegt werden.
    • Milestone bezeichnet einen Zeitraum, der wiederum aus mehreren Sprints besteht

Die Frage nach dem “Wie gehe ich nun vor?” ist über oben die dargestellte Struktur eigentlich relativ klar:

  • Anlegen der User Stories (WELCHE Funktionalität wird benötigt um einen Business Value zu erreichen?)
  • Erstellen der Requirements (WELCHE Probleme einer User Story gilt es zu lösen?) und Zuweisen der Requirements an eine User Story
  • Erstellen der zugehörigen Tasks (WAS ist bei einer User Story technisch zu tun?), die einer User Story angehören
  • Erstellen eines Meilensteins. Requirements müssen dem Meilenstein zugewiesen werden
  • Erstellen von ein oder mehreren Sprints. Tasks, User Stories und Bugs müssen den Sprints zugewiesen werden

Eventuell werde ich die nächsten Tage noch den ein oder anderen Blog-Eintrag zu Agilo verfassen. Danke fürs Lesen,

How-To: Module des Apache Webservers unter Windows mit Visual Studio kompilieren und debuggen

Aus aktuellem Anlass musste ich mal wieder ein Apache-Modul gerade biegen. Diesmal war es mod_auth_ldap. mod_auth_ldap sollte als Modul zur Authentifizierung und Autorisierung von LDAP-Benutzern (Active Directory, eDirectory, OpenLDAP etc.) vielen Leuten ein Begriff sein.

Diese Anleitung zeigt in wenigen Schritten, wie man aus den Sourcen des Apache Webserver 2.0.63 ein Modul patcht, kompiliert und debuggt. Voraussetzung für die Kompilierung ist ein Visual Studio Express bzw. Visual C++. Ich verwende auf meinem Rechner ein (relativ altes) Visual Studio 2005 Professional.

Auf meinem Arbeitsrechner schaut es so aus, dass ich unter c:ckldevsrvwebapache2.0.63 ($DIR_BIN) die installierte und kompilierte Version des Apache Webservers habe und unter c:ckldevprojectsappapache2.0.63 ($DIR_SRC) die zugehörigen Sourcen liegen.

Zuerst müssen von apache.org die aktuellen Sourcen für Windows heruntergeladen und auf der Festplatte ($DIR_SRC) entpackt werden. Wenn man zusätzlich noch durch die Sourcen des Apache Webservers debuggen will, werden weiterhin die Symbols benötigt. Diese müssen in das Hauptverzeichnis des kompilierten Apache Webservers ($DIR_BIN) entpackt werden.

Die Datei $DIR_SRCApache.dsw enthält alle Teilprojekte des Webservers und muss mit Visual Studio geöffnet werden. Falls beim Öffnen die Frage nach einer Konvertierung der Daten kommt, kann/muss dies mit Ja beantwortet werden.

Ausgehend davon, dass wir nur mod_auth_ldap patchen wollen, muss nun im Solutions Explorer das Teilprojekt mod_auth_ldap ausgewählt und die jeweiligen Änderungen in die mod_auth_ldap.c eingetragen werden. Mit einem Rechtsklick auf mod_auth_ldap > Build wird nun das Modul erstellt. Die .so-Datei lässt sich jetzt unter $DIR_SRCmodulesexperimental[Debug|Release]mod_auth_ldap.so ($MOD_AL) finden. Weiterhin ist die $DIR_SRCmodulesexperimentalDebugmod_auth_ldap.pdb ($DEBUG_AL) wichtig.

Der Apache muss nun als Dienst beendet werden (net stop apache2), danach muss $MOD_AL und $DEBUG_AL nach $DIR_BINmodules kopiert (vorher Sicherung des Originals erstellen!) und Apache auf der Kommandozeile ($DIR_BINbinapache.exe) gestartet werden. Dies ist nötig, damit Visual Studio sich an den Apache-Prozess hängen kann. Wird der Apache als Dienst ausgeführt, ist dies nicht ohne Weiteres möglich.

Sobald der Webserver läuft, kann im Visual Studio unter Debug > Attach to Process die Apache-Prozesse ausgewählt werden. Beim Hit eines Breakpoints in der mod_auth_ldap.c stoppt der Apache die Ausführung.

Hier die Hinweise im Überblick:

  • $DIR_SRCApache.dsw als Projekt öffnen und nicht $DIR_SRCmodulesexperimentalmod_auth_ldap.dsw, da man bei letzterem zu viele Einstellungen ändern muss.
  • Apache.exe als normalen Prozess und nicht als Dienst starten, da sich sonst der Debugger nicht nutzen lässt.
  • Neben der .so-Datei muss auch die zugehörige .pdb-Datei in $DIR_BINmodules kopiert werden.

Web Application goes Desktop

Heute habe ich bei Golem gelesen, dass Titanium den Appcelerator entwickelt hat. An sich nichts Neues, schließlich werden jeden Tag zu hauf’ neue Applikationen veröffentlicht.
Das Interessante ist, dass ich erst beim Lesen des Artikels die Tragweite von RIAs für die Zukunft erfasst habe.
Kurz zum Appcelerator: Das Framework stellt ein Browser-Umgebung – bisher nur für MacOS X und Windows, Linux folgt später – bereit. Dieses  erlaubt es den Entwicklern, ihre Anwendung mehr oder weniger nativ auf dem Desktop laufen zu lassen. Dabei wird in JavaScript + XHTML entwickelt. Appcelerator bietet einige eigene JavaScript-Namespaces an, die unter anderem das Abspielen von Sounds (MP3, WAV) oder das Speichern von relationalen Daten erlauben.

Appcelerator reiht sich in die Reihe der RIA-Frameworks ein. Silverlight von Microsoft und Flex von Adobe sind sicherlich wesentlich bekannter – haben allerdings den Nachteil, dass sie eben nicht JavaScript und XHTMl für die Entwicklung nutzen. Ich persönlich zähle mittlerweile auch das GWT als RIA-Framwork.

Wann kann aber ein RIA-Framework erfolgreich sein? Meiner Meinung nach ist es wichtig, dass der Entwickler -also ich- sich nicht in eine neue Technologie umständlich einarbeiten muss, sondern stattdessen bestehende Technologien benutzt werden. Eindeutig ein Plus für Appcelerator (JavaScript, CSS + XHTML) und GWT (Java + CSS).

Personen, die bereits mit WPF und XAML entwickelt haben, werden sicherlich Silverlight den Vorzug geben.
Aber nicht nur die Um- oder Eingewöhnung in das neue Environment sind wichtig, sondern auch die Features. Meine Wunschliste sieht folgendermaßen aus:

  • Abspielen von Medien – sowohl Video als auch Audio
  • Zugriff auf das Tray-Icon
  • Speicherung von Benutzerdaten in einer relationalen Datenbank (bspw. SQLite)
  • Asynchrone Verbindungen
  • JSON und XML
  • SOAP inkl. WSDL-Security
  • Netzwerkzugriff auf Layer >= 4 um beispielsweise POP3 oder IMAP zu benutzen, Gameserver anzufragen. Hiermit liessen sich etwa die Spielergebnsse eine Counter-Strike-Matches automatisch in das Blog eintragen
  • Plattformunabhängigkeit (Windows, Windows Mobile, MacOS X, Linux, Symbian)

Für mich besonders wichtig ist die Unterstützung von SOAP/Security. Denn damit können RIAs vernünftig an Service-orientierten Architekturen angebunden werden und Sessions lassen sich darüber realisieren.

Für mich steht eines fest: Im Laufe der nächsten zwei Jahre werden sich RIA-Frameworks vor allem in Business-Anwendungen durchsetzen können. Denn – und das habe ich bei der Xtopia oft genug gehört – : “Die User-Experience ist wichtig – vielleicht sogar wichtiger als die Funktionalität”.