|
1. Pengertian Work Breakdown Structure (WBS)
WBS merupakan kependekan dari Work Breakdown Structure. WBS
adalah suatu metode pengorganisaian proyek menjadi struktur pelaporan
hierarakis. WBS digunakan untuk melakukan Breakdown atau memecahkan tiap
proses pekerjaan menjadi lebih detail.hal ini dimaksudkan agar proses
perencanaan proyek memiliki tingkat yang lebih baik.
WBS
disusun bedasarkan dasar pembelajaran seluruh dokumen proyek yang
meliputi kontrak, gambar-gambar, dan spesifikasi. Proyek kemudian
diuraikan menjadi bagian-bagian dengan mengikuti pola struktur dan
hirarki tertentu menjadi item-item pekerjaan yang cukup terperinci.
Dalam
WBS kita akan membuat daftar fase-fase pengerjaan project. Beberapa
fase tergantung dari fase sebelumnya, tetapi ada juga beberapa fase yang
bisa dikerjakan secara bersama-sama. Dari analisa ini kita bisa
memperkirakan kapan project bisa dimulai dan kapan project bisa selesai.
2. Manfaat dari Work Breakdown Structure (WBS)
WBS
sangat penting dalam perencanaan project. Dengan WBS kita akan
menuliskan tahapan-tahapan project secara mendetail. Dari
tahapan-tahapan yang kita tuliskan kita kemudian akan menganalisa
kebutuhan SDM (Sumber Daya Manusia) dan sumber-sember daya lainnya
seperti tempat, fasilitas, alat-alat yang diperlukan. Dari analisa
sumber daya-sumber daya ini kemudian kita bisa tentukan total waktu yang
dibutuhkan. Dari total waktu yang dibutuhkan dan pemakaian
sumber-sumber daya lainnya kita bisa menentukan biaya project. Biaya
project ditambah dengan keuntungan yang ingin kita peroleh maka
didapatkan harga project.
Berikut adalah manfaat dari Work Breakdown Structure (WBS) :
Sumber : http://distroblogger.com/wbs-work-breakdown-structure/ http://sitompulke17.wordpress.com/2010/11/16/pengertian-work-breakdown-structure-wbs/ |
0 Work Breakdown Structure (WBS)
Jumat, 25 Januari 2013
0 Manajemen Kontrol Keamanan (Security Management Controls)
Pendahuluan `
Aset Sistem Informasi yang harus di lindungi melalui sistem keamanan dapat diklasifikasikan menjadi 2 yaitu (lihat gbr. 6.1) :
1. Aset Fisik, meliputi :
a. Personnel
b. Hardware (termasuk media penyimpanan, dan periperalnya)
c. Fasilitas
d. Dokumentasi dan
e. Supplies
2. Aset Logika
a. Data / Informasi dan
b. Sofware (Sistem dan Aplikasi)
Pelaksanaan Program Keamanan (Conducting a Security Program)
Langkah-langkah utama pelaksanaan Program keamanan yaitu (lihat gbr.6.2)
Persiapan Rencana Pekerjaan (Preparation of a Project Plan)
Perencanaan proyek untuk tinjaun kemanan mengikuti item sbb :
a. Tujuan Review
b. Ruang Lingkup (Scope) Review
c. Tugas yang harus dipenuhi
d. Organisasi dari Tim Proyek
e. Sumber Anggaran (Pendanaan) dan
f. Jadwal untuk Menyelesaikan Tugas
Identifikasi Kekayaan (Identification of asset)
Katagori asset :
a. Personnel
b. Hardware
c. Fasilitas
d. Dokumentasi
e. Persediaan
f. Data/Informasi
g. Software Aplikasi
h. Sistem Software
Penilaian Kekayaan (Valuation of asset)
Langkah ke tiga adalah penilaian kekayaan, yang merupakan langkah paling sulit. Parker (1981) menggambarkan ketergantungan penilaian pada siapa yang ditanya untuk memberikan penilaian, cara penilaian atas kekayaan yang hilang (lost), waktu periode untuk perhitungan atas hilangnya kekayaan, dan umur asset. Lihat gbr. 6.3
Identifikasi Ancaman-ancaman (Threats Identification) Lihat gbr. 6.4 Lapisan jenis ancaman aset SI
Sumber ancaman External :
1. Nature / Acts of God
2. H/W Suppliers
3. S/W Suppliers
4. Contractors
5. Other Resource Suppliers
6. Competitors
7. Debt and Equity Holders
8. Unions (strikes, sabotage,harassment)
9. Governmnets
10. Environmentalist
11. Criminals/hackers
Sumber ancaman Internal :
1.Management, contoh kesalahan dalam penyediaan sumber daya, perencanaan dan control yang tidak cukup.
2.Employee, contoh Errors, Theft (pencurian), Fraud (penipuan), sabotase, extortion (pemerasan), improper use of service (penggunaan layanan yg tidak sah)
3.Unreliable system, contoh Kesalahan H/W, kesalahan S/W, kesalahan fasilitas.
Penilaian Kemungkinan Ancaman (Threats LikeIihood Assessment)
Contoh, perusahaan asuransi dapat menyediakan informasi tentang kemungkinan terjadinya kebakaran api dalam satu waktu periode tertentu.
Analisis Ekspose (Exposures analysis)
Tahap analisis ekspose terdiri dari 4 tugas yaitu :
1. Identification of the controls in place
2. Assessment of the reliability of the controls in place
3. Evaluation of the likelihood that a threat incident will be successful
4. Assess the resulting loss if the threat is successful
source
http://v-class.gunadarma.ac.id/mod/resource/view.php?id=xx44641
Aset Sistem Informasi yang harus di lindungi melalui sistem keamanan dapat diklasifikasikan menjadi 2 yaitu (lihat gbr. 6.1) :
1. Aset Fisik, meliputi :
a. Personnel
b. Hardware (termasuk media penyimpanan, dan periperalnya)
c. Fasilitas
d. Dokumentasi dan
e. Supplies
2. Aset Logika
a. Data / Informasi dan
b. Sofware (Sistem dan Aplikasi)
Pelaksanaan Program Keamanan (Conducting a Security Program)
Langkah-langkah utama pelaksanaan Program keamanan yaitu (lihat gbr.6.2)
Persiapan Rencana Pekerjaan (Preparation of a Project Plan)
Perencanaan proyek untuk tinjaun kemanan mengikuti item sbb :
a. Tujuan Review
b. Ruang Lingkup (Scope) Review
c. Tugas yang harus dipenuhi
d. Organisasi dari Tim Proyek
e. Sumber Anggaran (Pendanaan) dan
f. Jadwal untuk Menyelesaikan Tugas
Identifikasi Kekayaan (Identification of asset)
Katagori asset :
a. Personnel
b. Hardware
c. Fasilitas
d. Dokumentasi
e. Persediaan
f. Data/Informasi
g. Software Aplikasi
h. Sistem Software
Penilaian Kekayaan (Valuation of asset)
Langkah ke tiga adalah penilaian kekayaan, yang merupakan langkah paling sulit. Parker (1981) menggambarkan ketergantungan penilaian pada siapa yang ditanya untuk memberikan penilaian, cara penilaian atas kekayaan yang hilang (lost), waktu periode untuk perhitungan atas hilangnya kekayaan, dan umur asset. Lihat gbr. 6.3
Identifikasi Ancaman-ancaman (Threats Identification) Lihat gbr. 6.4 Lapisan jenis ancaman aset SI
Sumber ancaman External :
1. Nature / Acts of God
2. H/W Suppliers
3. S/W Suppliers
4. Contractors
5. Other Resource Suppliers
6. Competitors
7. Debt and Equity Holders
8. Unions (strikes, sabotage,harassment)
9. Governmnets
10. Environmentalist
11. Criminals/hackers
Sumber ancaman Internal :
1.Management, contoh kesalahan dalam penyediaan sumber daya, perencanaan dan control yang tidak cukup.
2.Employee, contoh Errors, Theft (pencurian), Fraud (penipuan), sabotase, extortion (pemerasan), improper use of service (penggunaan layanan yg tidak sah)
3.Unreliable system, contoh Kesalahan H/W, kesalahan S/W, kesalahan fasilitas.
Penilaian Kemungkinan Ancaman (Threats LikeIihood Assessment)
Contoh, perusahaan asuransi dapat menyediakan informasi tentang kemungkinan terjadinya kebakaran api dalam satu waktu periode tertentu.
Analisis Ekspose (Exposures analysis)
Tahap analisis ekspose terdiri dari 4 tugas yaitu :
1. Identification of the controls in place
2. Assessment of the reliability of the controls in place
3. Evaluation of the likelihood that a threat incident will be successful
4. Assess the resulting loss if the threat is successful
source
http://v-class.gunadarma.ac.id/mod/resource/view.php?id=xx44641
0 Manajemen Kontrol Programming (Programming Management Controls)
Pada bab ini kita akan memeriksa secara praktis pengadaan atau produksi s/w dengan kualitas
yang tinggi.
Siklus Hidup Pengembangan Program
Pembuatan dan pengembangan program adalah merupakan tahap penting alam siklus hidup pengembangan sistem.
Tujuan utama tahap ini adalah untuk menghasilkan atau memperoleh dan menenerapkan program yang berkualitas.
Beberapa karakteristik program yang berkualitas adalah :
a. Berfungsi dengan tepat dan lengkap
b. Mempunyai user interface dengan kualitas tinggi (baik)
c. Bekerja secara efisien
d. Dirancang dan di dokumentasikan dengan baik
e. Mudah untuk pemeliharaan
f. Dapat menyesuaikan di bawah kondisi tidak normal
Jika program mempunyai karakteristik tersebut, aktivitas pengembangan, penerimaan dan implementasi program dapat diatur dengan baik. Dalam pengembangan sistem, auditor dapat menggunakan model siklus hidup untuk lebih memahami, merencanakan, dan menyelesaikan tugas dalam rangka untuk memperoleh s/w dengan kualitas baik. Selama proses audit, model ini juga dapat digunakan sebagai pedoman aktivitas pengumpulan dan evaluasi fakta.
Terdapat enam pedoman dalam pengembangan program, yaitu (lihat gbr.5.1) :
1. Planning
2. Control
3. Design
4. Coding
5. Testing dan
6. Operation and maintenance
Gbr.5.1 Siklus hidup pengembangan program
Perencanaan (Planning)
Tugas utama dari manajemen dalam tahap ini adalah untuk memperkirakan kebutuhan besarnya sumber daya (khususnya jam kerja) yang dibutuhkan dalam pengembangan, pengadaan, dan penerapan software. Jika, sebagai contoh, s/w di buat di rumah (in house), manajemen harus berusaha untuk memperkirakan berapa jumlah baris kode (program) yang di ketik atau banyaknya fungsi yang di buat. Jika suatu software akan dikembangkan dan diimplementasikan secara in-house, manajemen harus memanfaatkan lima teknik perencanaan biaya yang di buat oleh Boehm (1984) sbb :
Pada tahap kontrol ini, ada dua tujuan utama yaitu :
source
http://v-class.gunadarma.ac.id/mod/resource/view.php?id=xx44636
yang tinggi.
- Kita mulai dengan memeriksa fase utama pada siklus hidup engembangan program.Diskusi di fokuskan pada tipe pengalaman yang baik dan konsen pengendalian yangharus dilakukan oleh Auditor pada tiap fase.
- Selanjutnya kita akan memeriksa cara lain untuk mengorganisasikan dan mengatur tim programmer, dari sudut pandang pengendalian kita akan memfokuskan pada keuntungan dan kelemahan perbedaan struktur tim yang akan digunakan.
- Pada akhirnya, kita akan memeriksa masalah pengendalian khusus yang timbul dalamkaitan untuk kegiatan dari sistem programmer. Kita mempertimbangkan beberapapendekatan yang dapat digunakan untuk memudahkan persoalan pengendalian.
Siklus Hidup Pengembangan Program
Pembuatan dan pengembangan program adalah merupakan tahap penting alam siklus hidup pengembangan sistem.
Tujuan utama tahap ini adalah untuk menghasilkan atau memperoleh dan menenerapkan program yang berkualitas.
Beberapa karakteristik program yang berkualitas adalah :
a. Berfungsi dengan tepat dan lengkap
b. Mempunyai user interface dengan kualitas tinggi (baik)
c. Bekerja secara efisien
d. Dirancang dan di dokumentasikan dengan baik
e. Mudah untuk pemeliharaan
f. Dapat menyesuaikan di bawah kondisi tidak normal
Jika program mempunyai karakteristik tersebut, aktivitas pengembangan, penerimaan dan implementasi program dapat diatur dengan baik. Dalam pengembangan sistem, auditor dapat menggunakan model siklus hidup untuk lebih memahami, merencanakan, dan menyelesaikan tugas dalam rangka untuk memperoleh s/w dengan kualitas baik. Selama proses audit, model ini juga dapat digunakan sebagai pedoman aktivitas pengumpulan dan evaluasi fakta.
Terdapat enam pedoman dalam pengembangan program, yaitu (lihat gbr.5.1) :
1. Planning
2. Control
3. Design
4. Coding
5. Testing dan
6. Operation and maintenance
Gbr.5.1 Siklus hidup pengembangan program
Perencanaan (Planning)
Tugas utama dari manajemen dalam tahap ini adalah untuk memperkirakan kebutuhan besarnya sumber daya (khususnya jam kerja) yang dibutuhkan dalam pengembangan, pengadaan, dan penerapan software. Jika, sebagai contoh, s/w di buat di rumah (in house), manajemen harus berusaha untuk memperkirakan berapa jumlah baris kode (program) yang di ketik atau banyaknya fungsi yang di buat. Jika suatu software akan dikembangkan dan diimplementasikan secara in-house, manajemen harus memanfaatkan lima teknik perencanaan biaya yang di buat oleh Boehm (1984) sbb :
- Algorithmic Models (model algoritma) : model ini akan memperkirakan jumlah sumber daya yang dibutuhkan berdasar pada faktor biaya, sebagai contoh memperkirakan jumlah instruksi yang harus di ketik (di tulis), bahasa pemrograman yang digunakan, dan perubahan pada permintaan kebutuhan. Dengan menggunakan model COCOMO (Boehm’s (1981)).
- Expert Judgment (penilaian seorang ahli), seorang ahli dapat memperkirakan kebutuhan sumber daya yang diperlukan dalam proyek / pembuatan program. Menurut penelitian Vicinanza et el’s (1991), seorang ahli dapat menjadi pembuat perkiraan yang lebih baik untuk menentukan sumber daya jika dibanding dengan model algoritma.
- Analogy (analogi) : jika proyek software yang sama pernah dibuat, penentuan sumber daya yang dibutuhkan dapat di dasarkan pada pengalaman sebelumnya.
- Top-Down Estimation (Perkiraan atas-bawah) : proyek di pecah kedalam beberapa tugas (pekerjaan), dan penentuan sumber daya yang dibutuhkan oleh setiap tugas tersebut baru dibuat.
- Bottom-Up Estimation (Perkiraan bawah-atas) : jika tugas-tugas sudah di buat terlebih dahulu, kebutuhan sumber daya untuk masing-masing dapat diperkirakan dan di satukan / dikumpulkan untuk keperluan seluruh kebutuhan proyek. Selain memperkirakan kebutuhan sumber daya, manajemen juga harus memutuskan tujuan dari keputusan penting yang dibuat selama fase perencanaan seperti : Pengendalian (Control)
Pada tahap kontrol ini, ada dua tujuan utama yaitu :
- Untuk memonitor kemajuan dan beberapa tahap pada siklus hidup s/w agar tidak bertentangan dengan rencana awal.
- Mengontrol tugas pengembangan, pengadaan dan implementasi s/w, agar s/w dapat diproduksi secara autentik, akurat dan lengkap. Untuk memonitor agar kontrol tidak bertentangan dengan rencana awal, beberapa teknikdapat digunakan seperti :
- a. Work Breakdown Structures (WBS), dengan teknik ini kita dapat mengidentifikasi tugastugas yang spesifik untuk pengembangan, pengadaan, dan implementasi s/w yang dibutuhkan. (Mc.Leod and Smith 1996).Gbr.5.2 Pemecahan struktur untuk order-entry system
- b. Gantt Chart, dapat digunakan untuk membantu mengatur tugas (schedule) (lihat gbr.5.3). Teknik ini akan menunjukan kapan tugas harus dimulai dan diselesaikan, tugas apa yang harus dibuat bersama-sama, dan tugas apa yang harus dihasilkan secara serial. Gbr.5.3 Gantt Chart untuk order-entry system
source
http://v-class.gunadarma.ac.id/mod/resource/view.php?id=xx44636
0 OSGI (Open Service Gateway Initiative), AMIC (Automotive Multimedia Interface Collaboration) dan JAP (Java Community Process)
Selasa, 22 Januari 2013
1. OSGi (Open Service Gateway Initiative)
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.
1.1. Spesifikasi
Spesifikasi OSGi dikembangkan oleh para anggota dalam proses terbuka dan tersedia untuk publik secara gratis di bawah Lisensi Spesifikasi OSGi. The Alliance OSGi memiliki kepatuhan program yang hanya terbuka untuk anggota. Pada November 2010, ada tujuh bersertifikat OSGi kerangka implementasi . Sebuah halaman terpisah daftar baik bersertifikat dan non-bersertifikat Implementasi Spesifikasi OSGi, yang meliputi kerangka OSGi dan spesifikasi OSGi lainnya.
Kerangka OSGi (OSGi framework)
Kerangka OSGi adalah sistem modul dan layanan platform untuk Java bahasa pemrograman yang menerapkan lengkap dan dinamis model komponen , sesuatu yang seperti tahun 2012 tidak ada di Jawa standalone / VM lingkungan. Aplikasi atau komponen (datang dalam bentuk dari bundel untuk penyebaran) dapat jarak jauh diinstal, mulai, berhenti, diperbarui, dan dihapus tanpa memerlukan restart, pengelolaan paket Jawa / kelas ditentukan dengan sangat rinci. Aplikasi manajemen siklus hidup (start, stop, install, dll) dilakukan melalui API yang memungkinkan untuk remote download dari kebijakan manajemen. Registri layanan memungkinkan berkas untuk mendeteksi penambahan layanan baru, atau penghapusan layanan dan beradaptasi sesuai.
Spesifikasi OSGi telah bergerak melampaui fokus asli gateway layanan, dan sekarang digunakan dalam aplikasi mulai dari ponsel ke open source Eclipse IDE. Area aplikasi lainnya termasuk mobil, otomasi industri, otomatisasi bangunan, PDA, komputasi grid, hiburan, armada manajemen dan aplikasi server .
1.2. Arsitektur (Architecture)
Setiap kerangka yang menerapkan standar OSGi menyediakan suatu lingkungan untuk modularisasi aplikasi ke dalam bundel kecil. Setiap bundel adalah koleksi, erat dynamically loadable kelas, guci, dan file konfigurasi yang secara eksplisit menyatakan dependensi eksternal mereka (jika ada).
Kerangka ini secara konseptual dibagi menjadi bidang-bidang berikut:
1. Bundle Bundel adalah sekelompok kelas Java dan sumber daya tambahan yang dilengkapi dengan manifes rinci MANIFEST.MF file pada semua isinya, serta layanan tambahan yang diperlukan untuk memberikan kelompok termasuk kelas Java perilaku yang lebih canggih, sejauh deeming seluruh agregat komponen.
2. Layanan
Layanan yang menghubungkan lapisan bundel dalam cara yang dinamis dengan menawarkan, menerbitkan dan menemukan model dapat mengikat Java lama untuk menikmati objek (POJO). Siklus hidup menambahkan lapisan bundel dinamis yang dapat diinstal, mulai, berhenti, diperbarui dan dihapus. Buntalan bergantung pada lapisan modul untuk kelas loading tetapi menambahkan API untuk mengatur modul – modul dalam run time. Memperkenalkan lapisan siklus hidup dinamika yang biasanya bukan bagian dari aplikasi. Mekanisme ketergantungan luas digunakan untuk menjamin operasi yang benar dari lingkungan.
3. Layanan Registry
The API untuk jasa manajemen (ServiceRegistration , ServiceTracker dan ServiceReference).
4. Life-Cycle
The API ntuk manajemen siklus hidup untuk (instal, start, stop, update, dan uninstall) bundel.
5. Modul
Lapisan ang mendefinisikan enkapsulasi dan deklarasi dependensi (bagaimana sebuah bungkusan dapat mengimpor dan mengekspor kode).
6. Keamanan
Lapisan yang menangani aspek keamanan dengan membatasi fungsionalitas bundel untuk pra-didefinisikan kemampuan.
7. Eksekusi Lingkungan
Mendefinisikan apa yang metode dan kelas yang tersedia dalam platform tertentu. Tidak ada daftar tetap eksekusi lingkungan, karena dapat berubah sebagai Java Community Process menciptakan versi baru dan edisi Jawa.
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
Beberapa VMS masing-masing berjalan sistem operasi mereka sendiri (yang disebut sistem operasi tamu) yang sering digunakan di server konsolidasi, di mana layanan yang berbeda yang digunakan untuk menjalankan mesin individu untuk menghindari gangguan yang terpisah, bukan berjalan di VMS pada mesin fisik yang sama. Penggunaan ini sering disebut-kualitas dari layanan-isolasi (QoS isolasi).
Keinginan untuk menjalankan beberapa sistem operasi adalah motivasi asli untuk mesin virtual, seperti time-sharing memungkinkan satu komputer di antara beberapa single-tasking OS. Teknik ini memerlukan proses untuk berbagi sumber daya CPU antara sistem operasi tamu dan memori virtualisasi untuk berbagi memori pada host.
OS tamu tidak harus sama, sehingga memungkinkan untuk menjalankan OS yang berbeda pada komputer yang sama (misalnya, Microsoft Windows dan Linux, atau versi lama dari sistem operasi untuk mendukung perangkat lunak yang belum porting ke versi terbaru). Penggunaan mesin virtual untuk mendukung OS tamu yang berbeda menjadi populer di embedded system; tipikal digunakan adalah untuk mendukung real-time sistem operasi pada saat yang sama sebagai OS tingkat tinggi seperti Linux atau Windows.
Penggunaan lainnya adalah untuk sandbox sebuah OS yang tidak dipercaya, mungkin karena itu adalah sebuah sistem dalam pengembangan. Mesin virtual memiliki keuntungan untuk OS lain pembangunan, termasuk akses debugging yang lebih baik dan lebih cepat reboot.
Teknik alternatif seperti Solaris Zones menyediakan tingkat isolasi dalam satu sistem operasi. Ini tidak memiliki isolasi selengkap sebagai VM. Sebuah kernel mengeksploitasi dalam suatu sistem dengan beberapa zona akan mempengaruhi semua zona. Mencapai tujuan yang sama dalam implementasi mesin virtual akan membutuhkan mengeksploitasi kelemahan dalam hypervisor. Sebuah hypervisor biasanya memiliki lebih kecil "serangan permukaan" dari sebuah sistem operasi yang lengkap, membuat ini lebih menantang. Lebih lanjut, sebuah kernel mengeksploitasi tamu di VM tidak akan mempengaruhi VMS lain pada host, seperti gangguan yang sukses menjadi satu zona belum tentu mempengaruhi zona lain.
Zona tidak mesin virtual, tetapi contoh "virtualisasi sistem operasi". Ini termasuk lain "lingkungan virtual" (juga disebut "virtual server") seperti Virtuozzo, FreeBSD penjara, Linux-VServer, chroot penjara, dan OpenVZ. Ini memberikan beberapa bentuk rangkuman proses dalam sebuah sistem operasi. Teknologi ini memiliki keunggulan sumber daya yang lebih efisien daripada virtualisasi penuh dan memiliki lebih baik observability menjadi beberapa tamu secara simultan; yang merugikan adalah bahwa, pada umumnya, mereka hanya dapat menjalankan satu sistem operasi dan satu versi / patch tingkat sistem operasi bahwa -- jadi, misalnya, mereka tidak dapat digunakan untuk menjalankan dua aplikasi, salah satu yang hanya mendukung versi OS yang lebih baru dan yang lain hanya mendukung versi OS yang lebih lama pada hardware yang sama. However, Sun Microsystems has enhanced Solaris Zones to allow some zones to behave like Solaris 8 or Solaris 9 systems by adding a system call translator. Namun, Sun Microsystems telah meningkatkan Solaris Zones untuk memungkinkan beberapa zona untuk berperilaku seperti Solaris 8 atau Solaris 9 sistem dengan menambahkan system call penerjemah.
• Proses mesin virtual
Sebuah proses VM, kadang-kadang disebut aplikasi mesin virtual, berjalan sebagai aplikasi biasa di dalam sebuah OS dan mendukung proses tunggal. Hal ini tercipta ketika proses itu dimulai dan hancur ketika keluar. Tujuannya adalah untuk menyediakan sebuah platform-independen lingkungan pemrograman yang abstrak pergi rincian perangkat keras yang mendasarinya atau sistem operasi, dan memungkinkan sebuah program untuk mengeksekusi dengan cara yang sama pada platform apapun.
Sebuah proses VM memberikan abstraksi tingkat tinggi - yaitu yang tinggi tingkat bahasa pemrograman (dibandingkan dengan tingkat rendah ISA abstraksi dari sistem VM). VMS proses diimplementasikan menggunakan interpreter; kinerja yang sebanding dengan bahasa pemrograman terkompilasi dicapai dengan menggunakan just-in-time compilation .
Jenis VM ini telah menjadi populer dengan bahasa pemrograman Java, yang diimplementasikan menggunakan mesin virtual Java. Contoh lain termasuk Bayan mesin virtual, yang berfungsi sebagai lapisan abstraksi selama beberapa ditafsirkan lanugages, dan. NET Framework, yang berjalan pada sebuah VM yang disebut Common Language Runtime.
Suatu kasus khusus VMS adalah proses sistem yang abstrak atas mekanisme komunikasi yang (berpotensi heterogen) komputer cluster. Seperti VM tidak terdiri dari sebuah proses tunggal, tetapi satu proses per mesin fisik di cluster. Mereka dirancang untuk memudahkan tugas pemrograman aplikasi paralel dengan membiarkan programmer fokus pada algoritma daripada mekanisme komunikasi yang disediakan oleh interkoneksi dan OS. Mereka tidak menyembunyikan fakta bahwa terjadi komunikasi, dan dengan demikian tidak berusaha untuk menyajikan cluster sebagai satu mesin paralel.
Tidak seperti proses lain VMS, sistem ini tidak menyediakan bahasa pemrograman tertentu, tetapi tertanam dalam bahasa yang ada; biasanya sistem seperti menyediakan binding untuk beberapa bahasa (misalnya, C dan FORTRAN). Examples are PVM ( Parallel Virtual Machine ) and MPI ( Message Passing Interface ). Contohnya adalah PVM (Paralel Virtual Machine) dan MPI (Message Passing Interface). Mereka tidak ketat mesin virtual, sebagai aplikasi yang berjalan di atas masih memiliki akses ke semua layanan OS, dan karena itu tidak terbatas pada model sistem yang disediakan oleh "VM".
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, dikatakan sebuah implementasi dari API dimana 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. Hal ini menguntungkan kedua penyedia perangkat lunak (di mana mereka dapat mendistribusikan perangkat lunak yang ada pada sistem baru tanpa memproduksi / mendistribusikan upgrade) dan pengguna (di mana mereka mungkin lebih tua menginstal perangkat lunak pada sistem baru mereka tanpa membeli upgrade), meskipun hal ini memerlukan berbagai perangkat lunak secara umum pelaksanaan perpustakaan API diperlukan juga.
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.
Antara Unix-seperti sistem operasi, ada banyak terkait tetapi tidak sesuai sistem operasi berjalan pada platform hardware yang umum (khususnya Intel 80386 sistem yang kompatibel). Sudah ada beberapa usaha untuk standarisasi API vendor perangkat lunak sehingga dapat mendistribusikan satu aplikasi binari untuk semua sistem ini, namun sampai saat ini, tidak satu pun telah bertemu dengan banyak keberhasilan. Linux Standard Base adalah berusaha untuk melakukan hal ini untuk Linux platform, sementara banyak dari beragam Unix BSD (FreeBSD, NetBSD, OpenBSD) menerapkan berbagai tingkat kompatibilitas API untuk kedua backward compatibility (memungkinkan program yang ditulis untuk versi lama untuk berjalan di distribusi baru sistem) dan lintas-platform kompatibilitas (memungkinkan eksekusi kode asing tanpa mengkompilasi ulang).
source :
OSGi - http://en.wikipedia.org/wiki/OSGi
Open Service Gateway Initiative (OSGI), Spesifikasi OSGI – http://ayazmaniez.wordpress.com/2009/11/24/open-service-gateway-initiative-osgi/
http://jabberfunky.wordpress.com/2012/10/10/osgi/
http://addebetycaem.blogspot.com/2011/01/spesifikasi-dari-open-services-gateway.html
http://athanasiustrilasto.blogspot.com/2012/11/fungsional-dari-amic-automotive.html
http://code86.wordpress.com/2009/11/19/layanan-interface-dan-fitur-fitur-telematika/
http://translate.google.co.id/translate?hl=id&sl=en&u=http://en.wikipedia.org/wiki/Virtual_machine&ei=dVgRS-DgIY2OMc2mzTM&sa=X&oi=translate&ct=result&resnum=1&ved=0CA4Q7gEwAA&prev=/search%3Fq%3Dvirtual%2Bmachine%26hl%3Did%26client%3Dfirefox-a%26rls%3Dorg.mozilla:en-US:official%26hs%3DqER
http://translate.google.co.id/translate?hl=id&sl=en&tl=id&u=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FAPI
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.
1.1. Spesifikasi
Spesifikasi OSGi dikembangkan oleh para anggota dalam proses terbuka dan tersedia untuk publik secara gratis di bawah Lisensi Spesifikasi OSGi. The Alliance OSGi memiliki kepatuhan program yang hanya terbuka untuk anggota. Pada November 2010, ada tujuh bersertifikat OSGi kerangka implementasi . Sebuah halaman terpisah daftar baik bersertifikat dan non-bersertifikat Implementasi Spesifikasi OSGi, yang meliputi kerangka OSGi dan spesifikasi OSGi lainnya.
Kerangka OSGi (OSGi framework)
Kerangka OSGi adalah sistem modul dan layanan platform untuk Java bahasa pemrograman yang menerapkan lengkap dan dinamis model komponen , sesuatu yang seperti tahun 2012 tidak ada di Jawa standalone / VM lingkungan. Aplikasi atau komponen (datang dalam bentuk dari bundel untuk penyebaran) dapat jarak jauh diinstal, mulai, berhenti, diperbarui, dan dihapus tanpa memerlukan restart, pengelolaan paket Jawa / kelas ditentukan dengan sangat rinci. Aplikasi manajemen siklus hidup (start, stop, install, dll) dilakukan melalui API yang memungkinkan untuk remote download dari kebijakan manajemen. Registri layanan memungkinkan berkas untuk mendeteksi penambahan layanan baru, atau penghapusan layanan dan beradaptasi sesuai.
Spesifikasi OSGi telah bergerak melampaui fokus asli gateway layanan, dan sekarang digunakan dalam aplikasi mulai dari ponsel ke open source Eclipse IDE. Area aplikasi lainnya termasuk mobil, otomasi industri, otomatisasi bangunan, PDA, komputasi grid, hiburan, armada manajemen dan aplikasi server .
1.2. Arsitektur (Architecture)
Setiap kerangka yang menerapkan standar OSGi menyediakan suatu lingkungan untuk modularisasi aplikasi ke dalam bundel kecil. Setiap bundel adalah koleksi, erat dynamically loadable kelas, guci, dan file konfigurasi yang secara eksplisit menyatakan dependensi eksternal mereka (jika ada).
Kerangka ini secara konseptual dibagi menjadi bidang-bidang berikut:
1. Bundle Bundel adalah sekelompok kelas Java dan sumber daya tambahan yang dilengkapi dengan manifes rinci MANIFEST.MF file pada semua isinya, serta layanan tambahan yang diperlukan untuk memberikan kelompok termasuk kelas Java perilaku yang lebih canggih, sejauh deeming seluruh agregat komponen.
2. Layanan
Layanan yang menghubungkan lapisan bundel dalam cara yang dinamis dengan menawarkan, menerbitkan dan menemukan model dapat mengikat Java lama untuk menikmati objek (POJO). Siklus hidup menambahkan lapisan bundel dinamis yang dapat diinstal, mulai, berhenti, diperbarui dan dihapus. Buntalan bergantung pada lapisan modul untuk kelas loading tetapi menambahkan API untuk mengatur modul – modul dalam run time. Memperkenalkan lapisan siklus hidup dinamika yang biasanya bukan bagian dari aplikasi. Mekanisme ketergantungan luas digunakan untuk menjamin operasi yang benar dari lingkungan.
3. Layanan Registry
The API untuk jasa manajemen (ServiceRegistration , ServiceTracker dan ServiceReference).
4. Life-Cycle
The API ntuk manajemen siklus hidup untuk (instal, start, stop, update, dan uninstall) bundel.
5. Modul
Lapisan ang mendefinisikan enkapsulasi dan deklarasi dependensi (bagaimana sebuah bungkusan dapat mengimpor dan mengekspor kode).
6. Keamanan
Lapisan yang menangani aspek keamanan dengan membatasi fungsionalitas bundel untuk pra-didefinisikan kemampuan.
7. Eksekusi Lingkungan
Mendefinisikan apa yang metode dan kelas yang tersedia dalam platform tertentu. Tidak ada daftar tetap eksekusi lingkungan, karena dapat berubah sebagai Java Community Process menciptakan versi baru dan edisi Jawa.
1.3. Struktural
2. AMIC (Automotive Multimedia Interface Collaboration)
Kolaborasi
antar muka ototmotif multimedia adalah sebuah organisasi yang dibentuk
untuk menciptakan standarisasi dunia yang digunakan dalam mengatur
bagaimana sebuah perangkat elektronik dapat bekerja. Contoh Komputer
dan alat komunikasi kendaraan atau computer dan radio dalam mobil.
Satiap alat elektronik itu harus dapat bekerja dengan selaras sehingga
kendaraan dapat lebih handal.
Setiap perangkat elektronik yang dipasang belum tentu cocok dengan setiap kendaraan. Perangkat elektronik atau multimedia bisa saja mengganggu sistem keselamatan dan system-sistem lain di dalam kendaraan. Itulah kenapa perlu dibentuk standarisasi kolaborasi antarmuka multimedia.
Automotive Multimedia Interface Collaboration (AMI-C) sudah memiliki anggota : Fiat, Ford, General Motors, Honda, Mitsubishi, Nissan, PSA Peugeot-Citroen, Renault. AMI-C mengembangkan dan men-standarisasi antarmuka multimedia dan telematika otomotif yang umum untuk jaringan komunikasi kendaraan. Dan 40 pemasok elektronik mendaftarkan diri untuk menulis standar. Mereka berpendapat untuk menulis standar diperlukan waktu selama 2 tahun. Tapi dua tahun adalah masa di telematika. Penyelenggara elektronik, ponsel, komputer dan peralatan video yang akan menggunakan koneksi dapat melewati beberapa generasi dalam waktu itu.
Standar-standar akan memungkinkan sebuah pasar plug-and-play global untuk perangkat elektronik yang akan dipasang di kendaraan dengan kemudahan yang sama dengan melampirkan pheriperal komputer pribadi.
Setiap perangkat elektronik yang dipasang belum tentu cocok dengan setiap kendaraan. Perangkat elektronik atau multimedia bisa saja mengganggu sistem keselamatan dan system-sistem lain di dalam kendaraan. Itulah kenapa perlu dibentuk standarisasi kolaborasi antarmuka multimedia.
Automotive Multimedia Interface Collaboration (AMI-C) sudah memiliki anggota : Fiat, Ford, General Motors, Honda, Mitsubishi, Nissan, PSA Peugeot-Citroen, Renault. AMI-C mengembangkan dan men-standarisasi antarmuka multimedia dan telematika otomotif yang umum untuk jaringan komunikasi kendaraan. Dan 40 pemasok elektronik mendaftarkan diri untuk menulis standar. Mereka berpendapat untuk menulis standar diperlukan waktu selama 2 tahun. Tapi dua tahun adalah masa di telematika. Penyelenggara elektronik, ponsel, komputer dan peralatan video yang akan menggunakan koneksi dapat melewati beberapa generasi dalam waktu itu.
Standar-standar akan memungkinkan sebuah pasar plug-and-play global untuk perangkat elektronik yang akan dipasang di kendaraan dengan kemudahan yang sama dengan melampirkan pheriperal komputer pribadi.
Tujuan dari AMIC ini antara lain menyediakan
interface standar untuk memungkinkan pengendara mobil untuk menggunakan
berbagai media, komputer dan perangkat komunikasi - dari sistem
navigasi dan hands-free telepon selular, melalui manusia maju / mesin
sistem antarmuka, termasuk pengenalan suara dan sintesis, untuk
dipersembahkan komunikasi jarak dekat (DSRC) sistem untuk kendaraan
untuk infrastruktur komunikasi dan sistem mobil seperti airbag, pintu
kunci dan diagnostik input / output.
3. JAP (Java Community Process)
Java dikembangkan mengacu pada standar yang ditentukan oleh komite didalam JCP (Java Community Process). Spesifikasi Java tidak sekedar fondasi VMnya, tetapi menyangkut hampir semua aspek, mulai dari mekanisme mengakses devices I/O, komponen pertukaran objek, sampai pengembangan container. JCP merupakan badan yang bertanggung jawab terhadap standar teknologi Java.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
Beberapa VMS masing-masing berjalan sistem operasi mereka sendiri (yang disebut sistem operasi tamu) yang sering digunakan di server konsolidasi, di mana layanan yang berbeda yang digunakan untuk menjalankan mesin individu untuk menghindari gangguan yang terpisah, bukan berjalan di VMS pada mesin fisik yang sama. Penggunaan ini sering disebut-kualitas dari layanan-isolasi (QoS isolasi).
Keinginan untuk menjalankan beberapa sistem operasi adalah motivasi asli untuk mesin virtual, seperti time-sharing memungkinkan satu komputer di antara beberapa single-tasking OS. Teknik ini memerlukan proses untuk berbagi sumber daya CPU antara sistem operasi tamu dan memori virtualisasi untuk berbagi memori pada host.
OS tamu tidak harus sama, sehingga memungkinkan untuk menjalankan OS yang berbeda pada komputer yang sama (misalnya, Microsoft Windows dan Linux, atau versi lama dari sistem operasi untuk mendukung perangkat lunak yang belum porting ke versi terbaru). Penggunaan mesin virtual untuk mendukung OS tamu yang berbeda menjadi populer di embedded system; tipikal digunakan adalah untuk mendukung real-time sistem operasi pada saat yang sama sebagai OS tingkat tinggi seperti Linux atau Windows.
Penggunaan lainnya adalah untuk sandbox sebuah OS yang tidak dipercaya, mungkin karena itu adalah sebuah sistem dalam pengembangan. Mesin virtual memiliki keuntungan untuk OS lain pembangunan, termasuk akses debugging yang lebih baik dan lebih cepat reboot.
Teknik alternatif seperti Solaris Zones menyediakan tingkat isolasi dalam satu sistem operasi. Ini tidak memiliki isolasi selengkap sebagai VM. Sebuah kernel mengeksploitasi dalam suatu sistem dengan beberapa zona akan mempengaruhi semua zona. Mencapai tujuan yang sama dalam implementasi mesin virtual akan membutuhkan mengeksploitasi kelemahan dalam hypervisor. Sebuah hypervisor biasanya memiliki lebih kecil "serangan permukaan" dari sebuah sistem operasi yang lengkap, membuat ini lebih menantang. Lebih lanjut, sebuah kernel mengeksploitasi tamu di VM tidak akan mempengaruhi VMS lain pada host, seperti gangguan yang sukses menjadi satu zona belum tentu mempengaruhi zona lain.
Zona tidak mesin virtual, tetapi contoh "virtualisasi sistem operasi". Ini termasuk lain "lingkungan virtual" (juga disebut "virtual server") seperti Virtuozzo, FreeBSD penjara, Linux-VServer, chroot penjara, dan OpenVZ. Ini memberikan beberapa bentuk rangkuman proses dalam sebuah sistem operasi. Teknologi ini memiliki keunggulan sumber daya yang lebih efisien daripada virtualisasi penuh dan memiliki lebih baik observability menjadi beberapa tamu secara simultan; yang merugikan adalah bahwa, pada umumnya, mereka hanya dapat menjalankan satu sistem operasi dan satu versi / patch tingkat sistem operasi bahwa -- jadi, misalnya, mereka tidak dapat digunakan untuk menjalankan dua aplikasi, salah satu yang hanya mendukung versi OS yang lebih baru dan yang lain hanya mendukung versi OS yang lebih lama pada hardware yang sama. However, Sun Microsystems has enhanced Solaris Zones to allow some zones to behave like Solaris 8 or Solaris 9 systems by adding a system call translator. Namun, Sun Microsystems telah meningkatkan Solaris Zones untuk memungkinkan beberapa zona untuk berperilaku seperti Solaris 8 atau Solaris 9 sistem dengan menambahkan system call penerjemah.
• Proses mesin virtual
Sebuah proses VM, kadang-kadang disebut aplikasi mesin virtual, berjalan sebagai aplikasi biasa di dalam sebuah OS dan mendukung proses tunggal. Hal ini tercipta ketika proses itu dimulai dan hancur ketika keluar. Tujuannya adalah untuk menyediakan sebuah platform-independen lingkungan pemrograman yang abstrak pergi rincian perangkat keras yang mendasarinya atau sistem operasi, dan memungkinkan sebuah program untuk mengeksekusi dengan cara yang sama pada platform apapun.
Sebuah proses VM memberikan abstraksi tingkat tinggi - yaitu yang tinggi tingkat bahasa pemrograman (dibandingkan dengan tingkat rendah ISA abstraksi dari sistem VM). VMS proses diimplementasikan menggunakan interpreter; kinerja yang sebanding dengan bahasa pemrograman terkompilasi dicapai dengan menggunakan just-in-time compilation .
Jenis VM ini telah menjadi populer dengan bahasa pemrograman Java, yang diimplementasikan menggunakan mesin virtual Java. Contoh lain termasuk Bayan mesin virtual, yang berfungsi sebagai lapisan abstraksi selama beberapa ditafsirkan lanugages, dan. NET Framework, yang berjalan pada sebuah VM yang disebut Common Language Runtime.
Suatu kasus khusus VMS adalah proses sistem yang abstrak atas mekanisme komunikasi yang (berpotensi heterogen) komputer cluster. Seperti VM tidak terdiri dari sebuah proses tunggal, tetapi satu proses per mesin fisik di cluster. Mereka dirancang untuk memudahkan tugas pemrograman aplikasi paralel dengan membiarkan programmer fokus pada algoritma daripada mekanisme komunikasi yang disediakan oleh interkoneksi dan OS. Mereka tidak menyembunyikan fakta bahwa terjadi komunikasi, dan dengan demikian tidak berusaha untuk menyajikan cluster sebagai satu mesin paralel.
Tidak seperti proses lain VMS, sistem ini tidak menyediakan bahasa pemrograman tertentu, tetapi tertanam dalam bahasa yang ada; biasanya sistem seperti menyediakan binding untuk beberapa bahasa (misalnya, C dan FORTRAN). Examples are PVM ( Parallel Virtual Machine ) and MPI ( Message Passing Interface ). Contohnya adalah PVM (Paralel Virtual Machine) dan MPI (Message Passing Interface). Mereka tidak ketat mesin virtual, sebagai aplikasi yang berjalan di atas masih memiliki akses ke semua layanan OS, dan karena itu tidak terbatas pada model sistem yang disediakan oleh "VM".
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, dikatakan sebuah implementasi dari API dimana 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. Hal ini menguntungkan kedua penyedia perangkat lunak (di mana mereka dapat mendistribusikan perangkat lunak yang ada pada sistem baru tanpa memproduksi / mendistribusikan upgrade) dan pengguna (di mana mereka mungkin lebih tua menginstal perangkat lunak pada sistem baru mereka tanpa membeli upgrade), meskipun hal ini memerlukan berbagai perangkat lunak secara umum pelaksanaan perpustakaan API diperlukan juga.
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.
Antara Unix-seperti sistem operasi, ada banyak terkait tetapi tidak sesuai sistem operasi berjalan pada platform hardware yang umum (khususnya Intel 80386 sistem yang kompatibel). Sudah ada beberapa usaha untuk standarisasi API vendor perangkat lunak sehingga dapat mendistribusikan satu aplikasi binari untuk semua sistem ini, namun sampai saat ini, tidak satu pun telah bertemu dengan banyak keberhasilan. Linux Standard Base adalah berusaha untuk melakukan hal ini untuk Linux platform, sementara banyak dari beragam Unix BSD (FreeBSD, NetBSD, OpenBSD) menerapkan berbagai tingkat kompatibilitas API untuk kedua backward compatibility (memungkinkan program yang ditulis untuk versi lama untuk berjalan di distribusi baru sistem) dan lintas-platform kompatibilitas (memungkinkan eksekusi kode asing tanpa mengkompilasi ulang).
source :
OSGi - http://en.wikipedia.org/wiki/OSGi
Open Service Gateway Initiative (OSGI), Spesifikasi OSGI – http://ayazmaniez.wordpress.com/2009/11/24/open-service-gateway-initiative-osgi/
http://jabberfunky.wordpress.com/2012/10/10/osgi/
http://addebetycaem.blogspot.com/2011/01/spesifikasi-dari-open-services-gateway.html
http://athanasiustrilasto.blogspot.com/2012/11/fungsional-dari-amic-automotive.html
http://code86.wordpress.com/2009/11/19/layanan-interface-dan-fitur-fitur-telematika/
http://translate.google.co.id/translate?hl=id&sl=en&u=http://en.wikipedia.org/wiki/Virtual_machine&ei=dVgRS-DgIY2OMc2mzTM&sa=X&oi=translate&ct=result&resnum=1&ved=0CA4Q7gEwAA&prev=/search%3Fq%3Dvirtual%2Bmachine%26hl%3Did%26client%3Dfirefox-a%26rls%3Dorg.mozilla:en-US:official%26hs%3DqER
http://translate.google.co.id/translate?hl=id&sl=en&tl=id&u=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FAPI
