Masalah Implementasi untuk Penyedia ADSI

  • Artikel

Untuk menerapkan antarmuka ADSI, pertama-tama terapkan antarmuka COM IDirectoryObject. Dengan menyediakan antarmuka ini sebagai lapisan overhead minimal, Anda menyediakan aplikasi klien kontrol yang diperlukan untuk mengakses objek direktori langsung dari direktori daripada melalui cache ADSI, yang mengoptimalkan performa jaringan. Menggunakan antarmuka ini juga akan menyediakan implementasi Anda sendiri dengan fleksibilitas terbanyak.

Kedua, terapkan antarmuka ADSI dasar, IAD, IADsContainer, IADsCollection, dan antarmuka cache properti IADsPropertyValue, IADsPropertyEntry, IADsPropertyList. IADsGroup dan IADsMembers juga merupakan antarmuka yang sering diminati oleh perangkat lunak administrasi sistem.

Ketiga, terapkan antarmuka manajemen skema jika layanan direktori Anda memiliki skema yang mendasar: IADsClass, IADsProperty, IADsSyntax. Jika tidak ada skema yang mendasar, gunakan antarmuka ini untuk mengabstraksi kelas dan properti yang digunakan oleh layanan direktori. Skema dapat digunakan untuk menerbitkan fitur layanan direktori Anda ke klien ADSI.

Koleksi

Komponen penyedia ADSI dapat mengikuti salah satu dari tiga model untuk penembolokan koleksi selama enumerasi. Pilihan model penembolokan menentukan perilaku ADSI saat objek dalam koleksi dihapus dari layanan direktori yang mendasar di luar ADSI.

Model penembolokan meliputi:

  • Koleksi di-cache terlebih dahulu. Kumpulan instans objek diambil dari layanan direktori yang mendasar secara keseluruhan ketika IADsCollection::get__NewEnum dipanggil untuk membuat objek enumerator baru. Jika objek sumber untuk instans objek Direktori Aktif dalam koleksi yang diambil dihapus dari layanan direktori yang mendasar, klien tidak mengenali penghapusan hingga IAD::GetInfo atau IADs::SetInfo mencoba mengakses koleksi.
  • Koleksi di-cache secara bertahap. Koleksi diambil dari layanan direktori yang mendasar satu objek pada satu waktu ketika IEnumVARIANT::Next dipanggil. IEnumVARIANT::Reset akan kembali ke awal koleksi dalam cache dan IEnumVARIANT::Berikutnya akan mengembalikan objek yang di-cache hingga akhir cache tercapai, di mana titik objek baru akan ditambahkan dari penyimpanan yang mendasar. Ketika instans objek Direktori Aktif berada di cache, klien tidak akan mengetahui penghapusannya dari layanan direktori yang mendasar hingga IAD::GetInfo atau IADs::SetInfo mencoba mengakses objek.
  • Koleksi tidak di-cache. Koleksi diambil dari layanan direktori yang mendasar satu objek pada satu waktu ketika IEnumVARIANT::Next dipanggil. IEnumVARIANT::Reset akan kembali ke awal koleksi di penyimpanan yang mendasar. Operasi IEnumVARIANT::Next dan IEnumVARIANT::Reset tidak dapat mengambil objek yang dihapus, karena objek diambil sesuai permintaan dari layanan direktori yang mendasar. Hanya objek saat ini yang di-cache; jika objek saat ini dihapus, klien tidak akan mengetahui penghapusannya dari layanan direktori yang mendasar hingga IAD::GetInfo atau IADs::SetInfo mencoba mengakses objek.

Terlepas dari model penembolokan, ketahuilah bahwa enumerasi ADSI mengembalikan antarmuka layanan Direktori Aktif ke pemanggil. Untuk menghindari overhead mendapatkan penunjuk antarmuka baru, aplikasi ADSI harus menyimpan penunjuk antarmuka yang dikembalikan untuk objek yang ingin mereka manipulasi. Misalnya, aplikasi Visual Basic yang menghitung kontainer dan mengisi kotak daftar dengan nama dapat menyimpan pointer antarmuka yang terkait dengan nama untuk digunakan nanti. Pendekatan ini akan memberikan performa yang lebih besar daripada mengisi kotak daftar selama enumerasi dan mendapatkan penunjuk antarmuka baru ketika pengguna membuat pilihan.

Tentang ID Pengiriman

