[0:01] Herzlich Willkommen zum Anwendungsentwickler-Podcast, dem Podcast rund um die Ausbildung zum Fachinformatiker für Anwendungsentwicklung.

[0:09] In dieser Episode gibt es eine Lernzimmerkontrolle zum Thema Java EE. Viel Spaß!

[0:20] Hallo und herzlich Willkommen zur 54. Episode des Anwendungsentwickler-Podcasts.

[0:26] Mein Name ist Stefan Macke und heute mache ich mal weiter mit einer Lernzielkontrolle.

[0:31] Die letzte ist ja schon ein bisschen her. Da ging es damals um Java und auch heute geht es ein bisschen um Java.

[0:37] Allerdings nicht um die Kernprogrammiersprache, sondern um die Plattform Java.

[0:41] Und zwar ganz konkret um die Enterprise Edition, um Java EE.

[0:45] Und zwar aktuell in der Version 7, also um alles das, was man da so benutzt und benutzen kann.

[0:51] Und alles, was ich für abfragenswert halte, das habe ich heute mal in diese Episode gepackt.

[0:57] Meine beiden Azubis lernen das auch gerade. Die setzen gerade ihre ersten Web-Anwendungen mit Java EE um.

[1:03] Und da bietet es sich an, dass ich auch nochmal für die natürlich hier die Inhalte ein bisschen wiederhole.

[1:07] Und das Wichtigste, was ich so abfragen würde, wenn ich das zum Thema mal irgendeiner Lernzielkontrolle machen würde, das habe ich hier heute mal zusammengefasst.

[1:16] Gut, dann steigen wir doch einfach direkt ein mit einer simplen Einstiegsfrage.

[1:20] Was gibt es denn von Java überhaupt so für Versionen in Anführungszeichen oder Varianten?

[1:25] Und da gibt es eigentlich drei. Die ME, die SE und die EE.

[1:29] Ausgesprochen wären das die Micro Edition, die Standard Edition und die Enterprise Edition.

[1:36] Und die Enterprise Edition ist genau das Thema der heutigen LCK.

[1:40] Im Prinzip haben wir bislang, wenn wir von Java gesprochen haben, immer von der Standard Edition gesprochen.

[1:45] Das ist eigentlich die Programmiersprache, die man zum Beispiel in der Berufsschule, im Studium usw. auch immer lernt.

[1:49] Alles das, was so eine Java so machen kann. Ja, was kann man denn da so machen?

[1:53] Ich weiß nicht, XML-Dateien verarbeiten, Dateien überhaupt aufmachen, Web-Verbindungen herstellen, Datenbank-Verbindungen usw.

[1:59] Das kann man alles mit der Standard Edition machen.

[2:01] Allerdings geht es darum herum, sage ich mal, noch einen ganzen Haufen an Frameworks, die die Kernfunktionalität, sage ich mal, erweitern um bestimmte Inhalte.

[2:10] Und dann sprechen wir von der Enterprise Edition. Darum geht es halt heute.

[2:13] Die Micro Edition, das ist eine abgespeckte Variante von Java.

[2:16] Die ist optimiert für mobile Geräte bzw. läuft auch auf solchen Dingern wie Set-Top-Boxen für Fernseher usw.

[2:24] Da ist also nicht mehr alles drin, was in der SE drin ist.

[2:27] Die EE enthält allerdings alles, was in der SE enthalten ist und erweitert die halt um zusätzliche Frameworks, Spezifikationen, APIs usw.

[2:35] Sind wir auch gleich schon bei der nächsten Frage.

[2:37] Also was ist jetzt konkret die Enterprise Edition von Java?

[2:40] Das ist im Prinzip nichts weiter als eine Sammlung von verschiedenen Spezifikationen für zum Beispiel Frameworks oder Bibliotheken oder APIs, um Java um bestimmte Funktionalitäten zu erweitern.

[2:51] Als Beispiel sowas wie den Datenbankzugriff über einen objektrelationalen Mapper.

[2:56] Da gäbe es eine Spezifikation, die festlegt, wie man das vielleicht mit Java machen sollte, damit nicht jeder sein eigenes Ding da dreht.

[3:02] Hat man halt sich irgendwann mal überlegt, das könnte man mal verallgemeinern und hat dafür eine Spezifikation geschrieben.

[3:07] Und diese Spezifikation ist zum Beispiel Teil der Java EE Spezifikation.

[3:11] Wenn man bei Oracle auf der Seite mal guckt, Oracle ist ja der Hersteller von Java und daran nachrichte ich mich auch immer, wenn ich an die Dokumentation denke und an irgendwelche Listen usw.

[3:21] Da gucke ich da immer nach.

[3:22] Und auf der Seite von Oracle habe ich mal gezählt, es sind insgesamt 38 Spezifikationen, die unter Java EE 7 in diesem Fall zusammengefasst werden.

[3:30] Java EE, die Version ist übrigens nicht immer identisch zu der Version der Programmiersprache.

[3:36] Java selber, die Sprache, hat ja aktuell die Version 8, aber EE hinkt dem immer so ein bisschen hinterher.

[3:42] Also wenn wir jetzt hier von EE 7 sprechen, heißt das nicht, dass wir auch in Java Version 7 programmieren müssen, also zum Beispiel keine Lambdas benutzen können usw.

[3:50] Wir können in Java 8 programmieren, aber diese Spezifikation hat halt die Version Nummer 7.

[3:57] Und es ist auch schon Java EE 8 eigentlich gerade in der Mache und kurz vor der Veröffentlichung, aber es ist halt jetzt noch nicht freigegeben.

[4:04] Deswegen arbeiten wir jetzt noch mit der Java EE Version 7, programmieren dann aber mit Java und allen Sprachmitteln, die Java 8 bietet.

[4:11] Also muss man immer so ein bisschen aufpassen bei diesen Versionen, das passt nicht immer hundertprozentig zusammen.

[4:15] Java EE 7 nun aber sind wie gesagt 38 Spezifikationen und da sind jetzt gerade in Java EE 7 im Vergleich zu EE 6 einige wichtige Spezifikationen dazugekommen,

[4:25] die halt auch gerade die Erstellung von Web-Anwendungen deutlich erleichtern oder bestimmte Features überhaupt erst ermöglichen, wie zum Beispiel Websockets.

[4:32] Websockets gab es in Java EE 6 noch nicht, da gab es zwar Frameworks, Bibliotheken, die das alles schon umsetzen konnten, aber es war halt noch nicht standardisiert.

[4:40] Und jetzt mit Java EE 7 wird halt eine Websocket-API eingeführt und ist jetzt Teil des Standards, sodass ich mich also darauf verlassen kann,

[4:47] dass auch in Zukunft, ja, wenn ich gegen diese API entwickle, die halt weiter gepflegt wird und es abwärtskompatibel bleiben wird.

[4:53] Das ist eigentlich auch gleichzeitig der große Vorteil von Java EE, denn wenn ich mich an diese API halte und gegen diese Spezifikationen programmiere,

[5:00] dann kann ich hundertprozentig sicher sein, dass das auch noch viele Jahre in der Zukunft so funktionieren wird.

[5:05] Denn diese Spezifikation ist quasi wie in Stein gemeißelt, ja, und alle, zum Beispiel Server, die diese Spezifikationen implementieren,

[5:12] die vereinbaren halt quasi wie einen Vertrag, ja, wie eine Schnittstelle, gegen die ich hier entwickle.

[5:18] Und das bedeutet, dass ich auch sowohl einmal von meinem Server völlig unabhängig bin, ich kann den total austauschen gegen irgendeine andere Implementierung,

[5:26] weil halt alle mit der gleichen API arbeiten müssen, aber ich kann halt auch sicher sein, dass bei dem Prozess der Weiterentwicklung von Java und von Java EE

[5:33] darauf geachtet wird, dass diese APIs in Zukunft auch weiter funktionieren.

[5:36] Das heißt, wenn ich jetzt eine Anwendung entwickle, die vielleicht noch zehn Jahre im Einsatz sein soll,

[5:40] dann möchte ich vielleicht schon, dass die auch in zehn Jahren noch funktioniert und ich nicht alle zwei Jahre den Code neu schreiben muss,

[5:46] weil sich auf einmal irgendeine API verändert hat.

[5:48] Und das ist eigentlich der große Vorteil, deswegen setzen wir zum Beispiel auch auf Java EE,

[5:52] weil wir sicher sein können, dass es eine langlebige Spezifikation ist und wir die Anwendung, die wir heute schreiben, auch in ein paar Jahren noch einsetzen können.

[6:00] So, diese Spezifikationssammlung EE, wie gesagt, diese 38 Dinger, die ich da erwähnt habe,

[6:05] da achtet jetzt der sogenannte Community-Prozess, der sich auch darum kümmert, die neuen Spezifikationen aufzunehmen und so weiter,

[6:12] darauf, dass diese Spezifikationen alle gut zusammenarbeiten.

[6:15] Das ist eigentlich jetzt genau der Vorteil dieser, sage ich mal, das heißt auch auf Englisch gerne Umbrella-Spezifikation,

[6:21] also eine Regenschirm-Spezifikation im Prinzip, die alle anderen zusammenfasst.

[6:25] Und da ist jetzt halt der Vorteil, wenn ich zum Beispiel Dependency Injection mir angucke und dafür gibt es eine Spezifikation,

[6:31] dann kann ich dieses Dependency Injection in allen möglichen anderen Frameworks, die auch Teil der Spezifikationen von Java EE sind,

[6:37] einfach so benutzen und ich kann sicher sein, dass es auch funktioniert.

[6:40] Ich muss also zum Beispiel nicht, wenn ich mehrere verschiedene Spezifikationen nutzen will,

[6:43] meinetwegen Datenbankzugriff und REST-API und auch noch CDI für Context and Dependency Injection,

[6:49] dann muss ich nicht immer gucken, wie funktioniert das da und kriege ich das da irgendwie integriert

[6:53] und hier muss ich noch irgendwie durch drei Reifen springen, um die API anzupassen und das überhaupt ansprechen zu können.

[6:58] Nein, wenn ich diese Java EE Spezifikationen benutze, dann weiß ich, dass die aufeinander abgestimmt sind

[7:03] und dass ich das eine mit dem anderen wunderbar kombinieren kann

[7:06] und ich eben nicht mehr Aufwand habe, um die Sachen irgendwie miteinander zu verdrahten.

[7:10] Das ist eigentlich der große Vorteil.

[7:12] Das heißt, wenn ich mich daran halte und gegen diese Spezifikationen arbeite,

[7:16] dann habe ich es als Entwickler einfacher.

[7:18] Ich folge diesem Standard.

[7:20] Ich weiß, ich habe eine langlebige Applikation.

[7:22] Diese API wird sich nicht sehr schnell ändern, sage ich mal.

[7:26] Und ich muss auch nicht meine Zeit mit Konfigurationen und Verdrahtungen verbringen,

[7:30] sondern ich kann das einfach so benutzen und es funktioniert.

[7:33] Das ist zumindest der Ansatz der Spezifikation.

[7:37] Jetzt haben wir schon gerade grob gestriffen, wie neue Standards in Java EE dazukommen.

[7:42] Da gibt es einen sogenannten Java Community Process, den JCP,

[7:46] der selber sogar als ein sogenannter Java Specification Request damals ins Leben gerufen wurde.

[7:54] Und dieser Community Process definiert den Prozess wie solche Spezifikationsanforderungen,

[8:01] also Spezification Requests, ihren Weg durchlaufen von dem initialen Vorschlag bis hin zur fertigen Umsetzung.

[8:11] Da gibt es also quasi einen ganzen Lebenszyklus, den so eine Spezifikation durchläuft.

[8:15] Und da gibt es eben einen fest definierten Prozess, an dem man sich dann halten muss.

[8:19] Dann wird zum Beispiel eine Anfrage gestellt und dann gibt es ein paar Mitglieder dieses Konsortiums,

[8:23] die dann gucken, ob sowas schon gibt oder ob das sinnvoll ist und was man da standardisieren müsste

[8:28] und wie man das dann umsetzen kann und so weiter und so fort.

[8:30] Das ist teilweise ein mehrjahrelanger Prozess, bis so eine Spezifikation dann fertig ist.

[8:35] Und diese Mitglieder, die kümmern sich dann eben darum, dass diese Spezifikation irgendwann einmal veröffentlicht wird

[8:41] und dann zum Beispiel Teil von Java EE meinetwegen wird.

[8:44] Muss es aber nicht. Es gilt auch für alle möglichen anderen Features.

[8:48] Beispielsweise, wenn wir irgendwie Typ-Inferenz in Java haben wollten oder so.

[8:51] Ja, das würde man auch über so eine Spezifikationsanforderung lösen.

[8:56] Das muss nicht automatisch in Java EE münden. Das kann auch in Java, die Programmiersprache, letztlich dann eingehen.

[9:01] Von daher, dieser Prozess ist für alle Features, die irgendwie in Java rein sollen, der gleiche.

[9:06] Und am Ende wird dann halt eben ausgewählt, so für Java EE Version X,

[9:10] nehmen wir jetzt diese 35 meinetwegen anderen Spezifikationen und bandeln die so zusammen,

[9:16] dass sie halt miteinander arbeiten und verpacken das Ganze als ein hübsches Paket.

[9:20] Und dann haben wir quasi eine neue Java EE Version.

[9:23] Also, es gibt den Java Community Prozess und der bearbeitet die Java Spezifikation Requests.

[9:29] Und durch diese Requests kommen halt die neuen Features in die Sprache und auch in die Plattform.

[9:35] So, wenn wir uns jetzt mal die Anwendungen in dieser Plattform anschauen,

[9:39] dann werden die etwas anders ausgeführt, als man es vielleicht von Java so kennt.

[9:42] Die meisten werden wahrscheinlich Java irgendwie aus der Berufsschule kennen oder aus dem Studium.

[9:46] Und da arbeitet man dann halt mit so einer Main-Methode und die wird dann auf der Konsole ausgeführt.

[9:50] Oder man macht irgendwie eine Swing-Anwendung oder jetzt ganz neuerdings mit JavaFX irgendwie eine GUI-Geschichte.

[9:56] Das ist alles wunderbar, funktioniert in Java EE aber ein bisschen anders.

[10:00] Und zwar ist der Ansatz von Java EE, dass das Programm, das wir da bauen, in einem sogenannten Container läuft.

[10:06] Und dieser Container, der stellt der Anwendung alle möglichen Sachen bereit, die sie so braucht.

[10:10] Wie zum Beispiel Verbindungen zu Datenbanken oder ein Naming,

[10:14] dass ich meinetwegen irgendwelche Services anhand eines Namens identifizieren kann.

[10:18] Oder zum Beispiel, wenn ich Messaging benutze, irgendwelche Queues und so weiter.

[10:22] Diese ganze Infrastrukturgeschichte, die, wenn ich sie per Hand schreiben müsste,

[10:26] ziemlich kompliziert wäre und aufwendig wäre, die liefert mir quasi dieser Container schon out of the box.

[10:31] Und der Container, das ist der sogenannte Application-Server.

[10:35] Das ist das Ding, in dem meine Anwendung läuft.

[10:38] Das heißt, ich kann nicht einfach auf der Konsole sowas sagen wie, hey, starte mal meine Java EE-Anwendung,

[10:42] sondern ich muss die in einen sogenannten Application-Server eben deployen.

[10:47] Das heißt, ich veröffentliche die in diesem Server und der stellt dann eben diese ganze Infrastruktur bereit,

[10:52] sorgt dafür, dass das alles da ist und startet dann meine Applikation.

[10:56] Wenn die Applikation dann zum Beispiel sagt, hey, ich hätte gerne eine Datenbankverbindung,

[11:00] dann sagt der Application-Server, ja klar, hier hast du sie.

[11:02] Vorausgesetzt natürlich die Konfiguration passt, der Name ist der gleiche und so weiter und so fort.

[11:06] Also der Application-Server stellt potenziell diese Infrastruktur bereit.

[11:10] Natürlich muss die Anwendung korrekt mit dem Application-Server kommunizieren

[11:14] und zum Beispiel nach der richtigen Datenbankverbindung fragen.

[11:16] Die muss es halt auch geben, logischerweise.

[11:18] Aber grundsätzlich ermöglicht das halt dem Entwickler, sage ich mal,

[11:22] diese ganze Infrastrukturgeschichte völlig außer Acht zu lassen.

[11:25] Ich sage einfach nur, ich brauche eine Datenbank, ich brauche eine JMSQ

[11:28] und ich sage, so und so soll die heißen und frage einfach den Application-Server,

[11:33] der gibt mir das und dann lege ich los.

[11:35] Ich habe also nicht diesen enorm vielen Setup-Code, den ich normalerweise hätte.

[11:39] Als Beispiel, wenn ich so Dependency Injection machen würde,

[11:42] vielleicht kennst du ja irgendwelche anderen Dependency Injection Frameworks,

[11:45] wo du dann irgendwie erstmal in der XML-Konfiguration festlegen musst,

[11:48] welche Instanz von welcher Klasse für welches Interface bereitgestellt werden soll.

[11:52] Oder das machst du irgendwie über Code und dann hast du erstmal 10 Zeilen Code,

[11:56] um diesen Dependency Injection Container zu starten, um irgendwelche Klassen zu registrieren

[12:00] und so weiter und so fort.

[12:01] Und diesen ganzen Kram kannst du im Prinzip sparen, wenn du einen Application-Server hast,

[12:05] denn das macht der alles automatisch.

