Blog

JavaOne 2008 Tag drei

Erik Jan de Wit

Aktualisiert Oktober 23, 2025
9 Minuten

Heute war der dritte Tag der Konferenz. Noch ein paar Stunden und dann ist alles wieder vorbei. Die Müdigkeit macht sich bemerkbar, und wir fangen an, auf Reserve zu laufen. Zu den Themen des heutigen Tages gehörten:

  • Mylyn
  • Groovy
  • Semantisches Web
  • SOA
  • OSGi

Erik Jan über Mylyn Es ist nun der dritte Tag der JavaOne und die ersten Anzeichen von Müdigkeit machen sich bemerkbar, so dass ich heute nicht an den nächtlichen Bird of a Feather-Sitzungen teilgenommen habe. Ich habe aber eine Sitzung über Mylyn besucht. Ich habe schon früher darüber gebloggt, aber ich war beeindruckt von dem, was sie daraus gemacht haben. Sie haben eine Vielzahl von Konnektoren für verschiedene Problemverfolgungssysteme hinzugefügt. Eines der Dinge, die ich vermisst habe und die sie jetzt angekündigt haben, ist die Möglichkeit, automatisch die Zeit zu protokollieren, die an einem Problem gearbeitet wurde. Außerdem haben sie eine Perspektive geschaffen, in der Sie mehr Kontext für Ihre Aufgabe behalten können, so dass alle Webseiten, die Sie sich angesehen haben, auch mit Ihrer Aufgabe gespeichert werden. Mit einer Demo zeigte der Vortragende eine weitere großartige Anwendung für Mylyn. Wenn Sie z.B. zu zweit programmieren und einer der beiden nach Hause geht, können Sie ganz einfach einen Patch der Änderungen erstellen und ihn zusammen mit der Aufgabe speichern, ähnlich wie den Kontext. Ihr Kollege kann die Arbeit dann ganz einfach auf seinem eigenen Computer fortsetzen.Bei meinem nächsten Projekt werden wir also alle Mylyn verwenden, damit wir die geleistete Arbeit nachverfolgen und unsere Schätzungen verbessern können. Der zusätzliche Vorteil des Pairing und der Übernahme wird das Pair Programming vereinfachen. Jeroen über Groovy-Skripte und das Semantic Web Um meinen Tag zu beginnen. Ich habe den Groovy und Grails Vortrag von Guillaume LaForge und Graeme Rocher besucht. Leider war Graeme krank, so dass Guillaume den Vortrag allein gehalten hat. In diesem Vortrag ging er weiter als in der Scripting Bowl. Die Teilnehmer konnten aus erster Hand erfahren, was es bedeutet, die Macht des Meta-Object Protocol (MOP) in den Händen zu halten. Obwohl Groovy nicht die einzige Sprache mit einem MOP ist - Ruby, Lisp und Smalltalk haben auch eines -, konzentrieren wir uns auf diese Sprache. Das Meta-Object Protocol macht Groovy zu einer dynamischen Sprache. Es ermöglicht das Hinzufügen und Überschreiben von Methoden und Eigenschaften zu bestehenden Klassendefinitionen während der Laufzeit. Zwei kleine Beispiele, die Guillaume uns zeigte, waren die folgenden: Hinzufügen von Methoden zur Laufzeit

Klasse Hund {}
Dog.metaClass.bark = { ->  "Wuff" }
def d = new Hund()
print d.bark()
==>  Wuff

Überschreiben Sie die Methode zur Laufzeit (Hinweis: Dies ist keine gute Idee...)

Integer.metaClass.plus = { Integer i ->  1 }
3 + 4
==>  1

Außerdem erklärte er einige nette methodMissing-Tricks. Im nächsten Codebeispiel wird die fehlende Methode zur Klassendefinition hinzugefügt, so dass beim nächsten Mal die Strafe für das Durchlaufen von methodMissing entfällt.

Klasse Hund {}
Dog.metaClass.methodMissing = { String name, args ->
  def cached = { Object[] a ->  println "Hunde haben keinen $Namen"}
  Dog.metaClass."$name" = zwischengespeichert
  cached.call(args)
}
new Hund().quaken()

Alles in allem zeigte Guillaume, welche Vorteile Groovy gegenüber Java hat und welchen Beitrag Groovy zur Entwicklung Ihrer aktuellen Unternehmensanwendungen leisten kann. Nach dem Mittagessen ging ich zur Podiumsdiskussion über Semantic Web. Hier gab es eine Podiumsdiskussion mit 5 Semantic Web-Gurus, die einige coole Anwendungen vorstellten und Fragen aus dem Publikum beantworteten. Es wurde schnell klar, dass der Schwerpunkt derzeit auf dem Semantic Web als soziales Netzwerk liegt. Viele der vorgestellten Anwendungen drehten sich um dieses Thema. Nach Ansicht dieser Gurus besteht das Problem mit den derzeitigen sozialen Netzwerken darin, dass es zu viele davon gibt und jedes von ihnen zentralisiert ist und auf seiner eigenen Insel lebt. Das Semantic Web kann in dieser Hinsicht helfen. Es gibt keine konkurrierenden Standards, alles ist interoperabel, und es ist dezentralisiert, alles wird durch seine eigene URI identifiziert. In einer Demo wurde ein Adressbuch gezeigt, in das Sie sich selbst eintragen und so leicht Zugang zu Ihren Freunden und den Freunden Ihrer Freunde usw. erhalten können. Eine weitere große Ankündigung war, dass Yahoo! alle seine Seiten mit RDFa versehen und über seine APIs verbreiten wird. Dies ist ein großer Schritt, der Yahoo! zu einem semantischen Unternehmen macht, das sich anderen Unternehmen wie Reuters und dem W3C als Unterstützer semantischer Standards anschließt. Das Hinzufügen von RDF bedeutet das Hinzufügen von semantischen Tags zu den Seiten. Ein semantisches Tag unterscheidet sich von einem normalen Blog-Tag dadurch, dass es den Daten eine Bedeutung gibt, z.B. ob es sich um einen Ort, eine Organisation, eine Person oder etwas ganz anderes handelt.Nach fast 10 Jahren machen wir endlich Schritte in die Richtung, die Tim Berners Lee sich für das Web vorgestellt hat, aber das vollständige Semantic Web ist noch weit entfernt. Wir können nur hoffen, dass diesem Schritt von Yahoo! weitere Unternehmen folgen werden. Marco an seinem (SOA) Tag Sun Java Composite Application Platform Suite: Implementing Selected EAI Patterns Bei JavaPolis wurde mir ständig gesagt, was für ein großartiges Buch Enterprise Architecture Patterns sei, also habe ich es sofort nach meiner Rückkehr ins Büro bestellt. Leider hatte ich seitdem keine Gelegenheit mehr, es zu benutzen, da mein letztes Projekt nicht gerade für diese Art von Ansatz geeignet war. Diese Sitzung war zwar etwas trocken, aber sie hat mein Interesse wieder geweckt, da sie reale Implementierungen dieser Muster mit Suns Java CAPS zeigte. Hoffen wir, dass ich wenigstens dieses Mal in der Lage sein werde, all das Wissen, das ich gesammelt habe, zu nutzen. LifeCycle ES: Adobes Java 2 Platform, Enterprise Edition (J2EE Platform), SOA Platform Eines ist sicher: An Plattformen mangelt es dem Titel dieser Sitzung nicht. Mehr noch als bei der vorangegangenen Sitzung ging es hier um ein Produkt, in diesem Fall von demselben Unternehmen, das für seinen Acrobat Reader bekannt ist. Vor diesem Hintergrund war es nicht allzu überraschend, dass es in der Demo um einen PDF-Prozessor ging. Ich bin mir immer noch nicht sicher, wie das mit dem SOA-Zeug zusammenhängt, aber das könnte auch daran liegen, dass ich zu sehr damit beschäftigt war, mich an den Schauspieler zu erinnern, an den mich der Sprecher erinnerte (French Stewart von 3rd Rock - vor allem wegen der nasalen Stimme). Konvertierung großer Anwendungen in OSGi Ich kannte nur die Grundlagen von OSGi aufgrund eines Vortrags von Peter Kriens, den ich auf der JavaPolis besucht hatte, und wurde von demselben Redner (nun, natürlich nicht persönlich - obwohl er mich direkt ansah, als er sich an den Raum wandte) gewarnt, dass das Thema etwas schwer zu begreifen sein könnte. Er brauchte keine Angst zu haben: Es war ein sehr klarer Vortrag mit einigen nützlichen Anleitungen, wie man die Konvertierung einer bereits bestehenden Anwendung angehen kann. Composite Application Design Patterns Der Beweis dafür, dass selbst ich manchmal Fehler mache (alle, die mich persönlich kennen: hören Sie auf zu lachen), habe ich beschlossen, eine Sitzung über die Wahl des richtigen Webs dafür ausfallen zu lassen. Im Grunde war es nichts anderes als die Präsentation einiger Muster, die sich die Leute bei SAP ausgedacht hatten, und zwar in einer Art und Weise, die dem bloßen Überprüfen der PowerPoint-Präsentation absolut nichts hinzuzufügen vermochte. Ich weiß, dass es sehr schwierig ist, eine interessante, lebendige Präsentation zu halten, aber kommen Sie, es gab nicht einmal Affen! Wie kann man eine Sitzung zu diesem Thema ohne Affen abhalten? Es ist verrückt, das ist es. Designing Service-Oriented Architecture Applications with OSGI Die heutige letzte Sitzung fand einige Stunden nach meiner letzten statt, aber es hat sich gelohnt, dafür ins Moscone Center zurückzukehren. Eine 4-köpfige Gruppe sprach über die Vor- und Nachteile der Verwendung von OSGi auf der Grundlage ihrer Erfahrungen bei der Entwicklung der neuen Version von JBoss ESB. Im Allgemeinen äußerten sie sich sehr positiv, wobei sie das Whiteboard-Muster besonders lobten. Ich habe noch nie davon gehört, aber es ist klar, dass es bei einem Namen wie diesem etwas sein muss, mit dem man alle fehlerhaften Legacy-Codes auf einen Schlag löschen kann. Ja, das war ein Scherz. Epilog Ein weiterer Tag, der ganz im Zeichen von SOA stand, und die Puzzleteile fügen sich langsam an ihren Platz. Ich hätte auf den Vortrag der SAP-Leute verzichten können, aber leider: Manche gewinnen, manche verlieren. Morgen werde ich mir auch einige Sessions aus anderen Tracks ansehen. Ich hoffe, sie sind genauso interessant wie die meisten, die ich bisher besucht habe. Mischa on Converting (Large) Applications to OSGi BJ Hargrave und Peter Kriens sind Experten für OSGi und das Ziel ihres Vortrags war es, "uns zu zeigen, wie man die Anwendungsentwicklung vereinfacht, indem man für die OSGi Service Platform baut" OSGi ist das dynamische Modulsystem für Java. Der Standardansatz für die Modularisierung in Java hat eine Reihe von Problemen wie:

  • Die Granularität von Klassen und Paketen ist zu klein für reale Anwendungen
  • Gefäße dienen der Verpackung, können aber nicht zur Zugangsbeschränkung verwendet werden
  • Schwerwiegende Probleme wie geteilte Pakete
  • Keine Unterstützung für die Versionierung
  • Hat kein geeignetes Modell für die Erweiterung/Kollaboration

