Ultima dată când eram în Berlin era înainte să cadă zidul. Când, când am părăsit sectorul american la punctul de control Charlie, m-am dus în Berlinul de Est, fără îndoială că aici era o graniță. Sârmă ghimpată, armești și câmpuri minate au făcut-o foarte distinctă. Dar, în spatele liniei defensive, diferențele erau evidente: în partea de est a zidului, mașinile compacte de doi litri spumau fum gros, iar lângă magazine erau linii lungi.
Schimbările ne așteaptă cu fiecare tranziție a frontierei, indiferent cât de mică diferență este una din cealaltă. Acest capitol este dedicat trecerii frontierelor - în principal a granițelor dintre diferitele procese. Vom lua în considerare și intersecția limitelor dintre mașini.
De ce trebuie să mergem în străinătate? Deoarece în unele cazuri este preferabil să implementați componenta în EXE, nu în DLL. Unul dintre motive poate fi faptul că aplicația dvs. este deja implementată în EXE. După puțină rafinare, puteți pune la dispoziție servicii de aplicații, astfel încât utilizatorii să își poată automatiza utilizarea.
Dacă componenta și clientul sunt în diferite EXE-uri, acestea vor fi localizate în procese separate, fiecare proces creează propriul proces pentru fiecare modul EXE. Atunci când se transferă informații între o astfel de componentă și client, este necesar să se depășească limita dintre procese. Din fericire, nu este nevoie să modificați codul componentei, deși se fac unele modificări la clasa CFactory. prezentate în capitolul precedent, trebuie încă să facă. Cu toate acestea, înainte de a trece la punerea în aplicare, ar trebui luate în considerare problemele și soluțiile legate de accesarea interfețelor COM între limitele proceselor.
În timp ce fiecare modul EXE are propriul proces, DLL este proiectat în procesul EXE cu care sunt conectate. Din acest motiv, DLL-urile sunt numite servere în proces (în proces). și EXE - servere în afara procesului (în afara procesului). Uneori EXE se numește și servere locale. pentru a le distinge de un alt tip de servere în afara procesului - servere de la distanță. Un server de la distanță este un server în afara procesului care rulează pe altă mașină.
accesul la memoria asociată cu interfața, nu va putea apela funcțiile acestei interfețe. În această situație, interfețele noastre ar fi complet inutile.
Pentru ca interfața să funcționeze prin limita procesului, sunt necesare următoarele. "Procesul trebuie să poată apela funcția într-un alt proces.
"Procesul trebuie să poată transmite date către un alt proces.
"Clientul nu trebuie să-și facă griji dacă componenta este un server în interiorul sau în afara procesului.
Apel local de procedură
Există multe metode de comunicare interprocesă, inclusiv DDE, numite conducte și memorie partajată. Cu toate acestea, COM utilizează un apel local de procedură (LPC). LPC este un mijloc de comunicare între diferite procese pe aceeași mașină. LPC este un mijloc specializat de comunicare între diferite procese dintr-o singură mașină, construit pe baza unei proceduri de apel la distanță (RPC) (a se vedea Figura 10-2).
Standardul RPC este definit de OSF (Open Software Foundation) în specificația RPC DCE (Distributed Computing Environment) RPC. RPC asigură comunicarea între procese pe diferite mașini utilizând o varietate de protocoale de rețea. Modelul distribuit COM (DCOM), despre care vom discuta mai târziu în acest capitol, utilizează RPC pentru comunicarea prin rețea.
Apel local de procedură
Fig. 10-2 Clientul din EXE utilizează mecanismul Win32 LPC pentru a apela funcțiile unei componente implementate într-un alt EXE
Pentru marshaling a componentei, interfața IMarshal este proiectată. În timpul creării componentei COM, aceasta solicită această interfață. COM apoi solicită funcțiile membrului acestei interfețe să marcheze și să demareze parametrii înainte și după apelarea funcțiilor. Biblioteca COM implementează versiunea standard a IMarshal. care funcționează pentru majoritatea interfețelor. Motivul principal pentru crearea propriei versiuni
Pentru a continua descărcarea, trebuie să colectați imaginea: