Rabu, 08 Januari 2014

JURNAL TELEMATIKA MIDDLEWARE

UNIVERSITAS GUNADARMA
FAKULTAS ILMU KOMPUTER & TEKNOLOGI INFORMASI



TUGAS PENGANTAR TELEMATIKA




Nama & NPM             :  Maulana Syarif Hidayatulloh | 14110275
Slamet Raharjo | 16110630
Vicky Ariesca Merliana | 19110701
Fakultas                       :  Ilmu Komputer dan Teknologi Informasi
Jurusan                        :  Sistem Informasi
Kelas                           :  4KA11




Depok
2013

ABSTRAKSI

Maulana Syarif Hidayatulloh | 14110275
Slamet Raharjo | 16110630
Vicky Ariesca Merliana | 19110701
Tugas Pengantar Telematika. Jurusan Sistem Informasi, Fakultas Ilmu Komputer dan Teknologi Informasi, Universitas Gunadarma, 2013
Kata Kunci : Middleware, Pengantar Telematika, Platform

(iii + 11 halaman)

Dalam pemrograman client server tingkat lanjut,adalah memungkinkan untuk membangun sebuahaplikasi dengan dasar platform pemrograman yang berbeda-beda. Dalam pemrograman jaringan biasa / konvesional, maka tidak akan mampu untuk mengkoneksikan dua atau lebih platform yang berbeda.
Untuk membangun aplikasi itu maka dibutuhkan sebuah lapisan yang bisa menghubungkan platform pemrograman yang berbeda, lapisan yang dimaksudkan adalah diistilahkan sebagai ‘middleware’. Middleware pada tataran implementasi merupakan sebuah paket program instan yang dipakai pada suatu platform permograman tertentu, sedangkan pada tataran konsep, middleware mer upakan sebuah lapisan untuk lalulintas penghubung komunikasi antar objek dari sistem yang berbeda. Ada beberapa jenis middleware, seperti ORB (Object Request Broker), RMI (Remote Method Invocation), dan MOM (Message Oriented Middleware).
Dalam tulisan ini akan dibahas tentang pemahaman dan tujuan umum dari middleware, lingkungan komputasi dari middleware, memahami kebutuhan middleware, serta mengenal contoh-contoh middleware.

Daftar Pustaka (2012-2013)





ii
  



DAFTAR ISI

Halaman
Halaman Judul.............................................................................................................................i
Abstraksi....................................................................................................................................ii
Daftar Isi...................................................................................................................................iii
Bab I  PENDAHULUAN...........................................................................................................1
1.1  Latar Belakang Masalah.....................................................................................................1
1.2  Batasan Masalah.................................................................................................................1
1.3  Tujuan Penulisan........................................................................................................2
1.4  Metode Penelitian......................................................................................................2
Bab II TINJAUAN PUSTAKA..................................................................................................3
2.1 Middleware dan Enterprise ApplicationIntegration.................................................3
2.2 Middleware ORB dalam framework CORBA.........................................................3
2.3 Software CORBA-ORB...........................................................................................6
2.4 Interface Definition Language (IDL).......................................................................7
Bab III ANALISA DAN PEMBAHASAN................................................................................8
           3.1 Implementasi Pemrograman Jaringan Menggunakan Middleware CORBA-ORB...8
           3.2 Implementasi Pemrograman......................................................................................9
Bab IV PENUTUP...................................................................................................................10
           4.1 Kesimpulan..............................................................................................................10
DAFTAR PUSTAKA..............................................................................................................11

iii

I. PENDAHULUAN

