RMI még mindig csak localhoston megy

RMI még mindig csak localhoston megy
2008-07-24T10:40:10+02:00
2008-07-25T18:22:56+02:00
2022-11-10T10:10:42+01:00
Hofi Peti
Sziasztok!

Ezt már olvastam és azt itt írt kódot is használom, viszont sajnos nekem továbbra sem működik rendesen.
3 géppel kísérletezem. Egy WinXP-s laptop (192.168.2.150), illetve két linuxos gép, amit a laptopról vezérlek puttyal (192.168.2.110 illetve 192.168.2.112)
Localhoston mint a 3 géppel rendesen megy. Ha a linuxokról próbálom az XP-n futó szervert hivogatni a tűzfal kikapcsolása után működik az is normálisan. Viszont a két linuxos gép között sehogy sem, pedig az lenne a cél.

A kliens ezt a hibát írja ki:


java.rmi.UnmarshalException: error unmarshalling return; nested exception is: java.lang.ClassNotFoundException: Server_Stub (no security manager: RMI class loader disabled)

Ezzel mit tudok kezdni?
Mutasd a teljes hozzászólást!
Ha az interface változik, akkor ugyanúgy frissíteni kell a klienseket webservice esetén is.


Nem feltétlen. Ezen a téren rugalmasabb, mint a kopasz RMI, hiszen nincs kötelező alaki és típusos megfeleltetés a két oldal között.

Az RMI pedig annak ellenére hogy elég öreg, még mindig nagyon gyakori, és megállja a helyét.


Igen, és ebből adódóan azonnal szívás van, ha át kell nyomni VPN-en vagy ki kell engedni az internet felé (mert eszébe jut egy cégvezetőnek, hogy ő otthonról is szeretne csatlakozni, vagy ami még rosszabb, a mobiljára szeretne egy J2ME alkalmazást)...

Ha két egyszerű java alkalmazás közé kell kapcsolatot létesíteni, akkor szerintem teljesen felesleges Tomcat, vagy EJB vagy bármi. (ágyuval verébre)


Nem akarok senkit meggyőzni, de mintha itt szerver-kliens architektúra lenne. És most lehet, hogy nem scope amint fentebb írtam, de később az lehet. Egy Tomcat szinte alig jelent többlet erőforrást, mint egy RMI szervernek megírt alkalmazás, pláne ha az üzembiztonságról van szó, plusz felmerül, hogy ki indítja el az RMI szervert, ki ellenőrzi a futását és ki állítja le? Tomcat esetén ez nem kérdés.

A webservice-nek az interoperability-n kívül leginkább csak hátrányai vannak. Lassú, túl komplex, gyengén szabványos, nagy overheadje van stb.


RMI-vel összemérhető mostanában a teljesítménye. Semmi komplex nincs benne, teljesen szabványos és ezen túl egy csomó más előnye is van, például könnyen titkosítható, biztosíthatja a hitelességet, szükség esetén probléma nélkül clusterbe körhető, ami ismét nem mondható el az RMI-ról.

Az EJB ma már annyira egyszerű, hogy már szinte kötelező használni... :)
--
Sorry - this page has moved
Mutasd a teljes hozzászólást!

  • Hm... miért jó neked az, hogy egy tizenéves éves Java technológiát akarsz használni, amit jópár éve gyakorlatilag sehol nem használnak ilyen módon? :)

    Ezt valami produktív célra akarod használni a későbbiekben vagy egy 10 éves Java tutorialon rágod át magad éppen és ennél a fejezetnél tartasz?
    --
    Sorry - this page has moved
    Mutasd a teljes hozzászólást!
  • Pedig éles programban szeretnénk használni, és egy nálam tapasztaltabb személy javasolta ezt a technológiát (gondolom nem a hasára ütött). A rendszer nagy vonalakban úgy nézne ki, hogy lenne 5-6 számítógép, amik különböző eszközök adatait gyűjtenék be (1 gép 1 eszköz). Valamint lenne egy központi gép, ami a bejövő adatokat összegzi és vezérli a többi számítógépet is.
    Erre körülbelül milyen java technológiát javasolsz?

    (időközben sikerült megoldani a problémát)
    Mutasd a teljes hozzászólást!
  • Ha csak 5-6 számítógép és ezek egy subnetben vannak, akkor esetleg jó lehet az RMI is, de az RMI nagyon kötött protokoll, ha változik az interfész, akkor jó eséllyel minden kliensnél frissíteni kell, és újraindítani.

    Ilyen esetekben én WebService-t használnék, a Java 6 része, szerver oldalon Tomcat és kész. Ha később hozzá kell nyúlni, akkor kevésbé fájdalmas lehet.

    Ha még jobbat szeretnél, akkor EJB, nagy dolognak tűnhet egy pár gépes hálóhoz, de az EJB3 annyira egyszerű, hogy szinte minden apró dologhoz már célszerű használni.
    --
    Sorry - this page has moved
    Mutasd a teljes hozzászólást!
  • Ha az interface változik, akkor ugyanúgy frissíteni kell a klienseket webservice esetén is.
    Az RMI pedig annak ellenére hogy elég öreg, még mindig nagyon gyakori, és megállja a helyét.
    Ha két egyszerű java alkalmazás közé kell kapcsolatot létesíteni, akkor szerintem teljesen felesleges Tomcat, vagy EJB vagy bármi. (ágyuval verébre)
    A webservice-nek az interoperability-n kívül leginkább csak hátrányai vannak. Lassú, túl komplex, gyengén szabványos, nagy overheadje van stb.
    Mutasd a teljes hozzászólást!
  • Hát attól függ mit nevezünk egyszerű alkalmazásnak. A központi gépnek kellene adatbázist kezelni, a többi gépet vezérelni és a felhasználóval a kapcsolatot is tartani...

    Mivel bőségesen van idő megnézem az WebService-t és az EJB-t is, aztán majd meglátom...
    Mutasd a teljes hozzászólást!
  • Ha az interface változik, akkor ugyanúgy frissíteni kell a klienseket webservice esetén is.


    Nem feltétlen. Ezen a téren rugalmasabb, mint a kopasz RMI, hiszen nincs kötelező alaki és típusos megfeleltetés a két oldal között.

    Az RMI pedig annak ellenére hogy elég öreg, még mindig nagyon gyakori, és megállja a helyét.


    Igen, és ebből adódóan azonnal szívás van, ha át kell nyomni VPN-en vagy ki kell engedni az internet felé (mert eszébe jut egy cégvezetőnek, hogy ő otthonról is szeretne csatlakozni, vagy ami még rosszabb, a mobiljára szeretne egy J2ME alkalmazást)...

    Ha két egyszerű java alkalmazás közé kell kapcsolatot létesíteni, akkor szerintem teljesen felesleges Tomcat, vagy EJB vagy bármi. (ágyuval verébre)


    Nem akarok senkit meggyőzni, de mintha itt szerver-kliens architektúra lenne. És most lehet, hogy nem scope amint fentebb írtam, de később az lehet. Egy Tomcat szinte alig jelent többlet erőforrást, mint egy RMI szervernek megírt alkalmazás, pláne ha az üzembiztonságról van szó, plusz felmerül, hogy ki indítja el az RMI szervert, ki ellenőrzi a futását és ki állítja le? Tomcat esetén ez nem kérdés.

    A webservice-nek az interoperability-n kívül leginkább csak hátrányai vannak. Lassú, túl komplex, gyengén szabványos, nagy overheadje van stb.


    RMI-vel összemérhető mostanában a teljesítménye. Semmi komplex nincs benne, teljesen szabványos és ezen túl egy csomó más előnye is van, például könnyen titkosítható, biztosíthatja a hitelességet, szükség esetén probléma nélkül clusterbe körhető, ami ismét nem mondható el az RMI-ról.

    Az EJB ma már annyira egyszerű, hogy már szinte kötelező használni... :)
    --
    Sorry - this page has moved
    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