[Java lista] j2ee socket server

Hollósi Balázs hollosibalazs at gmail.com
2007. Feb. 1., Cs, 10:00:51 CET


Szépen felhízott a téma.. :) a socket több okból preferált jelen
esetben. egyrészről mert elég sokat használtam már, és eddig kevés
problémám volt vele (standalone alkalmazásoknál, appleteknél)

Jelen esetben inkább a j2ee-ben való implementálás ami kevésbé
fekszik, nem tudtam milyen kultúrált módja van, fiatal vagyok még az
enterprise apiban :).. utolsó gondolatom lett volna pojo, vagy pl egy
preparált servlet:
http://www.porcupyne.org/docs/browse_source/JavaServlet/com/oreilly/servlet/DaemonHttpServlet.java.html
reméltem hogy van rá olyan megoldás ami közelebb áll az appserverhez,
végülis egy másik domain is figyelhet az általam kiszemelt porton,
aztán valamelyik elkezdi dobálni a hibát hogy valaki már rátelepedett,
miközben házon belül van, akár tudhatna is róla, menedzselhetné,
stb.).

másik oldala, hogy a kialakuló protokollt több féle kliens is
használni fogja (pl j2me is, ahol elég korlátozottak a lehetőségek,
sok mindent nem raktak bele az api-ba, ha jól tudom az rmi is kimaradt
(talán a CLDC profilban egyáltalán nincs, csak a CDC-ben lehet benne,
de ott is csak opcionális). stb. stb. szóval socket. de ha van
alternatívája a felsorolt követelményeknek megfelelően, még nem késő..
:)

köszi a válaszokat
B

On 2/1/07, bognár attila <attila at netalfa.hu> wrote:
>
> > 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
>
> _______________________________________________
> Javalist mailing list
> Javalist at javagrund.hu
> http://javagrund.hu/mailman/listinfo/javalist
>


További információk a(z) Javalist levelezőlistáról