Memahami Konsep OSGi. Coba Ikuti Pendekatan Puzzle

Diterbitkan: 2013-04-20

OSGi menjadi sangat populer saat ini, berkat pendekatan modularitasnya dan kemampuannya untuk menegakkan batasan logis antar modul. Ketika kita pertama kali menemukannya, pertanyaannya adalah dari mana kita harus mulai memahami cara kerjanya?

Untuk memahami konsep OSGi kami akan mencoba mengikuti pendekatan teka-teki, idenya adalah untuk memulai dengan bagian sepele dari teknologi ini, dan mencari bagian lain yang terkait dengan yang ditemukan. Dan untuk merakit puzzle kita akan dibantu oleh JArchitect yang akan membantu untuk mendeteksi desain internal OSGi.

Untuk lebih konkrit kami menganalisa dengan JArchitect sebuah aplikasi yang menggunakan teknologi OSGi, ini menyangkut Eclipse IDE yang terkenal yang menggunakan OSGi container equinox.

Mari kita mulai dengan definisi khas OSGi:

OSGi mengurangi kompleksitas dengan menyediakan arsitektur modular untuk sistem terdistribusi skala besar saat ini serta aplikasi kecil yang disematkan. 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.

Bagian sepele dari OSGi adalah modularitas, mari kita cari tahu apa modul OSGi?

Modul OSGI disebut Bundel dan oleh karena itu setiap aplikasi terdiri dari setidaknya satu bundel.
Bundel ini dieksekusi di dalam wadah, dan karena setiap pendekatan modular di mana wadah mengelola modul, pertanyaannya adalah kontrak mana yang harus mengimplementasikan setiap modul untuk diintegrasikan ke dalam wadah?

Mari kita ambil contoh bundel org.Eclipse.equinox.jsp.jasper dan mencari semua antarmuka yang diimplementasikan, untuk itu kita dapat menjalankan permintaan CQLinq berikut:

gerhana4

Antarmuka BundleActivator dari paket OSGi diimplementasikan, antarmuka ini berisi dua metode mulai dan berhenti yang berguna untuk menyesuaikan awal dan penghentian bundel.

Kekhususan lain dari bundel adalah file manifesnya, inilah bagian dari file manifes org.Eclipse.equinox.jsp.jasper:

Seperti yang dapat kita amati, manifes ini berisi beberapa informasi meta yang dibutuhkan oleh container, seperti menentukan kelas bundle activator yang mengimplementasikan antarmuka BundleActivator.

Bundel tersebut mewakili potongan teka-teki pertama kami, dan inilah representasi bundel yang disederhanakan:

gerhana7

Dan hanya untuk mengetahui semua bundel yang digunakan oleh Eclipse, mari cari semua kelas yang mengimplementasikan antarmuka BundleActivator.

gerhana2

Siapa yang mengelola bundel dan memanggil metode BundleActivator?

Untuk mengetahuinya, mari cari metode yang memanggil secara langsung atau tidak langsung BundleActivator.start

gerhana6

Bundel ini diaktifkan oleh kerangka kerja OSGi saat diluncurkan. Kelas kerangka kerja dimulai oleh wadah ekuinoks. Dan untuk lebih memahami apa yang terjadi saat container dimulai, berikut adalah beberapa tindakan yang dijalankan saat container diluncurkan:

gerhana31

Ketika wadah diluncurkan, itu menginisialisasi kerangka OSGi, kerangka kerja mendapatkan semua bundel yang diinstal, dan untuk masing-masing itu membuat instance kelas BundleHost, dan menyimpan ke dalam repositori bundel yang ditemukan.

Kelas BundleHost mengimplementasikan antarmuka Bundle, yang berisi metode seperti start, stop, uninstall, dan update, metode ini diperlukan untuk mengelola siklus hidup bundel.

Jadi potongan teka-teki kedua kami adalah wadah OSGi, diluncurkan oleh Equinoxlauncher, yang menginisialisasi kerangka kerja. Kelas kerangka kerja bertanggung jawab memuat bundel dan mengaktifkannya.

Setelah menemukan beberapa konsep dasar tentang bundel dan wadah, mari masuk ke dalam bundel dan temukan cara kerjanya secara internal.

Mari kita ambil contoh bundel org.Eclipse.equinox.http.servlet dan cari metode yang dipanggil oleh metode start dari kelas Activatornya.

gerhana1

Bundel ini membuat layanan dan mendaftarkannya ke dalam wadah. Layanan di OSGi didefinisikan oleh kelas atau antarmuka Java standar. Biasanya antarmuka Java digunakan untuk mendefinisikan antarmuka layanan. Layanan adalah metode pilihan yang harus digunakan bundel untuk berkomunikasi antara satu sama lain.

Berikut adalah beberapa skenario yang berguna dalam menggunakan layanan:

  • Fungsi ekspor dari bundel ke bundel lain.
  • Impor fungsionalitas dari bundel lain.
  • Daftarkan pendengar untuk acara dari bundel lain.

