Model de obiect component - Component Object Model

Component Object Model ( COM ) este un standard de interfață binară pentru componentele software introdus de Microsoft în 1993. Este utilizat pentru a permite crearea obiectelor de comunicare între procese într-o gamă largă de limbaje de programare . COM este baza pentru alte câteva tehnologii și cadre Microsoft, inclusiv OLE , OLE Automation , Browser Helper Object , ActiveX , COM + , DCOM , Windows shell , DirectX , UMDF și Windows Runtime . Esența COM este un mod neutru de limbaj de implementare a obiectelor care poate fi utilizat în medii diferite de cel în care au fost create, chiar și peste granițele mașinii. Pentru componentele bine autorizate, COM permite reutilizarea obiectelor fără cunoștințe despre implementarea lor internă, deoarece forțează implementatorii de componente să furnizeze interfețe bine definite , care sunt separate de implementare. Semantica de alocare diferită a limbajelor este adaptată prin responsabilizarea obiectelor pentru propria lor creație și distrugere prin numărarea referințelor . Transformarea tipului de conversie între diferitele interfețe ale unui obiect se realizează prin metodă. Metoda preferată de „moștenire” în cadrul COM este crearea de sub-obiecte căreia sunt delegate metoda „apelurilor”. QueryInterface

COM este o tehnologie de interfață definită și implementată ca standard numai pe Microsoft Windows și Core Foundation 1.3 de la Apple și ulterior interfața de programare a aplicațiilor plug-in (API). Acesta din urmă implementează doar un subset al întregii interfețe COM. Pentru unele aplicații, COM a fost înlocuit cel puțin într-o oarecare măsură de cadrul Microsoft .NET și suport pentru serviciile web prin Windows Communication Foundation (WCF). Cu toate acestea, obiectele COM pot fi utilizate cu toate limbajele .NET prin .NET COM Interop . DCOM în rețea utilizează formate proprietare binare , în timp ce WCF încurajează utilizarea mesajelor SOAP bazate pe XML . COM este foarte asemănător cu alte tehnologii de interfață software componente , cum ar fi CORBA și Enterprise JavaBeans , deși fiecare are punctele sale forte și punctele sale slabe. Spre deosebire de C ++, COM oferă o interfață binară de aplicație stabilă (ABI) care nu se schimbă între versiunile compilatorului. Acest lucru face ca interfețele COM să fie atractive pentru bibliotecile C ++ orientate obiect, care urmează să fie utilizate de clienți compilate utilizând diferite versiuni de compilare.

Istorie

Una dintre primele metode de comunicare interproces în Windows a fost Dynamic Data Exchange (DDE), introdusă pentru prima dată în 1987, care permitea trimiterea și primirea de mesaje în așa-numitele „conversații” între aplicații. Antony Williams , care a fost implicat în crearea arhitecturii COM, a distribuit ulterior două lucrări interne în Microsoft care au îmbrățișat conceptul de componente software: Arhitectura obiectelor: tratarea necunoscutului - sau - tipul siguranței într-o bibliotecă de clase extensibilă dinamic în 1988 și Despre moștenire: ce înseamnă și cum să o folosești în 1990. Acestea au oferit fundamentul multor idei din spatele COM. Obiectivul de legare și încorporare (OLE), primul cadru Microsoft bazat pe obiecte, a fost construit deasupra DDE și conceput special pentru documentele compuse . A fost introdus cu Word pentru Windows și Excel în 1991 și ulterior a fost inclus cu Windows, începând cu versiunea 3.1 în 1992. Un exemplu de document compus este o foaie de calcul încorporată într-un document Word pentru Windows: pe măsură ce se fac modificări în foaia de calcul în Excel, acestea apar automat în interiorul documentului Word.