1.1 Latar belakang masalah
Untuk membangun sebuah aplikasi client server multi platform programming salah satu cara adalah dengan memanfaatkan middleware. Middleware bias dijelaskan pada 2 tataran, yaitu tataran konsep/paradigma dan tataran aplikasi pemrograman.
Pada tataran konsep, middleware digunakan sebagai jembatan atau penghubung dua aplikasi atau lebih yang memiliki perbedaan, middleware kadang disebut sebagai plumbing karena middleware digunakan untuk menghubungkan 2 bagian dari sebuah aplikasi dan digunakan untuk melewatkan data diantara mereka. Pada tataran implementasi, middleware adalah sebuah paket program instan yang digunakan untuk menghubungkan dua program yang berbeda platforma atau produk/vendor. Beberapa jenis middleware yang bisa digunakan untuk pemrograman adalah ORB, RPC, RMI, DCE, dan MOM. Produk Middleware biasanya di pakai oleh sebuah arsitektur atau framework pemrograman.
ORB (Object Request Broker) dimiliki oleh arsitektur atau framework pemrograman CORBA (Common Object Request Broker Architectur) dan JAVA, RMI (Remothe Method Invocation) dimiliki oleh teknologi JAVA. Pada tulisan ini akan dijelaskan konsep dan implementasi pemrograman middleware ORB pada framework CORBA, dengan kasus client server berbeda platform pemrograman. Tulisan ini akan dibagi menjadi beberapa bagian. Bagian berikutnya adalah bagian II akan membahas tentang middleware-middleware yang bisa membangun aplikasi bisnis (EAI).
Pada bagian ini juga akan dibahasa CORBA-ORB serta arsitektur frameworknya. Pembahasan tentang konsep dan implementasi pemrograman dengan middleware ini akan dibahas pada bagian III dan pada bagian IV akan dibahas tentang tinjauan kritis penggunaan middleware dalam membangun aplikasi client server.
1.2  Batasan Masalah
Berdasarkan masalah diatas maka ruang lingkup penulisan dibatasi pada pemanfaatan middleware ORB (Object Request Broker)
1

1.3 Tujuan Penulisan
Pembuatan makalah ini disusun untuk memberikan kemudahan dan pengetahuan tentang middleware telematika. Memberikan pengetahuan lebih tentang konsep pemrograman jaringan dengan memanfaatkan middleware ORB (Object Request Broker) 

1.4 Metode Penelitian
Beragai data yang digunakan dalam penulisan ini diperoleh dari studi pustaka dengan mencari bahan dasar sebagai acuan teori dan bahan dari beragai buku dan situs-situs terpercaya pada internet serta beberapa referensi yang berhubungan dengan permasalahan yang akan dibahas penulis.


2

II. TINJAUAN PUSTAKA

2.1 Middleware dan Enterprise ApplicationIntegration
Middleware adalah sebuah aplikasi yang secara logic berada diantara lapisan aplikasi (application layer) dan lapisan data dari sebuah arsitektur layer-layer TCP/IP . Middleware bisa juga disebut protokol. Protokol komunikasi middleware mendukung layanan komunikasi aras tinggi.
Biasanya program middleware menyediakan layanan pesan (messaging services) sehingga aplikasi-aplikasi yang berbeda-beda itu dapat berkomunikasi. Sistem middleware mengikat aplikasi-aplikasi yang terpisah. Penggunaannya dalam aplikasi bisnis dikenal sebagai Enterprise Application Integration (EAI).
Middleware EAI membuat penghubung antara aplikasi-aplikasi dalam berbagai cara, namun secara umum cara ini diistilahkan sebagai transformasi dan routing data dan mengatur aliran proses bisnis. Ada implikasi dalam hal ini bahwa aplikasi-aplikasi itu ber ada dalam sebuah dunia heterogenitas – perbedaan platform operasi, pemisahan model data dan penyimpan data, heterogenitas jaringan dan protocol komunikasi.

2.2 Middleware ORB dalam framework CORBA
CORBA (Common Object Request Broker Architecture) adalah sebuah standar system terdistribusi yang dikembangkan oleh OMG (Object Management Group), yaitu sebuah konsorsium yang terdiri dari lebih dari 800 perusahaan untuk membantu dalam pemrograman objek-objek terdistribusi. CORBA adalah sebuah cara bagi objekobjek untuk melakukan interoperasi lintas jaringan. Sejak spesifikasi CORBA versi 1.2 diperkenalkan pada tahun 1991, CORBA memberikan sebuah mekanisme standar bagi komunikasi antar objek lintas jaringan, kemudian spesifikasi CORBA tersebut berkembang dengan diperkenalkannya CORBA 2.0 di tahun 1994 dan CORBA 3.0 yang direlease tahun 2000. Hal yang penting untuk dicatat bahwa CORBA hanya sebuah spesifikasi untuk membuat dan menggunakan objek-objek terdistribusi, CORBA bukan sebuah produk atau bahasa pemrograman.
3

Vendor-vendor yang ingin membuat produk-produk yang mengikuti spesifikasi CORBA dapat bebas untuk melakukannya. Tetapi yang perlu ditekankan/diyakinkan adalah bahwa vendor-vendor tersebut mengikuti spesifikasi CORBA secara persis sama. Hal ini agar semua produk yang dihasilkan vendor-vendor tersebut memiliki keselarasan dengan CORBA (CORBA compliant), sehingga satu sama lain dapat berinteraksi. Hal lain yang perlu diingat bahwa CORBA independen terhadap bahasa pemrograman selama bahasa-bahasa pemrograman tersebut memiliki pemeta (mapping) dari bahasa definisi interface dalam CORBA.

CORBA merupakan sebuah spesifikasi middleware yang ideal untuk mendukung dan mengaplikasikan sistem komputer terdistribusi. Arsitektur CORBA berbasis pada model objek. Model ini berasal dari abstraksi inti model objek yang didefinisikan oleh OMG dalam sebuah petunjuk OMA (Object Management Architecture), yang dapat ditemukan dalam [2]. Beberapa hal penting yang perlu dicatat bahwa CORBA berbeda dengan pemrograman objek serupa adalah:
1.      Objek-objek CORBA dapat berjalan dalam berbagai platform.
2.      Objek-objek CORBA ditempatkan di manapun dalam jaringan.
3.      Objek-objek CORBA dapat ditulis dalam beberapa bahasa pemrograman yang memiliki pemeta IDL (IDL mapping).

Bersifat open, maksudnya bahwa CORBA bias dipakai oleh setiap orang yang ingin menggunakan standarisasi CORBA ini. Sehingga akan muncul perbedaan-perbedaan dalam menggunakannya, seperti perbedaan platform ataupun bahasa pemrograman. Tetapi hal ini justru menjadi kelebihan CORBA bahwa CORBA mampu mengkomunikasikan sistem yang memiliki perbedaan-perbedaan tersebut.
CORBA merupakan sebuah arsitektur yang menyediakan sebuah framework crossplatform untuk membangun dan mengembangkan sistem objek terdistribusi. Ide utama dibelakang CORBA adalah sebuah perangkat lunak perantara (intermedier) atau disebut middleware yang mengatur dan menyebarkan akses request ke sekumpulan data tertentu. Perangkat lunak perantara ini adalah Middleware ORB (Object Request Broker).
4

ORB melakukan interaksi dan membuat request ke berbagai macam objek. ORB ini terletak diantara layer data dan layer aplikasi dalam susunan arsitektur jaringan 7 layer model OSI. ORB akan melakukan negosiasi antara pesan request dari objek ke objek atau dari objek server ke sekumpulan data (data set). Tujuan CORBA adalah untuk membuat pemrograman lebih mudah dengan membuat aplikasi berbasis CORBA yang sangat portable. Untuk melihat lebih detail tentang arsitektur CORBA dan ORB berada didalamnya, maka CORBA memiliki sebuah arsitektur yang disebut OMA (Object Management Group).OMA mengelompokkan jenis-jenis interak si antar program untuk memudahkan penyediaan dukungan.

https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgumlosozN9sZREV-artIxaxRqqCwK6aNxNXpIHWf5ABo0TUcMdiISL3Ei5f59q0ustyigqI3R9WKUL9uq1lBLGrxrJ1scCN0H91xvSGCwL0oxsgKjcDspOZxDw7vaZCRC9ClZ9KSP0pE4/s1600/HAPUS1.jpg




OMA melakukan strukturisasi dunia aplikasi ke dalam dua kelompok besar: kategori layanan CORBA (CORBAservices) dan kategori fasilitas CORBA (CORBAfacilities). Layanan CORBA menyediakan fungsi-fungsi dasar yang digunakan oleh hampir setiap obyek dalam berbagai aplikasi. Fungsi-fungsi ini biasanya bersifat generik dan tidak tergantung pada jenis domain aplikasi. Sebagai contoh adalah layanan penamaan (naming service). Bayangkan bila memerlukan sebuah layanan tapi tidak tahu kemana harus mencari server yang menyediakan layanan tersebut. Layanan penamaan dapat membantu layaknya sebuah "halaman kuning" (yellow pages) ; dia bisa menyiarkan direktori layanan yang terdaftar padanya. Karena sifatnya yang generik, layanan penamaan dapat digunakan oleh aplikasi dari berbaga i domain.


5

