Java Community Process

| | 0 komentar
Nama: Muhamad Satria Perkasa
NPM: 16109102
Kelas: 4ka12
______________________________

Java Community Process (JCP), didirikan pada tahun 1998, adalah mekanisme formal yang memungkinkan pihak yang berkepentingan untuk mengembangkan spesifikasi teknis standar untuk teknologi Java. Siapapun bisa menjadi Anggota JCP dengan mengisi formulir yang tersedia di situs JCP. Keanggotaan JCP untuk organisasi dan entitas komersial membutuhkan biaya tahunan tetapi bebas untuk individu.
JCP melibatkan penggunaan Java Specification Requests (JSRs) dokumen formal yang menggambarkan spesifikasi yang diusulkan dan teknologi untuk menambah platform Java. Ulasan publik Formal JSRs akan muncul sebelum JSR menjadi final dan suara JCP Komite Eksekutif di atasnya. Sebuah JSR akhir menyediakan implementasi referensi yang merupakan implementasi bebas dari teknologi dalam bentuk kode sumber dan Kompatibilitas Kit Teknologi untuk memverifikasi spesifikasi API.


Virtual Machine
Sebuah mesin virtual (VM) adalah sebuah perangkat lunak implementasi sebuah mesin (misalnya komputer) yang melaksanakan program-program seperti mesin fisik. Sebuah mesin virtual pada awalnya ditentukan oleh Popek dan Goldberg sebagai "yang efisien, terisolasi duplikat dari mesin yang nyata". Saat menggunakan mesin virtual yang mencakup tidak memiliki surat-menyurat langsung ke perangkat keras yang nyata. Mesin virtual dipisahkan ke dalam dua kategori utama, berdasarkan tingkat penggunaan dan korespondensi untuk mesin nyata. Sebuah sistem mesin virtual yang lengkap menyediakan platform sistem yang mendukung pelaksanaan lengkap sistem operasi (OS). Sebaliknya, mesin virtual sebuah proses yang dirancang untuk menjalankan sebuah program, yang berarti bahwa ia mendukung satu proses. Karakteristik penting dari sebuah mesin virtual yang berjalan di dalam perangkat lunak adalah terbatas pada sumber daya dan abstraksi yang disediakan oleh mesin virtual tidak dapat keluar dari dunia virtual. 
Contoh: Suatu program yang ditulis dalam Java menerima jasa dari Java Runtime Environment (JRE) perangkat lunak dengan mengeluarkan perintah untuk, dan menerima hasil yang diharapkan dari, perangkat lunak Java. Dengan memberikan layanan ini untuk program tersebut, perangkat lunak Java bertindak sebagai "mesin virtual", menggantikan sistem operasi atau hardware untuk program yang biasanya akan disesuaikan. 

• Sistem virtual machines 
Sistem mesin virtual (kadang-kadang disebut mesin virtual hardware) memungkinkan pembagian yang mendasari sumber daya mesin fisik antara mesin virtual yang berbeda, masing-masing berjalan sendiri sistem operasi. Lapisan perangkat lunak yang menyediakan virtualisasi ini disebut mesin virtual monitor atau hypervisor. Sebuah hypervisor dapat berjalan di hardware yang telanjang (Tipe 1 atau pribumi VM) atau di atas sistem operasi (Tipe 2 atau host VM). 

Keuntungan utama dari sistem VMS adalah: 
• beberapa OS lingkungan dapat hidup berdampingan pada komputer yang sama, dalam isolasi kuat satu sama lain 
• mesin virtual dapat memberikan set instruksi arsitektur (ISA) yang agak berbeda dari mesin yang sebenarnya 
• aplikasi provisioning, pemeliharaan, tingkat ketersediaan dan pemulihan bencana 

Kerugian utama dari sistem VMS adalah: 
• mesin virtual kurang efisien daripada mesin nyata karena secara tidak langsung mengakses perangkat keras.

APIs
Sebuah application programming interface (API) adalah antarmuka bahwa sebuah program perangkat lunak alat untuk memungkinkan perangkat lunak lain untuk berinteraksi dengan itu, banyak cara yang sama seperti perangkat lunak mungkin akan mengimplementasikan antarmuka pengguna untuk memungkinkan manusia untuk menggunakannya. API dilaksanakan oleh aplikasi, perpustakaan dan sistem operasi untuk menentukan bagaimana perangkat lunak lain dapat membuat panggilan ke atau layanan permintaan dari mereka. Sebuah API menentukan kosa kata dan konvensi memanggil para pemrogram harus mempekerjakan untuk menggunakan layanan . Ini mungkin termasuk spesifikasi untuk rutinitas, struktur data, kelas objek, dan protokol yang digunakan untuk berkomunikasi antara konsumen dan pelaksana API.

