Modelul obiectelor componente

De la Wikipedia, enciclopedia liberă.
Salt la navigare Salt la căutare

În calculul Component Object Model (cunoscut sub numele de „ acronim COM, în engleză pentru modelul obiectelor pentru componente) este o„ interfață pentru software componentă introdusă de Microsoft în 1993 . COM permite comunicarea între procese și crearea obiectelor dinamice cu orice limbaj de programare care acceptă această tehnologie. [1] Termenul COM este adesea folosit în lumea dezvoltării de software cu semnificații multiple: OLE , OLE Automation , ActiveX , COM + și DCOM . Deși introducerea COM datează din 1993, Microsoft a început să folosească acest nume doar cu accent în 1997 .

Deși a fost portat și pe alte platforme, COM este utilizat în principal cu Microsoft Windows . La înlocuirea progresivă parțială a cel COM de către Microsoft .NET cadru este de așteptat.

Istorie

Anthony Williams, una dintre principalele minți implicate în crearea arhitecturii COM, a distribuit câteva documente interne Microsoft care se ocupă de conceptul de componente software; "Arhitectura obiectului: tratarea necunoscutului - sau - Tip siguranță într-o clasă extensibilă dinamic" ( "Arhitectura unui obiect: pentru a trata necunoscutul - sau - Tip siguranță într-o clasă dinamică extensibilă") în 1988 și "Pe moștenire: ce înseamnă și cum să o folosești "(" Despre moștenire: ce înseamnă și cum să o folosești ") în 1990 . Acestea au pus bazele pentru multe, dacă nu pentru toate, ideile din spatele fundamentelor COM.

Întrucât multe dintre aceste idei s-au născut primul cadru pentru obiecte Microsoft, OLE ( acronimul „ Engleză obiect care leagă și încorporează, înseamnă conexiune și încorporare de obiecte). OLE a fost construit din DDE și proiectat cu accent pe documentele compozite ; a fost introdus pentru prima dată cu Word pentru Windows și Excel în 1991 și ulterior a fost inclus în Windows, începând cu versiunea 3.1 în 1992 . Un exemplu de document compus ar putea fi o foaie Excel într-un document Word; când foaia de calcul este editată, modificările apar automat în documentul Word.

În 1991, Microsoft a introdus tehnologia VBX (acronim pentru extensia Visual Basic, Extensia Visual Basic ) cu Visual Basic 1.0.

În 1993 Microsoft a lansat OLE 2, având COM ca model de obiect de bază. În timp ce OLE 1 era axat pe documente compuse, COM și OLE 2 aveau o adresă mai generică. În 1994 au fost introduse comenzile OLE (OCX OLE Control eXtension , adică OLE Control Extension), cum ar fi succesorii naturali ai controalelor VBX; în același timp, Microsoft a anunțat că OLE 2 va fi numit pur și simplu „ OLE ” și că acesta nu va mai fi un acronim, ci un nume real prin care compania se va referi la tehnologiile sale orientate obiect.

Ulterior, la începutul anului 1996 , Microsoft a schimbat numele unor părți ale OLE legate de Internet în ActiveX , începând astfel procesul care l-a condus la redenumirea tuturor tehnologiilor OLE la ActiveX de-a lungul anilor, cu singura excepție a tehnologiei documentelor. în Microsoft Office . Mai târziu în acel an, Microsoft a distribuit DCOM ( acronimul Distributed Component Object Model , în engleză pentru Model for Distributed Component Object) ca răspuns la CORBA .

Structura și funcționarea COM

Scopul Component Object Model este de a permite crearea de componente software binare: deși a fost creat având în vedere limbajul C ++ , COM este neutru în ceea ce privește limbajul de programare, adică puteți utiliza orice limbaj de programare pentru a utiliza COM componente până la runtime. Această neutralitate se realizează prin specificarea formatelor de date și apeluri funcționale cu limbajul IDL complet independent. Prin urmare, din punct de vedere conceptual, este un pas mai departe decât bibliotecile de legături dinamice ( DLL ). Fiecare obiect COM trebuie să fie unic în cadrul sistemului și este utilizat prin interfețe software unice la nivel global. Pentru a asigura unicitatea, programatorul care creează un nou obiect COM creează un GUID pentru acesta (un număr de identificare generat aleatoriu pe 128 de biți care este, aproape sigur, diferit de orice alt GUID din sistem) și un GUID pentru fiecare dintre interfețele care instrumentul obiectului; aceste GUID-uri se numesc CLSID-uri (ID-uri de clasă) dacă se referă la un obiect COM și IID (ID-uri de interfață) dacă se referă la o interfață. Pentru ca un obiect COM să poată fi utilizat, acesta trebuie înregistrat în Windows în registru , adică se creează o intrare în registru care mapează CLSID-ul componentei la fișierul disc care îl implementează fizic și la orice informații de configurare. Când un program solicită o anumită componentă COM, se referă la CLSID corespunzător: Windows se va ocupa de găsirea fișierului pe disc (DLL sau EXE ) și de încărcarea codului necesar. Odată ce acest lucru este făcut, programul va cere componentei nou create să acceseze una dintre interfețele sale, utilizând IID-ul celei de care are nevoie.

Interfețele

O interfață COM este o colecție de funcții: adică este o clasă virtuală pură , iar în programarea orientată obiect este de obicei modelată astfel. Toate componentele COM trebuie să implementeze cel puțin interfața standard IUnknown . De fapt, toate interfețele COM sunt derivate din IUnknown . Se compune din trei metode : AddRef() și Release() , care implementează numărul de referințe (numărarea de referință) și controlează interfețele ciclului de viață; și QueryInterface() , care prin specificarea unui IID permite apelantului să obțină referințe la diferitele interfețe furnizate de componentă.

În mod material, o interfață constă dintr-un pointer către o tabelă de funcții virtuale care conține o listă de indicatori către funcțiile care implementează metodele declarate în interfață, în aceeași ordine în care sunt declarate. Această tehnică de trecere a listelor de indicatori de funcții este o evoluție directă a celei utilizate în OLE 1.0 pentru a comunica cu bibliotecile sale de sistem.

COM specifică multe alte interfețe standard utilizate pentru comunicarea între componente. De exemplu, una dintre aceste interfețe este IStream , care este furnizată de componente care au semantică de flux de date (de exemplu, componenta FileStream utilizată pentru citirea și scrierea fișierelor). Acesta oferă metodele de Read și Write pentru efectuarea citirilor și scrierilor de fluxuri. O altă interfață standard este IOleObject , furnizată de componente care intenționează să fie atașate sau încapsulate într-un container. IOleObject conține metode care permit apelantilor să determine dreptunghiul de IOleObject al componentei, să determine dacă componenta acceptă operațiuni precum Deschidere , Salvare etc.

După cum sa menționat deja, COM a fost dezvoltat având în vedere C ++, deci folosește pe scară largă indicii. Acest lucru a făcut imposibilă utilizarea obiectelor COM cu limbaje care nu le au, cum ar fi Visual Basic , Java și toate limbajele de scriptare; OLE Automation , printre altele, a remediat această situație. Interfețele pointer au fost numite interfețe personalizate și flancate de noi interfețe analoage, dar fără pointeri, bazate pe tablouri și colecții de obiecte, numite interfețe de automatizare ; în versiunea de automatizare, interfața IUnknown este înlocuită de IDispatch . Aceeași componentă poate implementa aceleași interfețe în ambele versiuni; cu toate acestea, versiunea personalizată este obligatorie, în timp ce automatizarea este opțională.

Numărarea referințelor

Numărarea referințelor este utilizată de componentele COM pentru a ști când pot termina și descărca din RAM. Un program client care folosește componenta nu poate continua eliminarea ei când a terminat de utilizat, deoarece ar putea fi încă utilizat de alte programe client (la urma urmei în mediul COM există posibilitatea ca un client, odată ce interacțiunea cu un componentă, treceți indicatorul de interfață al aceleiași componente către alt client). Prin urmare, eliminarea unei componente este gestionată de ea însăși prin numărarea referințelor ; această tehnică prevede că obiectul COM (adică componenta), atunci când trece pointerul de la una dintre interfețele sale către un program client (care apare în urma cererii clientului de a putea utiliza acea interfață particulară), mărește „numărul de referințe” ". Când clientul termină de a folosi obiectul COM, acesta invocă metoda IUnknown :: Release () care scade "numărul de referință" cu 1. Când un client primește indicatorul către o interfață de la un alt client, acesta invocă metoda IUnknown :: AddRef () pe obiectul COM, care crește același "număr de referință" cu 1. Obiectul COM se va "autodistruge" atunci când "numărul de referință" este egal cu 0.

