Abo
  1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Open Source Projekt…

Braucht jemand einen JEE Standard?

  1. Thema

Neues Thema Ansicht wechseln


  1. Braucht jemand einen JEE Standard?

    Autor: schap23 18.08.17 - 15:05

    J2EE war eine Katastrophe. Irgendwelche Softwareingenieure auf Drogen hatte sich ein unheimlich komplexes Gewirr aus Interfaces ausgedacht. Ehe "Hello World" lief, hatte man massenweise Dateien erstellt. Das ganze konnte man nur in den Griff bekommen mit Tools, die einem den Mist generierten.

    Dann kam Spring und zeigt, daß das ganze viel, viel einfacher und dabei noch besser ging. J2EE hat dann die 2 eingebüßt und übernahm im Prinzip den Ansatz von Spring.

    Heute ist aber der Applicationserver auch weitestgehend Geschichte. Die Leute Deployen nicht mehr Enterprise Beans sondern es werden Microservices entwickelt, die in Containern wie Docker laufen und mit Software wie Kubernetes koordiniert werden. Dabei ist man auch nicht mehr auf Java angewiesen, sondern verwendet die Programmiersprache und Umgebung, die am Besten zu dem Problem paßt.

    Insbesondere die Zeit der teueren Java-Applicationserver sollte vorbei sein, ebenso wie die Zeit der großen Server von Sun, IBM, etc. auf denen die liefen. Das sieht man auch daran, daß Oracle offensichtlich Solaris auslaufen läßt.

  2. Re: Braucht jemand einen JEE Standard?

    Autor: Plasma 18.08.17 - 18:03

    Es gibt dann noch das große Gespenst der sog. "Legacy"-Software.

  3. Re: Braucht jemand einen JEE Standard?

    Autor: werpu 18.08.17 - 20:50

    Microservices eignen sich nicht für alle applikationstypen, sie werden halt gerade massiv gehyped.

  4. Re: Braucht jemand einen JEE Standard?

    Autor: werpu 18.08.17 - 21:08

    Ah iwo... Microservices und App Server schliessen sich nicht aus. Im Gegenteil im Regelfall liegen in den sogenannten Microservices auch mini app server embedded. Gewisse Anforderunge hat man immer die sowohl in einer großen App vorhanden sind als auch in einem kleinen Microservices.

    Ich sehe Microservices mit gemischten Gefühlen, nichts anderes als was man jetzt probiert hatte man schon in den 90igern mit Corba danach mit Remote EJBs und später mit Cross Server Soap Kommunikation mit Soa. Man verschiebt halt die Komplexität jetzt weg von der eigentlichen App hin zum Kommunikations und deployment Layer. Sprich das Modulbinding wird reduziet, dafür wir der Netzwerk Wartungsaufwand erhöht und irgendwann weiss keiner mehr wass passiert wenn ein Service ausfällt über das über Netzschnittschellen 3 andere Services zugreifen auf die 5 weitere Services zugreifen. Sowas dann auszudebuggen ist die Hölle. Wo es wirklich was löst ist im NodeJS Umfeld, dass wegen der Single Thread Prolematik inherent schlecht skaliert ab einen bestimmten Punkt, wobei man hier vermutlich auch mit einem Cluster weniger Resourcen brauchen würde als mit einem Microservice Ansatz.

    Ad Reduktion der Modulkomplexität, bei einem ordentlichen modularen service orientierten Ansatz hat man die Komplexität auch bei einem Single server deployment in Griff. Es ist halt ein gewisser Hype so wie SOA vor einigen Jahren, Nur im Gegensatz zu Soa gibt es halt einige Szenarien wo es Sinn macht. Man sollte immer erst abwarten wieviele sich die Finger verbrennen bevor man auf sowas aufspringt.

    Ad Oracle, das grosse Geld liegt in der Tat nicht mehr bei den App Servern sondern in der Cloud. Darum gehts hier eigentlich.

  5. Re: Braucht jemand einen JEE Standard?

    Autor: redmord 18.08.17 - 21:50

    Ich schreib mal kurz wie ich bisher das Thema aufgenommen habe ...

    Microservices, orchestriert mit z.B. Kubernetes, haben vor allem den Vorteil, mit simpler Mechanik robuste Systeme bauen zu können. Nicht eine Instanz, sondern viele kleine Instanzen laufen. Wenn eine Abschmiert fällt's nicht auf und wird automatisch und kontrolliert neu gestartet. Deployment ist auch geregelt.

    Robustheit durch Redundanz und Lastverteilung sind besondere Vorteile dieser "Denkart". Gleichzeitig nutzt man von beginn an eine Architektur, die eben extrem gut skalieren kann und zwar punktuell und gezielt.

  6. Re: Braucht jemand einen JEE Standard?

    Autor: werpu 19.08.17 - 10:07

    Das Problem liegt im Detail. Microservices sind im Prinzip kleine app server (meist Embedded) die wenig spezialisierte Funktionalität bereitstellen (Do one thing do it right) und über Netzwerkverbindungen verbunden bzw. aufgerufen werden.
    Das funktioniert recht gut solange es nicht zuviele Dependencies zwischen den einzeilnen Services gibt. Bzw. die vergrösserte Deployment Komplexität durch Tools abgefangen werden kann. Es gibt aber mehr als wenige Applikationsklassen wo eben diese Komplexität der Modul/Servicebindung durch die Business Logik bedingt eben doch relativ stark ist bzw. wo man eben nicht viele kleine Teams hat die sich um jeweils einen Aspekt der Applikation kümmert und dann schneidet man sich mit Microservices ins eigene Fleisch. Ein weiterer Aspekt ist für Business Applikationen braucht man nunmal einen gewissen Satz an Basisfunktionalität (DB Verbindungen, meist irgendein ORM Layer, ein Kommunikationslayer ein DTO Layer in irgendeiner Form, oft noch etwas lokales Caching, app weites caching kann meist über ein eigenes Microservice gesteuert werdne) das wird dann auf jede Server instanz neu reinrepliziert, sprich der Ressourcen Bedarf steigt enorm pro Instanz). Es stellt sich halt dann die Frage welche Vorteile bietet es. Ausfallssicherheit ? Würde sagen die ist nicht wirklich viel besser als bei einem echten Cluster. Bessere Performance auch nicht wirklich gegenüber einem Cluster. Weniger Probleme wenn ein Teilaspekt der App niedergeht. Das hängt von der Stärke der Modulkopplung ab, kann sein meist ist es aber nicht gegeben. Der Wesentliche Vorteil ist halt man kann Teilaspekte der App durch den Austausch eines Services upgraden ohne gleich die gesamte App zu gefährden. Das erkauft man sich aber dadurch, dass man eine massiv erhöhte Komplexität im Deployment und Administrations Bereich hat und auch einen massiv erhöhten Aufwand im Bereich Testing und Unit Testing.

    Wie gesagt für größere Deployments mit Teams von duzenden bis hunderten Entwicklern eventuell ein gangbarer Weg. Aber bei einem mittleren Deployment mit 5-15 Entwicklern würde ich abhänging von der Applikation und Budget 2x überlegen so einen Weg zu gehen.

    Es ist wie letztendlich alles derzeit ein Riesenhypethema wo sich viele gerade die Finger verbrennen und in 3-4 Jahren wird man zu einer realistischeren Meinung kommen wo man es einsetzt. Ist halt der übliche Technologieschweinezyklus der halt alle 5-10 Jahren durchs Dorf getrieben wird.

  7. Re: Braucht jemand einen JEE Standard?

    Autor: Benjamin_Damm 20.08.17 - 14:37

    @werpu Danke! Endlich mal jemand der es genau auf den Punkt bringt.

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. TRILUX Lighting Solutions GmbH, Köln
  2. Friedrich-Alexander-Universität Erlangen-Nürnberg (FAU), Erlangen
  3. ING-DiBa AG, Nürnberg
  4. mobilcom-debitel GmbH, Hamburg

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 25,49€
  2. (-85%) 2,30€
  3. 3,99€
  4. 4,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


