Saya sudah membaca di Wikipedia dan situs lain tentang OSGi , tapi saya tidak benar-benar melihat gambaran besarnya. Dikatakan bahwa ini adalah platform berbasis komponen, dan Anda dapat memuat ulang modul saat runtime. Juga "contoh praktis" yang diberikan di mana-mana adalah Eclipse Plugin Framework.

Pertanyaan saya adalah:

1. Apa definisi OSGi yang jelas dan sederhana?

2. Masalah umum apa yang dipecahkan?

Yang dimaksud dengan "masalah umum" yang saya maksudkan adalah masalah yang kita hadapi sehari-hari, seperti "Apa yang dapat OSGi lakukan untuk membuat pekerjaan kita lebih efisien / menyenangkan / sederhana?"

apa manfaat yang diberikan sistem komponen OSGi bagi Anda?
Nah, ini daftar yang cukup lengkap:

Berkurang Kompleksitas - Berkembang dengan teknologi OSGi berarti mengembangkan bundel: komponen OSGi. Bundel adalah modul. Mereka menyembunyikan internal mereka dari bundel lain dan berkomunikasi melalui layanan yang terdefinisi dengan baik. Menyembunyikan internal berarti lebih banyak kebebasan untuk berubah nanti. Ini tidak hanya mengurangi jumlah bug, itu juga membuat bundel lebih mudah untuk dikembangkan karena bundel berukuran benar menerapkan sepotong fungsi melalui antarmuka yang terdefinisi dengan baik. Ada blog yang menarik yang menggambarkan apa yang dilakukan teknologi OSGi untuk proses pengembangan mereka.

Reuse - Model komponen OSGi membuatnya sangat mudah untuk menggunakan banyak komponen pihak ketiga dalam suatu aplikasi. Semakin banyak proyek sumber terbuka menyediakan JAR mereka yang siap dibuat untuk OSGi. Namun, perpustakaan komersial juga tersedia sebagai bundel siap pakai.

Dunia nyata -Kerangka kerja OSGi bersifat dinamis. Itu dapat memperbarui bundel dengan cepat dan layanan dapat datang dan pergi. Pengembang yang terbiasa dengan Java yang lebih tradisional melihat ini sebagai fitur yang sangat bermasalah dan gagal melihat keuntungannya. Namun, ternyata dunia nyata sangat dinamis dan memiliki layanan dinamis yang dapat datang dan pergi membuat layanan ini sangat cocok untuk banyak skenario dunia nyata. Misalnya, layanan dapat memodelkan perangkat di jaringan. Jika perangkat terdeteksi, layanan terdaftar. Jika perangkat hilang, layanan tidak terdaftar. Ada sejumlah skenario dunia nyata yang cocok dengan model layanan dinamis ini. Oleh karena itu aplikasi dapat menggunakan kembali primitif kuat dari registri layanan (daftar, dapatkan, daftar dengan bahasa filter ekspresif, dan menunggu layanan muncul dan menghilang) di domain mereka sendiri. Ini tidak hanya menghemat kode penulisan, tetapi juga menyediakan visibilitas global, alat debugging, dan lebih banyak fungsi daripada yang akan diterapkan untuk solusi khusus. Menulis kode dalam lingkungan yang dinamis terdengar seperti mimpi buruk, tetapi untungnya, ada kelas dan kerangka kerja pendukung yang mengambil sebagian besar, jika tidak semua, dari rasa sakit itu.

Penempatan Mudah - Teknologi OSGi bukan hanya standar untuk komponen. Ini juga menentukan bagaimana komponen dipasang dan dikelola. API ini telah digunakan oleh banyak bundel untuk menyediakan agen manajemen. Agen manajemen ini dapat sesederhana shell perintah, driver protokol manajemen TR-69, driver protokol OMA DM, antarmuka komputasi awan untuk EC2 Amazon, atau sistem manajemen IBM Tivoli. API manajemen terstandarisasi membuatnya sangat mudah untuk mengintegrasikan teknologi OSGi dalam sistem yang ada dan yang akan datang.