Moștenire, izolare și agregare

Standardul oferă un singur mecanism de moștenire care permite unei componente să extindă funcțiile alteia: fiecare interfață poate moșteni metodele unei (și singure) interfețe preexistente, dar nu modifică sau înlocuiește metodele moștenite din interfața „tată” . Mai general, este o practică destul de obișnuită ca obiectele COM cu o anumită complexitate să utilizeze alte obiecte COM din interiorul lor; vorbim despre conținerea unui obiect COM dacă primul folosește interfețele sale fără a le face disponibile în afara acestuia și de agregare dacă o face.

RegFree COM

Windows XP a introdus un nou mod de înregistrare locală a componentelor COM, denumit pe scurt înregistrare COM sau RegFree COM pe scurt. Cu această tehnică, aplicațiile nu mai trebuie să înregistreze metadatele de activare și CLSID-urile în registrul Windows, ci le pot specifica în manifestul lor; acesta poate fi un fișier XML care se află în directorul aplicației sau poate fi conținut în antetul fișierului executabil, ca o secțiune în format binar. Când Windows încarcă aplicația și face referire la obiectele COM, fabrica de clase (entitatea care creează fizic obiectele COM) va consulta manifestul aplicației pentru a căuta GUID-urile specificate și metadatele asociate și pentru a le încărca pe cele furnizate împreună cu aplicația; numai dacă manifestul nu conține GUID-urile necesare, va consulta registrul Windows și (dacă este instalat vreunul) va crea obiecte COM de sistem echivalente. Limita acestei tehnologii este că nu poate fi utilizată cu componentele COM care trebuie să fie vizibile în întregul sistem, deci nu poate fi utilizată pentru serverele COM OutOfProcess sau pentru a implementa părți ale sistemului de operare ( MDAC , MSXML , DirectX sau Internet Explorer ).

Tehnologii conexe

COM a fost principala platformă de dezvoltare software pentru Windows și, ca atare, a influențat dezvoltarea mai multor tehnologii de sprijin.

COM +

Cu Windows 2000 , a fost introdus un număr semnificativ de extensii COM numite COM + . În același timp, Microsoft a scos în evidență DCOM ca entitate separată.

DCOM

Pictogramă lupă mgx2.svg Același subiect în detaliu: Modelul obiectelor componente distribuite .

.NET

Pictogramă lupă mgx2.svg Același subiect în detaliu: Microsoft .NET .

Platforma COM a fost depășită în mare măsură de Microsoft .NET , iar marketingul Microsoft se referă la .NET; într-un fel, COM este acum chiar depreciată în favoarea .NET. În ciuda acestui fapt, COM rămâne o tehnologie importantă datorită bazei sale masive de software - de exemplu, DirectX SDK se bazează pe COM; în plus, o componentă COM este teoretic întotdeauna mai performantă decât o componentă corespunzătoare gestionată .NET [ fără sursă ] . În momentul redactării acestui articol, Microsoft nu a anunțat planuri de retragere sau întrerupere a asistenței COM.

Unele servicii pe care le oferă COM +, cum ar fi tranzacțiile și cozile de componente , sunt încă importante pentru aplicațiile de întreprindere .NET.

Există o limită pentru compatibilitatea cu versiunile anterioare . Un obiect COM poate fi utilizat în .NET prin implementarea unui runtime callable wrapper (RCW).

Securitatea internetului

Deoarece componentele COM și ActiveX rulează ca cod nativ pe computerul utilizatorului, există puține restricții cu privire la ceea ce poate face codul lor. Multe dintre aceste probleme au fost rezolvate de deprecierea relativă a COM în platformele dezvoltate de atunci, cum ar fi platforma Java și mai târziu și platforma .NET .

