TELEMATIKA 2

Arsitektur Client-Server Telematika

Arsitektur Client Side
Merujuk pada pelaksanaan data pada browser sisi koneksi HTTP. JavaScript adalah sebuah contoh dari sisi eksekusi client dan contoh dari sisi penyimpanan pada client adalah cookie.

Karakteristik :
- Memulai terlebih dahulu permintaan ke server.
- Menunggu dan menerima balasan.
- Terhubung ke sejumlah kecil server pada waktu tertentu.
- Berinteraksi langsung dengan pengguna akhir, dengan menggunakan GUI.

Arsitektur Server Side
Pada server side, ada sebuah server Web khusus yang bertugas mengeksekusi perintah dengan menggunakan standar metode HTTP. Misalnya penggunaan CGI script pada sisi server yang mempunyai tag khusus yang tertanam di halaman HTML. Tag ini memicu terjadinya perintah untuk mengeksekusi.

Karakteristik :
- Menunggu permintaan dari salah satu client.
- Melayani permintaan klien dan menjawab sesuai data yang diminta oleh client.
- Suatu server dapat berkomunikasi dengan server lain untuk melayani permintaan client.
- Jenis-jenisnya : web server, FTP server, database server, E-mail server, file server, print server.

Secara umum Arsitektur Client-Server merupakan sebuah aplikasi terdistribusi yang bertugas untuk mempartisi atau membagi pekerjaan antara server(penyedia layanan) dan client. Client dan server sering juga beroperasi menggunakan jaringan komputer pada hardware yang terpisah. Server adalah sebuah mesin yang memiliki performa tinggi dan menjalankan satu atau lebih program untuk memberikan data-data pada client. Sebuah client tidak mempunyai sumber daya apapun, namun meminta server untuk menyediakan sumber daya yang diperlukan. Oleh karena itu clientlah yang terlebih dahulu memulai sesi komunikasi dengan server yang menunggu request dari clientnya.

Dalam perkembangannya, client dan server dikembangkan oleh berbagai perusahaan software besar seperti Lotus, Microsoft, Novell, Baan, Informix, Oracle, PeopleSoft, SAP, Sun, dan Sybase. Perusahaan-perusahaan ini adalah superstar pada era pertama dimunculkannya konsep client dan server. Saat ini perusahaan-perusahaan tersebut telah menjadi perusahaan komputer yang stabil dan besar.

Dibawah ini merupakan penjelasan tentang beberapa kolaborasi arsitektur sisi client dan sisi server :

1) Arsitektur Single- Tier
Arsitektur Single- Tier adalah semua komponen produksi dari sistem dijalankan pada komputer yang sama. Sederhana dan alternatifnya sangat mahal. Membutuhkan sedikit perlengkapan untuk dibeli dan dipelihara. Kelemahan pada keamanan dari arsitektur ini yaitu rendahnya dan kurangnya skalabilitas. Sebuah arsitektur skala besar yang dapat dengan mudah diperluas atau dilengkapi untuk memenuhi performa yang dibutuhkan.

Biarpun demikian, semua komponen utama dan data yang ada pada satu komputer didalam perlindungan firewall tetap sangat rentan terhadap serangan berbahaya. Menjalankan semua komponen pada sebuah komputer juga membatasi kemungkinan untuk memperluas dan mengoptimalisasinya. Kita hanya dapat menambahkan beberapa memory atau CPU pada sebuah server tunggal.

2) Arsitektur Two-tier
Pada Arsitektur Two-tier, antarmukanya terdapat pada lingkungan desktop dan sistem manajemen database biasanya ada pada server yang lebih kuat yang menyediakan layanan pada banyak client. Pengolahan informasi dibagi antara lingkungan antarmuka sistem dan lingkungan server manajemen database. Manajemen database server mendukung untuk penyimpanan prosedur dan trigger. Vendor perangkat lunak menyediakan alat-alat untuk menyederhanakan pengembangan aplikasi untuk arsitektur dua lapis client dan server .

Arsitektur two-tier lebih aman dan terukur daripada pendekatan single-tier. Database Server dipindahlan ke mesin terpisah di belakang firewall yang kedua. Ini menambah keamanan tambahan dengan menghapus data pelanggan sensitif dari DMZ. Mempunyai database pada komputer yang terpisah meningkatkan kinerja keseluruhan situs. Kelemahannya adalah biaya yang mahal dan arsitektur yang kompleks.

3) Arsitektur Three-tier
Arsitektur Three-Tier diperkenalkan untuk mengatasi kelemahan dari arsitektur two-tier. Di tiga tingkatan arsitektur, sebuah middleware digunakan antara sistem user interface lingkungan client dan server manajemen database lingkungan. Middleware ini diimplementasikan dalam berbagai cara seperti pengolahan transaksi monitor, pesan server atau aplikasi server. Middleware menjalankan fungsi dari antrian, eksekusi aplikasi dan database staging. Di samping itu middleware juga mempunyai penjadwalan dan prioritas pada pekerjaan yang sedang dilakukan. Three-tier client dan server arsitektur digunakan untuk meningkatkan performa untuk jumlah pengguna besar dan juga meningkatkan fleksibilitas ketika dibandingkan dengan pendekatan dua tingkat. Kekurangannya adalah pengembangan lebih sulit daripada pengembangan pada arsitektur dua lapis.


Service Telematika

Seperti halnya infrastruktur transportasi, jalan, dan listrik, teknologi telematika yang merupakan konvergensi dari telekomunikasi, teknologi informasi dan penyiaran memungkinkan terlaksananya aktivitas perekonomian dan sosial kemasyarakatan dengan lebih baik. Walaupun kontribusi sektor telematika dalam Pendapatan Nasional belum cukup signifikan, namun dengan tersedianya infrastruktur dan layanan telekomunikasi dan informasi, sesungguhnya hal tersebut sangat membantu aktivitas perekonomian, pendidikan, pemerintahan dan aktivitas di sektor lain untuk dapat lebih cepat berputar, lebih efisien berproses dan pada akhirnya akan meningkatkan pertumbuhan di sektor lain selain telekomunikasi dan informasi

Contoh-contoh dari layanan telematika yaitu :

1. Layanan Informasi
Layanan ini menyatukan sistem komunikasi dengan kendaraan seperti mobil untuk memberikan informasi kepada masyarakat.
Beberapa contoh layanan informasi :
- Telematik terminal
- Jasa pelayanan internet
- Informasi lalu lintas terbaru

2. Layanan Keamanan
Layanan ini memberikan fasilitas untuk memantau dan memberikan informasi jika sesuatu berjalan tidak seharusnya. Layanan ini dapat mengurangi tingkat pencurian dan kejahatan.

3. Layanan Context-Aware dan Event-base
Dalam ilmu komputer terdapat pernyataan bahwa perangkat komputer mempunyai kepekaan dan dapat bereaksi terhadap lingkungan sekitarnya berdasarkan informasi dan aturan-aturan tertentu yang tersimpan di dalamnya. Gagasan inilah yang diperkenalkan oleh Schilit pada tahun 1994 dengan istilah context-awareness.
Context-awareness merupakan kemampuan layanan network untuk mengetahui berbagai konteks, yaitu kumpulan parameter yang relevan dari pengguna (user) dan penggunaan network itu, serta memberikan layanan yang sesuai dengan parameter-parameter itu. Beberapa konteks yang dapat digunakan yaitu data dasar user, lokasi user, berbagai preferensi user, jenis dan kemampuan terminal yang digunakan user. Sebagai contoh : ketika seorang user sedang mengadakan acara pesta ulang tahunnya, maka context-aware pada mobile phone yang dimiliki user akan langsung menyimpulkan bahwa user sedang mengadakan acara ulang tahun dan akan menolak semua panggilan telepon yang tidak berkaitan dengan acara tersebut.

Kolaborasi Antar muka Otomotif Multimedia

Apakah Kolaborasi Antar muka Otomotif Multimedia itu?

Kolaborasi Antar muka Otomotif Multimedia adalah Sebuah kelompok yang dibuat oleh pembuat (maker) untuk menciptakan standar umum yang digunakan untuk mengatur bagaimana cara kerja perangkat elektronik, seperti komputer dan hiburan unit, berkomunikasi dengan kendaraan. Dan memiliki anggota: Fiat, Ford, General Motors, Honda, Mitsubishi, Nissan, PSA Peugeot-Citroen, Renault, …

Automotive Multimedia Interface Kolaborasi (AMIC) mengatakan akan menjadi tuan rumah tiga update internasional briefing untuk menjadi pemasok otomotif, komputer dan teknologi tinggi industri elektronik. Briefing akan diadakan 23 Februari di Frankfurt, Jerman; Februari 29 di Tokyo; dan Maret 9 di Detroit.