În 1991, Microsoft a introdus extensiile Visual Basic (VBX) cu Visual Basic 1.0. Un VBX este o extensie ambalată sub forma unei biblioteci de legături dinamice (DLL) care permite obiectelor să fie plasate grafic într-o formă și manipulate prin proprietăți și metode . Acestea au fost ulterior adaptate pentru a fi utilizate de alte limbaje, cum ar fi Visual C ++ . În 1992, când a fost lansată versiunea 3.1 a Windows , Microsoft a lansat OLE 2 cu modelul său de obiect de bază . COM Interfața binară Application (ABI) a fost aceeași ca MAPI ABI (lansat în 1992), și , ca ea sa bazat pe MSRPC și în cele din urmă la Open Group e DCE / RPC . În timp ce OLE 1 a fost axat pe documente compuse, COM și OLE 2 au fost concepute pentru a aborda componentele software în general. Conversațiile text și mesajele Windows s-au dovedit a nu fi suficient de flexibile pentru a permite partajarea caracteristicilor aplicației într-un mod robust și extensibil, astfel încât COM a fost creat ca o bază nouă, iar OLE s-a schimbat în OLE2. În 1994, controalele personalizate OLE (OCX) au fost introduse ca succesor al controalelor VBX. În același timp, Microsoft a declarat că OLE 2 ar fi doar cunoscut sub numele de „OLE” și că OLE nu mai este un acronim, ci un nume pentru toate tehnologiile componente ale companiei. La începutul anului 1996, Microsoft a găsit o nouă utilizare a comenzilor personalizate OLE, extinzând capacitatea browserului web de a prezenta conținut, a redenumit unele părți ale OLE referitoare la Internet „ ActiveX ” și a redenumit treptat toate tehnologiile OLE la ActiveX, cu excepția tehnologiei documentelor compuse. care a fost folosit în Microsoft Office . Mai târziu în acel an, Microsoft a extins COM pentru a lucra în întreaga rețea cu DCOM .

Tehnologii conexe

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

DDE

COM a înlocuit DDE ca formă preferată de comunicare între procese.

DCE / RPC și MSRPC

Ca model de componentă de limbă încrucișată, COM se bazează pe un limbaj de definiție a interfeței, sau IDL, pentru a descrie obiectele și funcțiile asociate. ID-ul COM se bazează în mare măsură pe IDL DCE / RPC bogat în caracteristici, cu extensii orientate obiect. Implementarea proprie de către Microsoft a DCE / RPC, cunoscută sub numele de MSRPC, este puternic utilizată ca mecanism primar de comunicare inter-proces pentru serviciile Windows NT și componentele interne, făcându-l o alegere evidentă a fundamentului.

DCOM

DCOM ( Distributed COM ) a extins acoperirea COM de la simpla susținere a unui singur utilizator cu aplicații separate care comunică pe desktop-ul Windows, la activarea obiectelor care rulează în contexte de securitate diferite și pe diferite mașini din rețea. Cu aceasta s-au adăugat caracteristici necesare pentru configurarea utilizatorilor care au autoritatea de a crea, activa și apela obiecte, pentru identificarea utilizatorului apelant, precum și specificarea criptării necesare pentru securitatea apelurilor.

COM +

Pentru ca Microsoft să ofere dezvoltatorilor suport pentru tranzacții distribuite , grupare de resurse, aplicații deconectate, publicare și abonament de evenimente, o mai bună gestionare a memoriei și procesorului (thread), precum și pentru a poziționa Windows ca o alternativă la alte sisteme de operare la nivel de întreprindere, Microsoft a introdus o tehnologie numită Microsoft Transaction Server (MTS) pe Windows NT 4. Cu Windows 2000, acea extensie semnificativă la COM a fost încorporată în sistemul de operare (spre deosebire de seria de instrumente externe furnizate de MTS ) și redenumită COM + . În același timp, Microsoft a subliniat DCOM ca o entitate separată. Componentele care au folosit serviciile COM + au fost tratate mai direct de stratul adăugat de COM +, în special de suportul sistemului de operare pentru interceptare. În prima versiune a MTS, interceptarea a fost abordată - instalarea unei componente MTS ar modifica registrul Windows pentru a apela software-ul MTS și nu componenta directă. Windows 2000 a revizuit, de asemenea, aplicația panoului de control Servicii componente folosită pentru a configura componentele COM +.

Un avantaj al COM + a fost că ar putea fi rulat în „ferme componente”. Instanțele unei componente, dacă sunt codificate corect, ar putea fi reunite și reutilizate prin apeluri noi la rutina de inițializare fără a o descărca din memorie. Componentele ar putea fi, de asemenea, distribuite (apelate de la o altă mașină). COM + și Microsoft Visual Studio au furnizat instrumente pentru a facilita generarea de proxy-uri client, așa că, deși DCOM a fost folosit pentru a efectua apelul de la distanță, a fost ușor de făcut pentru dezvoltatori. COM + a introdus, de asemenea, un mecanism de evenimente abonat / editor numit Evenimente COM + și a oferit o nouă modalitate de valorificare a MSMQ (o tehnologie care furnizează mesaje asincrone între aplicații) cu componente numite Componente în coadă . COM + evenimente extinde COM + programare pentru a sprijini modelul cu întârziere legat ( a se vedea legarii ) evenimente sau apeluri de metode între editor sau abonat și sistemul de evenimente.

.NET

Microsoft .NET oferă mijloace atât pentru a furniza tehnologia componentelor, cât și pentru a interacționa cu COM + (prin COM-interop-assemblys); .NET oferă împachetări pentru majoritatea controalelor COM utilizate în mod obișnuit. Microsoft .NET ascunde cele mai multe detalii de la crearea componentelor și, prin urmare, facilitează dezvoltarea. .NET poate utiliza COM + prin intermediul spațiului de nume System.EnterpriseServices, iar mai multe dintre serviciile pe care le oferă COM + au fost duplicate în versiunile recente ale .NET. De exemplu, spațiul de nume System.Transactions din .NET oferă clasa TransactionScope, care asigură gestionarea tranzacțiilor fără a recurge la COM +. În mod similar, componentele din coadă pot fi înlocuite de Windows Communication Foundation cu un transport MSMQ . (Cu toate acestea, MSMQ este o componentă COM nativă.) Există un suport limitat pentru compatibilitatea cu versiunile anterioare. Un obiect COM poate fi utilizat în .NET prin implementarea unui Runtime Callable Wrapper (RCW). Obiectele NET care sunt conforme cu anumite restricții de interfață pot fi utilizate în obiecte COM apelând un împachetabil apelabil COM (CCW). Din ambele părți COM și .NET, obiectele care utilizează cealaltă tehnologie apar ca obiecte native. A se vedea COM Interop . WCF (Windows Communication Foundation) ușurează o serie de provocări de execuție la distanță ale COM. De exemplu, permite ca obiectele să fie mai ușor structurate în funcție de valoare peste limitele procesului sau ale mașinii.

Windows Runtime

Noua versiune Microsoft Windows Runtime (sau WinRT, care nu trebuie confundată cu Windows RT ) este un program bazat pe COM, deși se bazează pe un COM îmbunătățit. Datorită bazei sale de tip COM, Windows Runtime permite interfațarea relativ ușoară din mai multe limbi, la fel ca și COM, dar este, în esență, un API nativ neadministrat. Definițiile API sunt, totuși, stocate în fișiere „.winmd”, care sunt codificate în format de metadate ECMA 335, același format de metadate CLI pe care .NET îl folosește cu câteva modificări. Acest format comun de metadate permite semnificativ mai puține cheltuieli generale decât P / Invoke atunci când WinRT este invocat din aplicații .NET, iar sintaxa sa este mult mai simplă.

Nano-COM (alias XPCOM)

Nano-COM este un subset extrem de mic al Modelului de obiecte componente care se concentrează exclusiv pe aspectele interfeței de aplicație binară (ABI) ale COM, care permit apeluri de funcții și metode pe module / componente compilate independent. Nano-COM poate fi exprimat cu ușurință într-un singur fișier antet C ++ care este portabil pentru toate compilatoarele C ++. Nano-COM extinde ABI-ul nativ al arhitecturii de instrucțiuni subiacente și al sistemului de operare pentru a adăuga suport pentru referințele de tipuri de obiecte (ABI-urile tipice se concentrează doar pe tipuri atomice, structuri, tablouri și convenții de apelare a funcțiilor). Baza Nano-COM a fost utilizată de Mozilla pentru bootstrap-ul Firefox (numit XPCOM ) și este în prezent utilizat ca tehnologie ABI de bază pentru DirectX / Direct3D / DirectML .

Un fișier antet Nano-COM definește sau numește cel puțin trei tipuri:

