Skytecs Entwicklerblog

Wie man Objekte in Datenbanken steckt

Durch die Verwendung von Toolkits und Frameworks kann man sich das Leben gewaltig erleichtern: Statt stundenlang darüber nachzudenken, wie irgendein blödes Objekt in die Datenbank geschrieben werden soll, stopft man es einfach in Hibernate und kann davon ausgehen, dass schon irgendwelche sinnvollen Informationen in der DB landen werden. Ich kann gar nicht ausdrücken, wie genial ich das finde, nachdem ich den größten Teil meines PHP-Lebens damit verbracht habe, pseudo-objektorientierte Strukturen in einer Pseudo-SQL-Datenbank abzubilden…

Trotzdem: Manchmal sollte man einfach wissen, wie sowas geht. Beispielsweise dann, wenn man für einen Kunden arbeitet, der Hibernate aus irgendeinem Grund ablehnt. Oder wenn man gezwungen ist, mit einer Sprache zu arbeiten, für die es keine guten, freien O/R-Mapper gibt. Oder natürlich dann, wenn man der Ansicht ist, dass man keine Tools verwenden soll, wenn man nicht verstanden hat, wie sie unter der Haube funktionieren.

Für diesen informatorischen Ernstfall sollte man sich den Artikel über die Abbildung von Objekthierarchien auf Datenbankstrukturen, von dem mir PFuchs berichtet hat, in die Bookmarks stecken, was im übrigen ganz ohne O/R-Mapping machbar ist, da Bookmarks keine besonders komplizierte Struktur haben.

Der Internet Explorer im Firefox

Nicht ganz ohne Grund genießt der freie Webbrowser “Firefox” eine große Beliebtheit unter Entwicklern - auf die Gründe dafür muss wohl kaum eingegangen werden, entsprechende Diskussionen sind im WWW fast noch häufiger als Bilder von Supermodels. Wie lieb man den roten Panda aber auch gewonnen haben mag - gerade bei der Entwicklung von Webapplikationen kommt man um den MSIE nicht herum, schließlich wollen die Oberflächen ja auf allen gängigen Browsern getestet werden, außerdem gibt es ja immer noch genug Websites, die unbedingt einen Microsoft-Browser verlangen.

Um jetzt nicht alle Bookmarks doppelt pflegen zu müssen und ständig mehrere Browser in der hand zu haben, kann man sich des hochgenialen Firefox-Plugins “IE Tab”, das den MSIE im Firefox integriert, bedienen. Dieses ermöglicht es nicht nur, für jedes geöffnete Browser-Tab zwischen den verschiedenen Rendering-Engines umzuschalten, sondern kann auch bestimmte URLs bei jedem Zugriff abfangen und mit der Microsoft-Engine statt dem Mozilla-Renderer darstellen. Spätestens dann, wenn man für den Vergleich einer Website zwei Tabs offen hat, die diese schnell umschaltbar in den beiden Browservarianten darstellen, ist die kompromisslose Liebe zu diesem Plugin definitiv nicht mehr optional.

Ich danke MHenze für diesen mehr als nur wertvollen Hinweis, der mein Leben im Web entscheidend verbessert hat.

Portlets mit Spring erstellen

Der Portlet-Standard “JSR-168″ ist eine schöne Sache, ermöglicht er es doch, Applikationen leicht in einen gemeinsamen Rahmen zu stecken und die ganzen lästigen Aufgaben wie die Benutzeranmeldung dem Portal zu überlassen. Ärgerlich ist nur, dass die Entwicklung geeigneter Anwendungen so ein Schmerz im unteren Rückenbereich ist, weil brauchbare Frameworks eher dünn gesät sind.

