[Java lista] j2ee socket server

[bognár attila]

>> - tűzfal már akkor is létezett, ráadásul biztonsági funkciót is ellátott
>> (ha ezeket nem is nézzük, a szoftvermérnök egyik erénye a
>> tervezőképesség :-) )
>>     
>
> Letezett, de korantsem volt ennyire elterjedt. A legtobb embernek
> csupaszon logott a gepe a neten, esetleg egy ceg teljes intranetjet
> vedte egy, de belul nem volt semmi tagolas, mint most.
>   

Nyilván mások voltak a topológiák és elterjedtségek, de ettől 
függetlenül jelen voltak, egyfajta tendencia már látszódott.

A lényegen nem változtat: szűkült azon alkalmazások köre, amikor az RMI 
megfelelő megoldás, nekem az eredeti kérdésből az tűnt ki, hogy a 
megvalósítandó cél nem tartozik bele ezen körbe (lásd lejjebb).


>> - egy nagyobb vállalatnál, ahol pl egy hazai telephely is például
>> Hollandián keresztül lép ki a netre azért megnézném, hogy miként
>> sikerült ezt véghez venni (ha sikerül is mennyi idő és utánajárás) -
>> ezenkívül mi van például a felhasználói tűzfalakkal (gondoljuk egy
>> egyszerű csevegő programra)?
>>     
>
> Ez ugye mar a jelen, es nem a 90-es evek eleje-kozepe, amikor az rmi-t
> kitalaltak.
>   

Szerintem a kérdezőnek nem időutazást kell végeznie a feladat 
megvalósítása után, hanem a jelenben maradnia és beüzemelni az alkalmazást.


> EJB-rol volt szo, tehat nyilvan nem pusztan egy pingre volt szukseg.
> Javits ki, ha valamit rosszul olvastam.
>   

EJB-hez nem társítható egyszerű funkció (értsd: egyszerű bemenet, 
egyszerű kimenet, de a kettő között bonyolult logika), elképzelhetetlen 
az EJB-k hívása olyan környezetből, ahol nem alkalmazható RMI - például 
erőforrások hiánya, hálózati adottságok, eltérő platform?


Ehhez kapcsolódik:

> Koszonom szepen, en a magam reszerol nagyon jol megvagyok a
> socketekkel, es lehet, hogy masnak is pont erre van szuksege, de meg
> mindig tavoli EJB-hivasrol beszelunk, ha jol sejtem.
>   

A kiszolgáló oldali üzleti logika és az alkalmazáshoz történő távoli 
hozzáférés (ami akár többféle is lehet) két külön kérdés.


> Az ervelesed ettol fuggetlenul is santit, mert bar az API-ban szerepel
> a reflection is, ha teheted, azert megis mellozod a metodusok
> meghivasanal, nem igaz?
>   

Állítottam én valahol azt, hogy a lehető legkörülményesebb megoldásokat 
kell alkalmazni, még akkor is, ha van egyszerűbb? Csak azt akartam 
érzékeltetni, hogy attól, hogy van RMI, ott van a Socket osztály is 
például arra az esetre, ha az RMI nem lenne megfelelő, lehessen más utat 
választani.

Hollósi Balázs socketen akarta elérni az EJB-ket. Ha valaki EJB-zik, fel 
lehet tételezni, hogy hallott már az RMI-ről. Ha hallott róla és nem azt 
választja, valószínűleg megvan az oka. (szerintem nem nagy bűn 
intelligenciát feltételezni valakiről)

További kritérium volt: "egy folyamatos, duplex kapcsolatot igénylő 
klienseket kiszolgáló megoldást". A "duplex" értelmezés kérdeses - az 
RMI inkább két egyirányú kapcsolatról szól meglátásom szerint -, a 
"folyamatos" is értelmezés kérdése, de a kettő összevetésével én 
leginkább egy tcp csatornát látok magam előtt, mint megvalósítandó célt. 
Nyilván tévedhetek, de az RMI számomra akkor sem tűnik megoldásnak.

üdv,

attila

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