Suche
Teil 1: Rookie – praktische Einführung

Dependency Injection: Next Generation Application Development

Marcel Birkner

Next Generation Application Development
CDI ist seit gut einem Jahr fertig und wird schon in einigen Projekten eingesetzt. Dieser Artikel veranschaulicht die Features von CDI anhand von konkreten Beispielen und möchte die Leichtigkeit vermitteln, mit der in Zukunft Enterprise-Anwendungen entwickelt werden können. Wir verwenden CDI erfolgreich in unseren Projekten und möchten Sie an unserer Erfahrung teilhaben lassen.

Bei der Context und Dependency Injection (CDI) handelt es sich um einen neuen Standard für das Komponentenmanagement von Java-EE-Applikationen. CDI verwaltet den Lebenszyklus und die Interaktion von zustandsbehafteten Komponenten, die einem eindeutigen Kontext zugewiesen sind. Im Vergleich zu anderen Dependency-Injection-Frameworks bietet CDI Typensicherheit bei der Dependency Injection zwischen verschiedenen Komponenten. Dazu kommt der Vorteil der losen Kopplung der Komponenten durch das Prinzip der Inversion of Control, die Dependency-Injection-Frameworks anbieten [1]. Zudem verwaltet der CDI-Container automatisch alle Beans in den jeweiligen Kontexten, in denen sie erzeugt wurden.

Artikelserie: Dependency Injection

  • Teil 1: Rookie – praktische Einführung
  • Teil 2: Handwerker – Testing
  • Teil 3: Experte – fortgeschrittene Konzepte
  • Teil 4: Guru – Frameworkintegration

CDI ist ein Teil der Java EE 6 Platform und Bestandteil des „Full Profiles“ und des „Web Profiles“. Java EE 6 verwendet CDI zur Verbindung aller Core-EE-Technologien und -Frameworks [2]. CDI stellt den Anspruch, dem Anwendungsentwickler nützliche Dienste zur Verfügung zu stellen. Damit wird die Struktur von Anwendungscode verbessert. Zum einen verwaltet CDI einen definierten Lebenszyklus für zustandsbehaftete Beans, die einem spezifischen Kontext zugewiesen sind. Die Anzahl der Kontexte ist dabei nicht begrenzt, sondern flexibel für die Zukunft erweiterbar. Zum anderen bietet CDI einen typensicheren Dependency-Injection-Mechanismus, der es erlaubt, zu verschiedenen Deployment-Zeiten unterschiedliche Dependencies zu konfigurieren und das ohne komplexen Konfigurationsaufwand. Für Webapplikationen gibt es zudem eine Integration mit der Unified Expression Language (EL), die es erlaubt, kontextuelle Beans direkt in JSF- und JSP-Seiten zu verwenden. Zu den fortgeschrittenen Funktionen von CDI zählt die Möglichkeit, injizierte Beans zu dekorieren oder injizierte Beans mit typensicheren Interceptors zu assoziieren. Des Weiteren gibt es ein Event Notification Model, einen Conversation Context und Portable Extensions, die zur Erweiterbarkeit von CDI beitragen und der Integration mit anderen Frameworks dienen. Auf diese Features werden wir in einem der nächsten Artikel im Detail eingehen. Im aktuellen Artikel werden die Grundlagen von CDI vorgestellt und Beispiele für den Einsatz von CDI im Anwendungscode aufgezeigt. Ziel ist es, Sie schnell anhand dieser Beispiele in die Lage zu versetzen, selbst CDI bei sich im Unternehmen effektiv anzuwenden und einzusetzen.

Geschichte

CDI wurde zu Beginn durch die JSR-299 Expert Group spezifiziert, die von Gavin King (Red Hat) geleitet wurde. Anfangs hieß die Spezifikation Web Beans. Das wurde jedoch kurz vor der finalen Version in „Java Contexts and Dependency Injection for the Java EE Platform“ (kurz CDI) abgeändert. Während der Spezifikationsphase wurde schnell klar, dass die hier spezifizierten Dienste nicht nur für Webapplikationen, sondern auch für Java-SE-Applikationen nützlich sein könnten. Ende 2009 wurde die finale Version der JSR-299-Spezifikation abgesegnet. Die Referenzimplementierung des JSR-299 trägt den Namen Weld und wurde unter der Leitung von Pete Muir entwickelt. Ein großer Teil der Technologien im JSR-299 sind stark durch Seam beeinflusst. Basis für die neueste Version von Seam (v3) ist daher CDI [3]. In der Zwischenzeit gibt es verschiedene Implementierungen. Zu den wichtigsten zählen JBoss Weld (Apache License v2.0), Apache OpenWebBeans (Apache License v2.0) und Resin CanDI (GPL v2).
GlassFish v3 und JBoss AS 6 werden standardmäßig mit Weld ausgeliefert. Daher empfiehlt es sich, einen dieser EE-Server zu verwenden, hier bedarf es keiner zusätzlichen Konfiguration. Für unsere Projekte entschieden wir uns für GlassFish v3, da er die Java-EE-Referenzimplementierung ist und somit mit CDI ausgeliefert wurde [4].

Einführung Dependency Injection

Im weiteren Verlauf folgt anhand von konkreten Beispielen die Erklärung der einzelnen Features von CDI. Alle Beispiele befinden sich als Maven-Projekt auf GitHub und können unter [5] heruntergeladen werden.

CDI-Features: Spickzettel

Mehr zum Thema finden Sie übrigens auch im Java-Magazin-Spezial „Java EE 6“, mit einem Artikel über den JSR-299 von Mark Struberg (http://www.javaee-spezial.de). Die folgende Auflistung der wichtigsten JSR-299-Funktionen und -Eigenschaften stammt aus diesem Artikel:

  • Typensicherheit: Anstatt zu injizierende Objekte über ihren Namen zu suchen, werden diese bei JSR-299 hauptsächlich mit dem Java-Typ in Verbindung mit einer optionalen „Qualifier“-Annotation aufgelöst.
  • POJOs: Fast jedes Java-Objekt kann von einem CDI-Container verwaltet werden. Das gilt unter anderem auch für EJB Session Beans, JNDI-Ressourcen, Persintence Units und Persistence Contexts sowie alle Objekte, die durch eine Java-Methode erzeugt werden können (siehe @Produces).
  • Erweiterbarkeit: Jeder CDI-Container kann mit portablen „Extensions“ um Funktionalität erweitert werden. Portabel bedeutet, dass diese Extensions durch die Verwendung von SPI-Methoden (Service Provider Interface) auf jedem beliebigen JSR-299-Container lauffähig sind.
  • Interceptors: Nie war es einfacher, eigene Interceptors zu schreiben. Durch die portable Eigenschaft von JSR-299 sind diese nun auch auf jedem EE-6-zertifizierten Server lauffähig.
  • Decorators: Ermöglichen das dynamische Erweitern bestehender Interfaceimplementierungen um fachliche Aspekte.
  • Events: CDI spezifiziert einen typsicheren Mechanismus zum Senden und Empfangen von Ereignissen, wobei Sender und Empfänger technisch nicht zwingend voneinander wissen müssen (Loosely Coupled Events).
  • Unified EL Integration: EL 2.2 eröffnet einen neuen Horizont in Hinblick auf Flexibilität und Funktionalität bei der Erstellung von JSF- und JSP-Seiten oder ähnlich dynamischer Integrationsmechanismen. CDI bietet Out-of-the-Box-Support dafür.
Geschrieben von
Marcel Birkner
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.