Wie bei vielen Problemen heißt die Lösung auch hier mal wieder Spring. Mit diesem von mir sowieso sehr geschätzten Framework konnte man immer schon hübsche MVC-Applikationen zusammenstecken, die zwar nicht als Portlets ausgeführt werden konnten, sonst aber alles hatten, was ein Bier oder auch eine Webanwendung braucht. Wen wundert es da, dass mit der Version 2.0 des Frameworks auch die Unterstützung für den Bau von Portlets in den Leistungsumfang aufgenommen wurde?

Wie viele neue Features irgendwelcher Softwareprodukte krankt allerdings auch dieses daran, dass es noch etwas zu dürftig dokumentiert ist, um einen schnellen Einstieg zu erlauben. Um so erfreulicher ist es, dass Patrick Huber  einen Leitfaden zur Erstellung von Portletapplikationen mit Spring zusammengestellt hat, der enorm dabei hilft, wenn man so ein Projekt beginnen will. Besagter Leitfaden führt übrigens auch gleich in die Portlet-Thematik an sich ein, so dass man auch als kompletter Neuling in der Portalwelt mit dem Artikel glücklich wird, sofern man zumindest Grundkenntnisse der Entwicklung mit Spring hat.

Ein kleiner Hinweis sei mir noch erlaubt: Selbstverständlich funktionieren solche Portlets auch im Portalserver “Sitebase” der Skytec AG!

Wie man (sich) mit Java profiliert

In der letzten Woche war das Profiling von Java, d.h. das Aufspüren von Speicherlecks und Leistungsengpässen, ein großes Thema in unserer internen Mailingliste. Angefangen hatte das mit einem interessanten Artikel über das Profiling von Java-Code, den MReinermann aufgetan hatte. Dazu gehört auch gleich der Link zum Profiling-Tool “JMeter” von HP, das die angenehme Eigenschaft hat, kostenlos zu sein, und das im Artikel auch kurz vorgestellt wird. Der Kostenpunkt ist übrigens auch der massive Vorteil im Vergleich zu JProfiler, dem Tool, das wir hier im Hause erfolgreich einsetzen und das ich hier auch kurz erwähnen wollte, nachdem es von BLandgraf gelobt wurde.

So eine Mailinglisten-Diskussion kann natürlich nicht ohne einen Beitrag von PRogalinski ablaufen, der einen Artikel über einen Tag im Leben eines Speicherleck-Jägers beigesteuert hat - sehr interessante und durchaus unterhaltsame Lektüre, zu der es noch zwei weitere Teile gibt, die jeweils ganz unten auf den jeweiligen Seiten verlinkt sind.

Webservices von Sun: JWSDP 2.0

Ich gebe zu, dass ich zum Bauen von Webservices mit Java noch nie das von Sun herausgegebene Paket “JWSDP” verwendet habe - irgendwie schien es mir immer eine gute Idee zu sein, zu einem anderen Toolkit wie Axis oder XFire zu greifen. Vielleicht sollte ich diese Bildungslücke gelegentlich mal schließen, und wenn es nur sein sollte, um hinterher wenigstens einen Grund dafür zu haben, dass ich die 3rd-Party-Tools verwende. Wer weiß - vielleicht würde ich ja auch positiv überrascht und könnte mir zukünftig die Downloads sparen?

Die Gelegenheit für die Evaluierung des offiziellen Pakets scheint jedenfalls gerade zu günstig zu sein, da Sun die Version 2.0 des SOAP-Frameworks “JWSDP” ins Netz gestellt hat - inklusive umfangreicher Dokumentation und bereits vorbereiteter Versionen von Tomcat, Sun Application Server und Glassfish. Sobald ich mal Zeit habe… OK, ich sehe schon, das wird so bald nicht der Fall sein - für Kommentare zum Thema wäre ich also sehr dankbar.

Präsentieren in großen Buchstaben

