Java webes keretrendszerek az iparban
2012-09-18T18:18:41+02:00
2013-02-02T22:39:11+01:00
2022-07-19T02:07:33+02:00
  • Bármi kell szinte van rá gem.

    Nekem symfony-ban az volt a tapasztalatom, hogy több szopás volt a pluginokkal, mintha kézzel írtam volna meg őket. Nyilván az ügyfélnek 'picit' más kell, mint amit a plugin csinál, és akkor kezdődhetett a milliónyi konfiguráció, hogy akkor egyes helyeken az én felüldefiniálásomat használja, stb. Én azt szeretem, ha egy bizonyos absztrakciós szint alá nem megy a plugin, mivel onnantól használhatatlan.

    A java fejlesztés lassúságának szerintem több oka van. Az egyik, hogy fordítani kell. (Bár gondolom ezt már megoldották, mert pl play-scala ha módosítok egy fájlban akkor azt lefordítja és azzal fut tovább, nem kellett az egész stacket újraindítani kézzel. )

    A Hot Swapnek nevezett dolog elég jól működik, igaz egy-egy osztályt így is újra kell fordítani, de az is megvan 1-5s alatt.

    Másik lehet, hogy mások a követelmények, olyan üzleti helyeken ahol azt használják nem az van, hogy most kitalálok valami funkciót és 3 óra múlva le is fejlesztettem, hanem valaki valahol kitalál valamit aztán azt lefejlesztik de lehet nem is lesz rá szükség, vagy mire kész lesz addigra teljesen out of date.

    Ezt a részt nem értem.

    A dinamikussága miatt rubyban sokkal jobban lehet gányolni mint javában, de nyilván ez az előnyére is válhat.
    Pl az ActiveRecordhoz képest a squeryl egy szenvedés szerintem. (Vagy pl a hibernate)

    A hibernate-ben mit találsz kényelmetlennek/rosszabbnak, mint active recordsban? Én roppant kellemesnek tartom. Active records-ot a tutorialon túl nem nyúztam, nem tudom, igazán összetett lekérdezéseket is össze lehet-e vele dobni. No meg hibernate-hez elérhető pl. egy generic dao, amivel meg már tényleg nagyon egyszerű adatokat szüretelni.

    Valószínűleg a hosting is nehézkes, bár nyilván ez a felhőplatformokkal megoldott, de ha nincs alá vasra pénzem akkor miért válasszam a javat ahol a fejlesztők drágák és még ratyibb is mint a RoR.


    Elég egy virtuális szerver, ami mostanság már akár egy évi húszasból megvan. Miért lenne ratyibb?

    Azért szeretik amúgy a javát mert pl le sem fordul ha nem kezeltél le minden exceptiont, vagy ha nem jók a típusaid.

    Komoly rendszerekben mindkét platformra szükséges unit/integrity/system teszt, de valóban a szigorú típusosságot ám is nagyon szeretem.

    Tényleg érdekelne akár egy rövidke kódrészlet, ami RoR-ban(vagy csak simán rubyban) sokkal rövidebb hasonló olvashatóság mellett, mint javaban.

    De azért az elsődleges kérdésem továbbra is JSF vs Spring
    Mutasd a teljes hozzászólást!
  • Azért használják a RoR-t sok helyen (főleg külföldön), mert nagyon gyorsan lehet benne fejleszteni, ha meg bejön akkor átírják másra, ami gyorsabb, ha egyáltalán szükséges lesz.

    Bármi kell szinte van rá gem.


    A java fejlesztés lassúságának szerintem több oka van. Az egyik, hogy fordítani kell. (Bár gondolom ezt már megoldották, mert pl play-scala ha módosítok egy fájlban akkor azt lefordítja és azzal fut tovább, nem kellett az egész stacket újraindítani kézzel. )
    Másik lehet, hogy mások a követelmények, olyan üzleti helyeken ahol azt használják nem az van, hogy most kitalálok valami funkciót és 3 óra múlva le is fejlesztettem, hanem valaki valahol kitalál valamit aztán azt lefejlesztik de lehet nem is lesz rá szükség, vagy mire kész lesz addigra teljesen out of date.

    A dinamikussága miatt rubyban sokkal jobban lehet gányolni mint javában, de nyilván ez az előnyére is válhat.
    Pl az ActiveRecordhoz képest a squeryl egy szenvedés szerintem. (Vagy pl a hibernate)

    Valószínűleg a hosting is nehézkes, bár nyilván ez a felhőplatformokkal megoldott, de ha nincs alá vasra pénzem akkor miért válasszam a javat ahol a fejlesztők drágák és még ratyibb is mint a RoR.

    Azért szeretik amúgy a javát mert pl le sem fordul ha nem kezeltél le minden exceptiont, vagy ha nem jók a típusaid.

    Amúgy ez a play-scala frameworkben sem rossz és fényévekkel jobb mint javában fejleszteni, csak még elég új és elég fapados.
    (Pl nem lehet semmit berakni a sessionbe úgy, hogy azonnal elérhető legyen, csak a következő requestben. (Illetve van rá egy hack de az olyan ronda, hogy le sem írom. Emiatt pl nem lehet pl CSRF Tokent rakni kukiba ))
    Mutasd a teljes hozzászólást!
  • Sziasztok!

    Az elmúlt hónapokban szorgosan tanulmányoztam sok alternatívát, és valamennyire a bőség zavarába estem.

    JSF2 + Seam vs Spring stack(MVC, Security, Roo stb.) a legnagyobb kérdésem.

    Szimpatikus a jsf-hez elérő hatalmas komponens könyvtár és a pofonegyszerű, zéró-javascript AJAX megoldás. Nagyon gyorsan lehet készíteni jól használható UI-t, szinte automatikus AJAX-szal. Ellenben sokan szidják a neten amiatt, hogy nehézkes.

    Seam elképsztően lassú, sokáig tartott bekonfigurálni, de van egy pár hasznos fícsörje.

    Spring MVC-vel meg most kezdtem el ismerkedni, az is szimpatikus, csak hiányoznak belőle a jsf által nyújtott komponensek. Elvileg kombinálni is lehetne a kettőt, de azt nem ajánlják.

    Milyen tapasztalataitok vannak egyikkel-másikkal? A JSF2 mitől nehézkes? Mennyire zavaró, hogy nem tudod teljesen kontrollálni a html kimenetet? Milyen más hátulütők vannak, amiért nehézkesnek mondják? Miért van az, hogy akit csak láttam, mind a springet javasolta, bár hiányoznak a szuper komponenskönyvtárak?

    Kicsit más: azt is írják sok helyen, hogy pl. RoR mennyivel egyszerűbb, mennyivel produktívabb. Ellenben nem igazán hallani, hogy RoRban készítenének komoly, összetett rendszereket(pl. banki rendszer, vagy ügyviteli rendszer). Mi az egyik, ill. másik oka? Nem lehetséges, hogy csak azért mondják a java fejlesztést lassabbnak, mert azokban az alkalmazásokban, amelyet javaban fejlesztenek, sokkal jobb minőségű kódot állítanak elő?
    Mutasd a teljes hozzászólást!
  • ez tippeim szerint felnyalja az egesz file-t egy collection-be


    Nem, a getLines string Iterator-t ad vissza, a drop meg egyszerűen n (jelen esetben 1) elemet előre lép az iterátoban, és visszaadja az így keletkezett iterátort. A 'lines' változó (compile time meghatározott!) típusa type inference-el string iterator lesz. (Scala beli jelölése: Iterator[String]). Vagyis pontosanaz történik, mint amit a harmadik bekezdésedben írsz. Persze Scala-ban hasonlót többféleképpen el lehetne érni, ez a példa még annyira nincs is kihegyezve arra, hogy a nyelv erejét mutassa (még closure sincs benne:) ).

    Vannak olyan részei a Scala-nak, amivel nincsenek performancia gondok, ezek leginkább a Java-nál kifinomultabb és tömörebb szintaktikai elemek. Hátrányuk, hogy kicsit nehezebb a nyelv szintaxisát megtanulni mint a Java-ét, és amikor utoljára néztem gyengébb volt az IDE support mint a JAva-jé. De úgy egyébként inkább előnyei vannak.
    Az immutable stílus negatív performanciavonzataival egyetértek, emiatt vagyok én is óvatos a tisztán funkcionális stílussal és az immutable collection-ökkel kapcsolatban.
    Mutasd a teljes hozzászólást!
  • Na, ez peldaul nekem nem igazan arra pelda, hogy "a kod mondjuk nem annyira szep"... Szerintem szebb mint a java megfeleloje...

    A kerdes mondjuk az, hogy mennyire hatekony... ez tippeim szerint felnyalja az egesz file-t egy collection-be...

    Szivem szerint inkabb valami olyan jellegu konstrukciot hasznalnek, ami tudja hogy hogy olvasson egy sort a file-bol es passzolja tovabb a println-nek, aztan olvasson megint egy sort... stb. Valoszinuleg azt is sokkal tisztabban ossze lehet hozni mint a Java megfelelojet...

    Nem hasznaltam Scala-t meg, pontosan a funkcionalis tipusok okozta performance gondok miatt... de ettol meg valoszinuleg eleg jol hasznalhato kodot lehet vele gyartani... a trait-ek pl. tetszenek...
    Mutasd a teljes hozzászólást!
  • Nekem annyi van meg a javából hogy egy iszonyúan szószátyár nyelv.

    Ez nekem kifejezetten tetszik (no nem a kilométeres XML konfigurációk). Nem varázslás történik, hanem jól átlátható, hogy az adott kódrész mit csinál, így a kód magát magyarázza.
    Mutasd a teljes hozzászólást!
  • Azt még hozzá akartam szerkeszteni, csak már nem engedte, hogy:

    Én mondjuk csak szezonális java kóder vagyok, szóval keveset tudok az ipari standardokról. Nekem annyi van meg a javából hogy egy iszonyúan szószátyár nyelv. (Nah meg kicsit játszottam Springgel, Hibernattel, meg XML hellekkel stb)
    Mutasd a teljes hozzászólást!
  • - mindig kell tudnod, milyen típussal dolgozol
    - nem fogsz egy tömbbe bepakolni teljesen idegen típusokat(egyébként ide-oda kell castolni, ami miatt gyanús lesz, hogy valamit gázul csinálsz)
    - nem fogsz egy változónak különböző típusú értékeket adni
    - nem fogsz meghívni int-re string-függvényt(ill más kombinációkban)
    - nem fogod deklarálatlan változó értékét olvasni
    - nem void függvényből biztosan vissza fogsz térni valamivel

    +1 egy jó IDE mindig pontosan tudja, hol, milyen típust használsz, így egy refaktorálás gyerekjáték, és az esetek szinte teljes egészében hibamentes, szóval ha valami gyanúsan gány, gyorsan refaktorálni tudod(ez főleg a fejlesztés időszakára vonatkozik, ha már az alkalmazás 40% függ az adott kódrészlettől, nagyobb gondban lehetsz)

    Várom a cáfolatokat :)
    Mutasd a teljes hozzászólást!
  • Inkább a java helyettesítő részére gondoltam, nem a funkcionális részére. (Tehát nem az immutable listek, meg hasonlók, hanem a java beépített dolgait haszálni)

    Pl fájlbeolvasás:

    var lines = io.Source.fromFile("labirintus.txt").getLines drop 1 for(line <- lines ){ println line }

    Ami nálam már alapból megér egy pirospontot javához képest
    Mutasd a teljes hozzászólást!

  • Próbáld ki a scalat. Mindent használhatsz amit javaban, viszont olyan mintha nem is lennének típusok, és mégis vannak!
    De tényleg, szerintem nem rossz. A kód mondjuk nem annyira szép az bizti.


    Nekem valahogy pont az ellenkezo a velemenyem.

    1. Scalat ne probalja ki senki, amig nem erti hogy egy JVM-ben milyen szabalyok ervenyesek. Ergo eloszor tanuljon meg Java-ban biztonsagosan normalisan mukodo multithreaded kodot irni es ertse az adatstrukturak mukodeset.

    2. Scalaban sokkal szebb kodot lehet irni... csak a gond az hogy az a kod lehet nagyon szep, de attol meg az is lehet hogy az a szep kod nagyon nem optimalis lesz... az immutable adatstrukturakra epulo kodok altalaban ilyenek...
    Mutasd a teljes hozzászólást!
  • Jol ertem, hogy ezeket az "atlagos kodminosegeket" a prog.hu-n latott kodokbol szurted le?

    Esetleg tudnal konkret peldakat mutatni, ahol a statikus tipusossag miatt nehezebb ganyolni?
    Mutasd a teljes hozzászólást!
  • Java átlagos kód minősége vs php átlagos kód minősége viszonylag ilyen érzést ad. Igaz, sokkal kevesebb java kóddal találkoztam, de olyan igazán elb.tt java kódot még nem láttam, php-t meg naponta 20-at(lásd tudástár).
    Mutasd a teljes hozzászólást!
  • Neeeee, már megint?
    Mutasd a teljes hozzászólást!
  • illetve megfigyelésem szerint statikus típusosság esetén sokkal nehezebb gányolni


    Ezt megis mibol sikerult leszurni?

    Mutasd a teljes hozzászólást!
  • Nem hinném hogy előrébb vagy azzal hogy az elején hal meg az alkalmazásod vagy a közepén.


    De, mert nem fordulhat elő az, hogy úgy tűnik, mintha jó lenne, és az futás közben hal le. Pontosabban exceptionök így is vannak, de kicsit nagyobb biztonságot ad, illetve megfigyelésem szerint statikus típusosság esetén sokkal nehezebb gányolni.
    Mutasd a teljes hozzászólást!
  • Próbáld ki a scalat. Mindent használhatsz amit javaban, viszont olyan mintha nem is lennének típusok, és mégis vannak!
    De tényleg, szerintem nem rossz. A kód mondjuk nem annyira szép az bizti.
    Mutasd a teljes hozzászólást!
  • A szigorú típusossághoz való kötödés nem minden esetben előny. De egy gyengébben típusos nyelvet is lehet erősen típusosan használni. Szóval megoldás mindenre van, csak esetenként az egyik jobb néhol meg a másik. Fordításkori ellenőrzés? Helyette unit test. Nem hinném hogy előrébb vagy azzal hogy az elején hal meg az alkalmazásod vagy a közepén. De ez is ízlés kérdése. Igazából teljesen mindegy melyiket választod, mert java, .net és RoR is jó. Mindegyik kicsit másban. Olyan nincs ami mindenben jó és ami a legjobb :) Egy bizots, én .net felé nem mennék, ha jól olvastam a microsoft is kezd lemondani róla.
    Mutasd a teljes hozzászólást!
  • Nem rossz a MyBatis (en meg iBatiskent hasznaltam :) )
    Szamomra is az eppen eleg es nem tul sok kategoria volt.
    Mutasd a teljes hozzászólást!
  • Na, ezt a hozzaallast hianyolom a legtobb Java fejlesztobol akit ismerek... Mindenki hisz valamiben (persze, amihez ert). Es nyilvan az a legjobb... Pedig legjobb nincs. Szerintem.

    Hu, ha a projektjeimen tudnak, hogy en milyen egyszeru strukturat szeretek legjobban... Kiatkoznanak.
    Mutasd a teljes hozzászólást!
  • Nekem is eszembe jutott, és meg is néztem pár leírást, de számomra nagyon hiányzik a szigorú típusosság és a fordításkori hibaellenőrzés.
    Mutasd a teljes hozzászólást!
  • Esetleg felveheted a listára a Ruby on Rails-t is. Pár infó róla:

    Wiki
    Jobban kifejtve
    Mutasd a teljes hozzászólást!

  • bár .NET enterspájz a világom, meg kell mondjam h kifejezetten kedvelem a postjaidat. a technológiai különbségeken átlépve sokat lehet okulni belőlük bmely mainstream platformon is fejlesszen az ember.




    Koszi. Remelem mas is a jobbitasi szandekot latja bennuk, nem pedig a vallashaboru kovetkezo celpontjat (lasd ekezethiany vs. igenyesseg szal) :)
    Mutasd a teljes hozzászólást!
  • bár .NET enterspájz a világom, meg kell mondjam h kifejezetten kedvelem a postjaidat. a technológiai különbségeken átlépve sokat lehet okulni belőlük bmely mainstream platformon is fejlesszen az ember.
    Mutasd a teljes hozzászólást!

  • De ez is megvalósítható aszinkron Singleton bean-el. Bármelyik Session Bean-be injektálhatod, és miután átadtad az objektumodat az aszinkron metódusnak azonnal vissza is térhet. A Singleton-ban ahány szálon akarod annyin futtathatsz batch feldolgozást. Hiba esetén akár jelezhet is az aszinkron bean a Session Bean-ek (ha pl. rollbackelni kellett) Ebben én nem érzek semmi féle korlátozást.


    Na megneztem a Singleton EJB-ket.

    Ahogy gondoltam, sajnos nem igazan nyujt semmi tenyleg hasznalhato nagy skalazhatosagot lehetove tevo funkcionalitast.

    Ha container managed concurrency-t hasznalsz, az ugyanolyan mintha read-write lockokat hasznalnal... lassu es nem skalazhato.

    Ha bean managed concurrency-t hasznalsz akkor meg mi ertelme az egesz Singleton EJB hasznalatanak? Ugyanazt a kodot a Singleton EJB nelkul is hasznalhatod. A cluster-wide elerhetoseg nem ertek, mivel epeszu ember nem fog odavissza uzengetni fine grained muveletekkel JVM-ek kozott ha skalazhato rendszert akar epiteni.

    Az pedig hogy tobb szalrol adogass neki kereseket az meg teljesen ertelmetlen... eloszor szetdobalod egy szalrol a kereseket tobb szalra (avagy eleve tobb szalon kapod mert azt kenyszeritette rad a JEE specko) azert hogy ujra osszerakhasd oket batchelesre... teljesen logikatlan...


    Szoval a velemenyem tovabbra is all... a JEE specifikacio csak utban van az igazan nagy teljesitmenyu es skalazhato rendszerek fejlesztesenel.




    Mutasd a teljes hozzászólást!

  • Sajnos nem vagy hajlando ertelmezni azt amit irtam.

    Értelmezem, de a Springet nem csak 3rd party cuccokkal lehet használni, sőt az összehasonlítás a JEE-vel sem inkorrekt, mivel lehet azt mondani, hogy a két legnépszerűbb keretrendszerről van szó. Amivel érvelsz (egyedi fejlesztések), ott meg aztán nem sokat oszt vagy szoroz a Spring jelenléte. Valamint abban úgy néz ki egyet értünk, hogy a Spring nem skálázható, ill. nagy projektek esetében nem igazán játszik egyik framework sem.


    Nem egeszen ertunk egyet: amit en allitok az az, hogy a Spring nem befolyasolja a rendszer skalazhatosagat. A JEE-hez ragaszkodas igen. De hagyjuk...


    Nehezen tudom azt az üzleti igény elképzelni, ahol az kell, hogy összevonjam az ülzeti tranzakciókat egy erőforrás tranzakcióba (mert hiba esetén mi lesz?


    Ez nem kozvetlenul uzleti igeny. Ez mindossze az egyetlen megoldas arra, hogy egy bizonyos hataron tul skalazd a rendszert.


    Rollbackelünk? Vagy próbálunk hibát javítani, és csak a hibás adatokat visszadobni?


    Egyreszt, mielott elkezdenel irni, egy igen szigoru validaciot elvegezhetsz a memoriaban, ami biztositja, hogy logikai hiba ne legyen a kiirando dolgokban, igy ha az adatbazisba iras hibat dob, az csak amiatt lehessen, mert a DB nem erheto el.

    Ekkor a problema nem merul fel: se rollbackelni, se commitolni nem tudsz... Egyszeruen elkezded a memoriaban bufferelni a bejovo dolgokat, remelve hogy megjavul az adatbazis, utana ujraprobalod.


    De akkor már lehet drágább a leves, mint a hús.) De ez is megvalósítható aszinkron Singleton bean-el. Bármelyik Session Bean-be injektálhatod, és miután átadtad az objektumodat az aszinkron metódusnak azonnal vissza is térhet. A Singleton-ban ahány szálon akarod annyin futtathatsz batch feldolgozást. Hiba esetén akár jelezhet is az aszinkron bean a Session Bean-ek (ha pl. rollbackelni kellett) Ebben én nem érzek semmi féle korlátozást.


    Erre majd kesobb valaszolok, megnezem elobb ezt a Singleton beant, hogy pontosan mit biztosit.


    Es? Ez hol valasz a felvetett problemara? Az altalam emlitett ujonnan allokalt objektumok a Message-ek, a HttpRequest-ben minden ami benne van es deszerializalasra kerult, a request-ben talalhato input es outputstream... Aztan keres kiszolgalasa utan meg szemetgyujtesre... majd valamikor...

    A java-s webws keretrendszerek hátterében mindig áll servlet. Az pedig használ objektumokat, amik létrejönnek-megszűnnek. Hol van ez másképp? Vagy mi a megoldásod erre a GC-zésen kívül?


    Nagy Sandor megoldasat tudom javasolni (gordiuszi csomo atvagasa). Nem hasznalni webes keretrendszereket, sem servleteket a rendszer teljesitmeny kritikus reszen... Ugyis lassuak... Pontosan errol beszeltem, hogy a JEE specko all az utadba...

    Itt van ertelme low-latency messaging cuccokat hasznalni, mint pl. 29West (manapsag Informatica UM neven fut), IBM MQ LLM, stb. Ezek mind lehetove teszik hogy az altalad foglalt bufferbe pakoljak a message-eket (egyszerre amennyi jott es befer), nem pedig objektumokat peldanyosit.


    Hát ezt is másképp látjuk, de nem értem, hogy a multi core-os CPU-k korában miért baj az, hogy valami párhuzamosítva van? Egyébként, ha nem tetszik, szabadon konfigolható a pool mérete, akár 1-re is. ha még ez sem tetszik és teljesen szeretnél elrugaszkodni a megszokottól a JEE keretein belül, választhasz aszinkron, singleton (saját szál menedzselés) és akár applicationscope között.


    A parhuzamositas onmagaban nem baj. De ez nem jelenti azt hogy minden szalnak ugyanazt a vegyes feladathalmazt kellene vegeznie. Az nagyon rossz hatassal van a CPU-ban levo cache-ekre, kulonosen ha ezek a szalak kozosen irnak adatstrukturakat, es versenyezniuk kell cache sorokert (es minden lock alapu, synchronized alapu illetve CAS-al dolgozo adatstruktura versenyez a cache-sorokert ha tobb mint egy szal irhatja).

    Ha minden thread-nek megvan a sajat feladata amit lehetoseg szerint olyan adatokon vegez, amit csak o irkal, az sokkal elonyosebben hasznalja a CPU-ban levo cache-eket, es ennek nagyon szembetuno hatasa van a kod teljesitmenyere (CPU architekturatol es generaciotol fuggoen akar 2 nagysagrend is lehet a kulonbseg a vegyes feldolgozas es a feladattipushoz dedikalt szalak kozott attol fuggoen hogy L1-L2 cachebol (1-2 ns), L3 cache-bol (~10ns) vagy pedig a fizikai memoriabol dolgozik (~20ns + esetleg meg kell varni mig a masik CPU kiirja a dirty dolgait a fizikai memoriaba).

    Ha pedig tobb szalad van ami adatokert versenyez, akkor ezek kulonbozo socketeken is lehetnek, ami azzal jar hogy a cache sorok amikert versengenek, sohasem lesznek valojaban a cache-ben, mert folyton invalidaljak a CPU-k az adott cache sort egymasnal.

    Ha egyes szalaidnak jol meghatarozott tipusu feladatai vannak (egyik SSD-re irja az input journalt, a masik az output messaging buffer-be ir, a harmadik olvas az input messaging buffer-bol, a tobbi meg szamolgatja az uzleti logikat a bufferben levo adatokon parhuzamosan egymast nem akadalyozva), az sokkal hatekonyabb tud lenni, kulonosen ha nem akarod az egyes uzleti tranzakciokat kulon fizikai tranzakcioban is kezelni (mert akkor minden szalad kulon var a hattertarra). Sokkal hatekonyabb, ha minden szal osszebatchel annyit amit leghatekonyabban tud a celpontjanak tovabbadni (pl. device block meret-nek megfeleloen), a batchet kiirja, aztan jelez, hogy ezzel az adag adattal vegzett, nezheti a kovetkezo stage.

    Mindezt legtobbszor lehet ugy strukturalni, hogy a kulonbozo szalaid szinte soha nem versenyeznek cache sorokert, de legalabbis a versengo muveletek szama nem no a batch meretevel.


    Azért a JEE-ben elég sok mód van a tranzakciók kezelésének a finomhangolására. Az, hogy a konténer átveheti ezt a funkciót, az csak egy kényelmi szolgáltatás. Mint fentebb leírtam, egyszerűen megvalósítható multi-thread-es batch feldolgozó eljárás is mely összegyűjti a SessionBean-ek által tárolandó adatokat aszinkron módon.


    Masik postban fogok majd valaszolni ra (es lehet hogy csak kedden este).



    Azt egy szoval sem mondtam, hogy neked kell mindent lefejleszteni. Vannak ilyen library-k keszen, publikalt architekturakkal. Vannak 3rd party technologiak amiket hasznalhatsz kommunikaciora ilyen teljesitmenyszint mellett.


    Ez viszont érdekelne, hogy mikre gondolsz és milyen tapasztalataid vannak velük.


    Egyreszt emlitettem a low-latency messaging technologiakat. Ezek altalaban biztositjak a late-joinos perzisztens muticast messaging-et, amire sokkal jobban skalazhato failovert lehet epiteni amiatt, hogy nem kell a sajat processzeid kozt neked szinkronizalni, mert sokkal konnyebben elerheted, hogy azonos sorrendben lassa az inputot mindket processzed. Ekkor ha az allapotod csak az input sorrendjetol fugg (ergo minden event sorozatot egy kozos sorrendben kapsz meg), akkor biztositott hogy a ket processzed belso allapota azonos lesz ha azonos pontig dolgoztak fel az inputot.

    Tapasztalatok: sokba kerul... es megis szinte mindenhol hasznaljak valamelyiket, ahol nagyon nagy teljesitmeny es nagyon alacsony latency kell. Szerintem ez sokat elmond.

    Magara a kodod elrendezesere nem feltetlenul tudok mit ajanlani, ez nagyban fugg az adott processz feladataitol. Mindenkepp fontos, hogy a hardver lehetosegeihez illeszkedo modon strukturald az adatfeldolgozast, ne az lebegjen a szemed elott hogy mit mond a JEE altal javasolt architektura. Ha meggondolod, a JEE tervezesi alapelvei egyenesen visszavezethetok az RPC-ig, ami nem is tudom hany evtizedes technologia... ergo meg nem a mai hardver lehetosegeit ismerve terveztek. Abban az idoben fel nem merult az, hogy a fizikai memoria elerese szuk keresztmetszet lehet egy CPU-n futo tobb szal kozott... (akkor a memoria volt a leggyorsabb, nem volt CPU cache (arra csak az out-of-order feldolgozasu CPU-k miatt lett szukseg, aztan amiatt is hogy a memoria lassu lett a CPU-hoz kepest)... es persze az egy CPU-n futo tobb szal is csak alom volt... a szal implementacio maga sem letezett talan meg akkor.

    A lenyeg az, hogy a szalaid ne akadalyozzak egymast. Es ez nem csak annyit jelent hogy ne dolgozzanak kozos adaton egyszerre, hanem hogy a kulso eroforrasok eleresenel se versenyezzenek feleslegesen. Kicsit elcsepelt, de attol meg igaz: az eroforrasaid kezeleset is megfeleloen modellezni kell.

    Emellett javasolt a lock-free es a non-blocking algoritmusok es adatstrukturak gyakorlati ismerete, ami ehhez segitseget nyujthat. Ehhez meg kell a Java (vagy egyeb nyelvbeli) tobbszalusaghoz a platform (ertsd JVM) altal biztositott szolgaltatasok nagyon melyrehato ismerete. Ezen az altalam interjuztatott emberek 80-90%-a megbukott volna, ha csak ezt neznenk... Aki nem ismeri az eszkozeit, az csak veletlenul tudja a helyes architekturat megtalalni.

    A korabbi postokban volt egy-ket utalas elrejtve egyeb jol hasznalhato dolgokhoz, hadd ne ismeteljem magam... ha tenyleg erdekel, megtalalod mire gondoltam :)
    Mutasd a teljes hozzászólást!
  • Sajnos nem vagy hajlando ertelmezni azt amit irtam.


    Értelmezem, de a Springet nem csak 3rd party cuccokkal lehet használni, sőt az összehasonlítás a JEE-vel sem inkorrekt, mivel lehet azt mondani, hogy a két legnépszerűbb keretrendszerről van szó. Amivel érvelsz (egyedi fejlesztések), ott meg aztán nem sokat oszt vagy szoroz a Spring jelenléte. Valamint abban úgy néz ki egyet értünk, hogy a Spring nem skálázható, ill. nagy projektek esetében nem igazán játszik egyik framework sem.

    Eddig a szintig is jo par bottleneck-be bele fogsz utkozni:

    - tranzakciokezeles uzleti tranzakcionkent: 1 millio commit masodpercenkent fizikai tarolora? Ne vicceljunk mar... Valahogy ossze kell vonni a kulonbozo szalon erkezo uzleti tranzakciokat egy eroforras tranzakcioba... Na de session bean-ekkel ez nem megy...


    Nehezen tudom azt az üzleti igény elképzelni, ahol az kell, hogy összevonjam az ülzeti tranzakciókat egy erőforrás tranzakcióba (mert hiba esetén mi lesz? Rollbackelünk? Vagy próbálunk hibát javítani, és csak a hibás adatokat visszadobni? De akkor már lehet drágább a leves, mint a hús.) De ez is megvalósítható aszinkron Singleton bean-el. Bármelyik Session Bean-be injektálhatod, és miután átadtad az objektumodat az aszinkron metódusnak azonnal vissza is térhet. A Singleton-ban ahány szálon akarod annyin futtathatsz batch feldolgozást. Hiba esetén akár jelezhet is az aszinkron bean a Session Bean-ek (ha pl. rollbackelni kellett) Ebben én nem érzek semmi féle korlátozást.

    Es? Ez hol valasz a felvetett problemara? Az altalam emlitett ujonnan allokalt objektumok a Message-ek, a HttpRequest-ben minden ami benne van es deszerializalasra kerult, a request-ben talalhato input es outputstream... Aztan keres kiszolgalasa utan meg szemetgyujtesre... majd valamikor...


    A java-s webws keretrendszerek hátterében mindig áll servlet. Az pedig használ objektumokat, amik létrejönnek-megszűnnek. Hol van ez másképp? Vagy mi a megoldásod erre a GC-zésen kívül?

    Az emlitett EJB-k es a session bean pooling csak egy ujabb szog a koporsoban: minden szal kulon EJB peldannyal kommunikal... stateless session bean-ek eseten is!!!! Ezert kell oket pool-ozni... ez nem egy forradalmi ujitas... ez a barna halom formazasa...

    Minek egy kulon peldany minden szalhoz? Hol segit ez a skalazhatosagon? Es ha 10 kulonbozo fajta session bean-t kell meghivj akkor 10 peldanyt foglalsz szalankent... Nincs eleg szalhoz kotott objektum, mindenaron kell meg ennyi pluszba?


    Hát ezt is másképp látjuk, de nem értem, hogy a multi core-os CPU-k korában miért baj az, hogy valami párhuzamosítva van? Egyébként, ha nem tetszik, szabadon konfigolható a pool mérete, akár 1-re is. ha még ez sem tetszik és teljesen szeretnél elrugaszkodni a megszokottól a JEE keretein belül, választhasz aszinkron, singleton (saját szál menedzselés) és akár applicationscope között.


    Amig peldaul (es ez csak 1 pelda) a JMS message-et ack-zo commit utan az adatbazisban meg kell jelenjen amit csinaltal (atomicitas miatt), viszont ennek a commitnak a tranzakciot nyito es commitolo metodusod az ot hivo kodhoz visszaterese elott meg kell tortennie, addig ezeket az atrendezeseket nem lehet megejteni... mint mondtam, a skalazhatosag utjaba allt a JEE specifikacio...


    Azért a JEE-ben elég sok mód van a tranzakciók kezelésének a finomhangolására. Az, hogy a konténer átveheti ezt a funkciót, az csak egy kényelmi szolgáltatás. Mint fentebb leírtam, egyszerűen megvalósítható multi-thread-es batch feldolgozó eljárás is mely összegyűjti a SessionBean-ek által tárolandó adatokat aszinkron módon.

    Azt egy szoval sem mondtam, hogy neked kell mindent lefejleszteni. Vannak ilyen library-k keszen, publikalt architekturakkal. Vannak 3rd party technologiak amiket hasznalhatsz kommunikaciora ilyen teljesitmenyszint mellett.


    Ez viszont érdekelne, hogy mikre gondolsz és milyen tapasztalataid vannak velük.

    Termeszetes, hogy az elejen szamitani kell erre. Azert ahol penzzel dolgoznak, ott tudjak, hogy fontos amit lehet elore kiprobalni, tesztelni, es modositani ha szukseg van ra.


    Persze, de gondolom azért láttál olyan fejlesztést is, ahol megnőtt a forgalom és nem mindegy, hogy van-e hova nyúlni vagy sem. De amennyiben ez előre látható, - mint ahogy írtad is - akkor sem a Spring érdeme/hibája lesz, hisz 3rd party cuccok végzik a kritikus feladatokat.
    Mutasd a teljes hozzászólást!

  • nagy projekt esetében, ahol cluster, failover, load balanc, kutyafüle van és több ország fejleszője dolgozik párhuzamosan és a pénz sem számít, valamint az alkalmazás hardverigényei között min. 32Gb Ram szerepel, na ott nyoma sem volt sem JEE-nek, sem Springnek sem ORM-nek, teljesen egyedi megoldás volt, nulláról írva


    Itt igazan az az erdekes, hogy mit tudsz felhasznalni az adott technologiabol ami nem all a teljesitmeny utjaba.

    A kontenereknel altalaban a monitoring es menedzsment szolgaltatasok ilyenek.

    Az ORM az az utadba all... mindegy hogy JPA-nak vagy Hibernate-nek hivod... amig okos akar lenni es elkezd kutatkodni a sajat feje utan az adatbazisban, addig csak utban van. Ha az adatbazisba akarok irni, akkor irni akarok, nem olvasni. Lehetoleg minel kevesebb roundtrip-el, minel nagyobb mennyiseget. Adatbazis hiba meg csak olyan jojjon hogy sorry, de epp meghaltam, probald ujra... de constraint-eket felejtsuk el... csak lassit, es az adatbazis olvasni akar hogy ellenorizze... es mint mondtam, ne akarjon :(

    Spring-et mar lattam ilyen rendszerben... DI-re es JDBC-re hasznalva... persze nem a teljesitmenykritikus reszeken, ott altalaban nincs ido adatbazisba irni. A failover-re ott az input ujra lejatszasa illetve az input journal amit jo nagy blokkokban kiirsz mielott elkuldesz barmit amit az alapjan szamoltal... meg az active-active par.

    Igazsag szerint az adatbazis is az utban van, ha nem akar belole senki olvasni strukturalt modon (query-zve). Perzisztencia celra megfelel valami binaris adatot perzisztensen tarolo technologia is... lenyeg hogy kicsi legyen a latency-je es nagy blokkokkal tudjon dolgozni... es lehetoleg minel tobbfele threading modellje legyen...

    A 32giga memoria altalaban semmire se eleg... ennyit a notebookomba is beletehetnek...

    De egyebkent altalaban a teljesen egyedi architekturaval lehet a legnagyobb teljesitmenyt elerni...
    Mutasd a teljes hozzászólást!

  • Olyan értelemben igenis van értelme összehasonlítani, amikor ajánlatot kell adni és a Spring esetén vagy ezt betervezik, vagy pedig bukta lesz a projekt, mert hoppá, ezt nem tudja, valamit be kell tolni alá... Persze, lehet írni jobban skálázhatót, de én meg olyan rendszereket láttam, amik erőlködés nélkül jobban skálázható, mint akármilyen Springes hekkelés. Pont. Pláne akkor kezd ez izgalmas lenni, amikor már egy szerver nem elég.


    Sajnos nem vagy hajlando ertelmezni azt amit irtam. Pontosan arrol beszelek, hogy az alkalmazas szervert nem egy Spring-es hekkelessel kell osszehasonlitani, mert az hogy Spring az nem oszt, nem szoroz. Az alkalmazas szervert egy egyedi architekturaval kell osszehasonlitani, ami vagy hasznal bizonyos reszein Springet, vagy nem. A Spring nem befolyasolja a skalazhatosagot.

    A JEE specifikacio viszont sajnos egy limitet szab ra. Kesobb majd ezt reszletezem.


    Gondoltam elég lesz utána nézni annak amit leírtam, és azt is leírtam, hogy milyen rétegekben nyújt out of box megoldást a JEE. Valamint választott alkalmazás szervertől is függ, hogy mit és hogyan valósít meg, olvass légy szives figyelmesebben. Amúgy nem feltétlen ingyenes alkalmazás szerverre kell gondolni, de azt hittem ez értelemszerű.


    Kezdem erteni a problemad. Azt hiszed, nem vagyok tisztaban a JEE kontenerek/alkalmazas szerverek szolgaltatasaival. Tevedesek elkerulese vegett tudom milyen szolgaltatas tipusokat biztosit a JEE, dolgoztam korabbi verzioival (valoszinuleg legalabb olyan regen kezdtem mint te, ha nem regebben), szoval nem muszaj ugy kezelni mint a nyeretlen ketevest. Nem kell ezeknek utananeznem...

    Meg sem fordult a fejemben, hogy ingyenes alkalmazas szerverekbol induljak ki. Arrol volt szo hogy a skalazhatosagrol beszelunk. Termeszetes, hogy a specifikacio hasznalata melletti leheto legoptimalisabb eredmenyre gondoltam.
    Csakhogy en olyan rendszerekrol beszelek, ahol ez meg mindig keves. Bovebben kesobb.



    Ugyanezt elmondhatom arról is aki a Spring skálázhatóságát próbálja illeszteni a projektbe. Miért az talán sokkal egyszerűbb??? Pláne, ha esetleg menet közben derül ki, hogy probléma lesz. Az JEE esetén pár konfigolás, míg Spring esetén fejlesztés. Nem mindegy.


    Meg mindig nem erted mirol beszelek. A Spring jelenlete nem meghatarozo faktor. Vele is, nelkule is lehet akarmilyen skalazhatot es akarmilyen rosszat is irni.
    Igen, tudom, ha nem hasznalsz egy JEE kontenert/alkalmazas szervert, akkor mindig fejleszteni kell hozza, mert a Spring ilyen teren semmit nem ad. Ergo barmit fejlesztesz az alkalmazas szerver/JEE kontener request kiszolgalo stackje helyett, az a Spring-rol semmit nem mond. Barmilyen jo skalazhatosagot ersz el egy nem kontenerbe deployolt alkalmazassal, az nem a Spring erdeme lesz, es akarmilyen rosszat, nem a Spring hibaja. Hagyd ki a Spring-et a skalazhatosagi kerdesbol. Egyszeruen a fogalom nem ertelmezheto.


    Pláne akkor kezd ez izgalmas lenni, amikor már egy szerver nem elég.


    Ugyan... az a konnyu resze.
    A nehez resz az, amikor az egyik szervered elhalt... vagy csak GC-zik? Hogy allapitod meg? Mi van ha tevesen allapitottad meg? Mi van ha a teves megallapitas alapjan mar kuldtel valami uzenetet, ami kotelez teged valamire?



    Ezt kifejtenéd bővebben, mert ez így nem sokat mond. Melyik alkalmazás szerver? Milyen alkalmazás, ill. milyen skálázhatóság esetén? Komolyan érdekelne.


    Barmelyik alkalmazas szerverre igaz amit mondtam. A korlat, mint parszor elmondtam, a JEE specifikacio-hoz valo ragaszkodasbol adodik, nem a konkret implementaciobol.

    Eloszor jussunk el az alkalmazasszerverrel vagy clusterekkel egy belepo teljesitmenyszintig. Raerunk skalazhatosagon elgondolkozni ha egyaltalan a kezdeti szintet megugorja.

    CPU tipus legyen mondjuk modern 64bites Xeon procik.

    Kezdetnek eleg, az altalad emlitett JEE feature-ok (EJB-ket emlegettel leginkabb, es clusterezest... az igazat megvallva mindketto jobbara csak utban van... a clusterezes death detection resze az egyeduli ami hasznos) barmelyikevel ha elered az altalad valasztott alkalmazas szerverrel mondjuk 3-4 core-onkent az emlitett 1millio uzleti tranzakciot... azt elfelejtettem hozzatenni, hogy masodpercenkent, es mondjuk 1 milliszekundum valaszidovel!!!

    Ennel meg boven feljebb lehet menni ezen a hardveren, de nem a JEE specifikacion belul.

    Eddig a szintig is jo par bottleneck-be bele fogsz utkozni:

    - tranzakciokezeles uzleti tranzakcionkent: 1 millio commit masodpercenkent fizikai tarolora? Ne vicceljunk mar... Valahogy ossze kell vonni a kulonbozo szalon erkezo uzleti tranzakciokat egy eroforras tranzakcioba... Na de session bean-ekkel ez nem megy...

    - clusterezes: 1 millio uzleti tranzakcio utani allapotot akarsz atkuldeni a backup pair-re 1 mp alatt? Szinkron modban? Kizart... Aszinkron modban? Az meg adatot veszthet, tehat a failover nem biztositott, barmennyire is hajtogatod...

    - egyaltalan hany szalon akarod ezeket lekezelni? Arrol beszeltunk van 3-4 core-od... azon nem lehet tobb szaz szalat futtatni...

    - az alkalmazas szerverekkel adott messaging technologia sem kepes ennyi kerest egyaltalan behozni neked a JVM-be egyenkent



    Egyszeruen az, hogy 1 request/lifecycle metodus granularitassal kell a feladatokat kiszolgald, amiket ujonnan allokalt objektumok formajaban kapsz a konkret JEE API request ...

    Az mondjuk alapból tudja bármely JEE container, hogy poolozza a Session Beaneket (amely lehet stateless vagy Statefull) és még az is benn van, hogy a Stateless esetén is mehet a request ugyanahhoz a bean-hez, nem fog megszűnni az előző request után, csak az állapota nem tárolódik.


    Es? Ez hol valasz a felvetett problemara? Az altalam emlitett ujonnan allokalt objektumok a Message-ek, a HttpRequest-ben minden ami benne van es deszerializalasra kerult, a request-ben talalhato input es outputstream... Aztan keres kiszolgalasa utan meg szemetgyujtesre... majd valamikor...

    Az emlitett EJB-k es a session bean pooling csak egy ujabb szog a koporsoban: minden szal kulon EJB peldannyal kommunikal... stateless session bean-ek eseten is!!!! Ezert kell oket pool-ozni... ez nem egy forradalmi ujitas... ez a barna halom formazasa...

    Minek egy kulon peldany minden szalhoz? Hol segit ez a skalazhatosagon? Es ha 10 kulonbozo fajta session bean-t kell meghivj akkor 10 peldanyt foglalsz szalankent... Nincs eleg szalhoz kotott objektum, mindenaron kell meg ennyi pluszba?



    ami egy csomo szinkron muveletet definial es nem engedi hogy tetszes szerint atrendezd a request processing flow kulonbozo lepeseit akar kulonbozo kereseken atnyulva sajat szalkezelesi modellel, limitet szab a skalazhatosagnak, es soha nem fogsz tudni olyan teljesitmenyt elerni, mintha a hardver es szoftver (kernel, driverek) stack-ednek legmegfelelobb modeszerrel es meretekkel osszevonod a keresek feldolgozasat es feladat tipusonkent batcheled oket.


    Igen, csak ezzel nekem nem feltétlen kell foglalkozzak, mert beteszek még egy alkalmazás szervert (amit erre felkészítettek és teszteltek) és lehet megoldódott a problémám.


    Dugd csak a fejed a homokba... a problema az, hogy nem oldja meg a problemadat...

    Amig peldaul (es ez csak 1 pelda) a JMS message-et ack-zo commit utan az adatbazisban meg kell jelenjen amit csinaltal (atomicitas miatt), viszont ennek a commitnak a tranzakciot nyito es commitolo metodusod az ot hivo kodhoz visszaterese elott meg kell tortennie, addig ezeket az atrendezeseket nem lehet megejteni... mint mondtam, a skalazhatosag utjaba allt a JEE specifikacio...


    Ha ilyen mélységben kell lemenni, sem biztos, hogy jobb rendszer készül, mint amit az IBM, JBoss vagy akármi szerverei biztosítanak, plusz azért ez fejlesztési idő és költség.


    Azt egy szoval sem mondtam, hogy neked kell mindent lefejleszteni. Vannak ilyen library-k keszen, publikalt architekturakkal. Vannak 3rd party technologiak amiket hasznalhatsz kommunikaciora ilyen teljesitmenyszint mellett. Nem kell neked megirnod. De ezek egyiket sem igenyel alkalmazas szervert es nem igazodik a JEE specifikaciohoz, mert az nem lehetseges ilyen teljesitmeny szint mellett.

    A koltseg termeszetesen koltseg, mert ezek a 3rd party cuccok nem ingyenesek (meg csak nem is olcsok).

    A lenyeg, hogy a JEE specifikacio es a hozza igazodo alkalmazas szerverek nem a skalazhatosag es biztonsag netovabbja. Kozel sem. Olyan helyen hasznalhatoak, ahol nem kell adatokkal dolgoznia, hanem csak kereseket attenni a belso messaging technologiara es viszont. Itt nincs allapot amit karban kene tartania, ergo teljesen horizontalisan skalazhato ameddig akarod. A rendszer tenyleges teljesitmenyigenyes reszenek architekturaja teljesen fuggetlen az oket esetleg futtato alkalmazas szerverek request kiszolgalo funkcioitol. Oszinten szolva az okok ami miatt erdemes lehet valamilyen kontenert ennyire teljesitmenyigenyes rendszerben hasznalni, az a remote management es monitoring funkcionalitas. Ott ugyanis egesz kenyelmes funkciok vannak amik a teljesitmenyt nem rontjak, ha a tobbi cuccot, ami feleslegesen szalakat futtat, ki tudod banyaszni belole.


    Persze, ahol erre az elején számítanak. Node a másik véglet (ami jellemzőbb), hogy kész az alkalmazás aztán teljesítmény problémák esetén meg elfogyott a büdzsé, vagy lehet vakarózni. Na, én itt látom a JEE előnyét. Mindennél lehet jobbat írni, de nem feltétlenül kell abba időt ölni, ha van más megoldás (és az sem biztos, hogy jobb lesz).


    Termeszetes, hogy az elejen szamitani kell erre. Azert ahol penzzel dolgoznak, ott tudjak, hogy fontos amit lehet elore kiprobalni, tesztelni, es modositani ha szukseg van ra.


    Nem tudom otthon mi a helyzet... Én azt hiszem, hogy te élsz egy bizonyos hitben...


    En abban a hitben elek, hogy otthon nincs tozsdei kereskedelmi rendszer fejlesztes.



    Nekem olyat mutass légy szíves, amikor az egy gép nem elég, és elkerülhetetlen a a load balance, failover, cluster. Hidd el ilyen is van, jellemzően nagyobb rendszerek (banki és bizony van jó pár dobozos üzleti alkalmazás).


    Egy gep soha sem eleg mert barmikor meghibasodhat. De a masik gepre nem lehet orakat varni (masodperceket sem ha nem muszaj), mig eszreveszi hogy zur tortent, es felzarkozik a lemaradashoz.

    Load balance: ezzel is csinjan kell banni. Ha ez a load balance nagy mennyisegu allapot mozgatasaval jar, akkor az eleg lassu, es addig sem tudsz azzal az allapottal dolgozni. Load balance helyett, ha lehetseges, jobb a statikus particionalas dedikalt failover node-al, hogy ne kelljen adatot mozgatni.

    Failover: termeszetes hogy kell. De a legjobb, ha a rendszer eleve redundans (es lehetoleg active-active). Pl. ket node azonos sorrendben erkezo adaton azonos allapotot tart fenn a memoriaban, es idempotens message-eket kuld a kulvilag fele... mivel idempotens, mindegy hanyszor kuldi. Ha az egyik meghal, a masik akkor is kuldi a message-eket, tehat nincs kieses. Annyi szukseges meg, hogy vissza is tudj hozni egy uj node-ot hogy helyre tudd allitani a failover kepesseget. Erre pedig legjobb, ha a messaging technologia tud neked azonos sorrendu late joint adni az uzenetekre (latod mi tortent milyen sorrendben mielott ujra subscribe-oltal).


    Hidd el ilyen is van, jellemzően nagyobb rendszerek (banki és bizony van jó pár dobozos üzleti alkalmazás).


    Mint mondtam, nem nyeretlen keteves vagyok. Pontosan tudom hogy ezekre szukseg van, es eszembe se jutott, hogy ne lennenek ezek a rendszerben... egy par masodperces kieses is rohadt sok penzbe kerul...

    De nem mindegy hogy milyen modon oldod meg... low latency igenyek eseten a JEE session perzisztenciaja akkor is bottleneck tud lenni, ha nem adatbazisba hanem data gridbe mented, es onnan szeded vissza failoverkor a session state-et.

    Ezt csak egy active-active rendszer (lasd fentebb) tudja athidalni, ahol a masik active node addig is tartja a frontot mindig teljesen up-to-date mig a failover node felall.
    Mutasd a teljes hozzászólást!
  • Egyébként átgondoltam az eddigi prorejktjeimet, nekem eddig a következő volt a tapasztalatom java területen:
    - a Spring sok mindenre elég
    - ha nem, akkor többségben JEE egy szintig vagy Spring egyedi megoldásokkal (ebből láttam kevesebbet talán 1-2-t viszont sokról hallottam )
    - nagy projekt esetében, ahol cluster, failover, load balanc, kutyafüle van és több ország fejleszője dolgozik párhuzamosan és a pénz sem számít, valamint az alkalmazás hardverigényei között min. 32Gb Ram szerepel, na ott nyoma sem volt sem JEE-nek, sem Springnek sem ORM-nek, teljesen egyedi megoldás volt, nulláról írva

    Nekem ezek a tapasztalataim ezen a téren.
    Mutasd a teljes hozzászólást!
  • ugyanakkor kerdes, hogy tenyleg szukseg van-e kontener specifikus kodra. Ha nincs, akkor minden dependency-t DI-re deklaralva a teszt elvileg konteneren kivul is ugyanazt kene csinalja ha a dependency-ket sikeresen beinjektaltad.


    Igen, DI-vel megvalósítható, de nekem pont az nem tetszik, hogy pont a container-t kerültük meg. Valamint ha container-en keresztül tesztelhetem, akkor elég az adatbázis réteget kicserélni és 100% megegyezik az éles kód a tesztek kódjával. Míg más esetekben injektálhatom a teszt/mock bean-ket, ez meg idő.

    Ennyit arrol hogy szabvany... akkor megsem annyira az...


    Egy laza szabvány. De ezt nem kell magyarázzam, hisz az egész java világ a specekről és azok implementációiról szól. Egyébként ez nem azt jelenti, hogy kezdheted előről az alkalmazást, de problémák jöhetnek. Meg ugye attól is függ, mennyire térsz el a spectől. Másrészt ez tényleg marketing szöveg is, tény. Enterprise környezetben meg nem mindegy, hogy ki áll egy termék mögött. Egy community vagy egy/több multi.

    En nem mennek ennyire messzire, hogy valasztani kelljen. Miert kene valasztani?
    A Spring-et ugyanugy tudod konteneren belul is hasznalni. Pontosan az volt az egyik fo cel mar a legkorabbi verziok eseteben is, hogy adjon egy olyan absztrakcios reteget (a dependenciaidat nem neked kell elkerned, hanem a Spring injektal egy olyat ami kompatibilis a kornyezettel, es hogy mi kompatibilis azt nem kell a kodba tenni, hanem konfiguralni tudod), amibe csomagolva a kodod valtoztatas nelkul futtathato konteneren belul es kivul is.


    Persze, csak akkor nem értem mi értelme a Springnek a containeren belül? Miért hozzak be plusz egy réteget, amikor CDI már biztosítja a DI-t és vele már majdnem megkapom ugyanazt, amit Spring-el -> futni fog még Tomcat-en is vagy J2SE-vel, persze a "robusztus" illesztéseket nekem kell megcsinálni. A kérdés az, hogy nekem ez megér-e egy plusz réteget.

    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd