UNIVERSITAS

MUHAMMADIYAH
MALANG

Resume HF EJB :
Chapter II
ZAINAL BUCHORI
ARIEF PURNAMA ADJI
KHOIRUL HIDAYAT
M. ARIF ARIO ISLAM

(201110370311260)
(201110370311251)
(201110370311284)
(201110370311261)

Arsitektur EJB
Aristektur Enterprise JavaBeans adalah arsitektur komponen untuk
development dan deployment dari aplikasi bisnis terdistribusi berbasis komponen.
Aplikasi yang dibuat dengan artistektur Enterprise JavaBeans adalah skalabel,
transaksional, dan multiuser yang aman. Aplikasi-aplikasi ini mungkin ditulis sekali
dan dideploy pada berbagai platform server yang mendukung spesifikasi Enterprise
JavaBeans.
Konsep EJB terletak di container. Selebihnya EJB dibangun dari plain Java,
kumpulan dari library (bean) yang menurut Sun dibutuhkan untuk aplikasi
enterprise saat ini. Konsep bean sudah ada di Java SE atau secara konsep bahkan
sebelum Java. Inti dari bean cukup sederhana yaitu objek yang di rancang untuk
reusability.
Perbedaan EJB dgn bean terletak di container, yang sebenarnya adalah layer
sekaligus abstraksi tambahan yang di definisikan oleh Sun. Tujuan EJB adalah
mendefinisikan sebuah standar bagi para developer untuk membuat bean yang
capable untuk sistem enterprise.
Kebutuhan enterprise (saat ini) antara lain: remote invocation, scalability,
manageable.
Implementasi remoting sudah ada dari sebelum EJB misal dari socket, CORBA, RMI,
sampai WS. Konsep scalability misalkan: clustering, thread pooling, dsb. Jadi
sebenarnya developer bisa saja (dan tetap reasonable utk beberapa kasus)
mengimplementasikan kebutuhannya tanpa EJB. Namun di sinilah peranan EJB
sebagai framework yang standar (dan juga framework yang lain), memudahkan
(simplifikasi) developer untuk mengembangkan aplikasi.
Dengan container, bean dapat berinteraksi satu sama lain tanpa harus tahu secara
spesifik implementasi antar bean (abstraksi).JVM sendiri sebenarnya adalah sebuah
container. Dengan JVM, objek akan dapat berjalan di beberapa OS tanpa perubahan
kode. EJB dibangun di atas JVM, jadi EJB sebenarnya adalah kumpulan objek di atas
JVM, jadi wajar
EJB bisa berkomunikasi dengan EJB lain di beda JVM selama
JVM tersebut kompatibel.
EJB adalah salah satu framework Java, dan framework hanya memfasilitasi kita
melakukan pengembangan software. Apakah kita memilih CORBA, WS, RMI, Plain
Socket,dll.. menurut saya itu seharusnya sudah ada di luar scope EJB sebagai
framework.
Dan satu lagi, EJB adalah sebuah produk, EJB dibentuk dari konsep yang sudah ada
dan dipakai sebelumnya. Contohnya implementasi AOP pada EJB, sebenarnya
sebelum EJB, AOP sudah digunakan secara luas (AspectJ). JPA (Java Persistence API),
spesifikasi objek persisten pada EJB dibangun dengan mengadopsi Hibernate (Open
source ORM).

RMI adalah sebuah teknik pemanggilan method remote yang lebih secara umum
lebih baik daripada RPC. RMI menggunakan paradigma pemrograman berorientasi
obyek (Object Oriented Programming). RMI memungkinkan kita untuk mengirim
obyek sebagai parameter dari remote method. Dengan dibolehkannya program Java
memanggil method pada remote obyek, RMI membuat pengguna dapat
mengembangkan aplikasi Java yang terdistribusi pada jaringan.

Aplikasi RMI seringkali terdiri dari dua program terpisah yaitu server dan client.
Aplikasi server semacam ini biasanya membuat beberapa objek remote,
menyediakan referensi terhadap objek-objek tersebut sehingga dapat diakses, serta
menunggu client memanggil method dari objek-objek remote tersebut. Aplikasi
client mendapatkan referensi remote ke satu atau lebih objek remote di server dan
menjalankan method dari objek tersebut.
RMI menyediakan mekanisme dimana server dan client berkomunikasi dan
memberikan informasi secara timbal balik. Aplikasi semacam ini seringkali disebut
aplikasi objek terdistribusi.

Remote Method Invocation adalah teknologi remoting berbasis Java yang

memungkinkan 2 buah aplikasi yang berjalan diatas JVM (Java Virtual Machine) yang
berbeda dapat saling berkomunikasi. Dengan RMI sebuah objek dapat menginvoke/memanggil sebuah method dari remote objek.

RMI adalah sebuah teknik pemanggilan method remote yang lebih secara umum
lebih baik daripada RPC. RMI menggunakan paradigma pemrograman berorientasi
obyek (Object Oriented Programming). RMI memungkinkan kita untuk mengirim
obyek sebagai parameter dari remote method. Dengan dibolehkannya program Java
memanggil method pada remote obyek, RMI membuat pengguna dapat
mengembangkan aplikasi Java yang terdistribusi pada jaringan.

Membangun suatu aplikasi terdistribusi menggunakan RMI meliputi 6 langkah.

Keenam langkah tersebut adalah:
1. Mendefinisikan remote interface
2. Implementasi remote interface dan server
3. Pengembangan client (atau applet) yang menggunakan remote interface
4. Mengkompilasi source files dan mem-buat stub and skeletons

5. Memulai (start) RMI registry

6. Menjalankan server dan client

RMI Sublayer terdiri dari

Proxy (di client), tempat penyimpan lokal untuk remote objek
Dispatcher (di server), menerima request dan menggunakan methodID untuk
memilih message di skeleton
Skeleton (di server), menerapkan method dalam remote interface

JVM (Java Virtual Machine) adalah sebuah mesin imajiner (maya) yang bekerja
dengan menyerupai aplikasi pada sebuah mesin nyata. JVM menyediakan spesifikasi
hardware dan platform dimana kompilasi kode Java terjadi. Spesifikasi inilah yang
membuat aplikasi berbasis Java menjadi bebas dari platform manapun karena
proses kompilasi diselesaikan oleh JVM.
Remote Procedure Call (RPC) adalah sebuah metode yang memungkinkan kita
untuk mengakses sebuah prosedur yang berada di komputer lain. Untuk dapat
melakukan ini sebuah server harus menyediakan layanan remote procedure.
Pendekatan yang dilakuan adalah sebuah server membuka socket, lalu menunggu
client yang meminta prosedur yang disediakan oleh server. Bila client tidak tahu
harus menghubungi port yang mana, client bisa me- request kepada sebuah
matchmaker pada sebuah RPC port yang tetap. Matchmaker akan memberikan port
apa yang digunakan oleh prosedur yang diminta client.
RPC masih menggunakan cara primitif dalam pemrograman, yaitu menggunakan
paradigma procedural programming. Hal itu membuat kita sulit ketika menyediakan
banyak remote procedure. RPC menggunakan socket untuk berkomunikasi dengan
proses lainnya. Pada sistem seperti SUN, RPC secara default sudah ter- install
kedalam sistemnya,
Untuk proses nya kurang lebih sama dengan RMI. Kalau RMI kita mengenal proxy
dan skeleton, pada RPC dikenal dengan Stub ( Client stub dan Server stub)
Argumen dan nilai kembalian
Primitif
Serializable Objek
Sebuah Array atau koleksi primitif atau Serializable objek
Remote Objek
Melewatkan remote objek melalui method remote
RMI memungkinkan kita untuk mengirim obyek sebagai parameter dari remote
method. Dengan dibolehkannya program Java memanggil method pada remote

obyek, RMI membuat pengguna dapat mengembangkan aplikasi Java yang

terdistribusi pada jaringan.
Aplikasi RMI seringkali terdiri dari dua program terpisah yaitu server dan client.
Aplikasi server semacam ini biasanya membuat beberapa objek remote,
menyediakan referensi terhadap objek-objek tersebut sehingga dapat diakses, serta
menunggu client menginvoke/memanggil method dari objek-objek remote tersebut.
Aplikasi client mendapatkan referensi remote ke satu atau lebih objek remote di
server dan menjalankan method dari objek tersebut.
RMI menyediakan mekanisme dimana server dan client berkomunikasi dan
memberikan informasi secara timbal balik.
Session Bean dapat menjadi staless atau statefull
Salah satu perbedaan mendasarnya adalah jika stateful digunakan untuk layanan
yang memerlukan informasi yang disimpan selama klien berinteraksi dengan
aplikasi, tidak hanya untuk pemanggilan satu method saja, misalnya untuk
shopping cart, entry data di lebih dari satu halaman dll. Dan begitu pula sebaliknya
dengan stateless dia menghapus informasi selama klien berinteraksi.

Ketika nilai kembalian adalah remote objek

Penjelasan gambar diatas adalah client ingin memanggil method getCstomer() pada
remote objek menggunakan stb A maka client menyampaikan pesan ke stub A
selanjutnya stub A menyampaikan ke skel dan skel melanjtkan ke Remote objek A.

Penjelasan dari gambar diatas adalah remote objek mengembalikan nilai ke

customer objek (Remote objek B) melalui skelton diterskan ke stub dan
dikembalikan ke client.
POIN PENTING
1. EJB menggunakan RMI bean sehingga dapat diakses oleh remote client.
2. Remote client pada conteks ini adalah objek yang berada pada JVM yang
berbeda, bisa disebut juga di heap yang berbeda.
3. Stub objek menangani jaringan level ringan pada saat komunikasi dengan
remote objek.
4. Remote objek berada pada heapnya sendiri, ketika client memanggil method
pada proxy remote objek, maka yang dipanggil adalah stub.
5. Ketika client ingin memanggil method pada remote objek, client memanggil
method yang sama pada stub. Stub berada pada heap yang sama sebagai
client.
6. Untuk client, remote method call identik dengan lokal method call, kecuali
menggunakan exception handling.
7. Argumen dan nilai kembalian harus memenuhi salah satu persyaratan :
primitif, serializable objek, array atau koleksi primitif, atau serializable objek,
atau remote objek. Jika nilai tidak ada satupun syarat diatas maka akan
dihasilkan runtime exception.
8. Jika sebuah objek adalah argument atau nilai kembalian, objek mengirim
serialized copy, kemudian di deserialized pada remote objek lokal heap.
9. Jika remote objek sebagai argumen atau nilai nilai kembalian , objek stub
mengirim instead.
Apa yang harus dimiliki Remote objek dan stub pada umumnya
Bagaimana client tahu method mana yang akan dipanggil?
Bagaimana stub tahu method mana yang mempunya remote objek?

Jawabannya adalah dengan menggunakan Remote interface. Keduanya, Remote

objek dan stub diimplementasikan pada interface yang sama. Salah satu dengan
menggunakan method yang akan dipanggil client. Remote interface harus extend
java.rmi.Remote dan setiap method harus dideklarasikan remoteException.
Contohnya sebagai berikut :

Client memanggil business method pada stub melalui Remote business interface
Client tidak bisa langsung memanggil method pada remote objek harus melalui
Remote interface.

Remote objek bukan bean melainkan hanya bodyguard bean

Pada EJB Remote objek adalah bodyguard bean. Pada dasarnya client tidak bisa
langsung memanggil bean untuk keperluan transaksi dll. EJB Objek melakukan
semacam proses keamanan diantaranya authorisasi misal apakah client ini
terverifikasi untuk memanggil method ini. Untuk lebih jelasnya lihat gambar
berikut :