Pembaruan Dinamis - Model komponen OSGi adalah model dinamis. Bundel dapat diinstal, dimulai, dihentikan, diperbarui, dan dihapus instalasinya tanpa menjatuhkan keseluruhan sistem. Banyak pengembang Java tidak percaya ini dapat dilakukan dengan andal dan karena itu pada awalnya tidak menggunakan ini dalam produksi. Namun, setelah menggunakan ini dalam pengembangan selama beberapa waktu, sebagian besar mulai menyadari bahwa itu benar-benar berfungsi dan secara signifikan mengurangi waktu penyebaran.

Adaptif - Model komponen OSGi dirancang dari bawah ke atas untuk memungkinkan pencampuran dan pencocokan komponen. Ini mensyaratkan bahwa dependensi komponen perlu ditentukan dan memerlukan komponen untuk hidup di lingkungan di mana dependensi opsionalnya tidak selalu tersedia. Registri layanan OSGi adalah registri dinamis di mana bundel dapat mendaftar, mendapatkan, dan mendengarkan layanan. Model layanan dinamis ini memungkinkan bundel untuk mengetahui kemampuan apa yang tersedia pada sistem dan menyesuaikan fungsionalitas yang dapat mereka berikan. Ini membuat kode lebih fleksibel dan tahan terhadap perubahan.

Transparansi - Bundel dan layanan adalah warga negara kelas satu di lingkungan OSGi. API manajemen menyediakan akses ke status internal bundel serta bagaimana terhubung ke bundel lain. Sebagai contoh, sebagian besar kerangka menyediakan shell perintah yang menunjukkan keadaan internal ini. Bagian dari aplikasi dapat dihentikan untuk men-debug masalah tertentu, atau bundel diagnostik dapat dibawa masuk. Alih-alih menatap jutaan baris output logging dan waktu reboot yang lama, aplikasi OSGi sering dapat di-debug dengan shell perintah hidup.

Versi - teknologi OSGi memecahkan neraka JAR. JAR adalah masalah yang perpustakaan A bekerja dengan perpustakaan B; versi = 2, tetapi perpustakaan C hanya dapat bekerja dengan B; versi = 3. Di Jawa standar, Anda kurang beruntung. Dalam lingkungan OSGi, semua bundel diversi dengan cermat dan hanya bundel yang dapat berkolaborasi yang ditransfer bersama di ruang kelas yang sama. Ini memungkinkan bundel A dan C berfungsi dengan pustaka mereka sendiri. Meskipun tidak disarankan untuk merancang sistem dengan masalah versi ini, ini bisa menjadi penyelamat dalam beberapa kasus.

Sederhana - API OSGi ternyata sangat sederhana. API inti hanya satu paket dan kurang dari 30 kelas / antarmuka. API inti ini cukup untuk menulis bundel, menginstalnya, memulai, menghentikan, memperbarui, dan mencopotnya dan mencakup semua kelas pendengar dan keamanan. Ada sangat sedikit API yang menyediakan fungsionalitas sangat banyak untuk API yang begitu sedikit.

Kecil - Kerangka OSGi Release 4 dapat diimplementasikan dalam file JAR sekitar 300KB. Ini adalah overhead kecil untuk jumlah fungsionalitas yang ditambahkan ke aplikasi dengan memasukkan OSGi. Oleh karena itu OSGi berjalan pada sejumlah besar perangkat: dari sangat kecil, kecil, hingga mainframe. Hanya meminta Java VM minimal untuk dijalankan dan menambahkan sangat sedikit di atasnya.

Cepat - Salah satu tanggung jawab utama kerangka OSGi adalah memuat kelas dari bundel. Di Jawa tradisional, JAR sepenuhnya terlihat dan ditempatkan pada daftar linier. Pencarian kelas memerlukan pencarian melalui daftar ini (seringkali sangat panjang, 150 tidak jarang). Sebaliknya, OSGi pra-kabel bundel dan tahu untuk masing-masing bundel bundel mana yang menyediakan kelas. Kurangnya pencarian adalah faktor percepatan yang signifikan pada saat startup.

Malas - Malas dalam perangkat lunak baik dan teknologi OSGi memiliki banyak mekanisme untuk melakukan hal-hal hanya ketika mereka benar-benar dibutuhkan. Sebagai contoh, bundel dapat dimulai dengan penuh semangat, tetapi mereka juga dapat dikonfigurasi untuk hanya mulai ketika bundel lain menggunakannya. Layanan dapat didaftarkan, tetapi hanya dibuat saat digunakan. Spesifikasi telah dioptimalkan beberapa kali untuk memungkinkan jenis skenario malas yang dapat menghemat biaya runtime yang luar biasa.

Aman - Java memiliki model keamanan berbutir halus yang sangat kuat di bagian bawah tetapi ternyata sangat sulit untuk dikonfigurasi dalam praktik. Hasilnya adalah aplikasi Java yang paling aman dijalankan dengan pilihan biner: tidak ada keamanan atau kemampuan yang sangat terbatas. Model keamanan OSGi memanfaatkan model keamanan berbutir halus tetapi meningkatkan kegunaan (serta pengerasan model asli) dengan meminta pengembang bundel menentukan rincian keamanan yang diminta dalam bentuk yang mudah diaudit sementara operator lingkungan tetap sepenuhnya bertanggung jawab. Secara keseluruhan, OSGi kemungkinan menyediakan salah satu lingkungan aplikasi paling aman yang masih dapat digunakan di bawah platform komputasi yang dilindungi perangkat keras.

Non Intrusive - Aplikasi (bundel) di lingkungan OSGi dibiarkan sendiri. Mereka dapat menggunakan hampir semua fasilitas VM tanpa OSGi membatasi mereka. Praktik terbaik dalam OSGi adalah menulis Plain Old Java Objects dan untuk alasan ini, tidak ada antarmuka khusus yang diperlukan untuk layanan OSGi, bahkan objek Java String dapat bertindak sebagai layanan OSGi. Strategi ini membuat kode aplikasi lebih mudah untuk port ke lingkungan lain.

Berjalan Di Mana Saja - Ya, itu tergantung. Tujuan asli Jawa adalah menjalankan di mana saja. Jelas, tidak mungkin untuk menjalankan semua kode di mana-mana karena kemampuan Java VM berbeda. VM di ponsel kemungkinan tidak akan mendukung perpustakaan yang sama dengan mainframe IBM yang menjalankan aplikasi perbankan. Ada dua masalah yang harus diurus. Pertama, OSGi API tidak boleh menggunakan kelas yang tidak tersedia di semua lingkungan. Kedua, bundel tidak boleh dimulai jika berisi kode yang tidak tersedia di lingkungan eksekusi. Kedua masalah ini telah diurus dalam spesifikasi OSGi.

Sumber: www.osgi.org/Technology/WhyOSGi

Saya telah menemukan manfaat berikut dari OSGi:

• Setiap plugin adalah artefak berversi yang memiliki classloader sendiri.
• Setiap plugin bergantung pada guci tertentu yang dikandungnya dan juga plug-in berversi spesifik lainnya.
• Karena classloader versi dan terisolasi, versi berbeda dari artefak yang sama dapat dimuat pada saat yang sama. Jika satu komponen aplikasi Anda bergantung pada satu versi plug-in dan lainnya tergantung pada versi lain, keduanya dapat dimuat pada saat yang sama.

Dengan ini, Anda dapat menyusun aplikasi sebagai satu set artefak plugin berversi yang dimuat sesuai permintaan. Setiap plugin adalah komponen mandiri. Sama seperti Maven membantu Anda menyusun bangunan Anda sehingga dapat diulang dan ditentukan oleh satu set artefak versi spesifik yang dibuatnya, OSGi membantu Anda melakukan ini saat runtime.

Saya tidak terlalu peduli tentang hotplugability modul OSGi (setidaknya saat ini). Ini lebih merupakan modularitas yang dipaksakan. Tidak memiliki jutaan "publik" kelas yang tersedia di classpath kapan saja melindungi dengan baik dari dependensi melingkar: Anda harus benar-benar berpikir tentang antarmuka publik Anda - tidak hanya dalam hal konstruksi bahasa Jawa "publik", tetapi dalam hal perpustakaan Anda / module: Apa (tepatnya) komponen yang ingin Anda sediakan untuk orang lain? Apa (tepatnya) antarmuka (dari modul lain) yang Anda perlukan untuk mengimplementasikan fungsionalitas Anda?