Jetzt bietet das OSGi-Framework Folgendes:

  • Versand von Klassenladungen basierend auf dem Paketnamen
  • Ermöglicht mehrere Versionen der gleichen Klasse in einer VM
  • Jars können exportierte Pakete oder private Pakete enthalten
  • Bündel == Jar (Manifest enthält Metadaten)
  • Dienste bieten ein kollaboratives in-VM SOA-Modell

Sie enthält also alles, was wir brauchen. Wie konvertieren Sie also Ihre Anwendung? Nun, einen Schritt nach dem anderen.

  • Analysieren Sie, welche Abhängigkeiten zwischen den Jars bestehen.
  • Erstellen Sie ein Projekt mit Ihrer Anwendung und all ihren abhängigen Jars
  • Erstellen Sie einen Bundle-Aktivator, der main aufruft (alle Bibliotheken in ein Bundle einbinden).

Ein funktionierendes Bundle (unabhängig von der Größe) ist eine gute Ausgangsbasis und ermöglicht es, die abhängigen Jars nach und nach durch Bundles zu ersetzen. Lassen Sie es funktionieren! Jetzt, da es eine funktionierende Version gibt, beginnen Sie damit, das Bundle in kleinere Bundles aufzuteilen. Derzeit gibt es mehrere Open-Source-Projekte, die OSGi-Metadaten bereitstellen:

  • Apache (Derby, Struts, Felix, usw.)
  • Sämtlicher Eclipse-Code
  • Codehaus Groovy

Um es noch schöner zu machen, gibt es auch eine Reihe von Repositories online, so dass Sie nicht die ganze Arbeit selbst machen müssen. Das SpringSource Enterprise Bundle Repository ist ein Beispiel dafür. Leider gibt es ein paar Fallstricke wie z.B.:

  • Zu viel auf einmal (Machen Sie die gesamte Anwendung OSGi-fähig, modularisieren Sie einen Teil, testen Sie, und iterieren Sie in kleinen Schritten)
  • Dynamisches Laden von Klassen (Meistens werden benutzerdefinierte Klassenlader in Anwendungen missbraucht, beseitigen Sie sie)

Seien Sie also vorsichtig und fangen Sie klein an. Für diejenigen unter Ihnen, die sich einige OSGi-Anwendungsmodelle ansehen möchten, sehen Sie sich die folgenden Beispiele an:

  • Spring-DM (früher Spring-OSGi genannt)
  • Apache iPOJO
  • Service Anwendungs-Toolkit
  • OSGi Deklarative Dienste

Verfasst von

Erik Jan de Wit

Contact

Let’s discuss how we can support your journey.