• GUID pentru identificarea tipurilor de interfață - acesta este efectiv un număr de 128 biți
• HRESULT pentru a identifica codurile de eroare din apelurile de metodă - aceasta este efectiv o utilizare standardizată de 32 de biți de inți la valori bine cunoscute (S_OK, E_FAIL, E_OUTOFMEMORY etc.)
• INecunoscut ca tip de bază pentru toate referințele la obiectele tastate - acesta este efectiv funcții virtuale abstracte pentru a sprijini dynamic_cast<T>achiziționarea stilului de noi tipuri de interfețe și numărarea ref.shared_ptr<T>

Multe utilizări ale Nano-COM definesc, de asemenea, două funcții pentru a rezolva ca rezultate bufferele de memorie alocate în numerar

• <NanoCom> Alloc - apelat prin implementări de metode pentru a aloca buffere brute (nu obiecte) care sunt returnate apelantului
• <NanoCom> Gratuit - apelat de către apelanții de metode pentru a elibera buffere alocate de către clienți, odată ce nu mai sunt folosiți

Unele implementări ale Nano-COM, cum ar fi Direct3D, evită funcțiile de alocare și se limitează să utilizeze numai buffere alocate apelantului.

Nano-COM nu are nicio noțiune de clase, apartamente, organizare, înregistrare etc. Mai degrabă, referințele la obiecte sunt pur și simplu trecute peste granițele funcției și alocate prin intermediul constructelor de limbaj standard (de exemplu, noul operator C ++).

Securitate

Componentele COM și ActiveX sunt rulate ca cod nativ pe computerul utilizatorului, fără sandbox. Prin urmare, există puține restricții cu privire la ceea ce poate face codul. Practica anterioară de încorporare a componentelor ActiveX pe paginile web cu Internet Explorer a dus, prin urmare, la probleme cu infecții malware . Microsoft a recunoscut problema cu ActiveX încă din 1996, când Charles Fitzgerald spunea: „Nu am susținut niciodată că ActiveX este intrinsec sigur”. Versiunile recente ale Internet Explorer solicită utilizatorului înainte de a instala controalele ActiveX, permițându-i utilizatorului să interzică instalarea comenzilor de pe site-uri în care utilizatorul nu are încredere. Comenzile ActiveX sunt semnate cu semnături digitale pentru a le garanta autenticitatea. De asemenea, este posibil să dezactivați complet controalele ActiveX sau să permiteți doar câteva selectate. Suportul transparent pentru serverele COM în afara procesului promovează în continuare siguranța software-ului în ceea ce privește izolarea procesului . Acest lucru poate fi util pentru decuplarea subsistemelor aplicațiilor mari în procese separate. Izolarea proceselor limitează corupția stării într-un proces de a afecta negativ integritatea celorlalte procese, deoarece acestea comunică numai prin interfețe strict definite. Astfel, numai subsistemul afectat trebuie repornit pentru a recâștiga starea validă. Acest lucru nu este cazul pentru subsistemele din același proces, unde un pointer necinstit într-un subsistem poate corupe aleatoriu alte subsisteme.

Detalii tehnice

Programatorii COM își construiesc software-ul folosind componente compatibile cu COM . Diferite tipuri de componente sunt identificate prin ID-uri de clasă (CLSID), care sunt identificatori unici la nivel global (GUID). Fiecare componentă COM își expune funcționalitatea prin una sau mai multe interfețe . Diferitele interfețe acceptate de o componentă se disting între ele folosind ID-uri de interfață (IID), care sunt și GUID-uri. Interfețele COM au legături în mai multe limbi, cum ar fi C , C ++ , Visual Basic , Delphi , Python și mai multe dintre limbajele de scriptare implementate pe platforma Windows. Tot accesul la componente se face prin metodele interfețelor. Aceasta permite tehnici precum inter-proces sau chiar programare inter-computer (aceasta din urmă folosind suportul DCOM).

Interfețe

