In113 kjøremodeller. 3-lags programvarearkitektur presentasjon, utveksling av data mot bruker –skjer via maskinens terminaltjeneste forretningslogikk,

Presentasjon om: "In113 kjøremodeller. 3-lags programvarearkitektur presentasjon, utveksling av data mot bruker –skjer via maskinens terminaltjeneste forretningslogikk,"— Utskrift av presentasjonen:

1 in113 kjøremodeller

2 3-lags programvarearkitektur presentasjon, utveksling av data mot bruker –skjer via maskinens terminaltjeneste forretningslogikk, databehandling –hovedprosesser (sesjonsbestyrer og andre program som bruker starter) –interaktive prosesser trenger terminaltjeneste (bakgrunnsprosesser trenger ikke) lagring av data –skjer via en lagertjeneste

3 programvare bringes inn via disk (CD, tape) eller datanett, lages eventuelt internt lagres på et lager i påvente av bruk –programfiler i et filsystem, på en partisjon/volum etter behov lastes den inn i et minne og startes

4 lasting og oppstart programvare på lokal disk –raskest oppstart (kun via lokale busser) –få mellommenn (høyest tilgjengelighet) –vareendring skjer N steder programvare på annen maskin (filtjener): –endel tregere oppstart (via lokal/fjernnett) –flere mellommenn (lavere tilgjengelighet) –vareendring skjer ett sted (filtjener)

5 terminaler maskin har flere terminaler, kjører en terminaltjener per terminal flere maskiner i et datanett med interaktive prosesser som trenger terminal –vanligvis: bruker en lokal terminal –åpent system: kan bruke ikke-lokale terminaler interaktiv prosess må uansett gå via terminalens vokter (terminaltjeneren) for å få lov til å –motta brukerens tastetrykk og peking –opprette og kontrollere vinduer på terminalen

6 terminaltjener prosess som forvalter lokal terminalressurs (tastatur, skjerm, pekeutstyr) hos maskin A klient er prosess på maskin B som via nett ønsker å bruke terminalen hos maskin A –klient gjennomgår autentisering –flere klienter, gjerne fra flere maskiner B, C,..., kan bruke samme terminal hos maskin A, ved å gå gjennom A’s terminaltjener –den bruker som sitter på maskin A vil –f.eks. blir Word en klient til terminaltjener, Word sender skjermbilder o.l. for fremvising Word mottar terminalhendelser i retur –X-Windows (siden 1985, mest brukt for UNIX)

7 terminalkobling 1:1:1 – interaktiv prosess bruker ett vindu i en terminal (f.eks. en klokke) 1:1:M – interaktiv prosess bruker flere vindu i samme terminal (f.eks. en tekstbehandler) 1:N:M – interaktiv prosess bruker flere vindu, fordelt over flere terminaler –geografisk separert (f.eks. en prosessovervåker som skal vise tilstanden til vaktsentral og andre rom) –for ressurskrevende for en terminal (f.eks. komplekst designprogram ala CAD/CAM, værsimulering etc)

8 tykke klienter program –kjører lokalt mot lokal terminaltjener (bruker lokal prosessor og lokalt minne) lagrede data –operativsystem ligger på lokal disk –programvare spres ofte til lokal disk (endres sjelden) –hjemmekataloger ligger hos filtjener (endres ofte, enklere å ta daglig backup sentralt) tykkhet ligger i at det krever kraftige lokale ressurser (mye disk, prosessor og minne), vanlig siden tidlig 90-tall når ”alt” er lokalt minimeres responstiden mellom terminal og forretningslogikk (interaktivitet)

9 tynne klienter maskiner som har akkurat nok lokale ressurser og logikk til å være terminal (kun terminaltjener) –vil etter oppstart (boot) kontakte en sesjonstjener –brukers prosesser kjørte hos sesjonstjener –eneste lokale behandling er terminalrelatert, mye mindre behandlingskraft på 80-tallet var disk kostbart, så en hadde ”diskløse arbeidsstasjoner”, f.eks. X-terminaler –disse måtte hente operativsystem fra en annen maskin (via BOOTP protokoll for ”fjernbooting”)

10 separert kjøring og terminal driftskostnader kan reduseres med tynne klienter, –forseglet kasse, forenklet innold (færre komponenter som kan feile) gir høyere MTTF i klientmaskin –stiller høyere krav til MTTF i infrastruktur sentralisert drift reduserer antall manuelle inngrep –Citrix Metaframe (1995), Microsoft Terminal Server (1998) –”Network Computer” fra Oracle, og ”NetPC” fra Microsoft (1997) responstid avhenger av lokal/fjern-nett

