exensio it blog

Teil 2 - Grails in Produktion – mit Apache, Tomcat und MySQL

2012-03-04T16:31:00.000+01:00

Im zweiten Teil meiner Blog-Serie (hier geht es zum ersten Teil) möchte ich auf die Konfiguration des Apache Moduls mod_jk innerhalb des Apache Web-Servers eingehen. Hierzu muss die Datei httpd.conf angepasst und eine Datei worker.properties erstellt (die Konfiguration der Ports beschreibe ich dann im Tomcat-Teil meiner Blog-Serie) werden. Des Weiteren werden ich noch kurz die JKStatus Konsole vorstellen.

Einstellungen in der Datei httpd.conf:
Im Listing unten sieht man die Standard-Einstellungen, diese können und sollten dann in jedem Projekt modifiziert bzw. erweitert werden. Folgendes ist anzumerken :

Bis Zeile 9 - stehen die globalen Einstellungen, wie Lokation des Logfiles, der worker.properties, etc.
Ab Zeile 43 - stehen dann die Einstellungen innerhalb des Virtual-Host Abschnitts. In einer Produktions-Umgebung sollte man dann noch entscheiden, ob die JKStatus-Konsole benutzt werden soll (Zeile 50).

LoadModule jk_module /usr/lib/apache2/modules/mod_jk.so
LoadModule rewrite_module /usr/lib/apache2/modules/mod_rewrite.so
JkWorkersFile /etc/apache2/worker.properties 
# Where to put jk logs 
JkLogFile /var/log/apache2/mod_jk.log 
# Set the jk log level [debug/error/info] 
JkLogLevel info 
# Select the log format 
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] " 



 ServerAdmin webmaster@localhost

 DocumentRoot /var/www
 
  Options FollowSymLinks
  AllowOverride None
 
 
  Options Indexes FollowSymLinks MultiViews
  AllowOverride None
  Order allow,deny
  allow from all
 

 ErrorLog /var/log/apache2/error.log

 # Possible values include: debug, info, notice, warn, error, crit,
 # alert, emerg.
 LogLevel warn

 CustomLog /var/log/apache2/access.log combined

    Alias /doc/ "/usr/share/doc/"
    
        Options Indexes MultiViews FollowSymLinks
        AllowOverride None
        Order deny,allow
        Deny from all
        Allow from 127.0.0.0/255.0.0.0 ::1/128
    
 # JkOptions indicate to send SSL KEY SIZE, 
 JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories 
 # JkRequestLogFormat set the request format 
 JkRequestLogFormat "%w %V %T" 
 # Send all MyWebApp requests to Tomcat
 JkMount /MyWebApp/* loadbalancer
 # Send JKStatus Console
 JkMount /jkstatus/ status

 RewriteEngine On
 RewriteRule ^/$ /MyWebApp/ [PT,L]

Einstellungen in der Datei worker.properties (/etc/apache2):
Diese finden sich im Listing unten. Diese worker.properties führt ein Load-Balancing der Http-Requests auf 4 Tomcat-Server durch (mit einem Apache-WS davor). Sollen die 4 Tomcats die Requests von 2 Apache-WS-Servern erhalten, so bräuchte man 2 worker.properties. Ich würde dann jedoch weiterhin die Namen der Server global durchnummerieren, sprich svr1..svr4 und nicht svr1/svr2 für den ersten Apache-WS und erneut svr1/svr2 für den zweiten Apache-WS, da der Servername an die JSESSIONID angehängt wird und man somit einfacher herausfinden kann, an welchen Server der HttpRequest ging, um dann beispielsweise schneller das zugehörige Logfile zu finden. Zeile 29 ist noch erwähnenswert: Das Modul mod_jk geht standardmäßig von max. 3 Servern aus, auf die die Last verteilt werden soll. Aus diesem Grund ist hier der Wert auf 4 angepasst worden.

worker.list=svr1,svr2,svr3,svr4,loadbalancer,status
worker.svr1.type=ajp13
worker.svr1.host=xx.xx.xx.xx
worker.svr1.port=9008
worker.svr1.lbfactor=1
worker.svr1.socket_keepalive=1
worker.svr1.socket_timeout=300
worker.svr2.type=ajp13
worker.svr2.host=xx.xx.xx.xx
worker.svr2.port=9009
worker.svr2.lbfactor=1
worker.svr2.socket_keepalive=1
worker.svr2.socket_timeout=300
worker.svr3.type=ajp13
worker.svr3.host=xx.xx.xx.xx
worker.svr3.port=9008
worker.svr3.lbfactor=1
worker.svr3.socket_keepalive=1
worker.svr3.socket_timeout=300
worker.svr4.type=ajp13
worker.svr4.host=xx.xx.xx.xx
worker.svr4.port=9009
worker.svr4.lbfactor=1
worker.svr4.socket_keepalive=1
worker.svr4.socket_timeout=300
worker.loadbalancer.type=lb
worker.loadbalancer.sticky_session=1
# Adjust to the number of workers (4 in our case)
worker.retries=4
worker.loadbalancer.balance_workers=svr1,svr2,svr3,svr4
worker.status.type=status

JKStatus-Konsole:

Diese ist im Bild rechts zu sehen. Meines Erachtens ist diese Konsole während der Lasttests ein sehr nützliches Hilfsmittel. In Produktion sollte dann jedoch eher Nagios benutzt werden. Man sieht in der Konsole beispielsweise sehr schön, ob sich die Last gleichmäßig auf alle Tomcat-Server verteilt. Auch bekommt man sehr schnell mit, wenn ein Tomcat Probleme hat. Hierbei sind folgende Angaben (rote Umrandung im Bild rechts) von besonderem Interesse:

Busy (Current number of busy connections)
Max (Maximum number of busy connections).

Bei hohen Werten hat der Tomcat Probleme, meistens hängen dann Tomcat-Threads, beispielsweise verursacht durch eine überlastete Datenbank.

Teil 1 - Grails in Produktion – mit Apache, Tomcat und MySQL

2012-02-13T09:19:00.000+01:00

Mit diesem Blog-Post möchte ich die Schritte, die nötig sind, um eine Grails Applikation produktiv zu stellen, beschreiben. Dieses Thema werde ich in aufeinanderfolgende Blog-Posts aufteilen. Die Aufteilung sieht folgendermaßen aus:

Teil 1 – Allgemeines zur Systemarchitektur und Ergänzungen in Grails
Teil 2 – Apache Web Server
Teil 3 – Tomcat
Teil 4 – MySQL
Teil 5 – Load Tests

Systemarchitektur
Das Bild rechts beschreibt die gewählte Systemarchitektur. Diese besteht aus folgenden Komponenten:

Load-Balancer – dieser kann sowohl auf Soft-, wie auch auf Hardware basieren. Meistens wird hier Hardware favorisiert. Wichtig ist, dass der Load-Balancer „Sticky Sessions“ unterstützt, sprich einen User-Request immer wieder an den ursprünglichen Apache WS weiterleitet.
Apache Web Server – hier benutzen wir mod_jk zur Kommunikation zwischen Apache WS und Tomcat. Gründe hierfür sind: sehr ausgereift und wir benutzen meistens keine SSL Verschlüsselung zwischen Apache WS und Tomcat. Falls SSL notwendig ist, sollte eher mod_proxy_http benutzt werden [1].
Tomcat – hier ist wichtig zu erwähnen, dass wir nur ein Load-Balancing für die Requests durchführen, also kein Cluster mit Session Replication. Dies reicht in den meisten Fällen vollkommen aus. Nachteilig hierbei ist, dass ein User sich erneut anmelden muss, falls eine Tomcat-Instanz abstürzt. Als Nachteile für ein Cluster können folgende Punkte aufgeführt werden:
- Performanz – jede Session wird auf einen Backup-Server (in-memory) über das Netzwerk repliziert. Bei sehr vielen Sessions (und vielen Tomcat-Instanzen im Cluster) kann dies eine sehr hohe Netzwerklast verursachen. Die Sessions können auch in einer Datenbank persistiert werden. Dies ist jedoch nicht performanter.
- Bei der Entwicklung muss beispielsweise beachtet werden, dass alle Objekte in der HTTP-Session serialisierbar sind. Auch darf die http-Session nicht zu groß sein (max. 50 – 70 KByte). Des Weiteren darf beispielsweise keine Hibernate-Session in einem HTTP-Objekt gespeichert werden. Obwohl wir wissen, dass dies Anfängerfehler sind, treten diese Fälle trotzdem sehr oft auf. Insbesondere in hektischen Projektphasen. Dies bedeutet schließlich, dass ein Cluster höhere Aufwände verursacht.
MySQL – wir verwenden auch sehr gerne PostgreSQL. Jedoch ist MySQL bei den Hosting Providern unserer Kunden öfters vertreten. Deshalb wird hier auf MySQL eingegangen. Wichtig ist hier, sich über einen Fail-Over-Szenario im klaren zu sein. Es gibt mehrere Möglichkeiten, beispielsweise Linux-Cluster, VM-Ware-Cluster, Sequoia, etc. Die Hosting-Provider unserer Kunden setzen hier meistens ein Linux-Cluster ein.

Ergänzungen in Grails
Folgende Ergänzungen sollten meines Erachtens in Grails hinzugefügt werden:

GSP-Seite mit folgenden Informationen:
- Information über die für den Build des WAR-Files benutzte Revision-Nummer des Sourcecode-Systems (Subversion in meinem Fall).
- Ausgabe von allen Cookies. Hier ist insbesondere die JSESSIONID von Interesse, da mod_jk den in der workers.properties gewählten Servernamen an die JSESSIONID anhängt.
Konfiguration des Connection-Pools im Tomcat. Dieser wird dann als JNDI Connection-Pool in der Grails-Applikation benutzt. Dies hat den Vorteil, dass eine neue Datenbank mit anderen Settings, ohne ein erneutes Kompilieren der Grails-Applikation, benutzt werden kann.
Ausgabe der Logfiles in ${CATALINA_HOME}/logs. Nun könnte jemand auf die Idee kommen, dies über einen JNDI Eintrag steuern zu wollen, wie in meinem Blog [3] beschrieben. Hierbei ist jedoch das Problem, dass die Config.groovy vor der resources.groovy (die den Zugriff auf JNDI durchführt) aufgerufen wird.

Revision aus Subversion während Grails War-File Build ermitteln
Der Code unten basiert auf einem Code-Snippet von StackOverflow [2]. Ich habe diesen modifiziert (Zeile 32), so dass die Revision-Nummer angezeigt wird. Dieser Code muss der Datei _Events.groovy hinzugefügt werden.

import org.tmatesoft.svn.core.SVNException
import org.tmatesoft.svn.core.wc.SVNRevision
import org.tmatesoft.svn.core.wc.SVNInfo
import org.tmatesoft.svn.core.wc.SVNWCClient
import org.tmatesoft.svn.core.wc.SVNClientManager
import org.tmatesoft.svn.core.internal.io.fs.FSRepositoryFactory
import org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryFactoryImpl
import org.tmatesoft.svn.core.internal.io.dav.DAVRepositoryFactory

// Create revision info in case of a WAR build
eventWarStart = { type ->

    println "******************* eventWarStart *****************"
    try {
        // initialise SVNKit
        DAVRepositoryFactory.setup();
        SVNRepositoryFactoryImpl.setup();
        FSRepositoryFactory.setup();

        SVNClientManager clientManager = SVNClientManager.newInstance();
        println "clientManager = " + clientManager.toString();
        SVNWCClient wcClient = clientManager.getWCClient();
        println "wcClient = " + wcClient.toString();

        // the svnkit equivalent of "svn info"
        File baseFile = new File(basedir);

        println "baseFile = " + baseFile.toString();
        SVNInfo svninfo = wcClient.doInfo(baseFile, SVNRevision.WORKING);
        println "svninfo = " + svninfo.toString();

        def version = svninfo.revision.number as String
        println "Setting Version to: ${version}"
        metadata.'app.version' = "${version}".toString()
        metadata.persist()

    }
    catch (SVNException ex) {
        //something went wrong
        println "**************** SVN exception **************"
        println ex.getMessage();
    }

} // End eventWarStart()

Während des Builds wird die Revisions-Nummer in der Datei application.properties (siehe unten Zeile 6) geändert.


#Grails Metadata file
#Sat Jan 21 16:17:44 CET 2012
app.grails.version=1.3.7
app.name=MyGrailsProject
app.servlet.version=2.4
app.version=455
plugins.aop-reloading-fix=0.1
plugins.batch-launcher=0.5.6
plugins.csv=0.3.1
plugins.fixtures=1.1
plugins.hibernate=1.3.7
plugins.jquery=1.7.1
plugins.jquery-ui=1.8.15
plugins.mail=1.0-SNAPSHOT
plugins.resources=1.0.2
plugins.spring-security-core=1.2.4
plugins.tomcat=1.3.7

In der BuildConfig.groovy muss dann noch überprüft werden, ob das War-File nicht die Revisionsnummer angehängt bekommen hat. Sonst hätte der Name des War-Files folgenden Aufbau : MyProject-455.war, mit dem Nachteil, dass sich jedes Mal die Url der Grails-Applikation ändern würde.

grails.project.class.dir = "target/classes"
grails.project.test.class.dir = "target/test-classes"
grails.project.test.reports.dir = "target/test-reports"
grails.project.war.file = "target/${appName}.war"
grails.project.dependency.resolution = {
...

Das Ganze kann in einer GSP-Seite (inkl. Ausgabe der Cookies) folgendermaßen dargestellt werden:

<%--
  Created by IntelliJ IDEA.
  User: Peter Soth
  Date: 11.01.12
  Time: 11:49
  To change this template use File | Settings | File Templates.
--%>
<html>
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
    <meta name="layout" content="main"/>
    <title>Info:</title>
</head>

<body>






The following revision has been used for the build of this WAR.

REV: ${grailsApplication.metadata.'app.version'}






Show all cookies


    NAME: ${cookie.name} VALUE: ${cookie.value}

</body>
</html>

Tomcat JDBC Connection-Pool mittels JNDI einbinden
Hierzu wird in DataSource.groovy folgendes eingetragen:

// environment specific settings
environments {
    production {
        dataSource {
            jndiName        = "java:comp/env/jdbc/production"
            dialect         = org.hibernate.dialect.MySQL5InnoDBDialect
            dbCreate        = 'update'
        }
    }
...

Im Blog-Post zum Tomcat zeige ich dann, wie dies im Tomcat konfiguriert wird.

Logging in CATALINA_HOME festlegen
Mit folgendem Code-Snippet werden die Logs-Files der Grails-Applikation in das Log-Verzeichnis des Tomcat-Servers geschrieben.Hierzu muss die Variable logDirectory in der log4j-Konfiguration in Config.groovy benutzt werden.

// request parameters to mask when logging exceptions
grails.exceptionresolver.params.exclude = ['password']

// set per-environment serverURL stem for creating absolute links
environments {
 ...
    production {
        grails.serverURL = "http://www.changeme.com"
        //tomcat based logging
        def catalinaHome = System.getenv('CATALINA_HOME')
        if (!catalinaHome) catalinaHome = '.'   // falls nicht gesetzt
        def String grailsLogDir = "${catalinaHome}/logs/"
        ...
    }
}

[1] Tomcat Expert Blog
[2] StackOverflow: SVN Revisionsnummer in Grails einbinden
[3] Grails : JNDI Werte im Embedded Tomcat setzen

Grails 2.0 Upgrade Guide

2012-02-06T09:54:00.001+01:00

Auf Google+ [1] hat das Grails-Team die Grails Community über Ihre Erfahrungen bei der Migration auf Grails 2.0 befragt. Um es kurz zu machen: Bei kleinen Applikationen ist eine Migration sehr einfach, bei großen Applikationen gibt es jedoch Probleme. Vor allem bei der Migration von Tests gibt es Probleme. Laut Grails Team soll man auf Grails 2.0.1 [2] warten, sofern man die Tests auch migrieren möchte. Dies dürfte bei den meisten Projekten – wie auch bei uns - der Fall sein. Und hier geht es zum Upgrade Guide von Peter Ledbrook [3].

[1] https://plus.google.com/117411438136918964913/posts/axyCZk1P5L5
[2] https://plus.google.com/117411438136918964913/posts/TFw4YvNfQXX
[3] http://pledbrook.github.com/grails-howtos/en/upgradeToGrails2.html

Recruiting 2.0 – exensio auf Youtube - IT Berater (w/m) mit hohem *PZU-Faktor gesucht

2012-02-05T18:05:00.001+01:00

Unter Recruiting 2.0 versteht man die Benutzung von Web 2.0 Diensten, wie Xing, Facebook, Twitter, Google+ und Youtube zur Mitarbeitergewinnung. Bisher sind wir bei exensio auch den klassischen Weg mit Anzeigen in Jobbörsen gegangen. Vor allem für kleinere Unternehmen hat dies jedoch den Nachteil, dass Stellen- ausschreibungen leider in der Masse untergehen.

Warum neue Kollegen über einen Youtube Kanal suchen?

Uns wurde schnell klar, dass wir einen anderen Weg versuchen mussten und als Software-Ingenieure auch professionelle Unterstützung hierfür benötigen würden. Mit dem Kommunikationsdesigner Michael Starzmann von gadget Strategie + Design [1][2] hatten wir endlich den Richtigen gefunden, der sich voll und ganz auf unserer Wellenlänge befindet. gadget zeichnet meiner Meinung nach vor allem durch tragfähige sowie angemessene Lösungen aus, denn wir hatten kein Budget für ein ganzes Filmteam etc. Weitere Infos finden sich auf dem gadget Blog [3]

Fazit
Um es gleich vorweg zu nehmen: Mit dem Hochladen eines Videos auf Youtube steigen nicht über Nacht die Zahl der Bewerbungen an. Unsere Intension war hierbei eine andere: Wir sehen das Youtube Video mehr als Möglichkeit, uns unseren potentiellen neuen Mitarbeitern in 30 Sekunden vorzustellen und vielleicht etwas mehr von der exensio „Idee“ rüberzubringen, als dies mit einer statischen Web-Seite oder einer PDF-Datei möglich ist. Das sehr positive Feedback, das wir bisher erhalten haben, zeigt uns, dass es der richtige Weg ist - wir würden es auf jeden Fall wieder machen. Des Weiteren ist zu erwähnen, dass das Video länger für uns arbeitet, als eine Anzeige auf einem Jobportal.

[1] http://www.gadget.de
[2] http://blog.gadget.de
[3] http://blog.gadget.de/?p=163

Vermeiden von ClassCastExceptions beim Reloading in Grails-Applikationen

2012-02-02T18:48:00.000+01:00

Problem

Einer der Hauptvorteile von Grails gegenüber anderen Frameworks bzw. Sprachen ist die schnelle Entwicklung. Bei laufendem Server können Änderungen vorgenommen und diese sind ohne einen lang dauernden Publizierungsvorgang verfügbar.
Unter bestimmten Umständen funktioniert allerdings der Reload von Änderungen in Controllern oder Services nicht bei laufendem Server. Nimmt man eine Änderung vor und lädt anschließend über den Browser die Seite neu, dann resultiert dies in eine ClassCast-Exception, die nur durch einen Server-Neustart zu beheben ist. Das Problem tritt unseren Beobachtungen zufolge insbesondere im Zusammenhang mit dem Spring-Cache-Plugin auf, das Annotation verwendet. Auch bei anderen Annotationstypen ist das Problem schon aufgetaucht und bekannt [1]

Lösung

Ab der Grails-Version 2.0 ist dieses Problem behoben. Für andere Grails-Versionen lässt sich das Problem durch Installation des „AOP Reloading Fix“ Plugins [2] beheben. Dies funktioniert standardmäßig allerdings nur für die Umgebung (Environment) Development.
Wird eine eigene Umgebung für die Entwicklung eingerichtet, z.B. zum Umsetzen von Batches, dann werden die Erweiterungen des Plugins nicht angezogen. Durch Setzen der Variable grails.reload.enabled beim Starten der Anwendung kann dies umgangen werden und das Plugin wird angezogen.Die folgende Abbildung zeigt in IntelliJ den Befehl zum Starten der Umgebung devbatch. Zusätzlich werden die beiden Variablen grails.reload.enabled=true und grails.reload.location=. übergeben.

Links

[1] http://jira.grails.org/browse/GRAILS-6370
[2] AOP Reloading Fix Plugin

Grails : JNDI Werte im Embedded Tomcat setzen

2012-01-30T19:39:00.000+01:00

JNDI eignet sich sehr gut, um einer Web-Applikation von außen (über den Tomcat) Parameter zur Verfügung zu stellen. Die JNDI Einstellungen werden in Tomcat in der context.xml vorgenommen. Entwickelt man in Grails (beispielsweise mit IntelliJ), so läuft der Tomcat jedoch im Embedded Mode. Dies bedeutet, dass keine context.xml vorhanden ist, die editierbar wäre.In den folgenden Code-Beispielen möchte ich zeigen, wie ein JNDI Wert ausgelesen und im Embedded Tomcat gesetzt werden kann. Dies ist beispielsweise zum Testen sehr nützlich.

So würde das Setzen eines JNDI Parameters in der Context.xml (auf dem Produktionsserver) aussehen:


  ...
  
  ...

In der Grails Test-Umgebung werden dann in der Datei _Events.groovy die JNDI Werte gesetzt. Hier muss beachtet werden, dass MyWebAppName durch den richtigen Namen der Web Applikation ersetzt wird. In dem Beispiel unten ist es nicht nötig, das Grails Tomcat Plugin zu modifizieren, wie es in den Grails Mailing-Listen diskutiert wurde:

eventConfigureTomcat = {tomcat ->
    println "### Start Tomcat configuration"

    try {
        def environment = tomcat.class.classLoader.loadClass('org.apache.catalina.deploy.ContextEnvironment').newInstance()
    
        environment.name = 'jnditest'
        environment.type = 'java.lang.String'
        environment.value = 'Grails JNDI Test String'
        environment.override = Boolean.TRUE
    
        def context = tomcat.host.findChild('/MyWebAppName')
        context.namingResources.addEnvironment environment
    }
    catch (Exception e)
    {
        e.printStackTrace()
    }
    println "### End Tomcat configuration"
}

Auslesen in der resources.groovy. So funktioniert es sowohl in der Test- als auch in der Produktions-Umgebung. In dem Beispiel unten wird jedoch überprüft, ob Grails im Entwicklungsmodus läuft:

import org.springframework.web.servlet.i18n.SessionLocaleResolver

// Place your Spring DSL code here
beans = {
    localeResolver(SessionLocaleResolver) {       
        Locale.setDefault(Locale.GERMAN)
    }
    
    if (grails.util.GrailsUtil.environment.equals('development')) {
        jnditest(org.springframework.jndi.JndiObjectFactoryBean) {
            jndiName = 'java:/comp/env/jnditest'
        }
    }
}

Links:
[1] http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Environment Entries

Langsame Netzwerk-Geschwindigkeit mittels Apache-Webserver simulieren

2012-01-12T15:56:00.007+01:00

Einleitung

Im Bereich der Web-Entwicklung gibt es viele unterschiedliche Szenarien, die zu testen sind, bevor eine Änderung "live" gehen kann. Neben den typischen Kompatibilität-Tests auf Betriebssystem, Browser und Bildschirmauflösung ist auch die Netzwerk-Geschwindigkeit eine Komponente, der Beachtung geschenkt werden sollte.
Insbesondere wenn Ressourcen nachgeladen werden müssen, ist es wichtig zu testen, wie die Web-Applikation bei verschiedenen Übertragungsgeschwindigkeiten reagiert.

In einem aktuellen Projekt haben wir eine Flash/AS3-Applikation getestet, die JSON-Daten per asynchronem Request vom Server erhält und daraufhin externe Bilddateien in die Applikation nachlädt. In erster Linie musste also sichergestellt werden, dass die Applikation auch bei langsamer Übertragungsrate und gleichzeitig hoher Anzahl nachzuladender Bilder intuitiv zu bedienen bleibt (sprich: Einführung von Ladebalken, Deaktivierung von bestimmten Elementen, etc.).

Das Tool "Throttle"

Während es für den Apache Webserver mittlerweile auch Module gibt, die das "throttling" übernehmen können sollen, gibt es damit relativ schnell Kompatibilitätsprobleme zwischen den unterschiedlichen Webserver Versionen.
Als zuverlässig hat sich das kleine auf Pipe-Basis [1] operierende Tool Throttle [2] herausgestellt. Unter Linux erfolgt die Installation einfach mit dem gewohnten Dreisatz "./configure && make && make install".

Apache Webserver und Throttle

Pipe-Tools lassen sich auf einfache Weise in den Apache Webserver einbinden (Stichwort SetOutputFilter [3]). Im Folgenden ist die Beispiel-Konfiguration für ein Bandbreiten-Limit von 56K angegeben:


# 56KB/s filter definition
ExtFilterDefine ksec56 mode=output cmd="/usr/local/bin/throttle 57344" preservescontentlength 
# Use filter (e.g. in Location or VirtualHost directive)
SetOutputFilter ksec56

Der Filter kann beispielsweise innerhalb einer belieben Location- or VirtualHost-Anweisung verwendet werden.

Fazit

Mittels Throttle und dem Apache Webserver können auch verschiedene Übertragungsgeschwindigkeiten einfach in die Tests bei der Web-Entwicklung einbezogen werden. Mithilfe der Location- oder VirtualHost-Anweisung kann die Beschränkung nur für einzelne Verzeichnisse aktiviert werden - perfekt um langsame externe Server zu simulieren.

Links

[1] Pipe auf Wikipedia
[2] Website zu Throttle
[3] Dokumentation zu SetOutputFilter

exensio wünscht ein frohes Fest und ein erfolgreiches neues Jahr

2011-12-22T17:50:00.000+01:00

Unsere besten Wünsche

für ein frohes Weihnachtsfest

und ein glückliches, erfolgreiches neues Jahr.

Auch in diesem Jahr verwenden wir den von

uns für Weihnachtsgeschenke vorgesehenen Betrag zu Gunsten einer Spende an die

Marc Soth Stiftung in der Trägerschaft der SOS Kinderdorf Stiftung.

Criteria List Queries bei Many-To-Many Beziehungen in Grails

2011-12-22T14:52:00.011+01:00

Einleitung

In diesem Beitrag wird gezeigt, wie n:m Beziehungen in Grails (Stichwort 'hasMany') innerhalb einer Query abgefragt werden können.
Als Beispiel betrachten wir die Beziehung zwischen einer Person und eines Projekts. Eine Person kann in mehreren Projekten involviert sein. In einem Projekt arbeiten wiederum mehrere Personen. Die Modellierung in Domain-Klassen könnte wie folgt (vereinfacht) aussehen

class Person {
String firstname
String lastname
static hasMany = [projects:Project]
}

class Project {
String name
static hasMany = [persons:Person]
}

Datenbank-Abfragen

Im Folgenden sollen zwei Abfragen betrachtet werden:

Liefere alle Personen, deren Vorname "Max" oder "Moritz" ist.
Liefere alle Projekte, bei welchen Personen mit Vorname "Max" oder "Moritz" beteiligt sind.

Die erste Abfrage kann einfach mit dem dynamischen Finder findAllBy*InList [1] in Grails realisiert werden.

def firstnames = ["Max", "Moritz"]
def result = Person.findAllByFirstnameInList(firstnames)

Die zweite Abfrage kann nicht mehr über einen dynamischen Finder abgehandelt werden. Hierfür verwenden wir ein Criteria [2]. Criteria-Abfragen sind eine geschickte Möglichkeit, um komplexe Queries in Grails-Syntax relativ übersichtlich zu schreiben. Die zweite Abfrage lässt sich wie folgt realisieren:

def firstnames = ["Max", "Moritz"]
def c = Project.createCriteria()
def result = c.list() {
persons {
    inList("firstname", firstnames)
}
resultTransformer Criteria.DISTINCT_ROOT_ENTITY
}

Innerhalb der list-Closure des Criterias kann auf die einzelnen Attribute der Domain-Klasse zugegriffen werden - im Beispiel greifen wir auf die Assoziation "persons" zu. Mit der nächsten Closure wird sichergestellt, dass nur jene Personen zurückgeliefert werden, deren Vorname in der angegebenen Liste enthalten ist.

Sowohl der findAllBy-Finder als auch das list-Criteria akzeptieren die typischen Parameter wie max, offset, sort oder order, die vor allem bei Web-Applikationen für tabellarische Darstellungen unumgänglich sind.

Links

[1] findAllBy in der Grails-Dokumentation
[2] createCriteria in der Grails-Dokumentation

Datenbank-Migrationen mit Grails

2011-11-22T22:32:00.000+01:00

Problemstellung
Wird für eine Applikation, die darunterliegende Datenbank ausgetauscht, dann sind im Idealfall keine Änderungen im Anwendungscode notwendig.Dies sollte zumindest gelten wenn die Applikation Standard-SQL einsetzt.Unabhängig davon müssen aber die Daten von der ursprünglichen Datenbank in die Zieldatenbank überspielt werden.Für eine Grails-Applikation standen wir genau vor dieser Herausforderung, wobei von einer MySQL-Datenbank auf eine PostgreSQL-Datenbank migriert wurde.

Hierfür gibt es nun mehrere Möglichkeiten. Relativ einfach erscheint das Durchführen eines Datenbank-Exports, anschließendes modifizieren der Daten und abschließendes Importieren in PostgreSQL. Leider hat bei keinem der verfügbaren Tools zur Modifizierung (siehe [1]) der Import funktioniert, d.h. die Daten konnten nicht korrekt für PostgreSQL modifiziert werden. Des Weiteren gibt es kommerzielle Tools wie bspw. easyfrom, die über eine entsprechende Oberfläche die Migration von der Quell- zur Zieldatenbank ermöglichen. Eine weitere Möglichkeit ist die Verwendung eines Grails-Plugins wie beispielsweise DB Stuff [2]. Mit dem Plugin können Daten aus einer DB in XML abgespeichert werden und von XML wiederum in eine Datenbank eingelesen werden.

In unserem Fall traten Probleme bezüglich der unterschiedlichen Datentypen zwischen MySql und PostgreSQL auf. Außerdem ist das Handling von DB-Relationen mit dieser Art von Plugins eher schwierig bzw. nicht möglich. Aufgrund der Historie hatten wir auch einige Spalten im Originalschema, für die es kein Mapping mehr in den Grails-Domain-Klassen gab. Sie waren also unbenutzt und sollten möglichst automatisiert entfernt werden.
Der Entschluss fiel schließlich zur Erstellung einer eigenen kleinen Migrationssuite.

Migrationsidee
Die Idee zur Durchführung ist relativ einfach. Über Grails Domain-Klassen werden die Daten aus der alten DB ausgelesen und anschließend werden die Inhalte der Domain-Objekte direkt in die neue Datenbank gespeichert.
Folgende Punkte sind hierbei zu beachten und müssen gelöst werden:

Zugriff auf zwei Datenbanken in einer Grails-Applikation
Transaktionen: Abhängig von der Datenmenge ist ein entsprechendes Transaktionshandling notwendig
Definition von fachlichen Schlüsseln, um Relationen in der Ziel-Datenbank wieder zu erstellen

Migrationsdurchführung
Für den Zugriff auf zwei Datenbanken wurde das Datasources Plugin [3] eingesetzt. Die Standard-Konfiguration für Datenbanken in der Datei DataSource.groovy zeigte auf die alte DB und war wie bisher mit allen bestehenden Domain-Klassen verknüpft.
Die bestehenden Domain-Klassen wurden alle in ein neues Package kopiert und über das Datasources Plugin mit der neuen DB verknüpft. Hierfür können, wie nachfolgend dargestellt, in der Konfigurations-Datei des Plugins die zu verknüpfenden Domain-Klassen angegeben werden. Des Weiteren kann auch angegeben werden welche Services per Default auf die konfigurierte Data-Quelle zugreifen.

datasources = {
 datasource(name: 'dsPostgresMigration') {
  domainClasses([com.exensio.timesheet.migrate.RenderReportLevel,...])
  readOnly(false)
  pooled(true)
  dialect(org.hibernate.dialect.PostgreSQLDialect)
  driverClassName('org.postgresql.Driver')
  url('jdbc:postgresql://192.168.11.211:5432/extime')
  username('...')
  password('...')
  dbCreate('update') 
  pooled(true)
  services(['migration'])
 }
}

Für die eigentliche Migration ist der MigrationService zuständig. Der Service enthält für jedes zu migrierende Domain-Klassen-Geflecht eine Methode. Im einfachsten Fall führt eine Methode die Migration für genau eine Domain-Klasse und damit Datenbanktabelle durch. Das nachfolgende Code-Fragmentzeigt wie im ersten Schritt alle zu migrierenden Domain-Objekte ausgelesen werden. Anschließend wird über diese iteriert und bei jedem Schleifendurchlauf alle Attribute bis auf die technische ID vom alten Domain-Objekt in ein neu erstelltes Domain-Objekt kopiert und gespeichert.

def migrateRenderReportLevel() {
 def renderReportLevels = com.exensio.timesheet.RenderReportLevel.list()
 def domainClass = new DefaultGrailsDomainClass(RenderReportLevel.class)

 renderReportLevels.each {oldDomainObject ->
  def newDomainMap = [:]
  domainClass.persistentProperties.each { property ->
   newDomainMap[property.name] = oldDomainObject[property.name]
  }
  RenderReportLevel newDomainObject = new RenderReportLevel(newDomainMap)
  newDomainObject.save(flush: true)
  if (newDomainObject.hasErrors()) {
   handleErrors(newDomainObject)
  }
  else {
   log.info "${newDomainObject.class.simpleName} ${oldDomainObject.id} migrated"
  }
 }
}

Durch die Nutzung eines Service und die Aufspaltung in mehrere Methoden kann der Ablauf der Migration einfach in mehrere Transaktionen eingeteilt werden. Die Hauptschwierigkeit bei der Migration ist die Auflösung der Beziehungen. In vielen Fällen kann die Migration über mehrere Objekte in einer Methode direkt erfolgen.Allerdings gibt es auch Domain-Klassen, die von mehreren anderen referenziert werden. Hier ist darauf zu achten, dass die Migration nur einmal erfolgt und die Beziehungen anschließend über fachliche Schlüssel erstellt werden.
In unserem Fall gibt es die beiden Domain-Klassen User und Role, die in einer Methode migriert wurden. Die Klasse User wird auch von der Klasse Project referenziert, die wiederum in einer separaten Methode migriert wurde. Diese Migration-Methode sucht sich über den eindeutigen Login-Namen den entsprechenden User aus der Tabelle und setzt die Beziehung.

Employee existing = Employee.findByUsername(oldDomainObject.projectManager.username)
if (existing) {
 newDomainObject.projectManager = existing
}

Zusammenfassung
Das vorgestellte Verfahren für eine Datenbankmigration erfordert zwar etwas Programmierarbeit, ist aber dank Grails in kurzer Zeit umzusetzen. Es bietet sich insbesondere an wenn bei der Migration Sonderfälle zu beachten sind, wie bspw. das Entfernen nicht mehr benötigter Spalten.

Links
[1] Converting from other Databases to PostgreSQL
[2] DB Stuff Plugin
[3] Datasources Plugin

Verbesserung der Usability mittels Faceted Search

2011-11-20T17:16:00.001+01:00

Die Idee der Faceted Search basiert auf der Facettenklassifikation [1][2]. Diese wurde 1933 von dem indischen Mathematiker und Bibliothekar S. R. Ranganathan [3] entwickelt, um die Bestände der Universitätsbibliothek von Madras zu katalogisieren. Bei der Facettenklassifikation werden Objekte des Wissensbereichs nicht in eine starre Baumstruktur eingegliedert, sondern durch mehrere voneinander unabhängige Gesichtspunkte definiert. In folgendem Blogeintrag möchte ich kurz beschreiben, wie User mittels Faceted Search schneller und präziser Informationen finden können und somit die Usability von (Web-) Applikationen gesteigert werden kann.

Anwendungsbeispiele
Die Faceted Search ist heute vor allem bei Online Shops anzutreffen. Als prominentestes Beispiel kann hier Amazon genannt werden. Die Faceted Search setzt sich jedoch auch immer mehr bei der Verwaltung und späteren Suche von Informationen, wie Dokumenten oder Emails durch. Als Beispiel kann hier Google Mail betrachtet werden. Im Vergleich zu Outlook werden Mails nicht hierarchisch abgelegt, sondern mit Label versehen. Label sind auch unter dem Begriff Tag bekannt. Eine Hierarchie lässt sich beispielsweise unter Benutzung von Pfadnamen realisieren, wie es auch bei Google Mail gemacht wird.

Vorteile
Beim Ablegen von Dokumenten trifft man oft auf die Problematik, dass ein Dokument eigentlich in mehreren Knoten einer Baumstruktur abgelegt werden soll. Dies ist bei einer starren Baumstruktur nicht möglich (Google Mail versus Outlook). Bei der Faceted Search werden die Dokumente mit Tags versehen (verschlagwortet) und können später in verschiedenen Knoten angezeigt (gefiltert)werden. Ein Nebeneffekt der Verschlagwortung ist, dass die Dokumente eindeutig klassifiziert werden. Dies hat den großen Vorteil – im Vergleich zu einer Volltextsuche, dass Informationen präziser und schneller gefunden werden können. Bei einer Volltextsuche wird für die Dokumente beim Indizieren ein Wortvektor ermittelt. In der Suchergebnismenge wird dann die Relevanz eines Suchbegriffs über den Wortvektor ermittelt. Das Problem hierbei ist, dass die Relevanz nur eine Annäherung darstellt. Der semantische Bezug zum eigentlichen Suchwort ist meist nicht gegeben. So erreicht beispielsweise Google erst unter Einbeziehung von Wikipedia bessere Suchergebnisse.

Voraussetzung für den Einsatz einer Faceted Search
Die wichtigste Voraussetzung für die Benutzung von Faceted Search ist die Erstellung einer Tag Taxonomie. Diese kann beispielweise aus der Menüstruktur abgeleitet werden. Wichtiger Tipp hier ist, nicht mehr als 4 Hierarchieebenen aus der Menüstruktur zu übernehmen. Die Tags werden dann später zur Verschlagwortung durch den Editor herangezogen.

Beispiel

Als Beispiel (siehe Wireframe rechts) möchte ich das Dokumenten-Center unserer Enterprise 2.0 Applikation heranziehen. Auf der linken Seite wird die Faceted Search angezeigt. In unserem Fall ist sie hierarchisch. Eine flache Struktur wäre auch denkbar. Durch das Markieren der Check-Boxen wird die Suchergebnismenge in der Mitte eingeschränkt, sprich die Dokumente werden gefiltert. Auf der rechten Seite sind technische Filter (oder Navigatoren) platziert, mit denen die Suchergebnismenge nochmals um Aspekte, wie Dokumententyp oder Zeitraum eingeschränkt werden können.

Fazit
In unseren Kundenprojekten haben wir die Erfahrung gemacht, dass Benutzer schneller und präziser die gewünschten Informationen mittels Facted Search - im Vergleich zur Volltextsuche - finden. Hierdurch kann die Usability von (Web-)Applikationen enorm gesteigert werden. Nicht verschweigen sollte man jedoch, dass es eine gewisse Zeit für den Benutzer bedarf, bis er sich von einer hierarchischen Menüstruktur gelöst hat.

Links
[1] http://de.wikipedia.org/wiki/Facettenklassifikation
[2] http://de.wikipedia.org/wiki/Colon-Klassifikation
[3] http://de.wikipedia.org/wiki/S._R._Ranganathan

Excel Prozesse und warum es sinnvoll ist, diese durch Grails Web Applikationen zu ersetzen

2011-10-30T16:36:00.000+01:00

Excel gilt in Fachabteilungen als das Schweizer Taschenmesser um verschiedenste Prozesse abzubilden. So ist ein Prozess auf den ersten Blick schnell aufgesetzt und das ohne die Involvierung der IT-Abteilung, die den Fachabteilungen bekanntlich meistens zu langsam ist.

Als fiktiven Prozess können wir hier beispielsweise den Export eines Excel-Sheets aus dem SAP System heranziehen. Dieses Excel-Sheet wird dann per Mail oder Fileshare zwischen den unterschiedlichen Abteilungen (oder auch mit externen Dienstleistern) verteilt, die jeweils einen oder mehrere Prozessschritte in diesem Excel-Sheet abarbeiten. Zum Schluss soll dieses Excel Sheet wieder in das SAP System importiert werden.

Einige Leser werden sich nun fragen, wo hier das Problem liegt, da ja genauso in ihrem Unternehmen gearbeitet wird. Zunächst einmal funktioniert das Ganze natürlich auch per Excel-Sheet. Es wird jedoch leicht übersehen, dass diese Excel-Prozesse auf Dauer teurer sind, als wenn sie über eine Software-Lösung abgebildet werden.

Was ist an einem Excel-Prozess suboptimal?
Folgende Punkte können anhand unseres fiktiven Prozesses als nachteilig aufgeführt werden:

Alle im Prozess beteiligten Personen wissen nie, ob sie wirklich die aktuelle Version haben.
Mit MS Sharepoint ist es zwar möglich, ein Excel Sheet in einer Gruppe zu bearbeiten. Dies hat jedoch den Nachteil, dass keine Drittsysteme eingebunden werden können, mit der Folge, dass sich Falscheingaben – wie beispielsweise eine falsche Email-Adresse – einschleichen können. Diese Informationen sollten jedoch direkt aus den Drittsystemen, wie in diesem Fall aus dem Verzeichnisdienst (beispielsweise Active Directory) gezogen werden.
Sollen externe Dienstleister integriert werden, müsste Sharepoint über ein Extranet geöffnet werden. Viele Firmen scheuen sich jedoch momentan noch, aus Gründen der Sicherheit, Sharepoint nach außen zu öffnen.
Der abschließende Import in das SAP System ist sehr fehleranfällig, da es schon reicht, dass jemand im Excel-Sheet versehentlich eine Falschangabe (beispielweise Formatänderung der Zelle, etc.) gemacht hat.
Alle Prozessbeteiligten müssen über die gleiche Excel-Version verfügen. Dies ist dann vor allem problematisch, wenn externe Dienstleister integriert werden sollen.
Die Unterstützung von mobilen Endgeräten (iPad, iPhone oder Android) ist nicht möglich.

Was sind die Alternativen?
Der Königsweg wäre ganz klar, die Prozesse mittels einer unternehmensübergreifen BPM bzw. SOA Strategie abzudecken. Als größtes Problem ist hierbei jedoch aufzuführen, dass solch ein Projekt sehr langwierig ist und die Vorurteile des Fachbereichs gegenüber der IT (zu langsam) sicherlich bekräftigt.

Ein Mittelweg wäre den Excel Prozess mit einer Web Applikation abzubilden. Wir benutzen hier sehr gerne das Open-Source-Framework Grails, mit diesem Framework ist eine schnelle Entwicklung möglich.

Was wären die Vorteile - am Beispiel - unseres fiktiven Prozesses:

In der ersten Phase könnte der Export und Import des Excel-Sheets aus dem SAP System bestehen bleiben. Es ist natürlich auch möglich, auf das SAP System direkt mittels SAPJco oder Web-Services zuzugreifen. Dies hängt ganz von den Wünschen des Kunden ab.
Alle Prozessbeteiligten erhalten eine aktuelle Sicht auf Ihre Daten. Und nur auf ihre Daten. Wir haben in diesem Kontext schon Excel-Sheets mit 5000 und mehr Zeilen gesehen. Ich denke jeder kann sich vorstellen, dass es hier leicht zu Fehleingaben kommen kann.
Externe Dienstleister können über ein Extranet (z.B. XML-Schnittstelle) bedient werden. Da das Grails Framework auf der Java JVM aufbaut, kann hier der gesamte Java Security Stack benutzt werden.
Der abschließende Import in das SAP System könnte direkt über SAPJco oder einen Web-Service erfolgen. Falls der Import über Excel gewählt wird, kann auf jeden Fall sichergestellt werden, dass das zu importierend Excel-Sheet sauber ist.

Fazit
Auf vielen Veranstaltungen bekommen wir positives Feedback, wenn wir unseren Mittelweg der Excel-Prozess-Optimierung vorstellen. So ist vielen Unternehmen schnell ersichtlich, dass ein Excel-Prozess auf lange Sicht viel teurer kommt, als eine saubere Software-Lösung. Der Mittelweg über eine Grails Web Applikation ist somit – aus unserer Sicht – eine sehr gute Lösung für Firmen, die noch nicht bereit sind für den unternehmensübergreifenden BPM/SOA Ansatz.

Wir benutzen nun das CRM System Highrise von 37signals.com

2011-10-01T18:31:00.000+02:00

Mit diesem Blogeintrag möchte ich kurz über die von uns gesammelten Erfahrungen, bei der Evaluierung unseres neuen CRM Systems, berichten. Bisher haben wir hierzu eine Kombination aus Outlook und Excel benutzt, mit den bei dieser Kombination typischen Problemen. Ein Anlass diesen Prozess zu optimieren bot sich letzte Woche, als wir von einer Veranstaltung zurück kamen. Wir hatten uns vorgenommen, eine kleine Evaluierung durchzuführen und falls wir nicht fündig werden, ein kleines CRM System - basierend auf dem Grails Framework - selbst zu schreiben. Unsere Projekt-Zeiterfassung haben wir bereits - nach einer erfolglosen Suche - mit dem Grails Framework implementiert [1]. Für uns waren folgende Kriterien besonders wichtig:

Source: 37signals.com

Die Anwendung sollte sehr einfach zu bedienen sein
Die Anwendung sollte keine lange Einarbeitungszeit erfordern
Die Anwendung sollte als Software as a Service (SaaS) verfügbar sein.
Einfacher Import von Kontakten, ohne ein Browser-Plugin installieren zu müssen

Welche Anbieter haben wir uns angeschaut?
Folgende Lösungen sind von uns evaluiert worden:

CAS PIA [2]
SageCRM.com [3]
Salesforce [4]

Schnell mussten wir feststellen, dass unsere Kriterien, wie beispielsweise Einfachheit, von keinem der Systeme erfüllt wurde. Zufällig erinnerten wir uns, dass auf der Homepage der Firma 37signals.com auch ein CRM System angeboten wird. Die Firma 37signals.com ist wohl den meisten als Anbieter der Projektmanagement-Lösung Basecamp bekannt. Aus Basecamp wurde später Ruby on Rails [5] extrahiert und Ruby on Rails ist wiederum der Initiator des Opensource-Projekts Grails[6]. Nun wussten wir, dass wir richtig waren :-).

Was gefällt uns an Highrise von 37signals.com besonders?

Das System sehr einfach und selbsterklärend aufgebaut
Die Lösung ist als SaaS verfügbar
Kontakte können einfach mittels Excel, CSV oder vCard importiert werden
Es können verschiedene Drittsystem (z.B. für den Mailversand) als Add-Ons angebunden werden
Wir können Kontakte mit Schlagworten („Tags“) versehen werden. Diese Vorgehensweise ist viel besser, als ein Kommentarfeld.
Emails können mit Outlook versendet werden. In der BCC Zeile gibt man eine Dropbox-Email-Adresse an. Die Mail wird dann automatisch zu dem Activity Stream des Kontakts hinzugefügt. Dies ist einfach nur genial!

Weitere Infos zu Highrise finden sich hier [7]

Fazit
Wir sind wirklich sehr begeistert von dieser Lösung. Die anderen Anbieter verfügen selbstredend über einen viel größeren Funktionsumfang. Diesen brauchen wir jedoch nicht. Highrise sollte man bei einer CRM-Evaluierung auf jeden Fall in Betracht ziehen.

Links
[1] Erfahrungsbericht: Ablösung einer Excel-basierten Zeiterfassung durch eine Grails Web-Applikation
[2] CAS PIA
[3] SageCRM.com
[4] Salesforce
[5] Homepage Ruby on Rails
[6] Homepage Grails Framework
[7] Highrise Tour

Social Media und das Thema Sicherheit

2011-09-30T18:46:00.000+02:00

In den letzten Wochen habe ich wieder sehr viele Blog-Posts gelesen, in denen immer wieder mantraartig auf die mangelnde Bereitschaft deutscher Unternehmen, sich mit dem Thema Social Media zu beschäftigen, hingewiesen wird. Laut zahlreicher Studien (z.B. [1]) lehnen demzufolge knapp 86% aller deutschen Unternehmen Social Media aus Sicherheitsgründen ab.
Auf Veranstaltungen zum Thema Social Media wird von Agenturen meist nur aufgezeigt, wie wichtig es ist, dabei zu sein. Sicherheitsthemen werden gerne ausgeblendet, da dies dem neuen Geschäftsfeld nicht zuträglich ist.
Ich möchte hier nicht gegen Social Media wettern, aber ich finde es immer besser, wenn man sich der Gefahr bewusst ist. Nur dann kann adäquat reagiert werden. Des Weiteren ist es meines Erachtens sehr wichtig, die IT-Abteilung von Anfang an, bei den sicherheitsrelevanten Themen, zu involvieren. Ein Alleingang der Marketing- bzw. Personalabteilung ist nicht anzuraten. Aber wo lauern jetzt genau die Gefahren?

Ein kleiner Exkurs in die Welt der Virenscanner
Durch einen Virenscanner wird verhindert, dass sich Schädlinge (Malware) - wie Computerviren, Computerwürmer oder Trojanische Pferde - auf einem PC einnisten können. Hierzu arbeiten die Hersteller vor allem mit 2 Verfahren, den Virensignaturen und Heuristiken (Suche nach Merkmalen eines Computervirus). Leider sind Virenscanner nicht 100% zuverlässig. So können Virensignaturen erst vom Hersteller zum Download angeboten werden, wenn diesem der neue Virustyp bekannt ist (Problem der Zero-Day-Attacke [2]).

Was macht Facebook und Co nun so gefährlich?
Ein Angriff ohne Social Media benutzt beispielsweise Massenemails. Bei dieser Angriffsform wird darauf vertraut, dass ein gewisser Prozentsatz unwissentlich auf einen Link klickt. Mit Social Media Netzwerken, wie Facebook, Xing oder Google+ können Angreifer mit einer viel kleineren Anzahl von Mails auskommen und somit (theoretisch) fast punktgenau Malware auf den PC eines Mitarbeiters einschleusen.

Wie könnte so ein Angriffsszenario aussehen?
So kann beispielsweise über Xing der Vor- und Nachname von Mitarbeitern einer bestimmten Firma (und vielfach sogar die Abteilung) ermittelt werden. Dann ist es ein leichtes sich die Emailadressen zusammenzusetzen. Ohne Xing müssten die Emailadressen durchprobiert werden. Die Vornamen würden einer Vornamenliste (die es im Internet gibt) entnommen, die Nachnahmen würden permutiert werden. So wäre beispielsweise meine Email-Adresse sehr schnell ermittelt, da mein Nachname nur aus 4 Buchstaben besteht. Bei dieser Vorgehensweise müssen jedoch sehr viele Mails – auch viele mit falschen Mailadressen – an den Mailserver der anzugreifenden Firma versendet werden, deshalb wird solch ein Angriff mit einer hohen Wahrscheinlichkeit auffallen. Bei der Social Media Variante erreichen alle Mails ohne Verdacht die Empfänger. Virenscanner, die im Mailserver installiert sind, können keine Muster erkennen, da es Emails sind, die individuell für einen kleinen Kreis von Adressaten erstellt wurden. Klickt dann ein Mitarbeiter auf einen Link innerhalb der Mail, so wird der Schädling (Malware) heruntergeladen. Diese wird vom Virenscanner wahrscheinlich nicht erkannt, da es sich um einen ganz neuen und individuell für diesen Angriff entwickelten Virus handelt.
Facebook ist aufgrund seiner sehr hohen Anzahl von Mitgliedern besonders interessant für Angreifer, vergleichbar mit Windows in Bezug auf Linux. Aus diesem Grund ist es wohl wahrscheinlicher, sich über Facebook Malware einzuschleppen, als über Xing. Ein weiteres Sicherheitsproblem ergibt sich bei Facebook und Co. dadurch, dass ich von meinen Kontakten (Freunde und Bekannten) Nachrichten erhalte - und nicht von einer unbekannten Phishing-Mail-Adresse -, die ich für vertrauenswürdig halte. Die Wahrscheinlichkeit, dass ich auf einen Link, der mir von einem Freund über Facebook geschickt wurde, klicke, ist somit weitaus größer. Durch Social Media erhalten Angreifer somit erstmalig die Möglichkeit sehr gezielte Angriffe durchzuführen.

Fazit
Durch Social Media wird eine neue Qualität von Angriffen stattfinden. Jedes Unternehmen muss für sich den Nutzen und die Gefahren von Social Media abwägen. Folgende Punkte sind meines Erachtens beim Einstieg in diese Thematik zu beachten:

Mitarbeiter müssen für das Thema Sicherheit im Kontext von Social Media sensibilisiert werden. Wichtig wäre es auch, eine IT-Security-Strategie in den Social Media Guide mit aufzunehmen. Hier könnte dann auch verankert werden, dass es beispielsweise wichtig ist, ein sicheres Passwort bei Facebook und Co. zu verwenden.
Brauchen alle Mitarbeiter Zugriff auf Social Media? Dies ist eine wichtige Frage. Meistens benötigt nur die Marketing oder Corporate Communications Abteilung einen direkten Zugang. Die restlichen Mitarbeiter könnten sich auch über Ihr Smart-Phone - während der Mittagspause - bei Facebook oder Xing einwählen. Den Zugriff der Marketingabteilung könnte man beispielsweise über eine Bitbox [3] absichern.
Des Weiteren wäre die Benennung eines zentralen Ansprechpartners wichtig. Zum einen können sich Mitarbeiter mit Fragen an diese Person wenden und zum anderen kann diese Person dann das Krisenmanagement koordinieren. Social Media wird zukünftig ein weiteres Aufgabengebiet für den Chief Security Officer darstellen.

Links
[1] http://www.itespresso.de/2011/09/12/studie-deutsche-unternehmen-blocken-social-media-am-haufigsten/
[2] http://de.wikipedia.org/wiki/Zero-Day-Exploit#Zero-Day-Exploit
[3] http://www.sirrix.de/content/pages/BitBox

Weitere Infos zu diesem Thema
http://www.heise.de/newsticker/meldung/Klick-Diebstahl-auf-Facebook-breitet-sich-aus-1207165.html
http://exensio.blogspot.com/2011/07/facebook-und-die-problematik-mit-der.html

Das Such-Interface in der exensio Enterprise 2.0 Plattform

2011-08-25T15:32:00.014+02:00

Im Artikel Fuzzy Search und "Meinten Sie?" in Apache Solr habe ich bereits erwähnt, dass wir in unserer Enterprise 2.0 Plattform auf Apache Solr als Suchmaschine setzen. In diesem Artikel gehe ich auf das User Interface unserer Suche innerhalb unseres Portals ein.

Prinzipien eines User Interfaces einer Suche

In jeder besseren Suche kann man nicht nur nach Begriffen suchen - man kann auch im Anschluss die zurückgelieferte Ergebnismenge mithilfe nützlicher Filter weiter einschränken. Bekannte Filteroptionen sind unter anderem das Datum oder der Dateityp.

Hilfreich sind solche Filter insbesondere dadurch, dass man die gesamte Ergebnismenge schrittweise (per Klick) verfeinern kann, um letztendlich aus einem großen "Topf" an Daten die relevanten Informationen zu erhalten.

Einsatz innerhalb des Enterprise 2.0 Portals

In unserem Portal ist die Suche eine zentrale Komponente, die in verschiedenen Portlets zur Filterung der Inhalte verwendet wird. Im Folgenden gehe ich auf das User Interface der "eigenständigen" Suche ein.

Eingabe von Suchbegriffen: Eingegeben werden kann alles, was Apache Solr unterstützt. Eine Übersicht über die Syntax und die boolschen Operatoren findet sich unter [1].

Auto-complete: Dabei werden die Auto-complete Vorschläge zur Laufzeit anhand der aktuell im Index vorhandenen Daten über Apache Solr ermittelt.

Administrations-Tools: Nützliche Funktionen rundum die Indizierung können von berechtigten Benutzern direkt über die Suchseite aufgerufen werden.

Sortierung: Die Sortierung nach Relevanz ist Standard und erfolgt über den von Apache Solr ermittelten Score. Alternativ wird eine Sortierung nach Datum angeboten.

Filter (Navigatoren/Facets): Die Filter lassen sich in unterschiedliche Kategorien einteilen. Sie können benutzt werden, um Dokumente nach Datum, Typ, Autor, Kategorie o.ä. zu filtern. In Screenshot 2 ist dargestellt, wie sich solche Filter sukzessive anwenden lassen um von einer großen Ergebnismenge auf ein paar gezielt herausgesuchte Ergebnisse zu kommen.

Meta-Informationen: Jeder Treffer enthält nützliche Meta-Informationen wie das Datum der letzten Aktualisierung oder - im Fall von Dokumenten - die Dateigröße.

Teaser und Highlighting: Zu jedem Treffer wird ein Teaser angezeigt, bei dem die gesuchten Begriffe hervorgehoben werden.

Blätterung: Die Blätterung erlaubt das schnelle Durchsuchen der Ergebnismenge.

Tag-Cloud: Die Tag-Cloud kann über beliebige Informationen gebildet werden. In diesem Fall werden die am häufigsten Begriffe, die im Kontext des aktuellen Suchbegriffs auftauchen, angezeigt (groß = häufig, klein = weniger häufig). Gleiches lässt sich auch problemlos auf strukturierte Daten wie Tags anwenden.

Screenshots der Suche

Suche nach exensio GmbH

Suche nach exensio GmbH mit anschließender Filterung auf Blog-Beiträge mit Tag "exensio" im Zeitraum ab 1. August 2011

[1] http://lucene.apache.org/java/3_3_0/queryparsersyntax.html
[2] http://wiki.apache.org/solr/SolrRelevancyCookbook

ETL-Prozesse mit Pentaho Kettle umsetzen

2011-08-20T16:14:00.000+02:00

Ein wichtiger Aspekt beim Aufbau eines Data Warehouses ist der Befüllungs-Prozess, der über den sogenannten ETL-Vorgang [1] erfolgt. Hierbei werden Daten von verschiedenen Quell-Systemen extrahiert, anschließend ggfs. transformiert und im abschließenden Schritt in das Data Warehouse geladen.
Zur Unterstützung des ETL-Vorgangs stehen zahlreiche Tools aus dem kommerziellen und Open-Source Umfeld zur Verfügung. Generell bringen Data Warehouse Lösungen selbst schon ein entsprechendes Tool bzw. Toolunterstützung mit.
Alternativ kann man natürlich den gesamten ETL-Prozess auch „von Hand“ umsetzen. Dies ist aufgrund der Komplexität mit einem entsprechenden Aufwand verbunden. Deshalb wird i.d.R. auf ETL-Tools zurückgegriffen, die vor allen Dingen die folgenden Anforderungen erfüllen:

Integration von verschiedenen Quell-Systemen
Skalierbarkeit
Erweiterbarkeit für die Integration von weiteren Systemen
Unterstützung für Daten-Transformationen (z.B. Aggregation, Filterung, …)
ausführliche Test-, Debug- und Logging-Möglichkeiten

Ein ausgereiftes ETL-Tool, das unter anderem diese Anforderungen erfüllt ist Kettle. Kettle ist ein Open-Source Produkt und stammt von der Firma Pentaho [2], die auch die gleichnamige DWH- bzw. BI-Lösung anbietet.

Kettle in der Entwicklung
Dreh- und Angelpunkt ist in Kettle das Designer-Tool Spoon. Mit dessen Unterstützung werden die sogenannten Jobs und Transformationen definiert. Die Transformationen sind für das eigentliche ETL-Handling zuständig. Jobs sind dagegen für die Einhaltung der Reihenfolge sowie die Verwaltung (z.B. auch Fehlerhandling) verantwortlich und können mehrere Transformationen enthalten.

Die vorherige Abbildung zeigt eine Transformation in der Designer-Sicht von Spoon. Im ersten Schritt werden aus einem Verzeichnis CSV-Dateien eingelesen. Beim Einlesen kann über einen Regex-Ausdruck definiert werden welche Dateien eingelesen werden. Aus den CSV-Dateien werden die benötigten Werte extrahiert und bei Bedarf auch formatiert. Da die Daten in ein relationales Datenbankschema geladen werden sollen müssen zunächst entsprechende Fremdschlüssel über Lookups ermittelt werden. Nach der Ermittlung des nächsten freien Primärschlüssels für die Zieltabelle kann abschließend die Einfüge-Operation vorgenommen werden.

Der Aufbau der Transformation sowie die Definition der einzelnen Schritte wurden allesamt mit Spoon vorgenommen. Das vorgestellte Beispiel zeigt nur eine kleine Auswahl an möglichen Schritten, die durchgeführt werden können. Spoon bietet ein sehr große Palette an vordefinierten Elementen, die für Transformationen eingesetzt werden können (z.B. Ausführung von Pragrammcode zur Konvertierung oder FTP-Transfer zum Abholen von Dateien).

Das Testen und Debuggen der Transformation wird direkt in Spoon durchgeführt und ermöglicht so eine schnelle Verifikation.

Fazit
Würde man die vorgestellte Transformation komplett in Eigenarbeit umsetzen wäre ein wesentlich höherer Zeitaufwand notwendig und auch Erweiterungen bzw. Änderungen würden höher zu Buche schlagen. Kettle eignet sich, aufgrund seiner zahlreichen Funktionen, neben der Nutzung als ETL Tool auch zur Durchführung von Migrations-Projekten oder als Import-Werkzeug für Daten in OLTP-Datenbanken.

Kettle ist ein ausgereiftes und verbreitetes Werkzeug, was sich in der Statistik mit ca. 15.000 Downloads pro Monat bei Sourceforge [3] widerspiegelt.

[1] http://en.wikipedia.org/wiki/Extract,_transform,_load
[2] http://www.pentaho.com/
[3] http://sourceforge.net/projects/pentaho/files/Data%20Integration/stats/timeline

Building a Portal with Grails-Framework

2011-08-19T18:12:00.002+02:00

In this blog post I will describe how we have implemented a web portal by using only the Grails Framework [1]. Our approach differs from the Grails Portlets Plugin in the fact, that in our case the portlets are running directly in a Grails application and not as a JSR 168 portlet in a Liferay portal.

Why do we need a Grails Portal?
exensio has a long experience in the development of portal solutions. So far we have used portal solutions from the major manufacturers like Oracle. On the other hand, we use the Grails framework for developing Web applications more and more. Thus the idea to combine both was close. Our solution offers the possibility to embed a Grails controller as a portlet within a Grails application. Below I've included screenshots showing this feature.

The Building Blocks of the Grails Portal
A portal consists mainly of the following building blocks:

Portal
Page contains one or more portlets. A Portal can contain one or more pages.
Portlet-Instance of a Portlet. Each Portlet can reside on the same or another page.
Portlet Preferences. Each portlet can have specific preferences. For instance, a path to the root node of content.

The wireframe below depicts these building blocks:

The Link Issue of the Grails Portal
The generation of links must be implemented in a portal different than in a Grails application. The problem in a portal is that a click on a link must be redirected to the portlet on which the click has been executed.
There are different ways to solve this problem. The easiest way is to use Ajax or Flash to implement the portlets. This was not our preferred solution. Our solution should be based on standard GSP pages. We solved the link problem by implementing a portal controller which gets the requests first. A link in our Grails Portal looks the following:

http://server:port/enterprise20/default/MicroBlog?po_67_portlet_action=save#po_67

The link contains all the necessary information like portal (since the portal can contain one or more portals), page, portlet instance and the action which should be executed in the instance of that portlet. The portal controller loops over all the portlets which reside on the executed page, renders each portlet and returns the whole portal page back to the browser.

Some Screenshots showing the Functionality

Grails Portal displaying two portlets

Adding new values to portlet on right hand side.

Error is shown at portlet level.

Page is shown after entering correct value.

Conclusion
As you can see it is possible to implement a portal based on the Grails framework. This portal acts like a portal from the major vendors but is much easier and faster to implement.

Links
[1] Homepage Grails Framework

exensio bekommt Nachwuchs ...

2011-08-09T09:33:00.000+02:00

natürlich nicht exensio, sondern unser Kollege Xuetao ist Vater geworden. Hierzu wollen wir auf diesem Weg noch einmal recht herzlich gratulieren. Aufgrund des Fachkräftemangels in Deutschland wollen wir sogleich den Nachwuchs unseres Kollegen an die Firma binden. Hierzu kamen wir auf die geniale Idee, einen Strampler mit dem exensio Firmenlogo zu verschenken :-)

Grails Entwicklung mit IntelliJ

2011-08-08T11:30:00.006+02:00

Ein guter Editor reicht dem Puristen für die Entwicklung von Grails Applikationen aus. Werden die Projekte größer stellt sich jedoch die Frage, welche Entwicklungsumgebung (IDE) benutzt werden soll. Aktuell gibt es zwei IDEs, die in der Grails-Entwicklergemeinde benutzt werden:

SpringSource Tool Suite (STS) [1]
STS basiert auf Eclipse, dies hat den Vorteil, dass das reichhaltige Angebot von Eclipse-Plugins benutzt werden kann. Dies hat jedoch auch den Nachteil, dass ein schlecht implementiertes Plugin das ganze Eclipse runterreißen kann.
IntelliJ IDEA [2]
Basiert nicht auf Eclipse. Im Settings-Dialog kann die Eclipse-Keymap eingestellt werden, um die tief verinnerlichten Eclipse-Short-Cuts weiterbenutzen zu können. Als Nachteil könnte bei IntelliJ vielleicht aufgeführt werden, dass Spring Insight (Profiling Aufsatz für den Tomcat) nicht "out of the box" integriert ist. Zudem ist die Ulimate Edition (nur diese unterstützt die Entwicklung von Grails Applikationen) kostenpflichtig.

Wir haben bei exensio bisher STS benutzt, haben in letzter Zeit jedoch vermehrt gehört, dass die Entwicklung mit IntelliJ schneller vonstattengeht. Um es kurz zu machen, IntelliJ scheint unserer Meinung nach wirklich eine gelungene IDE zu sein. Vor allem viele Kleinigkeiten finden wir sehr beachtenswert. Eine Liste mit allen Groovy und Grails Funktionalitäten finden sich hier [3][4]. Folgende Punkte haben uns bei IntelliJ beeindruckt:

Stabilität:
Bei STS war oft das deployte WAR irgendwie inkonsistent und es erschienen irgendwelche komischen Fehlermeldungen. Durch ein “grails clean” war die Applikation wieder deploybar, aber dieser Prozess war auf Dauer zu nervig.
Einfacherer Setup:
Bei Eclipse gibt es so viele Settings, sodass leicht etwas übersehen wird. Bei IntelliJ ist alles, was ein Grails-Entwickler benötigt, vorab konfiguriert.
Debugging:
Das Debugging von Closures ist bei IntelliJ "out of the box" möglich. Bei STS muss dies erst konfiguriert werden [5]. War bei uns in der STS 2.7.1 Version vorab gesetzt, das Debugging von Closures haben wir jedoch nicht hinbekommen. Des Weiteren ist es sehr mühsam, (wenn überhaupt möglich) die Variablen zu inspizieren.
Übersichtlichkeit:
Wir finden IntelliJ übersichtlicher. So hat man immer die Gruppe (Domain-Klasse, Controller, Views und Test) im Blick:
Oder es ist einfach möglich, per Klick von einer Action in einem Controller in die GSP-Seite zu springen:
Des Weiteren ist kann ein ER-Diagramm einer Domain-Klasse in Beziehung zu den anderen angezeigt werden. Hier ein Beispiel eines Star Schemas, das wir mit Grails GORM modelliert haben. Diese Funktionalität ist sehr nützlich, wenn das Datenmodell anfängt zu wachsen.

Fazit

Wir wollen hier keine Empfehlung geben, welche Groovy/Grails IDE nun die bessere ist, da die Wahl einer IDE für einen Entwickler einer Glaubensfrage gleicht ;-) . Jedoch fällt auf, dass IntelliJ sehr viele Kleinigkeiten anbietet, die in Summe die Grails-Entwicklung wirklich vereinfacht und beschleunigt. Es fällt auch auf, dass bei IntelliJ die Entwickler ermuntert werden, Verbesserungsvorschläge und Wünsche einzubringen, dies merkt man unweigerlich bei der täglichen Arbeit. Wer sich selber überzeugen möchte, kann sich eine Testlizenz herunterladen, die 30 Tage gültig ist.

Links
[1] http://www.springsource.com/developer/sts
[2] http://www.jetbrains.com/idea
[3] http://www.jetbrains.com/idea/features/groovy_grails.html
[4] http://blogs.jetbrains.com/idea/tag/grails/
[5] http://blog.springsource.com/2010/11/30/new-groovy-debug-support-in-sts-2-5-1/

Weitere nützliche Links zum Thema IntelliJ und Grails
[1] http://wiki.jetbrains.net/intellij/Creating_a_simple_Grails_application_with_IntelliJ_IDEA
[2] http://wiki.jetbrains.net/intellij/Managing_Grails_plugins
[3] http://www.grails.org/IDEA+Integration
[4] http://www.grails.org

Fuzzy Search und "Meinten Sie?" in Apache Solr

2011-07-29T10:31:00.006+02:00

In unserer Enterprise 2.0 Plattform setzen wir die Volltextsuchmaschine Apache Solr, die auf Basis der Such-Bibliothek Lucene arbeitet, mit Begeisterung ein. Dieser Beitrag soll beschreiben, wie dem Benutzer mit einfachen Mitteln bei Tippfehlern geholfen werden kann.

Spellchecker Komponente
Mit der SpellCheckComponent [1] teilt Solr Vorschläge zu den vom Benutzer abgesandten Suchtermen mit. Als Grundlage dieser Vorschläge kann ein Feld aus dem Such-Index herangezogen werden.

Die Konfiguration der Komponente ist bereits in der standardmäßigen schema.xml enthalten. So gilt es nur noch das Vorschläge-Verzeichnis aufzubauen. Solr erledigt dies automatisch, wenn der Parameter spellcheck.build=true an die Anfrage angehängt wird. Ein Beispiel wäre:

http://localhost:8983/solr/spell?q=test%20cotent&spellcheck=true&spellcheck.collate=true&spellcheck.build=true

Das muss selbstverständlich nicht bei jeder Abfrage gemacht werden.

Die eigentliche Suchabfrage sieht genau gleich - nur ohne den Parameter - aus. Bemerkenswert ist der Parameter spellcheck.collate=true, der nicht nur das falsch geschriebene Wort, sondern auch gleich die komplett korrigierte Suchabfrage zurück liefert. So liefert die SpellCheck-Abfrage nach "test cotent" als Vorschlag "test content" zurück.

Fuzzy Search
Ein weiteres Mittel, das Apache Solr (genauer gesagt: Apache Lucene) bietet, ist die "Fuzzy Search". "Fuzzy Search" steht für Suche mit einer gewissen Unschärfe.
Durch Anhängen einer Tilde an den eigentlichen Suchterm wird angegeben, dass der Suchterm mit Unschärfe betrachtet werden soll. Dies korrigiert zum Beispiel automatisch Tippfehler, liefert aber auch ähnliche Suchtreffer, die möglicherweise passen könnten, als Ergebnis zurück.
Während bei uns die Suche nach "exnsio" keinerlei Treffer hat, findet die Fuzzy Search nach "exnsio~" alle Dokumente, in denen "exensio" auftaucht.

Verwendung in unserer Enterprise 2.0 Plattform
Sowohl die SpellCheck-Komponente als auch die "Fuzzy Search" bieten eine einfache Möglichkeit, um den Benutzer bei der Suche zu unterstützen und eventuelle Tippfehler (sogar automatisch) zu korrigieren.
In unserer Enterprise 2.0 Plattform verwenden wir beide Möglichkeiten: Wir bieten dem Benutzer Vorschläge wie "Meinten Sie? ..." à la Google und führen gleichzeitig bei wenig Treffern eine Fuzzy Search zum eingegeben Suchterm aus, um dem Benutzer sofort passende Ergebnisse anzeigen zu können.

[1] Ausführliche Beschreibung zur SpellCheck-Komponente: http://wiki.apache.org/solr/SpellCheckComponent

Grails Quick-Start

2011-07-08T11:51:00.000+02:00

Ich bekomme des öfteren die Frage gestellt, wie man sich am besten in das Thema Grails einarbeitet. Aus diesem Grund möchte ich hier kurz zwei Empfehlungen geben, die sich sehr gut für einen Einstieg in das Grails-Framework [1] eignen.

"Getting started with Grails" - der Klassiker von Jason Rudolph liegt in der zweiten Version vor. Dieses Buch gibt es als PDF (Login bei InfoQ ist nötig) und kann von folgendem Link heruntergeladen werden.

Folgende YouTube Videos können ebenfalls empfohlen werden:

Getting Started with Grails - Teil 1

Getting Started with Grails - Teil 2

Getting Started with Grails - Teil 3

[1] Homepage Grails Framework

Links

Facebook und die Problematik mit der Sicherheit für Unternehmen

2011-07-05T09:17:00.000+02:00

Im Oktober letzten Jahres meldete die Wirtschaftswoche, dass Porsche den Zugang zu Facebook gesperrt hat. Als Grund wurde Angst vor Wirtschaftsspionage angegeben. Auf Veranstaltungen zum Thema Social Media wird dieses Vorgehen immer als Negativbeispiel angeführt. Und meistens höre ich Sätze, wie „Porsche hat Social Media nicht verstanden“ oder „Dann greifen halt die Mitarbeiter mit Ihrem Smartphone auf Facebook zu“. Mit diesem Blog möchte ich die Informationen zusammenfassen, die ich bei meiner Internetrecherche zu diesem Thema gefunden habe.

Was macht Soziale Netzwerke in Bezug auf Cyberattacken so gefährlich?
Symantec [2] warnt im Internet Security Thread Report aus dem Jahre 2010 vor Problemen, die für Unternehmen dadurch entstehen, dass Mitarbeiter gerne ihren Arbeitgeber oder ihre Rolle innerhalb des Unternehmens in sozialen Netzwerken preisgeben. Neben Symantec warnt auch das BSI [3] (Bundesamt für Sicherheit in der Informationstechnik) davor Angaben über den Arbeitgeber in sozialen Netzwerken zu veröffentlichen. Aber warum ist dies so gefährlich? In diesem Artikel der VDI Nachrichten [4] ist dies - meiner Meinung nach - sehr schön dargestellt.

Was macht Facebook besonders riskant?
Zunächst einmal ist es die Größe von Facebook. Wie bei Windows ist es auch hier viel wahrscheinlicher, einem Angriff ausgesetzt zu sein. So sehen die Security-Experten von Sophos [5] vor allem folgende Verbesserungsmöglichkeiten bei Facebook:

Kein Informations-Sharing ohne Zustimmung.
Prüfung von App-Entwicklern. Durch die vielen Apps [6] unterscheidet sich Facebook von den anderen sozialen Netzwerken. Aber leider sind sie auch ein Sicherheitsrisiko.
Verschlüsselung als Regelfall. Die vor kurzen eingeführte HTTPS Option sollte der Regelfall sein.

Fazit
Ich möchte hier nicht gegen soziale Netzwerke wettern. Ich selbst benutze sehr gerne Xing. Aber auf der anderen Seite sollte man auch nicht die Gefahren unterschätzen. So kann ich Porsche durchaus verstehen, wenn dort Facebook gesperrt wurde. Benutzt ein Mitarbeiter sein Smart-Phone für den Zugriff auf Facebook können zumindest keine Schadprogramme in das Firmennetzwerk gelangen. Für Firmen, die nicht so restriktiv sein möchten, gäbe es noch die Möglichkeit die BitBox [7] zu benutzen. In diesem Fall läuft der FireFox-Browser in einer virtuellen Maschine, die auf einem abgespeckten Linux-Kernel basiert. Die BitBox wurde von der Sirrix AG in Zusammenarbeit mit dem BSI (Bundesamt für Sicherheit in der Informationstechnik) entwickelt, um ein sicheres Surfen zu ermöglichen.

[1] http://www.wiwo.de/unternehmen-maerkte/porsche-sperrt-facebook-443688/
[2] http://www.zdnet.de/news/41551384/symantec-soziale-netzwerke-heizen-cyberattacken-an.htm
[3] https://www.bsi-fuer-buerger.de/BSIFB/DE/SicherheitImNetz/KommunikationUeberInternet/SozialeNetzwerke/Schutzmassnahmen/schutzmassnahmen_node.html
[4] http://www.vdi-nachrichten.com/artikel/Unfreiwillige-Spione-im-eigenen-Haus/52543/4
[5] http://business.chip.de/news/Facebook-Security-Experten-fordern-mehr-Schutz_48514422.html
[6] http://www.zdnet.de/news/41541354/neuer-facebook-wurm-verbreitet-sich-ueber-schaedliche-apps.htm
[7] http://www.sirrix.de/content/pages/BitBox

Unsere Enterprise 2.0 Plattform - basierend auf dem Grails-Framework

2011-05-30T09:49:00.001+02:00

Mit diesem Blogeintrag will ich über die Entwicklung unserer Enterprise 2.0 Plattform berichten. Es werden weitere Beiträge, die Teilaspekte der Plattform beleuchten, folgen. Die Entwicklung unserer Enterprise 2.0 Plattform basiert auf dem Framework Grails [1], das wir seit dessen Veröffentlichung sehr erfolgreich in diversen Web-Projekten einsetzen.

Warum eine weitere Enterprise 2.0 Plattform?
Schaut man sich den Markt für Enterprise 2.0 Lösungen an, so kann der Markt folgendermaßen klassifiziert werden:

Spezialisierte Anbieter – hierzu zählen beispielsweise ThoughtFarmer, SocialText, Confluence oder XWiki (Open-Source). Diese Lösungen waren meistens ursprünglich Wikis und wurden im Laufe der Zeit um weitere Funktionalitäten erweitern. Ein guter Überblick findet sich hier [2].
Content Management Systeme – wurden in den letzten Jahren um Enterprise 2.0 Funktionalitäten erweitert. Zu den kommerziellen Anbietern zählen beispielsweise OpenText oder Day CQ. Im Open-Source-Bereich finden sich hier beispielsweise TYPO3 oder Drupal.
Portal Anbieter – hierzu zählen alle großen, wie IBM (WebSphere / Lotus Connections / Lotus Quickr), Microsoft (Sharepoint) oder Oracle (WebCenter) aber auch Liferay aus dem Bereich Open-Source.

Unsere Enterprise 2.0 Plattform wird sich von der Idee auch im Portal-Segment wiederfinden. Im Vergleich zu den „großen“ Systemen soll unsere Lösung vor allem durch einen modularen Aufbau bestechen. Des Weiteren wird eine einfache Anpass- und Erweiterbarkeit durch das Grails-Framework erreicht. Es müssen nur die Teile benutzt werden, die vom Kunden in unterschiedlichen Projekten gefordert werden. So kann dies bei einem Wiki beginnen und bei einer komplexen Portal-Lösung enden.

Ein Portal hat hier (meine persönliche Meinung) den großen Vorteil, dass es einen ganzheitlichen Ansatz verfolgt. Das Portal ist hier mit einem Cockpit vergleichbar. Der Benutzer muss nicht zwischen verschiedenen Applikationen (bestehendes Portal und neu eingeführte Enterprise 2.0 Lösung) umschalten.

Als Beispiel möchte ich ein Außendienst-Portal heranziehen. Mit diesem erhalten die Außendienst-Mitarbeiter aktuelle Informationen in Form von Dokumenten oder die aktuellen Verkaufszahlen aus SAP. Dieses kann mit einem Microblog angereichert werden. Mit diesem können die Außendienst-Mitarbeiter - in Echtzeit - Informationen (beispielsweise über das Verhalten des Wettbewerbers) austauschen. Der Innendienst kann sich auch auf diesen Informationskanal („Flurfunk“) aufschalten und erhält tagesaktuelle Informationen über das Marktgeschehen.

Funktionalitäten unserer Enterprise 2.0 Plattform

In diesem Abschnitt möchte ich die Funktionalitäten beschreiben, die aktuell geplant sind. Weitere Funktionalitäten, wie Activity Stream oder Unterstützung von mobilen Endgeräten werden in Zukunft noch aufgenommen werden.

Content Management – hier haben wir uns entschieden, ein kleines CMS System selbst zu entwickeln. Weceem, ein CMS basierend auf dem Grails-Framework, war nicht mit unserem Portal-Gedanken zu verbinden. Wir sehen hier vor allem die Anforderung, dass Content in Form von Portlets dargestellt wird. Hier werden auch Informationen, wie Bilder oder Filme gespeichert.
Wiki – dieses Modul wird es einem Team ermöglichen Informationen zu dokumentieren. Im Unterschied zum CMS gibt es hier beispielsweise keinen Workflow.
(Micro)Blog – dieses Modul ermöglicht das Erstellen von Blogs. Mit Microblogs können Kollegen in Echtzeit Kurzinformationen austauschen (Twitter unternehmensintern).
Dokumenten Management – hier sind wir noch auf der Suche nach einem geeigneten Open-Source-System, das sich einfach integrieren lässt.
Tag-Management – ist die zentrale Komponente. Alle Informationen sollen mit Tags versehen werden können. Mit diesen Tags ist es dann auch möglich, eine Faceted-Search zur Navigation aufzubauen. Die integrierte Suche kann mit Hilfe der Tags bessere Ergebnisse liefern.
Kommentieren und Bewerten – dies ist auch eine zentrale Komponente. Es soll möglich sein, Content, Dokumente, Wiki- und Blog-Einträge kommentieren und bewerten zu können.
Suche – hier benutzen wir Apache Lucene bzw. Apache Solr.
Portlets – alle Module können in Form von Portlets integriert werden. Des Weiteren können Portlets auch Informationen aus Back-End-Systemen - wie SAP - darstellen.
Kollektive Intelligenz – dieses Modul soll Empfehlungen geben. Zum Beispiel, könnte ein Benutzer Informationen erhalten, dass sein Kollege Dokumente gelesen hat, die mit denselben Tags verknüpft sind, die auch für sie oder ihn von Interesse sein könnten.

Aktueller Stand

Die Implementierung der CMS-Funktionalitäten, des Blogs und die Applikations-Integration mittels Portlets ist abgeschlossen. Gegenwärtig arbeiten wir am Wiki, dem Tag Modul und der Suche. Die Abbildung rechts oben liefert einen ersten Eindruck über den aktuellen Stand der Implementierung.

Aufruf zur Mitarbeit

Wir suchen Mitstreiter, die an diesem Projekt mitarbeiten wollen. Voraussetzung wären Kenntnisse des Grails-Frameworks und eine Affinität für das Thema Enterprise 2.0.

Links

[1] Homepage Grails Framework
[2] Wikimatrix

Enterprise 2.0 – Rating und die wichtige Involvierung des Betriebsrates

2011-04-18T14:42:00.000+02:00

Das bewerten und kommentieren von Content ist ein wesentlicher Baustein im Enterprise 2.0. In einem Enterprise 2.0 Projekt wollten wir ein 1-5 Star Rating einführen. Dies wurde jedoch durch den Betriebsrat untersagt, da vermieden werden sollte, dass Mitarbeiter eine schlechte Bewertung für den von Ihnen eingestellten Content erhalten können. Es wurde vielmehr ein 1-3 Star Rating (von „Good“ bis „Excellent“ - siehe links im Bild unten) entwickelt und vom Betriebsrat abgesegnet. Wir haben mit diesem Rating Verfahren sehr positive Erfahrungen gemacht.

Rating 1-3 Stars versus 1-5 Stars (Amazon)

In meiner Social Media Arbeitsgruppe haben wir letzten Freitag hierüber gesprochen. Als Nachteil eines nur positiven Ratings wurde aufgeführt, dass es nicht möglich ist, zu unterscheiden welcher Content wirklich gut und welcher schlecht ist. Der Arbeitskollege erwähnte jedoch auch, dass in seiner Firma ein Rating wieder abgeschafft wurde, da sich ein Spezialist darüber echauffiert hatte, dass sein Content nur mit 2 Sternen bewertet wurde.

Ich habe hierzu im Internet recherchiert und bin auf folgenden interessanten YouTube-Blog-Eintrag [1] gestoßen. In diesem wird die Auswertung von allen auf YouTube getätigten Bewertungen beschrieben und in der Grafik unten visualisiert. Das interessante hierbei ist, dass es eigentlich nur 1-Star und 5-Star-Ratings gibt. In diesem Blog gibt es noch jede Menge interessante Kommentare, wie ein Rating verbessert werden kann. Das Ergebnis der Auswertung hat dazu geführt, dass es bei YouTube nur noch eine binäre Bewertung („Mag ich“ bzw. „Mag ich nicht“ analog zu Facebook mit „Gefällt mir“) gibt.

Ergebnis der Analyse aller Ratings bei YouTube (1-5 Stars)

Fazit
Wie eingangs beschrieben ist das bewerten und kommentieren von Content sehr wichtig im Enterprise 2.0 Kontext. Der Betriebsrat sollte von Projektbeginn an involviert werden, da dieser hier ein gewichtiges Wort mitzusprechen hat. Wir haben sehr gute Erfahrungen mit dem 1-3 Star-Rating gemacht und dieses ist auf jeden Fall keinem Rating vorzuziehen. Den von YouTube gewählten Ansatz finde ich auch sehr interessant und besser als ein 1-3 Star-Rating. Mich würde interessieren, ob diese Art der Bewertung auch von einem Betriebsrat abgelehnt würde. Meiner Meinung nach eher nicht, da es keine harte „Notenskala“ gibt, sondern eine weichere Bewertung. Des Weiteren sollte die Bewertung auch kommentiert werden, um Rückschlüsse auf die Bewertung zu ermöglichen.

Links
[1] YouTube Blog - Five Stars Dominate Ratings

Enterprise 2.0 und das Problem mit der Partizipation

2011-04-10T18:20:00.002+02:00

Eine Enterprise 2.0 Lösung ist meist schnell innerhalb eines Unternehmens eingeführt. Jedoch fehlt es meistens an einer Strategie, die Nachhaltigkeit von Enterprise 2.0 innerhalb eines Unternehmens zu verankern. Die Nachhaltigkeit kann sich jedoch nur einstellen, wenn die Enterprise 2.0 Community durch interessante Beiträge lebt.
Jakob Nielsen (Nielsen Norman Group) hat in seinem Blog-Beitrag (90-9-1 Rule for Social Design) im Jahre 2006 auf das ungleichmäßige Verhältnis von Content-Lesern und Content-Editoren im Internet hingewiesen. Seine in diesem Blog erwähnte 90-9-1-Regel besagt folgendes:

90% - lesen und suchen, liefern jedoch keinen Content
9% - steuern gelegentlich Content bei
1% - steuern regelmäßig Content bei

Quelle: Jakob Nielsen

Jakob Nielsen weist in seinem Blog-Beitrag (Social Networking on Intranets) aus dem Jahre 2009 darauf hin, dass es auch im Intranet ein Ungleichgewicht zwischen Mitarbeitern gibt, die viel beisteuern und solchen, die nur lesen. Es kommt seiner Meinung nach darauf an, dass das Verhältnis von Editoren und Lesern innerhalb der Community stimmt. Auch sind die reinen Leser nicht unterzubewerten, da auch sie von der Community profitieren. Das Verhältnis von Lesern und Editoren kann von Unternehmen zu Unternehmen variieren. Andrew McAfee beschreibt in seinem Blog-Beitrag (Enterprise 2.0 the Indian Way – 7. April 2011) einen Besuch beim indischen IT Dienstleister Tata Consultancy Services. Hier war der Anteil der Editoren sehr viel höher, bedingt durch einen sehr hohen Anteil von jungen Mitarbeitern (Digital Natives), die schon mit Social Media aufgewachsen sind.

Wie kann die Partizipation erhöht werden?

Jakob Nielsen hat in seinem Blog folgende Punkte hierzu aufgeführt:

Die Veröffentlichung von Content muss sehr einfach sein, damit nicht nur technisch Versierte mitmachen können.
Partizipation als Nebeneffekt. Vergleichbar mit Amazon‘s Empfehlungen oder Most Viewed Topics (Tag Cloud).
Teilnehmer sollen belohnt werden. Dies kann monetär (Incentives) oder auch mittels Anerkennung („Gold Stars“ auf Profil) realisiert werden. Andrew McAfee beschreibt in seinem Blog-Beitrag, dass bei TCS die Editoren vor allem durch Ihre Reputation innerhalb der Community motiviert wurden Inhalte beizusteuern. In Deutschland ist es ratsam sehr früh den Betriebsrat einzubinden.
Editoren mit qualitativ hochwertigen Informationen müssen promotet werden, damit Ihre Beiträge nicht in der Masse der 1% Überaktiven untergehen.

Folgende Vorschläge wurden innerhalb eines OpenSpace Workshops (moderiert durch Dr. Willms Buhse) auf der Social CRM Veranstaltung der Computerwoche in Karlsruhe erarbeitet:

Geduld - ein Klima (Unternehmenskultur), in dem die Mitarbeiter im doppelten Sinne Zeit bekommen
- in dem die Umstellung nicht bis gestern erwartet wird
- in dem der Zeitaufwand für die Einarbeitung in die neuen Strukturen und Werkzeuge berücksichtigt und/oder honoriert wird
Benutzerfreundlichkeit
Konkrete Ziele vereinbaren und dabei das mittlere Management einbeziehen
Menschen, die den Umgang mit den neuen Technologien und ihren Möglichkeiten begleiten (Moderatoren)

Fazit

Partizipation ist ein wichtiger Aspekt bei der Einführung von Enterprise 2.0 innerhalb eines Unternehmens. Meines Erachtens ist die kontinuierliche Moderation nach dem Go-Live sehr wichtig, damit die Begeisterung nach einer anfänglichen Euphorie nicht verloren geht. Ich höre des Öfteren auch noch eine weitere Möglichkeit, um die Partizipation zu steigern. Hierbei wird erwähnt, die Teilnahme innerhalb der Enterprise 2.0 Community in die Ziele des Mitarbeiters aufzunehmen. Dies würde ich jedoch nur als letzte Maßnahme in Betracht ziehen (falls obige Punkte nicht greifen), da eine freiwillige Teilnahme besser ist, als eine erzwungene.

Ist der ROI von Enterprise 2.0 berechenbar?

2011-03-07T10:36:00.002+01:00

Die Berechnung eines ROI für Enterprise 2.0 gilt gemeinhin als nicht trivial. Auf dem Blog des Harvard Professors Andrew McAfee [1] (Schöpfer des Begriffs Enterprise 2.0) bin ich auf einen interessanten Eintrag gestoßen. Dieser basiert auf einem Report [2] [3] der Unternehmensberatung Deloitte mit dem Titel “Social Software for Business Performance”. Hierin werden bei zwei Firmen messbare Verbesserungen durch den Einsatz von Wikis – im Kontext von Enterprise 2.0 – aufgezeigt.

Die Abbildung unten zeigt, wie durch den Aufbau eines Wikis bei der der Firma Alcoa (Hersteller von Befestigungssystemen) die monatlichen Compliance Stunden reduziert werden konnten.

Quelle: Deloitte

Die Abbildung unten zeigt wie ein Wiki bei der Firma OSIsoft die Problemlösung im Customer Support um 22% verbesserte.

Quelle: Deloitte

Fazit

Der kritische Leser wird nun anmerken, dass es in diesem Fall einfach ist, einen Mehrwert auszurechnen. Ich gehe hier d’accord – nicht für jeden Fall kann so einfach ein ROI für den Einsatz von Enterprise 2.0 berechnet werden. Jedoch fand ich es sehr interessant einmal harte Zahlen zu sehen und vielleicht gibt der Report von Deloitte dem einen oder anderen eine Idee, wie sich in seinem speziellen Fall ein ROI berechnen lässt.

[1] Blog von Andrew McAfee
[2] Social Software Seite von Deloitte
[3] Report über Social Software (Deloitte)

Effiziente Entwicklung mit Virtualisierung (Teil 2)

2011-02-27T20:04:00.011+01:00

Der erste Teil des zum Thema „Effiziente Entwicklung mit Virtualisierung“ hat die Vorteile der Virtualisierung für die Entwicklung aufgezeigt und ESXi als eine mögliche Lösung vorgestellt. In diesem Teil wird auf die Einrichtung und Konfiguration der Virtualisierungs-Images eingegangen.

Konfiguration eines Virtualisierungs-Images
Jeder Entwickler besitzt ein eigenes, vorkonfiguriertes VMWare-Image. Die Entwicklungstätigkeiten von exensio sind überwiegend im Bereich von Java angesiedelt und deshalb wird aus Performance-Gründen auf Linux als Betriebssystem für die Entwicklung und damit auch für die Virtualisierung gesetzt.

Es gibt ein Master-Image, das mit entsprechender Software, wie Entwicklungsumgebungen, Datenbank-Zugriff-Tools oder Versionsverwaltungssoftware, vorkonfiguriert ist. Die relevanten, über SVN versionierten, Software-Projekte werden entsprechend auf dem Master-Image ausgecheckt. Des Weiteren werden auf dem Master-Image auch zeitaufwendige Konfigurationen, wie die Einrichtung einer Domäne für einen Applikationsserver, vorgenommen.

Jeder PC-Benutzer hat natürlich auch seine Vorlieben und Einstellungen auf einem PC, die er nicht missen möchte. Durch Anlage eines Accounts auf dem Master-Image für jeden Entwickler können individuelle Konfiguration vorgenommen werden.

Neben den Entwicklungs-Images gibt es einen zentralen DB-Server auf dem alle Datenbanken für die Entwicklung verfügbar sind. Der DB-Server ist wiederum selbst eine virtuelle Maschine. Die nachfolgende Abbildung zeigt beispielhaft die virtuellen Maschinen für die Entwicklung und die Datenbank. Hierbei ist auf der rechten Seite der Abbildung auch zu sehen, dass virtuelle Netzwerke für die einzelnen Maschinen eingerichtet wurden. Damit werden die virtuellen Maschinen Netzwerk-Ports zugeordnet, um zu verhindern, dass alle über den gleichen Netzwerk-Port des ESXi-Servers gehen.

Ausrollen der Virtualisierungs-Images für ein neues Projekt
Wie erfolgt nun das Ausrollen der Virtualisierungs-Images, wenn exensio mit einem neuen Projekt beginnt?

Ggfs. noch nicht installierte Software wird auf dem Master-Image eingerichtet
Basisstruktur wird in der Entwicklungsumgebung angelegt (z.B. Workspace konfigurieren, Eclipse-Projekte erstellen, Domaine für den App-Server erstellen und konfigurieren)
Datenbank und SVN-Repository für das neue Projekt einrichten und auf Master-Image auschecken bzw. konfigurieren
Einfaches clonen des Master-Images für jeden Entwickler, der am Projekt teilnimmt
Der Entwickler muss nach dem Starten seines Images noch ein Script ausführen, in dem individuelle Anpassungen vorgenommen werden, wie das Setzen des Hostnamen oder Berechtigungen für seinen Login-Benutzer

Die vorangegangene Auflistung zeigt noch einmal deutlich die Zeitersparnis, dass nur eine Person die eher lästigen Schritte 1. bis 4. durchführen muss und die anderen Entwickler anschließend direkt loslegen können.

Infografik über Kollaboration im Enterprise 2.0

2011-02-27T15:31:00.001+01:00

Folgende Infografik von Socialcast zeigt meines Erachtens kurz und knapp, wofür Enterprise 2.0 steht. Besonders schön zeigt die Teilgrafik die historische Entwicklung von Collaboration Tools - von Emails hin zu Twitter. Der ganze Blog findet sich hier (inklusive größerer Grafik).

(Source: socialcast.com)

Content-Präsentation in Web-Portalen

2011-02-26T19:33:00.001+01:00

Wird in einem Projekt Content aus einem CMS in ein Portal integriert, gilt es die Unterschiede beider Systeme zu verstehen, um eine gute Portal-Architektur entwickeln zu können. Hier wird oft der Fehler gemacht, dass jede Content-Seite 1:1 als Portal-Seite abgebildet wird. Die hieraus entstehenden Probleme sollen mit diesem Blogeintrag beschrieben werden.

Unterschiede beider Systeme:
Seiten werden in einem CMS meistens statisch in Form von HTML-Seiten vorgehalten. In einem Portal sind alle Seiten jedoch Objekte, die im Speicher gehalten werden. Basiert das Portal auf Java-Technologien, so sind dies meistens JSPs. Werden nun alle Content-Seiten als JSPs abgelegt, führt dies unweigerlich zu Performance- und Memory-Problemen.

Schlechte Architektur:
In diesem Fall werden die Content-Seiten (inklusive der Content-Navigation) 1:1 innerhalb der Portal-Seiten abgebildet (siehe Abbildung unten). Dies hat den großen Nachteil, dass jede Content-Seite (repräsentiert durch eine Portal-Seite) als Objekt Memory verbraucht. Neben dem Memory-Problem tritt auch noch ein Performance-Problem auf, falls zu viele Berechtigungen (Personalisierung) auf die einzelnen Content-Seiten vergeben werden.

Die Abbildung unten zeigt des Weiteren, dass für jeden Menü-Eintrag der Content-Navigation eine weitere Portal-Seite aufgebaut wird.

Gute Architektur:
Hierbei wird darauf Wert gelegt, dass es nur ein (oder mehrere wenige) Content-Portlets gibt. Der Content wird basierend auf Abfragen integriert und nicht 1:1 abgebildet. Es ist auch vorstellbar, dass das Menü des Content-Portlets innerhalb der Hauptnavigation angezeigt wird.

Fazit:
Bei der Integration von Content aus einem CMS sind die Unterschiede beider Systeme zu beachten. Ein Portal ist ein dynamisches, ein CMS hingegen ein statisches System. Wichtig hierbei ist darauf zu achten, dass die Anzahl von Content-Portlets möglichst gering gehalten wird. Innerhalb des Content-Portlets kann dann über den gesamten Content navigiert werden.

In unserem Unternehmen brauchen wir Twitter nicht!

2011-02-26T11:11:00.004+01:00

Diese Aussage höre ich des Öfteren. Auch in unserem Unternehmen wird der Einsatz von Twitter kontrovers diskutiert. So sind viele der Meinung, dass über Twitter nur sinnlose Informationen verteilt werden, beispielsweise, dass der Zug von Kollege X 5 Minuten Verspätung hat. Dies kann natürlich geschehen, da es neben introvertierte auch extrovertierte Kollegen gibt. Aber nun möchte ich kurz schildern, wie wir diese Woche mittels Twitter einen Spezialisten für ein dediziertes Thema gefunden haben.

Wie uns Twitter half einen Spezialisten zu finden:

Wir hatten diese Woche ein Problem, zu dessen Lösung wir gerne den Rat eines Spezialisten eingeholt hätten. Nun gibt es die Möglichkeit, solch eine Frage in einer offenen Mailingliste oder in einem Internet-Forum zu stellen. Das Problem ist nur, es gibt sehr viele Mailinglisten und auch Foren, die teilweise die selben Themen adressieren. Deshalb dachten wir, ob sich das Problem nicht mit einem Tweet lösen lassen würde. Auf unseren Tweet haben wir innerhalb von 1 Minute eine Antwort erhalten. Wir waren alle sehr beeindruckt. Wichtig hierbei ist, dass man ein für das Thema relevantes Tag benutzt. Diesen Tag-Kanal können dann Interessierte abonnieren.

Was könnte Twitter für Unternehmen bringen?

In großen Unternehmen stellt die Suche nach einem Spezialisten immer eine große Herausforderung dar. Jeder kennt den Spruch: „Wenn Siemens wüsste, was Siemens weiß“. Gerade für das Finden von Spezialisten würde sich Twitter meines Erachtens sehr gut eignen. Man könnte Twitter vielleicht auch mit dem unternehmensinternen „Flurfunk“ vergleichen. Über den „Flurfunk“ werden Informationen verteilt. Bei Interesse kann man sich auf solch einen Informationskanal aufschalten. Diese Informationen können per Tag oder Volltext durchsucht werden. Dies würde auch dramatisch zu einer Reduktion von Informationsemails führen, die nur versendet werden, um beispielsweise auf einen nützlichen Link hinzuweisen.

Twitter in Grails einbinden mit Twitter4J

2011-02-25T11:40:00.002+01:00

Twitter kann auf sehr einfache Weise in Grails[1]-Applikationen eingebunden werden. Aufgrund der vorhandenen Grails-Plugins und Java APIs wird das Twittern in der eigenen Applikation damit zum Kinderspiel.

Eigene Applikation bei Twitter registrieren
Um mit einer fremden Applikation auf den eigenen Twitter-Account zugreifen zu können, muss die Applikation bei Twitter registriert werden. Das geschieht auf der Twitter-Seiter unter Einstellungen -> Verbindungen. Die entsprechenden Tokens, die Twitter für die Applikation generiert, werden für die Authentifzierung benötigt.

Installation und Konfiguration des Grails-Plugins Twitter4J
Unter anderem wegen der guten OAuth-Unterstützung [2] haben wir uns für das Grails-Plugin Twitter4J [3] entschieden.
Die Installation läuft Grails-typisch über "grails install-plugin twitter4j" ab. Die Konfiguration, in welcher der eigenen Applikation Zugang zum Twitter-Account gestattet wird, erreicht man über http://localhost:8080/enterprise20/twitter4j (enterprise20 steht für den eigenen Applikationsnamen). Innerhalb dieser Konfiguration werden die zuvor erzeugten Tokens benötigt.

Der erste Tweet über die eigene Applikation
Der Twitter4J Service lässt sich intuitiv in einem Grails-Controller ansprechen und so ist alles, was für den ersten Tweet benötigt wird, der folgende kleine Controller.


package com.exensio.enterprise20.controller

import org.twitter4j.grails.plugin.Twitter4jService;
import twitter4j.TwitterException

class TwitterController {

 Twitter4jService twitter4jService
 def maxMessageLength = 140
 
 def postStatus = {
  def message = params.twitterMessage
  if (message?.size() <= maxMessageLength) {
   twitter4jService.connect()
   try {
    twitter4jService.updateStatus(message);
   } catch (TwitterException te) {
    flash.error = te.message
   }
  } else {
   flash.message = "Please limit yourself to 140 characters"
  }
 }
}

Fazit & weitere Möglichkeiten
Der Zugriff auf Twitter gestaltet sich mit Grails und dem richtigen Plugin also sehr einfach. Über die Möglichkeit, mehrere Twitter-Accounts in der Applikation zu verwalten, kann beispielsweise durch eine intuitive Oberfläche das Twittern unter verschiedenen Accounts deutlich vereinfacht werden. Durch Implementierung von Addons wie der automatischen Einbindung eines URL-Shorteners [4] kann dem Benutzer hilfreiche Funktionalität rund um das "normale" Twittern angeboten werden.

Links
[1] Homepage Grails Framework
[2] Das OAuth-Protokoll
[3] Das Twitter4J Grails-Plugin
[4] Zum Beispiel der Google URL Shortener

In Usability investieren - Warum es sich lohnt...

2011-02-21T11:17:00.012+01:00

Die Usability einer Software entscheidet oftmals über den Erfolg eines Projekts, speziell im Bereich der Web Applikationen und Portale. Usability betrifft u.a. die Gestaltung (Design und Layout) und Aspekte wie Lesbarkeit, Navigation und intuitive Bedienbarkeit. Wie gut die Usability einer Software ist, wird in sogenannten Usability Tests geprüft. Hierzu gibt es jede Menge Methoden beginnend bei einfachen Usability Fragebögen bis hin zu allen möglichen Formen von Ton-, Video- und Bildschirmaufzeichnungen. Ein spezieller Test ist das Eyetracking (Blickbewegungsregistrierung), bei der die Blickbewegungen der Tester aufgenommen werden, um herauszufinden, welche Bereiche einer Seite besonders oder gar keine Beachtung finden.

Bei einer meiner Recherchen im Internet bin ich auf ein interessantes Video von Dr. Susan Weinschenk gestoßen, welches sehr anschaulich (und mit toller Animation) in 5 Minuten aufzeigt, wie sich Investitionen in Aktivitäten zur Optimierung der Usability lohnen.

Hier der Link auf das erwähnte ROI Poster.

Ist unternehmensinternes twittern sinnvoll?

2011-02-20T19:29:00.003+01:00

Immer mehr Unternehmen beschäftigen sich mit dem Thema Enterprise 2.0. So befinden Wikis bei den meisten Unternehmen bereits im Einsatz, um Wissen unter Kollegen zu teilen. Doch kann Micro-Blogging die Wissensvermittlung unter Kollegen fördern?

Was ist ein Micro-Blog?
Die Kurznachrichten, die über Twitter versendet werden, heißen Micro-Blogs. Die Länge einer Nachricht ist auf 140 Zeichen begrenzt. Die interessanteste Neuerung bei Twitter war meines Erachtens die Einführung von Hash-Tags im August 2007, mit denen es möglich ist, Nachrichten zu filtern. Ich möchte nicht verschweigen, dass es zu dem Thema ‚Tags‘ kontoverse Diskussionen gibt, da Twitter auch über eine Suchfunktion verfügt. Suchergebnisse, die auf Tags basieren, sind meistens jedoch sinniger.

Wozu könnten Micro-Blogs innerhalb von Unternehmen eingesetzt werden?
Die Email – das heute beliebteste Kommunikationsmittel – stößt langsam an seine Grenzen. Bei großen verteilt arbeitenden Teams können Micro-Blogs dem Austausch von Informationen und Ideen dienen und viele Emails ersetzen. Eine Email erwartet von der Idee her eine Antwort. Es gibt jedoch viele Informationen, die per Email verteilt werden, jedoch keine Antwort erwarten. Diese enthalten meistens das Akronym „FYI“ und einen oder mehrere Links. Ein weiterer Unterschied zur Email ist, dass meine Informationen gefunden werden, ohne, dass ich diese verteile (Push vs. Pull). Micro-Blogs können auch mit einer virtuellen Kaffee-Pause vergleichen werden, bei der Informationen in Kurzform ausgetauscht werden. Ich möchte mit dieser Aussage jedoch keine Vier-Augen-Kaffee-Pausen durch virtuelle ersetzen ;-). Kollegen, die auf Reisen sind, können auch an diesen Informationen partizipieren. Ein weiterer Vorteil ist die Möglichkeit, nach diesen Informationen (und deren Verfassern, die potentielle Experten sein könnten) zu suchen.

Lösungen für unternehmensinternes twittern:
Die folgenden Lösungen können unternehmensintern eingesetzt werden. Hierbei gibt es die Möglichkeit, diesen Service zu mieten (SaaS) oder sich die Software intern zu installieren. Bei Saas gilt es auch, Fragestellungen bezüglich des Datenschutzes zu bedenken. Hier eine kurze Auflistung von verfügbaren Lösungen (die Liste erhebt keinen Anspruch auf Vollständigkeit):

Yammer – ist wohl die bekannteste Plattform. Ist als SaaS verfügbar. Weitere Informationen finden sich hier.
CO-OP – verfügbar als SaaS. Weitere Informationen finden sich hier.
Status.net – Open-Source-Lösung. Kann als SaaS gemietet oder hausintern installiert werden. Weitere Infos finden sich hier.
Communote – SaaS Lösung aus Deutschland. Weitere Infos finden sich hier.
Es wäre auch denkbar, solch eine Lösung basierend auf dem Grails-Framework ganz individuell - auf Kundenwünsche angepasst - zu realisieren.

Fazit:
Ich bin der Meinung, dass Micro-Blogs eine interessante Möglichkeit zur Wissensverarbeitung bieten können. Für einen erfolgreichen Einsatz reicht es jedoch nicht aus, sich ein Tool auszusuchen. Es ist vielmehr wichtiger, eine sinnvolle Tag-Taxonomie aufzubauen, damit das Wissen später wieder gefunden werden kann.

Effiziente Entwicklung mit Virtualisierung (Teil 1)

2011-02-13T16:21:00.006+01:00

Insbesondere bei größeren Projekten haben wir schon öfters in der Praxis erlebt, dass einiges an Zeit für die Einrichtung und das Warten der Entwicklungsinfrastruktur benötigt wird. Woran liegt das?
Die Entwicklungsumgebungen bieten heutzutage eine große Unterstützung und sind in der Regel einfach zu installieren. Allerdings sind in vielen Fällen zusätzliche Konfigurationen und Installationen notwendig z.B. für das Anbinden von Drittsystemen. Dies kann sehr zeitintensiv sein, wenn jeder Projektmitarbeiter dies an seinem Entwicklungsrechner selbst durchführt.
Kosten und auch Nerven kann der Einsatz von Virtualisierung in der Entwicklung sparen.

Virtualisierung mit ESXi
exensio setzt hierfür ESXi [1] ein. ESXi kommt von der Firma VMWare und ist ein sogenannter Bare-Metal-Hypervisor, der direkt auf der Server-Hardware installiert wird. Es handelt sich dabei um ein abgespecktes Linux-System, das im Vergleich zu anderen Virtualisierungslösungen einen sehr niedrigen Overhead hat. Des Weiteren ist ESXi kostenfrei verfügbar.

Für die Entwicklung greifen Entwickler auf ein VMWare-Image zu, das auf dem zentralen ESXi-Server läuft. Der Zugriff erfolgt bei Windows über den Remote Desktop und bei Linux über den NXClient. Auf dem VMWare-Image ist alle notwendig Software installiert und konfiguriert, so dass direkt mit der Arbeit losgelegt werden kann.
Die Hardwareausstattung des ESXi-Servers sollte angepasst sein an die Anzahl der parallel arbeitenden Entwickler. Bei komplexeren JEE-Projekten sollte man pro Virtuelle Maschine mit 3,5 GB RAM kalkulieren.

In einem der nächsten Blogeinträge wird detaillierter auf die Konfiguration, Individualisierung und Verteilung der VMWare-Images eingegangen.

Vorteile der Virtualisierung
Welche Vorteile können sich also durch die Nutzung von Virtualisierung für die Entwicklung ergeben?

Zeitersparnis, da die Basisumgebung nur einmal eingerichtet wird und anschließend für alle Entwickler dupliziert wird. Bei größeren Projekten ist diese Arbeit nicht zu unterschätzen:

Anlegen oder Konfiguration einer Server-Domaine (z.B. JDBC-Einstellungen)
Installation der Entwicklungsumgebung
Ggfs. Konfiguration der Versionsverwaltung
Basisstruktur für das Projekt wird einmal zentral aufgesetzt
Installationen und Konfiguration für den Zugriff auf Backendsysteme (z.B. DLL für SAP-Zugriff)

Es kann einfach auf eine funktionierende Entwicklungsinfrastruktur zurückgegriffen werden, falls etwas "zerstört" wurde (z.B. defekte Serverdomäne), sei es durch den Entwickler selbst oder das System.

Wird eine Applikation kompiliert oder deployed, dann fällt in der Regel eine hohe Belastung für die CPUs an. Durch die Virtualisierung steht über den ESXi-Server wesentlich mehr Leistungspotential (CPU, Festplattendurchsatz, ...) zur Verfügung, das von den jeweiligen VMs zeitweise abgerufen werden kann.

Was sollte man beachten?
Für einen reibungslosen Ablauf und Verbesserungen ist die Mitarbeit aller Entwickler erforderlich. Änderungen die zukünftig für alle verfügbar sein sollten müssen in das Masterimage zurückgespielt werden. Dies können beispielsweise Helper-Skript sein oder Plugins für die Entwicklungsumgebung.

Des Weiteren sollte für die Verwaltung der zentralen Entwicklungsserver eine dedizierte Personengruppe zuständig sein, da sonst sehr schnell der Überblick verloren geht.

[1] ESXi

Eignet sich Grails auch für „große“ Projekte?

2011-01-23T19:30:00.007+01:00

In dem Blog mit dem Titel „Why use Grails“ [1] sind sehr gut die Gründe aufgeführt, die meines Erachtens für Grails sprechen. Wir setzen seit mehreren Jahren Grails erfolgreich ein und sind vor allem von der Schnelligkeit begeistert, mit der es möglich ist – im Vergleich zur herkömmlichen JEE Implementierung – Applikationen zu entwickeln. Dennoch entdecke ich immer wieder Artikel, die die Aussage treffen, dass sich Grails nur für „kleine“ Projekte eignet. Hier meine Meinung zu Punkten, die ich öfters lese:

Skalierbarkeit:
Die Skalierbarkeit von Grails-Applikationen wird des Öfteren bemängelt. Natürlich gibt es sehr viele Beispiele von Vorzeigeprojekten [2] bei denen es offensichtlich keine Probleme gab. Grails ist wie jedes andere Web Framework für eine gute Skalierbarkeit entworfen worden. In Grails selbst können natürlich – wie bei jeder anderen Software – auch Bugs enthalten sein. So ist im Zusammenhang mit Performanz ein Tag-Lib-Problem bei Grails bekannt geworden, dies wurde inzwischen gefixt.
Es kann nur empfohlen werden, schon während der Entwicklung Lasttests durchzuführen, um die Architektur auf Skalierbarkeitsaspekte hin zu überprüfen. Dies machen wir auch bei herkömmlichen JEE-Applikationen, die wir neben Grails auch noch mit JEE (JPA, EJBs, Servlets, JSPs, JSF etc.) entwickeln. Auch bei klassischen JEE-Applikationen mussten wir schon des Öfteren unseren Sourcecode umbauen, da die anfängliche Implementierung nicht performant genug war. Da Grails auf Spring und Hibernate basiert, sollte sich immer ein Weg finden, um die Performanz zu optimieren. Notfalls direkt mit Java beziehungsweise Hibernate.
Testbarkeit:
Hier wird oft bemängelt, dass eine Grails Applikation nicht so einfach zu testen sei, da Groovy benutzt wird. Groovy ist eine dynamische Sprache und somit können Fehler erst zur Laufzeit auffallen, da hier – nicht wie bei Java – schon während der Compilierung etwaige Probleme gefunden werden können. Grails bringt schon von Haus aus die Möglichkeit mit, JUnit-Tests zu entwickeln. Eine weitere Möglichkeit stellt das Tool Cobertura dar, mit dem es möglich ist, die Test-Coverage des Source-Codes zu bestimmen. Hier sei vielleicht folgender Blog [3] zu empfehlen. Benötigen Teile des Systems eine 100% Test-Coverage so können diese auch in Java entwickelt werden. Ein weiterer Punkt sollte nicht vergessen werden – mit Groovy wird ein kompakterer Code geschrieben, demzufolge sollte dieser auch weniger Fehler enthalten.
Teamgröße:
Ich habe neulich in einem Blog gelesen, dass Grails nicht für Teams > 5 Programmierer geeignet ist. Diese Aussage ist mir vollkommen schleierhaft. Geht man bei Grails von einer Produktivitätssteigerung vom 3-4 fachen – im Vergleich zu einem JEE Team – aus, so würde ein 5 Mann starkes Grails-Team ein 15-20 Mann starkes JEE Team ersetzten. Dies ist schon eine Teamgröße, mit der sich etwas bewerkstelligen lässt. Soll von noch größeren Teams ausgegangen werden, so ist es wohl immer auch eine Frage des Projektmanagers und des Architekten, wie so ein Projekt in Module aufgeteilt wird, die dann von den einzelnen Teams implementiert werden können. Bei Grails könnte man sich auch vorstellen, solche Module in Form von Plugins abzubilden. Des Weiteren ist meiner Meinung nach die von Grails vorgegebene Projektstruktur ein klarer Pluspunkt, insbesondere wenn bedacht wird, dass es einfacher wird neue Entwickler in das Team zu integrieren, da einem Grails-Entwickler diese Struktur bekannt ist und er sich nicht in eine neue Struktur einarbeiten muss.
Komplexität:
Ein großer Vorteil von Grails ist das Paradigma „Convention over Configuration“. Dies kann jedoch auch den Eindruck erwecken, dass nicht hochkomplexe Applikationen erstellbar sind, da man nicht alle Freiheitsgrade wie bei JEE vorfindet. Generell gilt auch hier, dass alles, was mit Spring/Hibernate funktioniert auch mit Grails funktioniert. Wird seitens des Projekts jedoch die Unterstützung von EJBs gefordert so muss der JEE Weg beschritten werden.
JEE 6:
Durch die Einführung von JEE 6 wird auch häufig diskutiert, ob es noch Frameworks wie Grails bedarf. JEE 6 stellt gegenüber seinem Vorgänger klare Verbesserungen – beispielsweise durch die Einführung des Paradigma „Convention over Configuration“ – dar, jedoch muss man JEE 6 mit dem Gesamtpaket von Grails [1] vergleichen. Meine Meinung hier ist, dass Grails hier immer noch einige interessante Vorteile bietet. Hierbei zählt für mich auch die Sprache Groovy.

Fazit
Ich hoffe, es ist mir gelungen, ein paar Vorurteile gegenüber dem Einsatz von Grails bei „großen“ Projekten aus dem Weg zu räumen. Dennoch möchte ich mich hier auch nicht festlegen, was der Königsweg ist. Dies muss für jedes Projekt erneut entschieden werden. Aber gerade für Projekte, die sehr budgetsensitiv sind, führt meines Erachtens kein Weg an Grails vorbei. Früher hätte man JEE (oder genauer J2EE) auch nicht zugetraut, dass auf dieser Plattform einmal geschäftskritische Applikationen laufen.

[1] Why use Grails?
[2] Grails Testimonials
[3] Grails Test-Coverage

Domain-Modellierung in GORM, Tipps/ BestPractices

2011-01-17T12:17:00.209+01:00

Grails Domain Klassen sind Grundbausteine und enthalten die Datenstrukturen und Zuständen einer Geschäftsanwendung.
Die Domain-Modellierung ist ein wichtiger Bestandteil des Grails Object Relational Mappings (GORM).

In den vergangenen Grails Projekten, die in der Produktionsumgebung eine Oracle-Datenbank benutzen, finden einige Arbeitschritten zur Domain-Modellierung in derselben Art regelmäßig wiederkehrend statt.

Diese routinemäßigen Schritte möchte ich nun anhand eines Beispiels beschreiben:

package com.exensio.myapp.helper;
public class Constants {
    public static final String DB_PREFIX = "MYAPP_"; // 1
}

abstract class AbstractEntity implements Serializable { // 2
    Date    dateCreated // 3
    Date    lastUpdated // 4
    Integer    version // 5
}

class Project extends AbstractEntity { // 6
    String title

    static mapping = {
        table   Constants.DB_PREFIX + "project" // 7
        id      generator: "native", params:[ sequence: Constants.DB_PREFIX + "project_id_seq" ] // 8
        sort "title" // 9
    }
    String toString() { title } // 10
}

Tabellen-/Sequenzen- Namen bei dem DB-Mapping

Aus folgenden Gründen wird in dem obigen Beispiel (Punkten-1,7,8) ein DB-Präfix verwendet:

Wie die meisten Datenbank-Systeme hat Oracle vordefinierte Schlüsselwörter, die nicht als Tabellen-/Sequenz- Namen verwendet werden dürfen. Mit einem Präfix kann dies Problem vermieden werden.
Das Präfix ermöglicht die Verwendung eines gemeinsamen DB-Schemas mit weiteren Applikationen.

Automatisches Timestamping

Die Idee ist, automatisch einen Zeitstempel bei einer schreibenden DB-Operation zu setzen. Technisch wird dies mittels zwei GORM-Events: "beforeInsert" und "beforeUpdate" realisiert.
Als Grails-Entwickler hat man hier Glück, da mann den Konventionen folgen kann und zwei Attributen (wie Punkte-3,4 im Beispiel) definiert.

Erläuterung der einzelnen Punkten:

DB-Präfix der Applikation, siehe auch Punkt-7
Eine abstrakte Basisklasse, die das Interface Serializalbe implementiert
Automatisches Timestamping, per Namenskonvention aktualisiert GORM die zwei Attribute("dateCreated" und "lastUpdated") bei entsprechenden Ereignissen
Automatisches Timestamping, siehe auch Punkt-3
Das "Version" Attribut( ähnlich wie bei der JPA Annotation: @Version), das von GORM zum "Optimistischen Locking" verwendet wird
Eine Grails Domain Klasse, durch die Vererbung verfügt es über alle Eigenschaften seiner Basisklasse
Name der DB-Tabelle "MYAPP_PROJECT". Dieses Verfahren ermöglicht zum einen die Verwendung eines gemeinsamen DB-Schemas mit weiteren Applikationen, zum anderen wird hierdurch vermieden, dass ein von der Datenbank reserviertes Schlüsselwort als Tabellenname verwendet wird.
Name der DB-Sequenz "MYAPP_PROJECT_ID_SEQ". Diese hat die gleiche Funktion wie der Tabellename von Punkt-7
Defaultmäßige Sortierung nach "Title" in einer List von Projekten
Defaultmäßige String-Repräsentation für ein Objekt der Domain Klasse.

Impressionen von der DOAG 2010

2010-11-20T18:15:00.012+01:00

Am 17. und 18. November nahm ich an der DOAG 2010 [1] teil und möchte in diesem Blogbeitrag meine Eindrücke schildern. Ingesamt wurden auf der DOAG über 400 Sessions abgehalten. Da meistens 20 Sessions parallel liefen, fiel einem die Auswahl nicht immer leicht. Ich legte den Schwerpunkt für meine Vorträge auf die Bereiche Java und Middleware-Technologien.

Die besuchten Sessions zu Middleware verfestigten nochmal die Ankündigung von Oracle, dass ADF (Application Development Framework) [2] als Jave EE Framework strategisch im gesamten Bereich WebCenter gesetzt ist. Es werden damit auch die internen Applikationen wie bspw. die Administrationsoberfläche umgesetzt. Inwiefern sich ADF am freien Markt behaupten kann wird sich noch zeigen müssen. Hierzu gab es auch einen spannenden Vortrag der ADF, Spring und Grails miteinander verglichen hat. Die dort aufgeführten Ergebnisse decken sich auch großteils mit unseren Erfahrungen. Spring ist sehr flexibel und umfasst ein großes Spektrum, ist aber bzgl. der Entwicklung aufwendiger. Mit Grails lassen sich, wie auch schon von meinem Kollegen aufgeführt [3], sehr schnell Applikationen entwickeln. Allerdings hat man nicht die komplette Freiheit und stößt ggfs. an Grenzen. ADF ist zwischen den beiden Frameworks anzusiedeln.

Sehr interessant fand ich ebenfalls aus technischer Sicht den Vortrag von Ed Burns und Oliver Szymanski zu JSF2. Einige neue Features kennt man ja schon durch diverse Artikel und die Spezifikation, allerdings ist es viel interessanter, wenn man die Dinge life "vorprogrammiert" bekommt.

Die Keynote von Professor Hermann Maurer "Es stehen uns noch viele Entwicklungen und Überschungen ins Haus ..." war für mich der faszinierenste und auch abwechslungsreichste Vortrag. Prof. Maurer belegte anhand mehrerer Punkte warum die technologische Entwicklung in vielen Bereichen rascher und schneller ist wie wir meist annehmen. Insbesondere zeigte er auch auf warum es so schwierig bzw. fast unmöglich ist längerfristige Vorhersagen über Entwicklungen zu machen.

Für das leibliche Wohl war mit allerlei Köstlichkeiten ebenso wie für das Rahmenprogramm bestens gesorgt. Großer Beliebheit erfreuten sich die drei Billardtische und das am Mittwoch-Abend ausgespielte Turnier unter der Leitung von Bundestrainer Andreas Huber sowie der Billardprofis Manuel Ederer und Dominic Jentsch.

[1] http://doag.org/konferenz/doag/2010/
[2] http://www.oracle.com/technetwork/developer-tools/adf/index.html
[3] http://exensio.blogspot.com/2010/10/erfahrungsbericht-ablosung-von-excel.html

Grails-spezifische Settings für den Weblogic Server

2010-11-03T08:41:00.005+01:00

In diesem Blog-Eintrag möchte ich zwei Weblogic-spezifische Themen für die Entwicklung von Grails Applikationen erläutern.

1. JDK Version des Zielsystems verwenden:
Jede Weblogic Server Version wird mit einem eigenen JDK ausgeliefert. Beim Weblogic Server 8.1.4 ist es beispielsweise die Version 1.4.2_05, beim WLS 9.1 ist es die Version 1.5.0_04 und beim WLS 10.3.2 ist es die Version 1.6.0_14.
Um böse Überraschungen bezüglich JDK Versionen beim späteren Test und Deployment in der Produktionsumgebung zu vermeiden, sollte die Gails Applikation gleich nach dem Anlegen des Projekts so konfiguriert werden, dass die Applikation mit dem JDK des Zielsystems kompiliert wird.

Zum Kompilieren bzw. zur WAR-Generierung eines Grails Projekts können folgende Skripte verwendet werden:
- ${PROJECT_HOME}/war.cmd:


set JAVA_HOME=${WL_HOME}\bea103\jdk160_05
set PATH=%JAVA_HOME%\bin;%PATH%
call grails war
pause

- ${PROJECT_HOME}/run-app.cmd:


set JAVA_HOME=${WL_HOME}\bea103\jdk160_05
set PATH=%JAVA_HOME%\bin;%PATH%
call grails run-app
pause

2. Der Weblogic Deployment Descriptor (weblogic.xml)
Wenn folgende Exception beim Publizieren einer Grails Applikation auf dem Weblogic Server auftritt, hilft eine entsprechende weblogic.xml Konfiguration im WEB-INF Verzeichnis (siehe unten).
Weitere Infos finden sich unter: http://www.grails.org/Deployment

- Exception:


org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'pluginManager' defined in ServletContext resource [/WEB-INF/applicationContext.xml]: Invocation of init method failed;
nested exception is java.lang.NoSuchMethodError: org.apache.tools.ant.helper.AntXMLContext.setCurrentTargets(Ljava/utilMap;)

- ${PROJECT_HOME}/web-app/WEB-INF/weblogic.xml:


<?xml version="1.0" encoding="UTF-8"?>
<weblogic-web-app      xmlns="http://www.bea.com/ns/weblogic/90"
                    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                    xsi:schemaLocation="http://www.bea.com/ns/weblogic/90
                    http://www.bea.com/ns/weblogic/90/weblogic-web-app.xsd">
    
<container-descriptor>
      <prefer-web-inf-classes>true</prefer-web-inf-classes>
</container-descriptor>

</weblogic-web-app>

Slide-Effekt bei BlackBerry-Apps

2010-10-29T07:44:00.003+02:00

Beim Gebrauch von Apps, sei es für BlackBerrys, Androids oder iPhones, fällt stets auf, dass bei der Interaktion mit dem Benutzer auf ähnliche Effekte gesetzt wird. So fährt beispielsweise bei einem Klick auf Menüpunkte oder Links meist der neue Inhalt von rechts in den Bildschirm ein.

Bei der Entwicklung von BlackBerry-Apps ist ein solcher Effekt einfach zu implementieren. Die entsprechenden Begriffe in der BlackBerry-App-Welt lauten hierbei:
- Screen: Ein Screen enthält den Inhalt, der auf dem Bildschirm angezeigt wird. So kann es etwa einen Login-Screen und einen Home-Screen geben.
- TransitionContext: Der TransitionContext beschreibt, wie von einem Screen zum nächsten gewechselt wird. Screens können beispielsweise von einer Richtung außerhalb des Bildschirms in den Bildschirm fahren (slide) oder der neue Screen kann über dem alten eingeblendet werden (fade). Weitere Effekte heißen wipe und zoom.

Die folgende Methode beschreibt, wie beim Klick auf den Login-Button der neue Home-Screen eingeblendet wird. Die Dauer ist mit 500 ms angegeben.


public void fieldChanged(Field field, int context) {
 if (field instanceof LoginButton) {
  // Get UI engine for transition effetcs
  UiEngineInstance engine = Ui.getUiEngineInstance();
  
  // Init new home screen
  homeScreen = new HomeScreen();
                         
  // Specify and set transition context for sliding in
  TransitionContext transitionContextIn = new TransitionContext(TransitionContext.TRANSITION_SLIDE);
  transitionContextIn.setIntAttribute(TransitionContext.ATTR_DURATION, 500);
  transitionContextIn.setIntAttribute(TransitionContext.ATTR_DIRECTION, TransitionContext.DIRECTION_LEFT);
  engine.setTransition(null, homeScreen, UiEngineInstance.TRIGGER_PUSH, transitionContextIn);
  
  // Specify and set transition context for sliding out
  TransitionContext transitionContextOut = new TransitionContext(TransitionContext.TRANSITION_SLIDE);
  transitionContextOut.setIntAttribute(TransitionContext.ATTR_DURATION, 500);
  transitionContextOut.setIntAttribute(TransitionContext.ATTR_DIRECTION, TransitionContext.DIRECTION_RIGHT);                                                            
  transitionContextOut.setIntAttribute(TransitionContext.ATTR_KIND, TransitionContext.KIND_OUT);
  engine.setTransition(homeScreen, null, UiEngineInstance.TRIGGER_POP, transitionContextOut);
  
  // Push home screen on stack
  synchronized(UiApplication.getEventLock())
  {
   UiApplication.getUiApplication().pushScreen(homeScreen);                       
  }          
 }
}

Da diese Effekte häufiger benutzt werden und dabei immer einheitlich aussehen sollten, bietet es sich an, die Erstellung des "Transition Contexts" in eine kleine Helper-Klasse auszugliedern.

Personalisierungsformen bei Portalen

2010-10-23T17:54:00.001+02:00

Eine wichtige Funktion von Portalen stellt die Personalisierung dar. Erst hiermit ist es möglich, Informationen zielgerichtet verschiedenen Benutzergruppen zur Verfügung zu stellen. Zuerst boten Framework-Portale [1], wie das Oracle WebLogic Portal, Oracle WebCenter, IBM WebSphere Portal aber auch das Liferay Portal diese Funktionalität an. Beim Liferay Portal sei hier angemerkt, dass erst mit der Version 6 eine regelbasierte (Rules-Engine) Personalisierung möglich ist. Neuerdings bieten jedoch auch die Hersteller von Content-Management-Systemen (CMS) wie OpenText oder Day diese Funktionalität an.

Im Folgenden werden die verschiedenen Formen der Personalisierung erläutert:

Explizite Personalisierung – bei der expliziten Personalisierung wird basierend auf dem Benutzerprofil die Personalisierung durchgeführt. Das Benutzerprofil sollte die Möglichkeit bieten, Informationen aus verschiedensten Systemen – wie LDAP, Active Directory aber beispielsweise auch SAP – aggregieren zu können. Mit der expliziten Personalisierung ist es beispielsweise möglich Mitarbeitern aus verschiedenen Abteilungen unterschiedliche Informationen bereitzustellen. Oder bei einem Kundenportal könnte der Kunde einen Teaser mit einem Geburtstagsgruß eingeblendet bekommen.
Implizite Personalisierung – bei der impliziten Personalisierung wird das Interaktionsverhalten des Benutzers für die Personalisierung benutzt. Klickt ein User beispielsweise des Öfteren auf eine risikoreiche Anlageform, so erhält er im Weiteren mehr Informationen zu risikoreichen Anlagen. Diese Form der Personalisierung ist technisch und fachlich am schwierigsten zu realisieren. Die meisten Portale unterstützten nur die Verarbeitung der Klick-Events. Im Hintergrund müssen dann jedoch noch teilweise sehr aufwändige Prozesse laufen. Des Weiteren ist es hier sehr wichtig einen sehr guten Web-Miner an der Hand zu haben, der in dem großen – durch Web-Tracking – angehäuften Daten solche Muster erkennen kann. Diese Form der Personalisierung ist die komplexeste, wobei davon auszugehen ist, dass diese Form der Personalisierung in den nächsten Jahren immer mehr Anhänger finden wird, da sie gerade bei Kundenportalen interessante Möglichkeiten bietet.
Individualisierung – hierbei kann ein Users sich das Portal eigenen Anforderungen anpassen. So ist es beispielsweise für den Benutzer möglich Portlets auf einer Seite nach eigenen Kriterien anzuordnen und zu parametrisieren (zum Beispiel die Url bei einem RSS Feed).

Fazit

Bei einem Portalprojekt ist zunächst zu klären, welche Form der Personalisierung relevant ist. Die explizite Form unterstützen die meisten Hersteller. Jedoch ist darauf zu achten, dass die Personalisierung auf einer Rules-Engine basiert. Bei der impliziten Form ist davon auszugehen, dass bei den meisten Produkten noch Drittsysteme – beispielsweise eine Real Time Decision Engine, die basierend auf einem Model in Echtzeit Entscheidungen trifft, was für welchen Benutzer angezeigt werden soll - angeschafft werden müssen.

[1] Mein Blog-Eintrag mit dem Thema „Klassifikation von Portal-Lösungen“

Erfahrungsbericht: Ablösung einer Excel-basierten Zeiterfassung durch eine Grails Web-Applikation

2010-10-08T17:55:00.004+02:00

In diesem Blog-Eintrag möchte ich über ein internes Projekt der exensio GmbH berichten.

Ausgangssituation:
Für die Zeiterfassung unserer Beratertätigkeit hatten wir früher – wie viele andere Beratungshäuser auch – Excel eingesetzt. Richtig zufrieden waren wir mit dieser Lösung nicht wirklich. Die Eingabe der Stunden gestaltet sich noch recht einfach, die Konsolidierung am Monatsende war jedoch immer recht mühsam. Eine kleine Unaufmerksamkeit führte dann zu inkonsistenten Stundenzetteln. Alles in allem war ein Kollege ein Tag hiermit beschäftigt.

Wir dachten – das muss doch auch anders gehen:
Da wir ein IT-Beratungshaus sind, lag die Idee nahe, Excel durch ein web-basiertes Informationssystem zu ersetzten. Wir machten uns auf die Suche nach einer passenden Software. Wir fanden viele, jedoch hat keine so richtig auf unsere Prozesse gepasst. Und die Bedienung war generell bei allen Systemen zu komplex. Wir wollten natürlich auch nicht Funktionalität bezahlen, die wir überhaupt nicht benutzt hätten. Selbst ein kleines Unternehmen wie wir, wünscht sich, dass sich die Software an die eigenen Prozesse anpasst und nicht umgekehrt.

Machen wir es doch selbst:
Natürlich kam schon bald die Idee auf, eine eigene Zeiterfassung zu entwickeln. Leider ist dies mit den herkömmlichen Frameworks sehr zeitaufwendig und wir hatten nur ein kleines Budget. Unsere Anforderungen waren natürlich hoch. Es sollte eine elegante und einfach zu bedienende Rich Internet Application (RIA) - mit AJAX und alles was heute dazugehört - werden. In Kundenprojekten setzen wir schon seit geraumer Zeit sehr erfolgreich das Grails Framework [1] ein. Also lag nichts näher, als auch dieses Framework für unsere interne Zeiterfassungssoftware einzusetzen.

Und hat es geklappt?
Wir hatten unser Budget auf 25 Tage fixiert. Innerhalb dieser Zeit war es möglich eine Applikation für uns zu erstellen, die genau auf unsere Prozesse abgestimmt funktioniert. Man muss hierbei jedoch immer wieder darauf hinweisen, dass dies nur mit einem Framework wie Grails möglich ist. Wir waren bei der Entwicklung 3-4 mal produktiver verglichen mit herkömmlichen Tools.

War es für uns ökonomisch sinnvoll eine solche Applikation zu bauen?
Die Berechnung der Amortisierung stellt sich in diesem Fall denkbar einfach dar. Wir hatten früher 1 Tag für die Erstellung der Stundenzettel, die die Grundlage für die Rechnungsstellung bilden, gebraucht. Nun passiert dies auf Knopfdruck. Dies bedeutet, dass sich die Applikation für uns in 25 Monaten amortisiert hat. Ich denke dies ist kein schlechter Wert, wenn man davon ausgeht, dass laut Lehrbuch sich eine Anschaffung erst nach 3 Jahren amortisieren muss.

Fazit:
Es ist durchaus möglich, Applikationen in kurzer Zeit bei kleinem Budget zu entwickeln. Dies könnte besonders für den Mittelstand von Interesse sein, der in diesem Fall eine Software erhält, die genau seinen Prozessen folgt. Dies spart natürlich auch Einarbeitungszeit, da man keine überflüssigen Funktionalitäten erlernen muss. Als nächstes steht bei uns die Anschaffung eines CRM Systems (z.B. SugarCRM) an. Falls wir kein geeignetes System am Markt finden, werden wir auch hier wieder unser eigenes auf unsere Anforderungen und Prozesse optimiertes System bauen.

[1] Grails Framework

Weitere Informationen:
exensio Grails Flyer
Artikel in DOAG News 02/2010 zu WebLogic und Grails

Kommunikation zwischen mehreren Flash-Objekten über LocalConnection

2010-10-07T21:46:00.005+02:00

Flash und Flex sind mit der Programmiersprache Actionscript, welche auf dem ECMAScript-Standard basiert, weit mehr als nur ein Spielzeug um Videos oder blinkende Werbefilme abzuspielen. Durch die Unterstützung des objektorientierten Programmierparadigmas, guter Möglichkeiten der Serveranbindung und nicht zuletzt der Browser-Unabhängigkeit, die das Adobe Flash Plugin out of the Box bereitstellt, ist Flash ein Werkzeug, welches Beachtung verdient.

In diesem Beitrag soll anhand der Kommunikation zwischen verschiedenen Flash-Dateien, die in einer Seite eingebunden sind, gezeigt werden, wie robuste "Inter-Flash"-Kommunikation mit der LocalConnection-Klasse [1] in Flash funktioniert.

Sender
Zuerst wird eine Verbindung mit einem LocalConnection-Objekt aufgebaut. Im Anschluss können über einen frei wählbaren "Kanal" Daten gesendet werden. Das folgende Beispiel soll dies veranschaulichen:


var conn:LocalConnection = new LocalConnection();
conn.addEventListener(StatusEvent.STATUS, onStatusConn);
conn.send("exensioConnectionChannel", "connectionHandler", "exensio GmbH", "Other payload");

Es wird also über den Kanal "exensioConnectionChannel" bei jedem Client die Methode "connectionHandler" aufgerufen, die zwei String-Parameter erwartet. In diesem Fall werden "exensio GmbH" und "Other payload" als Daten gesendet. Dabei ist die Anzahl der zu übermittelnden Parameter beliebig.

Empfänger
Auf Empfänger-Seite muss ebenso eine Verbindung über ein LocalConnection-Objekt bestehen. Dabwei muss auf dem gleichen Kanal auf Nachrichten gewartet werden, über welchen auch der Sender Daten sendet. Im Beispiel sieht das wie folgt aus:


var recConn:LocalConenction = new LocalConnection();
recConn.connect("exensioConnectionChannel");
recConn.client = new ReceiverHandler();
recConn.addEventListener(StatusEvent.STATUS, onStatusRecConn);

Die Unterschiede zum Code des Senders bestehen hier also in der Angabe des Verbindungsaufbaus über "connect" und der Angabe eines "Clients". Diese Angabe gibt die Klasse an, in welcher die vom Sender bestimmte Methode enthalten ist. Ein Auszug aus unserer Klasse "RecieverHandler" sieht wie folgt aus:


public function connectionHandler(companyName:String, payload:String):void {
    //...
}

Die Angabe eines EventListeners, der auf das Status-Event "Status" reagiert, ist optional. Es empfiehlt sich jedoch, einen solchen anzugeben und zu implementieren, da darin die Fehlerbehandlung vorgenommen werden kann.

Fazit
Mit der LocalConnection-Klasse ist es in Flash und Flex auf einfache Weise möglich, Daten zwischen mehreren Flash-Dateien auszutauschen, ohne dabei den Umweg über einen weiterleitenden Server gehen zu müssen. Benötigen also mehrere Flash-Dateien auf einer Seite die gleichen Daten eines entfernten Servers, müssen diese nur einmal abgerufen werden um so etwa Serverressourcen zu sparen.

[1] http://livedocs.adobe.com/flash/9.0_de/ActionScriptLangRefV3/flash/net/LocalConnection.html

Automatisiertes "Builden" einfach gemacht

2010-09-26T13:58:00.004+02:00

Einführung

Für die Produktivsetzung, Tests oder auch beim Einsatz von Continuous Integration [1] werden bei Java-Applikationen WAR-, EAR- bzw. JAR-Archive benötigt. In der Regel bieten Entwicklungsumgebungen entsprechende Funktionalitäten zur manuellen Erzeugung der Archive an. Diese Archive werden auf den Zielsystemen wie bspw. einem Applikation-Server eingespielt.

Insbesondere bei größeren Software-Projekten sollte es aber auch die Bestrebung geben einen automatisierten Build-Prozess aufzusetzen.

Umsetzung

In der Java-Welt stehen hierfür unter anderem Buildwerkzeuge wie ANT [2] oder Maven [3] zur Verfügung. Wenn es allerdings an komplexere Sachen wie EJB 2.1 Generierungen oder spezifische Erweiterungen für Produkte geht, ist die Erstellung dieser Skripte aufwändig. Im konkreten Projekt stand solch ein Fall im Bereich Weblogic Portal an. Oracle bietet für die Erstellung der Build-Skripte entsprechenden Support [4][5]. Doch die Vergangenheit hat gezeigt, dass die generierten Build-Dateien zumindest im Portal-Umfeld nicht funktionieren und mit einem relativ hohen Aufwand nachbearbeitet werden mussten.

Mit der Entdeckung des Projektes headlesseclipse [6] lösten sich die Befürchtungen auf, einen hohen Aufwand für die Erstellung eines automatisierten Build-Prozesses investieren zu müssen. headlesseclipse ist ein Eclipse-Plugin, das per Kommandozeile den Build von Archiven analog zum manuellen Oberflächenmodus startet. Durch die Mitgabe von Parametern ist eine entsprechende Steuerung möglich. Die Installation ist denkbar einfach und es muss lediglich die heruntergeladene JAR-Datei im Eclipse-Plugin Verzeichnis platziert werden.

Der Aufruf zur Erzeugung der in der Entwicklungs-Umgebung befindlichen EAR-Projekte sieht folgendermaßen aus:


eclipse -nosplash -data d:\projects\TimesheetApp -application com.ind.eclipse.headlessworkspace.Application exportears

Ergebnis sind im konkreten Fall drei EAR-Archive für das Portal, das Backend sowie für den automatisierten Test. Zur Überraschung aller ließen sich die drei Archive fehlerfrei installieren und selbst die Meta-Informationen für die SVN-Versionsverwaltung wurden dank des Subclipse-Plugins bei der Erstellung exkludiert.

Fazit

headlesseclipse bietet eine erfreulich einfache Möglichkeit, um mit der Entwicklungsumgebung Eclipse sehr schnell und automatisiert Java-Archive erzeugen können. Schön wäre lediglich noch die Erweiterung um eine Log-Datei, die entsprechende Informationen über die Fortschritte bzw. Fehlerfälle protokolliert.

Müssen im Build-Prozess noch individuelle Anpassungen vorgenommen werden, wie bspw. das Setzen von Properties in Abhängigkeit von der Zielumgebung, bieten natürlich Werkzeuge wie ANT und MAVEN einen entsprechenden Vorteil.

[1] http://en.wikipedia.org/wiki/Continuous_integration
[2] http://ant.apache.org/
[3] http://maven.apache.org/
[4] http://download.oracle.com/docs/cd/E12840_01/wlw/docs103/guide/ideuserguide/build/conUseCustomAntBuild.html
[5] http://weblogic-wonders.com/weblogic/2010/02/12/how-to-auto-generate-build-xml-file/
[6] http://code.google.com/p/headlesseclipse/

Ist Offshoring von IT-Projekten nach Indien sinnvoll?

2010-09-19T19:03:00.001+02:00

Mit großem Interesse habe ich die Artikel in der Computerwoche (beispielsweise Ausgabe Nr. 36 vom 06.09.2010) zum Thema Offshoring verfolgt. Meine Meinung hierzu ist, dass dieses Thema aufgrund des demographischen Wandels in den nächsten Jahren immer bedeutsamer werden wird, es sei denn die Softwarehersteller schaffen (endlich) intelligentere Systeme bzw. Frameworks, mit denen die Entwickler sich mehr um die Fachlichkeit kümmern können, als sich mit technischen Problemen herumschlagen zu müssen. Wir von exensio setzten hier beispielsweise gerne bei der Entwicklung von Web Applikationen das Grails-Framework ein, wenn wir auf JEE - sofern es keine zwingende Kundenanforderung hierfür gibt - verzichten können.

Aber nun zurück. Das Offshoring-Thema wird gerne vom Einkauf verfolgt, da man sich eine dramatische Kostenreduzierung erhofft. Hierbei wird jedoch oft vergessen, dass für einen Projekterfolg mit einem Offshoring-Dienstleister einiges zu beachten ist. Da man jedoch davon ausgeht, dass alles vergleichbar mit einem deutschen Dienstleister abläuft, scheitern sehr viele Projekte dieser Art. Und wer will schon gerne über gescheiterte Projekte berichten.

Folgende Punkte sind meines Erachtens zu beachten:

Erhöhter Kommunikations- und Spezifikationsaufwand
Es wird meistens vergessen, dass bei Offshoring-Projekten ein erheblicher Mehraufwand für die Kommunikation und Spezifikation betrieben werden muss. Es wird leider nicht über den Tellerrand geschaut: Was in der Spezifikation steht, wird umgesetzt, auch wenn es keinen Sinn macht. Dies ist besonders kritisch bei der Entwicklung von Individual-Software, da jeder weiß, dass Papier sehr geduldig ist. Bei technischen Aufgabestellungen (beispielsweise Datenbank auf UTF-8 umstellen) ist ein Offshoring-Projekt viel leichter zu realisieren. Auch gilt zu bedenken, dass es viel einfacher ist komplexe Zusammenhänge in der Muttersprache zu formulieren.
Team-Skalierbarkeit
Dies wird immer gerne als positives Beispiel für einen Offshore-Dienstleiter genommen, da bei den heimischen Dienstleistern angeblich meistens Ressourcenknappheit herrscht. Scheint ein Projekt sich zu verzögern, so wird dann seitens des Offshore-Dienstleisters verkauft, dass dies kein Problem darstellt. Man könne ja das Team von anfänglich 15 Entwicklern schnell auf 50 oder auch 100 Mitarbeiter erweitern. Meiner Erfahrung nach ist die hieraus resultierende Software später leider nicht mehr vernünftig wartbar. Alles Weitere lässt sich bei Tom De Marco nachlesen.
Verschiedene Zeitzonen
Dies ist meiner Erfahrung nach kein Problem. Ich konnte beispielsweise auch noch spät abends einen Entwickler in Indien erreichen.
Ingenieurmäßiger Ansatz
Dieser Punkt stellt für mich das größte Problem dar. Wir Deutschen sind für unsere Präzision bekannt. Bei der Softwarequalität müssen auf jeden Fall Abstriche in Kauf genommen werden. Leider führt dies auch zu langfristig höheren Wartungskosten. Im schlimmsten Fall wird das gesamte Projekt langfristig viel teurer, als wenn es in Deutschland entwickelt worden wäre.
Hierarchische Arbeitsstrukturen im Vergleich zu eigenverantwortlichem Arbeiten
Es gibt ganz eindeutig kulturelle Unterschiede. Ich werde nie folgende Szene vergessen, als ich selbst in Indien vor Ort war: Ein Entwickler musste den Projektleiter fragen, ob er sich ein Fachbuch aus dem verschlossenen Regal (Schlüssel hatte der Projektleiter) nehmen darf. Hieraus resultiert wieder, wie eingangs bereits erwähnt, ein höherer Spezifikationsaufwand.
Kostenersparnis
Das erste Angebot ist natürlich viel billiger als das eines deutschen Mittbewerbers. Leider wird dann jedoch meistens für die spätere Wartung des Systems vergleichbare Preise verlangt. Entscheidet sich der Kunde, das System wieder in eigener Regie warten zu wollen, so muss er meistens feststellen, dass die Software nicht sauber entwickelt wurde und durch ihn nicht wartbar ist.
Projekt-/Architekturcontrolling
Für einen Projekterfolg ist es sehr wichtig das Projekt aus Projekt- sowie Architektursicht genau zu steuern. Hierbei ist es wichtig früh genug Mängel in der Umsetzung der Spezifikation aufzudecken. Eigentlich wäre hier ein agiler Ansatz richtig. In 2-wöchigen Sprints wäre schnell ersichtlich, wo es hapert. Hierzu gibt es jedoch unterschiedliche Auffassungen, viele meinen, dass das Wasserfall Modell hier besser passen würde, da die meisten Offshore-Dienstleister erst noch Erfahrungen mit Scrum und XP sammeln müssen. Hierbei kann auch ein Dienstleister wie die exensio GmbH unterstützen.

Fazit
Bei einem Offshoring-Projekt sind viele Aspekte zu beachten. Bedingt durch den demographischen Wandel, wird dies in den nächsten Jahren für viele Firmen eine interessante Option darstellen, die eigene IT-Abteilung zu entlasten. Diese Projekte müssen jedoch noch genauer geplant werden, um erfolgreich abgeschlossen werden zu können. Offshoring sollte somit eher als langfristige Unternehmensstrategie angesehen werden.

Einsatz von Spring mit EJB 3.0

2010-09-18T19:03:00.008+02:00

Einführung

Spring ist eines der am weitesten verbreiteten Java-Frameworks und wird insbesondere bei vielen Java-Projekten im Enterprise-Bereich verwendet.
Obwohl das Framework mittlerweile ein sehr breites Spektrum an Funktionalitäten abdeckt, ist der IoC Container (Inversion of Control) nach wie vor die am meisten eingesetzte Kern-Funktionalität von Spring.

Auch exensio nutzt die IoC-Funktionalitäten zur Erreichung einer losen Koppelung und insbesondere um Backend-Implementierungen über
Konfigurationen austauschbar zu machen.

Bei Web-Applikationen wird hierbei die Konfigurationsdatei für Spring in den meisten Fällen mit Hilfe eines Listener-Eintrags in der Datei web.xml geladen.
Doch wie lädt man eigentlich Spring-Konfigurationen in EJB-Projekten?

Spring und EJB 3.0

Zunächst ein einfaches Szenario: In einem EJB-Projekt existieren mehrere Session-Beans, die unter anderem auch Methoden eines Such-Service und eines CMS-Service aufrufen. Die Services sind zu Beginn eines Projektes noch nicht verfügbar und deshalb werden zunächst Mockup-Implementierungen eingesetzt. Um zu einem späteren Zeitpunkt einfach zwischen den Mockup und den richtigen Implementierungen switchen zu können erfolgt die Konfiguration über Spring.

Die nachfolgende Datei (serviceProviderContext.xml) zeigt die Konfiguration der Spring-Beans.

Relativ einfach funktioniert das Laden einer Spring-Konfiguration natürlich "von Hand", wie nachfolgend dargestellt:


public UserSearchService() {
 ClassPathXmlApplicationContext beanFactory = new ClassPathXmlApplicationContext("serviceProviderContext.xml");
 searchService = (SearchService)beanFactory.getBean("searchService");
}

Dass dies nicht besonders schön ist liegt auf der Hand. Werden der Such- und der CMS-Service von mehreren Session-Beans verwendet, dann muss des Weiteren in jeder Session-Bean der Ladevorgang und die Zuweisung erfolgen.

Deshalb stellt sich die Frage, ob dies auch eleganter funktioniert?

Wiring mit Interzeptoren

Mit EJB 3.0 wurden Interzeptoren eingeführt, mit deren Hilfe Spring-Konfiguration geladen werden können. Spring stellt hierfür den SpringBeanAutowiringInterceptor zur Verfügung, der bei Bedarf auch erweitert werden kann. Der Spring-Interzeptor muss hierfür der EJB 3.0 Annotation @Interceptors zugewiesen werden. Das Binding des Interzeptors kann alternativ neben der Annotation @Interceptors auch über den EJB Deployment Descriptor (ejb-jar.xml) vorgenommen werden.

Nachfolgend wird das Binding an den Interzeptor an einer Session-Bean illustriert, die über @Autowiring auch den Such-Service injiziert bekommt.


@Stateless(mappedName = "UserSearchService")
@Interceptors(SpringBeanAutowiringInterceptor.class)
public class UserSearchService implements UserSearchServiceLocal {

 @Autowired
 private SearchService searchService;

 public List getSortFields() {
  return searchService.getSortFields();
 } 
}

Der SpringBeanAutowiringInterceptor erwartet standardmäßig eine Datei mit dem Namen beanRefContext.xml im Klassenpfad. Diese nachfolgend dargestellte Datei verweist wiederum auf die eigentliche Konfigurationsdatei aus der die zu injizierdenden Service-Klassen entnommen werden.

Fazit
In EJB 3.0 können relativ einfach und elegant Spring-Konfiguration geladen und injiziert werden. Der Eintrag sollte dies veranschaulichen, da hierfür nur wenige Beispiele zu finden sind.

Was nutzt das Grails-Framework dem Business?

2010-08-21T19:30:00.006+02:00

In meinem DOAG-Artikel [1] mit dem Thema „Weblogic und Grails“ habe ich diese Thematik vor allem technisch beleuchtet. Natürlich hat das Grails-Framework[2] auch Vorteile für das Business, dies möchte ich kurz in diesem Blog-Eintrag festhalten.

Was macht Software-Projekte so teuer? Oder lohnt sich Software-Entwicklung in Deutschland noch?
Kostentreiber bei Softwareprojekten sind auf der einen Seite nicht klar definierte Anforderungen seitens des Auftraggebers an die Software-Lösung. Auf der anderen Seite sind es technisch verliebte Dienstleister, die gerne komplexe eigene Frameworks beim Kunden einführen wollen. Ein großer Teil des Projektbudgets wird hierbei durch technische Extravaganzen vergeudet (siehe hierzu auch die Glosse von meinem Kollegen [3]). Den Auftraggeber hingegen interessiert eigentlich nur die Umsetzung der fachlichen Anforderungen. Von den großen Dienstleistern wird deshalb, zur Kostenminimierung, Out-Sourcing in Länder mit niedrigeren Lohnkosten als Königsweg favorisiert. Jeder, der beispielsweise schon einmal ein Projekt mit einem indischen Dienstleister durchgeführt hat, weiß, dass diese Projekte (bei der Retrospektive am Projektende) doch nicht so billig sind, wie anfangs angenommen. Ein großes Problem ist hierbei immer die Kommunikation und die unterschiedlichen Kulturen. Des Weiteren wird meistens vergessen, dass die Spezifikationen detailgenauer (im Vergleich zu einem deutschen Dienstleister) sein müssen.

Was könnte nun ein Framework, wie Grails verbessern?
Wir haben die Erfahrung gemacht, dass wir uns beim Einsatz von Grails wieder vor allem auf die fachlichen Anforderungen konzentrieren können. So konnten wir auch feststellen, dass die Sprache Groovy (im Vergleich zu Java) den Entwickler um einiges produktiver macht. Dies bedeutet im Endeffekt, dass wir in der Lage sind, Projekte in kürzerer Zeit zu realisieren. Hieraus resultieren niedrigere Projektkosten für den Auftraggeber.

Fazit
Zuletzt möchte ich dennoch anmerken, dass Grails nicht zwingend für jede Problemstellung Anwendung finden kann. Eine Stärke von Grails ist zweifelsfrei der Ansatz „Convention over Configuration“. Hierbei konnten wir jedoch feststellen, dass dies wiederum hinderlich sein kann, wenn man alle Freiheitsgrade bei der Entwicklung, beispielsweise für das UI eines sehr komplexen transaktionsbasierten Dialogs, benötigt.

[1] WebLogic und Grails DOAG News 02/2010
[2] Grails Framework
[3] Glosse: Spezialisierung ist unnötig – wir können auch alles.

Glosse: Spezialisierung ist unnötig – wir können auch alles.

2010-08-18T09:56:00.004+02:00

Ein klassischer IT Dienstleister kann alles – grundsätzlich. Egal welche Technologie oder Methodik der Kunde nachfragt und sei es noch so exotisch, jeder kann alles. Bei den ganz Großen der Branche könnte man sogar annehmen, dass das tatsächlich stimmt. Irgendwo auf der Welt gibt es sicher einen Mitarbeiter, der sich mit diesem oder jenem beschäftigt hat. Warum also erst nach einem Spezialisten suchen, die großen Anbieter können ja sowieso alles.

Fragt sich nur, ob dieser Mitarbeiter noch in dem Unternehmen ist, und wenn ja, ob er für das anstehende Projekt zur Verfügung steht? Sicherlich mag er mit dem Produkt / der Technologie gearbeitet haben. Doch wie lange ist das her, welche Produktversion war das? Auch wenn das Produkt noch den gleichen Namen hat, aber hat es sich nicht im Laufe der Zeit völlig verändert, andere Funktionen, andere Basistechnologie, anderes Grundkonzept?

Die großen Anbieter der Offshore / Nearshore Szene machen da keine Ausnahme. Auch da wird grundsätzlich genickt, wenn die Frage nach spezifischen Know how kommt. Und wenn das Produkt etwas scheinbar nicht kann, wird einfach etwas dran- oder dazugebaut – das geht alles, kein Problem.

Das ist ein generelles Muster der großen Dienstleister. So ein Produkt hat ja schon so seine Defizite, und ganz schlimm, diese Hersteller-Abhängigkeit. Immer ein gerne genommenes Argument, um möglichst viel selber neu zu bauen, was eigentlich schon an Funktionalität vorhanden ist. Und dann noch ein paar abstrakte Schichten und Layer dazugebaut, mit einem eigenen Framework veredelt. Dann kann man nachher ganz leicht das Produkt mit einem anderen austauschen. Leider ist man dann anstatt vom Hersteller nun vom Dienstleister abhängig. Aber es ist ja immer alles gut dokumentiert, und auf Standards aufgebaut, da ist die Einarbeitung durch einen anderen Dienstleister kein Problem.

Wie, das stimmt alles nicht? Nun ja, sicher ist das alles etwas überzeichnet, aber im Grundsatz läuft das Geschäft genau so ab – das erleben wir als kleiner, spezialisierte Dienstleister immer wieder. Da kommt man oft in die Situation, dass man basierend auf dem vorhandenen Spezialwissen ein extrem gutes Angebot macht. Große Anbieter machen natürlich große Angebote – da müssen ja erheblich mehr Leute ausgelastet werden – und der Kunde reibt sich die Augen. Aber wenn die Großen so große Angebote machen, da hat der Kleine das doch sicher nicht richtig verstanden. Schade…

Warum also das Risiko eingehen, auf einen Kleinen zu setzen? Wenn es beim Großen schiefgeht, lässt sich das ja intern viel besser verkaufen nach dem Motto „Also wenn die das nicht mal geschafft haben…“. Warum der Kleine das eventuell besser macht? Er ist spezialisiert, kennt sich exakt mit dem Produkt / der Technologie aus, über lange Zeit. Er muss nicht eine große Anzahl an Mitarbeitern auslasten und neu einarbeiten, für ihn sind auch kleine Projekte attraktiv. Er will seine Mitarbeiter nicht unbedingt lange in einem Unternehmen mit Wartungsarbeiten binden, um diese frei zu haben für neue Projekte.

Warum wir das hier schreiben? Nein, wir sind nicht frustriert und wir haben auch jede Menge zu tun. Es gibt zum Glück immer noch Kunden, die auch die Zusammenarbeit mit einem kleinen Dienstleister wagen, schätzen und damit erfolgreich sind. Aber es fällt uns immer wieder auf, dass gerade im IT Bereich jeder der Tollste, Größte und Beste ist und insbesondere einfach alles kann.

Aber das ist auf der anderen Seite auch gut, denn das differenziert uns von den anderen. Wir sind da bescheidener. Wir können nicht alles. Wir können wenige Dinge, die aber sehr gut. Wir machen uns tatsächlich viele Gedanken, wie wir das Beste für den Kunden liefern können und Lösungen schaffen, die nachhaltig sind und wirklichen Nutzen stiften. Aber das können die anderen ja alle auch :-) .

RESTful Web Service mit Apache Wink in WebLogic Portal

2010-07-30T09:01:00.014+02:00

Mittlerweile sind für Java einige REST-Frameworks vorhanden zu den bekanntesten zählen sicherlich Jersey [1], Restlet [2], REST in Spring 3 [3] und Apache Wink [4]. All jene Frameworks implementieren die Java API für RESTful Web Services, kurz JAX-RS, welche unter anderem durch Annotation eine einfache Handhabung von Parametern, Pfaden und HTTP-Methoden ermöglicht.

Bei der Entwicklung für WebLogic Portal 10.3.2 ergibt sich das Problem, dass die verwendete Spring-Version REST noch nicht unterstützt. Auch die Frameworks Jersey und Restlet können aufgrund von Inkompatibilitäten mit WebLogic eigenen Bibliotheken nicht ohne weiteres in einem Portal-War eingebunden werden.

Apache Wink stellt als leichtgewichtiges (und darüber hinaus sehr performantes Framework [5]) eine ideale Möglichkeit dar, um innerhalb eines WebLogic Portals REST Web Services zu implementieren. Durch die einfache Integration in Spring kann auch innerhalb des eigens implementierten RESTful Wen Service auf die Vorzüge von Autowiring und ähnlichem zurückgegriffen werden.

Konfiguration
Die nötigen Konfigurationen befinden sich in der web.xml, in welcher der Spring-Context und das Servlet definiert werden.



    org.springframework.web.context.ContextLoaderListener


    contextConfigLocation
    classpath:META-INF/server/wink-core-context.xml
    /WEB-INF/application-context.xml


    restServlet
    org.apache.wink.server.internal.servlet.RestServlet


    restServlet
    /restapi/*

In der Spring-Konfiguration (hier: application-context.xml) muss nur noch die Bean, die die Implementierung des REST Services darstellt, angegeben werden.

Die Service-Klasse könnte wie folgt aussehen:


@Path("exensioService")
@Component
public class ExensioRestService {
    @Autowired
    private exensioTestServiceBusiness exensioTestService;
 
    @GET
    @Produces("text/plain")
    public String getStartingInfo() {
        return "This is an example output if no parameter and no extra path are given. "
    }

    @GET
    @Produces("text/plain")
    @Path("/name/{id}")
    public String getName(@PathParam("id") Long id) {
     return exensioTestService.getNameForId(id);
    }
}

Die Aufrufe dieses Services lauten:
http://host:port/exensioWar/restapi/exensioService/
http://host:port/exensioWar/restapi/exensioService/name/12

Fazit
Apache Wink ist ein einfach zu verwendendes REST-Framework mit JAX-RS und Spring-Unterstützung, welches sich problemlos in Projekten mit WebLogic Server und WebLogic Portal integrieren lässt.

Referenzen:
[1] https://jersey.dev.java.net/
[2] http://www.restlet.org/
[3] http://blog.springsource.com/2009/03/08/rest-in-spring-3-mvc/
[4] http://incubator.apache.org/wink/
[5] http://www.ibm.com/developerworks/web/library/wa-apachewink3/

Query Caching in JPA 1.0 mit EclipseLink

2010-07-30T07:33:00.003+02:00

Überblick Caching

Caching kann ein wichtiger Mechanismus zur Steigerung der Performance einer Software-Applikation sein. Abhängig von der Applikationsart bietet sich Caching insbesondere an, um die Anzahl der Datenbankzugriffe einer Applikation zu reduzieren.

Mit JPA 2.0 (Java Persistence API) wurden einige Möglichkeiten für das Caching standardisiert. Allerdings findet in der Praxis in den meisten Fällen noch die Version 1.0 Verwendung, da die gängigen Applikation-Server die neue JPA-Version oftmals nur in Preview-Releases anbieten.
Aufrund der nur rudimentären Unterstützung von JPA 1.0 für Caching, haben einige JPA-Implementierungen eigene Erweiterungen eingeführt, die über den Standard hinausgehen.

Dies gilt auch für die weit verbreitete Open Source Implementierung EclipseLink [1], die auch wir in einem Projekt einsetzen.

Beispiel für Cache Konfiguration
Die Cache-Definitionen können in EclipseLink in den Dateien persistence.xml, eclipselink-orm.xml sowie an den Entities erfolgen.
Da sich Caching nicht für alle Datenbankobjekte anbietet, ist es in der Regel sinnvoll Caches auf Ebene der einzelnen Entities zu definieren.

In unserem Projekt kommt Caching für einige Konfigurations-Tabellen zum Einsatz auf die lesend zugegriffen wird und die bei Änderungen direkt in der Datenbank manipuliert werden.

Nachfolgend ist die Beispiel-Konfiguration einer Entität aufgeführt:

@Cache(
type=CacheType.SOFT, // Cacheinhalte werden freigegeben, wenn Speicher ausgeht
size=200,            // Maximal 200 Objekte
expiry=600000,       // Gültigkeit von 10 Minuten
)

In der Datei persistence.xml wurden die entsprechenden Einstellungen laut Dokumentation vorgenommen. Die Tests zeigten zunächst, dass der Cache einwandfrei funktionierte und auch korrekt nach der abgelaufenen Zeitspanne invalidiert wurde.
Allerdings stellte sich bei weiteren Tests heraus, dass nicht nur die einzelnen gewünschten Entitäten gecached wurden, sondern alle Entitäten in der Applikation.

Nach einigigen Versuchen und weiteren Tests führte der nachfolgend aufgeführte Auszug der Datei persistence.xml zum Erfolg. Insbesondere musste die Default-Größe für Caches auf 0 gesetzt werden. Außerdem war das Deaktivieren des sogenannten Parent Session Cache für alle Entitäten, die nicht gecacht werden sollen, nötig.


<property name="eclipselink.cache.size.default" value="0">
<property name="eclipselink.cache.shared.default.Person" value="false">
<property name="eclipselink.cache.shared.default.Property" value="true">
<property name="eclipselink.cache.shared.default.Tasks" value="true">

Fazit
Nach einigen Konfigurationsschwierigkeiten funktioniert das Caching mit EclipseLink einwandfrei. Um böse Überraschungen zu vermeiden, empfiehlt es sich wie in unserem Fall das Caching durchgehend zu Testen.

Referenzen:
[1] EclipseLink

SAP EP Integration in das WebLogic Portal mittels WSRP

2010-07-18T17:53:00.003+02:00

In einem aktuellen Projekt sollten SAP HR (Self-Service) IViews - aus dem SAP Enterprise Portal (SAP EP) - mittels „Web Services for Remote Portlets“ (WSRP) [1] in das Oracle WebLogic Portal (WLP) eingebunden werden. Dieser Erfahrungsbericht beschreibt die aufgetretenen Probleme und warum schließlich nur eine Integration mittels IFrame möglich war. Des Weiteren wurde das Open-Source Portal Liferay eingesetzt, da der Oracle Support bei jedem Problem behauptete, dass SAP nicht standardkonform sei.

Probleme beim Oracle WebLogic Portal

Schemadefinitionen innerhalb von wsrp_v1_types.xsd wollte das WLP von w3.org nachladen. In unserem Fall war ein Internetzugriff nur über einen Proxy-Server mittels NTLM-Authentifizierung möglich. Wir konnten dieses Problem mit einem Workaround (lokaler Web-Server mit modifizierter Hosts-Datei) zum Testen umgehen. Das Liferay-Portal zeigte diesen Fehler nicht.
Das SAP Portal fordert beim WSRP Aufruf der Methode getServiceDescription User-Credentials – diese können in der WLP Admin Konsole nicht gesetzt werden, die Möglichkeit dies über die IDE zu machen war buggy. Beim Liferay-Portal war es ohne Probleme möglich, diese Werte in der Admin Konsole zu setzen. Hier die seitens SAP EP angeforderten User-Credentials:
- persistancy_mode_password
- producer_allocated_username
- producer_allocated_password
Um die Komplexität der WSRP Kommunikation zu verringern, wollten wir SAML abstellen, dies war nicht möglich. Weder die Tipps des Oracle Forums noch die des Oracle Supports haben hier geholfen. Das Liferay-Portal funktioniert out-of-the-box ohne SAML.

Probleme beim SAP Portal
Mit Hilfe des Liferay-Portals konnten wir dann das SAP EP testen. Hierbei wurde dann jedoch schnell sichtbar, dass das SAP EP nicht standardkonform ist.

Das SAP EP benutzt massiv IFrames innerhalb von IViews, um z.B. Informationen aus SAP HR darzustellen. Diese IViews waren in unserem Fall als Business Server Pages (BSP) implementiert. Das SAP Portal hat die IFrame Url (im an den Consumer zurückgelieferten Markup) gegen die des Liferay-Portals ausgetauscht. Dies ist bei normalen Urls valide, da diese wieder auf das Consumer-Portal zeigen müssen. Bei einem IFrame ist dies jedoch falsch.
Der nächste Versuch mit einer einfachen Url IView scheiterte daran, dass das SAP EP einen neuen Tag in den an den Consumer zurückgelieferten Markup hinzugefügt hat. Dieses hat jedoch laut [2] dort nichts zu suchen.

Fazit
Die Integration mittels WSRP scheiterte. Bleibt man in der SAP oder Oracle Welt funktioniert alles reibungslos, jedoch wurde WSRP gerade wegen der Interoperabilität entwickelt. Der Support beider Hersteller beschuldigte den anderen, nicht standardkonform zu sein. Vielleicht funktioniert beim SAP EP der Weg über reine Java Portlets (und keine BSPs) besser, wie er vom SAP Support empfohlen wurde. Leider basieren alle unsere zu integrierenden IViews auf BSPs. Wir hätten alles neu schreiben müssen, deshalb war dies keine Lösung innerhalb unseres Projekts. Da die meisten IViews auf BSP basieren ist dies wahrscheinlich auch keine Option bei anderen Projekten. Letztlich blieb nur die Möglichkeit einer Integration per IFrames. Dies war nach ein paar Änderungen am SAP EP möglich, da dies selbst massiv IFrames benutzt.

Referenzen:
[1] WSRP
[2] wsrp_v1_types.xsd

Die Evolution von Portal-Lösungen

2010-07-04T17:06:00.000+02:00

In diesem Blog-Eintrag möchte ich die Entwicklung von Portal-Lösungen aufzeigen. Laut den Analysten der Gartner-Group sieht die chronologische Entwicklung von Portal-Lösungen folgendermaßen aus:

HTML-Seiten – die erste Form von Portalen bestand aus HTML-Seiten, die manuell gepflegt wurden. Zu diesem Zeitpunkt gab es noch keine Content Management Systeme (CMS). Dies stellte noch kein Problem dar, da die anfänglichen Portale nur spärlich Content enthielten.

Content-Portale – mit dem exponentiellen Anstieg von Informationen (Content), die in einem Portal anzeigt werden sollten, stieg der Bedarf nach professionellen Lösungen zum Verwalten von großen Mengen an Content. Als Anbieter sind hier beispielsweise folgende zu nennen: OpenText, Day, RedDot

Applikations-Portale – als nächster Entwicklungsschritt erschienen Applikations-Portale. Diese aggregieren Informationen aus verschiedenen Applikationen. Der Benutzer erhält eine Sicht auf alle für ihn relevanten Informationen. Hier wird oft der Vergleich mit einem Flugzeug-Cockpit benutzt. Heute ist es auch mit Content-Portalen möglich Applikationen zu integrieren, jedoch unterstützen diese meist nur lesende Zugriffe in Portlets. Portlets zeigen hier beispielsweise das Wetter an. Mit Framework-Portalen (Oracle WebLogic Portal, IBM WebSphere Portal oder Liferay Portal) oder Applikations-Portalen (SAP Enterprise Portal, Mircosoft Sharepoint Server, Siebel Portal (nun Oracle), Cognos Portal (nun IBM), SAS Information Delivery Portal) können hier im Gegensatz komplexe Transaktionen mit Backend-Systemen realisiert werden.

Prozess-Portale – dies ist die Königsklasse von Portal-Lösungen. Sie können reinen Content und Applikationen enthalten. Des Weiteren bilden sie auch Unternehmensprozesse ab, beispielsweise einen Einkaufsprozess. Neben der Portal-Lösung wird hier auch eine Integrationskomponente (beispielsweise Enterprise Service Bus - ESB) benötigt, um die Geschäftsprozesse abbilden zu können. War es eine Zeit lang etwas ruhig um Prozess-Portale geworden, so ziehen sie heute - bedingt durch die Hype um serviceorientierte Architekturen (SOA) – wieder vermehrt Aufmerksamkeit auf sich.

HTML5 Überblick

2010-06-02T15:34:00.026+02:00

Was ist HTML5?
HTML5 bringt uns eine neue Generation von Webseiten. Für Web-Entwickler ist die Umstellung vergleichbar wie etwa der Umstieg von HTML-Tabellen zu DIV-Tags.

Die Gruppe WHATWG (Web Hypertext Application Technology Working Group) arbeitet seit 2004 an der Entwicklung dieser Sprache. WHATWG entstand aus Mitarbeitern von Apple, the Mozilla Foundation und Opera Software. Obwohl die Entwicklung an HTML5 erst 2022 abgeschlossen sein soll wird und kann es heute schon verwendet werden.

Wo wird HTML5 bereits heute verwendet?

Youtube und Facebook bieten heute schon die meisten Videos alternativ zu Flash auch per HTML5 an. Sie gehen auf die Bedürfnisse von iPads und iPhones ein, die aus Sicherheits- und Performancegründen ganz auf Flash verzichten.
Ein Beispiel für die Performance von HTML5-Videos gibt es unter http://www.craftymind.com.

Des Weiteren wird HTML5 gerne für Portfolio-Webseiten von Web-Entwicklern verwendet um Ihre Arbeiten darzustellen wie z. B. bei time2project.
Für weitere Beispiele zu den verschiedenen Funktionen und Möglichkeiten sind die folgenden Seiten zu empfehlen:

HTML 5 Showcase

HTML 5 forms Demo

Drag and drop Funktionalität

HTML 5 Geolocation Demo

HTML 5 Canvas Particle

Bei der Frage der Browserabhängingen Unterstützung von HTML5 geht es momentan nicht darum welcher Browser HTML5 unterstützt, sondern welcher Browser welches Element unterstützt. Hierzu gibt es auf http://html5readiness.com/ eine Grafik, die den Fortschritt und die Entwicklung der einzelnen Browser darstellt.

Der Code

Dieses Beispiel zeigt wie einfach die Einbindung eines Videos mit HTML5 funktioniert.

HTML 4.01

HTML5

Nachfolgend sind die nicht mehr verfügbaren sowie die neu hinzugekommenen HTML-Elementen aufgeführt.

Liste von HTML Tags die es nicht mehr geben wird:

<acronym> Tag

Der <acronym> Tag wurde verwendet, um Abkürzungen in HTML 4 zu definieren. Ein Akronym wird wie ein Wort ausgesprochen, z. B. NATO, NASA, ASAP, GUI waren.

<applet> Tag

Der <applet> Tag wurde verwendet, um ein eingebettetes Applet zu definieren. Sie können nun <OBJECT> stattdessen verwenden.

<basefont> Tag

Der <basefont> Tag wurde verwendet, um eine Standard-Schriftart, Schriftfarbe oder Schriftgröße für den gesamten Text in einem Dokument zu definieren. Dies wird nun per CSS gesteuert.

<big> Tag

Der <big> Tag wurde verwendet, um Text zu vergrößern.

<center> Tag

Die <center> Tag wurde zur mittigen Ausrichtung von Text und Inhalt verwendet. Wird nun auch im CSS definiert.

<dir> Tag

Die <dir> Tag wurde verwendet, um eine Verzeichnis-Liste zu definieren. Ist aber mit <ol> und <ul> Tags genauso möglich.

<font> Tag

Der <font> Tag wurde verwendet, um Schriftart, Schriftgröße und die Schriftfarbe des Textes zu definieren. Er gehörte zu den am häufigsten verwendeten Tags in HTML 4. Wird in Zukunft auch nur noch über das CSS gesteuert.

<frame>, <frameset> und <noframes> Tags

Da in HTML5 keine Framesets mehr unterstützt, wird es diese Tags nicht mehr geben. Mit dem Ziel, die Benutzerfreundlichkeit zu verbessern. Framesets erschweren zugleich die Suchmaschinenoptimierung (SEO) .

Der <s> und <strike> Tag wurde verwendet, um durchgestrichenen Text darzustellen. Dies kann mittels <del> oder über das CSS genauso erfolgen.

<tt> Tag

Das TT-Element bewirkte, dass der Text als Teletype oder monospaced Text dargestellt wurde.

<u> Tag

Der <u> Tag wurde verwendet, um Text zu unterstrichenen. Wird nun ebenfalls über das CSS ermöglicht.

<xmp> Tag

<xmp> war einmal als logische Auszeichnung für Quellcode-Beispiele gedacht.

Diese Liste zeigt die neuen HTML5 Tags.

<article> Tag

Der Tag definiert externen Inhalt. Die externen Inhalte könnten von einem News-Artikel, Weblog (Blog), Forum oder jeglicher anderen externen Quelle herstammen.

<aside> Tag

Dieser Tag definiert Inhalt welcher neben solchen platziert wird. Es wäre ein geeigneter Container um z. B. die Navigation neben den Content Bereich einzufügen.

<audio> Tag

Der Tag definiert Klang wie Musik oder andere Audio-Streams.

<canvas> Tag

Der <canvas> Tag wird verwendet, um Grafiken anzuzeigen. Er ist nur ein Container für Grafiken. um Grafiken zu malen muss Javascript verwendet werden.

<command> Tag

Der <command> Tag definiert eine Befehlsschaltfläche, wie einen Radiobutton, ein Kontrollkästchen oder einen Submit-Button. Der Befehl muss in ein Menü-Element sein. Wenn er dies nicht ist, wird er nicht angezeigt.

<datalist> Tag

Der <datalist> Tag definiert eine Liste von Optionen welcher in Verwendung mit dem input-Element den Value definiert. Das DataList Element und seine Optionen werden nicht angezeigt.

<details> Tag
Der <details> Tag dient dazu, Informationen über ein Dokument oder Teile eines Dokuments zu beschreiben.

<embed> Tag

Der <embed> Tag definiert eingebetteten Inhalt wie z. B. ein Plug-in.

<figcaption> Tag

Der <figcaption> Tag enthält eine Information für das "Figur"-Element. Das "figcaption" Element sollte als das erste oder das letzte Kind der "Figur"-Element platziert werden.

<figure> Tag

Der Tagdient zum gruppieren von Elemente. Der Inhalt innerhalb eines Figurenelements ist Stand-alone-Inhalt. Üblicherweise wird es verwendet, um Teile eines Dokuments zu erklären. Kann allerdings auch außerhalb des zu erklärenden Dokuments platziert werden.

<footer> Tag

Der <footer> Tag definiert den Footer eines Abschnitts oder eines Dokuments.

<header> Tag

Der <header> Tag definiert eine Einführung in das Dokument.

<hgroup> Tag

Der <hgroup> Tag definiert die Überschrift eines Abschnitts oder eines Dokuments. Das hgroup Element gruppiert Überschriften wie z. B. <h1> <h6>

<keygen> Tag

Der <keygen> Tag definiert einen generierten Schlüssel.

<mark> Tag

Der <mark> Tag definiert markierten Text. Verwenden Sie den <mark> Tag um Teile Ihres Textes hervorzuheben.

<meter> Tag

Der <meter> Tag definiert eine Messung. Wird nur für Messungen mit einem bekannten minimalen und maximalen Wert benutzt.

<nav> Tag

Der <nav> Tag definiert einen Bereich der Navigation.

<output> Tag

Der <output> Tag definiert verschiedene Typen von Ausgaben wie z. B. die Ausgabe von einem Skript

<progress> Tag

Die <progress> Tag definiert work-in-progress. Verwenden Sie das Fortschritt Element, um den Fortschritt einer aufwendigen JavaScript-Funktion anzuzeigen.

<rp> Tag

Der <rp> Tag ist in Ruby Annotationen benutzt, um festzulegen, was Browser, die keine Unterstützung des Ruby-Elementes haben darstellen sollen. Ein Ruby Annotation sind chinesischen Schriften oder Buchstaben, welche in Ostasien verwendet werden um die Aussprache der ostasiatische Zeichen zu verdeutlichen.

<rt> Tag

Der <rt> Tag definiert eine Erklärung oder die Aussprache der Zeichen (Chinesische Schrift oder Zeichen). Gebraucht in Ostasien, um die Aussprache der ostasiatischen Zeichen zu zeigen.

<ruby> Tag

Der <ruby> Tag definiert eine Ruby Annotation (Chinese Schrift oder Zeichen). Gebraucht in Ostasien, um die Aussprache der ostasiatische Zeichen zu zeigen. Benutze ihn zusammen mit dem <rt> und / oder die <rp> tags. Das Ruby-Element besteht aus einem oder mehreren Zeichen (welche Information zu Bedeutung / Aussprache benötigt), und ein rt-Element, dass diese Informationen darstellt.Gegebenenfalls noch ein rp-Element um Browsern, die keine Unterstützung des "Ruby" Tags besitzen Alternatives anzuzeigen.

<section> Tag

Der <section> Tag definiert Abschnitte in einem Dokument. Wie z. B. chapters, headers, footers oder jedes weiteren Abschnitts des Dokumentes.

<source> Tag

Der <source> Tag definiert Medien Quellen wie z. B. <video> und <audio>.

<summary> Tag

Der <summary> Tag ist einen Header für das "Details"-Element. Es wird verwendet um weitere Informationen über ein Dokument oder Teile eines Dokuments zu beschreiben.

<time> Tag

Der <time> Tag definiert eine Zeit oder ein Datum, oder beides.

<video> Tag

Der <video> Tag definiert Video, wie z. B. einen Movieclip oder andere Video-Streams.

Fazit

Die Entwicklung und Durchsetzung von HTML5 wird sicherlich dadurch bedingt wie sich die Entwickler-Community diese Themas annimmt und wie die Benutzer es verwenden. Stärker ist es allerdings davon abhängig wie die marktführenden Firmen wie Microsoft, Google und Apple mit Ihren unterschiedlichen Plattformen darauf reagieren. Die Tendenz geht eindeutig in eine positive Richtung. Es gibt mittlerweile auch schon Skripte, die das Ausführen von HTML5 im IE6-IE8 ermöglichen.
Was den vielerorts diskutierte Vergleich von Flash und HTML5 anbelangt, so finde ich diesen unnötig. Flash hat sich in den letzten Jahren zusätzlich mit dem Flashdeveloper in die Entwicklung von Desktopapplikationen entwickelt und HTML5 kann mit seinen SVG-Zeichenfunktionen noch lange nicht an komplexe Flashanimationen ersetzen. Beide Technologien werden sich Ihre Gebiete abstecken und nach Plattform und Funktionalität eingesetzt werden.

Zurücksetzen des Administrator-Passworts für den WebLogic Server

2010-05-11T07:51:00.006+02:00

Problem
Jeder ist wahrscheinlich schon einmal in die Situation geraten das Passwort für einen Account oder eine Applikation vergessen zu haben. Genau dieser Fall ist bei einem unserer Kunden aufgetreten. Niemand konnte sich mehr an das Administrator-Passwort für den WebLogic Server erinnern und auch das Ausprobieren der vermuteten Passwörter führte nicht zum Ziel. Was kann man hier tun?
Alle Anwesenden waren sich einig, dass es aus Sicherheitsgründen keine Möglichkeiten für das Zurücksetzen des Passwortes gibt.

Lösung
Da schon einige Zeit in das Anlegen und Anpassen der Domaine investiert wurde, wollte man sich aber auch nicht kampflos geschlagen geben. Nach etwas Recherche stellte sich heraus, dass es tatsächlich eine einfache Möglichkeit zum Zurücksetzen des Passwortes im Weblogic Server gibt. Hierfür sind folgende Schritte notwendig:

Sicherung der Datei DefaultAuthenticatorInit.ldift im Verzeichnis security der Domaine.
Öffnen einer Konsole und setzen der Umgebungs-Variablen für den Weblogic-Server durch Ausführen der Datei setDomainEnv.sh bzw. setDomainEnv.cmd.
Danach den folgenden abgebildeten Befehl in der Konsole ausführen:
Zu guter Letzt muss noch das Verzeichnis data unterhalb des Admin-Servers umbenannt werden. Es wird beim Serverstart wieder neu erstellt.

Das anschließende Hochfahren des Servers funktioniert problemlos. Der Reset erfolgte mit der WebLogic Server Version 11gR1. Ob dieser Trick auch für ältere Server-Versionen funktioniert ist auszuprobieren.

Fazit
Es existiert eine einfache Möglichkeit zum Zurücksetzen des Administrator Passworts für den WebLogic Server. Im Falle unseres Kunden ersparte dies einiges an Arbeit. Trotzdem darf die Frage gestellt werden, ob solch eine Möglichkeit auch sinnvoll ist?
Hat beispielsweise jemand böse Absichten und kommt durch eine Sicherheitslücke auf den physikalischen Server, dann ist es für diejenige Person unter Umständen auch relativ einfach den dort installierten WebLogic Server unter seine Kontrolle zu bekommen.

Klassifikation von Portal-Lösungen

2010-05-09T19:22:00.006+02:00

Portal-Lösungen gibt es wie Sand am Meer. Jeder Hersteller hat mindestens eine Portal-Lösung im Portfolio und jede Web Applikation, die über ein Login verfügt, wird umgangssprachlich als Portal bezeichnet. Aber was ist eigentlich der Unterschied zwischen einem SAP Portal und Spiegel-Online?

Die Portal-Historie
Das Portal, wie wir es heute kennen, wurde ursprünglich von Yahoo entwickelt. Bedingt durch den immensen Anstieg von Informationen auf den Yahoo-Seiten, sah man sich gezwungen neue Wege zu beschreiten. Hierbei entstand eine der wichtigsten Portalfunktionalitäten, die Personalisierung. Mussten früher Yahoo-Nutzer beispielsweise ihre Wetter-Seite mühsam suchen, so konnte der Benutzer später Präferenzen setzen. Der erste Schritt, der stetig steigenden Informationsüberflutung Herr zu werden. Portale werden oft auch mit einem Flugzeug-Cockpit verglichen. So erhält ein Mitarbeiter alle wichtigen Informationen auf einen Blick und muss sich nicht erst in verschiedene Applikationen einloggen.

Klassifikation
Hilfreich ist hier eine Klassifikation des Portal-Markts, wie sie beispielsweise von der Gartner Group erstellt wurde. Die Gartner Group unterscheidet Portal-Lösungen folgendermaßen:

Framework-Portale, z.B. Oracle WebLogic Portal, IBM WebSphere Portal oder Liferay Portal
Applikations-Portale, z.B. SAP Enterprise Portal, Mircosoft Sharepoint Server, Siebel Portal (nun Oracle), Cognos Portal (nun IBM), SAS Information Delivery Portal, ….
Content-Portale, z.B. OpenText, Day, RedDot

Die meisten Angebote finden sich im Bereich der Applikations-Portale, sprich jeder Hersteller bezeichnet sein User-Interface als Portal – dies macht den Markt so unübersichtlich. Wofür eigenen sich nun die Portal-Lösungen am besten?

Framework-Portale
Diese verfügen über eine eigene Entwicklungsumgebung und bieten die meisten Freiheitsgrade für die Entwicklung an. Sie eignen sich besonders gut, um einen heterogenen Zoo von Backend-Systemen in ein Portal einzubinden. Nachteil ist hier, dass man alles selber entwickeln muss – was jedoch meistens durch eine sehr gute Entwicklungsumgebung stark vereinfacht wird.

Applikations-Portale
Diese können besonders einfach die Applikationen desselben Herstellers integrieren. Leider ist es nicht so einfach, eine heterogene Landschaft zu integrieren. Diese dienen meist als User-Interface zu den verschiedenen Applikationen. Wird innerhalb eines Unternehmens beispielsweise nur SAP eingesetzt, so kann hier schon das SAP Enterprise Portal ausreichen.

Content-Portale
Diese eignen sich besonders gut, um Content redaktionell verarbeiten zu können. Die Integration von Applikationen bzw. Prozessen über verschiedene Backend-Systeme ist mit Content-Portalen jedoch nicht so einfach. Aus diesem Grund wird hier meistens eine Integrationsschicht vor das Portal gehängt, die im eigentlichen Sinn die Funktionalitäten eines Framework-Portals abdeckt.

Fazit
Ich hoffe, dass mit Hilfe dieser Klassifizierung von Gartner das Einordnen der unterschiedlichen Lösungen etwas einfacher fällt. Eine pauschale Aussage, wofür man welches Portal nehmen soll, kann jedoch nicht getroffen werden.

Übernehmen von Konfigurationen im WebLogic Portal durch Propagierung

2010-05-01T16:41:00.012+02:00

Das Oracle WebLogic Portal bietet zahlreiche Konfigurationsmöglichkeiten über die Administrationskonsole. Neben der Erstellung des Streaming-Portals werden dort unter anderem auch Portlet-Eigenschaften, der Seitenaufbau des Portals oder auch Berechtigungen definiert. Des Weiteren wird das integrierte CMS-System hierüber administriert.

Bei Software-Projekten werden in der Regel mehrere Umgebungen für die Durchführung benötigt (z.B. Produktions-, Wartungs- und Test-Umgebung). Da es sehr aufwändig und auch fehleranfällig ist die ganzen Konfigurationen des Portals in jeder Umgebung von Neuem zu erstellen, stellt sich die Frage wie Einstellungen und CMS-Inhalte von Umgebung zu Umgebung übertragen werden können.

Die Lösung hierfür ist die Verwendung der in der Entwicklungsumgebung (Workshop bzw. OEPE) mitgelieferten Propagierungs-Werkzeuge. Die Funktionsweise der Propagierung ist ausführlich auf den Seiten zur Portal-Dokumentation beschrieben [1]. Neben der kompletten Übernahme von Konfigurationen bei Neuanlagen sind auch Merges möglich. Die folgende Grafik zeigt einen Ausschnitt einer Merge-Session.

Beispiel einer Merge-Session

Leider kann es vorkommen, dass in der Zielumgebung nicht alles aktualisiert wird, obwohl die Einträge in der Merge-Session, wie in obiger Grafik zu sehen, entsprechend für ein „Update“ markiert wurden. Da auch das mehrfache Durchführen der Propagierung nicht hilft bleibt nur der Griff in die Datenbank des Portals übrig.

Konkret ist dieses Problem bei unseren Projekten schon mehrfach beim Versuch der Aktualisierung des Benutzer-Profils (UUP) aufgetreten. In der entsprechenden XML-Datei für das Benutzerprofil können Attribute, wie bspw. Abteilung definiert werden. Wenn jetzt zwischen zwei Releases ein neues Attribut hinzukommt tritt genau der Fall der notwendigen Aktualisierung auf. Mit etwas Kenntnis im Portalschema findet man heraus, dass in der Tabelle DATA_SYNC_ITEM die komplette XML-Datei als BLOB-Wert abgespeichert wird. Durch Austausch des BLOB-Wertes mit der neuen XML-Datei ist das aktualisierte Benutzer-Profil auch auf der Zielumgebung zur Verfügung.

Differenz einer UUP-Datei zwischen Quell- und Zielsystem, die nicht übernommen wird

Referenzen:
[1] http://download.oracle.com/docs/cd/E13155_01/wlp/docs103/prodOps/propTool.html

Volltextsuche mit der Open-Source-Lösung Compass Search im Cluster

2010-04-26T10:36:00.028+02:00

Wer sich mit Suchmaschinen für eigene Projekte beschäftigt, stößt zweifellos früher oder später auf Apache Lucene. Lucene ist eine Suchmaschinen-Bibliothek, die mit einer beeindruckenden Funktionsvielfalt ausgestattet ist. Sie ist in Java geschrieben, mittlerweile aber auch für viele andere Programmiersprachen verfügbar.

In diesem Eintrag geht es um die Einbindung einer Suche in ein WebLogic Portal Projekt, welches in einem Cluster auf WebLogic Servern läuft. Als Datenbank-Persistenzschicht wird Hibernate eingesetzt. Die Suche soll dabei Entitäten und deren Relationen erfassen und Funktionen wie unter anderem unscharfe Suche und boolesche Operatoren unterstützen und dabei einen gutes Ranking der Ergebnisse liefern.

Durchsuchen und Indizieren von Entitäten mit Relationen

In diesem Beispiel geht es um eine Applikation, mit der Projekte verwaltet werden können. Im vereinfachten Beispiel soll davon ausgegangen werden, dass es lediglich die Entität Project mit einigen Attributen sowie die Entität User mit einigen Attributen gibt. Dabei besteht zwischen Project und User folgende Relation: Ein Projekt ist immer einem User zugeordnet, ein User kann jedoch auch mehreren Projekten zugeordnet sein.

Bei der Suche soll dabei der Titel des Projekts, die Beschreibung des Projekts und der Vor- und Zuname des zugeordneten Autors (Entität User) durchsucht werden können.

Die folgende Abbildung zeigt die Entitäten und die vorherrschende Beziehung:

Das Framework Compass

Compass Search ist ein Framework, welches auf Lucene setzt und eine einfache (Java) API für Suche und Indizierung anbietet. Darüber hinaus lässt sich mit Compass Search die Suche direkt mit Hibernate und entsprechenden Annotationen in ein Projekt einbinden. Mit Compass Search besteht außerdem die Möglichkeit, den Suchindex über JDBC in einer relationalen Datenbank abzuspeichern. Letzteres ist mit Hibernate Search, einem Projekt, das einen ähnlichen Ansatz wie Compass Search verfolgt, nicht möglich, was den Einsatz bei Applikationen, die in einem Cluster laufen, ausschließt.

Damit Compass Search verwendet werden kann, muss es in das Projekt eingebunden werden. In erster Linie geht es dabei um das Hinzufügen der entsprechenden Jar-Dateien in den Classpath. Der Download mit Installationsanleitung findet sich auf der offiziellen Webseite von Compass Search.

Für unser Beispiel sieht die Konfiguration in der compass.cfg.xml, die im Classpath der Applikation liegt, wie folgt aus:

<compass-core-config xmlns="http://www.compass-project.org/schema/core-config"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.compass-project.org/schema/core-config
http://www.compass-project.org/schema/compass-core-config-2.2.xsd">

<compass name="default">
<connection>
<jdbc dialect="org.apache.lucene.store.jdbc.dialect.OracleDialect" managed="true">
<dataSourceProvider>
<jndi lookup="exensioExampleJndiDataSource" />
</dataSourceProvider>
</jdbc>
</connection>

<transaction factory="org.compass.core.transaction.JTASyncTransactionFactory" commitBeforeCompletion="true" lockPollInterval="200" lockTimeout="30">
</transaction>

<searchEngine>
<optimizer schedule="false" />
</searchEngine>

<mappings>
<class name="com.exensio.examples.persistence.entity.Project" />
<class name="com.exensio.examples.persistence.entity.User" />
</mappings>
</compass>

</compass-core-config>

Im ersten Abschnitt wird die Verbindung zur Datenbank definiert. In diesem Beispiel greifen wir auf eine im WebLogic Server definierte JNDI Datenquelle zurück. An dieser Stelle könnten auch direkt JDBC-Daten mit Benutzer und Passwort angegeben werden, was jedoch aus Performance-Gründen nicht zu empfehlen ist.

Eine weitere interessante Konfiguration ist das Mapping am Ende, bei welchem die Entitäten angegeben werden müssen, die Compass-Annotationen enthalten und bei der Suche betrachtet werden sollen.

Die Annotationen in den Java-Dateien sehen wie folgt aus und sind selbstklärend. Eine Übersicht über die vorhandenen Annotationen findet sich in der Dokumentation unter Kapitel 6 "OSEM - Object/Search Engine Mapping".

Aus Übersichtsgründen sind nur Teile der Entitäten angegeben.

Project.java

@Entity
@Searchable
public class Project implements IProject {
@Id
@SearchableId
private Long id;

@ManyToOne(fetch = FetchType.LAZY)
@SearchableComponent(prefix = "user_")
private User user;

@SearchableProperty(boost = 2.0f)
private String title;

@SearchableProperty
private String description;

// Getter and Setter will stay unmodified
}

User.java

@Searchable(root=false)
public class User {
@Id
@SearchableId
private Long id;

@SearchableProperty
private String firstname;

@SearchableProperty
private String lastname;

// Getter and Setter will stay unmodified
}

Wichtig ist die Annotation Searchable, bei der über die Eigenschaft root angegeben wird, welche Klasse die Wurzelentität darstellt.

Indizieren

Damit später auch etwas gefunden werden kann, müssen die Daten noch indiziert werden. Compass Search bietet die Möglichkeit über Hibernate Events bei jedem Schreibzugriff automatisch die neuen Werte zu indizieren bzw. alte Werte zu löschen. Die entsprechenden Listener müssen in der Compass Konfiguration angegeben werden.

Da in diesem Beispiel jedoch das programmatische Indizieren gezeigt werden soll, wird auf die automatische Indizierung nun nicht weiter eingegangen. Die nötige Konfiguration ist in dieser Dokumentation gut beschrieben.

// Load compass configuration
CompassConfiguration conf = new CompassConfiguration();
URL cfg = getClass().getClassLoader().getResource("compass.cfg.xml");
conf.configure(cfg);
compass = conf.buildCompass();

// Get a compass session
CompassSession compassSession = compass.openSession();

// Start with getting all projects
List<project> projects = exensioCompassExampleService.getAllProjects();

// Begin the compass transaction block
CompassTransaction compassTransaction = null;
try {
compassTransaction = compassSession.beginTransaction();

// Iterate through the list of projects
Project p = null;
for (int i = 0; i < projects.size(); i++) {
p = projects.get(i);

// Save annotated project to the index
compassSession.save(p);

// Commit with the specified commit interval or if at
// the end of the project list
if (((i % transactionCommitInterval) == 0) || (i == (projects.size() - 1))) {
compassTransaction.commit();
}
}

// Start optimizing
compass.getSearchEngineOptimizer().optimize();
} catch (CompassException ex) {
if (compassTransaction != null) {
compassTransaction.rollback();
logger.error("Compass Indexer: Had to rollback the Compass transaction because of a Compass exception.",ex);
} else {
logger.error("Compass Indexer: Compass exception (compass transaction is null)",ex);
}
} finally {
compassSession.close();
}

Suchen

Ähnlich einfach wie das Indizieren ist das Suchen. Der Aufruf dazu lautet:

CompassHits hits = session.find(searchString);

Anwendungsbeispiele

Mit Compass und Lucene können komplexe sowie gezielte Suchanfragen abgeschickt werden. Eine Suche nach description:"exensio GmbH integriert Compass Search" würde all jene Projekte als Resultat liefern, die in der Beschreibung den Text "exensio GmbH integriert Compass Search" haben. Nach dem Nachnamen eines Autors kann über das in der Annotation angegebene Präfix gesucht werden: user_lastname:Schmidt

Per Standardeinstellung durchsucht Compass alle Felder, so dass eine Suche nach exensio auf alle indizierten Attribute geht. In unserem Fall würde das Vorkommen von exensio im Titel eines Projekts jedoch höher bewertet werden (boost-Eigenschaft in der Annotation, siehe oben) und dadurch jene Projekte zuerst in der Ergebnismenge zurückliefern.

Fazit

Mit dem Compass Search Framework kann auf einfache Weise eine funktionsreiche und performante Suche in kleine sowie große Applikationen integriert werden. Beim Speichern des Indexes kann entweder das Dateisystem oder eine Datenbank benutzt werden, was somit den Betrieb im Cluster ermöglicht. Auch die Integration in JVM-nahe Cluster-Software wie Terracotta ist möglich.

Wenn gewünscht kann das Indizieren im Hintergrund über Hibernate Listener integriert werden, so dass es keine Verzögerung zwischen Suchresultaten und den tatsächlich vorhandenen Daten in der Applikation gibt.

Über die Einbindung von Apache Tika können nicht nur reine Texte sondern auch viele gängige Dateiformate indiziert werden. Dazu zählen beispielsweise diverse Office-Formate wie Microsoft Word, Excel und Powerpoint sowie Adobe PDF.

User-Interface-Design mit Wireframes

2010-04-24T15:46:00.003+02:00

In einer fachlichen Spezifikation ist das geschriebene Wort – wie auch in anderen Bereichen – dehnbar. Aus diesem Grund wird in Spezifikationen gerne visualisiert, beispielsweise durch den Einsatz von UML. Für die Beschreibung von User Interfaces (UI) bietet es sich hier an, die Spezifikation mit Grafiken anzureichern. Für die Erstellung dieser UI-Grafiken wird gerne Photoshop benutzt. Dies hat jedoch zum einen den Nachteil, dass dies sehr aufwändig sein kann und zum anderen wird gerne zunächst die Ästhetik diskutiert. Wir alle kennen die Aussage „die Farben gefallen mir aber noch nicht so sehr“ obwohl in diesem frühen Stadium zuerst das Fachliche geklärt werden sollte. Aus diesem Grund benutzen wir bei exensio zuerst Wireframes. Diese werden dann – wenn die fachlichen Fragen in Bezug auf das UI geklärt sind – mittels Photoshop reingezeichnet bzw. als HTML Prototyp umgesetzt.
Was sind Wireframes?
Ein Wireframe ist die konzeptionelle Darstellung eines UI-Prototypen. Diese werden bewusst in schwarzweiß gehalten, um ästhetische Fragen zu unterbinden. Wireframes können per Hand oder toolunterstützt gezeichnet werden. Wir bei exensio benutzen hierzu das Tool Balsamiq Mockups [1]. Es erlaubt die Gestaltung von sehr komplexen UIs mit einer einfachen und intuitiven Oberfläche. Das Bild unten zeigt ein Beispiel.

Referenzen
[1] Balsamiq Mockups

Content Modellierung

2010-04-23T17:44:00.014+02:00

Eines unserer Kernthemen ist die Konzeption und Umsetzung von Informationsportalen. Wie der Name bereits sagt, stellen Informationsportale Informationen aus verschiedensten Quellen dem Anwender zur Verfügung. Das Besondere dabei ist die Personalisierung. Informationen werden anhand des individuellen Bedarfs eines Benutzers zur Verfügung gestellt. D.h. nicht mehr der Benutzer sucht nach den für ihn geeigneten Informationen sondern Informationen, die für den Benutzer wichtig sind, werden ihm einfach zugänglich zur Verfügung gestellt. Anhand des Benutzerprofils werden die relevanten Informationen aus den verschiedenen Informationsquellen zusammengestellt und dem Benutzer angeboten. Damit das ganze auch funktioniert, sind verschiedene Dinge erforderlich. Neben dem bereits genannten Benutzerprofil mit den Stammdaten und Interessengebieten des Benutzers ist es dringend erforderlich, dass die Informationen in strukturierter Form zur Verfügung stehen. Diese Strukturierung ist bereits in der Konzeptionsphase zu erarbeiten. Wir nennen die dafür notwendige Aktivität Content Modellierung.

Was ist Content Modellierung?
Content Modellierung dient der Strukturierung und Kategorisierung der Informationen, die im Portal darzustellen sind. Ähnlich einem Datenmodell für eine Applikation werden die Informationen für das Portal modelliert. Ein solches Modell besteht aus Content Typen und deren Beziehungen. Beispielsweise kann es einen Content Typ Nachricht geben. Ein solcher Content Typ wird durch Metaattribute und Attribute beschrieben. Metaattribute enthalten Daten über Daten, d.h. sie beschreiben den Content. Beispielsweise sind der Autor, das Erstellungsdatum oder die Keywords klassische Metadaten. Attribute hingegen enthalten die eigentlichen Informationen. Im Falle des Content Typs Nachricht könnten dies die Attribute Titel, Untertitel, Text, Referenzen und Kontakt sein. Aus den Content Typen und deren Beziehungen ergibt sich dann das Content Modell. Dinge wie Vererbung und Spezialisierung, die man aus der objektorientierten Modellierung kennt, finden auch hier ihre Anwendung - zumindest für das fachliche Modell. So könnte beispielsweise der Content Typ Nachricht noch Spezialisierungen haben wie Rundschreiben oder Pressemeldung.

Wozu dient diese Modellierung?
Auf Basis der Attribute (und auch Metadaten) können zum einen Informationen gezielt ermittelt und dem Benutzer zur Verfügung gestellt werden. Beispielsweise können einem Mitarbeiter, der einem bestimmten Standort zugeordnet ist, auch nur die Standort-relevanten Nachrichten angzeigt werden. Zum anderen können durch die Strukturierung auch Teile der Informationen zur Verfügung gestellt werden. So ist es eventuell erforderlich, auf der Startseite des Portals, lediglich die Titel und die Zusammenfassung der Nachricht darzustellen. Liegen diese Information nicht strukturiert in separaten Attributen vor, wäre dies nicht möglich.
Wie auch bei der Datenmodellierung gilt es bei der Content Modellierung, Mass zu halten. Es muss nicht zwanghaft alles strukturiert abgebildet werden. Die Notwendigkeit besteht dann, wenn entweder Informationen personalisiert oder auszugsweise dargestellt werden sollen. Auch Aspekte der Content Wiederverwendung spielen eine Rolle. So kann beispielsweise strukturierte Information über Produkte an den verschiedensten Stellen wiederverwendet werden - sei es als Überblicksinformation auf den Webseiten oder mehr detaillierte Informationen auf den internen Marketingseiten oder im Bereich Vertrieb.

Beispiel Content Model

Wer sich weiter für das Thema Modellierung und Strukturierung von Informationen interessiert, dem empfehle ich das Studium des Buches "Single Source Publishing" von Sissi Closs [1]. Die Zielrichtung geht zwar eher in die Richtung des Publizierens von Dokumentationen - man erhält aber einige Anregungen, die sich direkt auf das Thema Content Modellierung für Informationsportale abbilden lassen.

Referenzen:
[1] Buch "Single Source Publishing" von Sissi Closs

JRockit und fragmentierter Heap

2010-04-18T19:24:00.008+02:00

Der Heap in einer JVM fragmentiert durch das Allokieren von Speicher für Objekte von unterschiedlicher Größe und Lebenszeit. Besonders problematisch ist dies beim Hochladen von großen Dateien. Sichtbar wird dies durch folgenden Logfile-Eintrag:

java.lang.OutOfMemoryError: allocLargeObjectOrArray - Object size: 262160, Num elements: 262144

In diesem Fall wurde vergeblich versucht 262160 Byte zu allokieren.
Was kann man tun?
Unter [1] findet sich eine wertvolle Anleitung. Hier die Infos, was wir gemacht haben:

Heapsize anpassen, ich bin jedoch kein Freund eines zu großen Heaps, da dies sehr lange GC Zyklen zur Folge hat. Es ist meistens besser in einem Cluster einen weiteren WebLogic Server hinzuzufügen, als den Heap zu groß zu wählen. Wir haben folgende Settings gewählt: -Xms1356m –Xmx1356m
Um sicherzustellen, dass der WebLogic Server Nodemanager die JRockit automatisch bei einem OutOfMemoryError starten kann, haben wir den Schalter –XxexitOnOutOfMemory benutzt. Hierbei bendet sich die Jrockit automatisch und läuft nicht in einem halbtoten Zustand weiter.
Um die GC überwachen zu können haben wir diesen Schalter hinzugefügt -Xverbose:gcpause
Ein weiterer wichtiger Parameter ist die Verdichtung des freien Heaps, sprich eine Defragmentierung. Hierbei sollte vorsichtig vorgegangen werden. Wir haben uns für folgenden Wert entschieden: -XXcompactratio=10
Des Weiteren haben wir noch die Generational GC mit -Xgc:gencon gesetzt.

Hier die gesamte Parameterliste:

-Xms1356m –Xmx1356m -Xgc:gencon –XxexitOnOutOfMemory -Xverbose:gcpause

Noch eine Anmerkung zur Heapsize. In unserem Fall handelte es sich um einen Windows 2003 Server mit 16GByte Memory und eingeschalteter (Physical Address Extension)PAE .
Unter [2] findet sich eine interessante Info bzgl. Speicherverfügbarkeit von JRockit unter Windows mit PAE. JRockit hat hier gegenüber der Sun JVM den Vorteil, dass der Speicher nicht zusammenhängend sein muss. Jedoch muss hier beachtet werden, dass in einem JRockit Prozess auch etwaige DLLs von nativen Java Bibliotheken (z.B. SAPJco oder Documentum) liegen. Dies war bei uns der Fall.

Referenzen:
[1]Repost: Tips and tricks for dealing with a fragmented Java heap
[2]Repost: How to get (almost) 3 GB heap on Windows!

WebLogic Portal 10.3.2 und Java Server Faces (JSF)

2010-04-18T15:34:00.015+02:00

Es hat sich herumgesprochen, dass Oracle das Apache Beehive Framework nicht länger unterstützen wird. Die Entwicklung von Portlets soll nun mittels JSF realisiert werden. Aktuell wird jedoch nur die SUN JSF Referenz-Implementierung von Oracle unterstützt. Siehe [1].

Dies ist verständlich, da es sehr viele JSF Frameworks auf dem Markt gibt. Es sind jedoch vor allem die auf Ajax basierenden Frameworks, wie ICEfaces oder ADF Faces, die den Einsatz von JSF reizvoll erscheinen lassen. Wie sieht es mit der Integration solcher Frameworks in das WebLogic Portal aus?
Ist ICEfaces oder ADF Faces im WebLogic Portal möglich?
Der Einsatz von ICEfaces oder ADF Faces für eine reine Web Applikation ohne WebLogic Portal ist ohne Probleme möglich. Werden diese Frameworks im WebLogic Portal benutzt, wird die Angelegenheit jedoch etwas komplexer. In WebLogic Portal 10.3.2 wird (per default) ein JSF 1.2 Portlet mittels der JSR 329 Faces Portlet Bridge in ein JSR 286 konformes Portlet gewandelt. Bei ICEfaces ist hier z.B. das Problem, dass die ICEfaces Bridge nicht durch eine andere JSF Bridge (z.B. JSR 329 Bridge) ersetzt werden kann. Ich stand vor 2 Jahren vor dem Problem mit WebLogic Portal 10, es scheint bei WebLogic Portal 10.3.2 immer noch zu existieren. Siehe [2] bzw [3].
Bei ADF Faces geht aktuell nur der Weg über Oracle Web-Center und WSRP. Siehe [4].
JSF lieber doch nicht?
Das exzellente Whitepaper [5] von Peter Laird und Tim Breeden – auch wenn es für WebLogic Portal 10.3 geschrieben wurde – gibt einen guten Einblick in die Entwicklung von JSF basierten Portlets. Meiner Meinung nach sollte man diesem Dokument folgen und erst einmal auf ICEfaces verzichten. Des Weiteren kann man hinterfragen, ob alle ICEFaces Controls benötigt werden. Mittels jQuery lässt sich bekannterweise auch ein gelungenes UI erstellen.
Was machen Projekte in denen hauptsächlich Beehive Erfahrung existiert?
In einem aktuellen Projekt haben wir dies lange mit unserem Kunden diskutiert. Wir haben uns dann dazu entschieden, momentan mit Beehive zu starten und später auf JSF 2.0, sobald es vom WebLogic Portal unterstützt wird, zu migrieren. Hierbei ist eine klare Trennung von Präsentations- und Businesslogik (in diesem Projekt mittels EJB 3.0) notwendig.

Referenzen:
[1] Oracle WebLogic Portal 10.3.2 Supported Standards
[2] Forums for ICEfaces
[3] Forums for ICEfaces
[4] Configuring Portlets That Use ADF Faces Rich Client Components
[5] Developing JSF Portlets with WebLogic Portal