Sistem Terdistribusi (CORBA - COMMON OJECT REQUEST BROKER ARCHITECTURE)

CORBA - COMMON OJECT REQUEST BROKER ARCHITECTURE

CORBA dan Sejarahnya

Dalam dunia yang terus berkembang ini, kebutuhan komputer yang mengaplikasikan sistem terdistribusi menjadi sangat tinggi. Sistem komputer yang terdistribusi adalah sebuah sistem yang memungkinkan aplikasi komputer beroperasi secara terintegrasipada lebih dari satu lingkungan yang terpisah secara fisik dan memiliki karakteristikconcurrency, synchronization, dan failures. Adalah tidak mungkin untuk mengembangkan sistem terdistribusi yang homogen, karena secara alamiah sistem komputer terdistribusi tumbuh dari lingkungan yang heterogen baik dalam hal perangkat keras, sistem operasi, maupun bahasa pemrogaman. Dari sini lah muncul istilahinteroperabilitas yang artinya adalah kemampuan kerjasama antar sistem komputer.

Interoperabilitas sudah banyak dikenal orang. Salah satunya adalah protokol komunikasi data yang kita kenal dengan istilah TCP/IP. Namun ada satu hal yang belum banyak dikenal, yaitu interoperabilitas pada level perangkat lunak aplikasi. Dalam konteks sistem komputer terdistribusi, walaupun komponen aplikasi dibuat dengan bahasa pemrogaman yang berbeda, menggunakan development tools yang berbeda, dan beroperasi di lingkungan yang beragam pula, mereka harus tetap dapat saling bekerjasama.

Dari kebutuhan tersebut lah maka berdasarkan “kesepakatan” antara sejumlah vendor dan pengembanga perangkat lunak terkenal semacam IBM, Hewlett-Packard, dan DEC, yang tergabung dalam sebuah konsorsium bernama Object Management Group (OMG) lahirlah CORBA.

CORBA

CORBA adalah sebuah arsitektur software yang berbasis Object Oriented dengan paradigma client-server. Dalam terminologi tersebut, sebuah objek berkomunikasi dengan objek lain dengan cara pengiriman pesan (message passing). Diterjemahkan dalam modelclient-server, satu objek berperan sebagai si pengirim pesan (client) dan yang lain bertindak sebagai penerima dan pemroses pesan (server).

Keunikan dari CORBA adalah arsitektur ini memiliki Object Request Broker (ORB) yang memungkinkan untuk client dan server diimplementasikan dalam hardware, sistem operasi, bahasa pemrogaman, dan dilokasi yang berbeda, tapi tetap bisa saling berkomunikasi. Secara gampangnya ORB ini akan menjadi “broker/pialang” yang akan menjebatatani heterogenitas antara kedua objek. ORB akan menangani perbedaan platform, pelacakan lokasi objek, dan proses transfer pesan sedemikian rupa sehingga transparan terhadap kedua objek. Dengan demikian pemrogaman client dan implementasi objek bisa berkonsentrasi sepenuhnya pada aspek fungsionalitas keduanya.

Structur CORBA ORBA

 

Komponen CORBA yang terletak di sisi Server

1. Server Side ORB Interface

2. Static IDL Skeleton

3. Dynamic Skeleton Interface

4. Object Adapter

5. Server Side Implementation

Komponen CORBA pada sisi Client:

1.     Client Application

2.     Client IDL Stubs

3.     Dynamic Invocation Interface

4.     Interface Repository

5          5.     Client Side ORB Interface

3.  Model Arsitekur OMG

          Arsitektur CORBA (Common Object Request Broker Architecture) yang pertama kali dikembangkan oleh OMG (Object Management Group), bertujuan untuk pengembangan pemrograman berorientasi pada obyek yang terdistribusi. CORBA itu sendiri bukanlah merupakan suatu bahasa pemrograman, tetapi merupakan suatu spesifikasi standard arsitektur untuk mengembangkan obyek-obyek terdistribusi. Beberapa software yang mengimplementasikan CORBA misalnya ORBIX (oleh Technologies), VisiBroker (oleh msprise), dan Java IDL (oleh JavaSoft). CORBA memiliki arsitektur yang berbasiskan model obyek. Model ini diturunkan strak Core Object Model yang didefiniskan OMG di dalam OMA (Object agement Architecture). Model mi merupakan gambaran abstrak yang tidak dapat diimplementasikan tanpa menggunakan teknologi tertentu. Dengan model tersebut, suatu aplikasi dapat dibangun dengan standard yang telah ditentukan.

Gambar

Model Arsitektur OMG

 

 

Sistem CORBA terdiri dari obyek-obyek yang mengisolasi suatu client dari suatu server dengan menggunakan interface enkapsulasi yang didefinisikan secara ketat. Obyek CORBA dapat berjalan di atas berbagai platform, dapat terletak dimana saja dalam suatu network, dan dapat dikodekan dengan bahasa pemrograman apapun asal memiliki mapping.

          Aplikasi enterprise tradisional kebanyakan adalah monolitik artinya data store, business logic, dan user interface. Perubahan yang sedikit saja mengakibatkan seluruh system perlu dikompilasi ulang. Dengan demikian reusability dari modul-modul adalah rendah sedang aplikasi terdistribusi yang dikembangkan dengan CORBA, komponen-komponennya dapat dipisahkan. Contoh dalam suatu aplikasi modular 3-tier, setiap komponen menjadi bagian yang terpisah. Semua komponen yang berupa obyek dapat dipakai oleh obyek-obyek lain dimana obyek-obyek itu tidak perlu ditulis dalam bahasa yang sama, tidak perlu berada pada platform yang sama atau pada mesin yang sama. Sekali obyek dibuat maka obyek itu dapat digunakan dari klien mana saja. User interface tier yang menampilkan informasi kepada pemakai akan menjadi tipis. Hal ini disebabkan karena obyek telah dipindahkan ke service tier yang bertindak sebagai middle war. Pada lapisan obyek logic ini terdapat CORBA object. Obyek-obyek inilah yang kemudian akan mengakses database yang berada pada data store tier..

Dengan CORBA beban dari suatu layanan bisa disebar ke beberapa server lain. CORBA dapat juga membuat bahasa pemrograman, misalnya Java, dan dapat berkomunikasi dengan obyek yang dibuat dengan bahasa yang lain dimanapun. Berkat kemampuan dinamic invocatioan interface dan dynamic skeleton interface CORBA, sebuah obyek (obyek Java) misalnya yang menjadi pelayan dapat memberi informasi mengenai jati dirinya kepada obyek lain agar obyek lain tersebut dapat meminta suatu layanan yang tersedia. Sebagai balasannya, ketidaktergantungan platform dari Java (write once – run anywhere) tentu memudahkan administrator dalam memutuskan di  mesin mana obyek CORBA yang dibuat akan diletakkan asalkan ada Java Virtual Machine pasti akan jalan. 

4. Object Management Architecture (OMA)

            Object Management Architecture (OMA) mendefinisikan berbagai fasilitas high-level yang diperlukan untuk komputasi berorientasi obyek. Bagian utama dari OMA adalah Object Request Broker (ORB). ORB merupakan suatu mekanisme yang memberikan transparansi lokasi, komunikasi, dan aktivasi. Suatu obyek. ORB adalah semacam software bus untuk obyek-obyek dalam CORBA. Berdasarkan OMA, spesifikasi CORRBA harus dipatuhi oleh ORB.

CORBA disusun oleh komponen-komponen utama :

1.    ORB (Object Request Broker)

2.    IDL (Interface Definition Language)

3.    DII (Dynamic Invocation Interface)

4.    IR (Interface Repositories)

5.    OA (Object Adapter)

 

5.   Komponen Object Request Broker (ORB)

          Inti dari CORBA adalah ORB, dimana ORB  bertanggungjawab untuk menjalankan semua mekanisme yang dibutuhkan, antara lain yaitu:

1.  menemukan implementasi obyek untuk memenuhi suatu request,

2.  menyiapkan implementasi obyek untuk menerima suatu request,