11 sesjon en bruker kan ha igang flere sesjoner samtidig – logge seg inn flere steder –vi er ”vant til” å ha en sesjon i gang på den Windows desktop vi ”sitter på” (f.eks. spc222) –telnet ulke gir meg ny sesjon hos ulke jeg kan nå starte interaktive prosesser hos ulke (f.eks. ping) prosessene på ulke formilder resultat via terminalbilder, de kan ikke etablere nye vindu på brukermaskin (spc222) –webmail gir ny sesjon hos webmailtjener (også ulke) alle funksjoner kjøres hos webmailtjener –Arena gir ny sesjon hos Arenatjener

12 single sign-on oppgir brukernavn og passord (eller annen legitimasjon, sertifikat, retinascan e.l.) kun en gang – Sun’s smartkort-NC nye sesjoner etableres ved at autentisering skjer i bakgrunnen (”legitimasjonsfritt”) –f.eks. innen et W2K domene, vanskeligere mellom domener fra ulike produsenter (med proprietære autentiseringsmåter, ”lukkede system”) reautentisering påkreves ofte etter en viss tid uten aktivitet

13 sesjonskontinuitet sesjonsdiskontinuitet –ved pålogging etableres ny sesjon : prosesser startes, filsystem monteres, filer/databaser åpnes –ved avlogging avsluttes sesjon: prosesser avsluttes, filer/databaser lukkes – ressursene frigis sesjonskontinuitet –sesjon (igangsatte program og åpnede filer) avsluttes ikke, men legges ”på is” – ressursene forblir opptatt terminal låses (gjenåpnes med re-autentisering) – når arbeidet gjenopptas må en bruke samme terminal (for å unngå versjonskonflikt) terminal frigis (kan brukes av andre) – når arbeidet gjenopptas kan en bruke samme eller annen terminal –sesjon avsluttes, men tilstanden huskes slik at program og filer/databaser kan startes ved innlogging

14 sesjonskontinuitet er meget vanskelig å gjennomføre –krever at mange tilstandsorienterte koblinger holdes i gang over lang tid, og gjenetableres etter brudd på andre steder i systemet de fleste system i dag tilbyr ikke- kontinuerlige sesjoner –bruker må huske hvor han var – en har flyttet kompleksiteten ut til bruker

15 ”tynn overalt” når en er ”ute i felten” eller ”hjemme” kan en likevel arbeide mot sesjonstjener ved å bruke enkle tilkoblingsprogram (sesjonsklient) –medbringes ”i lomma”, på diskett, startes fra tykke klienter –sesjonsklient har ofte innebakt autentiseringsinfo og serienummer som forenkler innlogging og automatiserer autentiseringen

16 sesjonstjener kjører (som sagt) program (Word, Internet Explorer etc.) og utveksler kun terminaltrafikk til klient data til programmet hentes fra –lokale disker, lokalisert på samme maskin som sesjonstjener kjører på –ikke-lokale disker ”frikoblet produksjon” – lager, kjøring og fremvising på forskjellige maskiner, via nett

17 Applikasjonstjenere application service provider (ASP) tjenestetilbyder –kjører tjenesteprogrammet hos sesjonstjener –data lagres hos tjenestetilbyder, gjerne hos egnet databasemaskin brukere (abonnenter) –leier tid/tilgang til tjenesten, –bruker tjenesten over nettet, har lokal fremvising, f.eks. i webleser

18 ASP (”outsourcing”) av alle eller deler av tjenestetilbudet kan være å foretrekke –organisasjonen slipper å drive tjenestene selv, –kan faktisk ”outsource” terminaldriften, f.eks. med å benytte ”tynne klienter” hjemmemarked? –istedetfor å kjøpe CD og installere lokalt vil en leie programvaren og kun betale for de deler av tjenesten en via nettet setter i gang hos sesjonstjener –se ellers: Microsoft’s.NET arkitektur (les: ”salgskonsept”)

19 alternativ ASP-modell –klient har lokal behandler, overfører (og betaler for) kun de deler av programmet som brukeren krever enkle funksjoner for massene (lav pris) avanserte funksjoner for spesialistene (høy pris) –webleser som kan kjøre Java er eksempel her: Kun de deler av Javaprogrammet som er nødvendig vil bli overført til klientmaskin Corel Draw kunne kjøres ”fra nettet” (1996) eLæringsprogrammer, nettbankprogram etc. kan kjøres fra weblesere som kan kjøre Javaprogram

20 programmene vokser nye versjoner av samme program får flere/forbedrede/fancyfiserte funksjoner –flere instruksjoner må utføres for å gi bruker samme funksjonalitet –tar mer prosessortid, krever større plass i minnet –kjørt på samme maskin (som forrige versjon) gir den nye versjon høyere responstid for samme funksjon

21 tiltak? –gå fra tykke klienter til tynne (behold klientmaskiner, bruk terminalklient) – krever kraftige sesjonstjenere, men en kan kjøre nye versjoner –beholde versjoner og gamle ikke-tykke-nok klienter, men får etterhvert kompatibilitetsproblem med omverdenen som har ”gått over” til nye format