Laste ned presentasjonen
Presentasjon lastes. Vennligst vent
PublisertGreta Engen Endret for 9 år siden
1
Arkitektur for distribuerte systemer In 140 Sommerville kap 11
2
Mål Forstå fordeler og ulemper med distribuerte arkitekturer Forstå forskjellige tilnærminger til utvikling av klient tjener arkitektur Forstå forskjellen mellom klient-tjener og distribuert (objekt)arkitektur Forstå ideen med objekt request broker og prinsippene for CORBA-standarden
3
Introduksjon Nesten alle større databaserte systemer er distribuerte Et distribuert system fordeler databehandlingen på flere maskiner Før sentraliserte stormaskiner med mange dumme terminaler Nå tre hovedtyper –Personlige systemer som ikke er distribuerte –Innebygde systemer som kjører på en prosessor eller en integrert gruppe av systemer –Distribuerte systemer som kjører på løst koblede prosessorer over nettverk.
4
Karakteristiske egenskaper ved distribuerte systemer. (Coulouris1994) Ressursdeling Åpenhet Parallelle prosesser Skalerbarhet Feiltoleranse Transparens
5
Ulemper ved distribuerte systemer Kompleksitet –Vanskelig å forstå –Vanskelig å teste Sikkerhet –Mange maskiner –Avlytting Drifting Uforutsigbarhet
6
Emner i distribuert systemutforming Ressursidentifikasjon –Gjør ressursene tilgjengelige –Navnesystem eks:URL Kommunikasjon –TCP/IP er pålitelig og effektiv –Alternativer kan være aktuelt Tjenestekvalitet –Ytelse, tilgjengelighet, pålitelighet Programvarearkitektur –Fordeling av funksjonalitet på komponenter og komponenter på prosessorer
7
Klassifisering av distribuerte systemer To hovedtyper arkitektur –Klient-tjener arkitektur Tjenester leveres av servere og brukes av klienter –Distribuert objektarkitektur Systemet er samarbeidende objekter der plassering er irrelevant Komponentene kan lages med forskjellig programmeringsspråk og kjøres på forskjellig prosessortype
8
Middleware Kan være –Programvare for kommunikasjon med databaser –Transaksjonsmanagere –Datakonvertere –Kommunikasjonskontrollere
9
Multiprosessorarkitekturer Systemet består av prosesser som kan kjøres på forskjellige prosessorer Vanlig i store sanntidssystemer Kan også kjøres på en prosessor (styrt av scheduler) Flere prosessorer gir større ytelse og motstandsdyktighet Fast prosessortildeling eller despatcher styrt
10
Multiprosessor-trafikkontrollsystem
11
Klient-tjenerarkitektur Tjenere leverer tjenester til klienter Klientene må vite om tjenere, men ikke nødvendigvis om hverandre Klient og tjenerprosesser vs. prosessorer
12
Et klient-tjener system
13
Datamaskiner i et K/T-nettverk
15
Lagdelt programarkitektur Vanlig utformingsarkitektur Presentasjonslag Behandlingslag Datalagringslag Disse lagene kan fordeles mellom klient og tjener. Fordelingen kan gjøres forskjellig
16
Applikasjonslag
17
Tykke og tynne klienter Tynne klienter –Har bare presentasjonslag –Behandling og lagring skjer på server Tykke klienter –Har både presentasjon og behandling –Lagring skjer på server Tolags arkitektur (Two tier) er den enkleste K/T-arkitektur
18
Tynne og tykke klienter
19
Tynne klienter Enklest når gamle sentraliserte systemer skal omarbeides til K/T Systemer som bygger på nettleser er tynnklientsystemer Stor arbeidsbelastning på server og nettverk, mens det er ledig kapasitet hos klienten
20
Tykke klienter Bruker kapasitetsreserven i klienten Serveren er da en transaksjonsserver, som ordner alle databasetransaksjoner Også her mulighet for stor nettverkstrafikk Minibanker er eksempel på tykk klient Mer komplisert systemadministrasjon –Funksjonalitet spredt på mange maskiner –Komplisert oppgradering
21
Eller en mellomting.. Java-appletter Kompatibilitetsproblemer Trelags (Three-tier) –Presentasjon, behandling og datalagring på hver sin maskin –Behandling og datalagring kan starte som separate prosesser på samme maskin og senere skilles for å skalere systemet
22
Trelags K/T arkitektur
23
Nettbank Trelagsløsning –Tynn klient – nettleser –Webserver gir tilgang til tjenester –Databaseserver har ansvar for lagring SQL Lavnivåprotokoller Mangelagsløsning –Forskjellige databaser –Integrasjonsserver –Skalerbare løsninger
24
Nettbanksystem
25
Bruk av klient/tjener-arkitekturer
26
Distribuerte objektarkitekturer Problemer med K/T –Lite fleksibel –Plassering av tjenester må bestemmer på forhånd –Lastfordeling og skalering må planlegges Løsning: –Fjern skillet mellom K og T –Bygg systemet med distribuerte objekter –Objektene gir tilgang til tjenester for andre objekter – intet skille mellom K og T
27
Distribuerte objektarkitekturer Objektene kan spres på forskjellige datamaskiner Kommunikasjon skjer gjennom middleware Programvarebuss (Software Bus) –Kommunikasjonsmuligheter –Tilkopling og frakopling –Sømløs sammenkobling Sammenkoblingsprogramvaren kalles Object Request Broker
28
Fordeler med distribuert objektarkitektur Avgjørelse om plassering av tjenester kan utsettes Svært åpen systemarkitektur Fleksibelt og skalerbart Dynamisk omkonfigurering av systemet – behovstyrt objektmigrering over nett
29
To anvendelsesområder for distribuert objektarkitektur i utforming Logisk modell for systemstrukturering –Store tjenesteobjekter leverer alt innenfor et område: Lagerstyring, kundekommunikasjon, vareinnkjøp Fleksibel tilnærming til K/T –Både K og T utformes som distribuerte objekter på software-buss –Lett å omkonfigurere
30
Et data mining system
31
Eksempel - Datamining Logisk sett: Ikke tjenesteyting Nye databaser kan legges til uten å avbryte systemet Nye sammenhenger kan undersøkes ved å legge til nye integratorer.
32
Ulemper ved distribuert objektarkitektur Mer komplisert å utforme enn K/T –K/T er mer intuitivt – likner mellommenneskelige forhold Lite erfaring med større forretningsobjekter
33
CORBA Middleware skal sikre sømløs kommunikasjon mellom objekter skrevet i ulike språk, på ulike plattformer To hovedstandarder CORBA(Common Object Request Broker Architecture) definert av OMG. –Mange implementeringer av standarden –UNIX og Microsoft OS DCOM(Distributed Component Object Model). Definert og implementert av Microsoft –Mindre generell enn CORBA –Bare på microsoftsystemer
34
CORBA Sannsynlig konvergens mellom CORBA, DCOM, Java-RMI til CORBA OMG(Object Management Group) består av over 500 selskaper –CORBA –UML –Common Business Objects
35
Komponenter i en distribuert applikasjon Applikasjonsobjekter skrevet for denne applikasjonen Standardobjekter for anvendelses-områder (under arbeid) Fundamentale CORBA-tjenester f.eks katalogtjeneste, sikkerhetstjeneste Horisontale CORBA støttetjenester for brukergrensesnitt, systemadministrasjon osv. Horisontal står for at tjenestene er felles for mange applikasjoner
36
Elementer i CORBA-standarden Objektmodell for applikasjonsobjekter. Innkapslet tilstand og språknøytralt grensesnitt beskrevet i IDL ORB Object Request Broker håndterer forespørsler etter objekttjenester –Finne objektet –Klargjøre objektet –Sende tjenesteforespørslene –Returnere resultatet Felles objekttjenester –katalogtjenester –transaksjonstjenester –Persistenstjenester Felles komponenter som det kan bli bruk for –Vertikale eller horisontale
37
CORBA applikasjonsstruktur
38
CORBA Objektet er en innkapsling av attributter og tjenester CORBA objekter har separat grensesnitt- definisjon av public attributter og operasjoner Språkuavhengig grensedefinisjonsspråk IDL objektet må ha en IDL stub for hvert objekt man ønsker tilgang til objektet må ha et IDL skeleton for grensesnitt man vil vise Unik IOR Interoperable Object Reference
39
ORB – Object Request Broker IDL isolerer objektene fra ORB. Med ORB er objektenes plassering uinteressant En ORB per prosessor ORB til ORB kommunikasjon –Tilgang til IDL-definisjoner –GIOP (Generic Inter Orb Protocol) –Kan fungere over TCP/IP
40
ORB-basert objektkommunikasjon
41
Inter-ORB kommunikasjon
42
CORBA-tjenester Siden åttitallet, stadig i utvikling Navnetjenester (Hvite sider) Trading services (Gule sider). med spesifikasjoner. Meldingstjenester og abonnement på meldinger Transaksjonstjenester
Liknende presentasjoner
© 2024 SlidePlayer.no Inc.
All rights reserved.