3.  melakukan komunkasi data untuk memenuhi suatu request.

          Sebuah permintaan (request) yang dikirimkan suatu client ke suatu object implementation akan melewati ORB. Dengan ORB, yang terdiri dari interface, suatu entitas dapat berkomunikasi dengan object implementation tanpa adanya batasan platform, topologi jaringan, bahasa pemrograman, dan letak obyek.

Dengan menggunakan ORB, obyek client dapat meminta sebuah method pada sebuah object server yang bisa saja terdapat dalam satu mesin maupun jaringan yang berbeda.  ORB  menerima  panggilan  dan  menemukan  obyek  yang  bisa mengimplementasikan permintaan, mengirim parameter, invoke method, dan mengembalikan hasil yang diperoleh.Berikut adalah gambar yang menunjukkan komponen utama dari arsitektur CORBA ORB (Object Request Broker).

 

CORBA ORB Architecture

on

 

1.    Object Implementation (OI)

          Suatu Object Implementation (OI) menyediakan semantik dari obyek, yang umumnya dilakukan dengan mendefiniskan data untuk object instance dan kode untuk method-method obyek tersebut. Seringkali kita menggunakan obyek lain atau menggunakan software tambahan untuk mengimplementasikan sifat suatu obyek.

          Berbagai Object Implementation (O1) dapat didukung oleh server yang terpisah, librarys, sebuah program setiap method, aplikasi ter-enkapuslasi, object-oriented database, dan lain-lain. Dengan menggunakan object adapters (OA) tambahan, dimungkinkan untuk mendukung suatu Object Implementation (OI) secara virtual.

          Secara umum, Object Implementation (OI) tidak tergantung pada ORB atau bagaimana suatu client memanggil suatu obyek. Object Implementation (OI) dapat memilih interface-nya ke ORB-dependent service yang dipilih dengan memilih Object dapter (OA).

Object Implementation (OI) menerima suatu request melalui

1.     IDL Skeleton

2.     Dynamic Skeleton Interface(DSl)

Object Implementation (0I) dapat memanggil Object Adapter (OA) dan ORB pada saat memproses sebuah request.

7.   ORB Interface

          ORB Interface Merupakan interface yang berhubungan langsung dengan ORB yang sama untuk semua ORB dan tidak tergantung pada interface suatu obyek atau Obyek Adapter (OA). Karena banyak fungsionalitas ORB yang disediakan melalui OA, stub, skeleton , maupun dynamic invocation; maka ada sedikit operasi yang umum bagi semua obyek.

          Inteface suatu obyek dapat didefinisikan dengan cara statis, yaitu menggunakan IDL (Interface Definition Languange). IDL mendefiniskan tipe suatu obyek berdasarkan operasi-operasi (yang mungkin dijalankan pada obyek tersebut) dan parameter operasi tersebut. Interface dapat pula ditambahkan ke dalam suatu IRS (Interface Repository Service) yang menggambarkan komponen-komponen dari interface suatu obyek. Client dapat mengakses komponen-komponen ini saat runtime.

          Client meminta suatu request dengan melakukan akses ke OR (Object Reference) suatu obyek yang dituju dan mengetahui tipe dari obyek dan operasi-operasi yang dapat dilakukan pada obyek tersebut. Client menginisialisasi request dengan memanggil rutin-rutin suatu stub yang sesuai dengan obyek atau membangun request secara dinamik. Interface dinamik dan interface stub harus memiliki semantic request yang masih dalam pemanggilan suatu request.

ORB mencari implementation code yang dituju, mengirimkan parameter-parameter dan mentransfer kontrol pada Object Implementation memalui IDL Sekeleton atau Dynamic Skeleton. Secara spesifik, skeleton berupa interface dan OA (Object Adapter).

          Dalam mengolah suatu request,    Object Implementation memberikan service pada ORB melalui OA (Object Adapter). Saat suatu request selesai dijalankan, kontrol dan nilai keluaran dikembalikan ke client. 0I dapat memilih OA yang akan digunakan. Keputusan pemilihan OA ditentukan oleh jenis service yang dibutuhkan oleh 0I tersebut. Infomasi tentang 0I diberikan pada saat instalasi dan disimpan dalam IR (Implementation Repository) yang digunakan selama pengiriman hasil request.

          Dalam arsitekturnya, ORB tidak perlu dimplementasikan dalam sebuah komponen tunggal; namun, ORB didefinisikan menggunakan interface-interface yang dimilikinya. Interface-interface tersebut dikelompokan menjadi:

