© Excellent backgrounds/Shutterstock.com
Java Magazin
Java EE trifft Microservices

Elefant im Porzellanladen?

In der Enterprise-Community hält sich hartnäckig das Gerücht, dass Java EE nicht wirklich als Werkzeug für die neue Wunderwelt der Microservices geeignet sei. Die Wurzeln des Enterprise-Java-Standards sind jedoch genau dort zu finden, wo wir heute mit dem Architekturansatz der Microservices hin wollen - in stark verteilten, fachlich orientierten Systemen. Warum also hat Java EE, in Bezug auf Microservices, einen so schlechten Ruf? Und ist er gerechtfertigt?

Lars Röwekamp


Video: Java-EE-7-Architekturen auf Java 8 werden Microservices

Unabhängig von den vielen Charakteristika, die eine Microservices-basierte Architektur im Detail auszeichnet, stehen vor allem die erhöhte Flexibilität bei Entwicklung und Deployment im Fokus. Etwas managementtauglicher könnte man es auch als „Time-to-Market-Optimierung“ bezeichnen. Leider scheint genau dieses „Time to Market“, selbst im Zeitalter von agiler Entwicklung und deutlich kürzeren Releasezyklen als noch vor Jahren, nicht wirklich zu Java EE zu passen (Abb. 1). Dabei hebt bereits die erste J2EE-Spezifikation vor mehr als zehn Jahren hervor, dass Enterprise Developer sich zukünftig – dank J2EE – voll und ganz auf die Fachlichkeit der umzusetzenden Anwendung konzentrieren können, anstatt ihre Zeit mit der Lösung von Infrastrukturproblemen zu vergeuden. Zum ersten Mal rückt damals der Aspekt „Time to Market“ als Wettbewerbsvorteil für Anwender des Java-EE-Frameworks in den Fokus. Und auch der Begriff Enterprise Services taucht in der Spezifikation mehrfach auf: „The Java 2 Platform, Enterprise Edition reduces the cost and complexity of developing multitier, enterprise services. J2EE applications can be rapidly deployed and easily en­hanced as the enterprise responds to competitive pressures.“

Woran liegt es also, dass Java EE den damaligen Ansprüchen nicht gerecht werden konnte und man sich als Java-EE-Entwickler im Kreise der Microservices-Fans wie ein Elefant im Porzellanladen fühlt?

Das Java-EE-Framework wird per Definition im Enterprise-Umfeld, somit also in großen Projekten eingesetzt. Derartige Projekte sind historisch bedingt häufig mit entsprechend komplexen Organisations- und Kommunikationsstrukturen versehen. Spätestens seit Conway’s Law [1] wissen wir, dass diese Strukturen automatisch zu unnötig aufgeblähten Systemen führen, die nur wenig – sehr wenig – Flexibilität mit sich bringen: „Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization‘s communication structure.“

Aus dem eben aufgezeigten Betrachtungswinkel muss den Java-EE-Kontrahenten also zunächst einmal Recht gegeben werden. Die Frage, die sich an dieser Stelle allerdings stellt, ist, ob das beschriebene Szenario tatsächlich ein Problem von Java EE beschreibt oder eher ein Problem der Zeit, in der Java EE groß geworden ist. Eine Zeit, in der wir uns damit arrangiert hatten, dass Architekten schichtenbasierte Frameworks oder Generatoren inkl...

Java Magazin
Java EE trifft Microservices

Elefant im Porzellanladen?

In der Enterprise-Community hält sich hartnäckig das Gerücht, dass Java EE nicht wirklich als Werkzeug für die neue Wunderwelt der Microservices geeignet sei. Die Wurzeln des Enterprise-Java-Standards sind jedoch genau dort zu finden, wo wir heute mit dem Architekturansatz der Microservices hin wollen - in stark verteilten, fachlich orientierten Systemen. Warum also hat Java EE, in Bezug auf Microservices, einen so schlechten Ruf? Und ist er gerechtfertigt?

Lars Röwekamp


Video: Java-EE-7-Architekturen auf Java 8 werden Microservices

Unabhängig von den vielen Charakteristika, die eine Microservices-basierte Architektur im Detail auszeichnet, stehen vor allem die erhöhte Flexibilität bei Entwicklung und Deployment im Fokus. Etwas managementtauglicher könnte man es auch als „Time-to-Market-Optimierung“ bezeichnen. Leider scheint genau dieses „Time to Market“, selbst im Zeitalter von agiler Entwicklung und deutlich kürzeren Releasezyklen als noch vor Jahren, nicht wirklich zu Java EE zu passen (Abb. 1). Dabei hebt bereits die erste J2EE-Spezifikation vor mehr als zehn Jahren hervor, dass Enterprise Developer sich zukünftig – dank J2EE – voll und ganz auf die Fachlichkeit der umzusetzenden Anwendung konzentrieren können, anstatt ihre Zeit mit der Lösung von Infrastrukturproblemen zu vergeuden. Zum ersten Mal rückt damals der Aspekt „Time to Market“ als Wettbewerbsvorteil für Anwender des Java-EE-Frameworks in den Fokus. Und auch der Begriff Enterprise Services taucht in der Spezifikation mehrfach auf: „The Java 2 Platform, Enterprise Edition reduces the cost and complexity of developing multitier, enterprise services. J2EE applications can be rapidly deployed and easily en­hanced as the enterprise responds to competitive pressures.“

Woran liegt es also, dass Java EE den damaligen Ansprüchen nicht gerecht werden konnte und man sich als Java-EE-Entwickler im Kreise der Microservices-Fans wie ein Elefant im Porzellanladen fühlt?

Das Java-EE-Framework wird per Definition im Enterprise-Umfeld, somit also in großen Projekten eingesetzt. Derartige Projekte sind historisch bedingt häufig mit entsprechend komplexen Organisations- und Kommunikationsstrukturen versehen. Spätestens seit Conway’s Law [1] wissen wir, dass diese Strukturen automatisch zu unnötig aufgeblähten Systemen führen, die nur wenig – sehr wenig – Flexibilität mit sich bringen: „Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization‘s communication structure.“

Aus dem eben aufgezeigten Betrachtungswinkel muss den Java-EE-Kontrahenten also zunächst einmal Recht gegeben werden. Die Frage, die sich an dieser Stelle allerdings stellt, ist, ob das beschriebene Szenario tatsächlich ein Problem von Java EE beschreibt oder eher ein Problem der Zeit, in der Java EE groß geworden ist. Eine Zeit, in der wir uns damit arrangiert hatten, dass Architekten schichtenbasierte Frameworks oder Generatoren inkl...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang