25. august 2008 - 13:52Der er
5 kommentarer og 1 løsning
Arkitekturmodel for et klient-server system
Hej
Jeg sidder med en problemstilling omkring et klient-server system.
Udgangspunktet er et klientprogram, der kontakter en server på www og henter data fra en database. Databasen indeholder pt lige over 1.5 mill records fordelt på flere tabeller osv. Det er ikke et db-design, jeg ønsker :o)
Jeg er raget lidt uklar med designet for systemet, da jeg ikke har kompetencer til at udelukke den ene løsning fra den anden.
Hvad er normal praksis ( hvis nogen )? Er en webservice "god" nok på serversiden, skal jeg benytte EJB, er Socket forbindelse løsningen eller hvad? Jeg er selvfølgelig interesseret i et stabilt system, men er der teknologier der går på kompromis med performance for at opnå det?
Der skal være noget sikkerhed på overførslen af data og tilsvarende, når klienten ønsker at gemme ændringer på serveren - dog ikke ændring af data, disse er statiske. Dvs den største belastning på båndbredde vil være download.
På et senere tidspunkt vil caching af data gøres muligt på klient siden, lige nu er min idé at bygge de dataobjekter klienten har brug for. ( Med mindre det er soleklart, at det skal være muligt med det samme qua perormance ).
Foerste spoergsmaal er om det er store ustrukturede klumper data (BLOB's f.eks. billeder) eller mindre strukturede klumper data.
Hvis det er BLOB's, saa boer du for en intranet loesning gaa efter socket - det vil give bedst performance. Sockets passer ikke saa godt ind i en Java EE loesning, men du kan lave en inbound JCA adapter. Hvis det er en internet loesning boer du gaa efter en simpel HTTP loesning. Den performer naesten lige saa godt som socket og kan gaa igennem firewalls. I Java EE vil det vaere en servlet som skal udfoere det. P.g.a. at overheaden ved HTTP er saa lille, saa vil du i en kombineret intranet og internet loesning sagtens kunne noejes med HTTP.
Hvis det er rigtige objekter med masser af felter, saa vil du ved en internet eller en intranet loesning med ikke-Java klienter vaelge SOAP/HTTP. Mens du ved en intranet loesning med Java-only klienter vil vaelge EJB. I et kombineret intranet og internet loesning vil du nok vaelge at implementere begge loesninger, da SOAP/HTTP har et stort overhead sammenlignet med et EJB kald.
Data i sig selv er blot tekst, så min plan var at skabe nogle strukturerede dataobjekter indeholdende disse data. Jeg har givet det en del tanker om, hvorvidt systemet ville performe ok, hvis der skal hentes mange records på en gang selvom det dybest set kun er måske 9-10 kolonner fra en tabel.
Løsningen vil lige nu være 100% internet og java-only klient, da klienten vil bevæge sig rundt i landet.
Hvis stort set bare en klump text, saa plain HTTP via en servlet, ellers hvis forskellige data med relations saa SOAP/HTTP.
Database performance kan naturligvis vaere en flaskehals, men jeg tvivler. Readonly data kan caches rimeligt godt i selve databasen, og hvis det er mobile neheder, saa er baandbredde vel begraenset.
Men du skal naturligvis kigge lidt paa stoerrelsen af data der skal hentes og antal samtidige klienter naar DB HW skal dimensioneres.
Men selv beskedent HW kan nu klare en del med den form for load.
Indtil det er bevist at det ikke fungerer saa ville jeg ogsaa lade databasen selv cache fremfor at cache i app serveren - specielt hvis DB og app er paa samme fysiske box.
Simpelt. Og saa tilfoej cache i app hvis noedvendigt. Sandsynligvis indeholder dit persisterings framework allerede cache muligheder.
Korrekt, mit framework understøtter cache muligheder - vil dog undlade at bruge det hvis det ikke giver problemer at køre setup'et uden.
Jeg foretrækker at lave relationen på serveren og returnerer det færdige objekt. Jeg må lave nogle målinger på størrelsen og tiden det tager at hente. Det burde ikke være et problem at sikre transporten med SSL eller lign?
Takker for din uddybende forklaring og de gode råd :o)
Synes godt om
Ny brugerNybegynder
Din løsning...
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.
