Seperti yang sudah dijelaskan sebelumnya bahwa arsitektur sistem terdistribusi membutuhkan middleware (object request broker) untuk menangani komunikasi antar objek. Pada prinsipnya, object-object pada sistem dapat diimplementasikan dengan bahasa pemrograman yang berbeda, dapat pula berjalan di platform yang berbeda dan namanya tidak perlu diketahui semua object lain pada sistem.
Saat ini ada dua standar utama middleware untuk mendukung komputasi object terdistribsi:
- CORBA (Command Objet Request Broker Architecture), adalah satu set standar middleware yang dikeluarkan oleh OMG (Object Management Group). CORBA mendefinisikan pendekatan yang tidak dependen mesin dan generic terhadap komputasi objek terditribusi. sejumlah implementasi ini tersedia untuk aplikasi sistem operasi UNIX dan Microsoft.
- DCOM (Distributed Component Object Mode), dikebangakan oleh Microsoft. Model komputasi terdistribusinya kurang umum dari model CORBA dan DCOM memberikan dukungan yang terbatas pada interoperabilitas.
- RMI (Remote Method Invocation), dikembangkan oleh Java.
CORBA dikembangkan oleh OMG yang berperan dalam mendefinisikan standar untuk pengembangan berorientasi object, tapi tidak menyediakan implementasi untuk standar ini. Visi OMG tentang sistem terdistribusi ditunjukkan pada gambar 10.7 yang mengusulkan agar aplikasi terdistribusi terbuat dari sejumah komponen yaitu:
- Objek Aplikasi, yang dirancang dan diimplementasikan untuk aplikasi ini.
- Objek Standar, yang didefinisikan oleh OMG untuk domain khusus misalnya untuk masalah keuangan, e-commerce, kesehatan, dll.
- Layanan CORBA, fundamental yang menyediakan layanan komputasi terdistribusi dasar seperti direktori, manajemen sekuritas, dll.
- Fasilitas CORBA horizontal, seperti fasilitas interface user, manajemen sistem, dll. Istilah horizonal berarti fasilias bersifat umum untuk banyak domain aplikasi.
Gambar 10.7 CORBA application structure
Standar CORBA mencakup semua aspek visi ini, ada 4 elemen utama untuk standar ini:
- Model object CORBA merupakan encapsulasi status dengan interface yang terdefinisi dan dideskripsikan dalam IDL (Interface Definition Language).
- Object Request Broker (ORB), yang menangani permintaan layanan objek. ORB mencari objek yang menyediakan layanan tersebut, menyediakannya untuk permintaan, mengirimkan dan mengembalikan hasilnya kepada pemohon.
- Satu set layanan objek, yang menyediakan layanan umum dan mungkin diperlukan oleh banyak aplikasi terdistribusi, contoh layanan ini adalah layanan direktori, layanan transaksi.
- Satu set komponen umum yang dibangun di atas layanan-layanan dasar yang mungkin dibutuhkan oleh aplikasi.
Objek CORBA memiliki identifier unik yang dinamakan Interoperable Object Reference (IOR) yang digunakan ketika satu objek meminta layanan dari yang lain.
Object Request Broker (ORB) tahu mengenai objek yang meminta layanan dan interface mereka. ORB menangani komunikasi diantara objek-objek tersebut. Objek-Objek yang berkomunikasi tidak perlu mengetahui lokasi objek lain dan implementasinya, karena interface mengisolasi objek dari ORB, maka perubahan implementasi objek dilakukan dengan cara transparan. Lokasi bojek dapat berubah anara invokasi dan hal ini transparan bagi objek lainnya pada sistem tersebut.
Gambar 10.8 komunikasi objek melalui ORB
Hal ini dapat dilihat pada gambar 10.8 yang mengilusrasikan bagaimana dua objek o1 dan o2 berkomunikasi melalui ORB. Objek pemanggil (O1) memiliki IDL stub yang berhubungan dengan interface objek yang memberikan layanan yang dibutuhkan. Implementator o1 menggabungkan panggilan untuk stub ini pada implementasi objek ketika layanan dibutuhkan. IDL merupakan superset C++ sehingga mudah untuk mengaksesnya. Pemetaan ke IDL juga telah didefinisikan untuk bahasa lain seperti ADA dan COBO yang mendukung link ke IDL. Objek yang menyediakan layanan memilii IDL skeleton yang terhubung ke interface untuk aplikasi layanan. Jadi, ketika layanan dipanggil melalui interface, IDL skeleton menerjemahkan panggilan ini menjadi panggilan layanan dalam bahasa implementasi apapun yang digunakan. Ketika metode atau prosedur telah dilaksanakan, IDL skeleton menerjemahkan hasilnya menjadi IDL, sehingga dapat diakses oleh objek yang memanggil. Ketika objek menyediakan layanan ke objek lain dan menggunakan layanan yang disediakan ditempat lain, objek tersebut membutuhkan IDL skeleton dan IDL stub. IDL stub dibutuhkan oleh setiap objek yang dipakai.