1.     operasi yang sama untuk semua implementasi ORB,

2.     operasi khusus untuk tipe obyek tertentu,

3.     operasi khusus untuk style OI tertentu.

8.   Object Reference (OR)

          Object Reference (OR) merupakan informasi yang dibutuhkan untuk menentukan sebuah obyek dalam ORB. Client dan Object Implementation (OI) memiliki bagian yang tertutup dari OR dengan language mapping, yang kemudian disekat dari representasi aktualnya. Dua implementasi ORB dapat memiliki representasi OR yang berbeda. Representasi OR pada sisi client hanya valid selama masa hidup client tersebut.

          Semua ORB harus menyediakan language mapping yang sama untuk sebuah OR (umumnya disebut obyek) untuk sebuah bahasa pemrograman tertentu. Hal ini memungkinkan sebuah program ditulis dalam bahasa apapun untuk mengakses OR secara independen terhadap ORB tertentu.

9.   Komponen Interface Definition Language (IDL)

          Obyek-obyek CORBA dispesifikasikan menggunakan interface, yang merupakan menghubung antara client dan server. Interface Definition Language (IDL) digunakan untuk mendefinisikan interface-interface  tersebut.

             IDL menentukan tipe-tipe suatu obyek dengan mendefinisikan interface-interface obyek tersebut. Sebuah interface terdiri dari kumpulan operasi dan parameter operasi. IDL hanya mendeskripsikan interface dan tidak mengimplementasikannya. Meskipun sintaks yang dimiliki oleh IDL menyerupai sintaks bahasa pemrograman C++ dan  Java., perlu diingat, IDL bukan bahasa pemrograman.

          Melalui IDL, Object Implementation (OI) akan memberitahu client, yang akan mengaksesnya, operasi apa saja dan method apa saja yang harus dipanggil client tersebut. Dari definisi IDL, obyek-obyek CORBA dipetakan ke bahasa pemrograman C, C++,  Java, dan lain-lain yang memiliki IDL mapping. Bahasa pemrograman yang berbeda dapat mengakses obyek-obyek CORBA dalam berbagai cara yang berbeda. Pemetaan dari IDL ke bahasa pemrograman tertentu harus sama untuk semua implementasi ORB.

          Language Mapping ini menyertakan definisi tipe data untuk bahasa pemrograman tertentu dan procedure interface untuk mengakses obyek melalui ORB. Ini meliputi hal-hal sebagai berikut.

1.     Struktur dari client stub interface (tidak dibutuhkan untuk bahasa OOP)

2.     Dynamic Invocation Interface

3.     Implementation Skeleton

4.     Object Adapters

5.     Direct ORB Interface

          Language Mapping juga mendefinisikan interaksi antara pemanggilan obyek dan langkah kontrol pada client dan implementasi. Pemetaan yang paling umum menyediakan synchronous call, dimana rutin mengembalikan nilai pada saat operasi suatu obyek selesai dilakukan. Pemetaan tambahan memungkinkan sebuah call di-inisiasi dan control dikembalikan kepada program.

1.1   Dynamic Invocation/Skeleton (DI)

            IDL interface yang digunakan oleh sebuah client ditentukan pada saat client dikompilasi. Hal tesebut mengakibatkan seorang programmer hanya dapat menggunakan server-server yang terdiri dari obyek-obyek yang mengimplementasikan interface­s-interface tersebut.

            Bila suatu aplikasi membutuhkan interface-interface yang tak didefiniskan saat kompilasi, maka diperlukan DII (Dynamic Invocation Interface) atau pun DSI (DynamicSkeleton Interface). DII memungkinkan suatu aplikasi/client memanggil operasi-operasi dari sembarang interface. DSI menyediakan suatu cara untuk mengirim request dari sebuah ORB ke sebuah Object Implementation (0I) tanpa harus mengetahui tipe dari obyek pada saat kompilasi.

