Bagikan melalui

Mengubah Antarmuka dengan Cara yang Kompatibel Mundur

  • Artikel

Metode yang dijelaskan dalam The Versioning Theory untuk RPC dan COM mungkin tidak dapat diterima karena berbagai alasan. Mengubah versi antarmuka sesuai dengan aturan pada dasarnya mengharuskan klien baru tidak berkomunikasi dengan server lama. Ini sering kali tidak mungkin dengan perangkat lunak komersial yang disebarkan di lapangan. Terkadang, Windows telah memperkenalkan perubahan antarmuka yang tidak ada GUID atau versi yang diubah. Ini adalah hasil dari klien baru yang perlu berkomunikasi dengan server warisan, dan karena solusi bahwa klien baru akan mendukung antarmuka lama dan baru dianggap tidak diinginkan.

Praktik terbaik

Ini adalah metode yang wajar untuk bekerja di sekitar masalah ketidakkompakan kawat ketika ANTARMUKA GUID dan versi tidak dapat diubah.

  1. Mintalah aplikasi untuk mengetahui kemampuan sisi lain.

    Klien dan server memiliki protokol yang memungkinkan masing-masing (atau setidaknya klien baru) untuk menetapkan identitas mitra. Biasanya cukup untuk meminta klien baru mengetahui fitur yang didukung oleh server lama dan baru. Ini dapat dengan mudah dilakukan ketika aplikasi berpegang pada konteks koneksi, dan didukung melalui jenis panggilan fungsi XxxGetInfo yang dijalankan oleh klien sebelum melakukan operasi RPC apa pun. Ketika aplikasi mengelola fitur berdasarkan rilis per server, panggilan dengan ketidaksesamaan ke server/klien lama tidak pernah dapat terjadi, karena kontrol aplikasi yang memanggil dikeluarkan ke server mana. Intinya adalah bahwa aplikasi proaktif dalam mencegah ketidakcocokan terjadi. Ini dapat dilakukan bersama dengan praktik kedua.

  2. Memperkenalkan API jarak jauh baru.

    Metode jarak jauh baru tidak bertabrakan dengan metode yang ada jika ditambahkan di bagian paling akhir antarmuka. Klien lama dapat memanggil server baru seperti biasa. Klien baru dapat memanggil metode baru tanpa mengetahui identitas server, asalkan mengawasi kesalahan yang berasal dari server yang dipanggil. Run time RPC selalu memeriksa nomor metode untuk setiap antarmuka sebelum pengiriman untuk memastikan metode berada dalam v-table yang sesuai. Untuk metode yang tidak diketahui oleh server, run time RPC memunculkan pengecualian RPC_S_PROCNUM_OUT_OF_RANGE. Pengecualian ini hanya dimunculkan dalam situasi khusus ini. Oleh karena itu, klien baru dapat watch untuk pengecualian sebagai tanda bahwa panggilan masuk ke server lama dan dapat memodifikasi perilakunya dengan anggun.

  3. Perkenalkan parameter baru atau jenis data baru hanya dalam metode baru.

    Salah satu alasan untuk memperkenalkan metode baru adalah untuk menghindari ketidakkompakan data. Jika jenis data baru diperkenalkan atau hanya dimodifikasi, pada prinsipnya harus digunakan hanya dalam metode baru (atau metode). Lihat Contoh Perubahan yang Tidak Kompatibel untuk contoh perubahan jenis data yang tidak kompatibel. Satu-satunya pengecualian penting untuk aturan ini dijelaskan dalam item empat.

  4. Petakan parameter baru atau jenis data baru melalui pembungkus.

    Solusi ini berlaku ketika parameter atau jenis data baru harus diekspos ke pengguna, tetapi sebenarnya tidak harus di-remote secara terpisah atau dapat dipetakan ke jenis data atau parameter lama. Misalnya, banyak API sistem berbalik dan menjalankan panggilan jarak jauh. Mereka mungkin atau mungkin tidak melakukan semacam pemetaan dari jenis data yang diketahui pengguna ke jenis data yang benar-benar digunakan dalam panggilan RPC yang mendasar. Oleh karena itu selalu perlu diperiksa apakah perubahan antarmuka pengguna perlu disebarluaskan sebagai perubahan pada antarmuka jarak jauh.

    Situasi serupa dapat terjadi ketika pengguna memanggil API jarak jauh secara langsung, tetapi pembungkus dapat diperkenalkan untuk melakukan pemetaan jenis baru atau beberapa tindakan tambahan lainnya yang telah menjadi diperlukan. Interface Definition Language (IDL) memiliki beberapa cara untuk memfasilitasi remapping tersebut, yaitu [call_as], [transmit_as], dan [wire_marshal]. Atribut [call_as] memperkenalkan pembungkus fungsi pada klien dan server. Keduanya ditempatkan antara kode pengguna dan marshaler. Atribut lain menangani pemetaan jenis langsung. Untuk masalah ekstensi, [call_as] adalah yang paling sering digunakan, dan paling mudah dipahami dan dimanipulasi tanpa jebakan.

  5. Ubah jenis data melalui penyatuan tanpa default.

    Mengubah atribut atau jenis data biasanya menyebabkan ketidaksesamaan kawat. Lihat Contoh Perubahan yang Tidak Kompatibel misalnya. Namun, dalam kasus penyatuan tanpa klausul default, ketidakkompakan dapat dikelola dengan cara yang mirip dengan kasus prosedur di luar jangkauan, seperti yang dijelaskan sebelumnya. Skema ini mudah berlaku untuk jenis XxxINFO populer yang menggunakan serikat.

    Misalnya, panggilan seperti ini

    XxxGetInfo( [in] level, [out] XxxINFO  * pInfo );

    dapat mengembalikan informasi pada tingkat 1, 2 atau 3, dengan XxxINFO menjadi serikat dengan tiga cabang: 1, 2 dan 3.

  6. Gunakan atribut [range] untuk menentukan rentang.

    Anda dapat menentukan atribut [rentang] pada jenis skala sederhana tanpa melanggar kompatibilitas mundur. Atribut ini tidak memengaruhi format kawat, tetapi selama RPC yang belum diubah memeriksa nilai pada kawat untuk mengonfirmasi bahwa itu berada dalam rentang yang ditentukan dalam file .idl. Jika tidak, pengecualian RPC_X_INVALID_BOUND dilemparkan. Ini sangat berguna jika server tahu ukuran maksimum array berukuran.

    Contohnya:

    HRESULT Method1( [in, range(0,100)] ULONG m, [size_is(m)] ULONG *plong);

