Antarmuka IMarshal (objidlbase.h)
Memungkinkan objek COM untuk menentukan dan mengelola marsekal penunjuk antarmukanya.
Warisan
Antarmuka IMarshal mewarisi dari antarmuka IUnknown . IMarshal juga memiliki jenis anggota ini:
Metode
Antarmuka IMarshal memiliki metode ini.
| IMarshal::D isconnectObject Metode IMarshal::D isconnectObject (objidlbase.h) merilis semua koneksi ke objek yang servernya memanggil implementasi objek dari metode ini. |
| IMarshal::MarshalInterface Metode IMarshal::MarshalInterface (objidlbase.h) marshals penunjuk antarmuka. |
| IMarshal::ReleaseMarshalData Metode IMarshal::ReleaseMarshalData (objidlbase.h) menghancurkan paket data marshal. |
| IMarshal::UnmarshalInterface Metode IMarshal::UnmarshalInterface (objidlbase.h) membatalkan nama penunjuk antarmuka. |
Keterangan
Marshaling adalah proses pengemasan data ke dalam paket untuk transmisi ke proses atau komputer yang berbeda. Unmarshaling adalah proses pemulihan data tersebut di ujung penerima. Dalam panggilan tertentu, argumen metode di-marshalasi dan tidak dinamai dalam satu arah, sementara nilai yang dikembalikan dinamika dan tidak dinamai di arah lain.
Meskipun marshaling berlaku untuk semua jenis data, penunjuk antarmuka memerlukan penanganan khusus. Masalah mendasar adalah bagaimana kode klien yang berjalan dalam satu ruang alamat dapat dengan benar mendereferensikan penunjuk ke antarmuka pada objek yang berada di ruang alamat yang berbeda. Solusi COM adalah untuk aplikasi klien untuk berkomunikasi dengan objek asli melalui objek pengganti, atau proksi, yang hidup dalam proses klien. Proksi menyimpan referensi ke antarmuka pada objek asli dan memberi klien penunjuk ke antarmuka itu sendiri. Ketika klien memanggil metode antarmuka pada objek asli, panggilannya benar-benar akan masuk ke proksi. Oleh karena itu, dari sudut pandang klien, semua panggilan sedang dalam proses.
Saat menerima panggilan, proksi mendeskripsikan argumen metode dan melalui beberapa cara komunikasi antarproses, seperti RPC, meneruskannya ke kode dalam proses server, yang membatalkan amarshal argumen dan meneruskannya ke objek asli. Marshal kode yang sama ini mengembalikan nilai untuk transmisi kembali ke proksi, yang membatalkan nama nilai dan meneruskannya ke aplikasi klien.
IMarshal menyediakan metode untuk membuat, menginisialisasi, dan mengelola proksi dalam proses klien; itu tidak menentukan bagaimana proksi harus berkomunikasi dengan objek asli. Implementasi default COM IMarshal menggunakan RPC. Ketika Anda menerapkan antarmuka ini sendiri, Anda bebas untuk memilih metode komunikasi antarproses apa pun yang Anda anggap sesuai untuk aplikasi Anda—memori bersama, pipa bernama, handel jendela, RPC—singkatnya, apa pun yang berfungsi.
Implementasi Default IMarshal
COM menggunakan implementasi internal antarmuka IMarshal sendiri untuk marshal objek apa pun yang tidak menyediakan implementasinya sendiri. COM membuat penentuan ini dengan mengkueri objek untuk IMarshal. Jika antarmuka hilang, COM default ke implementasi internalnya.Implementasi default COM IMarshal menggunakan proksi generik untuk setiap objek dan membuat stub dan proksi individual, karena diperlukan, untuk setiap antarmuka yang diimplementasikan pada objek . Mekanisme ini diperlukan karena COM tidak dapat mengetahui terlebih dahulu antarmuka tertentu apa yang dapat diterapkan objek tertentu. Pengembang yang tidak menggunakan marshaling default COM, memilih sebagai gantinya untuk menulis rutinitas proksi dan marshaling mereka sendiri, mengetahui pada waktu kompilasi semua antarmuka untuk ditemukan pada objek mereka dan oleh karena itu memahami dengan tepat apa kode marshaling diperlukan. COM, dalam memberikan dukungan marshaling untuk semua objek, harus melakukannya pada waktu proses.
Proksi antarmuka berada dalam proses klien; stub antarmuka berada di server. Bersama-sama, setiap pasangan menangani semua marshaling untuk antarmuka. Pekerjaan setiap proksi antarmuka adalah untuk argumen marshal dan nilai pengembalian yang tidak biasa dan parameter keluar yang diteruskan bolak-balik dalam panggilan berikutnya ke antarmukanya. Pekerjaan setiap stub antarmuka adalah untuk membatalkan akar argumen fungsi dan meneruskannya ke objek asli dan kemudian marshal nilai yang dikembalikan dan parameter keluar yang dikembalikan objek.
Proksi dan stub berkomunikasi dengan saluran RPC (panggilan prosedur jarak jauh), yang menggunakan infrastruktur RPC sistem untuk komunikasi antarproses. Saluran RPC mengimplementasikan satu antarmuka, IRpcChannelBuffer, di mana proksi antarmuka dan stub memegang pointer. Proksi dan stub memanggil antarmuka untuk mendapatkan paket marshaling, mengirim data ke rekan mereka, dan menghancurkan paket ketika mereka selesai. Stub antarmuka juga memegang pointer ke objek asli.
Untuk antarmuka tertentu, proksi dan stub keduanya diimplementasikan sebagai instans dari kelas yang sama, yang tercantum untuk setiap antarmuka dalam registri sistem di bawah label ProxyStubClsid32. Entri ini memetakan IID antarmuka ke CLSID dari proksi dan objek stub-nya. Ketika COM perlu marshal antarmuka, ia melihat registri sistem untuk mendapatkan CLSID yang sesuai. Server yang diidentifikasi oleh CLSID ini mengimplementasikan proksi antarmuka dan stub antarmuka.
Paling sering, kelas yang dirujuk CLSID ini secara otomatis dihasilkan oleh alat yang inputnya adalah deskripsi tanda tangan fungsi dan semantik antarmuka tertentu, yang ditulis dalam beberapa bahasa deskripsi antarmuka. Meskipun menggunakan bahasa seperti itu sangat disarankan dan didorong demi akurasi, melakukannya tidak diperlukan. Proksi dan stub hanyalah komponen COM yang digunakan oleh infrastruktur RPC dan, dengan demikian, dapat ditulis dengan cara apa pun yang diinginkan, selama kontrak eksternal yang benar ditegakkan. Programmer yang merancang antarmuka baru bertanggung jawab untuk memastikan bahwa semua proksi antarmuka dan stub yang pernah ada menyetujui representasi data marshaled mereka.
Saat dibuat, proksi antarmuka selalu diagregasi ke dalam proksi yang lebih besar, yang mewakili objek secara keseluruhan. Proksi objek ini juga menggabungkan objek proksi generik COM, yang dikenal sebagai manajer proksi. Manajer proksi mengimplementasikan dua antarmuka: IUnknown dan IMarshal. Semua antarmuka lain yang mungkin diimplementasikan pada objek diekspos dalam proksi objeknya melalui agregasi proksi antarmuka individual. Klien yang memegang pointer ke proksi objek "percaya" ia memegang pointer ke objek aktual.
Proksi yang mewakili objek secara keseluruhan diperlukan dalam proses klien sehingga klien dapat membedakan panggilan ke antarmuka yang sama yang diterapkan pada objek yang sama sekali berbeda. Persyaratan seperti itu tidak ada dalam proses server, namun, di mana objek itu sendiri berada, karena semua stub antarmuka hanya berkomunikasi dengan objek yang dibuat. Tidak ada koneksi lain yang dimungkinkan.
Stub antarmuka, berbeda dengan proksi antarmuka, tidak dikumpulkan karena tidak perlu mereka muncul ke beberapa klien eksternal untuk menjadi bagian dari keseluruhan yang lebih besar. Ketika terhubung, stub antarmuka diberikan penunjuk ke objek server tempat ia harus meneruskan pemanggilan metode yang diterimanya. Meskipun berguna untuk merujuk secara konseptual ke manajer stub, yang berarti bagian kode dan status apa pun dalam infrastruktur RPC sisi server yang melayani remoting objek tertentu, tidak ada persyaratan langsung bahwa kode dan status mengambil bentuk tertentu yang ditentukan dengan baik.
Pertama kali klien meminta pointer ke antarmuka pada objek tertentu, COM memuat stub IClassFactory dalam proses server dan menggunakannya untuk marshal pointer pertama kembali ke klien. Dalam proses klien, COM memuat proksi generik untuk objek pabrik kelas dan memanggil implementasi IMarshal untuk membatalkan penunjuk pertama itu. COM kemudian membuat proksi antarmuka pertama dan memberinya penunjuk ke saluran RPC. Akhirnya, COM mengembalikan penunjuk IClassFactory ke klien, yang menggunakannya untuk memanggil IClassFactory::CreateInstance, meneruskannya referensi ke antarmuka.
Kembali ke proses server, COM sekarang membuat instans baru objek, bersama dengan stub untuk antarmuka yang diminta. Stub ini membuat penunjuk antarmuka kembali ke proses klien, di mana proksi objek lain dibuat, kali ini untuk objek itu sendiri. Juga dibuat adalah proksi untuk antarmuka yang diminta, penunjuk yang dikembalikan ke klien. Dengan panggilan berikutnya ke antarmuka lain pada objek, COM akan memuat stub antarmuka dan proksi yang sesuai sesuai kebutuhan.
Ketika proksi antarmuka baru dibuat, COM memberinya penunjuk ke implementasi IUnknown manajer proksi, tempat ia mendelegasikan semua panggilan QueryInterface . Setiap proksi antarmuka mengimplementasikan dua antarmukanya sendiri: antarmuka yang diwakilinya dan IRpcProxyBuffer. Proksi antarmuka mengekspos antarmukanya sendiri langsung ke klien, yang dapat memperoleh penunjuknya dengan memanggil QueryInterface pada manajer proksi. Namun, hanya COM yang dapat memanggil IRpcProxyBuffer, yang digunakan untuk menyambungkan dan memutuskan koneksi proksi ke saluran RPC. Klien tidak dapat meminta proksi antarmuka untuk mendapatkan penunjuk ke antarmuka IRpcProxyBuffer .
Di sisi server, setiap stub antarmuka mengimplementasikan IRpcStubBuffer. Kode server yang bertindak sebagai manajer stub memanggil IRpcStubBuffer::Connect dan melewati stub antarmuka penunjuk IUnknown objeknya.
Ketika proksi antarmuka menerima pemanggilan metode, ia mendapatkan paket marshaling dari saluran RPC melalui panggilan ke IRpcChannelBuffer::GetBuffer. Proses marshaling argumen akan menyalin data ke dalam buffer. Ketika marshaling selesai, proksi antarmuka memanggil IRpcChannelBuffer::SendReceive untuk mengirim paket marshaled ke stub antarmuka yang sesuai. Ketika IRpcChannelBuffer::SendReceive kembali, buffer tempat argumen dinamai akan digantikan oleh buffer baru yang berisi nilai pengembalian yang dinamai dari rintisan antarmuka. Proksi antarmuka membatalkan nama nilai pengembalian, memanggil IRpcChannelBuffer::FreeBuffer untuk membebaskan buffer, lalu mengembalikan nilai yang dikembalikan ke pemanggil asli metode.
Ini adalah implementasi dari IRpcChannelBuffer::SendReceive yang benar-benar mengirim permintaan ke proses server dan yang tahu cara mengidentifikasi proses server dan, dalam proses itu, objek tempat permintaan harus dikirim. Implementasi saluran juga tahu cara meneruskan permintaan ke manajer stub yang sesuai dalam proses itu. Rintisan antarmuka membatalkan nama argumen dari buffer yang disediakan, memanggil metode yang ditunjukkan pada objek server, dan membasmi nilai yang dikembalikan kembali ke buffer baru yang dialokasikan oleh panggilan ke IRpcChannelBuffer::GetBuffer. Saluran kemudian mengirimkan paket data kembali ke proksi antarmuka, yang masih berada di tengah-tengah IRpcChannelBuffer::SendReceive, yang kembali ke proksi antarmuka.
Instans tertentu dari proksi antarmuka dapat digunakan untuk melayani lebih dari satu antarmuka, selama kondisi berikut terpenuhi:
- IID antarmuka yang terpengaruh harus dipetakan ke ProxyStubClsid yang sesuai dalam registri sistem.
- Proksi antarmuka harus mendukung panggilan ke QueryInterface dari satu antarmuka yang didukung ke antarmuka lain, seperti biasa, serta dari IUnknown dan IRpcProxyBuffer.
Pada berbagai waktu, proksi dan stub harus mengalokasikan atau membebaskan memori. Proksi antarmuka, misalnya, perlu mengalokasikan memori untuk mengembalikan parameter ke pemanggilnya. Dalam hal ini, proksi antarmuka dan stub antarmuka hanyalah komponen COM normal, karena mereka harus menggunakan alokator tugas standar. (Lihat CoGetMalloc.)
Persyaratan
| Persyaratan | Nilai |
|---|---|
| Klien minimum yang didukung | Windows 2000 Professional [aplikasi desktop | Aplikasi UWP] |
| Server minimum yang didukung | Windows 2000 Server [aplikasi desktop | Aplikasi UWP] |
| Target Platform | Windows |
| Header | objidlbase.h (termasuk ObjIdl.h) |
Lihat juga
Saran dan Komentar
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.
Kirim dan lihat umpan balik untuk