“AMIC telah membuat suatu kemajuan yang signifikan dalam satu tahun terakhir ini dalam menyelesaikan struktur organisasi dan mencapai kesepakatan mengenai persyaratan yang diperlukan untuk hardware dan software baik di masa depan mobil dan truk,” Jurubicara AMIC Dave Acton berkata, “Dan sekarang sudah saatnya bagi kita untuk bertemu dengan pemasok dan mereka yang tertarik untuk menjadi pemasok untuk memastikan kami pindah ke tahap berikutnya pembangunan kita bersama-sama. “
Acton menekankan bahwa AMIC terbuka untuk semua pemasok yang tertarik bisnis elektronik. AMIC dibentuk pada bulan September l998 dan saat ini dipimpin oleh 12 produsen otomotif dan anak perusahaan yang meliputi: BMW, DaimlerChrysler, Ford, Fiat, General Motors, Honda, Mitsubishi, Nissan, PSA / Peugeot-Citroen, Renault, Toyota, dan VW. Seorang juru bicara mengatakan kelompok AMIC berencana untuk mendirikan sebuah kantor di San Francisco di masa depan.

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.

MIDDLEWARE TELEMATIKA

Dalam dunia teknologi informasi, terminologi middleware adalah istilah umum dalam pemrograman komputer yang digunakan untuk menyatukan, sebagai penghubung, ataupun untuk meningkatkan fungsi dari dua buah progaram/aplikasi yang telah ada.

Perangkat lunak middleware adalah perangkat lunak yang terletak diantara program aplikasi dan pelayanan-pelayanan yang ada di sistim operasi.

Adapun fungsi dari middleware adalah:

ü Menyediakan lingkungan pemrograman aplikasi sederhana yang menyembunyikan penggunaan secara detail pelayanan-pelayanan yang ada pada sistem operasi.

ü Menyediakan lingkungan pemrograman aplikasi yang umum yang mencakup berbagai komputer dan sistim operasi.

ü Mengisi kekurangan yang terdapat antara sistem operasi dengan aplikasi, seperti dalam hal: networking, security, database, user interface, dan system administration.

Perkembangan middleware dari waktu ke waktu dapat dikategorikan sebagai berikut:

* On Line Transaction Processing (OLTP), merupakan perkembangan awal dari koneksi antar remote database. Pertama kali ditemukan tahun 1969 oleh seorang engineer di Ford, kemudian diadopsi oleh IBM hingga kini dikenal sebagai proses OLTP. DIGITAL ACMS merupakan contoh lainnya yang sukses pada tahun 70-an dan 80-an. UNIX OLTP lainnya seperti: Encina, Tuxedo pada era 80-an, serta DIGITAL CICS untuk UNIX yang memperkenalkan konsep dowsizing ke pasar.

* Remote Procedure Call (RPC), menyediakan fasilitas jaringan secara transparan. Open Network Computing (ONC) merupakan prototipe pertama yang diperkenalkan awal tahun 70-an. Sun unggul dalam hal ini dengan mengeluarkan suatu standar untuk koneksi ke internet. Distributed Computing Environment (DCE) yang dikeluarkan oleh Open Systems Foundation (OSF) menyediakan fungsi-fungsi ONC yang cukup kompleks dan tidak mudah untuk sis administrasinya.
* Common Object Request Broker Architecture (CORBA), merupakan object-oriented middleware yang menggabungkan fungsi RPC, brokering, dan inheritance. DIGITAL ObjectBroker merupakan salah satu contohnya.

Database middleware adalah salah satu jenis middleware disamping message-oriented middleware, object-oriented middleware, remote procedure call, dan transaction processing monitor1. Pada prinsipnya, ada tiga tingkatan integrasi sistem komputer yaitu integrasi jaringan, integrasi data, dan integrasi applikasi. Database middleware menjawab tantangan integrasi data, sedangkan midleware-middleware yang lain menjawab tantangan integrasi applikasi dan jaringan.

Tersedianya bermacam-macam sistem komputer beserta perangkat keras, perangkat lunak, dan perangkat tambahannya, yang mana masing-masing mempunyai kelebihan dan kekurangan, mendorong kita untuk melakukan integrasi dari sistem-sistem komputer tersebut. Salah satu syarat suatu sistem komputer bisa diintegrasikan adalah sistem tersebut haruslah bersifat terbuka (open). Selain memudahkan integrasi, sebuah sistem yang terbuka juga bersifat portable yang berarti bisa dijalankan atau menjadi bagian dari sistem yang lain. Untuk alasan-alasan inilah standar dibuat.

Namun, adanya standar tidak menyelesaikan masalah integrasi secara menyeluruh. Seperti kita ketahui, dunia bisa berkembang karena adanya perbedaan dan kompetisi. Bila segala sesuatu harus mengikuti standar, maka suatu ide baru yang cemerlang harus melalui proses standarisasi yang memerlukan waktu dan seringkali merugikan si pemilik ide tersebut. Karena alasan inilah, standar yang benar-benar universal hampir mustahil untuk diciptakan. Namun masalah ini juga tidak menutupi arti penting dari standarisasi dan alasan-alasan standarisasi itu sendiri.

