Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

DCOM - Distributed Component Object Model Hans Harald Wennersgård Jørn Anders Svendsen.

Liknende presentasjoner


Presentasjon om: "DCOM - Distributed Component Object Model Hans Harald Wennersgård Jørn Anders Svendsen."— Utskrift av presentasjonen:

1 DCOM - Distributed Component Object Model Hans Harald Wennersgård Jørn Anders Svendsen

2 Introduksjon – DCOM bygger på COM-teknologi utviklet av Microsoft Corp., i motsetning til CORBA som er utviklet i fellesskap av en komité medført en mindre bra arkitektur og design men, pga Windows store utbredelse er den mye brukt

3 COM – Component Object Model (1) objekt/komponent er en bit kompilert kode som tilbyr en tjeneste hovedhensikten med COM er å lage komponenter som kan aktiveres dynamisk og kommunisere med hverandre app./komponenter kommuniserer gjennom ”interfaces” ved at klient- komponenten har interface-pekere

4 COM – Component Object Model (2) angir en binærstandard –komponenter kan implementeres i en rekke ulike språk –klienten som bruker komponentene kan igjen være skrevet i et helt annet språk –krever at språket støtter kall via pekere (C, C++, Ada, Smalltalk) interfacene er tabeller med pekere til implementasjonen av metodene.

5 Virtual function tables (VTBL) binærstandarden definerer hvordan utlegget av VTBL skal være i minnet og hvordan kallene gjøres