Softwareentwicklung besteht zu 10% aus Programmierung, zu 5% aus Dokumentation und zu 60% aus Präsentation - der Rest verteilt sich gleichmäßig auf Kaffee und Tiefkühlpizza. Der große Präsentationsanteil ist es allerdings, der dem typischen Softwareentwickler oft die größten Kopfschmerzen bereitet. Schließlich ist es gar nicht einfach, durchgestylte Powerpoint-Folien zu erstellen und das Publikum mit Clip-Art, Diagrammen und vielen Aufzählungen zu begeistern.

Vielleicht sollte man das auch gar nicht tun, denn möglicherweise lenkt das nur ab. Als Alternative sollte man eventuell einmal die Takahashi-Methode des Präsentierens mit großen Buchstaben ausprobieren und sich auf einen guten Vortrag konzetrieren, statt Zeit und Energie für die Erstellung von Folien zu vergeuden, die im Endeffekt doch eher vom Vortrag ablenken, als ihn zu unterstützen. Ob es funktioniert, weiß man wohl erst, wenn man es ausprobiert hat - aber ich finde die Idee durchaus nicht uninteressant.

Username und Passwort in SOAP

Auch Webservices wollen abgesichert werden - nur, weil sie nicht in einem Browser dargestellt werden und normalerweise nicht in Suchmaschinen auftauchen sind die kleinen Biester keineswegs weniger Sicherheitsbedürftig als eine normale Website. Jetzt fragt sich nur, wie man das mit der Sicherheit realisieren will, schließlich gibt es da doch verschiedene Ansätze, die man umsetzen kann, um aus ihnen Umsätze zu generieren.

Den einfachsten Fall lasse ich einfach mal außer Acht, weil er ästhetisch schlichtweg unbefriedigend ist: In der Methodensignatur Parameter für Usernamen und Passwort aufzunehmen, ist etwa so stillos wie guter Whisky, den man mit Eistee mischt. Wenn man diese Variante mal ausschließt, bleibt dann eigentlich nur noch, die Headerfelder der SOAP-Message zu verwenden - auch dann kommt aber keine Langeweile auf, denn auch hier gibt es Entscheidungen, die getroffen werden wollen.

Einfach, dafür aber eher proprietär, ist es, wenn man sich einfach selber ein paar Headerfelder für die Userdaten einfallen lässt. Sowas ist flink umgesetzt, von Standardisierung kann aber kaum die Rede sein. Das sieht schon besser aus, wenn man die von OASIS definierten Header für die Authentifizierung nutzt - sowas wird mit etwas Glück auch von fremden Diensten verstanden. Die Lösung krankt höchstens noch daran, dass sie irgendwie nicht besonders schick aussieht, aber auch für Softwareästheten gibt es eine geeignete Lösung: Die Ablage von XML-Signature-Blöcken im Header, das kommt stilvoll rüber und funktioniert nicht nur mit SOAP, sondern auch mit so ziemlich jeder anderen XML-basierten Kommunikationsform.

Wie man sieht, führen viele Wege nach Rom, die allesamt mindestens wie Bundesstraßen oder gar Autobahnen aussehen. Den Fußweg über die Felder in die italienische Hauptstadt, d.h. die Verseuchung der Methodensignatur mit Anmeldeinformationen, kann man sich also erfreulicherweise wirklich sparen.

Noch eine Bedeutung für “SOA”

Manche Abkürzungen tun mir echt leid, weil sie noch überstrapazierter als ein Entwickler kurz vorm Abgabetermin sind - eine davon ist “SOA”. Diese unschuldig wirkenden drei Buchstaben tragen wohl mehr zur Verwirrung in Projektmeetings bei, als es hochdosierter Alkohol zu tun vermag.

Schon seit längerer Zeit ist es ja üblich, dass Consultants und Entwickler mit diesem Akronym gepflegt aneinander vorbei reden - die einen meinen den Sarbanes-Oxley-Act, die anderen haben ServiceOrientierte Architekturen im Kopf. Interessanterweise habe ich übrigens schon mal eine zweistündige Präsentation erlebt, in der es nicht mal aufgefallen ist, dass die beiden Hälften des anwesenden Publikums von völlig unterschiedlichen Vortragsthemen ausgegangen sind… Sowas kann einem halt passieren, wenn man eine Auditing-Software serviceorientiert implementiert.