[12:08] Ich muss also weder riesengroße XML-Dateien mit Konfiguration fliegen,

[12:12] noch in meinem Programm erstmal ganz viel Setup-Code schreiben,

[12:15] sondern ich sage einfach, hey, ich will eine Databank-Verbindung haben,

[12:18] und der Application-Server gibt mir die einfach.

[12:20] So jetzt mal ins Unreine gesprochen, so ganz bildlich dargestellt.

[12:25] Ich habe deutlich weniger Code, deutlich weniger Konfiguration

[12:28] und muss mich um diesen ganzen Kram halt nicht kümmern.

[12:30] Hat aber auch zur Folge, dass irgendwer anders sich darum kümmern muss.

[12:33] Das heißt, es wird einen Administrator geben, der diesen Application-Server veraltet

[12:36] und der da zum Beispiel die Datenbank-Verbindung konfiguriert und monitort und so weiter.

[12:41] Also irgendwer muss das natürlich tun, keine Frage.

[12:43] Und meistens machen das auch die Entwickler dann tatsächlich selber.

[12:46] Aber ich mache es halt eben nicht mehr in meinem Code und in meinem XML,

[12:49] sondern es ist halt eben zum Beispiel beim Application-Server in der Web-Oberfläche,

[12:53] der mir diese Funktionalitäten dann bereitstellt.

[12:55] Jetzt gibt es allerdings bei diesen Application-Servern im Java-EE-Umfeld

[12:58] zwei verschiedene sogenannte Profile.

[13:01] Und zwar einmal das Web-Profile und einmal das Full-Profile.

[13:04] Das Full-Profile, das bietet im Prinzip alle Funktionalitäten an, die Java-EE spezifiziert.

[13:09] Also alle 38 Stück.

[13:11] Das heißt, wenn ich irgendwie, ich weiß nicht, auf die Datenbank will oder REST oder SOAP

[13:15] oder WebSockets oder was auch immer machen will, das ist alles da.

[13:18] Und ich kann davon ausgehen, dass das Server das komplett anbietet.

[13:21] Beim Web-Profile geht es darum, dass nicht alle Spezifikationen implementiert sind,

[13:26] sondern nur ein paar, und zwar deutlich weniger.

[13:29] Ich glaube, das sind ungefähr 10 oder so, also wirklich ein Drittel ungefähr.

[13:33] Und bestimmte Spezifikationen, die man sehr selten braucht, sind dann z.B. nicht dabei.

[13:37] Wie z.B. die REST-Geschichten.

[13:40] JAX-RS, das ist das Framework, um REST-Services bereitzustellen,

[13:43] das ist z.B. im Web-Profile standardmäßig nicht drin.

[13:46] Und z.B. auch JMS oder die historisch bedingt sehr schwergewichtigen EJBs,

[13:52] die sind nicht dabei.

[13:54] Aber das Web-Profile umfasst z.B. sowas wie JSF fürs Frontend

[13:58] oder CDI, Context Independency Injection und so weiter.

[14:01] Also sage ich mal, für so eine klassische Web-Anwendung ist da alles Wichtige dabei.

[14:04] Aber wenn es dann ein bisschen ins Eingemachte geht

[14:07] und ich wirklich an Java Kernfunktionalität rein,

[14:09] oder das brauche, sage ich mal, auch für so eine knackige Enterprise-Anwendung,

[14:13] dann ist eben nicht mehr alles dabei.

[14:15] Und dann brauche ich wirklich so einen full Java-IE-Server,

[14:18] der mir das komplett anbietet.

[14:20] Warum gibt es jetzt die beiden unterschiedlichen Varianten?

[14:22] Naja, die Web-Anwendungen sind klassischerweise, oder sollten klassischerweise

[14:26] eher so ein bisschen leichtgewichtig sein.

[14:28] Ich will die knackig in ein paar Sekunden mal eben deployen können.

[14:31] Und wenn der Application-Server erstmal einen riesen Stack mit 35 Frameworks laden muss,

[14:35] obwohl ich die eigentlich alle gar nicht brauche,

[14:37] dann ist das natürlich Zeit und vor allem vielleicht auch Arbeitsspeicher

[14:40] und vielleicht auch Plattenplatz, der da eigentlich verloren geht,

[14:42] obwohl ich die ganzen Dinge gar nicht brauche.

[14:44] Genauso wie ich bei einem Web-Server, wenn ich den absichern,

[14:46] nicht erstmal alle möglichen Services installiere,

[14:48] wie FTP und Telnet und weiß der Geier was,

[14:51] obwohl das eigentlich niemand braucht,

[14:53] werde ich bei so einem Application-Server erstmal nur das nehmen,

[14:55] was ich wirklich haben will.

[14:56] Und zwar irgendwie die Datenbank-Anbindung und meinetwegen ein Web-Framework.

[14:59] Und der Rest drumherum, der interessiert mich erstmal nicht.

[15:01] Und genau deswegen gibt es diese beiden Profile.

[15:04] Für so eine klassische Web-Anwendung, ich sag mal CRUD-Operationen

[15:07] über so ein bisschen Datenbank-Tabellen im Hintergrund,

[15:09] da brauche ich halt eben nicht diese ganzen Frameworks, die ich genannt habe.

[15:13] Von daher lasse ich die da weg.

[15:15] Kann halt eben schnell und sag ich mal einfach und leichtgewichtig etwas deployen.

[15:20] Und wenn ich dann wirklich eine krasse Enterprise-Applikation mit SAP-Anbindung habe

[15:24] und ich weiß nicht, asynchronen Nachrichten und weiß der Geier was,

[15:27] dann nehme ich mir halt einen richtig dicken Server, in Anführungszeichen,

[15:30] der halt diesen ganzen Kram dann auch umsetzt.

[15:32] So, dann kommen wir doch mal ein bisschen zur Praxis.

[15:34] Was gibt es denn jetzt so für Application-Server im Java-Umfeld?

[15:37] Und so ein paar bekannte Namen, die sollte man schon mal gehört haben.

[15:40] Zum Beispiel Websphere, das ist von IBM.

[15:43] So eine richtig dicke Kiste, sag ich mal, die auch kommerziell ist und richtig teuer.

[15:47] Weblogic wäre quasi der offizielle Server von Oracle, vom Hersteller quasi selber.

[15:52] Dann gibt es noch JBoss als großen Vertreter.

[15:54] Und es gibt auch viele Open-Source-Geschichten, wie zum Beispiel Wildfly.

[15:58] Das ist die Open-Source-Variante von JBoss.

[16:00] Dann haben wir den Glassfish, das ist die Referenzimplementierung übrigens,

[16:03] also Referenz-Java-EE-Server von Oracle.

[16:06] Das ist kein kommerzielles Produkt, sondern Open-Source und gleichzeitig auch die Referenzimplementierung.

[16:12] Und es gibt zum Beispiel noch den Tommy, das ist so ein bisschen der Nachfolger von Tomcat.

[16:17] Tomcat ist kein kompletter EE-Server, sondern wie gesagt so ein Web-Profile oder so ein abgespeckter.

[16:22] Und der Tommy, davon gibt es gleich mehrere Varianten in verschiedensten Konstellationen.

[16:26] Den gibt es mit Web-Profile, den gibt es mit Web und REST, den gibt es als kompletten EE-Server und so weiter.

[16:31] Also da kann man sich genau die Versionen schnappen, die man wirklich braucht.

[16:34] Und es gibt zum Beispiel auch einen Application-Server mit dem Namen Jetty.

[16:37] Den kann ich dann zum Beispiel auch quasi aus meinem Java-Prozess heraus direkt selber starten.

[16:42] Und damit kann ich zum Beispiel meine Applikationen sehr schön automatisiert testen.

[16:45] Das ist quasi ein automatisierbarer Application-Server, den ich quasi mitliefern kann mit meiner Anwendung, wenn man so will.

[16:54] Und welche Spezifikationen sind jetzt genau Teil von Java EE?

[16:58] Also keine Angst, ich gehe jetzt hier nicht die 38 verschiedenen Spezifikationen durch.

[17:02] Das kann sich eh keiner merken und das ist auch irrelevant.

[17:04] Aber was man mal so ein paar wichtige gehört hat.

[17:06] Es gibt zum Beispiel die Enterprise Java Beans, das sind die EJBs.

[17:10] Dann gibt es die Servlets.

[17:12] Dann gibt es Java Server Pages, womit jahrelang viele Web-Anwendungen gebaut wurden.

[17:16] Dann gibt es zum Beispiel Web-Services.

[17:18] Es gibt JMDI für Lookups anhand von Namen.

[17:22] Es gibt JMS, Java Message Service.

[17:25] Es gibt eine Transaction API und eine Autorisierungs-API.

[17:30] Java Mail, XML, RPC, RESTful, tralala.

[17:35] Also wirklich ganz, ganz viele verschiedene Spezifikationen sind halt da zusammengefasst.