Fasilitas CORBA menyediakan layanan pada level aplikasi. Ada dua jenis fasilitas: horizontal, yang diperlukan oleh berbagai jenis domain (misalnya, user-interface), dan vertikal, yang berlaku khusus untuk domain tertentu. Fasilitas horizontal fungsinya mirip dengan layanan CORBA, tetapi beroperasi pada level yang lebih tinggi karena berhubungan langsung dengan aspek fungsional dari aplikasi. OMG secara terus-menerus melakukan standarisasi terhadap interface untuk komponen-komponen di masing-masing kategori. Semakin banyak layanan dan fasilitas yang distandarisasi, semakin mudah untuk mencapai komputasi terdistribusi berbasis komponen dalam berbagai bidang secara plug-and -play, tanpa terganggu oleh masalah heterogenitas. 


2.3 Software CORBA-ORB
Ada banyak software CORBA-ORB baik yang free dan opensource maupun yang komersil. Yang akan digunakan disini adalah software ORB dari Java yang disebut Java-ORB dan JAC-ORB dari Fu Berlin / Xtradine. Keduanya berbasis Java. Sementara software ORB yang lainnnya dapat dilihat dalam tabel berikut.

https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhW3kDFQ2reiMUYNAaH0w2PQktendchyCZJem4b_UVZTE9QgcyVnkS3QZBid1OuysW_OIk3CmciwAgTT6CFydEp7CueiJxHnUVNw30vBZjGONtKphgepfbh0PnJczbIUJQbgr1O7FjjBCs/s1600/HAPUS2.jpg



Ketika masuk ke pemrograman secara teknis maka yang perlu diketahui adalah sebuah bahasa interface yang digunakan untuk menghubungkan berbagai macam aplikasi. Bahasa ini disebut Interface Definition Language (IDL). Untuk mengenal tentang IDL maka berikut adalah pembahasan tentang IDL.
6
2.4 Interface Definition Language (IDL)
IDL merupakan inti untuk pembuatan aplikasi CORBA. IDL memuat sekumpulan tipe variabel yang kemudian akan dipetakan ke berbagai bahasa pemrograman. Suatu interface dalam CORBA menyediakan sebuah deskripsi fungsi-fungsi yang disediakan untuk sebuah objek. Atribut, method dan parameter adalah informasi-informasi yang dispesifikasi oleh sebuah interface. IDL adalah sebuah bahasa yang menggambarkan objek-objek interface dalam sebuah aplikasi CORBA.
IDL mendefinisikan tipe-tipe objeknya dengan mendefinisikan interface-interfacenya. Sebuah interface terdiri dari sekumpulan nama operasi dan parameter-parameter untuk operasi-operasi tersebut. Catatan bahwa IDL hanya digunakan untuk menggambarkan interface, dan bukan sebuah implementasi. IDL bukan pula bahasa pemrograman. Melalui IDL, sebuah implementasi objek tertentu memberitahukan pada client tentang operasi-operasi apa saja yang tersedia dan memberitahukan bagaimana cara untuk mengambilnya. Dengan definisi IDL, objek-objek CORBA harus dipetakan ke beberapa bahasa pemrograman yang akan digunakan untuk membangun aplikasi client dan juga server. Beberapa bahasa pemrograman yang memiliki pemeta IDL (IDL mapping) adalah C, C++, Java, Smalltalk, Lisp, Basic, Pascal dan Python. Setelah mendefinisikan sebuah interface untuk objek-objek dalam IDL, programmer bebas untuk mengimplementasikan objek-objek dengan menggunakan bahasa pemrograman yang sesuai yang memiliki pemeta IDL. Sebagai sebuah protokol kompiler, IDL bisa digambarkan sebagai berikut:

https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhnIvbn1A0IOacVQxS50ITbFjekMDOktfqu0s2z0AgzQjcJX138eDa7hm0nht4wgGfcAebXU8zOQKmtyTeHVQRjlJFUXR4lwwxEvBJw9lYNOZBgF_G7G4KOpk8kSf9zQXSr-hrhyphenhyphenkoLA8M/s1600/HAPUS+3.jpg




7
III. ANALISA DAN PEMBAHASAN

3.1 Implementasi Pemrograman Jaringan Menggunakan Middleware CORBA-ORB

Untuk membangun aplikasinya ada beberapa langkah yang perlu diperhatikan dalam hal pemrograman menggunakan middleware CORBA-ORB. Langkah-langkah itu adalah :
1.      Membuat rancangan dan analisa kebutuhan system
2.      Men-download software yang akan digunakan (software yang akan digunakan adalah Java-ORB dan JAC-ORB)
3.      Coding atau melakukan langkah-langkah teknis pemrograman
Untuk membangun pemrograman jaringan dengan Middleware CORBA-ORB, maka perlu dianalisa terlebih dahulu hal-hal yang diperlukan sebelum masuk ke langkah coding/pemrograman. Sesuai dengan tujuan yang ingin dibuat adalah aplikasi yang melakukan koneksi melalui ORB, dan bias menunjukkan aplikasi yang terpisah dan berbeda platform, maka bisa digambarkan sebagai berikut :

https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjryhKYJvKve_wIos56kTh1tdwJ-hqV_zll15evikXWsDXURV2BL2myDDC-QVCHRjrDH4Az3h0tot_cfCnlfqsNZvQ2zQzOAgcCsLbXf5DXztY8xbU3CHUTMmBm2LMCf1hcZoPxAlaJw4o/s1600/HAPUS+4.jpg



Dari gambar diatas terlihat bahwa ada 2 aplikasi yang jalan di dua platform pemrograman yang berbeda. Platform yang akan digunakan adalah Java-ORB dan Jac-ORB. 2 aplikasi tersebut juga akan diinstal pada platform sistem operasi yang berbeda. Sistem operasi yang akan digunakan adalah Linux untuk Jac-ORB dan Windows untuk Java-ORB.
8
Dua aplikasi itu pun berada pada mesin yang berbeda. Disisi lain client pun akan menggunakan platform yang berbeda dengan server-nya. Jika ingin mengakses Server Java-ORB, maka yang akan digunakan adalah ORB Name Product Bhs Pemrogrmn Licence JAVA ORB SUN MicroSystem Java Free VisiBroker Visigenic/Borland Java, C++, Delphi Evaluation JacORB Fu Berlin/XTRADyneJava Free MICO Mico.org/GPL Soft. C++ Free ISP Rusian Univ C++ Free ORBacus IONA Java, C++ Free OMNIORB OMNI Java, C++ Evaluation VBORB Visual Basic Free MTdORB Phyton Phyton Free. Aplikasi Client yang dibuat dengan JAC-ORB. Sedangkan jika client ingin mengakses aplikasi yang ada di platform JAC-ORB, maka akan digu nakan aplikasi client yang dibangun dengan Java-ORB.

3.2 Implementasi Pemrograman
Beberapa langkah yang harus dilakukan untuk membangun aplikasi sesuai dengan arsitektur diatas adalah :
1.      Membuat bahasa definisi IDL
2.      Membuat aplikasi Server
3.      Membuat Aplikasi Client
4.      Mengkompilasi semua class yang telah dibuat

Contoh kasus ini adalah program jumlah() dan kurang() untuk server Java-ORB dan program kali() dan bagi() untuk server JAC-ORB. Dua file tersebut kemudian dikompilasi dengan menggunakan IDL Compiler yang dimiliki oleh Java- ORB dan JAC-ORB.

Langkah berikutnya membuat aplikasi server untuk kedua ORB yang digunakan. Dua file server diatas sebelum diinstallkan di dua komputer server yang berbeda terlebih dulu di kompilasi. Karena secara default Client tidak bsa mengakses kedua server tersebut, maka langkah berikutnya adalah membuat aplikasi Client dengan CORBA (JAVA-ORB dan JAC-ORB) sebagai Middleware. Setelah CORBAdijalankan, Client dapat mengakses kedua server tersebut.
Hasil akhir dari percobaan ini adalah terbukti bahwa CORBA dapat menghubungkan server sebagai middleware yang berbeda platform dengan client.

9


4. PENUTUP

4.1  Kesimpulan
Kesimpulan yang diperoleh dari hasil penulisan makalah ini yaitu : Middleware CORBA-ORB bisa membangun dua buah sistem untuk bisa saling melakukan interoperasi. Kemudian Middleware CORBA-ORB juga sangat membantu untuk pengembangan skala program aplikasi. Dan kesimpulan yang terakhir Middleware CORBA-ORB dapat memudahkan untuk pengembangan tim developer.
Hal yang sangat menarik dari pemrograman dengan memanfaatkan middleware CORBA-ORB adalah isu tentang interoperasi, atau diistilahkan interoperabilitas. Isu ini memandang 2 sistem berbeda yang ingin melakukan komunikasi. Middleware CORBA-ORB bisa dijadikan suatu fasilitator untuk melakukan interoperasi itu. Middle ware CORBA-ORB juga bisa digunakan untuk penghubung dari banyak aplikasi yang berbeda platform bahasa pemrograman.
Isu yang lain yang juga terlibat dalam pemrograman middleware CORBA-ORB adalah masalah scalability. Isu ini dimaksudkan untuk penambahan / perluasan skala pengembangan aplikasi. Untuk membuat aplikasi jaringan client server tidak dibatasi dengan satu platform pemrograman saja tetapi bias lebih luas lagi dengan berbagai platform pemrograman.
Isu yang juga menarik adalah kemudahan pengembangan. Dengan sistem terpisah-pisah secara fisik maupun logika, maka tim developer bias dipecah-pecah secara mudah berdasarkan pemisahan itu. Ahli pemrograman Java bisa concern dengan aplikasi Java, ahli pemrograman C++ bisa concern dengan aplikasi C++, begitu juga programer Delphi dan lain-lainnya.


