boerncke

Archive for November 2006|Monthly archive page

WebServices bekommen mit soapUI ein Gesicht

In Allgemein, Java, WebServices on 29. November 2006 at 17:42

Es liegt in der Natur der Sache, dass WebServices von Haus aus erst einmal keine GUI mitbringen. Wer häufig vor der Aufgabe steht, SOAP-Dienste integrieren oder testen zu müssen, der findet in soapUI ein nützliches Tool, um sich eine einfache Oberfläche ohne Programmieraufwand generieren zu lassen.

Als Webstart-Applikation ist soapUI schnell installiert und unterstützt den Benutzer bei dem Umgang mit WebServices. Auf Basis einer WSDL wird dynamisch ein SOAP-Envelope als Formularvorlage erstellt, mit der die Funktionalität von einem Dienst einfach überprüft werden kann. Die ausgefüllten Formulare können abgespeichert und für spätere Tests wiederverwendet werden.

Mit zusätzlichen Features zum Automatisieren und Reproduzieren von Tests liefert soapUI einen wertvollen Beitrag für die Qualitätssicherung bei Integrationsprojekten. Wer möchte, kann schließlich auch noch Sourcecodegeneratoren einbinden, um sich aus einer WSDL Coderümpfe generieren zu lassen – aber auch so hat mir soapUI schon viel geholfen.

Advertisements

Java Server Faces mit dem NetBeans Visual Web Pack 5.5

In Allgemein, Java on 24. November 2006 at 10:13

Wer sich bei Struts grundsätzlich gut aufgehoben fühlt, der stellt sich vielleicht auch manchmal die Frage, warum es sich lohnen kann, mehr Zeit in Java Server Faces (JSF) zu investieren. Solange die Implementierung mit beiden Frameworks auf Codeebene stattfindet, kann ich keinen wirklichen Vorteil von JSF erkennen, was die Produktivität angeht.

Das kann sich ändern, wenn die Tools für JSF besser werden. Der strukturierte Komponentenbaum, der dem JSF-Konzept zugrundeliegt, macht komfortable GUI-Designer für Webapplikationen möglich, wie wir sie sonst eher aus Redmond kennen.

Wer einmal staunen möchte, was jetzt schon geht, der kann sich das aktuelle NetBeans installieren und dann zusätzlich noch das als „Technology Preview“ deklarierte „NetBeans Visual Web Pack 5.5„. Die Entwicklung einer WebApplikation wird hier zu einer neuen Erfahrung. Die GUI-Komponenten können interaktiv mit der Maus gestaltet werden, auch die Verknüpfung mit den in der faces-config.xml konfigurierten managed beans erfolgt über die grafische Oberfläche. Für die Erstellung der Business-Logik muss der Entwickler dann natürlich doch noch in den Code gehen, aber für die UI-Entwicklung stellt dieser Ansatz einen deutlichen Fortschritt dar. Für struts und im Umfeld von Eclipse habe ich noch nichts vergleichbares entdecken können.

Als Technology Preview gibt es noch Einschränkungen. Für mich derzeit ein no go: Die Einbindung von facelets wird noch nicht unterstützt (ist aber angekündigt). Auch habe ich gelesen – aber nicht selber getestet – dass bei größeren Anwendungen mit vielen Seiten die Performance des Designers Probleme macht. Aber das klingt nach einem lösbaren Problem. Ich bin sehr gespannt, was uns aus dieser Richtung noch erwartet.

Vorsicht Falle: Security mit Spring und ACEGI

In Allgemein, Java on 21. November 2006 at 14:22

Mit dem ACEGI-Framework bietet Spring eine Möglichkeit, einen Sicherheitslayer zwischen Benutzer und der Applikation hineinzuweben. Das ist praktisch, für die Lernkurve sollte man aber etwas Zeit einplanen

An einer Stelle habe ich dabei leider viel Zeit verloren, weil in drei mir vorliegenden Büchern zu dem Thema eine seltsame Eigenschaft nicht dokumentiert ist. Analog zu den Beschreibungen hatte ich zunächst folgendes geschrieben, um eine Filterkette zu konfigurieren:

