Socket og RMI

RMI er nemt da du får et nemt RPC proxy interface og multithreadingen
også håndteres for dig.

Til gengæld er der også nogle restriktioner p.g.a. modellen.

Hvis du f.eks. skal lave en server i RPC stil f.eks. 15 metoder med 0-5 argumenter
som er simple data typer, så er RMI en rigtig god løsnning fordi RMI håndterer
en masser arbejde for dig.

Hvis du f.eks. skal lave en fil upload så er RMI ikke en speciel god løsning
fordi det er mere streamet af natur. Du kan enten læse hele filen ind i memory
og sende i en stor klump eller du kan lave en opslitning i chunks som ikke
nødvendig med sockets.

jeg har skrevet lidt om RMI (mest kod emen også lidt om godt og skidt) her:

http://www.eksperten.dk/artikler/25
http://www.eksperten.dk/artikler/225

hvis dit administrative system er

client app---(LAN)---server

så er RMI absolut en relevant mulighed

hej Arne ...måtte lige læse dine artikler først...

Kort sagt er RMI godt til client/server løsninger på LAN, da firewalls er problematiske.
Samt, når man har mange funktioner med mange argumenter, som ikke fylder meget.

Vil du da anbefale en RMI til f.eks en banks håntering af konti, og en socket løsning til bankens forbindelse med Dankortautomater (pga. firewalls) ?

Og på trods af at vi snakker om en client app---(LAN)---server.....vil det da være passende på trods, at bruge socket i forbindelse med udveksling af tunge txt filer blandt personale.

måske - men hverken socket eller RMI har indbygget clustering/loadbalancing/failover
som godt kunne være et krav fra en bank

hvis man skal ind gennem en firewall er web service (SOAP/HTTP) tit en god løsning

----

jeg synes ihvertfald at RMI er uegnet til store filer - socket eller HTTP eller FTP
er bedre

Og kan man egentlig sige at forskellen mellem RMI og socket ligger i hvordan data pakkes og flyttes over nettet, da stub og skeleton med rimelighed i funktion kan sammenlignes med socket plus nogle hånteringer???

RMI bruger en socket

det RMI gør at den tager et antal argumenter serialiserer dem sender dem over socket og
i den anden ende bliver de deserialiseret og bruges i kaldet af server koden

så RMi er noget client utility kode + en socket + noget server utility kode

der er iøvrigt en interesant artikel her:

http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnwebsrv/html/asmxremotesperf.asp

det er ganske vist omkring .NET men problem stillingerne er meget de samme

.NET ES (COM+) = Java EJB
ASP.NET Web Service (ASMX) = Java Web Service
.NET Remoting binary formatter = Java RMI

Ok ..og så er det du siger at, der implicit i RMI ligger socket håndtering....har nemlig ikke kunne finde (ServerSocket servSock = new ServerSocker(port)) i nogle af mine RMI kode eksempler...

Du får pointene...men har du tid til et tillægsspørsmål (50 point)...om concurrency???

Socket ligger i stub og ServerSocket ligger i skeleton

enten i de klasser som bliver genereret eller i de klasser som de arver fra

et svar

og spørg endelig om concurrency

Hvis man har nogle kontier med hver sit eget objekt, hvordan sikres  concurrency når f.eks. én bruger flytter penge fra en konto til en anden,  samtidig med at ægtefællen, der deler konti med brugeren, også trækker på kontoen??

Gøres det automatisk i RMI eller skal men definere tråde???

RMI serveren starter selv tråde

du kan løse det på flere måder:

1)  du kan bruge synchronized i din server kode således at en transaktion er
    færdig før den næste starter

    nemt men ikke en high performance løsning

2)  hvis konti ligger i en database så kan du bruge databasens
    transaktions system

    bedre performance men kræver så at alt det relevante ligger på samme
    database server

3)  bruge en transaction manager til at styre flere database servere og
    andre systemer som understøtter 2 phase commit (f.eks. messages queues)

    sådan noget er f.eks. indbygget i J2EE EJB container

super....Tak for din hjælp...der var utroligt nok et par pærer, der begyndte at brænde der.