10


Daftar Pustaka

2.      Mahmoud H., Qusay , Distributed Programming With Java, Manning, 2000.
3.      Somantri, Maman, Pemrograman Lintas Bahasa Pemrograman dalam Arsitektur CORBA, Prosiding Seminar Nasional Teknologi Informasi, STTNAS Yogyakarta, Juni 2005.
4.      Somantri Maman. Konsep pemograman Jaringan dengan memanfaatkan jaringan Middleware ORB

 



Minggu, 22 Desember 2013

Proses Komunitas Java (Java Community Process JCP)

Java Community Process (JCP) Program Management Office (PMO) sangat tertarik untuk mengumumkan upgrade ke jcp.org baru-baru ini meluncurkan situs web. Setelah web rumah masyarakat benar-benar dirombak dan dirilis pada bulan Juni 2009, bekerja terus di belakang layar untuk menambah, meningkatkan, dan memperbaiki fungsi dan kegunaannya. Anggota PMO berfungsi sebagai tim proyek untuk mendefinisikan dan menyelesaikan pekerjaan.

Program yang JCP komunitas pengguna telah membantu dalam memberikan umpan balik pada situs web. Banyak fitur baru dan perbaikan bug pada awalnya diusulkan atau diidentifikasi oleh pengguna. Beberapa implementasi tersebut akan segera jelas. Sebagai contoh, semua wiki dan papan sekarang mencakup satu cara bagi pengguna untuk memberikan pendapat mereka yang cepat konten dengan menghadiahi setiap item dengan nilai, dengan memilih jumlah bintang tertentu. Selain itu, semua papan diskusi publik dan wiki termasuk RSS tombol untuk memungkinkan pengguna untuk berlangganan pembaruan konten. Karena pengaturan keamanan dan persyaratan browser, RSS feed fitur ini hanya bekerja jika SSL diaktifkan. Misalnya, fitur RSS melakukan kerja dengan Firefox.
Berbagai bug telah diperbaiki dan navigasi juga telah diperbarui untuk mengatur informasi yang tersedia. Ini adalah langkah inkremental lain sepanjang perjalanan untuk meningkatkan jcp.org. Dalam bulan-bulan mendatang, sebagai masyarakat terus menyarankan perubahan dan perangkat tambahan, upaya akan terus memperbaiki situs. Semua umpan menyimpan program dan JCP jcp.org bergerak maju dan ke atas.

VIRTUAL MACHINE
Virtual machine (VM) adalah suatu environment, biasanya sebuah program atau system operasi, yang tidak ada secara fisik tetapi dijalankan dalam environment lain. Dalam konteks ini, VM disebut “guest” sementara environment yang menjalankannya disebut “host”. Ide dasar dari virtual machine adalah mengabtraksi perangkat keras dari satu komputer (CPU, memori, disk, dst) ke beberapa environment eksekusi, sehingga menciptakan illusi bahwa masing-masing environment menjalankan komputernya [terpisah] sendiri.VM muncul karena adanya keinginan untuk menjalankan banyak sistem operasi pada satu komputer.Teknologi virtual machine memiliki banyak kegunaan seperti memungkinkan konsolidasi perangkat keras, memudahkan recovery sistem, dan menjalankan perangkat lunak terdahulu.

Salah satu penerapan penting dari teknologi VM adalah integrasi lintas platform. Beberapa penerapan lainnya yang penting adalah :

• Konsolidasi server.
Jika beberapa server menjalankan aplikasi yang hanya memakan sedikit sumber daya, VM dapat digunakan untuk menggabungkan aplikasi-aplikasi tersebut sehingga berjalan pada satu server saja, walaupun aplikasi tersebut memerlukan sistem operasi yang berbeda-beda.

