PENGENALAN CORBA

• What is CORBA?

• CORBA adalah sebuah standard untuk interoperabilitas obyek

• Mendukung bahasa yang berbeda

• Mendukung platform yang berbeda

• Komunikasi pada jaringan

• Service tambahan ( misalnya : sekuritas )

• CORBA didefinisikan oleh OMG (Object Management Group)

• OMG berdiri sejak 1989, bertujuan untuk memperkenalkan teori dan

praktek dari teknologi obyek dalam sistem komputer terdistribusi

• CORBA 1 diluncurkan pada1991

• Sekarang sampai pada CORBA 3

• Informasi : http://www.omg.org

• CORBA adalah komponen dari OMA (Object Management Architecture)

• Desain CORBA berdasar atas OMG Object Model

• OMG Object Model

• OMG Object Model mendifinisikan semantik umum untuk menspesifikasikan

karakteristik eksternal yang visibel dari object dalam suatu standard dan dengan

cara implementation-independent. Dalam model ini, clients meminta service dari

objects ( yang juga disebut servers ) melalui interface yang telah didefinisikan.

Interface ini dispesifikasikan dalam OMG IDL (Interface Definition Language).

Sebuah client mengakses sebuah object dengan melakukan request ke suatu

object(s). Request merupakan suatu event yang membawa informasi termasuk

sebuah operasi, object reference dari pemberi service dan parameter actual ( jika

ada ). Object reference adalah nama sebuah nama object yang dapat diacu.

• What is OMA?

• OMA adalah spesifikasi standar ( yang saling berhubungan ) yang mendefiniskan

cakupan yang luas mengenai layanan dalam mengembangan aplikasi terdistribusi.

OMA terdiri atas, empat komponen yang dapat dibagi menjadi dua bagian :

