2 CDI
2.1 Was ist das?
CDI steht fürContexts and Dependency Injection for the Java EE Platform und ist ein Standard innerhalb des Webprofils der Dachspezifikation Java EE 6. Der Arbeitsbereich von CDI ist die Bereitstellung und Verknüpfung von Komponenten und Diensten als Basis für Enterprise-Applikationen. CDI ist allerdings nicht nur im EE-Umfeld nutzbar, sondern kann auch ohne Applikationsserver eingesetzt werden.
CDI wurde im JSR 299 lange Zeit unter den Namen WebBeans entworfen und standardisiert viele Ideen und Konzepte von populären Open-Source-Frameworks wie Seam und Spring(-Core). Die Spezifikation ist für Java-EE-Verhältnisse angenehm kurz: ca. 100 gut lesbare Seiten1.
Neben der Referenzimplementierung JBoss Weld2 stehen u. a. Apache OpenWebBeans3 und Resin CanDI4 als CDI-Container zur Verfügung.
2.2 Wozu braucht man das?
Professionelle Anwendungen sind nicht monolithisch aufgebaut, sondern bestehen aus Komponenten. Zum einen ergeben sich bei der Entwicklung von Software aus der Analyse der Aufgabenstellung fachliche Bereiche, die durch fachliche Komponenten abgebildet werden können. Innerhalb dieser Komponenten lassen sich wieder Teile abgrenzen, diesmal eher technischer Natur. Die Komponenten benutzen andere Komponenten und die Plattformdienste, sind aber weitgehend abgegrenzt (Abb. 2.1).
Abbildung 2.1: Anwendungskomponenten
Eine Aufgabe der Softwareentwicklung ist es nun, diese Komponenten untereinander zu verknüpfen, sodass eine saubere Anwendungsarchitektur entsteht. Das kann natürlich mit einfachen Sprachmitteln von Java geschehen. Eine Komponente kann in ihrem Programmcode andere Komponenten instanziieren, indem sienew benutzt. Dadurch wird die Kopplung der Komponenten aber sehr stark, denn die aufrufende Komponente muss die benutzte sehr genau kennen,Änderungen sind aufwändig, der Einsatz einer alternativen Komponente unmöglich.
Zudem profitieren solche Objekte kaum von der Umgebung der Anwendung: Der Applikationsserver„kennt“ sie nicht, kann also bspw. kein Monitoring und keine Laufzeitsteuerung dafür durchführen. Flexibler ist es, die benötigten Objekte vom Application Server herstellen zu lassen. In den früheren Versionen der Java EE– damals noch J2EE– hat man dazu weitgehend String-basierte Referenzen benutzt, hat also bspw. die benötigte Komponente per Namen im JNDI-Dienst adressiert. Hier stellt sich aber das Problem der„Zielgenauigkeit“: Ist ein Objekt unter dem verwendeten Namenüberhaupt vorhanden und hat es den richtigen Typ (Listing 2.1)?
// Unsicher: Ist ein Objekt mit dem Namen konfiguriert?
// Falls ja, hat es den korrekten Typ?
MyService myService
= (MyService) jndiContext.lookup("ejb/myService");
Listing 2.1: Referenzierung einer Komponenteüber ihren Namen
Ein weiteres Problem ist die Abhängigkeit der aufrufenden Komponente von ihrer Umgebung: Der Code im Beispiel setzt unumstößlich voraus, dass es einen JNDI-Dienst gibt. Ein Test des Codes außerhalb des Applikationsservers ist damit unmöglich. Hier setzt die IdeeInversion of Control an, die den aktiven Teil der Komponentenverknüpfung aus der Komponente herauslöst und in die Laufzeitumgebung– den Container– verlagert: Nicht die Komponente besorgt sich die von ihr benötigten Serviceobjekte, sondern der Container liefert sie an. Dieses Verfahren firmiert unter dem NamenDependency Injection– Injektion von benötigten Objekten, womit wir auch schon die beiden letzten Drittel des Namens CDI erklärt hätten (Abb. 2.2).
Abbildung 2.2: Dependency Injection
Die Komponente„weiß“ jetzt nicht mehr, woher sie die von ihr genutzten Objekte erhält. Damit ist die Kopplung zu ihrer Umgebung so klein geworden, dass ein Austausch leicht möglich wird: Im Produktivsystem werden Komponenten und Ressourcen vom Container bspw. weiterhin im JNDI-Dienst verwaltet, während sie in einer Testumgebung ohne Container von der Testklasse geliefert werden.
Bei der Dependency Injection obliegt es dem Container, wann die benötigten Objekte erzeugt und zerstört werden, er kann also die Komponenten von der komplett