• Fitur 
API adalah sebuah abstraksi. Perangkat lunak yang menyediakan fungsionalitas yang dijelaskan oleh API dikatakan sebuah implementasi dari API. 
API dapat: 
• Tergantung pada bahasa, yaitu hanya tersedia dalam bahasa pemrograman tertentu, dengan menggunakan sintaks dan unsur-unsur bahasa itu untuk membuat API nyaman untuk digunakan dalam konteks ini. 
• Bahasa-independen, yaitu ditulis dengan cara yang berarti dapat dipanggil dari beberapa bahasa pemrograman. Ini adalah fitur yang diinginkan untuk layanan-gaya API yang tidak terikat pada suatu proses atau sistem dan dapat diberikan sebagai remote procedure calls atau layanan web. 
Sebagai contoh, sebuah website yang memungkinkan pengguna untuk memeriksa restoran lokal mampu lapisan tinjauan di atas peta mereka diambil dari Google Maps, karena Google Maps API yang memiliki memungkinkan hal ituGoogle Maps 'API mengontrol informasi apa pihak ketiga situs bisa ambil, dan apa yang bisa dilakukan dengan itu. 
"API" dapat digunakan untuk mengacu ke antarmuka lengkap, satu fungsi, atau bahkan satu set berbagai API yang disediakan oleh sebuah organisasi. Dengan demikian, cakupan makna biasanya ditentukan oleh orang atau dokumen yang mengkomunikasikan informasi. 
• Web API 
Ketika digunakan dalam konteks pengembangan web, biasanya sebuah API yang didefinisikan set Hypertext Transfer Protocol (HTTP) pesan permintaan bersama dengan definisi respon struktur pesan, biasanya dinyatakan dalam sebuah Sementara "Web API" secara virtual sinonim untuk layanan web, tren baru-baru ini (yang disebut Web 2.0) telah bergerak jauh dari Simple Object Access Protocol (SOAP) layanan berbasis lebih langsung terhadap Negara Representasi Transfer (REST) gaya komunikasi. Web API memungkinkan kombinasi dari berbagai layanan ke aplikasi baru yang dikenal sebagai mashup. 
• Implementasi 
POSIX standard mendefinisikan sebuah API yang memungkinkan berbagai fungsi komputasi umum harus ditulis sedemikian rupa sehingga mereka dapat beroperasi pada banyak sistem yang berbeda (Mac OS X dan berbagai Berkeley Software Distribusi (BSD) mengimplementasikan interface ini), namun, dengan menggunakan ini memerlukan kompilasi ulang untuk setiap platform. API yang kompatibel, di sisi lain, memungkinkan dikompilasi kode obyek untuk berfungsi tanpa perubahan apapun, pada pelaksanaan sistem apapun yang API.

Microsoft telah menunjukkan komitmen untuk API yang kompatibel ke belakang, terutama di dalam Windows API (Win32) perpustakaan, seperti aplikasi yang lebih tua dapat berjalan di Windows versi yang lebih baru menggunakan pengaturan khusus eksekusi yang disebut "Compatibility Mode" . Apple Inc telah menunjukkan kecenderungan yang kurang perhatian ini, memecah kompatibilitas atau mengimplementasikan dalam sebuah API yang lebih lambat "mode emulasi"; ini memungkinkan kebebasan lebih besar dalam pembangunan, pada biaya pembuatan perangkat lunak yang lebih tua usang.




Referensi:
http://en.wikipedia.org/wiki/Java_Community_Process
http://septianadhe2wz.blogspot.com/2009/12/proses-komunitas-java-java-community.html

Automotive Multimedia Interface Collaboration

| | 0 komentar
Nama: Muhamad Satria Perkasa
NPM: 16109102
Kelas: 4ka12
______________________

Apa yang terlintas dipikiran kita ketika mendengar Automotive Multimedia Interface Collaboration (AMI-C) atau dalam bahasa Indonesia berarti Kolaborasi Antarmuka Otomotif Multimedia? Apakah memang ada yang seperti itu? Lantas kolaborasi seperti apa yang tercipta antara Otomotif dengan Multimedia? Ah, tentunya masih banyak pertanyaan dibenak kita yang muncul mengenai Automotive Multimedia Interface Collaboration. Lalu apa sebenarnya Automotive Multimedia Interface Collaboration itu?

Setelah mencari beberapa referensi di internet ternyata Automotive Multimedia Interface Collaboration adalah sebuah kelompok yang dibuat oleh pembuat/pabrik automotive untuk menciptakan standar umum untuk mengatur bagaimana perangkat elektronik, seperti computer dan unit-unit hiburan berkomunikasi dengan kendaraan. Tapi kenapa perlu ada Automotive Multimedia Interface Collaboration? Ternyata para pembuat/pabrik automotive mengkhawatirkan bahwa perangkat elektronik dan multimedia akan tidak cocok/tidak kompatibel dengan kendaraan; bahwa perangkat tersebut dapat mengganggu elektronik yang mengontrol sistem keselamatan dan bahwa organisasi standar yang ada tidak akan bergerak cukup cepat. Oleh karena itu terbentuklah Automotive Multimedia Interface Collaboration.

Arsitektur
AMIC ditentukan unsur arsitektur platform terintegrasi



