CORBA DAN RMI

CORBA

Sistem komputer terdistribusi adalah sebuah sistem yang memungkinkan aplikasi komputer beroperasi secara terintegrasi pada lebih dari satu lingkungan yang terpisah secara fisis. Sistem informasi kesehatan yang diilustrasikan di atas menunjukkan komponen-komponen aplikasi yang terdistribusi (di tempat praktek dokter, di rumah sakit, di apotik, dan di perusahaan asuransi kesehatan). Ciri khas sistem komputer terdistribusi adalah heterogenitas dalam berbagai hal: perangkat keras, sistem operasi, dan bahasa pemrograman. Adalah tidak mungkin untuk mengembangkan sistem terdistribusi yang homogen secara paksaan, karena secara alamiah sistem komputer terdistribusi tumbuh dari lingkungan yang heterogen. Kata kunci dalam menjembatani perbedaan-perbedaan yang muncul adalah interoperabilitas (interoperability).

CORBA (Common Object Request Broker Architecture) adalah suatu standard untuk sistem objek oriented terdistribusi yang dikembangkan oleh OMG. CORBA memungkinkan kita menggunakan aplikasi tanpa adanya batasan platform, teknologi jaringan, bahasa pemrograman, maupun letak  objek pemberi service yang dituju.

CORBA sebagai system yang terdistribusi, memiliki potensi yang besar untuk ditembus dari berbagai sisi. Karena itu diperlukan suatu sistem pengamanan yangmemadai pada CORBA.

 Arsitekur CORBA

CORBA (Common Object Request Broker Architecture) merupakan suatu spesifikasi yang dikembangkan oleh OMG (Object Management Group), sebuah konsorsium yang terdiri lebih dari 800 perusahaan.

Tujuan CORBA adalah untuk pengembangan pemrograman objek terdistribusi.CORBA bukanlah bahasa pemrograman, tapi merupakan spesifikasi untukmengembangkan objek-objek terdistribusi.

Beberapa software yang mengimplementasikan COBA misalnya ORBIX (oleh IONA Technologies), VisiBroker (oleh Insprise), dan JavaIDL (oleh JavaSoft). CORBA memiliki arsitektur yang berbasiskan model objek. Model ini diturunkan dari abstrak Core Object Model yang didefiniskan OMG di dalam OMA (Object Management Architecture). Model ini  merupakan gambaran abstrak yang tidak dapat diimplementasikan tanpa menggunakan teknologi tertentu. Dengan model tersebut, suatuaplikasi dibangun dengan standard yang telah ditentukan.

Sistem CORBA terdiri dari objek-objek yang mengisolasi suatu client dari suatu server dengan menggunakan interface enkapsulasi yang didefinisikan secara ketat. Objek-objek CORBA dapat berjalan di atas berbagai platform, dapat terletak dimana saja dalam suatu network, dan dapat dikodekan dengan bahasa pemrograman apapun asal memiliki IDL mapping.Object Management Architecture (OMA) mendefinisikan berbagai fasilitas highlevel yang diperlukan untuk komputasi berorientasi objek.

Bagian utama dari OMA adalah Object Request Broker (ORB). ORB merupakan suatu mekanime yangm memberikan transparansi lokasi, komunikasi, dan aktivasi. Suatu objek. ORB adalah semacam software bus untuk objek-objek dalam CORBA. Berdasarkan OMA, spesifikasi CORBA 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)

Komponen CORBA pada sisi Client:

1. Client Application

2. Client IDL Stubs

3. Dynamic Invocation Interface

4. Interface Repository

5. Client Side ORB Interface

6. ORB Core

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

Object Request Broker (ORB)

ORB merupakan inti dari CORBA dan bertanggung jawab untuk menjalankan semua

mekanisme yang dibutuhkan, yaitu:

1. Menemukan implementasi objek untuk memenuhi suatu request

2. Menyiapkan implementasi objek 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 client dapat berkomunikasi dengan object implementation tanpa adanya batasan platform,teknologi jaringan, bahasa pemrograman, dan letak objek.

Dengan menggunakan ORB, objek client bias meminta sebuah method pada sebuah object server yang bisa saja terdapat dalam satu mesin maupun jaringan yang berbeda. ORB menerima panggilan dan menemukan objek yang bisa mengimplementasikan permintaan, mengirim parameter, invoke method, dan mengembalikan hasil yang diperoleh.

Client

Secara umum, client adalah suatu program/proses yang melakukan request pada suatu objek. Terdapat pula client relative, yaitu suatu objek yang menjadi client dari objek lainnya.Client suatu objek harus mengakses OR (Object Reference) suatau objek tertentu untuk melakukan operasi pada suatu objek. Client hanya mengetahui struktur logika suatu objek melalui interface yang dimiliki objek tersebut dan behaviour yang dimiliki objek tersebut saat dipanggil.Secara umum, client mengakses objek dan ORB melalui language mapping.Client dapat bersifat portable dan seharusnya dapat berjalan tanpa harus mengubah kode pada ORB yang mendukung language mapping berbeda dengan objek instance yangmengimplementasikan interface berbeda.

Untuk membuat suatu request, client dapat menggunakan :

1. DII (Dynamic Invocation Interface) yaitu suatu interface yang tidak tergantung pada

inteface objek yang dituju

2. IDL Stub, yang tergantung pada interface objek yang dituju.

(cth: Untuk fungsi-fungsi tertentu, client dapat berinteraksi secara langsung dengan ORB)

 Object Implementation (OI)

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

Berbagai Object Implementation (OI) dapat didukung oleh server yang terpisah,librarys, sebuah program setiap method, aplikasi terenkapuslasi, 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 suatau client memanggil suatu objek. Object Implementation (OI) dapat memilih interface-nya ke ORB-dependent service yang dipilih dengan memilih Object Adapter (OA).

Object Implementation (OI) menerima suatu request melalui

1. IDL Skeleton

2. Dynamic Skeleton Interface(DSI)

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

Interface

Inteface suatu objek dapat didefinisikan dengan cara statis, yaitu menggunakan IDL (Interface Definition Languange). IDL mendefiniskan tipe suatu objek berdasarkan operasi-operasi (yang mungkin dijalankan pada objek tersebut) dan parameter operasi tersebut.

Interface dapat pula ditambahkan ke dalam suatu IRS (Interface Repository Service) yang menggambarkan komponen-komponen dari interface suatu objek. Client

dapat mengakses komponen-komponen ini saat runtime.Client meminta suatu request dengan melakukan akses ke OR (Object Reference)suatu objek yang dituju dan mengetahui tipe dari objek dan operasi-operasi yang dapat dilakukan pada objek tersebut. Client menginisialisasi request dengan memanggil rutinrutin suatu stub yang sesuai dengan objek atau membangun request secara dinamik.

Interface dinamik dan interface stub harus memeiliki semantic request yabng msa dalam pemanggilan suatu request.ORB mencari implementation code yang dituju, mengirimkan parameterparameter dan mentransfer kontrol pada Object Implementation memalui IDL Sekeleton

atau Dynamic Skeleton. Secara spesifik, skeleton berupa interface dan OA (ObjectAdapter).

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. OI dapat memilih OA yang akan digunakan.Keputusan pemilihan OA ditentukan oleh jenis service yang dibutuhkan oleh OI tersebut.Infomasi tentang OI 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 objek tertentu

3. operasi khusus untuk style OI tertentu

 Object Reference (OR)

Object Reference (OR) merupakan informasi yang dibutuhkan untuk menentukan sebuah objek dalam ORB. Client dan Object Implementation (OI) memiliki bagaian 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 objek) untuk sebuah bahasa pemrograman tertentu. Hal ini memungkinkan sebuah program ditulis dalam bahasa apapun untuk mengakses OR secara independen terhadap ORB terntentu.

Interface Definition Language (IDL)

Objek-objek CORBA dispesifikasikan menggunakan interface, yang merupakan penghubung anatara client dan server. Interface Definition Language (IDL) digunakan untuk mendefinisikan interface tersebut.IDL menentukan tipe-tipe suatu objek dengan mendefinisikan interface-interface objek tersebut. Sebuah interface terdiri dari kumpulan operasi dan parameter operasi tersbut. IDL hanya mendeskripsikan interface, 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 mengakses operasi apa saja dan method apa saja yang harus dipanggil client tersebut.Dari definisi IDL, objek-objek CORBA dipetakan ke bahasa pemrograman –C,C++, Java, dan lain-lain—yang memiliki IDL mapping.