<bean id="filterChainProxy" class="org.acegisecurity.util.FilterChainProxy">
    <property name="filterInvocationDefinitionSource">
      <value>
        CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
        PATTERN_TYPE_APACHE_ANT
        /**=httpSessionContextIntegrationFilter,logoutFilter,
        authenticationProcessingFilter,exceptionTranslationFilter,
        filterInvocationInterceptor
      </value>
    </property>
</bean>

Diese Code ist mir aber ständig begleitet von mystischen Fehlermeldungen um die Ohren geflogen. Funktioniert hat es erst, nachdem ich die Formatierung folgendermaßen verändert hatte:

<bean id="filterChainProxy" class="org.acegisecurity.util.FilterChainProxy">
    <property name="filterInvocationDefinitionSource">
      <value>
        CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
        PATTERN_TYPE_APACHE_ANT
        /**=httpSessionContextIntegrationFilter,logoutFilter,authenticationProcessingFilter,exceptionTranslationFilter,filterInvocationInterceptor
      </value>
    </property>
</bean>

Wo ist der Unterschied? Die Filterelemente müssen in einer Zeile hintereinander stehen und dann sind auch noch keine trennenden Leerzeichen erlaubt. Andernfalls geht es schief. In meinen Büchern war stets nur die von der Layoutabteilung „schön“ formatierte und umgebrochene Variante zu finden.

Bin ich der einzige, der das Format im XML-Element value ziemlich seltsam findet? Erwartet hätte ich so etwas wie:

<bean id="filterChainProxy" class="org.acegisecurity.util.FilterChainProxy">
    <property name="filterInvocationDefinitionSource">
      <value>
        <list>
          <someelement>CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON </someelement>
          <someelement>PATTERN_TYPE_APACHE_ANT</someelement>
          <someelement>/**=httpSessionContextIntegrationFilter</someelement>
          <someelement>logoutFilter</someelement>
          <someelement>authenticationProcessingFilter</someelement>
          <someelement>exceptionTranslationFilter</someelement>
          <someelement>filterInvocationInterceptor</someelement>
        </list>
      </value>
    </property>
</bean>

Auch an anderer Stelle (org.acegisecurity.userdetails.memory.InMemoryDaoImpl) verwendet ACEGI eine Notation im unformatierten Text, wo ein wenig mehr XML nicht schaden könnte. Aber das wird sich ja vielleicht/hoffentlich in einer zukünftigen Spring-Version noch ändern.

Wie ‘Standards’ die Auswahl der besseren Technologie erschweren können …

In Allgemein, Java on 20. November 2006 at 12:03

Welche Bedeutung haben offizielle Standards bei der Auswahl von Technologien und Frameworks für ein Projekt? Bei vielen Entwicklern stellt es wohl eine konsensfähige Position dar, dass offizielle Standards hilfreich sein können, oft aber inoffizielle de-facto Standards wie struts oder Spring den schnelleren Weg zum Ziel ermöglichen. Wer würde da auch widersprechen?

Gegenwind für dieser Sichtweise verspüre ich nicht aus der Entwicklerecke, sondern aus einer ganz anderen Richtung. Wenn „Techniker“ nicht mehr unter sich sind und plötzlich auch nicht-technische Entscheidungsträger bei der Auswahl von Frameworks mit am Tisch sitzen, dann verändern sich auch die Entscheidungsprozesse für die Auswahl von Technologien.

Plötzlich zählen dann nicht-technische Argumente, die eher politischer Natur sind. Ich habe da in der Vergangenheit zum Beispiel folgende Statements vernommen (die ich mir ausdrücklich NICHT zu eigen mache):

– „Welche Technologie wird von unseren bestehenden Entwicklungspartnern unterstützt und supportet? Wir wollen uns nicht mehrere Firmen ins Haus holen.“
– „Wir machen auch sonst nur, was Oracle macht und wollen keine Frameworks, die aus einer anderen Ecke kommen.“
– „Was sagen die großen Unternehmen aus der Industrie wie Sun, Oracle, IBM, SAP etc. Und wer ist Interface21?“
– „Die Entscheidung für Produkt X ist am Wochenende auf dem Golfplatz gefallen.“
– „Was nichts kostet kann auch nichts taugen.“
– „Von OpenSource und einer anonymen Community kann ich weder guten Support noch Qualität ertwarten.“

Glücklicherweise höre ich zumindest die beiden letzten Argumentationsmuster in letzter Zeit deutlich seltener, hier hat sich etwas im Bewusstsein vieler Entscheider verändert.

Das Gegenargument, dass auch offizielle Standards in der Vergangenheit manchmal kaum 5 Jahre überlebt haben, zeigt dagegen meist wenig Wirkung. Viele Entscheidungsträger wollen später nicht für ihre Entscheidung angegriffen werden können. Und wer eine Technologie nicht selber bewerten kann, der schaut dann eben auf die großen Namen und das vermeintliche Zauberwort „Standard“.

Hier wird deutlich, dass es auch für inoffizielle de-facto Standards zumindest aus Marketing-Sicht wichtig ist, den Begriff „Standard“ zu besetzen oder Kooperation mit der Industrie zu suchen, um bei manchen Entscheidern als ernsthafte Alternative wahrgenommen zu werden. Als Erfolgsfaktor für ein OpenSource-Framework ist also nicht nur eine gute Technologie nötig, sondern es besteht auch Bedarf nach viel kleinschrittiger Lobbyarbeit – die durchaus auch kollektiv von einer breiten zufriedenen Entwickler-Community geleistet werden kann. Diese Ochsentour mag durchaus Jahre dauern, aber wenn wir ehrlich sind: ein offizieller Standard ist auch nicht schneller.

myEclipse jetzt mit einem all-in-one-installer

In Allgemein, Java on 19. November 2006 at 13:19

Ich arbeite viel mit der Kombination eclipse / myEclipse. Diese Lösung ist zwar nicht kostenlos, aber sicherlich ihr Geld wert. Mit einer Fülle von vorkonfigurierten und aufeinander abgestimmten Plugins erleichtert sie mir das Arbeiten deutlich. Die Gute Dokumentation und ein aktives Forum helfen bei konkreten Fragestellungen weiter.

Aktuell ist nun myEclipse in einem neuen Release erschienen und erstmals in einem All-In-One-Bundle angeboten. Dies erleichtert die Installation deutlich und mag vielleicht manchen Leser dazu zu bewegen, selber mal einen Blick auf eine 30-Tage-Demo von MyEclipse zu werfen.

Als Features werden angepriesen:

  • Matisse4MyEclipse SWING UI Designer
  • Web Services Support
  • AJAX / WEB 2.0 Tools
  • UML Modeling with full Roundtrip Engineering
  • Split-screen Web Designer for WYSIWYG Development
  • Visual JSF & Struts Development
  • Hibernate Tools – Spring IDE Integration
  • World-class Support Ready for Enterprise Use

AJAX – Experimente mit dem Google Web Toolkit (gwt)

In Allgemein, Java on 16. November 2006 at 12:22

Als Ergebnis meiner Experimente mit dem gwt-Framework von Google habe ich mir ein kleine Frontend für die parallele Verwendung mehrerer Suchmaschinen geschrieben und online gestellt.

Achtung: Wenn JavaScript abgeschaltet wird, bekommt man natürlich kein brauchbares Ergebnis.

Nicht ganz im Spirit von Ajax habe ich hier allerdings die komplette „Businesslogic“ im Client untergebracht, so dass es sich hier eigentlich um ein Beispiel für eine Applikation handelt, die mit Java entwickelt wurde, dann aber als JavaScript-Compilat komplett im Browser ausgeführt wird.

Im gewissen Sinne übernimmt hier also JavaScript die Funktion des Java-Bytecodes. 😎

Tatsächlich hat sich dieses kleine Tool in der letzten Zeit für mich als recht praktisch erwiesen. Ich freue mich über Feedback, wenn jemand eigene Erfahrungen damit gesammelt hat.

GPL für Java

In Allgemein, Java on 14. November 2006 at 12:04

Nun ist es raus: Sun hat sich dazu entschieden, JAVA unter der GPL-Lizenz der Community zur Verfügung zu stellen. Welchen „Impact“ dieser Schritt auf das Java-Universum haben wird, ist derzeit ein heiss diskutiertes Thema in diversen Foren.

Befürchtungen gehen zum Beispiel dahin, dass durch drohende Forks und der parallelen Existenz von mehreren Java-Versionen in Zukunft einer der großen Vorteile von Java ins Wanken gerät, nämlich das „Write once, run anywhere“-Prinzip.

Wer mitdiskutieren möchte, vorher aber noch einmal einen Blick auf die Fakten werfen mag, der kann sich in einem ausführlichen FAQ von SUN darüber informieren, was wirklich geplant ist:

Free and Open Source Java

Hier wird auch deutlich, dass SUN es sich vorbehält, selber zu entscheiden, was sich in Zukunft JAVA nennen darf. Auch der Java Community Process (JCP) bleibt erhalten. Jeder Entwickler darf in Zukunft aber durchaus ein inkompatibles JAVA bauen, wird dieses aber dann zum Beispiel „Hawaii“, „Madagaskar“ oder „Tonga“ nennen müssen.

Die GPL ist als eine „ansteckende Lizenz“ bekannt. Muss in Zukunft auch Software, die auf der Java-Plattform betrieben wird, unter GPL veröffentlicht werden? Das wäre in der Tat kritisch, ist aber nicht der Fall. Die zur Anwendung kommende Variante der „GPL v2 mit Classpath Exception“ stellt ähnlich der LGPL sicher, dass sich hier am Status Quo nichts verändert:

„It [the license] allows you to link an application available under any license to a library that is part of software licensed under GPL v2, without that application being subject to the GPL’s requirement to be itself offered to the public under the GPL.“

Sun verspricht sich von diesem Schritt vor allem eine Öffnung für neue Märkte. Aus lizenzrechtlichen Gründen findet sich auf vielen Linux-Distributionen derzeit kein aktuelles JDK. Das wird sich nun ändern. Manche Länder und Institutionen machen „Open Source“ zu einer Vorraussetzung für den Einsatz in Ihrem Umfeld, sei es bei Behörden oder im Bildungswesen.

Vor diesem Hintergrund sage ich der Kombination „Ubuntu und Java“ eine rosige Zukunft voraus.

Developer: Bessere Web-Guis mit Java Server Faces?

In CSS, HTML, WebFrameworks on 3. November 2006 at 18:10

Wer sich als Entwickler bei dem Web-Framework struts gut aufgehoben fühlt, der stellt sich vielleicht auch manchmal die Frage, warum es sich lohnen kann, mehr Zeit in Java Server Faces (JSF) zu investieren. Solange die Implementierung mit beiden Frameworks auf Codeebene stattfindet, kann ich keinen wirklich entscheidenden Vorteil von JSF erkennen, was die Produktivität angeht.

Das kann sich ändern, wenn die Tools für JSF besser werden. Der strukturierte Komponentenbaum, der dem JSF-Konzept zugrundeliegt, macht komfortable GUI-Designer für Webapplikationen möglich, wie wir sie sonst eher aus Redmond kennen.

Wer einmal staunen möchte, was jetzt schon geht, der kann sich das aktuelle NetBeans installieren und dann zusätzlich noch das als “Technology Preview” deklarierte “NetBeans Visual Web Pack 5.5“.

AJAX ohne JavaScript (nicht wirklich)

In Allgemein, Java on 3. November 2006 at 12:51

AJAX ist letztlich mit dem massiven Einsatz von JavaScript verbunden. Ich kenne allerdings keinen Entwickler, der wirklich gerne mit JavaScript arbeitet. Mir selber geht es da nicht anders. Zu viele neue Baustellen holt man sich mit JavaScript ins Haus:

  • Sprachmix: Eine Mischung aus Java und JavaScript erschwert die Wartung, Entwicklung und das Refakturieren von Anwendungen. Das ist nicht primär ein Problem von JavaScript, sondern ein Ergebnis der Situation, mit mehreren Sprachen eine Aufgabe lösen zu wollen.
  • Die Entwicklungswerkzeuge für Java sind deutlich besser entwickelt als für JavaScript. Wer sich in der Java-Welt daheim fühlt, der wird die Arbeit mit der „anderen Sprache“ erst einmal als Rückschritt erleben.
  • Browser-Inkompatibilitäten: Das vertraute Paradigma des „Write once, run everywhere“ gilt plötzlich nicht mehr. AJAX-Anwendungen müssen separat für jeden Browser (mehrere Internet Explorer Versionen, Firefox/Mozilla, Opera, Safari etc.) getestet werden. Die Entwicklungszyklen werden damit länger und teurer.
  • Nicht zuletzt waren in der Vergangenheit häufig Sicherheitsbedenken ein Argument gegen den Einsatz von JavaScript. Da manche Unternehmen wegen drohender Sicherheitslücken unternehmensweit JavaScript-Code abschalten oder herausfiltern, können AJAX-Anwendungen mangels Plattform hier gar nicht zum Einsatz kommen. Dieses letzte Argument war früher ein K.O.-Kriterium, in letzter Zeit scheint es aber an Bedeutung verloren zu haben.

Was die Bedenken beim Entwicklungsprozess betreffen, so versprechen hier Frameworks Abhilfe. Das von Google gesponsorte gwt (Google Web Toolkit) verfolgt zum Beispiel ein besonders elegantes Konzept:

1. Der Entwickler arbeitet nach wie vor mit Java in seiner vertrauten Entwicklungsumgebung und deshalb mit gewohnter Produktivität.
2. Ein gwt-Compiler übersetzt den JavaCode in JavaScript-Code, der auf allen gängigen Zielplattformen lauffähig ist.

Damit können Entwickler AJAX-Applikationen entwickeln, ohne eine Zeile JavaScript schreiben zu müssen. Die nächsten Tage werde ich mich einmal genauer mit diesem Thema beschäftigen.