Sangat menyenangkan, bahwa hotplug datang dengan itu, tetapi saya lebih suka me-restart aplikasi saya yang biasa daripada menguji semua kombinasi hotplugability ...

• Anda dapat, secara analog, mengubah motor mobil Anda tanpa mematikannya.
• Anda dapat menyesuaikan sistem yang kompleks untuk pelanggan. Lihat kekuatan Eclipse.
• Anda dapat menggunakan kembali seluruh komponen. Lebih baik dari sekadar benda.
• Anda menggunakan platform yang stabil untuk mengembangkan Aplikasi berbasis komponen. Manfaatnya sangat besar.
• Anda dapat membangun Komponen dengan konsep kotak hitam. Komponen lain tidak perlu tahu tentang antarmuka tersembunyi, mereka hanya melihat antarmuka yang diterbitkan.
• Anda dapat menggunakan dalam sistem yang sama beberapa komponen yang sama, tetapi dalam rilis yang berbeda, tanpa mengganggu aplikasi. OSGi memecahkan masalah Jar Hell.
• Dengan OSGi Anda mengembangkan pemikiran ke sistem arsitek dengan CBD

Ada banyak manfaat (saya ingatkan ini sekarang), tersedia untuk semua orang yang menggunakan Java.

diedit untuk kejelasan. Halaman OSGi memberikan jawaban sederhana yang lebih baik daripada saya

Jawaban sederhana: Platform Layanan OSGi menyediakan lingkungan komputasi standar, berorientasi komponen untuk bekerja sama layanan jaringan. Arsitektur ini secara signifikan mengurangi kerumitan keseluruhan dalam membangun, memelihara dan menggunakan aplikasi. Platform Layanan OSGi menyediakan fungsi untuk mengubah komposisi secara dinamis pada perangkat berbagai jaringan, tanpa memerlukan restart.

Dalam struktur aplikasi tunggal, katakanlah Eclipse IDE, itu bukan masalah besar untuk memulai kembali ketika Anda menginstal plugin baru. Menggunakan implementasi OSGi sepenuhnya, Anda harus dapat menambahkan plugin saat runtime, mendapatkan fungsionalitas baru, tetapi tidak harus memulai ulang gerhana sama sekali.

Sekali lagi, bukan masalah besar untuk setiap hari, penggunaan aplikasi kecil.

Tapi, ketika Anda mulai melihat multi-komputer, kerangka kerja aplikasi terdistribusi, di situlah mulai menarik. Ketika Anda harus memiliki waktu aktif 100% untuk sistem kritis, kemampuan untuk hotswap komponen atau menambah fungsionalitas baru saat runtime berguna. Memang, ada kemampuan untuk melakukan ini sekarang untuk sebagian besar, tetapi OSGi berusaha untuk menggabungkan semuanya menjadi kerangka kecil yang bagus dengan antarmuka umum.

Apakah OSGi memecahkan masalah umum, saya tidak yakin tentang itu. Maksud saya, itu bisa, tetapi overhead mungkin tidak sepadan untuk masalah yang lebih sederhana. Tapi itu sesuatu yang perlu dipertimbangkan ketika Anda mulai berurusan dengan aplikasi yang lebih besar, jaringan,.

Beberapa Hal yang membuat saya gila di OSGi:

1) Implentasi dan pemuat konteksnya memiliki banyak keanehan pada mereka, dan bisa agak asink (Kami menggunakan felix di dalam pertemuan). Dibandingkan dengan pegas murni (tanpa DM) di mana [utama] cukup banyak menjalankan sinkronisasi semuanya.

2) Kelas tidak sama setelah beban panas. Katakanlah, misalnya Anda memiliki lapisan cache tangosol di hibernate. Itu diisi dengan Fork.class, di luar lingkup OSGi. Anda men-download tabung baru, dan Fork belum berubah. Kelas [Garpu]! = Kelas [Garpu]. Itu juga muncul selama serialisasi, untuk penyebab mendasar yang sama.

3) Clustering.

Anda dapat mengatasi hal-hal ini, tetapi itu adalah rasa sakit yang besar, dan membuat arsitektur Anda terlihat cacat.