[17:39] Und ich nehme jetzt einfach mal ein paar Kernspezifikationen raus,

[17:42] die man wahrscheinlich, sage ich mal, in seinem Entwickleralltag dann tatsächlich auch mal anwenden wird.

[17:46] Es mag sein, dass du jetzt, wenn du mit Java arbeitest, tatsächlich auch irgendwie asynchrone Nachrichten über JMS verschickst.

[17:52] Das kann alles sein.

[17:53] Ich sage mal, für so eine klassische Web-Anwendung brauchen wir das allerdings nicht.

[17:56] Da brauchen wir irgendwie Zugriff auf eine Datenbank.

[17:58] Da brauchen wir ein bisschen Validierung und da brauchen wir ein Frontend.

[18:00] Und dann haben wir es eigentlich.

[18:02] Und deswegen gehe ich mal die wichtigsten Implementierungen aus meiner Sicht,

[18:05] sage ich jetzt mal, für den Alltag mal einmal kurz durch.

[18:07] Und da gibt es dann auch immer entsprechende Referenzimplementierungen.

[18:10] Denn, wie gesagt, diese Spezifikationen beschreiben eigentlich nur eine Schnittstelle.

[18:14] Das heißt, wenn ich dagegen arbeite, dann habe ich erstmal keine Implementierung.

[18:17] Ich weiß zwar, wie die API aussieht und wie meine Programmieraufrufe aussehen müssen,

[18:21] aber ich habe halt niemanden dahinter, der das tatsächlich dann auch umsetzt.

[18:24] Und deswegen sollte man vielleicht für die Kernspezifikationen wissen, wie die Referenzimplementierung heißen.

[18:30] Denn die sind natürlich immer dann am Puls der Zeit und setzen alle Funktionalitäten um,

[18:33] die in der Spezifikation stehen.

[18:35] Deswegen Referenzimplementierung.

[18:37] Wenn ich halt andere Frameworks benutze, muss es nicht unbedingt so sein,

[18:41] dass sie halt wirklich alles hundertprozentig so umsetzen.

[18:43] Deswegen würde ich mich für bestimmte Aufgaben auf diese Referenzimplementierung berufen

[18:47] und dann zum Beispiel, wenn ich irgendwie mit JPA auf den Datamarkt will,

[18:51] halt vielleicht Eclipse Link als Referenzimplementierung nutzen

[18:54] und nicht, was die Alternative wäre, Hibernate zum Beispiel.

[18:57] Wobei ich jetzt keinen Streit anfangen will, ob Hibernate besser ist oder schlechter als EclipsLink.

[19:02] Kann ich nicht bewerten, will ich auch gar nicht. Hibernate ist bestimmt genauso gut oder vielleicht sogar besser als EclipsLink.

[19:07] Aber ich wollte nur sagen, es gibt eben diese Referenzimplementierung und da kann man sich halt eben sicher sein, dass die alles umsetzen, was gefordert ist.

[19:14] Ich gehe jetzt einfach mal, wie gesagt, ein paar Spezifikationen durch.

[19:17] JSF, da wäre die Referenzimplementierung Mojara oder Mojara wird es geschrieben, aber ich schätze, es wird Mojara ausgesprochen.

[19:25] JSF, das ist das Frontend für die Webentwicklung.

[19:28] Damit kann ich also HTML oder XHTML, besser gesagt mit Java Codefragmenten beziehungsweise einer speziellen Java-ähnlichen Sprache, der Expression Language, mischen und dann auch sehr einfach zum Beispiel Webfrontends erstellen.

[19:43] Dann haben wir JPA, hatte ich eben schon gesagt, die Java Persistence API.

[19:46] Das ist quasi meine Datenbankabstraktion, ein objektrelationaler Mapper im Prinzip.

[19:50] Da ist die Referenzimplementierung das EclipsLink.

[19:53] Dann haben wir CDI, das ist Context and Dependency Injection.

[19:56] Das ist, wie der Name schon sagt, Dependency Injection.

[19:58] Und da ist die Referenzimplementierung Welt.

[20:01] Dann haben wir JaxRS, das ist die Bibliothek oder die Schnittstelle, um Rest-Web-Services zu veröffentlichen.

[20:08] Die Referenzimplementierung heißt Jersey.

[20:10] Und dann haben wir noch die Bean Validation.

[20:12] Das ist also mein Validierungs-Framework, wo ich dann zum Beispiel sagen kann, dass der Name nur 30 Zeichen lang sein darf und so weiter.

[20:18] Da ist die Referenzimplementierung Hibernate Validator.

[20:21] Und als letztes habe ich dann noch JaxWS dazugenommen, also für die Web-Services, die guten alten Soap-Web-Services,

[20:28] die in gefühlten 90% der Enterprise-Anwendungen immer noch eingesetzt werden und bei uns auch immer noch eingesetzt werden

[20:35] und auch viele Jahre noch im Ereignis bleiben werden.

[20:37] Dafür gibt es auch eine Referenzimplementierung und die heißt Metro.

[20:41] So, jetzt habe ich eigentlich schon ein bisschen vorweggenommen, was ich eigentlich jetzt erzählen wollte.

[20:44] Und zwar wollte ich mal so die aus meiner Sicht zentralen Spezifikationen durchgehen, die man auch tatsächlich bei der Programmierung braucht.

[20:50] Das fängt für mich ganz unten an bei der Datenbank.

[20:52] Das ist JPA, das ist die Java Persistence API und die legt fest, wie ich am besten in Java meine Objekte persistiere,

[21:00] also klassischerweise in eine relationale Datenbank ablege.

[21:04] Und da gibt es halt einen ganzen Haufen an Schnittstellen, wie ich das am besten machen kann

[21:08] und wie ich meine Klassen auszeichne, damit sie automatisch in der Datenbank landen im Prinzip.

[21:12] Und das definiert mir die Java Persistence API eben, das JPA.

[21:19] So, Referenzimplementierung Eclipse Link, wie gerade gesagt.

[21:22] Und wie mache ich das jetzt mit JPA? Was mache ich da eigentlich genau?

[21:25] Grundsätzlich schreibe ich einfach erst mal POJOs, also Plain Old Java Objects, wie du das wahrscheinlich auch kennst.

[21:32] Klasse machen mit Getter und Setter und Business-Logic drin und so weiter.

[21:36] Und diese Klasse, die annotiere ich dann mit bestimmten Annotations aus JPA.

[21:41] Und zwar schreibe ich ganz oben vor die Klasse zum Beispiel AddEntity.

[21:45] Entity, das ist so ein bisschen der Begriff, der jetzt festlegt, dass diese Klasse auch in der Datenbank irgendwo persistiert werden soll.

[21:51] Eine Entität, das kennen wir eigentlich schon aus dem Entity Relationship Model.

[21:55] Eine Entität ist vergleichbar mit einem Objekt.

[21:58] Ein Objekt aus der Objektorientierung, das beschreibe ich ja immer als ein Ding der realen Welt.

[22:02] Und nichts anderes programmieren wir ja gerade, wenn wir diese Entitätsklasse bauen.

[22:06] Wobei die Entität noch ein bisschen was anderes ist.

[22:09] Die Entität hat nämlich eine wichtige Eigenschaft, die ist eindeutig identifizierbar.

[22:13] Wenn ich mir also eine Entität anschaue, dann weiß ich, dass ich sie zum Beispiel anhand eines Schlüssels jederzeit eindeutig quasi wiederfinden kann.

[22:20] Das unterscheidet zum Beispiel auch die Entität von einem sogenannten Value-Objekt, was allein aufgrund seiner Eigenschaften definiert ist.

[22:27] Eine Entität hat eben zusätzlich zu diesen Eigenschaften noch eine, ja ich sag's mal ganz blöd, eine ID im Prinzip.

[22:33] Und diese Entität, die schreiben wir jetzt quasi an unsere Java-Klasse dran.

[22:38] addEntity schreiben wir davor und dadurch weiß jetzt JPA, aha, diese Klasse wird irgendwo in der Datenbank persistiert.

[22:44] Die wird dort abgelegt.

[22:46] Wie die da jetzt genau abgelegt wird, das entscheiden wir anhand einer weiteren Annotation, nämlich addId.

[22:53] id, wie ich gerade schon sagte, das schreiben wir genau an das Attribut, was diese Entität jetzt eindeutig identifiziert.

[22:58] Also wenn ich jetzt zum Beispiel, ja meinetwegen, sowas habe wie private long id,

[23:03] also ein ganz einfaches Zahlenfeld, wo eben diese ID drin steht, dann schreibe ich davor addId

[23:08] und dadurch weiß dann mein JPA, dass dieses Attribut in der Datenbank den Schlüssel enthält im Prinzip.

[23:15] Ansonsten wird JPA hergehen und einfach jedes Attribut, was es in dieser Klasse findet, auf eine entsprechende Spalte in der Tabelle mappen.

