Child pages
  • JEE6 vs Spring
Skip to end of metadata
Go to start of metadata

Érdekelne a véleményetek, hogy ki mit preferál. Szeretem mindkettőt és a JEE6-al sok jó dolog megjelent, de amit problémásnak érzek az még mindig a tesztelhetőség... A fejlesztés gyors és a CDI jó dolgokat hozott, de hogy a teszteléssel többet szívjon az ember, mint a fejlesztéssel, ez valahogy nem tetszik. JUnit-os tesztek készítésére ott az embedded-glassfish vagy az arquilian. Mind a kettőnek szerintem egsz sok nyűgje van és én mást nem is ismerek amivel a konténer menedzselt serviceket tesztelni lehetne. Ebben a tekintetben szerintem még mindig jobb a Spring, persze ott nincs konténer, ezért is egyszerűbb a tesztelése. Igaz a fejlesztés több kódot igényel, viszont valahogy közelebb érzem magamhoz, jobban látom, hogy melyik bean mikor jön létre és itt még függőségi sorrendet is meg tudok adni, míg CDI-nál van a sepc, és majd valahogy létrejön. Ráadásul a JBoss-t elég bugosnak tartom és Glassfish-nél is találkoztam bugokkal, amit érzésem szerint Springben egyszerűbben tudok javítani, jobban belenyúlhatok. Pl. alkalmazás szerver szinten még a JPA provider kicserélése is problémát jelenthet, ha pl. valami újabbat szeretnék használni, mint amivel az alkalmazásszerver jött. Persze, a JEE nagy előnye a SessionBean, mivel akár admin felületről is dobhatok a performancián a pool méretezéssel, bár business object poolozásra Springben is van lehetőség... Ti mit gondoltok?

 

      
      
Page viewed times
#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))
  • No labels

