Open Service Gateway Initiative (OSGI)
OSGi Alliance yang independen merupakan lembaga nirlaba yang terdiri dari inovator dan pengembang teknologi dan fokus pada interoperabilitas aplikasi dan layanan yang berbasis pada integrasi komponen platform.
OSGi teknologi adalah sistem modul dinamis untuk Java ™
Teknologi OSGi Universal Middleware. OSGi teknologi menyediakan layanan berorientasi, komponen berbasis lingkungan untuk para pengembang dan menawarkan cara-cara standar untuk mengelola siklus hidup perangkat lunak. Kemampuan ini sangat meningkatkan nilai berbagai komputer dan perangkat yang menggunakan platform Java.
Dibentuk pada tahun 1999, Aliansi OSGi awalnya berfokus pada solusi untuk Embedded Jawa dan perangkat jaringan pasar. Akibatnya teknologi OSGi telah diterapkan dan digunakan dalam produk dan solusi di seluruh dunia dan di berbagai pasar. Saat ini, teknologi OSGi juga menikmati penerimaan luas dalam komunitas Open Source, seperti yang ditunjukkan oleh Apache Derby Felix dan proyek-proyek, Eclipse Callisto, Equinox dan proyek-proyek Corona, OSCAR, Knopflerfish, dan lain-lain. Akibatnya inti teknologi OSGi kini semakin lazim di Enterprise, dan juga dipandang sebagai komponen kunci dari generasi berikutnya Layanan Java Platform dinamis yang memungkinkan penggelaran layanan Web 2.0 dan mashup.
Pengadopsi teknologi OSGi manfaat dari peningkatan waktu ke pasar dan mengurangi biaya pengembangan karena teknologi OSGi menyediakan integrasi pra-dibangun dan pra-komponen subsistem diuji. Teknologi ini juga mengurangi biaya pemeliharaan dan kemajuan aftermarket baru peluang unik karena jaringan dapat dimanfaatkan untuk secara dinamis mengupdate atau memberikan layanan dan aplikasi di lapangan
OSGi Alliance Keanggotaan
Anggota OSGi Alliance membantu mengembangkan platform integrasi komponen spesifikasi, implementasi referensi, test suite dan program-program sertifikasi. Selain sponsor Aliansi pengembangan pasar, pendidikan dan program-program penghubung, dan mempromosikan pembentukan Forum Pengguna di seluruh dunia untuk mengembangkan global industri lintas ekosistem.
The OSGi Arsitektur
Teknologi yang OSGi adalah seperangkat spesifikasi yang mendefinisikan sistem komponen dinamis untuk Java. Spesifikasi ini memungkinkan suatu model pengembangan aplikasi di mana (dinamis) terdiri dari banyak berbeda (reusable) komponen. Spesifikasi yang memungkinkan komponen OSGi untuk menyembunyikan implementasi dari komponen lain saat berkomunikasi melalui layanan, yang merupakan objek yang secara khusus dibagi antara komponen. Mengherankan model sederhana ini telah mencapai jauh efek untuk hampir semua aspek dari proses pengembangan perangkat lunak.
Meskipun komponen telah di cakrawala untuk waktu yang lama, sejauh ini mereka gagal untuk membuat baik pada janji-janji mereka. OSGi adalah teknologi pertama yang benar-benar berhasil dengan sistem komponen yang memecahkan banyak masalah nyata dalam pengembangan software. Adopter dari teknologi OSGi melihat kerumitan berkurang secara signifikan di hampir semua aspek pembangunan. Kode lebih mudah untuk menulis dan menguji, menggunakan kembali meningkat, membangun sistem menjadi sangat sederhana, penyebaran lebih mudah dikelola, bug terdeteksi lebih awal, dan runtime memberikan wawasan yang sangat besar apa yang sedang berjalan. Paling penting, ia bekerja seperti yang dibuktikan oleh adopsi yang luas dan populer digunakan dalam aplikasi seperti Eclipse dan Spring.
Kami mengembangkan teknologi OSGi untuk menciptakan sebuah lingkungan perangkat lunak kolaboratif. Kami tidak mencari kemungkinan untuk menjalankan beberapa aplikasi dalam satu VM. Aplikasi server sudah melakukan itu (walaupun mereka belum sekitar ketika kita mulai tahun 1998). Tidak, masalah kita lebih sulit. Kami ingin aplikasi yang muncul dari menyatukan berbagai komponen dapat digunakan kembali yang tidak memiliki pengetahuan a-priori satu sama lain. Bahkan lebih keras, kita ingin bahwa aplikasi untuk merakit secara dinamis muncul dari seperangkat komponen. Sebagai contoh, Anda memiliki rumah server yang mampu mengelola lampu dan peralatan Anda. Sebuah komponen dapat memungkinkan Anda untuk menghidupkan dan mematikan lampu di atas halaman web. Komponen lain bisa memungkinkan Anda untuk mengontrol peralatan mobile melalui pesan teks. Tujuannya adalah untuk mengizinkan fungsi-fungsi lain tersebut akan ditambahkan tanpa memerlukan bahwa pengembang telah rumit pengetahuan satu sama lain dan membiarkan komponen ini akan ditambahkan secara independen.
Layering
Yang berlapis-lapis OSGi memiliki model yang digambarkan dalam gambar berikut.
Daftar berikut berisi definisi singkat dari istilah:
• Kumpulan – Kumpulan adalah komponen OSGi yang dibuat oleh pengembang.
• Jasa – Layanan bundel menghubungkan lapisan dalam cara yang dinamis dengan menawarkan menerbitkan-menemukan-model mengikat Jawa lama untuk menikmati objek.
• Life-Siklus – The API untuk instalasi, start, stop, update, dan menghapus bundel.
• Modul – Lapisan yang mendefinisikan bagaimana sebuah bungkusan dapat mengimpor dan mengekspor kode.
• Keamanan – Lapisan yang menangani aspek keamanan.
• Pelaksanaan Lingkungan – Tetapkan apa yang metode dan kelas-kelas yang tersedia dalam platform tertentu.
Konsep ini lebih luas dijelaskan dalam bagian berikut.
Modul
Konsep dasar yang memungkinkan sistem seperti ini adalah modularitas. Modularitas, simplistically berkata, adalah tentang dengan asumsi kurang. Modularitas adalah tentang menjaga hal-hal lokal dan tidak berbagi. Sulit untuk keliru tentang hal-hal yang tidak memiliki pengetahuan dan tidak membuat asumsi tentang mereka. Oleh karena itu, modularitas merupakan inti dari spesifikasi OSGi dan diwujudkan dalam konsep bundel. Dalam istilah Jawa, sebuah kemasan adalah dataran JAR tua. Namun, di mana di Jawa standar segalanya dalam JAR benar-benar dapat dilihat oleh semua guci lain, OSGi menyembunyikan segala sesuatu dalam JAR, kecuali secara eksplisit diekspor. Sebuah bundel yang ingin menggunakan JAR lain harus secara eksplisit mengimpor bagian-bagian yang dibutuhkan. Secara default, tidak ada berbagi.
Meskipun kode bersembunyi dan berbagi eksplisit memberikan banyak manfaat (misalnya, yang memungkinkan beberapa versi dari library yang sama yang digunakan dalam satu VM), kode berbagi hanya ada untuk mendukung layanan OSGi model. Model layanan tentang kumpulan yang berkolaborasi.
Layanan
Alasan kita membutuhkan layanan model ini adalah karena Jawa menunjukkan betapa sulitnya menulis model kolaboratif dengan kelas hanya berbagi. Solusi standar di Jawa adalah dengan menggunakan pabrik-pabrik yang menggunakan kelas dinamis pemuatan dan statika. Sebagai contoh, jika Anda ingin DocumentBuilderFactory, Anda memanggil metode DocumentBuilderFactory pabrik statis. NewInstance (). Di balik façade, metode yang newInstance setiap kelas loader mencoba trik dalam buku (dan beberapa yang tidak) untuk membuat sebuah instance dari sebuah implementasi DocumentBuilderFactory subkelas dari kelas. Mencoba mempengaruhi pelaksanaan apa yang digunakan adalah non-sepele (model jasa, properti, konvensi di nama kelas), dan biasanya global untuk VM. Juga itu adalah model pasif. Kode pelaksanaan tidak bisa berbuat apa-apa untuk mengiklankan ketersediaannya, atau dapat daftar pengguna yang mungkin memilih implementasi dan implementasi yang paling cocok. Juga tidak dinamis. Setelah tangan keluar penerapan sebuah contoh, ia tidak bisa menarik objek. Terburuk, pabrik mekanisme konvensi digunakan di ratusan tempat di VM di mana setiap pabrik unik memiliki API dan mekanisme konfigurasi. Tidak ada tersentralisasi ikhtisar implementasi yang terikat kode Anda.
Solusi untuk semua masalah ini adalah layanan OSGi registri. Sebuah bundel dapat menciptakan sebuah benda dan mendaftarkannya dengan layanan OSGi registri di bawah satu atau lebih interface. Kumpulan lain bisa pergi ke registri dan daftar semua objek yang terdaftar di bawah antarmuka khusus atau kelas. Sebagai contoh, sebuah kemasan memberikan pelaksanaan DocumentBuilder. Ketika dijalankan, itu menciptakan sebuah instance dari kelas dan mendaftarkan DocumentBuilderFactoryImpl dengan registri di bawah kelas DocumentBuilderFactory. Sebuah bundel yang memerlukan DocumentBuilderFactory bisa pergi ke registri dan meminta untuk semua layanan yang tersedia yang memperpanjang DocumentBuilderFactory kelas. Bahkan lebih baik, sebuah kemasan dapat menunggu untuk layanan tertentu untuk muncul dan kemudian mendapatkan panggilan kembali.
Sebuah bundel demikian bisa mendaftar layanan, itu bisa mendapatkan layanan, dan dapat mendengarkan layanan untuk muncul atau menghilang. Sejumlah bundel dapat mendaftar jenis layanan yang sama, dan sejumlah bundel bisa mendapatkan layanan yang sama.
Ini digambarkan dalam gambar berikut.
Apa yang terjadi bila beberapa kumpulan objek mendaftar di bawah antarmuka yang sama atau kelas? Bagaimana ini dapat dibedakan? Jawabannya adalah properti. Setiap layanan registrasi memiliki seperangkat standar dan adat properti. Sebuah bahasa filter ekspresif tersedia hanya untuk memilih layanan yang Anda minati. Sifat dapat digunakan untuk mencari layanan yang tepat atau dapat memainkan peran lain di tingkat aplikasi.
Layanan bersifat dinamis. Ini berarti bahwa sebuah kemasan dapat memutuskan untuk menarik layanan dari registri sementara kumpulan lain masih menggunakan layanan ini. Kumpulan menggunakan layanan tersebut kemudian harus memastikan bahwa mereka tidak lagi menggunakan layanan objek dan jatuhkan referensi apapun. Kami tahu, ini terdengar seperti kompleksitas yang signifikan, tetapi ternyata bahwa kelas penolong seperti Tracker Layanan dan kerangka kerja seperti iPOJO, Spring, dan Layanan deklaratif dapat membuat rasa sakit yang minimal, sementara keuntungan yang cukup besar. Dinamika layanan ditambahkan sehingga kami dapat menginstal dan menghapus buntalan on the fly sementara kumpulan lain bisa beradaptasi. Itu adalah, sebuah kemasan dapat tetap memberikan fungsionalitas bahkan jika layanan http pergi. Namun, kami mengetahui dari waktu ke waktu bahwa dunia nyata yang dinamis dan banyak masalah yang jauh lebih mudah untuk model dengan layanan dinamis daripada statis pabrik. Sebagai contoh, sebuah layanan Device dapat mewakili salah satu perangkat pada jaringan lokal. Jika perangkat hilang, mewakili layanan ini tidak terdaftar. Dengan cara ini, ketersediaan model-model layanan ketersediaan entitas dunia nyata. Ini berhasil sangat baik dalam, misalnya, model OSGi terdistribusi di mana layanan ini dapat ditarik jika koneksi ke mesin remote hilang. Hal ini juga ternyata bahwa dinamika memecahkan masalah inisialisasi. OSGi aplikasi tidak memerlukan memulai tertentu memesan dalam bundel.
Efek dari registri layanan telah banyak API khusus bisa jauh model layanan dengan registri. Hal ini tidak hanya menyederhanakan aplikasi secara keseluruhan, hal itu juga berarti bahwa alat-alat standar dapat digunakan untuk debug dan melihat bagaimana sistem kabel atas.
Meskipun registri layanan menerima objek apapun sebagai layanan, cara terbaik untuk mencapai adalah dengan mendaftar menggunakan kembali objek-objek ini di bawah (standar) antarmuka untuk decouple pelaksana dari kode klien. Ini adalah alasan Aliansi OSGi menerbitkan spesifikasi Compendium. Spesifikasi ini mendefinisikan jumlah besar layanan standar, dari Layanan log ke Negara Pengukuran dan spesifikasi. Semua layanan standar ini dijelaskan dengan sangat rinci.
Deployment
Kumpulan dikerahkan pada kerangka OSGi, bungkusan lingkungan runtime. Ini bukan sebuah wadah seperti Java Application Server. Ini adalah sebuah lingkungan kolaboratif. Bundel menjalankan VM yang sama dan dapat benar-benar berbagi kode. Kerangka menggunakan eksplisit impor dan ekspor untuk memasang sebuah buntalan sehingga mereka tidak perlu menyibukkan diri dengan kelas loading. Kontras lain dengan aplikasi server adalah bahwa pengelolaan kerangka kerja standar. API sederhana memungkinkan kumpulan untuk menginstal, start, stop, dan memperbarui kumpulan lainnya, serta pencacahan buntalan dan penggunaan layanan mereka. API ini telah digunakan oleh banyak agen manajemen untuk mengendalikan kerangka OSGi. Manajemen agen sangatlah beragam sebagai Knopflerfish desktop dan manajemen Tivoli IBM server.
Implementasi
Spesifikasi OSGi proses yang membutuhkan referensi spesifikasi implementasi untuk masing-masing. Namun, karena spesifikasi pertama selalu ada perusahaan komersial yang telah menerapkan spesifikasi serta implementasi open source. Saat ini, terdapat 4 open source implementasi dari kerangka dan terlalu banyak untuk menghitung implementasi dari layanan OSGi. Industri perangkat lunak yang terbuka telah menemukan teknologi OSGi dan semakin banyak proyek artefak menyampaikan sebagai kumpulan.
Spesifikasi OSGi License, Versi 1.0.
The OSGi Alliance ( “OSGi Alliance”) dengan ini memberikan kepada Anda dibayar penuh, non-eksklusif, tidak dapat dialihkan, di seluruh dunia, lisensi terbatas (tanpa hak untuk mensublisensikan), di bawah Aliansi OSGi hak kekayaan intelektual yang berlaku untuk melihat, mendownload, dan mereproduksi OSGi Spesifikasi ( “Spesifikasi”) yang mengikuti Perjanjian Lisensi ini ( “Perjanjian”). Anda tidak diizinkan untuk menciptakan karya turunan dari Spesifikasi. OSGi Alliance yang juga memberikan kepada Anda terus-menerus, non-eksklusif, di seluruh dunia, disetor penuh, bebas royalti, lisensi terbatas (tanpa hak untuk mensublisensikan) di bawah hak cipta yang berlaku, untuk menciptakan dan / atau mendistribusikan pelaksanaan Spesifikasi bahwa:
(i) benar-benar mengimplementasikan Spesifikasi termasuk semua antarmuka dan fungsionalitas yang diperlukan,
(ii) tidak mengubah, subset, superset atau memperpanjang Nama OSGi Space, atau menyertakan publik atau dilindungi setiap paket, kelas, Jawa antarmuka, ladang atau metode dalam Ruang Nama yang OSGi selain yang dibutuhkan dan disahkan oleh Spesifikasi. Penerapan yang tidak memuaskan keterbatasan
(i) – (ii) tidak dianggap sebagai pelaksanaan Spesifikasi, tidak mendapatkan keuntungan dari lisensi ini, dan tidak boleh digambarkan sebagai pelaksanaan Spesifikasi. Sebuah pelaksanaan Spesifikasi tidak boleh mengklaim sebagai pelaksanaan sesuai Spesifikasi kecuali melewati Pengujian Kepatuhan Aliansi OSGi untuk Spesifikasi sesuai dengan proses OSGi Alliance. “Nama OSGi Space” akan berarti kelas publik atau deklarasi interface yang namanya dimulai dengan “org.osgi” diakui atau penggantinya atau penggantian daripadanya.
SUMBER : http://adhek09.wordpress.com/2009/11/30/open-service-gateway-initiative-osgi/