• Otomasi dan konsolidasi lingkungan pengembangan dan testing.
Setiap VM dapat berperan sebagai lingkungan yang berbeda, ini memudahkan pengembang sehingga tidak perlu menyediakan lingkungan tersebut secara fisik.

• Menjalankan perangkat lunak terdahulu.
Sistem operasi dan perangkat lunak terdahulu dapat dijalankan pada sistem yang lebih baru.

• Memudahkan recovery sistem.
Solusi virtualisasi dapat dipakai untuk rencana recovery sistem yang memerlukan portabilitas dan fleksibilitas antar platform.

• Demonstrasi perangkat lunak.
Dengan teknologi VM, sistem operasi yang bersih dan konfigurasinya dapat disediakan secara cepat.

- Kelebihan Virtual Machine (VM)
Teknologi VM memiliki beberapa keunggulan, antara lain :

• Hal keamanan.
VM memiliki perlindungan yang lengkap pada berbagai sistem sumber daya, yaitu dengan meniadakan pembagian sumber daya secara langsung, sehingga tidak ada masalah proteksi dalam VM. Sistem VM adalah kendaraan yang sempurna untuk penelitian dan pengembangan sistem operasi. Dengan VM, jika terdapat suatu perubahan pada satu bagian dari mesin, maka dijamin tidak akan mengubah komponen lainnya.

• Memungkinkan untuk mendefinisikan suatu jaringan dari Virtual Machine (VM).
Tiap-tiap bagian mengirim informasi melalui jaringan komunikasi virtual. Sekali lagi, jaringan dimodelkan setelah komunikasi fisik jaringan diimplementasikan pada perangkat lunak.

- Kekurangan Virtual Machine (VM)

Beberapa kesulitan utama dari konsep VM, diantaranya adalah :

• Sistem penyimpanan.
Sebagai contoh kesulitan dalam sistem penyimpanan adalah sebagai berikut: Andaikan kita mempunyai suatu mesin yang memiliki 3 disk drive namun ingin mendukung 7 VM. Keadaan ini jelas tidak memungkinkan bagi kita untuk dapat mengalokasikan setiap disk drive untuk tiap VM, karena perangkat lunak untuk mesin virtual sendiri akan membutuhkan ruang disk secara substansial untuk menyediakan memori virtual dan spooling. Solusinya adalah dengan menyediakan disk virtual atau yang dikenal pula dengan minidisk, dimana ukuran daya penyimpanannya identik dengan ukuran sebenarnya. Dengan demikian, pendekatan VM juga menyediakan sebuah antarmuka yang identik dengan perangkat keras yang mendasari.

• Pengimplementasian sulit.
Meski konsep VM cukup baik, namun VM sulit diimplementasikan.

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. 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).

SUMBER :
http://www.total.or.id/  
http://code86.wordpress.com/2009/11/19/layanan-interface-dan-fitur-fitur-telematika/
http://nurpratamarekzy04.blogspot.com/2013/01/java-community-process.html

Kolaborasi Antar muka Otomotif Multimedia (Automotive Multimedia Interface Colaboration - AMI-C)

Kolaborasi antarmuka otomotif 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 system 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.

Kendaraan segera akan mengalamin peningkatan perlengkapan dengan ditambahkannya sistem digital yang mendukung beberapa aplikasi seperti untuk mengakses informasi, komunikasi, kemanan dan internet. Ketertarikan terhadap aplikasi multimedia pada kendaraan meningkat, misalnya pada periode 2003-2005. Seperti: pengenalan aplikasi real-time, kamera kecepatan tinggi, seiring dengan semakin meningkatnya komersialisasi lalu lintas multimedia dan pelayanan pariwisata dan travel. Oleh sebab itu, kebutuhan akan multimedia bus yang diletakkan pada kendaraan akan meningkat.

Automotive Multimedia Interface Collaboration (AMI-C) menyatakan bahwa akan menggandeng teknologi Open Service Gateway Initiative (OSGi) sebagai framework untuk platform sofware yang dibangun untuk informasi mobile dan sistem entertainment. Dalam kombinasi’a, AMI-C dan framework OSGi akan menyediakan satu platform software yang umum dan pasar yang terbuka untuk penyedia aplikasi atomotif berbasis wireless. Untuk pengguna, platform umum tersebut akan menyediakan pilihan software aplikasi yang luas.