Toate componentele COM implementează interfața IUnknown ( personalizată ), care expune metode de numărare a referințelor și conversie de tip (casting). O interfață personalizată IUnknown constă dintr-un pointer către o tabelă de metode virtuale care conține o listă de indicatori către funcțiile care implementează funcțiile declarate în interfață, în aceeași ordine în care sunt declarate în interfață. Cheltuielile generale de invocare în proces sunt, prin urmare, comparabile cu apelurile de metodă virtuală în C ++ . Pe lângă interfețele personalizate , COM acceptă și interfețele de expediere moștenite de la IDispatch . Interfețele de expediere acceptă legarea târzie pentru automatizarea OLE . Acest lucru permite accesarea nativă a interfețelor de expediere dintr-o gamă mai largă de limbaje de programare decât interfețele personalizate .

Clase

O clasă COM („coclass”) este o implementare concretă a uneia sau mai multor interfețe și seamănă foarte mult cu clasele în limbaje de programare orientate obiect . Clasele sunt create pe baza ID-ului lor de clasă ( CLSID ) sau pe baza șirului lor de identificare programatică ( ProgID ). Ca multe limbaje orientate obiect, COM oferă o separare a interfeței de implementare. Această distincție este deosebit de puternică în COM, unde obiectele nu pot fi accesate direct, ci doar prin interfețele lor. COM are, de asemenea, suport pentru mai multe implementări ale aceleiași interfețe, astfel încât clienții în timpul rulării pot alege ce implementare a unei interfețe să instanțeze.

Interfață definiție Limbaje și biblioteci de tipuri

Bibliotecile de tipuri conțin metadate pentru a reprezenta tipurile COM. Aceste tipuri sunt descrise folosind Microsoft Interface Definition Language (MSIDL / IDL). Fișierele IDL definesc clase orientate obiect, interfețe, structuri, enumerații și alte tipuri definite de utilizator într-un mod independent de limbă. IDL este similar în aparență cu declarațiile C ++ cu unele cuvinte cheie suplimentare, cum ar fi „interfață” și „bibliotecă” pentru definirea interfețelor și colecțiilor de clase. IDL acceptă, de asemenea, utilizarea atributelor între paranteze înainte de declarații pentru a furniza informații suplimentare, cum ar fi interfețele GUID și relațiile dintre parametrii indicatorului și câmpurile de lungime. Fișierele IDL sunt compilate de compilatorul MIDL . Pentru C / C ++, compilatorul MIDL generează un fișier antet independent de compilator care conține definiții struct pentru a se potrivi cu vtbl - urile interfețelor declarate și un fișier C care conține declarații ale GUID-urilor de interfață . Codul sursă C ++ pentru un modul proxy poate fi generat și de compilatorul MIDL. Acest proxy conține stub-uri de metodă pentru conversia apelurilor COM în apeluri de procedură la distanță pentru a permite DCOM pentru comunicarea în afara procesului. Fișierele IDL pot fi de asemenea compilate de compilatorul MIDL într-o bibliotecă de tipuri (TLB). Fișierele TLB conțin metadate binare care pot fi procesate de diferite compilatoare de limbă și medii de execuție (de exemplu, VB, Delphi, .NET etc.) pentru a genera construcții specifice limbajului pentru a reprezenta tipurile COM definite în TLB. Pentru C ++, aceasta va converti TLB înapoi la reprezentarea sa IDL.

Cadrul obiectelor

Deoarece COM este un cadru de execuție, tipurile trebuie să poată fi identificate și specificate individual la execuție. Pentru a realiza acest lucru, se utilizează identificatori unici la nivel global (GUID). Fiecare tip COM este desemnat propriul GUID pentru identificare în timpul rulării. Pentru ca informațiile despre tipurile COM să fie accesibile atât în ​​timpul compilării, cât și în timpul rulării, COM utilizează biblioteci de tipuri. Prin utilizarea eficientă a bibliotecilor de tip, COM își atinge capacitățile ca cadru dinamic pentru interacțiunea obiectelor.

Luați în considerare următorul exemplu de definiție a coclasei într-un IDL:

coclass SomeClass {
  [default] interface ISomeInterface;
};

Fragmentul de cod de mai sus declară o clasă COM numită SomeClasscare implementează o interfață numită ISomeInterface.

Acest lucru este echivalent conceptual cu definirea următoarei clase C ++:

class SomeClass : public ISomeInterface {
  ...
  ...
};

unde ISomeInterface este o clasă virtuală pură C ++ (uneori numită clasă de bază abstractă).