19 Comments

  1. Ebből flame lesz... ezért inkább alszom rá egyet... (smile)

    1. Egyáltalán nem a flame kedvéért nyitottam, csak kiváncsi vagyok mások tapasztalataira. Szerintem a JEE6 fejlesztésre tényleg nagyon jó, pár apróságtól eltekintve, de ha tesztelni is kell, akkor már érzésem szerint jönnek a problémák, ez könnyebb Springnél. De az is lehet, hogy nem tudok valamit amit más igen és ő elmagyarázhatná, hogy ezért meg azért gondolom ezt rosszul. (smile)

      Megpróbálom összeszedni, ahogy én látom:

      JEE6 előnyei:

      • CDI - elég hatékony, és sok kódot lehet vele spórolni
      • JEE konténer - kellemes, hogy van egy pool a háttérben és egyszerűen "elfeljthetjük" a tranzakciókezelést a háttérben
      • szabvány
      • egyszerű jogolsultságkezelés

      hátrányai:

      • alkalmazás szervereken nehézkes lehet pl. újabb lib használata és az ember csak kisérletezhet vele, mert ki tudja, hogy mi fog vele okozni később. Csak egy újabb JPA provider vagy validation lib-re gondolok.
      • eddig két alkalmazás szervert használtam, a glassfisht és a jbosst. A glassfish szerintem nagyságrendekkel jobb,de a JBoss is már egész elfogadható a 7.1-es verziótól, de előtte a 6-os az tele volt buggal (ok, hogy nem is lett belőle final, ha jól tudom). De ha itt bugos valami, akkor jön az előző pont, nagyon veszélyesnek és nehézkesnek érzem egy lib cseréjét is.
      • konténerek tesztelhetősége szerintem még mindig nehézkes. Arquilian-t használtam jboss-hoz, de elég problémásnak érzem a konfigurálást és meg kellett küzdeni csomó dependency problémával és bugos is volt. Az embedded glassfish még egész jó lenne, de ott is tapsztaltam furcsaságokat. Pl. nem eclipselinket akartam használni, hanem hibernate-t, akkor már szép exceptionöket dobált.
      • A jelenlegi verziót (JEE6), kicsit olyan mixeltnek érzem. Arra gondolok, hogy megvan a CDI-nak a saját életciklusa, van az EJB-nek és van JSF-nek egy harmadik életciklusa.  Bár, ahogy olvastam a JSF annotációkat már nem is javasolják használni, hanem helyette inkább a CDI bean-ket. Ami normál esetben elég is lehet, de ha GUI logika is kell, akkor könnyen lehet, hogy JSF bean is kell.
      • jogosultságkezelés-nél nem igazán tetszik, ha valami bonyolultabb ell, akkor saját modult kell hozzá írni, ami külön betehető az alkalmazás szerver alá. Kis szépséghibának érzem, hogy elkülönül az alkalmazástól, de igazából nem olyan hatalmas érv.
      • SessionBean-ből több szálat nem lehet indítani, bár vannak trükközések.

       

      Spring előnyei:

      • DI még hatékonyabb, mint a CDI. Vannak olyan lehetőségek, amit a CDI még nem is tud
      • nem egy spec alapján működik, hanem ahogy én akarom
      • jogosultágkezelés itt igazán testre szabható
      • jobb tesztelhetőség
      • több szerver közül lehet választani, hisz csak a depedenciái kellenek és elfut mindenen
      • nem vagyok az alkalmazás szerver dependenciához kötve, gyakorlatilag bármit használhatok
      • aspekt orientált programozásban is rugalmasabbnak érzem

      hátrányai:

      • nincs konténer, bár poolozást itt is meg lehet valósítani
      • nagyon testre szabható, emiatt nagyon sok konfigurálási lehetőség is van, mélyen meg kell ismerni.
      • összességében több kódból lehet elkészíteni ugyanazt az alkalmazást, mint JEE-vel
      • tranzakció kezelésről nekem kell gondoskodni, bár igaz, hogy egyszerű
      • nem szabvány
      • pont amitt, hogy mindene elfut, a dependenciákról nekem kell gondoskodni. Emiatt az alkalmazás jóval nagyobb lehet, hisz az alkalmazás szerveren általában nincs semmi a spring dependenciáiból.

       

    2. Csatlakozom az előttem alvóhoz.

  2. Még annyi, hogy Springnél találtam bejegyzést támadhatóságról, gyakorlatilag idegen jar-t/támadó kódot fel tudtak játszani egyszerűen a szerverre a Spring valamilyen hibája miatt. Ilyesmit eddig még JEE szerverről nem találtam, így talán biztonságosabbnak is mondható a JEE.

  3. Szerintem felesleges flame-et indítani. Ez kb. olyan, mintha a Trabantot hasonlítanánk az IFA-hoz.

  4. Mint irtam, nem flame-t szandekoztam inditani, hanem erdekelne mas hogyan latja ezen dolgokat. Ha elolvastad amit irtam, akkor lathatod, hogy megprobaltam osszeszedni az elonyoket es hatranyokat es talan egyiket sem tuntettem fel negativ szinben, probaltam targyilagos maradni. Szoval nem ertem a problemaitokat... De OK, tudomasul vettem.

    1. A szándék nem okoz flame-t, csak a téma... (smile)

      A Spring remek eszköz volt a JavaEE 1.3 és 1.4 környékén, amikor az EJB2.x volt az alternatív megoldás, kitöltötte azt a piaci rést, amely a Java Serlvet/JSP és a JavaEE között volt. Tudni kell, hogy az EJB2.x nem egy egyszerű dolog volt, igencsak nehéz volt alkalmazásokat építeni, de a legfőbb probléma egyszerűen az ingyenesen elérhető alkalmazás szerverek hiánya volt: a JBoss 3.x és 4.0.x nem volt a helyzet magaslatán, a többi alkalmazás szerver pedig igen drágán volt csak elérhető, így a kisebb cégek nem tudtak JavaEE technológiákra építeni, nem volt más alternatíva, mint a Spring.

      A JavaEE 5 hozta a fordulópontot, mivel megjelentek a open source JavaEE konténerek, illetve az EJB3.0 hihetetlen mértékben egyszerűsítette a fejlesztést, a JavaEE annyira egyszerű lett, mint a Spring volt... mostanság a JavaEE annyira elterjedt, hogy már erősen keresni kell olyan konténert, amely nem tudja a JavaEE5-öt... és persze ott a kényelem: egy JBoss 7.1 kevesebb erőforrást eszik full profile indítva, mint egy Tomcat, miközben sokkal könnyebb konfigurálni, menedzselni és ott a teljes JavaEE6 tudás...

      Meglátásom szerint a Spring esetén még mindig alacsonyabb a küszöb, könnyebb működő alkalmazást összeállítani, mint JavaEE6 használatával, az általad leírt előnyök és hátrányok nagyjából stimmelnek. De az alacsonyabb küszöb mellé azonban Spring esetén van egy alacsonyabb plafon is: amikor cluster-safe alkalmazásokat kellene írni, illetve tranzaktált terhelést elosztani vertikálisan és horizontálisan. Ez JavaEE esetén out-of-the-box működik, Spring esetén már maga a cluster is sokszor kihívás, több rétegű alkalmazás esetén a tranzaktált load-balancing meg már sci-fi.

      Amikor az ember keretrendszer választ, akkor érdemes megnézni a küszöböt és a plafont, mert hiába könnyű belépni, ha pár lépés után a fejünk a plafont súrolja... (smile)

      1. Köszi, hogy megtörted a csendet... (smile)

        Amit leírtál, annak többségével egyet értek. Amiben nem, azon dolgok egy része szubjektív, mert én Veled ellentétben úgy gondolom, hogy JEE5 vagy 6-al is gyorsabb a fejlesztés, mint Springgel. Viszont a tesztelés szerintem határozottan egyszerűbb Springgel. Ez valahogy nekem hiányzik JEE-ből...

        Az alkalmazás szerverek tekintetében igazad van, bár a JBoss azért elég bugos volt, de ez az utolsó 7.1, már egész tűrhető még sebességben is. Esetleg annyit meg lehet jegyezni, hogy a Springnek sem kell feltétlen Tomcaten futni, futhat az is Jboss-on, ha kell. Legutóbbi projektemben az összeállításkor próbálgattam dolgokat és azért 7.1-nél tapasztaltam olyan dolgot, amik Glassfish 3.1.2 alatt simán futottak, JBoss7.1 meg kiabált..., sőt ugyanaz még 6.1.0-nál is működött. (Service injektálás ear lib alatti utility-be)

        A skálázhatóság teljesen egyértelműen a JEE felé húz. Tudsz esetleg projekt bonyolultságot(konkurens userszám) mondani, ami felett nem érdemes Springet használni?

        1. Amit leírtál, annak többségével egyet értek. Amiben nem, azon dolgok egy része szubjektív, mert én Veled ellentétben úgy gondolom, hogy JEE5 vagy 6-al is gyorsabb a fejlesztés, mint Springgel. Viszont a tesztelés szerintem határozottan egyszerűbb Springgel. Ez valahogy nekem hiányzik JEE-ből...

          Ööö... izé... a tesztelés nem része a fejlesztésnek? (smile)

          Esetleg annyit meg lehet jegyezni, hogy a Springnek sem kell feltétlen Tomcaten futni, futhat az is Jboss-on, ha kell.

          Nyilván futhat WebSphere-n is, láttam már erre példát... de ettől még elég egy Servlet/JSP konténer a futásához... (smile)

          Legutóbbi projektemben az összeállításkor próbálgattam dolgokat és azért 7.1-nél tapasztaltam olyan dolgot, amik Glassfish 3.1.2 alatt simán futottak, JBoss7.1 meg kiabált...

          Ennek az az oka, hogy az alkalmazás szerverek fejlesztőinek más-más a fontos, a szabványt mindegyik megvalósítja, aztán más-más területen terjesztik ki azt. Ha a projekted a JavaEE határain belül marad, akkor futni fog mindegyik alkalmazás szerveren, ha pedig túlmész néha a határon, akkor igazítani kell az alkalmazáson.

          A skálázhatóság teljesen egyértelműen a JEE felé húz. Tudsz esetleg projekt bonyolultságot(konkurens userszám) mondani, ami felett nem érdemes Springet használni?

          Erre nincs számszerű válasz, feladattól és architektúrától függ. A Spring-es projektek egyik problémája, amikor kicsiből nagyobb lesz terhelés és nincs hova lépni, mert egy gépen szépen dolgozott, de kettő gépen kiderül, hogy milyen adatok nem replikálódnak (tipikusan sticky session pattern), aztán amikor több tucat gép kell, akkor kiderül, hogy a replikáció se hatékony megoldás, ésatöbbi. Ha tudod, hogy nem lesz nagy tranzaktált igénybevétel, akkor teljesen jó a Spring, ha viszont várható, hogy vertikálisan és/vagy horizontálisan kell a terhelést elosztani, akkor azzal problémák lesznek.

          Az is igaz, hogy jó Spring-es embert könnyebb szerezni, mint jó JavaEE-s embert... mert attól, hogy a platform remekül képes skálázódni, attól még képesek a fejlesztők ezt remekül eltoszni... (smile)

        2. Sajnos az, hogy Spring, vagy JEE nem csak a terheléstől függ, hanem főként a feladattól. Például egy elosztott (cluster) rendszer esetén a JEE szolgáltatásokat sokkal könnyebb rábízni a konténerre, mint mindenféle pluginekkel játszani.

          Én azt gondolom, hogy akkor tudsz igazán dönteni, ha pontosan tudod mit akarsz csinálni és mindkét eszközt (szabványt, framework-öt, stb.) alaposan megismered.

          Szerencsére a neten elég sok jó doksi található erről. Az a fontos, hogy egyik oldal híveire se hallgass, ha nem tudnak megfelelő megoldást mondani a problémára.

          Mint ahogy Gábor lejjebb írja, nagyon sok a tapasztalatlan fejlesztő mindkét oldalon.

          A lényeg: 80% tervezés 20% kódolás! (smile)

  5. Gábor, sajnos le kell, hogy törjem a JBoss iránti lelkesedésed. Mondhatni a 7.1.1 egy rakás szar.

    Fejlesztek, tesztelek egy 12 gépből álló clusteren futó alkalmazást , ami a JBoss 7.1.0-n tökéletesen fut (kivéve, hogy a relay a DC-k között ott sem megy), azonban a 7.1.1-nél olyan értelmetlen hibaüzenetek jelennek meg, hogy semmi utalás sincs a hiba valódi okára.

    A másik, ami a JBoss-ban hihetetlenül jó, hogy néhány alap JEE szabványt is másként értelmez és a dokumentációja jóindulattal is jegyzetnek nevezhető. 

    Én azt mondom, ha csak web alkalmazás, akkor Spring, ha elosztott szolgáltatás, akkor JEE.

    Az, hogy jó valaki vagy sem, az nem attól függ, hogy Spring, vagy JEE. 

    1. Gábor, sajnos le kell, hogy törjem a JBoss iránti lelkesedésed. Mondhatni a 7.1.1 egy rakás szar.

      Ööö... én nem lelkes vagyok, hanem realista... (smile)

      Fejlesztek, tesztelek egy 12 gépből álló clusteren futó alkalmazást , ami a JBoss 7.1.0-n tökéletesen fut (kivéve, hogy a relay a DC-k között ott sem megy), azonban a 7.1.1-nél olyan értelmetlen hibaüzenetek jelennek meg, hogy semmi utalás sincs a hiba valódi okára.

      Valószínűleg kiléptél a JavaEE6 határán, amelyet a 7.1.0 még tolerált, a 7.1.1 pedig már nem... egyébként érdemes TRACE szintre tenni a logolást, meglepően sok információt közöl a JBoss a működéséről és a hibákról.

      Én azt mondom, ha csak web alkalmazás, akkor Spring, ha elosztott szolgáltatás, akkor JEE.

      Ezt értem, de tipikusan nem "web alkalmazás" használati eseteként került szóba a Spring.

      Az, hogy jó valaki vagy sem, az nem attól függ, hogy Spring, vagy JEE.

      Én csak annyit írtam, hogy minden technológiának és keretrendszernek van egy küszöbe és egy plafonja. A küszöb akkor fájdalmas, ha nem tudja átlépni az ember, a plafon pedig akkor fájdalmas, ha eléri. (smile)

       

      1. Tényleg nem akarok flame-et!

        >Valószínűleg kiléptél a JavaEE6 határán, amelyet a 7.1.0 még tolerált, a 7.1.1 pedig már nem... egyébként érdemes TRACE szintre tenni a logolást, meglepően sok információt közöl a JBoss a működéséről és a >hibákról.

        Sajnos nem én léptem ki, hanem a JBoss, ami azért fura, mert a 7.1.0-ban és a 7.1.1-ben nem ugyanaz az eltérés a szabványtól. (pl. névterek, erőforráskezelés, stb.)

        Ha gondolod írok egy cikket a tapasztalataimról. A 6, 7.0, 7.1.0 és 7.1.1 szerverek teljesen másként konfigurálódnak és másképp is működnek.

        A Spring esetén az "elosztott" szolgáltatást hiányolom, azaz a szolgáltatás a web-tier része és nem az enterprise szervíz konténer menedzseli. Azaz a Spring határozza meg az erőviszonyokat és nem a konténer. 

        Így értettem.

        A többivel egyetértek.

         

        1. Igen, en is azt erzem, hogy a JBoss egyzser igy, masszor amugy mukodik egy verziovaltast kovetoen... Ezert dontottem inkabb ugy, hogy fejlesztes alatt Glassfish, aztan az eles kornyezetben majd meglatjuk mi lesz. De igy legalabb megfelelek a ref implementacionak... Pl. a 6.1 szerintem meg talan most sem felel meg a JEE5 specnek (persze mar meg sem fog). (smile) Jol emlekszem a @Singletone-t tuti nem ismerte. Az ok, hogy a 7.1 igen, de hat azert az nem regen jott ki. (smile)

           

          A Spring-el kapcsolatban amit irsz, egyetertek. De neha pont ezert "csabulok" el, mert par dolgot szerintem pont azert lehet esszerubben elkesziteni, mert ott ugy alakitom a mukodest, ahogy nekem tetszik, mig a kontener eseteben megbziom abban, hogy spec szerint csak jol mukodik. (smile) Egyebkent tobbnyire igen, nincs olyan nagy baj vele. De pl. a szalkezelest kicsit hianyolom belole, persze ez galibakat is okozhat, ertheto, hogy miert nem eroltettek.

  6. A JBoss 6.1 a JEE5 specifikáció keretein belül azért nem támogatta a @Singleton-t mert az JEE6 spec.

    A többiben Gáborokkal nagyrészt egyetértünk. 

    A szálkezeléssel pls. ne komolytalankodjunk. A JEE alapú megközelítések az erőforrások direkt kezelését, így a szálkezelést is a container-re bízzák, részint, hogy azok felhasználása kontrolláltan történjen, részint, hogy a fejlesztőnek ne kelljen ezzel foglalkozni. Ha JEE-ben a szálak kezelése olyan, mint a JSE-ben a memóriakezelés. Ha szükséged van rá, akkor valamit nagyon benéztél!

    A "flexibilis" megoldások és a keretrendszerből kinyúlások nagyon rövid távon karbantarthatatlan és továbbfejleszthetetlen kódkupacokat eredményeznek. Ezzel pályám során rengeteg alkalmam volt találkozni. Sokan nem tudják belátni, hogy nem okosabbak azoknál a keretrendszerek és szabványok kidolgozását végző profiknál és megpróbálják azokat megkerülve "hatékonyabb" és "egyszerűbb" megoldásaikkal behálózni a kódot. Gyakran kerülök olyan helyzetbe, amikor régi kódok elemzésénél felmerül a kérdés, hogy "Mire is gondolt a költő?". Egyik "kedvenc" ilyen megoldás az Exception-ök manuális dobálásával, azok több ősosztállyal feljebb elkapásával az üzleti logika lefutásának irányítása. Itt már azonban gyanús, hogy a költő igazán vonzódott a különböző zőldfűszerekkel megszórt gombafélék LSD-be mártott kokalevélbe csavarásához, majd elszívásához, gondolkodni pedig már nem szokott.

    Amúgy meg a Confluence is Springben készül, tehát ez a beszélgetés sem jöhetne nélküle létre. (smile) (Hozzáteszem a nagy okosságokat Auth kolléga már leírta előttem, mert Android browserből még nem használható a felület)

    1. Igaz, JEE6 spec, de mar a JBoss 6.1-et JEE6 kompatibiliskent fejlesztettek, ami nem jott ossze, csak a 7-ben.

      Nem neztem be semmit es hidd el tisztaban vagyok vele, hogy mi a koncepcio. Tobbsegeben nem kell, de van ugy, hogy egy hosszabb projektnel olyan dolog jon elo, amire kezdetekkor nem keszulhettel es volt olyan eset, amikor nekem jol jott volna. Egyebkent feltetelezem, pont ezen igenyek miatt vezettek be az  @Asynchronous-t JEE6-ban.

       

      1. Igaz, JEE6 spec, de mar a JBoss 6.1-et JEE6 kompatibiliskent fejlesztettek, ami nem jott ossze, csak a 7-ben.

        Technology preview volt.

        Tobbsegeben nem kell, de van ugy, hogy egy hosszabb projektnel olyan dolog jon elo, amire kezdetekkor nem keszulhettel es volt olyan eset, amikor nekem jol jott volna.

        Tiszta sor, sok minden jól jönne, amikor egy hosszabb projektnél kiderül, hogy baj van az alapokkal... csak amikor az élesbe állítás után üzemeltetés közben a pillanatnyi igények kibillentik a szervert a komfortzónájából, akkor nem mindegy, hogy az üzemeltetés képes beavatkozni és a thread pool méretét EJB szinten módosítani, hogy a fontos funkciók továbbra is működjenek és a kevésbé fontos funkciók lassuljanak be vagy dobjanak timeout-ot, vagy sem.

        A szálak szabad indítása azért tiltott dolog, mert a konténer dolga a Quality of Service biztosítása, és bizonyos alkalmazás szerverek meg is próbálják az előírt SLA-t betartani az erőforrások elosztásával, azt pedig csak úgy lehet, ha a futó programok nem maguk kezelik az erőforrásokat, hanem a konténer biztosítja azokat. Spring esetén ez a koncepció hiányzik, olyan, mint annó a DOS volt egy Unix rendszerhez képest: sokkal szabadabb, sokkal gyorsabb, sokkal rugalmasabb, ugyanakkor sokkal sérülékenyebb és jóval kevéssé felügyelhetőbb.

        1. Szerintem Technology preview lett... ha rossz indulatu akarok lenni (smile)

          Nem az alapokkal volt baj, hanem az igenyek valtozasaval. Eleve az ember elore gondolkozik amennyire lehet, hogy rugalmas legyen a projekt, de minden eshetosegre nem lehet szamitani. Az ugyfel meg sajnos azt hiszi, hogy hat meg "ezt a kis aprosagot kerem", csak az nem aprosag valojaban.

          A tobbivel egyetertek, amikor nyitottam a temat es a JEE elonyeit soroltam, pont ezt irtam, hogy a service reteg es annak teljesitmenyre hangolasa nagyon kellemes dolog. Viszont az, hogy a szalkezeles valos problema volt onnan is latszik, hogy a JBoss is probalt az alkalmazasszerverbe beepiteni ilyen funkciot(mar nem emlekszem milyen class-kon keresztul) korabban, amivel ez megvalosithato. Egyebkent, osszesen csak egyszer lett volna ra szuksegem, de hat kerulo megoldassal is sikerult elernem amit szerettem volna, ez csak egy alternativ lehetosegkent merult fel.