komponen berorientasi (Object Request Brokers and Object Services dan

komponen berorientasi aplikasi (Application Objects and Common Facilities).

• Object Request Broker adalah salah satu bagian dasar dari OMA dan mengatur

semua komunikasi diantara komponen-komponennya. ORB memungkinkan

objects berinteraksi secara heterogen, dalam lingkungan/sistem tersebar,

independen dari platform dimana objects ini berada dan teknis yang digunakan

untuk mengimplementasikannya. Dalam menjalankan tugasnya, OMA berdasar

atas Object Services yang bertanggung jawab secara umum untuk manajemen

object seperti membuat object, acces control, meengontrol object yang

dialokasikan, dsb. Common Facilities danplication Objects adalah komponenkomponen

yang dekat dengan user dan dalam fungsinya, mereka membangkitkan

service pada komponen-komponen sistem.

Common Object Request Broker Architecture (CORBA)

• Standarisasi untuk sebuah ORB (Object Request Broker)

• IIOP (Internet Inter-ORB Protocol) : standarisasi yang digunakan untuk

komunikasi

• Mendefinisikan interface bahasa dan tool-tool

• Object Services ( service umum )

• Service inti yang dibutuhkan untuk mengembangkan arsitektur

terdistribusi

• Naming : membolehkan client untuk menemukan object berdasar namanya

• Trading : membolehkan client untuk menemukan object berdasar

propertinya

• Lainnya: Security, Transactions, event notification, lifecycle management,

dsb.

• Common Facilities ( high-level services )

• Layanan ini berguna untuk aplikasi terdistribusi dalam beberapa kondisi

pada aplikasi bersangkutan. Dua kategori umum Common Facilities

adalah horizontal dan vertical; dimana menentukan aturan kerja sama

komponen bisnis yang dibutuhkan agar bekerja secara efektif. Fasilitas

yang ada dalam Common Facilities adalah : Distributed Document , User

Interface, Information Management, System Management, Task

Management.

• Misalnya, Distributed Document Component Facility (DDCF) -- OpenDoc

• Allowing for the presentation and interchange of objects based on

a document model facilitating the linking of a spreadsheet object

into a report document

• Domain Interface

• Antar muka ini lebih berorientasi langsung pada domain aplikasi. Sebagi

contoh, salah satu OMG RFP yang ada adalah untuk Product Data

Management ( PDM ) yang digunakan untuk industri manufaktur. Selain

OMG tersebut diatas ada beberapa yang akan dikembangkan untuk bidang

telekomunikasi, medis dan keuangan.

• Application Interface

• Antar muka ini dikembangkan khusus untuk aplikasi diinginkan. Karena

antar muka ini bergantung kepada aplikasi yang akan dikembangkan dan

juga karena OMG tidak mengembangkan aplikasi tetapi hanya spesifikasi

aplikasi sehingga interface ini tidak mempunyai standar baku.

Some ORBs

• CORBA Software (http://www.infosys.tuwien.ac.at/Research/Corba/software.html)

– Orbix (IONA)

– VisiBroker (Inprise)

– ObjectBroker (BEA)

– PowerBroker (Expersoft)

– ORB Plus (HP)

– ORBacus (Object-Oriented Concepts, Inc.)

– NEO/JavaIDL (SunSoft)

Why CORBA?

• Need to share information and resources within and across diverse computing

enterprises

– CORBA is a Middleware Standard

– CORBA is a “Software Bus”

– CORBA is a Distributed Object Architecture

CORBA is a Middleware Standard

• Sebelum CORBA, middleware didominasi oleh vendor yang dikeluarkan pembuat

tools

Secara umum, ada lima kategori middleware yang dikelompokkan berdasarkan

standar signifikan atau produk di pasaran, yaitu :

1. Data Access, konektivitas ke basis data

2. Remote Procedural Call ( RPC ), invokasi antar aplikasi secara jauh dan

procedural

3. Transaction Processing Monitor, manajemen transaksi pada sistem tersebar

4. Message Oriented Middleware ( MOM ), komunikasi asynchronous antar

sistem

5. Distributed Object, invokasi object antar aplikasi di sistem tersebar.

CORBA ORB Architecture

Fungsionalitas dasar yang disediakan oleh ORB terdiri dari passing request dari client ke

implementasi object. Untuk membuat request, client dapat berkomunikasi dengan ORB

Core melalui IDL stub atau melalui Dynamic Invocation Interface (DII). Stub

merepresentasikan pemetaan diantara bahasa untuk implementasi dari client dan ORB

Core. Kemudian client dapat ditulis dalam sembarang bahasa asalkan implementasi dari

ORB mendukung pemetaan ini. ORB Core kemudian mentransfer request ke suatu

implementasi object yang menerima request sebagai up-call melalui IDL skeleton atau

sebuah dynamic skeleton.

Komunikasi diantara implementasi object dan ORC core dipengaruhi oleh Object

Adapter (OA). OA menangani service seperti pembangkitan dan interpretasi dari object

references, method invocation, securitas dari interaksi, aktivasi dan de-aktivasi

implementasi object, mapping reference sesuai dengan implementasi object dan registrasi

dari implementasi. Di masa datang diharapkan akan ada banyak object adapter khusus

yang berbeda untuk memenuhi kebutuhuan sistem yang khusus ( sebagai contoh

basisdata ).

OMG mendefinisikan empat aturan dimana OA dapat menangani aktivasi implementasi

object :

Shared Server Polic : Banyak obyek yang aktif share server/program yang sama. Server

melayani request dari banyak client. Server akan tetap aktif sampai server dimatikan.

Unshared server Policy : Hanya satu object yang aktif di server. Server akan mati ketika

client yang menyebabkan aktif keluar.

Server-per-method Policy : Setiap request menghasilkan

Persistent server Policy : Implementasi object secara konstan aktif ( jika tidak, maka

akan dibangkitkan Exception ).

Jika sebuah request dibangkitkan selain berdasar policy diatas, object akan diaktifkan

oleh OA dalam policy khusus. Untuk melakukannya, OA membutuhkan akses ke

informasi tentang lokasi object dan lingkungan yang ada. Basisdata yang berisi informasi

tersebut disebut Implementation Repository dan merupakan komponen standar dari

arsitektur CORBA. Informasi didapat dari sana oleh OA pada aktivasi object..

Implementation Repository dapat juga berisi informasi lain mengenai implementasi

service, seperti debugging, versi dan administrasi informasi.

Interface ke object dapat dispesifikasikan dalam dua cara : OMG IDL atau dapat

ditambahkan ke Interface Repository. Dynamic Invocation Interface membolehkan client

untuk melakukan request ke object yang definisi dan interfacenya tidak diketahui pada

waktu kompilasi client. Untuk menggunakan DII, client harus menyusun sebuah request

termasuk object reference, operasi dan daftar parameter. Spesifikasi ini ( dari objects dan

services yang disediakan ) di-retrieve dari Interface Repository, sebuah basisdata yang

menyediakan penyimpanan tetap dari definisi interface object. Interface Repository juga

berisi informasi mengenai tipe parameter-parameter, informasi debugging tertentu, dsb.

Analogi server side dari DII adalah Dynamic Skeleton Interface (DSI), dengan

menggunakan interface ini, operasi tidak lagi mengakses melalui sebuah operationspecific

skeleton, yang dibangkitkan dari spesifikasi interface IDL, malahan operasi

dicapai melalui sebuah interface yang menyediakan akses ke nama operasi dan

paramater-parameter ( seperti DII, diatas, informasi dapat didapat dari Interface

Repository). Sehingga DSI adalah sebuah cara untuk mengantarkan request dari ORB ke

sebuah implementasi object yang tidak mempunyai pengetahuan waktu kompilasi dari

suatu object yang sedang diimplementasikan. Meskipun pertama kali sekilas terlihat

bahwa situasi ini tidak sering terjadi, dalam kenyataannya DSI adalah sebuah jawaban

untuk tools software development yang interaktif berbasis interpreters dan debuggers.

How Does CORBA Work?

• Langkah 1 : Tulis sebuah spesifikasi untuk setiap object menggunakan IDL

(Interface Definition Language)

• Langkah 2 : Compile IDL untuk membangkitakn client stub dan kode server

skeleton

• Langkah 3 : Tulis kode aplikasi client

• Langkah 4 : Tulis kode object server

• Langkah 5 : Kompile kode client dan server

• Langkah 6 : Hidupkan server

• Langkah 7 : Jalankan aplikasi client

IDL ( Interface Definition Language )

IDL adalah bahasa yang digunakan untuk mendefinisikan interface diantara komponen

aplikasi. IDL bukan bahasa procedural; IDL hanya dapat mendefinisikan interface, bukan

implementasi. Programmer C++ dapat menganalogikan definisi IDL sebagai header file

untuk class-class; sebuah header file biasanya tidak berisi berisi implementasi dari suatu

class, tetapi hanya mendeskripsikan interface class. Kemungkinan programmer Java lebih

menyukai definisi IDL untuk mendefinisikan interface Java.

Spesifikasi IDL bertanggung jawab untuk menjamin pertukaran data diantara bahasa

yang berbeda. Sebagai contoh, tipe long pada IDL adalah 32-bit signed integer, yang

dapat dipetakan ke C++ long (tergantung pada platform ) atau int Java. Hal ini

merupakan tanggung jawab dari spesifikasi IDL dan kompiler IDL yang

mengimplementasikan untuk mendefinisikan tipe data dalam language-independent.

Daftar Pustaka

http://www.omg.org

http://developer.java.sun.com/developer/onlineTraining/corba/corba.html

A Brief Tutorial on CORBA Kate Keahey, Indiana University :

http://www.cs.indiana.edu/hyplan/kksiazek/tuto.html

http://www.cs.indiana.edu/~kksiazek/tuto.html

http://www.cs.wustl.edu/~schmidt/corba.html

http://www.cs.wustl.edu/~schmidt/PDF/corba4.pdf

http://courses.cs.tamu.edu/cpsc608/hohin/summer00/notes/corba.ppt

Dokumentasi Java j2sdk-1_4_1 ( Dapat didownload di http://java.sun.com atau email

dana@stttelkom.ac.id)

Teach Yourself CORBA In 14 Days : Sams' Teach Yourself CORBA in 14 Days

Jeremy Rosenberger

Client/Server Programming with Java and CORBA : Robert Orfali and Dan Harkey.

1997, John Wiley and Sons, Inc.