Vendor Lock-In
Oleh
chmood
Vendor Lock-In
Bukti anekdotal: Kami telah sering dijumpai proyek perangkat lunak yang mengklaim arsitektur mereka didasarkan pada vendor atau lini produk tertentu. Bukti anekdot lain terjadi sekitar waktu upgrade produk dan instalasi aplikasi baru: "Ketika saya mencoba untuk membaca file data baru ke dalam versi lama dari aplikasi, crash sistem saya." "Setelah Anda membaca data ke dalam aplikasi baru, Anda tidak pernah bisa keluar lagi." "Perangkat lunak tua bertindak seperti itu memiliki virus, tapi itu mungkin hanya data aplikasi baru." "Arsitektur kami adalah .. Apa nama dari database kami lagi?"
Latar belakang
Sebuah skenario terburuk dari antipattern ini akan terjadi jika data Anda dan lisensi perangkat lunak benar-benar dialokasikan untuk layanan online, dan satu hari, sebuah kotak dialog modal muncul.
Pengolah kata interaktif menjadi lebih populer daripada format teknologi bahasa (seperti SGML) karena memungkinkan pengguna untuk melihat format akhir pada layar komputer dan mencetak salinan dari penampilan di layar. Kemampuan ini disebut "Apa yang Anda lihat adalah apa yang Anda dapatkan" (WYSIWIG).
Sebuah variasi meresap Vendor Lock-In adalah fenomena yang disebut "Apa yang Anda lihat adalah semacam-of seperti apa yang Anda dapatkan" (WYSISLWYG, diucapkan "musang wig"). Baru-baru ini, mengingat dominasi desktop Microsoft, fitur yang menyebabkan produk versi cetak dokumen bervariasi secara signifikan dari penampilan mereka di layar. Misalnya, simbol dalam gambar dapat berubah atau hilang, dan benda-benda tertanam sering dicetak sebagai string perintah (seperti "{TERTANAM POWERPOINT GAMBAR}").
Dokumen dari versi yang berbeda dari produk Microsoft yang sama dapat menyebabkan masalah dukungan pada jaringan perusahaan dan sistem crash. Banyak perusahaan mencegah atau melarang co-berbaur versi produk. Sulit untuk menghindari bentuk vendor lock-in dan misfeatures produknya karena ketergantungan organisasi pada produk Microsoft untuk pertukaran dokumen.
Bentuk umum
Sebuah proyek software mengadopsi teknologi produk dan menjadi benar-benar tergantung pada implementasi vendor. Ketika upgrade selesai, perubahan perangkat lunak dan masalah interoperabilitas terjadi, dan pemeliharaan terus menerus diperlukan untuk menjaga sistem berjalan.
Selain itu, diharapkan fitur produk baru sering tertunda, menyebabkan jadwal slip dan ketidakmampuan untuk menyelesaikan fitur perangkat lunak aplikasi yang diinginkan.
Gejala Dan Konsekuensi
Upgrade produk komersial mendorong siklus pemeliharaan aplikasi perangkat lunak.
Fitur produk yang dijanjikan ditunda atau tidak pernah disampaikan, selanjutnya, menyebabkan kegagalan untuk memberikan update aplikasi.
Produk bervariasi secara signifikan dari standar sistem terbuka yang diiklankan.
Jika upgrade produk terjawab seluruhnya, produk pembelian kembali dan reintegrasi sering diperlukan.
Penyebab khas
Produk bervariasi dari yang diterbitkan standar sistem terbuka karena tidak ada proses kesesuaian yang efektif untuk standar.
Produk ini dipilih berdasarkan sepenuhnya pada pemasaran dan informasi penjualan, dan tidak setelah pemeriksaan teknis yang lebih rinci.
Tidak ada pendekatan teknis untuk mengisolasi perangkat lunak aplikasi dari ketergantungan langsung pada produk.
Pemrograman aplikasi membutuhkan pengetahuan produk mendalam.
Kompleksitas dan umum dari teknologi produk sangat melebihi dari kebutuhan aplikasi; ketergantungan langsung pada hasil produk kegagalan untuk mengelola kompleksitas arsitektur sistem aplikasi.
Dikenal Pengecualian
Vendor Lock-In antipattern diterima ketika kode vendor tunggal membuat sebagian besar kode yang dibutuhkan dalam aplikasi.
Solusi refactored
Solusi refactioned ke Vendor Lock-In antipattern disebut lapisan isolasi. Lapisan isolasi memisahkan paket perangkat lunak dan teknologi. Hal ini dapat digunakan untuk menyediakan perangkat lunak portabilitas dari middleware yang mendasari dan interface-platform tertentu. Solusi ini berlaku jika satu atau lebih kondisi berikut berlaku:
Isolasi aplikasi perangkat lunak dari infrastruktur tingkat rendah. Infrastruktur ini mungkin termasuk middleware, sistem operasi, mekanisme keamanan, atau mekanisme tingkat rendah lainnya.
Perubahan pada infrastruktur dasar diantisipasi dalam siklus hidup perangkat lunak yang terkena dampak; misalnya, rilis produk baru atau direncanakan migrasi ke infrastruktur baru.
Sebuah antarmuka pemrograman lebih nyaman berguna atau diperlukan. Tingkat abstraksi yang disediakan oleh infrastruktur yang terlalu primitif atau terlalu fleksibel untuk aplikasi dan sistem dimaksudkan.
Ada kebutuhan untuk penanganan konsisten infrastruktur di banyak sistem. Beberapa konvensi kelas berat untuk penanganan default interface infrastruktur harus dilembagakan.
Beberapa infrastruktur harus didukung, baik selama siklus hidup atau bersamaan.
Solusinya memerlukan menciptakan lapisan software yang abstrak infrastruktur atau tergantung produk-interface perangkat lunak yang mendasari. Lapisan ini menyediakan antarmuka aplikasi yang benar-benar mengisolasi perangkat lunak aplikasi dari antarmuka yang mendasari.
Antarmuka aplikasi harus mengimplementasikan antarmuka bahasa-spesifik nyaman untuk kemampuan yang diinginkan. Perangkat lunak layering harus memastikan penanganan default beberapa panggilan infrastruktur dan parameter, tapi mengekspos rincian lainnya jika diperlukan.
Lapisan isolasi ini digunakan di beberapa proyek pengembangan sistem untuk menjamin interoperabilitas, konsistensi, dan isolasi. Untuk menerapkannya, bermigrasi isolasi untuk infrastruktur baru yang diperlukan; juga, memperbarui lapisan isolasi ketika infrastruktur diperbarui. Dalam semua kasus, mempertahankan antarmuka perangkat lunak aplikasi yang sama, terlepas dari perubahan infrastruktur.
Hal ini juga diperlukan untuk menginstal gateway antara beberapa infrastruktur yang harus didukung secara bersamaan, dan untuk menginstal maju dan mundur gateway selama migrasi infrastruktur
Manfaat dari solusi ini adalah:
Mitigasi risiko dan biaya migrasi infrastruktur.
Menghalangi usang disebabkan oleh perubahan infrastruktur.
Pengurangan risiko dan biaya upgrade software yang dibutuhkan oleh perubahan infrastruktur.
Jaminan kurang dan lebih murah padat karya pemrograman antarmuka untuk kebanyakan programmer aplikasi.
Dukungan untuk penggunaan bersamaan beberapa infrastruktur, transparan.
Penegakan terkoordinasi penanganan default interface fleksibel dan parameter.
Pemisahan pengetahuan infrastruktur dari pengetahuan aplikasi, sehingga memungkinkan tim kecil dari pengembang infrastruktur untuk mempertahankan lapisan isolasi, sementara mayoritas programmer memiliki antarmuka yang disesuaikan untuk perangkat lunak layering.
Konsekuensi lain dari solusi ini adalah bahwa:
Lapisan isolasi harus bermigrasi dan dipelihara, berpotensi pada berbagai platform dan infrastruktur.
Para pengembang yang mendefinisikan lapisan isolasi interface awal harus dikoordinasikan.
Perubahan yang dilakukan pada antarmuka aplikasi harus dikoordinasikan.
Variasi
Solusi ini sering digunakan di tingkat global dalam produk komersial dan teknologi. Biasanya, lapisan isolasi memungkinkan vendor untuk menyediakan antarmuka bahasa-spesifik nyaman untuk teknologi tingkat rendah. Beberapa kemudahan ini datang dalam bentuk penanganan default antarmuka tingkat rendah yang lebih fleksibel dari yang diperlukan untuk sebagian besar aplikasi.
Sebagai contoh, produk HP Berorientasi Objek Distributed Computing Environment (DCE OO) terdiri dari lapisan isolasi, dan menyajikan C ++ antarmuka untuk pengembang aplikasi. Mendasari antarmuka ini lapisan isolasi perangkat lunak yang dibangun di atas bahasa C DCE lingkungan.
Panggilan ke C ++ API dapat meminta beberapa mendasari DCE panggilan prosedur; khususnya, hanya dua panggilan yang diperlukan untuk menginisialisasi OO DCE interface layanan keamanan. Lapisan isolasi yang mendasari, pada gilirannya, membuat lebih dari 50 panggilan ke DCE API untuk mencapai inisialisasi ini dengan layanan keamanan warisan DCE.
Lapisan isolasi solusi yang paling berlaku di tingkat perusahaan. Namun, sistem individu telah menerapkan solusi ini untuk memberikan middleware isolasi; misalnya, Paragon Elektronik Cahaya Tabel (ELT) produk menggunakan lapisan isolasi di atas Common Desktop Environment (CDE) infrastruktur middleware, disebut ToolTalk. Dengan mengisolasi ToolTalk, Paragon dapat dengan mudah bermigrasi produk untuk infrastruktur CORBA dan mendukung CORBA dan prasarana ToolTalk.
Contoh
Contoh-contoh berikut tiga kegunaan diketahui dari solusi lapisan isolasi:
Kerangka ORBlite, berdasarkan HP ORB ditambah, isolat aplikasi perangkat lunak dari beberapa pemetaan bahasa dan protokol jaringan demikian, ia mampu mendukung beberapa pemetaan bahasa untuk C ++, mengingat evolusi pemetaan OMG selama proses adopsi dan revisi
Meskipun OpenDoc tidak lagi dalam strategi produk dari penciptanya, beberapa pendekatan teknis yang menarik yang digunakan, termasuk solusi lapisan isolasi. The OpenDoc Parts Framework (OPF) lembaga yang lebih tinggi tingkat C ++ pemrograman antarmuka ke antarmuka dokumen senyawa OpenDoc, didefinisikan dalam ISO IDL. OPF termasuk antarmuka untuk operasi fungsi sistem (termasuk tampilan grafis), serta fungsi OpenDoc. Dalam melakukannya, OPF memungkinkan sumber interface portabilitas kode untuk sistem middleware, windowing, dan operasi. Bagian dokumen senyawa ditulis menggunakan OPF dapat porting melalui kompilasi dan menghubungkan ke OS / 2, MacOS, dan Windows95. Sebuah pengujian kemampuan disebut LiveObjects, dari Komponen Integrasi Labs, konsorsium yang bertanggung jawab untuk OpenDoc, menjamin portabilitas komponen dan interoperabilitas.
EOSDIS (Earth Observing System Data dan Sistem Informasi) adalah proyek pencarian informasi skala besar yang didanai oleh NASA. The EOSDIS middleware lapisan abstraksi digunakan untuk mengisolasi perangkat lunak aplikasi dan berkembang middleware. Prototipe awal yang digunakan produk beta-test CORBA. Ini prototyping upaya terbukti tidak berhasil, terutama karena kesulitan dalam menggunakan produk beta-test. Meskipun manajemen program mengakui perlunya dukungan CORBA masa depan, sebuah berorientasi objek ekstensi DCE proprietary dipilih untuk implementasi jangka pendek. Manajemen juga tidak ingin bergantung sepenuhnya pada antarmuka proprietary. Situasi itu diselesaikan melalui penambahan lapisan middleware abstraksi yang bertopeng pilihan middleware dari perangkat lunak aplikasi EOSDIS; itu bersembunyi perbedaan objek penciptaan, aktivasi objek, dan objek doa.
Solusi terkait
Pola ini terkait dengan pola Obyek Wrapper, yang menyediakan isolasi ke dan dari satu aplikasi ke infrastruktur objek tunggal. Pola lapisan isolasi memberikan insulasi beberapa aplikasi dari beberapa infrastruktur. Pola ini juga terkait dengan pola Profil, di mana lapisan isolasi dapat dilihat sebagai profil perusahaan tertentu untuk penggunaan middleware.
Lapisan isolasi dapat dianggap sebagai salah satu tingkat dalam arsitektur berlapis Berbeda dengan kebanyakan lapisan, ini adalah lapisan sangat tipis yang tidak mengandung objek aplikasi. Biasanya, lapisan isolasi hanya berfungsi sebagai proxy untuk mengintegrasikan klien dan jasa dengan satu atau lebih infrastruktur. Pola Proxy dijelaskan dalam Buschmann (1996).
Berlakunya Untuk Pandangan Dan Timbangan Lainnya:
Dampak Vendor Lock-In pada manajemen adalah hilangnya kontrol teknologi, fungsi IT, dan O & M anggaran untuk diktat rilis produk penjual. Vendor Lock-In juga dampak manajemen risiko. Antipattern sering diterima dengan pemahaman bahwa fitur masa depan akan dilaksanakan. Sayangnya, fitur ini sering memberikan lambat dari yang diharapkan atau dibutuhkan, jika pernah.
Vendor Lock-In mempengaruhi pengembang dengan mengharuskan mereka memiliki pengetahuan produk yang mendalam. Tapi pengetahuan ini bersifat sementara; itu akan dibuat usang oleh rilis produk berikutnya. Dengan demikian, pengembang diharapkan pada pembelajaran-kurva treadmill terus menerus tentang fitur produk, bug produk, dan produk berjangka.
Antipattern Nama: Penjual Lock-In
Disebut Juga Sebagai: Produk-Dependent Arsitektur, Bondage dan Submission, Connector Konspirasi
Kebanyakan Skala Sering: Sistem
Refactored Solusi Nama: Isolasi Lapisan
Refactored Solusi Jenis: Software
Penyebab root: Sloth, Apatis, Kebanggaan / Ketidaktahuan (mudah tertipu)
Angkatan seimbang: Manajemen Alih Teknologi, Manajemen Perubahan
Bukti anekdotal: Kami telah sering dijumpai proyek perangkat lunak yang mengklaim arsitektur mereka didasarkan pada vendor atau lini produk tertentu. Bukti anekdot lain terjadi sekitar waktu upgrade produk dan instalasi aplikasi baru: "Ketika saya mencoba untuk membaca file data baru ke dalam versi lama dari aplikasi, crash sistem saya." "Setelah Anda membaca data ke dalam aplikasi baru, Anda tidak pernah bisa keluar lagi." "Perangkat lunak tua bertindak seperti itu memiliki virus, tapi itu mungkin hanya data aplikasi baru." "Arsitektur kami adalah .. Apa nama dari database kami lagi?"
Latar belakang
Sebuah skenario terburuk dari antipattern ini akan terjadi jika data Anda dan lisensi perangkat lunak benar-benar dialokasikan untuk layanan online, dan satu hari, sebuah kotak dialog modal muncul.
Pengolah kata interaktif menjadi lebih populer daripada format teknologi bahasa (seperti SGML) karena memungkinkan pengguna untuk melihat format akhir pada layar komputer dan mencetak salinan dari penampilan di layar. Kemampuan ini disebut "Apa yang Anda lihat adalah apa yang Anda dapatkan" (WYSIWIG).
Sebuah variasi meresap Vendor Lock-In adalah fenomena yang disebut "Apa yang Anda lihat adalah semacam-of seperti apa yang Anda dapatkan" (WYSISLWYG, diucapkan "musang wig"). Baru-baru ini, mengingat dominasi desktop Microsoft, fitur yang menyebabkan produk versi cetak dokumen bervariasi secara signifikan dari penampilan mereka di layar. Misalnya, simbol dalam gambar dapat berubah atau hilang, dan benda-benda tertanam sering dicetak sebagai string perintah (seperti "{TERTANAM POWERPOINT GAMBAR}").
Dokumen dari versi yang berbeda dari produk Microsoft yang sama dapat menyebabkan masalah dukungan pada jaringan perusahaan dan sistem crash. Banyak perusahaan mencegah atau melarang co-berbaur versi produk. Sulit untuk menghindari bentuk vendor lock-in dan misfeatures produknya karena ketergantungan organisasi pada produk Microsoft untuk pertukaran dokumen.
Bentuk umum
Sebuah proyek software mengadopsi teknologi produk dan menjadi benar-benar tergantung pada implementasi vendor. Ketika upgrade selesai, perubahan perangkat lunak dan masalah interoperabilitas terjadi, dan pemeliharaan terus menerus diperlukan untuk menjaga sistem berjalan.
Selain itu, diharapkan fitur produk baru sering tertunda, menyebabkan jadwal slip dan ketidakmampuan untuk menyelesaikan fitur perangkat lunak aplikasi yang diinginkan.
Gejala Dan Konsekuensi
Upgrade produk komersial mendorong siklus pemeliharaan aplikasi perangkat lunak.
Fitur produk yang dijanjikan ditunda atau tidak pernah disampaikan, selanjutnya, menyebabkan kegagalan untuk memberikan update aplikasi.
Produk bervariasi secara signifikan dari standar sistem terbuka yang diiklankan.
Jika upgrade produk terjawab seluruhnya, produk pembelian kembali dan reintegrasi sering diperlukan.
Penyebab khas
Produk bervariasi dari yang diterbitkan standar sistem terbuka karena tidak ada proses kesesuaian yang efektif untuk standar.
Produk ini dipilih berdasarkan sepenuhnya pada pemasaran dan informasi penjualan, dan tidak setelah pemeriksaan teknis yang lebih rinci.
Tidak ada pendekatan teknis untuk mengisolasi perangkat lunak aplikasi dari ketergantungan langsung pada produk.
Pemrograman aplikasi membutuhkan pengetahuan produk mendalam.
Kompleksitas dan umum dari teknologi produk sangat melebihi dari kebutuhan aplikasi; ketergantungan langsung pada hasil produk kegagalan untuk mengelola kompleksitas arsitektur sistem aplikasi.
Dikenal Pengecualian
Vendor Lock-In antipattern diterima ketika kode vendor tunggal membuat sebagian besar kode yang dibutuhkan dalam aplikasi.
Solusi refactored
Solusi refactioned ke Vendor Lock-In antipattern disebut lapisan isolasi. Lapisan isolasi memisahkan paket perangkat lunak dan teknologi. Hal ini dapat digunakan untuk menyediakan perangkat lunak portabilitas dari middleware yang mendasari dan interface-platform tertentu. Solusi ini berlaku jika satu atau lebih kondisi berikut berlaku:
Isolasi aplikasi perangkat lunak dari infrastruktur tingkat rendah. Infrastruktur ini mungkin termasuk middleware, sistem operasi, mekanisme keamanan, atau mekanisme tingkat rendah lainnya.
Perubahan pada infrastruktur dasar diantisipasi dalam siklus hidup perangkat lunak yang terkena dampak; misalnya, rilis produk baru atau direncanakan migrasi ke infrastruktur baru.
Sebuah antarmuka pemrograman lebih nyaman berguna atau diperlukan. Tingkat abstraksi yang disediakan oleh infrastruktur yang terlalu primitif atau terlalu fleksibel untuk aplikasi dan sistem dimaksudkan.
Ada kebutuhan untuk penanganan konsisten infrastruktur di banyak sistem. Beberapa konvensi kelas berat untuk penanganan default interface infrastruktur harus dilembagakan.
Beberapa infrastruktur harus didukung, baik selama siklus hidup atau bersamaan.
Solusinya memerlukan menciptakan lapisan software yang abstrak infrastruktur atau tergantung produk-interface perangkat lunak yang mendasari. Lapisan ini menyediakan antarmuka aplikasi yang benar-benar mengisolasi perangkat lunak aplikasi dari antarmuka yang mendasari.
Antarmuka aplikasi harus mengimplementasikan antarmuka bahasa-spesifik nyaman untuk kemampuan yang diinginkan. Perangkat lunak layering harus memastikan penanganan default beberapa panggilan infrastruktur dan parameter, tapi mengekspos rincian lainnya jika diperlukan.
Lapisan isolasi ini digunakan di beberapa proyek pengembangan sistem untuk menjamin interoperabilitas, konsistensi, dan isolasi. Untuk menerapkannya, bermigrasi isolasi untuk infrastruktur baru yang diperlukan; juga, memperbarui lapisan isolasi ketika infrastruktur diperbarui. Dalam semua kasus, mempertahankan antarmuka perangkat lunak aplikasi yang sama, terlepas dari perubahan infrastruktur.
Hal ini juga diperlukan untuk menginstal gateway antara beberapa infrastruktur yang harus didukung secara bersamaan, dan untuk menginstal maju dan mundur gateway selama migrasi infrastruktur
Manfaat dari solusi ini adalah:
Mitigasi risiko dan biaya migrasi infrastruktur.
Menghalangi usang disebabkan oleh perubahan infrastruktur.
Pengurangan risiko dan biaya upgrade software yang dibutuhkan oleh perubahan infrastruktur.
Jaminan kurang dan lebih murah padat karya pemrograman antarmuka untuk kebanyakan programmer aplikasi.
Dukungan untuk penggunaan bersamaan beberapa infrastruktur, transparan.
Penegakan terkoordinasi penanganan default interface fleksibel dan parameter.
Pemisahan pengetahuan infrastruktur dari pengetahuan aplikasi, sehingga memungkinkan tim kecil dari pengembang infrastruktur untuk mempertahankan lapisan isolasi, sementara mayoritas programmer memiliki antarmuka yang disesuaikan untuk perangkat lunak layering.
Konsekuensi lain dari solusi ini adalah bahwa:
Lapisan isolasi harus bermigrasi dan dipelihara, berpotensi pada berbagai platform dan infrastruktur.
Para pengembang yang mendefinisikan lapisan isolasi interface awal harus dikoordinasikan.
Perubahan yang dilakukan pada antarmuka aplikasi harus dikoordinasikan.
Variasi
Solusi ini sering digunakan di tingkat global dalam produk komersial dan teknologi. Biasanya, lapisan isolasi memungkinkan vendor untuk menyediakan antarmuka bahasa-spesifik nyaman untuk teknologi tingkat rendah. Beberapa kemudahan ini datang dalam bentuk penanganan default antarmuka tingkat rendah yang lebih fleksibel dari yang diperlukan untuk sebagian besar aplikasi.
Sebagai contoh, produk HP Berorientasi Objek Distributed Computing Environment (DCE OO) terdiri dari lapisan isolasi, dan menyajikan C ++ antarmuka untuk pengembang aplikasi. Mendasari antarmuka ini lapisan isolasi perangkat lunak yang dibangun di atas bahasa C DCE lingkungan.
Panggilan ke C ++ API dapat meminta beberapa mendasari DCE panggilan prosedur; khususnya, hanya dua panggilan yang diperlukan untuk menginisialisasi OO DCE interface layanan keamanan. Lapisan isolasi yang mendasari, pada gilirannya, membuat lebih dari 50 panggilan ke DCE API untuk mencapai inisialisasi ini dengan layanan keamanan warisan DCE.
Lapisan isolasi solusi yang paling berlaku di tingkat perusahaan. Namun, sistem individu telah menerapkan solusi ini untuk memberikan middleware isolasi; misalnya, Paragon Elektronik Cahaya Tabel (ELT) produk menggunakan lapisan isolasi di atas Common Desktop Environment (CDE) infrastruktur middleware, disebut ToolTalk. Dengan mengisolasi ToolTalk, Paragon dapat dengan mudah bermigrasi produk untuk infrastruktur CORBA dan mendukung CORBA dan prasarana ToolTalk.
Contoh
Contoh-contoh berikut tiga kegunaan diketahui dari solusi lapisan isolasi:
Kerangka ORBlite, berdasarkan HP ORB ditambah, isolat aplikasi perangkat lunak dari beberapa pemetaan bahasa dan protokol jaringan demikian, ia mampu mendukung beberapa pemetaan bahasa untuk C ++, mengingat evolusi pemetaan OMG selama proses adopsi dan revisi
Meskipun OpenDoc tidak lagi dalam strategi produk dari penciptanya, beberapa pendekatan teknis yang menarik yang digunakan, termasuk solusi lapisan isolasi. The OpenDoc Parts Framework (OPF) lembaga yang lebih tinggi tingkat C ++ pemrograman antarmuka ke antarmuka dokumen senyawa OpenDoc, didefinisikan dalam ISO IDL. OPF termasuk antarmuka untuk operasi fungsi sistem (termasuk tampilan grafis), serta fungsi OpenDoc. Dalam melakukannya, OPF memungkinkan sumber interface portabilitas kode untuk sistem middleware, windowing, dan operasi. Bagian dokumen senyawa ditulis menggunakan OPF dapat porting melalui kompilasi dan menghubungkan ke OS / 2, MacOS, dan Windows95. Sebuah pengujian kemampuan disebut LiveObjects, dari Komponen Integrasi Labs, konsorsium yang bertanggung jawab untuk OpenDoc, menjamin portabilitas komponen dan interoperabilitas.
EOSDIS (Earth Observing System Data dan Sistem Informasi) adalah proyek pencarian informasi skala besar yang didanai oleh NASA. The EOSDIS middleware lapisan abstraksi digunakan untuk mengisolasi perangkat lunak aplikasi dan berkembang middleware. Prototipe awal yang digunakan produk beta-test CORBA. Ini prototyping upaya terbukti tidak berhasil, terutama karena kesulitan dalam menggunakan produk beta-test. Meskipun manajemen program mengakui perlunya dukungan CORBA masa depan, sebuah berorientasi objek ekstensi DCE proprietary dipilih untuk implementasi jangka pendek. Manajemen juga tidak ingin bergantung sepenuhnya pada antarmuka proprietary. Situasi itu diselesaikan melalui penambahan lapisan middleware abstraksi yang bertopeng pilihan middleware dari perangkat lunak aplikasi EOSDIS; itu bersembunyi perbedaan objek penciptaan, aktivasi objek, dan objek doa.
Solusi terkait
Pola ini terkait dengan pola Obyek Wrapper, yang menyediakan isolasi ke dan dari satu aplikasi ke infrastruktur objek tunggal. Pola lapisan isolasi memberikan insulasi beberapa aplikasi dari beberapa infrastruktur. Pola ini juga terkait dengan pola Profil, di mana lapisan isolasi dapat dilihat sebagai profil perusahaan tertentu untuk penggunaan middleware.
Lapisan isolasi dapat dianggap sebagai salah satu tingkat dalam arsitektur berlapis Berbeda dengan kebanyakan lapisan, ini adalah lapisan sangat tipis yang tidak mengandung objek aplikasi. Biasanya, lapisan isolasi hanya berfungsi sebagai proxy untuk mengintegrasikan klien dan jasa dengan satu atau lebih infrastruktur. Pola Proxy dijelaskan dalam Buschmann (1996).
Berlakunya Untuk Pandangan Dan Timbangan Lainnya:
Dampak Vendor Lock-In pada manajemen adalah hilangnya kontrol teknologi, fungsi IT, dan O & M anggaran untuk diktat rilis produk penjual. Vendor Lock-In juga dampak manajemen risiko. Antipattern sering diterima dengan pemahaman bahwa fitur masa depan akan dilaksanakan. Sayangnya, fitur ini sering memberikan lambat dari yang diharapkan atau dibutuhkan, jika pernah.
Vendor Lock-In mempengaruhi pengembang dengan mengharuskan mereka memiliki pengetahuan produk yang mendalam. Tapi pengetahuan ini bersifat sementara; itu akan dibuat usang oleh rilis produk berikutnya. Dengan demikian, pengembang diharapkan pada pembelajaran-kurva treadmill terus menerus tentang fitur produk, bug produk, dan produk berjangka.
Category
Komentar