P30 Pro im Kameratest: Huawei baut die vielseitigste Smartphone-Kamera
P30 Pro im Kameratest
Huawei baut die vielseitigste Smartphone-Kamera

Huawei will mit dem P30 Pro seinen Vorsprung vor den Smartphone-Kameras der Konkurrenez ausbauen - und schafft es mit einigen grundlegenden Veränderungen.
Ein Test von Tobias Költzsch

  1. P30 Pro Teardown gewährt Blick auf Huaweis Periskop-Teleobjektiv
  2. CIA-Vorwürfe Huawei soll von chinesischer Regierung finanziert werden
  3. Huawei-Gründer "Warte auf Medikament von Google gegen Sterblichkeit"

Anno 1800 im Test: Super aufgebaut
Anno 1800 im Test
Super aufgebaut

Ach, ist das schön: In Anno 1800 sind wir endlich wieder in einer heimelig-historischen Welt unterwegs - zumindest anfangs. Das neue Werk von Blue Byte fesselt dank des toll umgesetzten und unverwüstlichen Spielprinzips. Auch neue Elemente wie die Klassengesellschaft funktionieren.
Von Peter Steinlechner

  1. Ubisoft Blue Byte Anno 1800 erhält Koop-Modus und mehr Statistiken
  2. Ubisoft Blue Byte Preload der offenen Beta von Anno 1800 eröffnet
  3. Systemanforderungen Anno 1800 braucht schnelle CPU