Fișierele IDL care conțin interfețe și clase COM sunt compilate în fișiere biblioteci de tipuri (TLB), care pot fi ulterior analizate de clienți în timp de execuție pentru a determina ce interfețe acceptă un obiect și pentru a invoca metodele de interfață ale unui obiect.

În C ++, obiectele COM sunt instanțiate cu CoCreateInstancefuncția care ia ID-ul clasei (CLSID) și ID-ul interfeței (IID) ca argumente. Instanțierea SomeClasspoate fi implementată după cum urmează:

ISomeInterface* interface_ptr = NULL;
HRESULT hr = CoCreateInstance(CLSID_SomeClass, NULL, CLSCTX_ALL,
                              IID_ISomeInterface, (void**)&interface_ptr);

În acest exemplu, subsistemul COM este utilizat pentru a obține un pointer către un obiect care implementează ISomeInterfaceinterfața și este necesară implementarea particulară a acestei interfețe de către CLASID_SomeClass.

Numărarea referințelor

Toate obiectele COM utilizează numărarea referințelor pentru a gestiona durata de viață a obiectelor. Numărul de referințe este controlat de clienți prin metodele AddRef și Release din interfața obligatorie IUnknown pe care o implementează toate obiectele COM. Obiectele COM sunt apoi responsabile pentru eliberarea propriei memorii atunci când numărul de referințe scade la zero. Anumite limbaje (de exemplu, Visual Basic ) oferă numărarea automată a referințelor, astfel încât dezvoltatorii de obiecte COM nu trebuie să mențină în mod explicit niciun contor de referință intern în codurile lor sursă. În C ++, un coder poate efectua fie contorizarea explicită a referințelor, fie poate utiliza indicatori inteligenți pentru a gestiona automat numărul de referințe.

Următoarele sunt îndrumări pentru momentul în care trebuie să apelați AddRef și Release pe obiecte COM:

• Funcțiile și metodele care returnează referințele interfeței (prin valoarea returnată sau prin parametrul „out”) vor crește numărul de referințe al obiectului returnat înainte de a reveni.
• Eliberarea trebuie să fie apelată la un indicator al interfeței înainte ca indicatorul să fie suprascris sau să iasă din sfera de aplicare.
• Dacă se face o copie pe un indicator de referință al interfeței, AddRef ar trebui apelat pe acel indicator.
• AddRef și Release trebuie să fie apelate pe interfața specifică la care se face referire, deoarece un obiect poate implementa numere de referință per interfață pentru a aloca resurse interne numai pentru interfețele la care se face referință.

Nu toate apelurile de numărare a referințelor sunt trimise către obiecte la distanță prin cablu; un proxy păstrează o singură referință pe obiectul la distanță și își păstrează propriul număr de referințe locale. Pentru a simplifica dezvoltarea COM, Microsoft a introdus ATL (Active Template Library) pentru dezvoltatorii C ++. ATL oferă o paradigmă de dezvoltare COM de nivel superior. De asemenea, protejează dezvoltatorii de aplicații client COM de necesitatea menținerii directe a numărării referințelor, prin furnizarea de obiecte cu pointer inteligent . Alte biblioteci și limbaje care conțin COM sunt clasele Microsoft Foundation , VC Compiler COM Support, VBScript , Visual Basic , ECMAScript ( JavaScript ) și Borland Delphi .

Programare

COM este un standard binar de limbă agnostic care poate fi dezvoltat în orice limbaj de programare capabil să înțeleagă și să implementeze tipurile sale de date și interfețele binare definite. Implementările COM sunt responsabile pentru intrarea și ieșirea din mediul COM, instanțierea și numărarea obiectelor COM, interogarea obiectelor pentru interfețele acceptate, precum și gestionarea erorilor. Compilatorul Microsoft Visual C ++ acceptă extensii la limbajul C ++ denumit Atribute C ++ . Aceste extensii sunt concepute pentru a simplifica dezvoltarea COM și a elimina o mare parte din codul boilerplate necesar pentru a implementa servere COM în C ++.

Utilizarea registrului