Perilaku RPC ketika tingkat yang ditunjukkan adalah 4 dan lengan hilang, tergantung pada definisi serikat. Untuk gabungan dengan klausul default yang ditentukan, RPC mengirimkan jenis yang ditunjukkan dalam klausa default untuk apa pun yang berbeda dari label lengan yang diketahui (dalam hal ini, apa pun selain 1, 2 atau 3). Untuk serikat tanpa default, unmarshaler menimbulkan pengecualian karena menurut definisi tidak ada default untuk dijatuhkan kembali. Pengecualiannya RPC_S_INVALID_TAG.

Sekali lagi, klien baru dapat menyesuaikan perilakunya setelah menemukan bahwa itu disebut server lama.

Apa yang mengikuti dari praktik yang direkomendasikan ini adalah bahwa jika jenis data yang dapat diremotable harus dirancang yang dapat diperluas di masa mendatang, gunakan penyatuan tanpa default dalam file IDL. Mengingat pilihan, serikat yang dienkapsulasi sedikit lebih bersih.

Karena kedaluwarsa representasi internal dari protokol kawat NDR64, rekomendasi untuk menambahkan lengan yang disediakan sebelumnya di bagian ini perlu dikualifikasi sebagai berikut: Lengan baru yang ditambahkan tidak dapat mengubah keselarasan serikat, dan khususnya, perataan senjata terbesar tidak boleh berubah. Ini biasanya bukan masalah, karena penunjuk dalam keselarasan pasukan lengan ke 8. Desain di mana setiap lengan adalah penunjuk ke jenis lengan adalah salah satu cara yang bersih untuk memenuhi persyaratan.