[23:22] Also wenn ich da einfach ein Attribut habe mit dem Namen Name, ja, ich bin gerade sehr einfallslos,

[23:28] dann wird JPA in der Datenbank eine entsprechende Spalte anlegen mit dem Namen Name,

[23:34] beziehungsweise wenn es die Tabelle nicht anlegt, weil es sie schon gibt, wird es halt eben eine Spalte mit dem Namen Name erwarten

[23:40] und daraus die Daten ziehen, um sie in das Attribut zu packen.

[23:43] Es ist also quasi schon fast wie bei Ruby on Rails, wo ich ganz viel Convention over Configuration habe.

[23:48] Das heißt, ich konfiguriere nicht in meiner Java-Klasse mit 95 Annotationen, wie die Spalten in der Datenbank heißen,

[23:54] sondern ich gehe einfach davon aus, dass die Spalten exakt genauso heißen wie die Attribute in meiner Klasse.

[23:59] Und wenn ich davon ausgehe, muss ich einfach auch in meiner Klasse nichts weiter hinschreiben.

[24:02] Ich muss einfach nur sagen, welches Attribut von meinen 27 in meiner Klasse ist denn die ID, denn das kann JPA nicht alleine rausbekommen,

[24:10] aber die restlichen Spalten quasi werden einfach eins zu eins aus den Namen der Attribute übernommen.

[24:16] Und die dürfen dann auch wunderbar private sein zum Beispiel.

[24:19] Ich kann also auch die Kapselung einhalten, wie ich es auch aus Objektorientierung gelernt habe.

[24:22] Und JPA sorgt dann dafür, dass es die Daten irgendwie aus der Datenbank ausliest und zum Beispiel Instanzen der Objekte dann erzeugt

[24:29] und die Attribute entsprechend korrekt setzt.

[24:31] Im Prinzip muss ich nicht mehr tun.

[24:33] Also ich schreibe addEntity davor und ich spezifiziere ein Attribut als ID und die restlichen Spalten werden halt eins zu eins übernommen.

[24:41] Ich kann aber auch dann noch meine Beziehungen abbilden.

[24:44] Also wenn ich jetzt mehrere Entitäten habe, oder besser gesagt Entitätstypen,

[24:49] also ich wiederhole das nochmal kurz.

[24:51] In der Objektorientierung sprechen wir von Objekt und Klasse.

[24:54] Ein Objekt ist eine Instanz der Klasse.

[24:57] Und wenn wir jetzt hier von Datenbankmodellierung sprechen, dann reden wir von Entitäten und Entitätstypen.

[25:02] Die Entitätstypen entsprechen quasi den Klassen und die Entitäten, das sind die konkreten Objekte.

[25:07] Also meinetwegen das Auto mit der ID 57, das ist die eine Entität.

[25:11] Und diese Entität kann natürlich auch in Beziehung zu anderen Entitäten stehen.

[25:15] Aber ich meinte jetzt eigentlich gerade, dass wir natürlich die Entitätstypen zueinander in Beziehung setzen.

[25:19] Also wie im Entity Relationship Model, wo wir unsere Kainalitäten abbilden.

[25:23] Meinetwegen ein Auto hat mehrere Fahrer.

[25:27] Dann muss ich das ja irgendwie in meiner Datenbank auch ablegen.

[25:30] In diesem Fall Auto und Fahrer ist wahrscheinlich so eine M zu N Beziehung.

[25:33] Ein Fahrer kann ja auch mehrere Autos fahren.

[25:35] Und das muss ich jetzt irgendwo auch in meinem Datenmodell hinterlegen.

[25:38] Und auch vor allem in meinem Objektmodell, also in meiner Klasse, die ich in Java programmiere.

[25:42] Und das muss ich irgendwie Java beibringen, denn das kann er nicht von alleine wissen, wie diese Dinger in Beziehung stehen.

[25:48] Und üblicherweise würde ich jetzt eben in der Objektorientierung mit Referenzen arbeiten.

[25:52] Das heißt meine Klasse Auto, die hat dann zum Beispiel eine List of und dann meinetwegen Personen.

[25:58] Und die heißt dann einfach Fahrer.

[26:00] Das heißt ich habe zwei Klassen, Auto und Person.

[26:03] Und eine Person kann halt als Fahrer eines Autos agieren.

[26:07] Und weil es eben mehrere Fahrer geben kann, hat halt so ein Auto einfach eine List of Personen.

[26:12] Das ist auf Objektebene wunderbar.

[26:15] Ich kann direkt auf die Objekte zugreifen.

[26:17] Ich habe jetzt also nicht irgendwie sowas wie Fremdschlüssel oder sowas.

[26:20] Das passt auch nicht in meine objektorientierte Welt.

[26:22] Das ist eben eine Datenbankdenkweise.

[26:24] Aber die wenden wir hier in der Objektorientierung nicht an.

[26:26] Sondern ich arbeite einfach mit Objektreferenzen.

[26:28] Das Problem ist, wenn ich diese Referenzen in die Datenbank jetzt persistieren will, dann geht das nicht.

[26:33] Denn die Datenbank kennt sowas wie Objektreferenzen nicht.

[26:35] Die arbeitet nämlich mit Fremdschlüsseln.

[26:37] Und genau diese Übersetzung, die macht jetzt dieser objektrelationale Mapper für uns im Hintergrund.

[26:43] Und dafür spezifiziert JPA eben die Schnittstelle.

[26:46] Ich kann also jetzt in meiner Klasse genau dieses Mapping hinterlegen.

[26:50] Und zwar muss ich dafür jetzt einfach nur beibringen, der Klasse Auto,

[26:54] dass zum Beispiel dieses Attribut, was ich da gerade angelegt habe mit dem Namen Fahrer, diese List of Personen,

[26:59] dass das jetzt entsprechend eine Beziehung zu einer anderen Entität sein soll.

[27:03] Und ich muss jetzt über eine bestimmte Annotation dann zum Beispiel sagen, wie die Schlüsselspalte heißen soll

[27:08] und ob das zum Beispiel beim Lesen der Daten aus der Datenbank automatisch mitgeladen werden soll

[27:13] oder erst wenn ich auf die Werte zugreife.

[27:15] Also ein Lazy oder ein Eager Loading, so heißt das dann und so weiter.

[27:19] Und dafür gibt es halt einige Annotationen, wie ich das ablegen kann.

[27:22] Da gibt es zum Beispiel die Annotation at many to many.

[27:25] Damit kann ich zum Beispiel eine M zu N Beziehung in meinem Klassenmodell abbilden.

[27:30] Und JPA ist jetzt so intelligent und erkennt anhand dieser Abbildung, wie es die Daten in der Datenbank ablegen soll.

[27:36] Er weiß jetzt zum Beispiel bei einer M zu N Beziehung,

[27:39] aha, da muss ich wohl so eine Lookup-Tabelle in der Mitte, eine M zu N Zuordnungstabelle anlegen,

[27:44] wo die beiden Fremdschlüssel auf die Entitäten drin sind.

[27:47] Und das macht er automatisch im Hintergrund, ohne dass ich noch mehr irgendwie konfigurieren muss.

[27:51] Ich muss ihm einfach nur sagen, das ist die eine Klasse und die hat eine Beziehung zu der anderen

[27:56] und das ist entweder 1 zu 1, 1 zu N oder M zu N und den Rest, den macht JPA von alleine.

[28:01] Das ist eben genau der Sinn von so einem Objekt-Relational-Mapper,

[28:03] dass ich mich nicht mit beiden Welten auseinandersetzen muss,

[28:06] sondern dass ich am besten in meinem Code einfach nur schreibe, wer wen kennt

[28:09] und die Datenbank-Geschichten im Hintergrund, die werden quasi auf Knopfdruck automatisch generiert.

[28:14] Wenn ich jetzt die Daten aus der Datenbank rausholen will,

[28:17] auch dafür spezifiziert JPA eine nette Geschichte und zwar die sogenannte JPQL.

[28:23] Das ist die Java Persistence Query Language.

[28:26] Und damit kann ich sehr ähnlich zu SQL meine Daten abfragen.

[28:30] Nur, dass ich eben nicht mit Tabellen hier arbeite, sondern mit Klassennamen.

[28:33] Das heißt, ich würde nicht sowas machen wie SELECT Sternchen FROM Person oder sowas,

[28:37] sondern ich würde machen SELECT Sternchen FROM Person, allerdings mit großem P,

[28:41] weil wir hier von einer Klasse Person sprechen.

[28:44] Und ich kann jetzt auch über die Namen der Attribute, zum Beispiel WHERE abfragen und so weiter machen.

[28:48] Die Syntax ist quasi identisch zu SQL.

[28:51] Nur, dass wir eben nicht mit Datenbank-Tabellen arbeiten, sondern mit echten Objekten in Anführungszeichen

[28:56] und zum Beispiel auch mit Punkt Name direkt auf die Attribute zugreifen können.

[29:00] Ist eine tolle Sache.

[29:02] Das Problem dabei ist, dass das Ganze String-basiert ist.

[29:05] Das heißt, es gibt kein Syntax-Highlighting.

[29:07] Es gibt kein Syntax-Check zum Beispiel meiner IDI.

[29:10] Das wird erst zur Laufzeit herausgefunden, ob das Ding überhaupt gültig war oder nicht.

[29:14] Also ob ich mich irgendwo zum Beispiel vertippt habe bei einem Klassennamen oder sowas.

[29:17] Das sehe ich bei der Programmierung nicht, sondern erst, wenn ich es ausführe.

[29:20] Das ist also der zentrale Nachteil von JPQL.

[29:22] Ansonsten ist das Ding super lesbar.

[29:24] Denn wenn ich SQL kann, kann ich im Prinzip auch JPQL.

[29:27] Deswegen gibt es noch einen weiteren Punkt, und zwar die Criteria-API.

[29:31] Also quasi die Kriterien-API, wenn man so will auf Deutsch.

[29:35] Darüber kann ich typisiert auf meine Inhalte zugreifen.

[29:38] Ich schreibe also keine Strings, sowas wie SELECT Sternchen FROM irgendwas,

[29:42] sondern ich schreibe quasi typisiert über Methoden solche Dinge,

[29:46] wie zum Beispiel, keine Ahnung, ich weiß es jetzt nicht genau,

[29:49] aber PERSON, PUNKT, SELECT und dann in Klammern irgendwie sowas,

[29:52] dass ich also schon durch den Compiler prüfen lassen kann,

[29:55] ob das, was ich da eingebe, auch wirklich korrekt ist.

[29:57] Der Nachteil ist, dass es nicht mehr so schön lesbar ist.

[29:59] Der Vorteil ist halt, der Compiler checkt, ob ich irgendwo einen Fehler drin habe.

[30:02] Von daher muss ich immer genau wissen, was möchte ich denn haben.

[30:05] Habe ich zum Beispiel ganz komplexe Abfragen,

[30:07] dann ist es vielleicht sinnvoll, dass ich die möglichst lesbar gestalte und JPQL nehme.

[30:11] Wenn ich aber einfach durch den Compiler unterstützt werden möchte

[30:14] und möglichst wenig Fehler einbauen möchte,

[30:16] nehme ich vielleicht eher die Criteria-API, weil der Compiler das halt eben checken kann.

[30:20] So, kurze Frage noch am Ende zu JPA.

[30:23] Kann man damit auch NoSQL anbinden?

[30:25] Das muss natürlich heute sein.

[30:27] Wenn man modern und hip und fesch sein will,

[30:29] dann bindet man natürlich auch NoSQL-Datenbanken an,

[30:32] wie zum Beispiel MongoDB und so weiter.

[30:34] Und das geht auch, allerdings nicht direkt mit JPA

[30:38] und zum Beispiel der Implementierung Hibernate, die dahinter liegt.

[30:41] Denn das ist halt schon ein komplett anderes Konzept bei NoSQL-Datenbanken.

[30:45] Aber es gibt ein nettes Framework, das heißt Hibernate OGM.

[30:48] Das steht für Object Grid Mapper.

[30:50] Und das ist quasi genau die Lösung für das Problem.

[30:53] Dann kann man mit der Standard-JPA-Syntax, die man auch schon kennt,

[30:56] mit dem Framework im Hintergrund auch zum Beispiel auf dokumentenorientierte Datenbanken,

[31:00] wie zum Beispiel MongoDB zugreifen,

[31:02] habe ich auch schon selbst gemacht, funktioniert einwandfrei, kein Problem.

[31:05] Ist also eine Dependency, die man eintragen muss

[31:07] und schwupp kann ich auch auf alle möglichen NoSQL-Datenbanken zugreifen.

[31:10] MongoDB war jetzt nur ein Beispiel.

[31:12] Es gibt noch wirklich für alle möglichen anderen Datenbanken.

[31:14] Keine Ahnung, Cassandra und…

[31:16] Also fällt mir jetzt gerade alles nicht ein.

[31:19] Aber da wir auf jeden Fall 20 verschiedene Datenbanken haben,

[31:21] die implementiert auf jeden Fall, damit kann man eigentlich alles abdecken,

[31:23] was man heutzutage so an NoSQL-Datenbanken anbinden können sollte.

[31:27] Ja, kommen wir zum nächsten Punkt.

[31:29] JPA ist für mich abgehakt, Datenbank.

[31:31] Das war es dann zu dem Thema.

[31:33] Wir haben aber auch noch das Frontend, nämlich unsere HTML-Seiten.

[31:36] Und dazu wird das JSF benutzt, die Java Server Faces.

[31:40] Das ist quasi das Framework, was es mir ermöglicht,

[31:43] eben recht einfach HTML-Frontends zu erzeugen.

[31:47] Und das Ganze sieht dann so aus, dass ich quasi xHTML schreibe.

[31:51] Da gibt es dann vordefinierte Tags,

[31:53] die dann zum Beispiel auch aus so einer Bibliothek von JSF kommen.

[31:55] Da würde ich dann zum Beispiel nicht eingeben

[31:58] sondern ich mache dann halt im Namespace von JSF

[32:03] sowas wie h.inputtext und so weiter und so fort.

[32:07] Das heißt, ich schreibe nicht direkt HTML,

[32:10] sondern ich schreibe quasi einen XML-Dialekt,

[32:12] der dann übersetzt wird in die entsprechenden HTML-Elemente.

[32:15] Aber ich kann dann relativ einfach zum Beispiel auch

[32:18] auf meine Java Beans im Hintergrund zugreifen.

[32:21] Das Konzept ist also, ich schreibe eigentlich XML

[32:23] und hinter diesem XML sitzt noch so eine Java-Klasse,

[32:26] die dann auch gerne Backing Bean genannt wird.

[32:29] Bean, reden wir hier von Kaffeebohnen,

[32:31] um in der Java-Sprechweise zu bleiben.

[32:34] Und diese Bean, die ist dann dafür zuständig,

[32:36] die Logik in dieser Seite abzubilden.

[32:38] Das heißt, die füllt zum Beispiel die Daten

[32:40] für die Textfelder aus der Datenbank

[32:42] oder die nimmt meine Requests entgegen,

[32:44] wenn ich Sachen speichern will und so weiter und so fort.

[32:46] Prüft Logik und so weiter.

[32:48] Das heißt, ich habe das genau getrennt.

[32:50] Ich habe im Frontend mein XML quasi,

[32:53] was mehr oder weniger genauso aussieht wie HTML,

[32:55] nur vielleicht mal hier und da ein bisschen anders geschrieben

[32:57] und mal mit einem anderen Attribut und so weiter.

[32:59] Und dahinter habe ich halt so eine Java-Klasse, die Logik enthält.

[33:02] Und ich kann dann über eine weitere Spezifikation,

[33:04] über die EL, die Expression Language,

[33:06] relativ einfach in meinem XML

[33:08] auch tatsächlich auf die Attribute

[33:10] der Java Bean im Hintergrund zugreifen.

[33:12] Ich könnte also zum Beispiel einfach an so ein Textfeld dranschreiben,

[33:15] pack hier bitte mal den Inhalt des Attributs Name

[33:18] aus der Klasse XY rein.

[33:20] Und das geht dann wirklich in einer Zeile.

[33:22] Da muss ich jetzt also nicht ganz große Aufrufe machen.

[33:25] Und ich leite das dann zum Beispiel ein,

[33:27] indem ich schreibe hash geschweifte Klammer auf

[33:29] und dann meinetwegen meine Bean Punkt Name geschweifte Klammer zu.

[33:33] Das ist also wirklich ein ganz simpler, kleiner Ausdruck,

[33:36] eben in dieser Expression Language.

[33:38] Das ist also, wie man es auch aus anderen Webframeworks kennt,

[33:40] zum Beispiel Ruby on Rails.

[33:42] Da mache ich das auch so,

[33:44] dass ich quasi meinen variablen Ausdruck

[33:46] zum Beispiel mit dem Hash einleite.

[33:48] Und dann kann ich das direkt eins zu eins da ausgeben.

[33:50] Also mein Frontend sieht eigentlich relativ,

[33:52] sag ich mal, clean aus.

[33:54] Ich habe so ein bisschen XML und dazwischen

[33:56] ein bisschen Expression Language und dann war es das schon.

[33:58] Ich kann natürlich auch so etwas machen wie Schleifen.

[34:00] Das geht auch alles im Frontend.

[34:02] Wenn ich zum Beispiel eine ganze Tabelle ausgeben will

[34:04] über mehrere, über eine Liste meinetwegen,

[34:06] dann geht das auch.

[34:08] Aber ich habe eigentlich keine Logik in meinem Frontend,

[34:10] sondern wirklich nur die Präsentation.

[34:12] Und die gesamte Logik dahinter liegt in einer sauberen Java Klasse,

[34:15] die ich dann natürlich auch testen kann und so weiter.

[34:17] Das ist im Prinzip das Konzept von JSF.

[34:19] Was man vielleicht noch erklären können sollte,

[34:21] ist, was ein Servlet ist.

[34:23] Das kommt nämlich auch immer wieder hoch,

[34:25] dieser Begriff.

[34:27] Ein Servlet, das ist nichts weiter als eine Java-Klasse,

[34:29] die meine Requests verarbeitet.

[34:31] Das heißt im Prinzip gerade mal diese Backing Bean,

[34:33] die ich da gerade genannt habe,

[34:35] das ist im Prinzip ein Servlet,

[34:37] denn da geht mein HTTP-Request rein

[34:39] und die kümmert sich darum,

[34:41] einen HTTP-Response daraus zu machen

[34:43] oder schon so ein Servlet.

[34:45] Und zum Schluss haben wir dann noch

[34:47] zwei andere kleine Spezifikationen,

[34:49] die ich gerne noch mal unterbringen würde,

[34:51] die man auch häufig braucht heutzutage,

[34:53] und zwar einmal CDI.

[34:55] Eben schon erwähnt, Contexts and Dependency Injection.

[34:57] Das ist sehr wichtig,

[34:59] wenn ich meine Dependencies injizieren möchte,

[35:01] wie der Name auch schon sagt.

[35:03] Denn ich möchte, wenn ich so eine komplexe Web-Anwendung habe,

[35:05] zum Beispiel, wo ich irgendwie

[35:07] Repositories habe und Services und Backing Beans

[35:09] und weiß der Geier nicht,

[35:11] dass ich irgendwie miteinander interagieren muss,

[35:13] dann wird das ganz schön schwierig,

[35:15] die alle in der richtigen Reihenfolge zu instanziieren

[35:17] und dann jeweils einander als Abhängigkeit unterzujubeln.

[35:19] Und von daher gibt es ein komplettes Framework,

[35:21] was sich einfach darum kümmert,

[35:23] diese Abhängigkeiten aufzulösen.

[35:25] Ich schreibe zum Beispiel einfach in meine Klasse rein,

[35:27] hey, diese Klasse braucht meinetwegen

[35:29] einen Datenbank-Repo.

[35:31] Und dann schreibe ich einfach ein AddInject

[35:33] zum Beispiel vor das Attribut dieses Repos

[35:35] und dann wird mir das einfach automatisch injiziert.

[35:37] Ich muss keinen Constructor dafür anlegen,

[35:39] ich muss keinen Setter dafür anlegen, gar nichts.

[35:41] Ich kann ein Private-Attribut anlegen

[35:43] und schreibe einfach AddInject davor

[35:45] und der Container, der kümmert sich halt darum,

[35:47] eine Implementierung für dieses Ding,

[35:49] was ich da eben haben will, zu suchen,

[35:51] instanziiert die und injiziert mir die,

[35:53] ohne dass ich irgendwas dafür tun muss.

[35:55] Naja, ein bisschen muss ich schon tun,

[35:57] und zwar das Ding, was injiziert werden soll,

[35:59] das muss einen parameterlosen Constructor haben.

[36:01] Das leuchtet, glaube ich, auch ein, sonst kann der Container

[36:03] natürlich keine Instanz erzeugen.

[36:05] Wenn es Abhängigkeiten gäbe,

[36:07] in den Constructor reingeben muss,

[36:09] meinetwegen eben die Name, ID und weiß der Geier was,

[36:11] wie soll der Container das natürlich

[36:13] zu Laufzeit wissen? Das kann er nicht.

[36:15] Von daher, alle diese Dinge, die hier quasi

[36:17] durch den Container gemanagt werden,

[36:19] die müssen alle einen parameterlosen Constructor haben,

[36:21] sonst kann der Container

[36:23] sie einfach nicht instanziieren.

[36:25] Aber wenn das dann der Fall ist, wie gesagt,

[36:27] dann schreibe ich einfach irgendwo hin,

[36:29] hey, ich hätte ganz gerne ein Objekt dieser Klasse

[36:31] und schwupp, kriege ich das halt einfach,

[36:33] ohne irgendetwas dafür tun zu müssen.

[36:35] Das finde ich also sehr gut und das erleichtert einem

[36:37] die Arbeit wirklich enorm. Und ich muss das

[36:39] auch nicht irgendwie in riesengroßen XML-Dateien

[36:41] konfigurieren. Wenn ich zum Beispiel ein Interface

[36:43] habe und ich sage, ich hätte das ganz gerne

[36:45] injected und es gibt nur eine einzige

[36:47] Klasse, die dieses Interface implementiert,

[36:49] dann ist der Container schlau genug, das zu erkennen

[36:51] und instanziiert mir das. Und wenn

[36:53] es eine Abhängigkeit gibt, die er nicht

[36:55] auflösen kann, als Beispiel,

[36:57] ich habe wieder das Interface, aber ich habe zwei Klassen,

[36:59] die das Interface implementieren, dann wird der Container

[37:01] die Anwendung gar nicht starten. Dann wird er mir nämlich sagen,

[37:03] Moment mal, du hast hier eine Abhängigkeit definiert,

[37:05] die kann ich nicht auflösen, denn ich kann nicht entscheiden,

[37:07] welche Instanz du haben willst. Das heißt,

[37:09] diese Anwendung starte ich gar nicht erst.

[37:11] Das ist also relativ schön. Ich kriege das Ding

[37:13] gar nicht hochgefahren, wenn ich

[37:15] diese Abhängigkeit nicht aufgelöst bekomme.

[37:17] Also als Entwickler habe ich es ziemlich einfach.

[37:19] Ich sehe nämlich direkt beim Start der Anwendung, ob ich irgendwas falsch gemacht habe.

[37:21] Also einfacher geht es fast nicht.

[37:23] Und zuletzt habe ich noch ein wichtiges

[37:25] Framework, und zwar JAX-RS

[37:27] für REST-Services. Komplett ausgesprochen

[37:29] heißt das Ding die Java API

[37:31] for RESTful Web Services.

[37:33] JAX-RS. Und das Ding wird

[37:35] benötigt, um eben REST-Ressourcen

[37:37] anbieten zu können. Also eine schöne REST-API,

[37:39] wie eigentlich jede

[37:41] Web-Anwendung, die heutzutage was auf sich hält,

[37:43] es tun sollte. Und das kann man

[37:45] wirklich sehr, sehr einfach machen. Also es gibt

[37:47] schon fast keine Ausrede mehr, das mit Java nicht zu tun,

[37:49] denn das sind wirklich zwei, drei Annotationen,

[37:51] die ich an meine Klasse packe, und schwuppdiwupp

[37:53] kann ich das Ding über REST aufrufen.

[37:55] Also es ist wirklich super einfach.

[37:57] Und das Ganze komplett typisiert. Ich kann

[37:59] zum Beispiel, wenn ich eine Methode habe, die mir irgendwie

[38:01] Autos zurückliefert, kann ich einfach

[38:03] sowas machen wie public list of

[38:05] auto, get all

[38:07] cars, oder, na gut, das wäre jetzt doof,

[38:09] get autos meinetwegen.

[38:11] Wenn ich sowas habe, schreibe ich einfach ein

[38:13] add get davor, und ein

[38:15] add produces, und dann in

[38:17] Klammern media type application json.

[38:19] Und das reicht schon aus,

[38:21] und ich kann das Ding im Webbrowser aufrufen

[38:23] unter einem Pfad, und dann kriege ich halt eine

[38:25] JSON-Repräsentation meines Autos

[38:27] geliefert. Ohne, dass ich irgendwie

[38:29] konfigurieren muss, wie die Darstellung

[38:31] funktioniert, wie die Serialisierung

[38:33] funktioniert, und so weiter. Das macht das Grimlock komplett

[38:35] alleine. Und das ist wirklich

[38:37] super trivial. Ich kann wirklich,

[38:39] ich habe es mir mal in einem Beispiel angeguckt, mit vier

[38:41] Annotationen kann ich eine komplette

[38:43] Klasse als REST-Ressource

[38:45] freigeben. Das ist wirklich

[38:47] einfach, und das finde ich richtig cool

[38:49] gelöst, und das kann man auch sehr gut nachvollziehen.

[38:51] Und wie ich finde,

[38:53] ja, für die Praxis top. Ich

[38:55] habe das sehr gerne eingesetzt, und

[38:57] habe jetzt zum Beispiel auch für meine

[38:59] Beispielanwendungen, für meinen Talk auf der

[39:01] CeBIT dieses Jahr, genau das genutzt,

[39:03] um ein AngularJS Frontend

[39:05] über meine Java-EE-Anwendung zu packen.