Komentar lain dari grafik ketergantungan sebelumnya adalah bahwa pabrik layanan digunakan untuk membuat instance layanan.

Bagian ketiga dari teka-teki kami adalah lapisan layanan OSGi, setiap bundel dapat menggunakan atau mendeklarasikan beberapa layanan, yang menerapkan pendekatan desain komponen, inilah representasi baru dari bundel OSGi.

gerhana8

Jika bundel menggunakan layanan untuk berkomunikasi dengan bundel lain, bagaimana ia berkomunikasi dengan toples lain?

Jika kami mengembangkan bundel dan mencoba menggunakan kelas dari toples lain, kami akan terkejut bahwa itu tidak akan berfungsi seperti yang diharapkan, alasannya adalah bahwa ClassLoader terhubung dengan wadah OSGi, untuk memeriksa apakah mari kita cari metode mana yang memanggil Java. lang.Thread.setContextClassLoader.

gerhana9

Banyak metode yang memanggilnya termasuk EquinoxLauncher. jadi setiap kali bundel mencoba membuat instance kelas, wadah OSGi akan memeriksa apakah kode diizinkan untuk melakukan tindakan ini atau tidak, dan inilah peran paket yang diimpor dan diekspor dalam file manifes.

Bundel tersebut mendeklarasikan paket yang diekspor dan diimpor secara eksplisit, dan untuk memeriksanya, mari cari paket yang digunakan oleh bundel org.Eclipse.equinox.http.servlet dan verifikasi apakah paket tersebut hanya menggunakan paket yang diimpor.

gerhana10

Seperti yang dapat kita amati, semua paket yang digunakan ditentukan dalam file manifes, di bagian paket impor.
Namun paket yang diekspor mewakili paket yang dapat digunakan dari bundel lain. itu diwakili oleh antarmuka ExportedPackage, dan kita dapat mencari kelas kontainer menggunakan antarmuka ini.

gerhana12

Apa yang menarik dengan kemampuan baru ini, adalah bahwa bundel akan memiliki batas yang jelas, dan apa yang digunakan dan apa yang diekspos sebagai layanan ditentukan dengan sangat baik.

Kami dapat menerapkan pemeriksaan menggunakan paket yang diimpor dengan menggunakan alat lain, misalnya dengan CQLinq kami dapat menulis beberapa aturan peringatan setiap kali proyek menggunakan paket selain yang ditentukan, tetapi lebih baik untuk memeriksa ini di lingkungan eksekusi, jadi pengembang tidak dapat melanggar aturan ini.

Kemampuan untuk menangani paket yang diimpor dan diekspor ini dikelola oleh lapisan modul OSGi dan ini adalah bagian keempat dari teka-teki kami.

Mari kembali ke wadah OSGi dan temukan layanan mana yang disediakannya?

Layanan kontainer

Seperti yang kami temukan sebelum wadah diluncurkan oleh kelas EquinoxLauncher dan kelas kerangka kerja menginisialisasi dan meluncurkan bundel, untuk mendeteksi layanan mana yang disediakan, mari cari semua kelas yang digunakan dalam metode inisialisasi kerangka kerja.

gerhana11

Beberapa kelas sudah ditemukan sebelumnya seperti BundleRepository,BundleHost,PackageAdminImpl dan ServiceRegistry.

Bagaimana dengan kelas lainnya:

  • Manajer Tingkat Awal:
    Setiap Bundel OSGi dikaitkan dengan level awal yang memungkinkan server mengontrol urutan awal dan penghentian relatif dari bundel. Hanya bundel yang memiliki level awal kurang atau sama dengan level awal aktif kerangka kerja server yang harus aktif. Biasanya, bundel dengan level awal yang lebih kecil cenderung dimulai lebih awal.
  • KeamananAdmin:
    Lapisan keamanan menangani aspek keamanan dengan membatasi fungsionalitas bundel ke kemampuan yang telah ditentukan sebelumnya.
  • Pengelola acara:
    Layanan Event Admin menyediakan model publish-subscribe untuk menangani event. Hal ini diwujudkan sesuai dengan Spesifikasi Layanan Admin Acara OSGi. Layanan Admin Acara mengirimkan acara antara Penerbit Acara dan Pelanggan Acara (Penangan Acara) dengan menyisipkan saluran acara. Penerbit memposting acara ke saluran dan saluran acara menentukan penangan mana yang perlu diberi tahu. Jadi penerbit dan penangan tidak memiliki pengetahuan langsung satu sama lain, yang menyederhanakan manajemen acara.

Seluruh gambar OSGi

Mari kita kumpulkan semua potongan puzzle yang dijelaskan sebelumnya, dan kita akan memiliki gambar OSGi berikut:
layering-osgi

Arsitektur ini memiliki manfaat menarik sebagai berikut:

  • Sederhana.
  • Kompleksitas Berkurang.
  • Penerapan yang Mudah.
  • Aman.

Apa yang membuatnya sangat menarik dan Layak untuk Diputar, dan Anda tidak akan membuang waktu Anda jika Anda mempelajarinya secara mendalam.