Dan bagi Anda yang mengiklankan hotplugging .. Klien # 1 OSGi? Gerhana. Apa yang dilakukan Eclipse setelah memuat bundel?

Memulai kembali.

OSGi membuat kode Anda dibuang NoClassDefFoundErrordan ClassNotFoundExceptiontanpa alasan yang jelas (kemungkinan besar karena Anda lupa mengekspor paket dalam file konfigurasi OSGi); karena memiliki ClassLoaders, itu dapat membuat kelas Anda com.example.Foogagal untuk dilemparkan ke com.example.Fookarena itu sebenarnya dua kelas yang berbeda dimuat oleh dua kelas yang berbeda. Itu dapat membuat Eclipse boot ke konsol OSGi setelah menginstal plugin Eclipse.

Bagi saya, OSGi hanya menambahkan kompleksitas (karena menambahkan satu lagi model mental bagi saya untuk grok), menambahkan gangguan karena pengecualian; Saya tidak pernah benar-benar membutuhkan dinamika yang "menawarkan". Itu mengganggu karena memerlukan konfigurasi bundel OSGi untuk semua modul; itu jelas tidak sederhana (dalam proyek yang lebih besar).

Karena pengalaman buruk saya, saya cenderung menjauh dari monster itu, terima kasih banyak. Saya lebih suka menderita neraka ketergantungan jar, karena cara itu lebih mudah dimengerti daripada neraka classloader yang diperkenalkan OSGi.

Saya belum menjadi "penggemar" OSGi ...

Saya telah bekerja dengan aplikasi perusahaan di perusahaan Fortune 100. Baru-baru ini, produk yang kami gunakan telah "ditingkatkan" ke implementasi OSGi.

memulai penyebaran CBA lokal ... [18/02/14 8: 47: 23: 727 EST] 00000347 CheckForOasis

akhirnya dikerahkan dan "bundel berikut akan dikosongkan dan kemudian dimulai kembali" [2/18/14 9: 38: 33: 108 EST] 00000143 AriesApplicat I CWSAI0054I: Sebagai bagian dari operasi pembaruan untuk aplikasi

51 menit ... setiap perubahan kode waktu ... Versi sebelumnya (non-OSGi) akan digunakan dalam waktu kurang dari 5 menit pada mesin pengembangan yang lebih lama.

pada mesin dengan ram 16 manggung dan 40 manggung disk gratis dan Intel i5-3437U CPU 1,9 GHz

"Manfaat" dari peningkatan ini dijual sebagai peningkatan (produksi) penyebaran - suatu kegiatan yang kami lakukan sekitar 4 kali setahun dengan mungkin 2-4 penyebaran kecil perbaikan setahun. Menambahkan 45 menit per hari menjadi 15 orang (QA dan pengembang) Saya tidak bisa membayangkan dibenarkan. Dalam aplikasi perusahaan besar, jika aplikasi Anda adalah aplikasi inti, maka mengubahnya, memang demikian (perubahan kecil memiliki potensi dampak yang jauh - harus dikomunikasikan dan direncanakan dengan konsumen di seluruh perusahaan), aktivitas monumental - arsitektur yang salah untuk OSGi. Jika aplikasi Anda bukan aplikasi perusahaan - yaitu masing-masing konsumen dapat memiliki modul khusus mereka sendiri yang kemungkinan besar mengenai silo data mereka sendiri dalam basis data silo sendiri dan berjalan di server yang menampung banyak aplikasi, maka mungkin lihatlah OSGi. Setidaknya,

Jika aplikasi berbasis Java memerlukan penambahan atau penghapusan modul (memperluas fungsionalitas basis aplikasi), tanpa mematikan JVM, OSGI dapat digunakan. Biasanya jika biaya mematikan JVM lebih banyak, hanya untuk memperbarui atau meningkatkan fungsionalitas.

Contoh :

1. Eclipse : Menyediakan platform bagi plugin untuk diinstal, dihapus, diperbarui, dan saling bergantung.
2. AEM : Aplikasi WCM, di mana perubahan fungsionalitas akan didorong oleh bisnis, yang tidak mampu mengurangi waktu pemeliharaan.

