[Java lista] j2ee hatterben futo szal

[bognár attila]

> Ez igaz. Sok esetben nyilvan overengineering erre keszulni. De egy ilyan altalanosan
> felvetett kerdesnel valoszinuleg mindenki a sajat szemszogebol valaszolgat.
> Tehat aki skalazhatosagi problamarol ir, az valoszinuleg olyan projecteken
> dolgozik, ahol ez fontos (csak nem teszi hozza). Ebbol aztan persze konnyen
> valik 'nepi bolcsesseg'.
>   

szerintem sokan szeretnek általánosságban gondolkodni (ami nem baj, de 
az általánosságnak a nem skálázandó alkalmazások is részei), 
hipotetikusan gondolkodni, vagy játszani a hozzáértőt.


>> természetesen - mint mindenhol máshol, legyen az egy egyszerű vonalkód generáló - 
>> meg kell nézni, hogy minek milyen hatása van/lehet az egész rendszerre, alkalmazását 
>>     
>
> Igy van. En a hozzaszolasok kozt talaltam erdekes szempontokat.
>   

tény és való, én is. el is tettem a könyvjelzők közé. a gondom leginkább 
az, hogy az egészből az jön le, ami a népmese: ne használj szálakat, 
éljen a mamut java. (azért megdöbbentő, hogy már milyen sok éve volt az, 
hogy még egy-két év és a java nagyon jó lesz, mert a hardverek elég 
erősek lesznek futtatni. sajnos még most sem mindig elég erősek, a java 
alkalmazások erőforrásigénye sajnos lépést tart a hardver erőforrásokkal)


>> szál állapota hibatűrés esetén: szerintem az már tervezési és megvalósítási 
>> kérdés, hogy egy szál "csak úgy" van, vagy pedig az állapotát vagy azzal 
>>     
>
> A dolog nyilvan megoldhato, szerintem azert erdekes a megjegyzes, mert aki
> csak ugy nekiesik szalakat inditgatni, az nem feltetlenul gondol bele
> ebbe a mellekhatasba. Hiszen amugy a servlet containerek azt igerik, hogy
> programozas nelkul automatikusan kezelik a session failovert.
>   

ahhoz, hogy a fentiekt beállítsd, és úgy használd, nyilván sok mindennek 
utána kell nézni, többek között illik megkérdezni az alkalmazás 
fejlesztőjét, hogy a rendszer támogatja-e, vagy eleve úgy kell 
megrendelni, hogy támogassa. ha ilyenre van szükség, eleve nagyon 
körültekintőnek kell lenni, és szerintem nem azt kell elvárni, hogy az 
EE container csettintésre mindent megcsinál és Neked semmive nem kell 
foglalkoznod, hanem azt, hogy erőteljes támogatást ad hozzá, aminek 
nyilván megvannak a feltételei, amiknek nyilván utána kell pontosan nézni.
és nyilván az is kérdés, hogy mit csinál az a nyomorult szál.


> Igy van: C-ben valoszinuleg 20ad annyival is elmenne. Mondjuk 30x annyi ideig
> tartana osszeszerelni :). Ez egy ismert kompromisszum. Jelen van nyelvi szinten is
> (C/C++ vs. Java/Script nyelvek) meg platform szinten is (mezei java alkalmazas,
> web alkalmazas, alkalmazas szerverben futtatott komplett JEE alkalmazas).
>
> A kifejezetten csak a feladatra keszitett alkalmazas biztosan kevesebb memoriat
> es processzort fog hasznalni, mint az eloregyartott komponenseket is felhasznalo,
> viszont egy csomo plusz munkaba (idobe/penzbe) fog kerulni.
>   

Jó, hogy olcsó a memória, de 4GB (a példánál maradva) azért ma is tétel. 
Főleg akkor, ha sok ilyen java alkalmazás van, ilyen követelményekkel, 
főleg ha mindezt szerverben kell megvalósítani, ráadásul hibatűrően. És 
akkor azért előjön, hogy egy ilyennek mekkora fenntartási költsége van, 
mindezt beszorozva a telepítések számával (mert mondjuk nem egyedi a 
szoftver) kijöhet egy olyan összeg, hogy esetleg olcsóbb lett volna +6 
emberhónapot fejleszteni, és külsőleg (értsd: system requirements 
fejezet) is jobban mutatna.
(azért azt is tegyük hozzá, hogy a C-s "mindent mi csinálunk, mert fasza 
gyerekek vagyunk" és a Javas összehányjuk a mamut .jar-okat és mindent 
futtatunk között azért nem kis átmenet van)

A dolog egy másik aspektusa, hogy sokszor feltételezett, hogy az 
újrafelhasznált részeket jól írták meg. A gond ott van, hogy az is lehet 
egy rakat barna, akár kódminőség, akár erőforrás, akár függőségkezelési 
szempontból, ami összeségében ismét költségeket generál (akár rosszabb, 
hiszen nem várt költségeket!!) - pedig elsőre azt is lehetne hinni, hogy 
fix ára van: OS projekt esetén ingyenes, fizetős esetén előre 
meghatározható összeg. Most akkor hogy csoportosítjuk a költségeket, 
kinek érdeke jobbat csinálni, kinél mi csapódjon le?

Tudom, hogy time2market és egyéb szempontok is vannak, de néha van olyan 
érzésem, hogy az EE néha már kezd nekifutni a lónak, hogy átugorja.


> Mondjuk en lattam mar peldat arra is, hogy valaki ugy akart tul okos lenni,
> hogy egybol a fejlesztes elejen elkezdett sporolni a majdani rendszer 
> eroforrasaival: '...dehogy, C++-ban, mert a java tul lassu'. Ezt egy ismert
> online jatek fofejlesztoje, kitalaloja mondta egy beszelgetesben. A beszelgetes
> ugy kezdodott, hogy megkerdezte tolem, hogy nem ismerek-e valakit, aki jol
> ert az elosztott rendszerekhez, mert kezdik nehezen kiszolgalni az itthoni piacot,
> plusz Nemetorszagba es az USAba is eladnak a jatekot, ahol min. 10x ekkora
> terhelesre terveznek. Biztos megoldottak valahogy, lehet, hogy sporoltak 2
> szervert meg 3GB memoriat, de anyagilag biztos buktak a dolgon. (Ettol fuggetlenul
> igazad van abban, hogy a javas megoldasokat biztos sokan tulmeretezik, mert
> abbol 'nem lehet baj')
>   

Kérdés, hogy a költségekbe azt is beleszámították-e, hogyha Javában 
készül és kicsit olcsóbb, ellenben nagyobb az erőforrásigény, akkor 
mennyit adtak volna el és mi lett volna a végső mérleg. (az is kérdéses, 
hogy egy ilyen apróságon múlott-e a projekt sikere, hiszen a megfelelő 
marketing sokkal fontosabb, mint a termék minősége)
(és még az is hozzátartozik, hogy mi alapján mondta azt, hogy a java túl 
lassú és amitt nem abban csinálták? valószínűleg a mindenféle mamut java 
alkalmazásokról szóló történetek miatt)

A teljességhez nyilván hozzátartozik az is, hogy minden nyelven lehet 
jól és pancserul is fejleszteni. Egyik kedvenc példám (ha már játék) a 
javában írt Doom. Én nehezen akartam elhinni.

üdv,

attila

--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: http://javagrund.hu/pipermail/javalist/attachments/20061201/250ac345/attachment-0001.html