Bahasa Pemrograman yang berbeda dapat mengakses objek-objek CORBA dalam bebagai 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 terntentu dan procedure interface untuk mengakses objek melalui ORB. Ini meliputi:

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 objek dan langkah kontrol pada client dan implementasi. Pemetaan yang paling umum menyediakan syncrhonous call, dimana rutin mengembalikan nilai pada saat operasi suatu objek selesai dilakukan. Pemetaan tambahan memungkinkan sebuah call diisisiasi dan kontrol dikembalikan kepada program.

 Dynamic Invocation/Skeleton Interface

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 objek-objek yang mengimplementasikan interfaceinterface tersebut.

Bila suatu aplikasi membutuhkan interface-interface yang tak didefiniskan saat kompilasi, maka diperlukan DII (Dynamic Invocation Interface) atau pun DSI (Dynamic Skeleton 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 (OI) tanpa harus mengetahui tipe dari objek pada saat kompilasi.

Dynamic Invocation Interface (DII)

CORBA mendukung DII dan SII. Operasi invocation dapat dilakukan menggunakan static interface ataupun dynamic interface. Static Invocation Interface (SII) ditentukan pad saat kompilasi dan dihubungkan dengan client mengunakan stub.Sedangkan Dynamic Invocation Interface (DII) memungkinkan apliaksi di sisi client untuk menggunakan server object tanpa perlu mengetahui tipe obek-objek tersebut saat kompilasi.

DII memungkinkan client untuk mendapatkan sebuah instance dari objek CORBA dan membuat invocation pada objek tersebut dengan menciptakan request yang sifatnya dinamis. DII  menggunakan Interface Repository (IR) untuk memvalidasi dan mengambil identifier operasi pada suatu request yang dibuat.Client menggunakan Interface Repository (IR) untuk mempelajari tentang

interface-objek yang tidak diketahui dan client menggunakan DII untuk memanggil methods suatu objek.

Empat tahap yang diperlukan saat penggunaan Dynamic Invocation Interface (DII):

1. Mengidentifikasikan target objek yang akan dipanggil

2. Mendapatkan target interface dari objek tersebut

3. Membangun invocation

4. Mengirim request untuk mendapatkan respon

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

-Aplikasi client dapat melakukan permintaan kepada setiap operasi meskipun tersebut tidak diketahui pada saat aplikasi dikompilasi.

-Apliaksi client tidak harus dikompilasi ulang untuk mengakses OI yang diaktivasi ulang.

 Dynamic Skeleton Interface (DSI)

Dynamic Skeleton Interface (DSI) menyerupai DII, namun tereletak di sisi server. DSI memungkinkan server ditulis tanpa harus mempunyai skeleton-skeleton atau informasi tentang waktu kompilasi, dan untuk objek mana server ini diimlementasikan. Fungsi utama Dynamic Skeleton Interface (DSI) adalah mendukung implementasi gateway antara ORB yang memiliki protocol komunikasi berbeda.

Object Adapter (OA)

Object Adapter (OA) merupakan cara utama bagi sebuah Object Implemetation (OI) untuk mengakses service yang disediakan oleh ORB. Tugas utamanya adalah melakukan masking (menutupi) perbedaan dalam implementasi objek untuk memperoleh portability yang lebih tinggi.

ORB Interface

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

 Inteface Repository (IR)

Interface Repository (IR) merupakan online database yang berisi tentang meta informasi tentang tipe dari objek ORB. Meta ionformasi yang disimpan meliputi informasi tentang modul, interface, operasi, atribut, dan eksepsi dari objek.Interface Repository (IR) menyediakan cara lain untuk menentukan interface ke suatu objek. Interface ini dapat ditambahakan ke layanan IR. Dengan menggunakan IR,sebuah client akan mencari objek yang tidak diketahui pada saat kompilasi, menemukan informasi tentang interface objek 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 alam sebuah jaringan

5. Mengeizinkan designer apliaksi untuk memodifikasi interface definition

6. Mengizinkan language compiler untuk mengcompile stub dan skeleton dari IR

bahkan langsung dari file IDL.

Implementation Repository

Implementation Repository terdiri dari informasi yang memperbolehkan ORB untuk mencari dan mengaktivasi implementasi suatu objek. Meskipun untuk suatu ORB atau lingkungan operasi, Implementation Repository merupakan tempat yang konvensional untuk menyimpan suatu informasi.

 Internet Inter-ORB Protocol (IIOP)

CORBA mendefinisikan IIOP (Internet Inter-ORB Protocol) untuk mengatur bagaimana objek berkomunikasi melalui jaringan. IIOP merupakan open protocol yang berjalan diatas TCP/IP.

3. Sistem Keamanan pada CORBA

Selain mendefinisikan arsitektur CORBA, OMG (Object Management Group) juga mengembangkan definisi formal untuk servis keamanan pada CORBA.Keamanan (security) merupakan hal sangat vital pada sistem komputer modern,terutama untuk sistem terdistribusi yang lebih mudah diserang dari pada sistem trandisional biasa. Oleh karena itu servis yang menunjang keamanan sangat diperlukan

dalam system terdistribusi seperti CORBA.

 Sistem Kemananan

Sistem keamanan (sekuriti) adalah proteksi umum suatu sistem informasi dari orang-orang yang akan melakukan akses yang tak diizinkan maupun interferensi dalam pengiriman informasi. Secara umum, keamanan berkenaan dengan masalah:

• Confidentiality (informasi hanya diberikan pada user yang berhak mengaksesnya)

• Integrity (informasi hanya boleh diubah oleh user yang berhak mengubahnya)

• Accountability (aksi-aksi user yang berhbungan dengan keamanan selalu dicatat)

• Avaiability (sistem selalu tersedia bagi user yang berhak mengaksesnya)

Sebagai tambahan dari hal-hal mendasar tersebut, spesifikasi OMG juga menyebutkan sejumlah ancaman (threat) dan sejumlah fitur (ferature) penting untuk mencapai tujuan (goal) dari sistem kemananan.

 Ancaman

Banyak ancaman yang terdapat pada suatu sistem informasi karena selalu saja ada orang yang mencoba untuk menjebol sistem tersebut dan berusaha mendapatkan informasi yang seharusnya tidak boleh diakses mereka.Sistem objek terdistribusi, semisal CORBA, lebih mudah diserang dari pada sistem-sistem tradisional. Hal ini dikarenakan pada sistem terditribusi terdapat banyak komunikasi antar komponen software yang beraneka macam sehingga menjadi peluang bagi para penjebol sistem.

Beberapa jenis ancaman yang dideskripsikan dalam spesifikasi OMG adalah:

• Kontrol keamanan (security control) di-bypass oleh orang lain.

• Seorang authorised user mendapatkan akses pada informasi yang seharusnya disembunyikan darinya.

• Seorang user menyamar sebagai orang lain dan mendapatkan akses, sehingga aksinya tercatat dilakukan oleh orang lain tersebut. Pada sistem terdistribusi, user mungkin saja mendelegasikan proses pada objek lain, sehingga objek tersebut dapat digunakan untuk kepentingannya.

• Kurangnya accountability, misalnya identitas user yang tidak mencukupi.

• Penyadapan untuk mendapatkan data yang seharusnya dirahasiakan.

• Memodifikasi pada komunikasi antar objek (mengubah, menambah maupun menghapus item) Tingkat keamanan suatu sistem yang merupakan sasaran bagi berbagai macam serangan, kadang merupakan hasil tawar-menawar pada desain dan implementasi,biasanya untuk mencapai tujuan yang dinginkan seperti penambahan kinerja atau fungsi tambahan.

Goal

Hal-hal mendasar pada sistem keamanan, yaitu confidentiality, integrity,accountability, dan availability adalah dasar untuk membangun sistem keanaman pada CORBA. Namun, sistem CORBA bukanlah jenis sistem informasi biasa, melainkan karena sifat terdistribusinya, sistem ini memiliki potensi ancaman yang mungkin tidak terdapat pada sistem lain.Oleh karena sifat terdistribusi tersebut, beberapa tujuan keamanan yang khusus pada CORBA adalah:

• menyediakan keamanan atas sistem heterogen dimana vendor yang berbeda mungkin mensuplai ORB yang berbeda pula

• karena sistem CORBA berorientasi objek, maka spesifikasi-nya juga harus berorientasi objek:

- interface harus sepenuhnya objek oriented murni.

- model harus menggunakan enkapsulasi untuk menampilkan kesatuan sistem dan menyembunyikan kompleksitas mekanisme sekuriti dibawah interface sederhana.

- model harus mengizinkan implementasi polimorfisme pada objeknya yang berbasis pada mekanisme lapisan bawah berbeda, sehingga menyediakan apa yang disebut teknologi keamanan independen.

• Secure Object Invocation, untuk memastikan invocation diproteksi oleh aturan sekuriti

• Access Control dan Auditing, untuk memastikan bahwa accsess control dan auditing yang diperlukan telah diterapkan pada invocation objek.

Fitur

Dalam rangka menghadapi ancaman yang telah disebutkan diatas dan mencapai tujuan yang diinginkan, spesifikasi OMG menentukan fitur-fitur kunci yang harus diproses oleh sistem keamanan pada CORBA, yaitu:

• Identification dan Authentication

• Authorisation dan Access control (memutuskan apakah suatu user dapat mengakses objek (umumnya menggunakan identitas secara normal dan/atau atribut istimewa lain) dan apakah atribut kontrol dari objek target dapat mengaksesnya)

• Security Auditing (untuk membuat mencatat semua kegiatan user yang berhuungan dengan sekuriti. Mekanisme auditing harus harus dapat mengidentifikasi user secara benar, bahkan setelah rangkaian call melalui banyak objek)

• Keamanan dari komunikasi antar objek (hal ini memerlukan koneksi yang terpercaya antara client dan target, yang mungkin memerlukan autentifikasi dari client untuk target, maupun autentifikasi dari target untuk client. Hal ini juga memerlukan integrity protection dan confidentiality protection untuk message yang dikirimkan antar object)

• Non-repudiation (menyediakan bukti nyata dari suatu aksi yang dilakukan oleh user)

• Administrasi dari informasi sekuriti.

Penerapan Sistem Keamanan

Spesifikasi keamanan CORBA menentukan bagaimana menyediakan keamanan dalam sistem CORBA. Spesifikasi tersebut mendefiniskan dua level fungsionalitas sekuriti yang utama (main security functionality), yaitu:

• Level 1: menyediakan keamanan pada level pertama untuk aplikasi yang tidak peduli pada keamanan dan untuk yang memiliki kemampuan terbatas dalam menangani sekuriti mereka (dalam arti access control dan auditing).

• Level 2: menyediakan fasilitas keamanan yang lebih tinggi dan mengizinkan aplikasi untuk mengontrol keamanan yang disediakan pada invokasi objek. Level ini juga

termasuk administrasi dari aturan sekuriti.Sebagai tambahan pada dua level sekuriti dasar ini, spesifikasi OMG juga menentukan suatu arsitektur yang dapat mensuport bermacam-macam aturan keamanan untuk memenuhi kebutuhan yang berbeda-beda.

 Model Keamanan

Model referensi sekuriti yang didefinisikan pada spesifikasi OMG adalah model yang mendeskripsikan keseluruhan framework dari sistem keamanan CORBA, dengan tujuan untuk memperlihatkan fleksibilitas yang diperlukan untuk mendefinisikan berbagai aturan sekuriti yang berbeda-beda.

Secara actual, model tersebut sebagai keseluruhan dibagi menjadi beberpa model terpisah, bagian yang paling penting adalah apa yang disebut “Principle” beserta atributatributnya,dan Secure Object Invocations.Principle didefinisikan sebagai user dan objek yang perlu beroperasi sendiri.Intinya, model tersebut mendeskripsikan mengapa dan bagaimana user dan apa yang dapat dilakukan mereka dapat dimodelkan.Membuat identifikasi dan authorisasi pada tiap invokasi akan tidak efisien, oleh karena itu model tersebut mengenalkan konsep tentang asosiasi security. Dengan konsep keamanan asosiasi tersebut, identifikasi dan authorisasi tetap bertahan untuk banyak

interaksi, tidak hanya untuk sebuah invokasi.Secure Object Invocation menanggulangi masalah pada komunikasi yang tidak aman melalui message protection. Message dapat diproteksi dengan menggunakan algoritma enkripsi baik simetrik maupun asimetrik. Message hanya diprotek dengan kualitas proteksi yang diperlukan oleh aturan keamanan, hal ini mungkin dilakukan untuk memastikan integritas dan menyediakan konfidentialitas. Bila keamanan telah disediakan oleh layer dibawahnya (missal melalui SSL), maka komunikasi software pada ORB tidak perlu menyediakan sekuriti sendiri.

Arsitektur Keamanan

Arsitektur Sekuriti dalam spesifikasi OMG, menjelaskan bagaimana model sekuriti diimplementasikan dan terdiri dari berbagai bagian yang berbeda. Bagian yang paling penting adalah model structural yang mendeskripsikan suatu arsitektur konsep utama dimana spesifikasi lainnya berdasar. Arsitektur keamanan juga mendefinisikanempat level dari object yang digunakan selama invokasi objek, yaitu:

• Komponen Application-level (yang dapat mengindahkan maupun tak mengindahkan keamanan)

• Komponen yang mengimplementasikan servis sekuriti, independen dari teknologi sekuriti pada  layer dibawahnya (spesifikasi mengizinkan penggunaan interface pengisolasi antara level ini dan teknologi keamanan, mengizinkan penggunaan teknologi keamanan yang berbeda). Komponen-komponen tersebut adalah:

-ORB core dan servis ORB.

-Servis keamanan.

-Aturan objek yang digunakan untuk menjalankan aturan sekuriti:

• Komponen yang mengimplementasikan teknologi sekuriti khusus

• Proteksi dan komunikasi dasar, umumnya disediakan oleh kombinasi perangkat keras dan mekanisme Sistem Operasi.

Pada gambar diatas, arsitekur keamanan terlihat rumit dan terdiri dari bermacammacam objek. Yang paling penting adalah bahwa tidak ada code spesifik untuk teknologi keamanan yang eksplisit sebagai bagian dari arsitektur. Semua code spesifik tersebut disembunyikan dalam servis ORB dan objek mengenkapsulasinya hingga dapat menggunakan underlayingteknologi keamanan yang berbeda.

Interface

Interface memastiken model sekuriti diimplementasikan secara standard dan dapat dipertukarkan. Spesifikasi OMG juga menentukan sejumlah interface, yaitu: Application developer's interface, administrator's interface, dan the implementor's security interface. Sebagai tambahan pada interface-interface tersebut, spesifikasi OMG mendefinisikan beberapa ekstensi ke IDL.

Penerapan pada ORB

Sistem keamanan adalah servis CORBA dan bukan bagian integral dari CORBA core. Namun, hanya menambah beberapa objek keamanan tidak menjamin operasi yang aman, maka penerapan keamanan pada ORB diperlukan. Keamanan CORBA meliputi:

• Main security functionality

terdiri dari dua pilihan, yaitu fungsionalitas sekuriti level 1 dan level 2

• Security Functionality Options

dalam spesifikasi ini hanya berisi non-repudiation.

• Security Replaceability

tediri dari dua pilihan:

- ORB Services replaceability (ORB menggunakan interceptor untuk memanggil servis objek, termasuk keamanan)

- Security Service replaceability (ORB dapat menggunakan/tidak menggunakan interceptor , tapi semua call pada servis sekuriti dibuat melalui interfase replaceability yang sudah dispesifikasi)

• Secure Interoperability

terdapat dua pilihan, yaitu:

- Secure Interoperability Standard, ORB dapat menggunakan dan membangkitkan informasi sekuriti dalam IOR dan dapat mengirim serta menerima request menggunakan GIOP/IIOP dengan peningkayan security (SECIOP).

- Standard plus DCE-CIOP Option, ORB mensupport pilihan standar dan juga menyediakan interoperabilitas yang aman dengan menggunakan servis keamanan DCE dan protocol DCE-CIOP.

Spesifikasi ORB memperkenalkan interceptor. Suatu interceptor bertanggung jawab terhadap eksekusi satu atau lebih servis ORB dan secara logika diletakkan dalam jalur invokasi antara objek client dan objek target. Dua tipe interceptor didefinisikan dalam spesifikasi ini, yaitu request level interceptor dan message level interceptor.Dimana request level interceptor mengeksekusi request yang diberikan, sedangkan message level interceptor mengirim dan menerima message yang diturunkan dari request dan reply. Spesifikasi OMG mendefinisikan servis ORB mana yang harus   dipanggil oleh interceptor. Ketika ORB perlu untuk mem-bind suatu Object Reference (OR), maka ORB interceptor yang sesuai dengan karakteristik objek tersebut.

RMI

RMI (Remote Method Invocation) adalah cara programmer Java untuk  membuat program aplikasi Java to Java yang terdistribusi. Program-program yang menggunakan RMI bisa menjalankan metode secara jarak jauh, sehingga program dari server bisa menjalankan method di komputer klien, dan begitu juga sebaliknya.

Java RMI yang ada pada bahasa Java telah didesain khusus sehingga hanya bisa bekerja pada lingkungan Java. Hal ini berbeda dengan sistem RMI lainnya, misalnya CORBA, yang biasanya didesain untuk bekerja pada lingkungan yang terdiri dari banyak bahasa dan heterogen. Pemodelan objek pada CORBA tidak boleh mengacu pada bahasa tertentu.

Sistem RMI terdiri atas tiga layer/lapisan, yaitu
1. stub/skeleton layer, yaitu stub pada sisi klien (berupa proxy), dan skeleton pada sisi server.
2. remote reference layer, yaitu perilaku remote reference (misalnya pemanggilan kepada suatu objek)
3. transport layer,  yaitu set up koneksi, pengurusannya dan remote object tracking.

Batas antar masing-masing layer disusun oleh interface dan protokol tertentu, yaitu tiap layer bersifat independen terhadap layer lainnya, dan bisa diganti oleh implementasi alternatif tanpa mengganggu layer lainnya. Sebagai contoh, implementasi transport yang digunakan RMI adalah yang berbasis TCP (menggunakan Java socket), tapi bisa digantikan dengan menggunakan UDP.

 

Sebuah remote method invocation dari klien ke remote server object akan melalui layer-layer pada sistem RMI dari layer transport pada sisi klien ke layer transport pada sisi server.

Sebuah klien yang menjalankan method pada remote server object sebenarnya menggunakan stub atau proxy yang berfungsi sebagai perantara untuk menuju remote server object tersebut. Pada sisi klien, reference ke remote object sebenarnya merupakan reference ke stub lokal. Stub ini adalah implementasi dari remote interface dari sebuah remote object, dan meneruskan panggilan ke server object melalui remote reference layer. Stub dibuat dengan menggunakan kompiler rmic.

Supaya sebuat panggilan method tersebut bisa sampai di remote object, panggilan tersebut diteruskan melalui remote reference layer.  Panggilan tersebut sebenarnya diteruskan ke skeleton yang berada di sisi server. Skeleton untuk remote object ini akan meneruskan panggilan ke kelas remote object implementation yang menjalankan method yang sebenarnya. Jawaban, atau return value dari method tersebut akan dikirim melalui skeleton, remote reference layer dan transport layer pada sisi klien, lalu melalui transport layer, remote reference layer, dan stub pada sisi klien.

Teknik dalam RMI salah satunya adalah dynamic stub loading, yang berfungsi untuk membuat klien me-load stub yang belum ada di komputernya. Stub mengimplementasi remote interface yang sama dengan yang diimplementasikan oleh remote object.

Dengan RMI, komputer klien bisa memanggil remote object yang berada di server. Server juga bisa  menjadi klien dari suatu remote object, sehingga komputer klien bisa menjalankan method-method tertentu di komputer server. Dengan menggunakan RMI, program yang dijalankan di komputer klien bisa berupa applet, maupun berupa aplikasi.

Program RMI memerlukan remote interface, kelas-kelas implementasi dari remote interface tesebut (implementation class), dan program rmiregistry yang sedang dijalankan di komputer server (rmiregistry terdapat dalam paket JDK).

Pada paket Whiteboard, RMI digunakan untuk program-program Chat, Whiteboard dan Projector. Dalam program Chat, RMI digunakan untuk memasukkan input dari para pengguna, baik dosen maupun mahasiswa, ke komputer server. Setelah itu, server akan mengeluarkan output berupa hasil percakapan antar pengguna kepada semua komputer klien.  Pada Whiteboard, penggunaan RMI terletak pada pengiriman graphics dan image antara komputer server dan klien. Sedangkan pada Projector, RMI digunakan agar dosen, sebagai klien, bisa mengatur indeks tampilan pada Projector yang berlangsung pada komputer mahasiswa, yang berfungsi sebagai klien lainnya.

Kelas WhiteboardClient adalah tampilan yang dimunculkan pada komputer klien, sedangkan penggunaan RMI dilakukan oleh kelas WhiteboardClientManifestImplementation. Kelas WhiteboardClientManifestImplementation merupakan kelas yang mengimplementasikan interfaceWhiteboardClientManifest.Dalam konsep RMI, interface WhiteboardClientManifest ini adalah remote interface untuk klien. Sedangkan pada server dijalankan program WhiteboardServer Implementation yang berupa implementasi dari interface WhiteboardServer. WhiteboardServer juga merupakan remote interface. Program WhiteboardServer Implementation ini bersifat public, sehingga bisa diakses oleh klien.

Remote interface harus meng-extend interface java.rmi.Remote. Setiap method pada remote interface harus meng-throw java.rmi.RemoteException.

WhiteboardClientManifest     Implementation dan WhiteboardServer Implementation adalah implementation classes. Implementation class merupakan kelas yang mengimplementasikan remote interface. Implementation class perlu mendefinisikan konstruktor untuk remote object, sekaligus membuat instance dari remote object tersebut.  Implementation class juga menyediakan implementasi dari method yang bisa dijalankan secara remote. Selain itu implementation class juga perlu membuat dan menjalankan Security Manager. Tambahan lagi, implementation class juga harus me-register atau mendaftarkan paling tidak sebuah remote object pada RMI remote object registry. Pada program implementation class, semua argumen untuk remote method dan semua return value dari remote method bisa berupa object bertipe apa saja, asal object-object tersebut mengimplementasi interface java.io.Serializable.

Untuk remote objects, penyampaiannya dilakukan dengan pass by reference. Referensi untuk suatu remote object sebenarnya merupakan referensi untuk sebuah stub, yaitu proxy pada sisi klien untuk remote object.

Pada method main di implementation class, diperlukan pembuatan dan pemasangan sebuah security manager, yang bisa berupa RMISecurityManager, ataupun security manager yang sebelumnya telah didefinisikan dulu secara khusus oleh sang programmer. Security manager ini diperlukan untuk menjaga agar kelas-kelas yang dipakai tidak melakukan operasi-operasi yang bisa mengancam keamanan sistem. Jika dalam method main tidak terdapat security manager, RMI tidak bisa digunakan karena kelas-kelas RMI tidak akann diijinkan untuk di-load.

Dalam method main, suatu instance dari remote object harus diciptakan. Konstruktor akan menghasilkan remote object, dan sebagai hasilnya, setelah konstruktor dipakai untuk menciptakan instance, sebuah remote object akan siap untuk mendengar method-method panggilan dari komputer klien.

Agar komputer klien bisa menjalankan method di remote object, klien sebelumnya harus membuat referensi kepada remote object tersebut. Biasanya referensi diambil dengan cara dijadikan parameter dari suatu remote method, ataupun diambil dari return value suatu remote method.

Untuk keperluan bootstrapping, RMI menyediakan registry yang bisa mem-bind suatu URL ke remote object. Bentuk atau format dari URL tersebut adalah : //host/nama_object, dan nama_object harus berupa nama berbentuk string. Setelah suatu remote object diregistrasi di server, komputer-komputer klien bisa mencari nama objek tersebut, mengambil referensi ke remote-object, dan seterusnya menjalankan method pada objek tersebut.

RMI akan membuat referensi ke stub dari remote object dengan referensi yang ditentukan oleh argumen kedua dari perintah Naming.rebind(URL, argumen ke-2). Objek implementasi yang ada di komputer klien (remote implementation objects) akan selalu berada di komputer klien, jadi sewaktu klien melakukan pencarian ke remote object yang ada ada di registry di server, komputer server akan melakukan referensi ke stub yang berada di komputer klien.

Protokol yang dipakai oleh RMI adalah Java Object Serialization dan HTTP. Protokol Object Serialization digunakan unntuk meneruskan panggilan klien dan mentransfer data. Protokol HTTP digunakan untuk mem-"POST" sebuah remote method invocation dan mengembalikan data keluaran untuk situasi ketika komputer klien dan server dipisahkan oleh firewall.