Skytecs Entwicklerblog

Einst XFire, jetzt CXF - einfache Webservices mit Java und Spring

Ich war immer schon ein Freund des SOAP-Toolkits “XFire” - irgendwie hat mir das Tool einfach besser gefallen als das eher komplizierte und verfettete AXIS aus dem Apache-Lager. Mittlerweile schießen sich XFire und Apache allerdings nicht mehr aus, wie ich heute gelesen habe, denn aus XFire und einem anderen Tool namens “Celtix” ist nun das im Apache-Incubator rumliegende Projekt “CXF” geworden. Ich habe gerade mal die Dokumentation überflogen und muss sagen, dass mir das Teil da immer noch besser gefällt als Axis. Insbesondere dann, wenn man seine Webservices aus einem Spring-Container heraus publizieren will und die Microsoft-typische Art, einen Service zu bauen (Interface mit Annotations und aus die Maus) mag, wird man mit CXF sicherlich glücklich werden.

Spring auf .Net

In letzter Zeit häufen sich bei uns die Projekte, die nicht in der bisher ziemlich dominanten Java-Welt, sondern eher im Microsoft-Umfeld angesiedelt sind. Man merkt durchaus, dass Microsoft mit .Net eine durchaus interessante Plattform geschaffen hat - und der Umstand, dass der aktuelle Sharepoint-Server durchaus einiges “im Ei hat”, dürfte auch nicht schaden.

Jedenfalls hat es sich bei uns so ergeben, dass wir gewisse Projekte mit .Net machen sollten, die sich eigentlich spontan nach klassischen Java/Spring/Hibernate-Anwendungsfällen angehört haben. Da kam es für uns gerade recht, dass es mittlerweile auch eine Spring-Portierung für .Net gibt, die in den ersten Anwendungsszenarien durchaus zu beeindrucken vermochte. Ich selbst war im Projekt nicht dabei, aber das Feedback der Kollegen war durchweg positiv und die Doku zur .Net-Springerei sieht vielversprechend aus. Insbesondere hatte ich den Eindruck, dass hier nicht nur stur portiert, sondern tatsächlich auch an die Besonderheiten der Zielplattform gedacht wurde - das geht bis hin zu dem Punkt, dass gewisse Elemente der XML-Kontexte (”bean”) so umbenannt wurden (”object”), dass sie nach .Net aussehen, statt wie Java-Artefakte in fremder Umgebung zu wirken.

Kurzer Auszug dazu aus einer IM-Diskussion mit einem Entwickler:

GOttmann: Wie würdest Du Spring .Net in einem kurzen Satz beschreiben bzw. beurteilen?

PRogalinski: Funktioniert. Ist so gut wie mit Java.

Ich denke, das sagt letztendlich alles, oder? Zusätzlich habe ich noch diese Links bekommen, die mit den Worten: “Auch gut.” beschrieben wurden:

• NHibernate - Hibernate für .Net
• Log4Net - Logging in der .Net-Welt
• XStream für .Net - alles überallhin serialisieren

So, jetzt wisst Ihr’s. Zieht los und seht Euch .Net mal an, auch wenn Ihr bisher noch nichts damit zu tun hattet - die Plattform ist wirklich durchaus einen Blick wert.

Reiche Klienten mit Spring

Wenn man vor hat, sich eine traditionelle Standalone-Applikation (Neudeutsch: einen “Rich Client” oder auch “reichen Kunden”) zu basteln, statt seine Frontends nur ins Web zu pumpen, sollte man zusehen, dass man sich auf irgendein Framework stützt - sonst macht man sich einfach zuviel Arbeit, die nur dem dem Drumrum zu tun hat, ohne wirklich irgendwie zur Verbesserung der Welt oder der eigentlichen Anwendung beizutragen. Für Java-Coder heißt das typischerweise, sich ein Monster wie NetBeans oder Eclipse ans Bein zu binden, was eventuell für kleine Applikationen minimal überdimensioniert sein könnte.

OK, wir haben also ein Problem mit zu fetten Frameworks und Java, und wie heißt hier die typische Lösung? Kinder, sprecht mir nach: “Spring wird’s richten, Spring ist die Rettung und das Licht im Dunkel!” - etwas lauter bitte! Ja, so ist’s brav, das habe ich bis ins Büro gehört. Und natürlich war das nicht nur inhaltsleeres Dumpfgebrülle, wie man es in diesen Tagen des Oktoberfests in München sehr oft vernimmt, sondern die Wahrheit und nichts als die Wahrheit, so wahr mir James Gosling helfe.