BenQ/Siemens sorgt jetzt für eine weitere Verkomplizierung der Sachlage, und zwar mit den so genannten “Services Over Air”, d.h. automatischen Updates für Mobiltelefone, die direkt über die Funkleitung geschoben werden. Ich will mir lieber gar nicht vorstellen, was mit dieser zusätzlichen Interpretation des Kürzels passieren kann, wenn Serverprogrammierer, Handyhacker und Consultants gemeinsam in einem Kickoff-Meeting sitzen und plädiere deshalb für eine sofortige Umbenennung in “Software Over Air”. OK, ich gebe zu, dass das auch nicht viel bringen würde und danke lieber JKuehner für den Link, statt mich noch weiter als Akronymentwickler zu versuchen.

Nützliche Online-Generatoren

Man kann natürlich alles selber machen, aber warum sollte man, wenn man gewisse Dinge auch einfach generieren lassen kann? Schließlich hat man im Regelfall genug zu tun, um seine kostbare Zeit nicht mit der Art von Aufgaben verschwenden zu wollen, die ein Computer genauso gut machen kann - insbesondere deshalb, weil der Computer nicht alle Details in irgendwelchen Dokumentationen nachschlagen muss, bevor er loslegen kann.

Aus diesem Grund finde ich die umfangreiche Liste diverser Online-Generatoren für alles mögliche, die unser Leser Galileo gefunden hat, auch ausgesprochen nützlich. Vom primitiven Basis-CSS über Impressumstexte bis hin zu Grafiken, Formularen und Sitemaps findet man dort wirklich alles, was Zeit und Nerven spart. Mein Prädikat: Sehr nützlich, deshalb erfolgt auch der unbedingte Bookmarkbefehl.

Hibernate mit Caching beschleunigen

Caching ist gut - wer mag schon jedesmal zum Telefonbuch greifen, wenn er eine Nummer braucht, die er ständig wählt? Nein, da verwendet man lieber einen First-Level-Cache und merkt sich die Nummer oder greift auf einen Second-Level-Cache zu, was soviel bedeutet wie eine PostIt-Notiz mit der Nummer am Monitor. So kriegt man die Telefonnummer schneller, wählt früher und kommt pünktlich zum Abendessen heim. Wählst Du noch oder isst Du schon?

Wenn man dieses Vorgehen bei Telefonnummern sinnvoll findet, sollte man es doch eigentlich auch anwenden, wenn man eine Datenbank benutzt, oder? Gerade dann, wenn man nicht nur kleine Queries abschießt, sondern stattdessen mit Hibernate große Anfragen konstruiert, sollte man an Zugriffen sparen, wo es nur geht. Dummerweise haben Optimierungen ohne Fachwissen gewisse Gemeinsamkeiten mit in Richtung Fuß abgefeuerten Waffen, folglich sollte man schon wissen, was man tut.

Für Einsteiger in dem Bereich empfehle ich das Tutorial zur Benutzung von Second-Level-Caches mit Hibernate, von dem mir PFuchs berichtet hat. Die Ergebnisse, die da in den Benchmarks auftauchen, sprechen eigentlich für sich - Optimierungen im 400%-Bereich für einfachste Anfragen haben eine gewisse Attraktivität, der man sich nur sehr schwer entziehen kann, sofern man nicht gerne sehr oft Kaffee kochen geht, während man eine Website lädt. Allerdings habe ich den Eindruck, dass am ersten Beispiel etwas nicht stimmt: Sofern mich nicht alles täuscht, ist im ersten dort dargestellten Hibernate-Mapping das Caching bereits aktiviert, obwohl es das nicht sein sollte.