În Windows, clasele COM, interfețele și bibliotecile de tipuri sunt listate de GUID-uri în registru , sub HKEY_CLASSES_ROOT \ CLSID pentru clase și HKEY_CLASSES_ROOT \ Interface pentru interfețe. Bibliotecile COM utilizează registrul pentru a localiza fie bibliotecile locale corecte pentru fiecare obiect COM, fie locația de rețea pentru un serviciu la distanță.

COM fără înregistrare

Înregistrare-Free COM (RegFree COM) este o tehnologie introdusă cu Windows XP , care permite Component Object Model (COM) componente pentru activare magazin metadate și CLSID ( Class ID) pentru componenta fără a utiliza registru . În schimb, metadatele și CLSID-urile claselor implementate în componentă sunt declarate într-un manifest de asamblare (descris folosind XML ), stocate fie ca resursă în executabil, fie ca fișier separat instalat împreună cu componenta. Aceasta permite instalarea mai multor versiuni ale aceleiași componente în diferite directoare, descrise de propriile manifeste, precum și implementarea XCOPY . Această tehnică are suport limitat pentru serverele EXE COM și nu poate fi utilizată pentru componente la nivel de sistem, cum ar fi MDAC , MSXML , DirectX sau Internet Explorer .

În timpul încărcării aplicației, încărcătorul Windows caută manifestul. Dacă este prezent, încărcătorul adaugă informații din acesta în contextul activării. Când fabrica de clase COM încearcă să instanțeze o clasă, contextul de activare este verificat mai întâi pentru a vedea dacă se poate găsi o implementare pentru CLSID. Numai dacă căutarea eșuează, registrul este scanat.

Instanțierea manuală a obiectelor COM

Obiectele COM pot fi create manual, având în vedere calea fișierului DLL și GUID- ul obiectului. Acest lucru nu necesită înregistrarea DLL sau GUID în registrul de sistem și nu folosește fișiere manifest. O DLL COM exportă o funcție numită DllGetClassObject. Apelarea DllGetClassObject cu GUID-ul dorit și IID_IClassFactory oferă o instanță a unui obiect din fabrică . Obiectul Factory are o metodă CreateInstance, care poate crea instanțe ale unui obiect având un GUID de interfață. Acesta este același proces utilizat intern la crearea instanțelor componentelor COM înregistrate.

Dacă obiectul COM creat creează un alt obiect COM folosind API-ul CoCreateInstance generic, va încerca să facă acest lucru în modul generic obișnuit, folosind fișierele registry sau manifest. Dar poate crea obiecte interne (care poate să nu fie înregistrate deloc) și să distribuie referințe la interfețe către acestea, folosind propriile cunoștințe private.

Transparența procesului și a rețelei

Obiectele COM pot fi instantaneate și referite în mod transparent din cadrul aceluiași proces (în proces), peste limitele procesului (în afara procesului) sau de la distanță prin rețea (DCOM). Obiectele în afara procesului și obiectele la distanță folosesc marshalling-ul pentru a serializa apelurile metodei și a returna valorile peste limitele procesului sau ale rețelei. Această organizare este invizibilă pentru client, care accesează obiectul ca și cum ar fi un obiect local în proces.

Filetat

În COM, threading-ul este abordat printr-un concept cunoscut sub numele de apartamente . Un obiect COM individual trăiește exact într-un singur apartament, care poate fi cu un singur fir sau cu mai multe fire. Există trei tipuri de apartamente în COM: apartament cu un singur fir (STA) , apartament cu mai multe fire (MTA) și apartament cu fir neutru (NA). Fiecare apartament reprezintă un mecanism prin care starea internă a unui obiect poate fi sincronizată pe mai multe fire. Un proces poate consta din mai multe obiecte COM, dintre care unele pot utiliza STA și altele pot folosi MTA. Toate firele care accesează obiecte COM trăiesc în mod similar într-un singur apartament. Alegerea apartamentului pentru obiectele și firele COM sunt determinate în timpul rulării și nu pot fi modificate.

Firele și obiectele care aparțin aceluiași apartament respectă aceleași reguli de acces la fir. Apelurile de metodă care se efectuează în interiorul aceluiași apartament sunt, prin urmare, efectuate direct, fără nicio asistență din partea COM. Apelurile efectuate prin metode efectuate între apartamente sunt realizate prin rețea. Acest lucru necesită utilizarea de proxy și stub-uri.

