Diétás alkalmazáskiszolgálók: A klasszikus alkalmazáskiszolgálóknak még mindig van jövőjük?

Megfelelnek-e ma is a vállalati alkalmazásszerverek, amint az elmúlt tíz évben megismertük és megszerettük őket? Vagy elavult a sokoldalú gondtalan munkafolyamat-környezet modellje, ideértve a menedzsmentet és a felügyeleti funkciókat is? Jó kérdés, amelyre az EnterpriseTales megpróbál választ adni.

Nemrég egy konferencián tartottam egy előadást a "Mikroszolgáltatások: A méret nem számít - vagy nem?" Témában. A beszélgetés keretében többek között a mikroszolgáltatások „munkafolyamat-környezeteiről”, például a Spring Boot vagy a Dropwizard került szóba. Ezt követően az egyik résztvevő érdekes kérdéssel fordult hozzám, amelyet nem szeretnék visszatartani az EnterpriseTales rovat olvasóitól: "Van-e még jövője a klasszikus alkalmazásszervereknek?"

JAX - A Java, az architektúra és a szoftverinnováció konferenciája

Tipikus építészeti hibák - a harmadik megdöbbenti!

Eberhard Wolffal | INNOQ Germany GmbH

Műhely: Remek új Java-szolgáltatások - jobb kód a Java 9-16-ig

Michael Indennel | szabadúszó

A nagy 3 az 1-ben képzési csomag, több mint 20 oktatóval és körülbelül 18 intenzív műhellyel

API-k és mikroszolgáltatások tesztelése

Arne Limburgtal | open knowledge GmbH

Műhely: Az API tervezés megfelelő megszerzése - Tervezés a részvételhez

Uwe Friedrichsennel | kodecentrikus

Egy korszak vége

El kell ismerni, hogy a beszélgetésben leírt forgatókönyvek nem igazán javasolnak kövér alkalmazásszervert futásidejű környezetként. A klasszikus alkalmazásszerver fő előnye, hogy számos Az alkalmazások párhuzamosan futhatnak rajta vagy benne, ugyanakkor tisztán el vannak választva egymástól. Akkor miért? egy Csak akkor használja az alkalmazásszervert a Alkalmazás vagy szolgáltatás futni akar rajta?

Természetesen egy alkalmazásszerver valamivel több hozzáadott értéket kínál, mint a tiszta futásidejű környezet. Például biztosítja az alkalmazáshoz szükséges infrastruktúrát - például az adatbázishoz való kapcsolódást vagy a JMS-sorokat -, valamint támogatja az alkalmazás telepítését, kezelését és felügyeletét. Ezen túlmenően a kiszolgáló általában számos olyan könyvtárat köt össze, amelyek egymáshoz illeszkednek azokban a verziókban - azaz kompatibilis -, amelyek hasznos szolgáltatásokat nyújtanak az alkalmazás számára, és elavulttá teszik a könyvtárak kézi keresését. A könyvtárak vagy meg tudnak felelni egy szabványnak, például a Java EE Application Servers esetében, vagy egyszerűen csak kombinációk lehetnek, amelyeknek bizonyos célokra van értelme, amint azt például az egyik vagy másik Tomcat disztribúcióból tudjuk. Aki valaha megpróbálta hozzáadni a kívánt könyvtárakat a saját alkalmazásához, és véletlenül került az osztály betöltőjébe és a pokol verziójába, tudja, miről beszélek.

Egy szerver tehát ideális lenne, amely meghozná az imént említett előnyöket, ugyanakkor - a rendelkezésre bocsátandó alkalmazás szempontjából - felesleges előtétet adna el. Ha a szerver akkor is az alkalmazás részévé válhat, és így nem szükséges külön telepítés és a szerver kezelése, akkor igen, a világunk tökéletes lenne.

Keskeny nyomtávú szerver

Pontosan az imént leírt forgatókönyv olyan meglévő megoldásokon alapul, mint a Spring Boot, a Dropwizard vagy a Play. Eddig ezek különösen (de nem csak) nevet szereztek maguknak a mikroszolgáltatási környezetben. De a szabványosított vállalati Java szerver világ képviselői is felismerték a szükségletet és megfelelő megoldásokat kínálnak. A legérdekesebb képviselők jelenleg a TomEE Shades, a WildFly Swarm, a Payara Micro GlassFish és a KumuluzEE. Az összes megoldásban az a közös, hogy a Dropwizardról ismert „csak azt vegye, amire szüksége van” megközelítést átadja a Java EE világának, és beágyazott szerverként részévé válhat a JAR-ként telepített alkalmazásnak.

Szerver helyett támogató

Keskeny nyomtávú szerver vagy tojást tojó Wollmichsau futási környezet?

Manapság elavultaknak tűnnek az alkalmazáskiszolgálók, amelyek azt állítják, hogy tojásrakó gyapjú-cum-futásidejű környezetet biztosítanak, beleértve egy felügyeleti és felügyeleti központot. És nemcsak a mikroszolgáltatások környezetében. Másrészt megfelelőbbnek tűnnek az adott alkalmazás igényeihez egyedileg adaptálható folyamatkörnyezetek. Az olyan megoldások, mint a Dropwizard és a Spring Boot, bebizonyították, hogy a két világ nem zárja ki egymást teljesen, és még egy beágyazható keskeny nyomtávú szerverrel sem kell kényelmet és a szükséges vállalati szolgáltatásokat nélkülözni. Az első szolgáltatók a Java EE környezetből most követik példájukat, így a Java Enterprise Standard világában ez sokkal rugalmasabb lesz a jövőben. Egyébként: a Jigsaw moduláris projekt segítségével újabb ugrásra számíthatunk a rugalmasság terén. Mivel azonban a Jigsaw csak Java 9-gyel érkezik, és ezért nem feltétlenül várható, hogy ez már hatással lesz a Java EE 8-ra, a szabványosított szerver részéről 2020-ig kell várnunk. Más megoldásoknak viszont sokkal korábban kellene alkalmazkodniuk a Jigsaw-hoz. Ezt szem előtt tartva: Maradjon velünk ...

Mondja el az Enterprise Tales oszlopban Lars Röwekamp, Sven Kölpin és Arne Limburg (nyitott ismeretek) érdekes történeteket és informatív betekintést nyújt a Java EE-re és az Enterprise Java színes világára.