Raspi-Tastatur und -Maus im Test: Die Basteltastatur für Bastelrechner
Raspi-Tastatur und -Maus im Test
Die Basteltastatur für Bastelrechner

Für die Raspberry-Pi-Platinen gibt es eine offizielle Tastatur und Maus, passenderweise in Weiß und Rot. Im Test macht die Tastatur einen anständigen Eindruck, die Maus hingegen hat uns eher kaltgelassen. Das Keyboard ist zudem ein guter Ausgangspunkt für Bastelprojekte.
Ein Test von Tobias Költzsch

  1. Bastelcomputer Offizielle Maus und Tastatur für den Raspberry Pi
  2. Kodi mit Raspberry Pi Pimp your Stereoanlage
  3. Betriebssystem Windows 10 on ARM kann auf Raspberry Pi 3 installiert werden

  1. Chuwi Aerobook: Leichtes Notebook ab 350 Euro mit Core m3
    Chuwi Aerobook
    Leichtes Notebook ab 350 Euro mit Core m3

    Das Aerobook scheint ein für mobile Schreibarbeiten geeignetes Notebook zu sein. Wie für Chuwi üblich, versucht der Hersteller das Gerät möglich günstig anzubieten: Ab 350 Euro gibt es einen Core-m3-Prozessor und 128 GByte Speicher.

  2. Tim Sweeney: Weiter Streit um den Epic Games Store
    Tim Sweeney
    Weiter Streit um den Epic Games Store

    Der Chef von Epic Games diskutiert mit der Community über seinen neuen Store. Unter anderem will Tim Sweeney keine Exklusivspiele mehr anbieten - falls Konkurrent Steam seine Provisionen senkt.

  3. Cyber Week: Computec-Partner geben Rabatte auf Hard- und Software
    Cyber Week
    Computec-Partner geben Rabatte auf Hard- und Software

    Vom 26. April bis zum 5. Mai findet die Cyber Week statt: Die Computec Media GmbH und ihre Partner offerieren Preisnachlässe für Hard- und Software aus einem breiten Angebot.


  1. 11:38

  2. 10:42

  3. 10:30

  4. 10:24

  5. 10:13

  6. 09:39

  7. 09:15

  8. 09:02