[Java lista] j2ee socket server

[bognár attila]

> A tuzfal valoban problema lehet, de amikor az RMI-t kitalaltak, akkor
> meg nem volt minden ugy betuzfalazva, mint most. Mindenesetre
> egyszerubb es kevesebb hibalehetoseggel jar atlyukasztani egy tuzfalat
> az RMI-nek, mint sajat protokollal buveszkedni.
>   

- 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 :-) )

- 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)?

- egy ping funkciót megvalósító alkalmazást nem feltétlenül rmi-vel 
célszerű megvalósítani és tűzfalakkal bajlódni (a feladat komplexitása 
nem derült ki a leírásból, pusztán egy követelmény, ami könnyen lehet 
indokolható)


> (A szoftveresek altal tervezett kommunikacios librarynel pedig csak
> egy rosszabbat ismerek: a hardveresek altal tervezett kommunikacios
> libraryt.)
>   

Szerintem a kettő keverékéből lehet normálisat kigyúrni, aki figyelembe 
veszi azt, hogy mire lehet normálisan fejleszteni, de az 
infrastruktúrális adottságokkal is számol. Ha ilyen egyveleg nincs is, 
akkor a szakterületeknek nem árt kommunikálni, mint például egy 
építésznek a gépésszel, különben elég faramuci dolgok derülnek ki az 
építés során, aminek általában az a tünete, hogy az építő a haját tépi 
és őszül, a pénztárcájából pedig folyik ki a pénz.

A felvetésedet sem értem: attól, hogy Neked nem fekszik a socket-ezés, 
másnak pont arra lehet szüksége (mellesleg esetleg a kérdezőnek sem 
igazán fekszik, de ütik-vágják, azaz nem sok választása van).
Szerintem az API-ban sem csak azért szerepel, hogy az SSL és RMI libek 
tudják használni, mert ez esetben pl. com.sun.socket.BlaBla osztályok 
lennének.

üdv,

attila