6 Interfaces som sagt: interfacene angir en komponents funksjonalitet interfacene defineres i IDL (Interface Description Language) interfacene endrer seg aldri interfacene er en ”kontrakt” ny funksjonalitet blir lagt til ved legge til nye interfacer [ object, //Use the GUID for the ILookup interface. uuid(c4910d71-ba7d-11cd-94e8-08001701a8a3), pointer_default(unique) ] interface ILookup : IUnknown { import "unknwn.idl“ HRESULT LookupByName( [in] LPTSTR lpName, [out, string] WCHAR **lplpNumber); HRESULT LookupByNumber( [in] LPTSTR lpNumber, [out, string] WCHAR **lplpName); } IID alle komponenter arver fra IUnknown

7 Globally Unique Identifiers (GUIDs) identifiserer alle interfacene (IID) og alle COM-komponentene (CLSID) 128 bit integer genereres ut i fra: –stort random-nummer –lokaltid –nettverksadressen muligheten for at det finnes to like GUIDs tilnærmet lik 0. DEFINE_GUID(CLSID_PHONEBOOK, 0xc4910d70, 0xba7d, 0x11cd, 0x94, 0xe8,\ 0x08, 0x00, 0x17, 0x01, 0xa8, 0xa3); DEFINE_GUID(IID_ILOOKUP, 0xc4910d71, 0xba7d, 0x11cd, 0x94, 0xe8,\ 0x08, 0x00, 0x17, 0x01, 0xa8, 0xa3);

8 Microsoft IDL compiler ut i fra IDLen genereres: –header-filer : brukes av applikasjoner som bruker interfacen –kildekode til proxy- og stubobjekt : håndterer ”remote procedure calls” –type library (*.tlb) : informasjon om typer (aliases, enumerations, structures, or unions) og objekter (module, interface o.l)

9 IUnknown implementeres av alle COM-komponentene interface IUnknown { virtual HRESULT QueryInterface(IID& iid, void** ppvObj) = 0; virtual ULONG AddRef() = 0; virtual ULONG Release() = 0; } QueryInterface : lar klienten dynamisk finne ut om en interface er støttet av COM- komponenten AddRef og Release : teller antall referanser til komponenten. Når antallet referanser er 0 kan komponenten frigjøres fra minnet.

10 La oss se på et eksempel LPLOOKUP *pLookup; TCHAR szNumber[64]; HRESULT hRes; hRes = pPhoneBook->QueryInterface( IID_ILOOKUP, &pLookup); if( SUCCEEDED( hRes ) ) { pLookup->LookupByName("Daffy Duck", &szNumber); pLookup->Release(); } else { // Failed to acquire Ilookup interface pointer. } Fått tak i denne med kall til CreateInstance(CLSID_PHONEBOOK) Hei! Støtter du ILookup interfacet? Du støtter interfacet ja! Flott, fyll inn pekerverdien her er du snill. Done! Du kan ”unload’e” deg fra minnet nå for min del. Interface Identifier

11 Komponentaktivering sørge for at komponenten ”er lagd” og finnes i en prosess hvor den kan motta metodekall Eksempel (Windows): SCM Service Control Manager (Local or Remote) 1. CreateInstance(CLSID_TEST) 3. Path til implementasjonen 2. Lookup CLSID_TEST Windows Registry 5. Peker til IUnknown Server Component 4. Starter opp serveren komponeten hører til 3 typer servere: In-process (DLL, OCX) Local (EXE) Remote (EXE) Client app

12 3 type servere Client Process Client Application In-Process Server In-Process Object Local Object Proxy COM Remote Machine Remote Server Process Stub COM RPC Local Server Process Stub COM RPC Remote Object Proxy Local Server Local Object Remote Object Remote Server

13 Kommunikasjon (1) Opprinnelig var kommunikasjonen i DCOM synkron (dvs klienten blokkert inntil svar) Utvidet med callback interfaces (connectable objects) Connectable object Client Sink Incoming intf. Outgoing intf. I COM+ ble det mulig å avbryte synkron- kommunikasjon (cancel object) Asynkron: ved å angi async_iid() i IDL- fila vil det for hver metode i interfacen bli generert to metoder

14 Kommunikasjon (2) Eksempel (IDL-fil): HRESULT GetStudent([in] UINT uStudentID, [out] IStudent** ppStudent); async_iid(…) HRESULT Begin_GetStudent([in] UINT uStudentID); HRESULT Finish_GetStudent([out] IStudent** ppStudent); Kall til Begin_ returnerer øyeblikkelig Svar hentes ut ved kall til Finish_ (bufres inntil det hentes ut) Hvis Finish_ kalles før serverkomponenten er ferdig vil klienten blokkeres inntil svaret kommer (kan spørre ISynchronize om svaret har kommet) Krever at begge (klient og server) er ”oppe” (transient communication)

15 Events (1) publish/subscribe system avsender ikke direkte tilknyttet mottaker(ne) som var tilfelle med connectable objects en event class imellom avsender og mottaker håndterer kommunikasjonen mottakere implementerer event- interfacet og mottar events gjennom dette (distribuert fra event-klassen)

16 Events (2) event-klassen gjør det mulig for avsenderen og mottakerne og ha ulik ”levetid” mottakerne kan velge å abonnere på kun utvalgte metoder (filtrering) events kan lagres i event-klassen Publisher Event Class IMyEvents MyEvents Subscriber MyEvents Subscriber MyEvents Subscriber IMyEvents Subscribers Subscriptions

17 Messaging (1) persistent asynkron kommunikasjon vha Queued Components (QC) begrenset til interfaces med metoder som kun har inn- parametere (kun en vei) når en klient binder seg til en klient som støtter QC får den tilbake en interface-peker med metodene den kan kalle asynkront

18 Messaging (2) kallene lagres lokalt hos klienten (sendes ved kall til Release) det gis ingen garanti for at metodene kalles i samme rekkefølge, men det finnes støtte for transaksjonskøer passer for situasjoner som ikke krever øyeblikkelig respons garantert levering ligner på email, men er mellom applikasjoner

19 Objekthåndtering alt rundt håndtering av objekter på serveren er i utgangspunktet overlatt til utvikleren utvikleren er selv ansvarlig for at serveren har nok tilgjengelig ressurser ved opprettelse av objekter men, DCOM tilbyr fasiliteter for objekthåndtering, JIT Activation.

20 Akkurat-Tidsnok-Aktivering serveren kontrollerer aktivering og destruering av objekter ved bruk av ATA kan serveren destruere et objekt når den vil, for eksempel når minnet begynner å gå fullt. når en klient da prøver å aksessere et objekt som er destruert, blir det bare opprettet et nytt objekt. fungerer bra med tilstandsløse objekter. hvis objektet ikke er tilstandsløst, må tilstanden skrives til disk før objektet destrueres og hentes inn igjen når nytt objekt opprettes.

21 Navngivning DCOM tilbyr bare lavnivå navngivning av objekter. interface-pekere er brukt for å referere til objekter DCOM tilbyr persistente objektreferanser, monikers, som kan deles mellom flere prosesser. DCOM kan benytte seg av Windows Active Directory som høynivå navngivningstjeneste.

22 Monikers en persistent objektreferanse som kan lagres på disk. hver moniker tilbyr en interface med metoder for å lagre innholdet av den på disk. flere typer monikers: –file moniker: refererer til et objekt som skal lages ut fra en fil i det lokale filsystemet. inneholder stien til filen som objektet skal lages fra og CLSID til klassen som objektet skal lages fra. –URL moniker: referanse til et objekt som skal konstruert fra en url. –Class moniker: referanse til et klasseobjekt brukt sammen med file eller url moniker. overskriver standard klasseid oppslagsmekanisme. –composite moniker: referanse til en samling med monikers –Item moniker: referanse til en moniker i en samling –Pointer moniker: referanse til et objekt i en fjernprosess.

23 Koble moniker til et objekt: (file moniker) klienten kaller BindToObject som er tilbudt gjennom interfacen iMoniker Moniker henter opp tilhørende CLSID og ber SCM å opprette objekt av klassen SCM oppretter objekt av klassen peker til objektets interface returneres til moniker-objektet moniker ber objektet laste tidligere lagret tilstand. objektet henter tilstand fra fil moniker returnerer interfacepekeren til klienten og legger objektet inn i Running Object Table (ROT)

24 Deling av objekter når en klient binder en moniker til et objektet, vil moniker først slå opp i Running Object Table hvis objektet finnes der (det er allerede opprettet), vil monikeren koble til den instansen av objektet. på den måten deles objekter mellom ulike prosesser på samme maskin.

25 Active Directory DCOM applikasjoner kan benytte seg av Windows Active Directory som katalogtjeneste Active Directory tillater mer generelle spørringer enn en DCOMs egen lavnivå navngivningstjeneste. (må ikke ha navnet eksakt)

26 Feiltoleranse DCOM tilbyr støtte for feiltoleranse på protokollnivå. En ping-mekanisme brukes for å detektere nettverk og klient-hardware-feil. Hvis nettverket kommer opp igjen innen en gitt timeout, gjenoppretter DCOM forbindelsen automatisk. feiltoleranse også støttet gjennom bruk av automatic transaction. Dette går ut på at utvikler kan gruppere flere metodekall, på ett eller flere objekter, til en transaksjon.

27 Sikkerhet DCOM gjør bruk av sikkerhetsrammeverket i Windows. To forskjellige metoder som blir brukt for sikkerhet i DCOM –Declarative security –Programmatic security

28 Declarative security for hver komponent defineres det i registeret hva som kreves mht: –aktivisering –aksesskontroll –autentisering. registeret vil da spesifisere hvilke brukere/brukergrupper som har rettigheter til å opprette objekt av komponenten etc. ulike nivåer av autentisering

29 Eksempel

30 Programmatic security ved siden av den deklarative sikkerheten, kan man la utviklerne av applikasjonene benytte seg av ulike sikkerhetstjenster i DCOM alle objekter innenfor en prosess har i utgangspunkt samme sikkerhetsinnstillinger utvikleren kan sette egne sikkerhetsinnstillinger på objekter ved å eksplisitt angi dette.

31 Autentisering og Autoriseringstjenester autentiseringstjenester i DCOM Autoriseringstjenester i DCOM

32 Eksempel


Laste ned ppt "DCOM - Distributed Component Object Model Hans Harald Wennersgård Jørn Anders Svendsen."

Liknende presentasjoner


Annonser fra Google