Komponen Interface
Pada EJB, bisnis interface disebut komponen interface. Perbedaan utama antara RMI
interfac dengan remote komponen interface adalah bahwa dengan EJB kita bisa
extend javax.ejb.EJBOBject dan sebaliknya RMI java.rmi.Remote.
Poin penting
1. Interface dengan java.rmi.Remote pada
inherntence tree adalah Remote interface.
2. Interface EJBObjek extend Remote,
sehingga EJBObjek adalah Remote interface.
3. Remote komponen interface harus
extend EJBObjek interface.
4. Menampilkan business method ke client
melalui komponen interface.
5. Interface EJBObjek menambahkan method
tambahan untuk digunakan client.

Penyesuaian kelas bean

Gambaran arsitektur Session beans

Klien berbagi Home object , tapi tidak dengan komponen. Setiap klien mendapat
refrensi EJBObject sendiri dan komponen sendiri. Klien tidak berbagi komponen
dengan klien yang lain. Hanya ada satu HomeObject untuk jenis komponen
tertentu (misalnya, MviceBean), sehingga kedua klien memiliki home yang sama.
Kedua klien meminta saran pada home yang sama untuk referensi ke sebuah
komponen, akan tetapi klien tidak mendapat referensi ke instance Komponen,
melainkan mendapat referensi ke EJBObject.

Gambaran arsitektur: Entity Beans

Klien berbagi Home, dan dapat berbagi Komponens.
Setiap klien memiliki referensi sendiri pada satu-satunya Home untuk Komponen
ini (katakanlah, CustomerBean). Tapi, jika dua klien mencoba untuk mengakses
Pelanggan yang sama(misal Fred Smith) , maka kedua klien memiliki reference ke
EJBObject yang sama.. Dalam kata lain, EJBObject adalah pengawal untuk
Pelanggan tertentu . Jika semua klien mencoba untuk mengakses Fred Smith ,
masing-masing mereka memiliki rintisan mereka sendiri, tapi semua stub akan
berkomunikasi dengan Remote EJBObject yang sama. Dan hanya akan ada satu
komponen yang mewakili Fred Smith . Jika klien ingin mengakses dua pelanggan
yang berbeda, klien akan memiliki dua stub, dan akan memiliki dua EJBObjects
yang berbeda, satu untuk setiap pelanggan. Dan itu juga berarti dua komponen
yang berbeda.

Architectural overview:
Creating a Stateful Session bean
Setelah mendapatkan Home stub, klien memanggil untuk "menciptakan" pada
Home . Home menciptakan komponen dan Object EJB untuk komponen dan stub
EJBobject.

1. Klient memanggil method create() pada home stub (creatae adalah method
pada interface home)
2. Stub mengrim method create pada home
3. Selanjutnya home kontainer menambah layanannya
4. EjbObject telah dibuat untuk klient
5. Bean tetap di bean pool ! dy keluar hanya untuk melayani sebuah busines
mehod sebenarnya, jika clien yang memanggil satu di EJBObject stub
6. EJBObject stub kembali pada klien, jadi klien dapat memanggil bisnis
method pada komponen interface.

Stateless session beans are more scalable

Klien tidakdapt berbagi EJBObjects, namun bean yang sama dapat melayani
beberapa EJBObjects. Hanya saja tidak pada waktu yang sama. Sebuah bean
tunggal dapat menangani beberapa klien, selama hanya satu klien pada suatu
waktu berada di tengah-tengah metode bisnis.

Gambaran arsitektur: Message driven beans

Message driven beans tidak memiliki tampilan klien. Itu berarti mereka tidak
memiliki antarmuka (Remote atau lokal) yang mengekspos metode untuk klien.
Dengan kata lain, Message driven beans tidak memiliki Home atau EJBObject.
Mereka tidak memiliki antarmuka Awal atau antarmuka Komponen.