1.2   Komponen Dynamic Invocation Interface (DII)

          CORBA mendukung DII dan SII. Operasi invocation dapat dilakukan menggunakan static interface ataupun dynamic interface. Static Invocation Interface(SII) ditentukan pada saat kompilasi dan dihubungkan dengan client mengunakan stub. Sedaangkan Dynamic Invocation Interface (DII) memungkinkan apliaksi di sisi client untuk menggunakan server object tanpa perlu mengetahui tipe obek-obyek tersebut saat kompilasi. DII memungkinkan client untuk mendapatkan sebuah instance dari obyek CORBA dan membuat invocation pada obyek tersebut dengan menciptakan request yang sifatnya dinamis. DII menggunakan Interface Repository (IR) untuk memvalidasi dan mengambil identifier operasi pada suatu request yang dibuat.

1.3  Komponen Interface Repository (IR)

          Client menggunakan Interface Repository (IR) untuk mempelajari tentang interface-obyek yang tidak diketahui dan client menggunakan DII untuk memanggil methods suatu obyek. Empat tahap yang diperlukan saat penggunaan Dynamic Invocation Interface (DII):

1.     mengidentifikasikan target obyek yang akan dipanggil,

2.     mendapatkan target interface dari obyek tersebut,

3.     membangun invocation,

4.     mengirim request da mendapatkan respon.

          Aplikasi-aplikasi client yang menggunakan Dynamic Invocation Interface (DII) tidak lebih  efisien dari yang menggunakan SII, tetapi ada dua keuntungan menggunakan DII, yaitu:

·      aplikasi client dapat melakukan permintaan kepada setiap operasi meskipun tersebut tidak diketahui pada saat aplikasi dikompilasi,

·      aplikasi client tidak harus dikompilasi ulang untuk mengakses 0I yang diaktivasi ulang.

          Interface Repository (IR) merupakan online database yang berisi tentang meta informasi  tentang tipe dari obyek ORB. Meta informasi yang disimpan meliputi informasi tentang modul, interface, operasi, atribut, dan eksepsi dari obyek.

          Interface Repository (IR) menyediakan cara lain untuk menentukan interface ke suatu obyek. Interface ini dapat ditambahkan kelayanan IR. Dengan menggunakan IR, sebuah client akan mencari obyek yang tidak diketahui pada saat kompilasi, menemukan informasi tentang interface obyek tersebut dan implementasi suatu aktivasi dan deaktivasi.

          ORB biasa menggunakan IR untuk:

1.     menyediakan interoperability antar implementasi ORB yang berbeda,

2.     menyediakan type checking dari signature sebuah request yang melalui SII dan DII.

3.     mengecek kebenaran grafik inheritance,

4.     mengelola instalasi dan distribusi interface definition dalam sebuah jaringan,

5.     mengeizinkan designer apliaksi untuk memodifikasi interface definition, dan

mengizinkan language compiler untuk mengkompile stub dan skeleton dari IR bahkan langsung dari file IDL.

Keterangan Situs

1.        Halaman Web Object Management Group                     http://www.omg.org/

 (OMG) menyediakan titik akses ke berbagai informasi
   tentang CORBA

2.         Halaman Web ILU di Xerox Palo Alto Research Centre ftp://ftp.parc.xerox.com/pub/ilu/ilu.html

3.         Halaman Web Fnorb dari DSTC, Australia                     http://www.fnorb.org

4.         Halaman Web MICO                                                         http://www.mico.org

5.         Halaman Web JacORB di Freie Universitat, Berlin        http://jacorb.inf.fu-berlin.de/

6.          Halaman Web OmniORB2 di AT&T Inggris                 http://www.uk.research.att.com    /omniORB/

7.           Situs ini berisi berbagai hal yang berhubungan dengan paradigma berorientasi obyek (OO), termasuk CORBA. Mirror tersebar di berbagai lokasi.

http://www.cetus-links.org/.