Komponen
Arsitektur AMIC memiliki empat komponen
  • In-Vehicle Jaringan
  • Jaringan perangkat
  • Kendaraan Antarmuka
  • Host (platform komputasi)


Mengapa AMIC terhubung dengan OSGI?
Similar persyaratan
- Layanan remote disediakan untuk jaringan lokal
- Layanan dapat dikelola oleh operator jarak jauh
- Pelayanan harus berjalan pada berbagai platform lokal
- Harus berjalan pada sumber daya terbatas (biaya rendah) platform

Similar solusi berbasis Java
- Vendor independen
- Mekanisme untuk layanan menggabungkan dari beberapa vendor
- Fungsi yang disediakan oleh platform OSGi meliputi sebagian besar yang
  dibutuhkan oleh AMIC

Menggunakan API yang ada akan meningkatkan solusi AMIC ini
- Leverage pengalaman dan keahlian yang masuk ke sebelumnya
  implementasi
- Mengurangi jumlah pembangunan API yang diperlukan dengan menggunakan umum
  solusi sedapat mungkin.



Referensi:
http://www.osgi.org/wiki/uploads/Congress2002/Edward%20Nelson.pdf
http://eutass.blogspot.com/2009/11/automotive-multimedia-interface.html

Open Service Gateway Initiative (OSGI)

| | 0 komentar
Nama: Muhamad Satria Perkasa
NPM: 16109102
Kelas: 4ka12
__________________________

OSGI (Open Service Gateway Initiative) adalah sebuah rencana industri untuk cara standar untuk menghubungkan perangkat seperti perangkat rumah tangga dan sistem keamanan ke Internet. OSGI berencana menentukan program aplikasi antarmuka (API) untuk pemrogram menggunakan, untuk memungkinkan komunikasi dan kontrol antara penyedia layanan dan perangkat di dalam rumah atau usaha kecil jaringan. OSGI API akan dibangun pada bahasa pemrograman Java. Program java pada umumnya dapat berjalan pada platform sistem operasi komputer. OSGI adalah sebuah interface pemrograman standar terbuka. The OSGI Alliance (sebelumnya dikenal sebagai Open Services Gateway inisiatif, sekarang nama kuno) adalah sebuah organisasi standar terbuka yang didirikan pada Maret 1999. Aliansi dan anggota – anggotanya telah ditentukan sebuah layanan berbasis Java platform yang dapat dikelola dari jarak jauh.Spesifikasi OSGI yang dikembangkan oleh para anggota dalam proses terbuka dan tersedia untuk umum secara gratis di bawah Lisensi Spesifikasi OSGI. OSGI Alliance yang memiliki program kepatuhan yang hanya terbuka untuk anggota. Pada Oktober 2009, daftar bersertifikat OSGI implementasi berisi lima entri. 

Spesifikasi
OSGi spesifikasi yang dikembangkan oleh para anggota dalam proses terbuka dan tersedia untuk umum secara gratis di bawah Lisensi Spesifikasi OSGiOSGi Allianceyang memiliki kepatuhan program yang hanya terbuka untuk anggota. Pada Oktober 2009, daftar bersertifikat OSGi implementasi berisi lima entri.



Arsitektur
  • Bundels: komponen OSGi yang dibuat oleh pengembang
  • Services: Layanan bundel menghubungkan lapisan dalam cara yang dinamis dengan menawarkan menerbitkan, menemukan model mengikat Jawa lama untuk menikmati objek.
  • Life Cycle: The API untuk instalasi, start, stop, update, dan menghapus bundel.
  • Modules: Lapisan yang mendefinisikan bagaimana sebuah bundel dapat mengimpor dan mengekspor kode.
  • Security (Keamanan): Lapisan yang menangani aspek keamanan.
  • Execution Environment (Eksekusi Lingkungan): Menetapkan metode dan kelas-kelas apa saja yang tersedia dalam platform tertentu.


Specification Version

  • OSGi Release 1 (R1): May 2000
  • OSGi Release 2 (R2): October 2001
  • OSGi Release 3 (R3): March 2003
  • OSGi Release 4 (R4): October 2005 / September 2006
    • Core Specification (R4 Core): October 2005
    • Mobile Specification (R4 Mobile / JSR-232): September 2006
  • OSGi Release 4.1 (R4.1): May 2007 (AKA JSR-291)
  • OSGi Release 4.2 (R4.2): September 2009
    • Enterprise Specification (R4.2): March 2010
  • OSGi Release 4.3 (R4.3): April 2011
    • Core: April 2011
    • Compendium and Residential: May 2012
  • OSGi Release 5 (R5): June 2012
    • Core and Enterprise: June 2012

Refrensi :
http://bluewarrior.wordpress.com/2009/12/01/open-services-gateway-initiative-osgi/
http://uriflabamba.blogspot.com/2009/12/open-service-gateway-initiative-osgi.html
http://en.wikipedia.org/wiki/OSGi#Specification_process