1. Bagaimana Fungsional Kolaborasi Antarmuka Otomotif Multimedia (AMIC) Telematika
Automotive Multimedia Interface Collaboration (AMI-C) adalah mengembangkan dan standarisasi yang umum multimedia dan telematika otomotif untuk kendaraan antarmuka jaringan komunikasi.

Tujuan utamanya adalah untuk:

1. 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.

2. Meningkatkan pilihan dan mengurangi keusangan sistem elektronik kendaraan.

3. Memotong biaya keseluruhan informasi kendaraan dan peralatan hiburan dengan meningkatkan ukuran pasar yang efektif dan memperpendek waktu pengembangan - industri otomotif efektif terdiri dari banyak pasar yang kecil karena setiap platform kendaraan sering mengandung berbagai adat-mengembangkan komponen dan platform yang khas hanya sekitar 50.000 unit.

4. Menawarkan standar terbuka dan spesifikasi untuk informasi interface dalam kendaraan dan antara kendaraan dan dunia luar.
 
Struktural Kolaborasi Antarmuka Otomotif Multimedia

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.
 
SUMBER :

http://wartawarga.gunadarma.ac.id/2009/12/automotive-multimedia-interface-colaboration-ami-c/
http://ridwan-simbada.blogspot.com/2011/12/kolaborasi-antarmuka-otomotif.html
http://ithamustika.blogspot.com/2012/12/tugasfungsional-kolaborasi-antarmuka.html
http://mrpram.blogspot.com/2009_12_01_archive.html
 

Open Services Gateway Initiative (OSGi)

The OSGi Alliance (sebelumnya dikenal sebagai Open Services Gateway inisiatif, sekarang nama kuno) adalah terbuka organisasi standar yang didirikan pada Maret 1999. Aliansi dan anggota-anggotanya telah ditentukan yang Java berbasis layanan platform yang dapat dikelola dari jarak jauhInti bagian dari spesifikasi adalah sebuah kerangka kerja yang mendefinisikan suatu manajemen siklus hidup aplikasi model, layanan registry, sebuah lingkungan Eksekusi dan Modul. Berdasarkan kerangka ini, sejumlah besar OSGi layers, API, dan Jasa telah ditetapkan.
OSGi teknologi adalah sistem modul dinamis untuk Java.

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. 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.

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


Arsitektur : 




Setiap kerangka yang menerapkan standar OSGi menyediakan suatu lingkungan untuk modularisasi aplikasi ke dalam kumpulan yang lebih kecil. Setiap bundel adalah erat-coupled, dynamically loadable kelas koleksi, botol, dan file-file konfigurasi yang secara eksplisit menyatakan dependensi eksternal mereka (jika ada).  Kerangka kerja konseptual yang dibagi dalam bidang-bidang berikut:
  1. Bundles
    Bundles adalah normal jar komponen dengan nyata tambahan header
  2. Services
    Layanan yang menghubungkan lapisan bundel dalam cara yang dinamis dengan menawarkan menerbitkan-menemukan-model mengikat Jawa lama untuk menikmati objek (POJO).
  3. Services
    API untuk jasa manajemen (ServiceRegistration, ServiceTracker dan ServiceReference).
  4. Life-Cycle
    API untuk manajemen siklus hidup untuk (instal, start, stop, update, dan uninstall) bundel.
  5. Modules
    Lapisan yang mendefinisikan enkapsulasi dan deklarasi dependensi (bagaimana sebuah bungkusan dapat mengimpor dan mengekspor kode).
  6. Security
    Layer yang menangani aspek keamanan dengan membatasi fungsionalitas bundel untuk pra-didefinisikan kemampuan.
  7. Execution Environment
    Mendefinisikan metode dan kelas apa yang tersedia dalam platform tertentuTidak ada daftar tetap eksekusi lingkungan, karena dapat berubah sebagai Java Community Process menciptakan versi baru dan edisi Jawa. Namun, set berikut saat ini didukung oleh sebagian besar OSGi implementasi:
    •    CDC-1.1/Foundation-1.1 CDC-1.1/Foundation-1.1
    •    OSGi/Minimum-1.0 OSGi/Minimum-1.0
    •    OSGi/Minimum-1.1 OSGi/Minimum-1.1
    •    JRE-1.1 JRE-1.1
    •    From J2SE-1.2 up to J2SE-1.6 Dari J2SE-1.2 hingga J2SE-1,6
    •    CDC-1.0/Foundation-1.0 CDC-1.0/Foundation-1.0

SUMBER :http://en.wikipedia.org/wiki/OSGi
http://www.osgi.org/Main/HomePage