IDispatch adalah antarmuka Automation yang ditentukan oleh COM untuk pengontrol yang tidak menggunakan antarmuka COM secara langsung. Mengakses objek melalui IDispatch disebut akses terikat nama atau terikat terlambat, karena terjadi pada waktu proses ("terlambat") dan menggunakan nama string properti dan metode untuk mengatasi referensi ("nama"). Pada waktu proses, klien meneruskan nama string properti atau metode yang ingin mereka panggil ke metode IDispatch::GetIDsOfNames(). Jika properti atau metode ada pada objek, pengidentifikasi pengiriman (dispID) dari fungsi yang sesuai diambil. DispID kemudian digunakan untuk menjalankan fungsi melalui IDispatch::Invoke(). Menggunakan IDispatch, properti, dan metode pada antarmuka yang diekspos oleh satu objek muncul sebagai daftar datar. Karena akses terikat nama memerlukan dua panggilan fungsi, itu kurang efisien daripada menggunakan antarmuka COM secara langsung. Klien didorong untuk menggunakan antarmuka ADSI COM pada objek saat performa adalah pertimbangan. Pengontrol Automation Tingkat Lanjut seperti Visual Basic 4.0 dapat memanggil antarmuka COM lainnya serta IDispatch, jika antarmuka mematuhi batasan Automation untuk jenis data dan parameter yang lewat.

Penyedia ADSI menghasilkan dispID secara dinamis untuk setiap objek Direktori Aktif. DispID yang diambil melalui IDispatch::GetIDsOfNames untuk objek tertentu adalah nilai yang dihasilkan, tetapi bukan nilai yang ada di IDL untuk objek. Pengguna IDispatch harus memanggil GetIDsOfNames untuk mendapatkan dispID yang valid pada waktu proses.

Ketik Informasi dan Tipe Pustaka

ADSI SDK menyediakan pustaka jenis, Activeds.tlb, yang mendanai semua antarmuka standar yang didukung oleh ADSI. Penyedia harus menyediakan pustaka jenis serupa untuk semua antarmuka yang ditemukan di Activeds.tlb, ditambah data jenis tambahan apa pun untuk antarmuka yang diterapkan dalam komponen penyedia.

Berikut ini adalah contoh kode IDL.

[ object, uuid(IID_IADsXYZ), oleautomation, dual ]
interface IADsXYZ: IDispatch
{
// Read-only properties.
[propget]
HRESULT AReadOnlyProp ([out, retval]BSTR *pbstrAReadOnlyProp);
 
// Read/write properties.
[propget]
HRESULT AReadWriteProp ([out, retval]long *plAReadWriteProp);
[propput]
HRESULT AReadWriteProp ([in]long lAReadWriteProp);
 
// Methods.
HRESULT AMethod ([in]DATE dateInParameter,
[out, retval]BSTR *pbstrReturnValue);
};

Keamanan Thread

Model Objek Komponen (COM) menjelaskan tiga model utas berikut. Aplikasi COM menunjukkan model mana yang digunakan saat menginisialisasi pustaka COM menggunakan fungsi CoInitialize dan CoInitializeEx:

  • Utas tunggal. Model utas tunggal mengasumsikan satu utas eksekusi dalam suatu proses, dengan asumsi lebih lanjut bahwa struktur data COM dalam proses tidak memerlukan serialisasi akses.
  • Utas apartemen. Objek COM dikaitkan dengan utas yang membuatnya. Panggilan ke objek pada utas lain harus dijalankan oleh utas yang membuat objek tersebut. Untuk mencapai hal ini, utas sumber memanggil proksi klien yang mengatur panggilan metode dan mengirimkannya ke fungsi stub server di utas tujuan melalui antrean pesan Win32 yang terkait dengan utas tujuan.
  • Utas gratis. Objek COM diasumsikan aman untuk utas. Beberapa utas diizinkan mengakses objek apa pun dalam proses tanpa serialisasi yang diberlakukan.

ADSI tidak mengasumsikan model utas tertentu. Penulis komponen penyedia harus mengasumsikan model threading gratis dan menjamin konsistensi struktur data internal mereka dengan melindunginya dari thread-unsafe, yaitu, tidak terkoordinasi, pembaruan melalui penggunaan objek sinkronisasi seperti bagian penting atau semaphores.

Penguncian Objek

ADSI tidak memaksakan atau menentukan skema penguncian objek. Penyedia untuk namespace layanan yang mendukung serialisasi akses menggunakan penguncian dapat mengekspos skema penguncian yang mendasar melalui ekstensi khusus penyedia ke ADSI.

Nama Properti Dalam Skema

ADSI mewakili properti sebagai objek properti dalam kontainer skema ADSI. Ini mengharuskan nama properti unik dalam setiap kontainer skema. Penyedia harus memastikan bahwa tidak ada tabrakan nama.

Antarmuka Utama

Ketika penyedia tidak dapat mengidentifikasi antarmuka mana yang harus dikembalikan sebagai antarmuka utama, IID_IADs harus dikembalikan. Ini menyediakan akses terikat nama ke semua properti objek melalui IDispatch dan IADs::Get, IADs::GetEx, IADs::P ut, dan IADs::P utEx methods.