[39:07] Weil es wirklich so einfach war. Ich gebe alle

[39:09] Ressourcen einfach als REST-Ressource

[39:11] frei. Ich habe automatisch GET, POST, PUT,

[39:13] was auch immer ich haben will, das kann ich selber spezifizieren.

[39:15] Und meine Angular-App zieht sich halt die

[39:17] Daten, kriegt direkt JSON ausgeliefert,

[39:19] und kann das Ding direkt verarbeiten und im Frontend anzeigen.

[39:21] Also, einfacher geht es eigentlich nicht.

[39:24] So, damit wäre ich jetzt mit meiner kleinen LZK zum Thema Java EE durch. Wir

[39:29] haben jetzt auch, glaube ich, die wichtigsten Sachen abgehakt. Wir haben

[39:31] den Datenbankzugriff, wir haben Dependency Injection, wir haben das Frontend. Ja, was

[39:35] will man mehr? Damit kann ich ja schon mal eine lauffähige, ach ja, REST natürlich. Wie

[39:38] konnte ich das vergessen, ja? Aber damit können wir auf jeden Fall jetzt eine

[39:41] komplette Web-Anwendung von vorn bis hinten bauen mit Java EE. Von daher

[39:44] reicht mir das jetzt für heute für meine LZK zu dem Thema. Ich hoffe, es war ein

[39:49] bisschen was Spannendes für dich dabei. Vielleicht hast du ja noch ein bisschen was Neues

[39:51] dazugelernt. Dass sowas jetzt in der Abschlussprüfung direkt so abgefragt

[39:55] wird, halte ich für unwahrscheinlich. Man kann ja nicht von allen Prüflingen

[39:58] erwarten, dass sie Java können und Java EE auch schon mal gar nicht. Ich kann die

[40:02] Prüflinge natürlich auch nicht zu Ruby on Rails abfragen, ja? Das ist ja kein

[40:05] Allgemeinwissen, was wir haben, sondern das ist eine konkrete Programmiersprache. Von daher

[40:09] wird man höchstens über die allgemeinen Konzepte abgefragt werden, wie zum

[40:11] Beispiel eben Dependency Injection und so, ja? Allerdings, wenn du ganz konkret ein

[40:16] Abschlussprojekt umsetzt mit Java oder Java EE, dann darfst du natürlich auch davon

[40:21] ausgehen, dass man dich dazu fragt. Also wenn ich da Prüflinge sitzen habe, die mit

[40:24] Java EE gearbeitet haben und mir CDI nicht erklären können, dann haben die ein

[40:28] Problem. Denn das erwarte ich natürlich, wenn du die Programmiersprache und diese

[40:31] Plattform benutzt, dass du dich damit auch auskennst und mir fachlich dazu

[40:35] Rede und Antwort stehen kannst. Also, wenn du tatsächlich vorhast, ein Java EE-Projekt

[40:39] als Abschlussprojekt zu benutzen, hoffe ich, dass diese Episode für dich

[40:42] hilfreich war, denn dann waren schon quasi einige Prüfungsfragen dabei, denn

[40:47] genau so würde ich in einer möglichen Prüfung an die Sache rangehen. Ich würde

[40:50] erwarten, dass du alles das, was du da benutzt, vom Objektrelationalen Mapper

[40:54] bis Kontext- und Dependency Injection bis hin zu JSF und so weiter auch erklären

[40:59] kannst und nicht einfach nur anwenden kannst. In den Shownotes zur heutigen

[41:04] Episode habe ich noch einen Haufen Links reingepackt zu offiziellen Dokumentationen

[41:09] und Wikipedia-Artikeln, zu diesem ganzen Kram, den wir heute besprochen haben.

[41:12] Guck da gerne mal rein. Wenn das dein Projektthema zum Beispiel trifft, dann

[41:16] kannst du gar nicht genug über diese Technologien wissen. Und davon abgesehen,

[41:20] das ist nicht nur für die Prüfung relevant, sondern auch für deine tägliche Arbeit.

[41:22] Wenn du wirklich gut programmieren willst, solltest du auf jeden Fall verstehen,

[41:26] was du da tust und wie die Sachen zusammenhängen. Also schau gerne mal rein

[41:29] unter anwendungsentwicklerpodcast.de slash 54, also die Ziffern 5 und 4,

[41:34] für die heutige 54. Episode. Und wenn du schon im Blog bist, dann schau doch mal auch

[41:39] im Blog tatsächlich vorbei. Letzte Woche habe ich nämlich einen fantastischen Bookmark oder

[41:44] meinen Link der Woche veröffentlicht. Einen Fachartikel habe ich leider nicht geschrieben,

[41:48] weil ich, wie gerade schon erwähnt, auf der CeBIT letzte Woche meinen Vortrag gehalten habe.

[41:51] Eben nämlich zufällig genau zum Thema Java EE. Und zwar Leichtgewichtige Webentwicklungen mit

[41:57] Java EE. Passt also haargenau zu dieser Lernzielkontrolle im Prinzip. Aber ich habe

[42:01] am Freitag einen Link der Woche veröffentlicht. Und zwar, wie funktionieren relationale Datenbanken.

[42:06] Und das ist also wirklich ein ganz toller Artikel. Der ist mehrere Seiten lang. Nicht nur Seiten,

[42:10] das ist fast ein halbes Buch quasi. Komplett kostenfrei verfügbar. Und der geht da komplett

[42:15] ins Detail, wie wirklich eine relationale Datenbank konkret im Hintergrund funktioniert.

[42:19] Mit Query-Optimization. Und der erklärt Bäume und Listen und Arrays und also alles Mögliche,

[42:25] was man braucht, um zu verstehen, wie ein Datenbanken funktioniert. Und das fand ich

[42:28] einfach faszinierend. Also wenn du zum Beispiel täglich mit relationalen Datenbanken arbeitest,

[42:32] aber gar nicht so genau weißt, wie die eigentlich intern funktionieren,

[42:35] unbedingt eine Leseempfehlung. Schau dir das mal an. Also einen besseren Artikel,

[42:40] der auch noch kostenfrei ist vor allem. Zu diesem Thema habe ich persönlich noch nicht gefunden.

[42:45] Ansonsten würde ich mich wie immer freuen, wenn du mich weiterempfiehlst, wenn es dir gefallen hat.

[42:48] Wenn es dir nicht gefallen hat, gib mir gerne ein Feedback. Schreib mir eine Mail an

[42:51] mail.anwöchensentwicklerpodcast.de oder gib mir ein Feedback direkt unter der Episode oder über

[42:57] eines der zahlreichen sozialen Netzwerke. Du kannst mich eigentlich überall finden,

[43:00] wenn du nach meinem Namen suchst. Und ganz besonders würde ich mich freuen,

[43:02] wenn du dich in mein Newsletter einträgst. Unter anwöchensentwicklerpodcast.de

[43:05] slash Newsletter kannst du das tun. Dann kriegst du immer jede Woche einmal ein Update,

[43:09] was es aktuell an Neuigkeiten so gibt. Und vor allem auch Zugriff auf die Checklisten

[43:13] rund ums Abschlussprojekt, den Projektantrag, die Projektpräsentation und so weiter und so fort.

[43:18] Also wenn du magst, trage dich doch ein. Kostet auch nichts und du hast auch nichts zu verlieren.

[43:22] Wenn dir die Inhalte nicht gefallen, trage dich einfach wieder aus. Bzw. ich bin dir nicht böse

[43:27] drum. Nächste Woche werde ich dann mal wieder das Thema Abschlussprojekt aufgreifen. Und zwar

[43:31] habe ich jetzt schon ein paar Anfragen bekommen, ob ich nicht mal eine Episode machen kann,

[43:34] wie man denn mit der Projektarbeit quasi anfängt. Wie steigt man ein ins Abschlussprojekt? Fängt

[43:40] ja eigentlich schon mit dem Projektantrag an. Aber wenn es dann wirklich ans Tun geht,

[43:43] Projektantrag ist genehmigt und jetzt geht es los. Wie findet man denn einen Einstieg? Ich

[43:48] denke, da habe ich ein bisschen Tipps zusammengetragen, die ich nächste Woche mal

[43:51] vorstelle. Und vielleicht hilft es dir ja auch. Vielleicht bist du ja gerade in der

[43:53] Vorbereitungsphase oder sogar schon in der Umsetzungsphase. Ich nehme das ja hier schon

[43:57] im März 2016 auf. Das ist ja schon fast die heiße Phase für die Sommerprüfung. Von daher hoffe ich,

[44:02] dass du da wieder ein bisschen was rausziehen kannst. Wenn du noch konkrete Fragen zum Thema

[44:06] hast, schicke mir einfach eine Mail. Noch kriege ich da sicherlich was untergebracht. Ansonsten

[44:10] sage ich für heute erstmal vielen, vielen Dank fürs Zuhören und dann bis zum nächsten Mal. Tschüss.