Arsitektur sisi client server serta kolaborasinya

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



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.

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://hakusensha.blogspot.com/2010/11/arsitektur-dan-service-pada-telematika.html
http://adhek09.wordpress.com
http://wartawarga.gunadarma.ac.id/2010/12/pengantar-telematika-materi-2/