Die Helden vom Spring-Projekt haben nämlich, wie ich leider erst jetzt erfahren habe, neben ihres sowieso schon geilen Webframeworks auch noch ein Framework für die Entwicklung von Java-Desktop-Anwendungen aus dem Boden gestampft, das recht schlank aussieht und optisch einen ziemlich guten Eindruck macht. Erfahrungen kann ich hier noch nicht beitragen, weil ich momentan keine Verwendung dafür habe, aber ich hoffe hier schon bald Kommentare zu lesen, die uns allen sagen, ob das Ding wirklich so gut ist, wie ich es mir von allem erwarte, wo Spring drauf steht.

Login mit AJAX und ACEGI

Wenn man schon Web 2.0 macht, dann bitte richtig, also komplett mit Venture Capital, einem total gestörten Businessplan und ganz viel Scheuerpulver für’s Web. Das Scheuerpulver wird dabei klassisch verwendet, um so ziemlich alle Aspekte der Oberfläche aufzupolieren - nur beim Login hat der normale Web-2-Bastler meist noch Schiss und verschickt einfach ein klassisches Formular. Igitt, wie 2002 sowas doch ist, das kann man doch nicht machen… Muss man auch nicht. Über Yigg.de habe ich nämlich ein Tutorial für ein AJAX-Login-Form, das auf dem Server mit ACEGI spricht, gefunden, mit dem kriegt man endlich seine ganze Website modern.

Irgendwie hip finde ich übrigens auch diese Zirkularverbloggung, bei der ich Sachen von Yigg hole, sie blogge und sie dann über das Wordpress-Plugin von Yigg in selbige Seite zurückstopfe. Irgendein armer Google-Rechner wird davon bestimmt ähnlich verwirrt wie die Banker, die dachten, sie hätten mit dem Dotcom-Tod die Sache mit den Krediten für hahnebücherne Geschäftsideen hinter sich gelassen. Finde ich irgendwie gut.

Monitoring von Spring-Applikationen

Woher komme ich? Wohin gehe ich? Und wie wirkt sich das auf meine dumme Webapplikation aus, die irgendwie nicht dahin geht, wo sie hingehen soll? Existenziellere Fragen kann es im Leben eines Webentwicklers kaum geben, daran ändert auch Spring, jene eierlegende Wollmilchsau des modernen Java-Alltags nicht viel. Gelegentlich hilft einem ja wenigstens der Debugger, aber wenn man keine Lust hat, sich durch 1000 Controller zu steppen, sorgt auch der oft eher für Frust.

Eine mögliche Lösung des Problems, zumindest aber ein nettes Spielzeug, dessen Nutzen man irgendwann schon genauer erkennen wird, dürfte der Spring-Monitor namens “Spring Dashboard” sein, von dem mir MHenze heute berichtet hat. Die Software wird einfach statt des normalen Dispatcher-Servlets in eine beliebige Spring-MVC-Anwendung eingeklemmt, schon sieht man ganz genau, was so vorgeht, und kann auch schöne Daten über das Applikationsverhalten sammeln. Komfortabler dürfte wohl nur ein Praktikant sein, dem man den Debugger aufs Auge drückt, während man sich selbst wichtigeren Aufgaben wie der Espresso-Maschine zuwendet.

Lokale Configs in Spring

Wenn man mit mehreren Leuten an einem Spring-basierten Projekt arbeitet, kommt es leicht zu Konfigurations-Bashing im CVS: Jeder ändert die Datei, in der die Zugriffsdaten für die Datenbank stehen, so, dass die Config bei ihm passt. Danach wird alles commited, woraufhin die anderen wieder bei sich die Daten ändern, sie commiten… Wer hat eigentlich behauptet, dass es ein Perpetuum Mobile nicht geben kann?

Nun habe ich schon vor einiger Zeit von einem Trick berichtet, der das Problem recht gut löst - allerdings wird dabei für jeden Rechner eine eigene Configdatei verwendet, was der Ästhetik in den Augen vieler Kollegen eher abträglich ist. Nun ist das aber das kleinste Problem, wie ein Blogpost über die Verwendung lokaler Konfigurationen in einer einzelnen Spring-Properties-Datei zeigt, den OBlume mir empfohlen hat. Sehr einfach und sehr schön, aber noch nicht ganz perfekt, wie OBlume meinte - und da stimme ich ihm zu. Man braucht nämlich für alle Lokalen Configs eine komplette Kopie der gesamten Einstellungen, obwohl meist fast alles aus Defaults gezogen werden kann. Macht nix, das hat der O nämlich auch gelöst, und zwar mit dieser leichten Sourcecodeanpassung:

if(props.containsKey(propertyKey))
// we found a host-specific property
return props.getProperty(propertyKey);
else
// return default property if present
return props.getProperty(placeholder);