Archiv für den Monat: Oktober 2019

Warum ist mir OpenSource so wichtig?

Seitdem ich profesionell Software entwickle, treibe ich mich in OpenSource Projekten herum. Warum ist immer mal wieder eine Frage, die mir gestellt wird. Hier möchte ich kurz darauf eingehen, was OpenSource für mich bedeutet und warum ich mich immer wieder mit Projekten im OpenSource Umfeld beschäftige.

Der wohl wichtigste Grund für mich, liegt darin, das ich viel lernen kann. Man lernt nicht nur durch das lesen von Offenem Quellcode, sondern auch, wenn man eigene Code veröffentlicht und von anderen reviewen lässt.

Ein anderer wichtiger Grund ist die Kommunikation mit anderen Entwicklern. Andere Entwickler haben einen anderen Blickwinkel, durch den man einiges lernen kann. Hier hat sich Stackoverflow als das Hilfsmittel der Wahl etabliert. Dort kann man Fragen stellen, aber auch eigene Antworten geben. Die Fragen, aber auch die Antworten werden bewertet und man kann dadurch viel lernen, immer in der Kommunikation mit anderen. Eines der wohl interessantes Projekte an dem ich beteiligt war, hatte einen IRC-Channel, auf dem täglich (eher nächtlich) Meetings stattfanden und man sich ausgetauscht hat.

Jedoch lernt man nicht nur durch das lesen und schreiben von Code, auch das lesen von Dokumentation zu verschiedenen Projekten öffnet die Augen für neues. Bug-Reports sind ebenso immer wieder auch interessant, denn dort lernt man, Software mit anderen Augen zu sehen.

In den letzten Jahren sind andere Projekte aufgetaucht, bei denen es um Gesundheitliche belange geht. Hier geht es nicht nur um den Austausch von Code, sondern plötzlich auch um konkrete Gesundheitliche Fragen. Das bedeutet mir (als Diabetiker) eine ganze Menge.

Die Tätigkeiten in einem OpenSource Projekt sind vielfältig und jeder kann dazu beitragen, warum also nicht auch Du?

THESE: EJBs sind Tod/JEE ist Tod…

Meine recht provokant formulierte These, das EJBs tot sind, habe ich basierend auf einem wohlbegründeten Bauchgefühl meiner bescheidenen Erfahrung vor einiger Zeit getätigt. Nun hat mich eine vertiefende Betrachtung und eine durch Fakten belegte Begründung interessiert. Diese könnt Ihr hier lesen.

Schaut man sich die beiden Spezifikationen EJB und CDI an, so wird man feststellen, das diese beiden Technologien recht ähnlich aufgebaut sind. In einigen Artikeln wird gar davon gesprochen, das EBJ >= CDI ist [Freely Mix EJB and CDI]. So erscheint also eine Betrachtung der beiden Spezfikationen gegeneinander kaum sinnvoll. Ich versuche mich dennoch, um im Fazit dann auf den Grund dafür einzugehen.

Einen Quellennachweis habe ich versucht, an die einzelnen Punkte anzuhängen, erhebt jedoch keinen Anspruch auf Vollständigkeit. Auch hier gilt, das sich jeder eine eigene Meinung bilden sollte. Über Feedback würde ich mich sehr freuen.

EJB

EJBs werden seit 1997 spezifiziert und spätestens durch die Adoption von SUN 1999 auch genutzt [Wikipedia EJBs]. Mit den Versionen 1.0/1.1 und 2.0 wurde eine sehr strikte und Code-Intensive Umsetzung der Spezifikation angeboten. So war es z.B. zwingend erforderlich, das man Interfaces implementiert. Insbesondere in den Versionen 1.0/1.1 mussten auch lokale Beans immer über Corba aufgerufen werden, auch wenn man ein Distributed Computing nicht verwendete. Dies führte zu einem hohen Performance impact [Wikipedia EJBs History]. Dies änderte sich dann mit Version 2.0.

In der Version 3.0 der EJB-Spezifikation (2004) wandte man sich in Teilen von den bisherigen Konzepten ab, und übernahm Konzepte aus dem bereits damals schon aufkommenden und als leichtgewichtiger empfundenen Spring Framework. So wurde hier verstärkt auf Annotationen und nicht mehr auf die Implementierung von Interfaces gesetzt.[Wikipedia EJBs History].

Eine Versions-Historie bis zur Version 3.2 (2013) kann man unter [Wikipedia EJBs Versions Historie] einsehen.

CDI – Contexts and Dependency Intjection

Bereits mit der EJB Spezfikation 3.1 und dem JEE Stack 6 (2009) wurde CDI [Wikipedia CDI] eingeführt. Dieses Konzept entstammt in weiten Teilen dem Spring Framework und beruht auf dessen und Google Guice‘ Konzepten.

Im folgenden möchte ich auf einige Punkte in der JEE Spezifikation eingehen, die meist mit EJBs umgesetzt werden.

Remoting

Im Bereich des Remoting (sprich, die Method Invocation innerhalb einer anderen VM bzw. sogar über Hardware-Genzen hinweg ist ein Einsatzbereich der EJBs (@Remote). Dieses Paradigma wird in einigen Applikationen für die Kommunikation zwischen verschiedenen Applikatiionen genutzt. Dieses Programmier-Paradigma ist längst durch andere Paradigmen mit loser Kopplung (zB. REST [Adam Bien – Local and Remote EJB]) abgelöst worden.

Für die Asynchrone Kommunikation werden vielfach die Message Driven Beans (MDB) und JMS eingesetzt. Dies wird voraussichtlich mit der JEE 9.0 Spezifikation auch in CDI abgebildet, so dass eine Verwendung von MDBs in Zukunft nicht mehr notwendig erscheint [Eclipse JEE8 – Absatz CDI 2]. Derzeit erscheinen diese jedoch immer noch eine einfache Möglichkeit um asynchron Messages zwischen Systemen auszutauschen.

Security

Im Bereich der Security haben EJBs auch eine Stärke, die mit CDI1.1/1.2 leider noch nicht komplett aufgehoben wurde. Dennoch ist es bereits in dieser Version möglich, die von EJB bekannten Sicherheitskonzepte einfach „nachzubauen“[Wofür braucht man JEE eigentlich noch – Absatz Security].

Transaktionshandling

Mit CDI1.1 wurde das Transaktionshandling mit dem Handling von EJBs weitgehend angeglichen. Bei der Behandlung von Exceptions ist CDI sogar besser als das bisherige EJB Konzept. Eine Ausnahme bildet der Einsatz von sogenannten Extended Transactions, die die Objekte nach dem Ende einer Transaktion nicht von der DB detachen und so einen einfacheren Flow der Daten ermöglichen [Wofür braucht man JEE eigentlich noch – Absatz Transaktionsbehandlung und JPA].

Hier hat sich bereits jetzt in Projekten „eingebürgert“, das Objekte gemerged werden, was eine Extended Transaction nicht mehr notwendig macht. Dies geschieht häufig in einer zentralen DAO Klasse.

Scheduling

Mit JEE8 wurde leider nicht, wie ursprünglich geplant, die @Schedule-Annotation in CDI implementiert. Dies ist auch weiterhin nur über ein Singleton-EJB möglich. Bei Bedarf kann diese Zeitsteuerung aber über entsprechende Zusatzbibliotheken auch in CDI nachgerüstet werden [Schedule Jobs in CDI].

Startup

Häufig sollen beim Startup eines Containers einige Funktionen ausgeführt werden, zB. um spezifische Konfigurationsdaten zu lesen. Auch dies wurde mit CDI 2.0 noch nicht umgesetzt. Auch dies kann bereits in CDI 1.1 recht einfach nachgebildet werden [CDI and Startup].

FAZIT

Da immer noch ein paar (wenige) Features in der EJB Spec nicht in CDI abgebildet sind, ist es derzeit nicht möglich, die EJBs bereits aus den Projekten zu entfernen. Dies ist auch nicht notwendig, da die beiden Spezifikationen sehr gut miteinander kooperieren. Dennoch empfiehlt es sich, bei einer Implementierung eines Projektes darauf zu achten, das die EJBs in Zukunft durch CDI abgelöst werden (könnten). Um dann zusätzliche Aufwand zu vermeiden (wie zB. bei den in JEE8 deprecateden @ManagedBean und den daran hängenden Scopes) sollte somit vorwiegend CDI eingesetzt werden.

Die Fokussierung auf Microservices und schnell startende bzw. Self-Contained Container [Thorntail] und die damit zusammenhängenden Mirco-Profiles [Microprofile] ergibt sich, zumindest aus meiner Perspektive, ein klarer Trend in Richtung einer EJB-losen Welt.

Für die Zukunft gerüstet sein, heißt hier also ganz klar, auf EJBs möglichst verzichten [birdseye JEE8 – Absatz CDI 2, letzter Abschnitt].