Ideea Microsoft de a încapsula conținut activ pe pagini web sub formă de componente COM / ActiveX (mai degrabă decât, de exemplu, applet-uri Java ) a creat o serie de probleme în browserul Internet Explorer , ceea ce a dus la o explozie de infecții din viruși de computer , troieni și spyware . Aceste atacuri malware datorează în principal activării și propagării lor către alte computere. Microsoft a recunoscut problema ActiveX încă din 1996 , când Charles Fitzgerald , directorul echipei Java a Microsoft, a spus „Dacă doriți securitate pe internet , deconectați-vă computerul. (...) Nu am susținut niciodată că ActiveX este intrinsec sigur”.

Critici

Deoarece COM este destul de complex de implementat, programatorii riscă să fie distrași de alte activități secundare.

Inițializarea mediului

Pentru fiecare fir care are nevoie de funcționalitate COM, programatorul trebuie să adauge apeluri explicite la funcțiile CoInitialize[Ex] și CoUninitialize ; de asemenea, codul care utilizează clipboard-ul sau OLE drag & drop trebuie să apeleze OleInitialize și OleUninitialize . Deoarece unele fire din sistem pot fi create de biblioteci care nu utilizează COM, programatorul trebuie să fie atent în utilizarea oricărei funcții COM într-un thread care nu a fost creat în cadrul programului în sine.

Sortarea mesajelor

Când un apartament cu un singur fir este inițializat, acesta creează o fereastră ascunsă care este utilizată pentru adresarea mesajelor inter-apartament și inter-proces . Această fereastră trebuie să aibă procedura standard pentru gestionarea mesajelor. Acest proces este cunoscut sub numele de pompare a mesajelor. În versiunile anterioare de Windows, eșecul de a face acest lucru ar putea provoca o blocare la nivel de sistem. Această problemă este complicată și mai mult de unele API-uri Windows care inițializează COM ca parte a implementării lor, ceea ce provoacă la rândul său o lipsă de detalii de implementare a componentelor COM.

Numărarea referințelor

Un scenariu în care numărarea referințelor duce la probleme este unul în care două obiecte COM se referă unul la altul, așa cum se întâmplă de exemplu folosind „ puncte de conexiune” sau „ chiuvete de evenimente” . În acest caz, niciunul dintre obiecte nu se poate elibera pentru că trebuie mai întâi să-l elibereze pe celălalt, care, la rândul său, nu poate fi eliberat deoarece are încă o referință la obiectul care ar dori să-l elibereze. Acest cerc vicios poate fi rupt în două moduri: o terminare în afara benzii a unuia dintre cele două obiecte sau crearea a două obiecte COM identice, slab referențiate, dintre care unul este utilizat pentru conectarea la partenerul de comunicare și celălalt servește doar pentru a termina primul.

Iadul DLL-urilor

Fiecare interfață COM este, de asemenea, un contract între apelant și apelant: un program care utilizează o componentă COM trebuie să presupună că metodele pe care le apelează se vor comporta întotdeauna așa cum era de așteptat și nu are control asupra lor. Deoarece locația fiecărei componente este stocată într-o locație la nivel de sistem (în Windows în registru ), o singură versiune a aceleiași componente poate fi instalată pe sistem la un moment dat, de obicei versiunea pe care a adus-o ultima aplicație instalată pe care a adus-o cu el; dacă noua componentă are proprietăți chiar ușor diferite de cea anterioară, alte aplicații vor genera brusc erori și un comportament imprevizibil sau aleatoriu, fără niciun motiv aparent. Acest fenomen se numește „ DLL hell” ( „DLL infern”), situație infamă pentru programatori și administratori de sistem. Cu RegFree COM [ neclar ] al Windows XP, acest dezavantaj major poate fi redus drastic.

Notă

  1. ^ Component Object Model Technologies , de la microsoft.com , Microsoft Corporation.

Elemente conexe

linkuri externe

Controllo di autorità LCCN ( EN ) sh98001683
Estratto da " https://it.wikipedia.org/w/index.php?title=Component_Object_Model&oldid=116813102 "