Critici

Deoarece COM are o implementare destul de complexă, programatorii pot fi distrași de unele dintre problemele de „instalare”.

Mesaj de pompare

Când un STA este inițializat, se creează o fereastră ascunsă care este utilizată pentru rutare de mesaje între apartamente și între procese. Această fereastră trebuie să aibă coada de mesaje în mod regulat „pompată”. Această construcție este cunoscută sub numele de „ pompă de mesaje ”. În versiunile anterioare de Windows, eșecul în acest sens ar putea cauza blocaje la nivel de sistem. Această problemă este complicată de unele API-uri Windows care inițializează COM ca parte a implementării lor, ceea ce provoacă o „scurgere” a detaliilor de implementare.

Numărarea referințelor

Numărarea referințelor în cadrul COM poate provoca probleme dacă se referă circular două sau mai multe obiecte . Proiectarea unei aplicații trebuie să ia în considerare acest lucru, astfel încât obiectele să nu rămână orfane. Obiectele pot fi lăsate, de asemenea, cu număr de referințe active, dacă se utilizează modelul COM "Event sink". Deoarece obiectul care declanșează evenimentul are nevoie de o referință la obiectul care reacționează la eveniment, numărul de referințe al acestuia din urmă nu va ajunge niciodată la zero. Ciclurile de referință sunt de obicei rupte utilizând fie terminarea în afara benzii, fie identități divizate. În tehnica de terminare în afara benzii, un obiect expune o metodă care, atunci când este apelată, îl obligă să renunțe la referințele sale la alte obiecte, întrerupând astfel ciclul. În tehnica de identitate divizată, o singură implementare expune două obiecte COM separate (cunoscute și sub numele de identități). Aceasta creează o referință slabă între obiectele COM, împiedicând un ciclu de referință.

DLL Hell

Deoarece componentele COM în proces sunt implementate în fișiere DLL și înregistrarea permite doar o singură versiune per CLSID, acestea ar putea fi, în unele situații, supuse efectului „ DLL Hell ”. Capacitatea COM fără înregistrare elimină această problemă pentru componentele aflate în proces; COM fără înregistrare nu este disponibil pentru serverele în afara procesului.

Vezi si

• Definiție a modelului de obiecte cu mai multe limbi între platforme cu obiecte portabile (de calcul)
• Distribuit Component Object Model (DCOM), extensie care face COM să funcționeze în rețele
• Common Language Infrastructure curent .NET cross-language multi-model Obiect platformă
• Windows Runtime , un model de aplicație, versiune evoluată a COM care vizează Windows 8
• CORBA Common Object Request Broker Architecture, model de obiect cross-language deschis în mai multe limbi
• Modelul de obiecte cu platformă transversală deschisă D-Bus
• KParts KDE component framework
• SOM IBM System Object Model, alternativă bogată în caracteristici la COM
• Aplicațiile XPCOM Mozilla încorporează modelul de obiecte componente pentru platforme
• Enterprise JavaBeans
• Invocare metodă Java la distanță
• Motor de comunicații pe internet
• Legarea limbii
• Interfață funcție străină
• Convocarea apelului
• Denumiți mangling
• Interfață de programare a aplicației - API
• Interfață binară de aplicație - ABI
• SWIG generator de legături de interfețe automate open source din mai multe limbi în alte limbi

Note

Referințe

• „COM: O scurtă introducere (powerpoint)” . Adus pe 7 martie 2006 .
• Box, Don (1998). COM esențial . Addison-Wesley. ISBN 978-0-201-63446-4.
• Chappell, David (1996). Înțelegerea ActiveX și OLE . Microsoft Press. ISBN 978-1-57231-216-6.
• "Integrarea și migrația serviciilor COM + către WCF" . Adus la 15 aprilie 2010 .

linkuri externe

• Model de obiecte componente pe MSDN
• Interviu cu Tony Williams, co-inventator al COM (Video Webcast, august 2006)
• Informații: Diferența dintre comenzile OLE și comenzile ActiveX de la Microsoft
• Specificația formatului de date TypeLib (neoficial) cu utilitar dumper open source.
• Glosarul COM / DCOM