Kembali ke masalah data, kita tahu bahwa data bisa disimpan dalam macam-macam tipe penyimpanan seperti text file, relational database, hierarchical database, object oriented data base, spreadsheet, dan beberapa bentuk yang lain. Lebih jauh, setiap bentuk penyimpanan mempunyai bermacam-macam cara penyimpanan, tergantung pada si pembuatnya. Sebagai contoh, walaupun sama-sama relational database, data yang disimpan di Oracle database disimpan dengan cara yang berbeda dengan kalau data tersebut disimpan di Sybase database.

Masalah tipe penyimpanan menjadi semakin rumit karena cara pengaksesan data pun bisa berbeda-beda. Masalah pengaksesan di relational database cukup teratasi dengan adanya SQL (Structured Query Language), tapi sekali lagi ini hanya terjadi di relational database dan bukan di tipe penyimpanan data yang lain (kita tidak bisa mengakses text file dengan perintah SQL, misalnya). Seperti bahasa pemrograman, SQL pun mengalami masalah dalam standarisasinya, karena tiap vendor mempunyai perintah-perintah tambahan yang berbeda satu dengan yang lain.

Bisakah masalah standarisasi dipecahkan dengan cara lain? Lebih jelasnya, bisakah kita mengintegrasikan atau menggunakan beberapa bentuk penyimpanan data dalam sebuah program aplikasi? Jawabnya adalah bisa.

Ada dua cara yang mungkin dilakukan, yang pertama adalah dengan mempelajari setiap tipe penyimpanan data yang akan kita pakai, dan kemudian membuat program antar muka (interface program) antara program aplikasi kita dengan tipe-tipe penyimpanan yang akan dipakai.

Seperti telah Anda duga, hal ini menjadi sangat sukar dilakukan bila kita memakai bermacam-macam tipe penyimpanan. Jadi, seringkali solusi ini menjadi pilihan terakhir dalam setiap usaha integrasi.

Cara yang kedua adalah menggunakan suatu alat bantu (tool) yang menyediakan satu antar muka untuk bermacam-macam tipe penyimpanan. Dengan ini, kita hanya perlu mempelajari satu antar muka, dan proses akses data ke bermacam-macam tipe penyimpanan menjadi sesuatu yang transparan bagi kita. Alat bantu inilah yang kita sebut sebagai database middleware.

Database middleware yang paling umum digunakan adalah ODBC (Open DataBase Connectivity). Keterbatasan ODBC adalah bahwa middleware ini didisain untuk bekerja pada tipe penyimpanan relational database, lebih tepatnya SQL-based relational database2, meskipun pada saat buku ini ditulis sudah tersedia ODBC untuk text file dan Excel spreadsheet.

Database middleware yang lain, yang merupakan superset daripada ODBC adalah OLEDB. OLEDB bisa mengakses hampir segala macam bentuk database, dan karenanya Microsoft mengklaim OLEDB sebagai Universal Data Access Interface2. Kelebihan yang lain dari OLEDB adalah dia didisain dengan konsep obyek komponen (Component Object Model) yang mengandalkan object-oriented computing dan menjadi salah satu trend di dunia komputasi. Hanya saja OLEDB relatif masih baru pada saat buku ini ditulis, sehingga penulis belum dapat mengevaluasinya lebih jauh.

Database middleware yang ketiga lebih bersifat produk daribada sekedar standard seperti ODBC dan OLEDB yang bisa dibuat oleh berbagai vendor. Beberapa produk database middleware yang bisa disebutkan di sini adalah Oracle’s DB Integrator (previously DIGITAL’s DB Integrator), Sybase’s Omni CONNECT, and International Software Group’s Navigator. Kelebihan dari produk-produk ini dibandingkan dengan standard seperti ODBC dan OLEDB adalah performance, yang sangat sulit dimiliki oleh suatu produk yang mengacu pada standar1.

Bagaimana masa depan dari database middleware? Database middleware, seperti midleware-middleware yang lain akan tetap dan semakin dibutuhkan dimasa yang akan datang. Dan besar kemungkinannya bahwa OLEDB akan menjadi database middleware yang paling populer pada saat teknologinya matang, karena keterbukaannya, arsitekturnya yang object-oriented, dan kemampuannya mengakses hampir semua tipe penyimpanan data.

Sumber :

1. http://hakusensha.blogspot.com/2010/11/arsitektur-dan-service-pada-telematika.html

2. http://adhek09.wordpress.com