Catatan : Kerangka pegas berhenti mendukung bundel pegas OSGI, menganggapnya sebagai kompleksitas yang tidak perlu untuk aplikasi berbasis transaksi atau untuk beberapa titik di baris ini. Saya pribadi tidak mempertimbangkan OSGI kecuali benar-benar diperlukan, dalam hal besar seperti membangun platform.

Saya telah melakukan pekerjaan dengan OSGi hampir 8 tahun atau lebih dan saya harus mengatakan bahwa Anda harus mempertimbangkan OSGi hanya jika Anda memiliki kebutuhan bisnis untuk memperbarui, menghapus, menginstal atau mengganti komponen saat runtime. Ini juga berarti bahwa Anda harus memiliki pola pikir modular dan memahami apa arti modularitas. Ada beberapa argumen bahwa OSGi ringan - ya, itu benar tetapi ada juga beberapa kerangka kerja yang ringan dan lebih mudah untuk dirawat dan dikembangkan. Hal yang sama berlaku untuk mengamankan java bla bla.

OSGi membutuhkan arsitektur yang solid untuk digunakan dengan benar dan cukup mudah untuk membuat OSGi-sistem yang bisa dengan mudah menjadi toples yang dapat dijalankan sendiri tanpa melibatkan OSGi.

OSGi memberikan manfaat sebagai berikut:

■ Lingkungan eksekusi portabel dan aman berdasarkan Java

■ Sistem manajemen layanan, yang dapat digunakan untuk mendaftar dan berbagi layanan di seluruh bundel dan memisahkan penyedia layanan dari konsumen layanan

■ Sistem modul dinamis, yang dapat digunakan untuk menginstal dan menghapus instalasi modul Java secara dinamis, yang oleh OSGi disebut bundel

■ Solusi yang ringan dan terukur

Ini juga digunakan untuk membawa portabilitas tambahan middleware dan aplikasi di sisi mobile. Sisi seluler tersedia untuk WinMo, Symbian, Android misalnya. Segera setelah integrasi dengan fitur perangkat terjadi, dapat terfragmentasi.

Paling tidak, OSGi membuat Anda BERPIKIR tentang modularitas, penggunaan kembali kode, versi dan secara umum pipa proyek.

Yang lain telah menguraikan manfaatnya secara rinci, dengan ini saya menjelaskan penggunaan praktis yang saya lihat atau gunakan OSGi.

1. Di salah satu aplikasi kami, kami memiliki aliran berdasarkan peristiwa dan aliran didefinisikan dalam plugin berbasis pada platform OSGi jadi besok jika beberapa klien menginginkan aliran berbeda / tambahan maka ia hanya perlu menggunakan satu plugin lagi, konfigurasikan dari konsol kami dan ia selesai .
2. Ini digunakan untuk memasang konektor Store yang berbeda, misalnya, misalkan kita sudah memiliki konektor Oracle DB dan besok mongodb diharuskan untuk terhubung kemudian menulis konektor baru dan menyebarkannya dan mengkonfigurasi detail melalui konsol dan lagi Anda selesai. penyebaran konektor ditangani oleh kerangka kerja plugin OSGi.

Sudah ada pernyataan yang cukup meyakinkan di situs resminya, saya kutip sebagai

Alasan utama teknologi OSGi begitu sukses adalah karena ia menyediakan sistem komponen yang sangat matang yang benar-benar bekerja di sejumlah lingkungan yang mengejutkan. Sistem komponen OSGi sebenarnya digunakan untuk membangun aplikasi yang sangat kompleks seperti IDE (Eclipse), server aplikasi (GlassFish, IBM Websphere, Oracle / BEA Weblogic, Jonas, JBoss), kerangka kerja aplikasi (Spring, Guice), otomasi industri, gateway perumahan, telepon, dan banyak lagi.

Adapun manfaat bagi pengembang?

DEVELOPERS: OSGi mengurangi kompleksitas dengan menyediakan arsitektur modular untuk sistem terdistribusi skala besar saat ini serta aplikasi kecil yang tertanam. Membangun sistem dari modul in-house dan off-the-shelf secara signifikan mengurangi kompleksitas dan dengan demikian biaya pengembangan dan pemeliharaan. Model pemrograman OSGi mewujudkan janji sistem berbasis komponen.

Silakan periksa detail di Manfaat Menggunakan OSGi .