ZAINAL BUCHORI(201110370311260)

ARIEF PURNAMA ADJI (201110370311251) KHOIRUL HIDAYAT(201110370311284)

M. ARIF ARIO ISLAM (201110370311261)

UNIVERSITAS MUHAMMADIYAH MALANG

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 meng-invoke/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 home3. Selanjutnya home kontainer menambah layanannya4. EjbObject telah dibuat untuk klient5. Bean tetap di bean pool ! dy keluar hanya untuk melayani sebuah busines

mehod sebenarnya, jika clien yang memanggil satu di EJBObject stub6. 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.