Jeg er meget i tvivl mht. hvordan jeg bedst tackler databaseadgang til server, min plan var at bruge RMI i stedet for Sockets, ene og alene fordi jeg har sat mig lidt ind i RMI, men ikke i sockets, men er det nu også det rigtige at bruge. Jeg kan som minimum forvente 50 clienter, men det kan sagtens stige væsentligt.
Har forstillet mig noget med en DBhandler der loggede på databasen (MySql) gennem denne ville jeg så checke brugerne i tabel, så er jeg til gengæld lidt i tvivl om hvordan jeg kommer videre herfra.
Og hvordan lige mht. hvis flere clienter forespørger databasen samtidig, står de i kø og venter på svar, eller sendes der svar til flere clienter samtidig?
Eller for at spørge på en anden måde, hvordan griber jeg dette rigtigt an ?
Håber ovenstående nogenlunde dækker situationen, ellers spørg! Jeg kan sagtens vente et par dage på svar.
Hvilken type applikation vil du lave? Hvis der er tale om Client GUI -> Server ->DBServer ville jeg kaste mig ud i RMI. Ved at benytte Sockets skal du selv kode en masse ting, der allerede er med i RMI.
En socket er en indpakning af forbindelsen mellem processer og repræsenterer én proces i forbindelsen til en anden proces (evt. på en anden maskine) Kan med fordel være pakket ind i en klasse, som fx i java. Sockets kan anvendes til forbindelsesorien-teret/forbindelsesløs kommunikation og to ting karateriserer sockets: IP-adresse Portnummer (1025 - 65535)
I sockets er princippet, at man sender data i form af en byte-stream mellem server og klient. Dette betyder, at objekter skal serialiseres(Dette klarer Java i en vis grad for os). Serveren skal fortolke byte-streamen til metode-kald og input-parametre. Dvs. man skal selv håndtere protokoller på applikationsniveau.
Du kan evt. benytte en connection-pool til databasefirbindelser, så dine klienter først får tildelt en forbindelse til db og derefter forespørger. Skal flere klienter også kunne skrive samtidigt? I så fald skal samtidighedspromlemmatikken også håndteres.
RMI kan KUN anvendes java-applikationer imellem og du skal derfor sikre dig, at klienten også laves i Java.
Sockets er hurtigere end RMI (ca. 30%) idet der bruges dataplads til at pakke objekter ind osv. Vælger man så at anvende XML over sockets, udjævnes hastighedsforskellen.
Samtidighedsproblemet i forbindelse med databasen løser du lettest ved at bruge en database der kan anvende transaktioner og derved opfylder ACID-kravende. Det gør MySQL 4.*, PostgreSQL, MS SQL-Server (ikke Access) samt alle de store distributioner i Oracle's klasse.
Andre alternativer er også Java Webservices (streaming af XML) eller CORBA. Java Webservices kan udvikles vha. Apache Axis, SUN Webservice Development kit osv.
CORBA er en model til håndtering af distribuerede objekter, på en måde som er uafhængig af sproglig implementation Dette opnås ved at definere et fælles interface, i sproget IDL, til de metoder (og attributter) der er public Endvidere håndterer CORBA en stor del af netværksopgaverne. Dette gøres i ORB’en (Object Request Broker). Den virker som en objekt bus gennem hvilken et objekt kan bruge andre lokale eller distribuerede objekter. ORB’en er ansvarlig for at finde og dirigere requests til et serverobjekts implementering, og sende svaret tilbage til klienten
Jeg vil i de efterfølgende antage, at du bruger en standalone server applikation ikke komponenter der skal køre i en container (altså ikke noget J2EE). Ellers er det nemlig noget helt andet.
server appplication----database vil formentlig bruge JDBC (SQLJ er aldrig slået igennem). Hvis applikationen skal bruge databasen meget, så bør du lave en database connection pool.
For multiple clients----server appplication er som du allerede har fundet ud af de 2 mest naturlige valg: sockets og RMI. RMI er rimeligt nemt, da du får en masse funktionalitet forærende (serialisering, multithreading etc.), men til gengæld er det ikke så egnet til meget store data mængder f.eks. fil upload og download samt at RMIRegistry og porte godt kan drille lidt.
Serveren skal naturligvis være multithreaded, så flere requests kan processes i parallel. RMI sørger for det automatisk. Med sockets skal du selv kode det. Men det er dog ikke så svært.
* man kan godt bruge porte under 1024, men på seriøse operativ-systemer kræver det specielle priviligier
* en connection pool løser faktisk samtidigheds problemet, da kun en client kan have den samme connection ad gangen
* transaktioner løser ikke problemet med samtidig access stil en connection eller samtidig access til en database record men problemet med multiple SQL sætninger der afhænger af hinanden
Du kan jo også overveje, om db'en skal ligge på samme fysiske maskine som application server - det er et spørgsmål og to eller tre fysiske lag i arkitekturen.
Jeg sidder faktisk her med totalt røde ører og en ekstremt dårlig samvittighed, selv kender jeg ikke noget værre, end når folk siger de vender tilbage og så sker der bare ikke en meter.
Jeg har ikke haft tid til, at kigge nærmere på det siden den dag, jeg stillede spørgsmålet og har faktisk overvejet, om jeg bare skulle dele nogle point ud, og så lade det være det.
Tror dog jeg vælger at sætte mig ind i det, indenfor de næste par uger og så vende tilbage - det var nok for tidligt jeg stillede spørgsmålet.
Håber i har mod på at fortsætte, når jeg bliver mere klar til at gå i gang med opgaven.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
