EJB Best Practices and Performance Optimizations

EJB Best Practices Kapan menggunakan stateful vs stateless Kapan menggunakan messaging vs RMI-IIOP Bagaimana menjamin waktu respon dengan perencanaan kapasitas Bagaimana mencapai singletons dengan EJB Membungkus entity beans dengan session beans Kinerja entity beans

Stateful vs Stateless Session Beans

Stateful vs. Stateless Session Beans Stateless session bean – mampu dengan mudah untuk menyatukan dan me-reuse komponen dengan pengeluaran tambahan yang sedikit atau tidak memerlukan pengeluaran tambahan Stateful session bean – automatic session management (state recovery, large session data …… )

Pilih Stateful atau Stateless Session Beans? Gunakan stateful : Untuk perusahaan yang memproses spans multiple invocations, membutuhkan sebuah percakapan Gunakan stateless : Untuk perusahaan yang memproses terakhir sebuah single method call Karena tujuan utama dari sebuah session bean adalah untuk mewakili client di server J2EE, kebanyakan dari session beans merupakan stateful.

Messaging vs. RMI-IIOP

Kelebihan dari Messaging Database performance Quick responses Smooth load balancing Request prioritization Rapidly assembling disparate systems Loosely coupled systems Geographically disperse systems Parallel processing Reliability Many-to-many communications

Messaging Ketika kita tidak yakin jika prosesnya berhasil Ketika kita menginginkan hasil yang mengembalikan nilai Ketika kita menginginkan sebuah operasi menjadi bagian dari transaksi yang besar Ketika kita menginginkan untuk menyebarkan keamanan identitas client ke sever Ketika kita memberi perhatian tentang request performance Ketika kita menginginkan strongly-typed, OO system Ketka kita menginginkan sistem yang lebih ketat

Bagaimana menjamin waktu respons dengan perencanaan kapasitas

Strategi untuk perencanaan kapasitas Membatasi jumlah kerja dari server yang bisa diatasi sekali, dengan cara : Membatasi thread pool dari EJB server Membatasi bean instance pool

How to achieve singletons with EJB

Singleton adalah suatu instansiasi dari sebuah kelas dengan satu global point untuk mengakses Singleton dapat dibuat di Java dengan menggunakan static keyword ketika mendefinisikan sebuah kelas Kita tidak bisa menggunakan variabel yang static di dalam beans. Untuk mengatasinya kita bisa menggunakan JNDI (Java Naming and Directory Interface)

Wrap entity beans with session beans

Wrap entity bean with session bean to reduce network calls Gambar

Performance tuning beans

Tips untuk meningkatkan kinerja Entity Bean Entity beans tidak bisa dipanggil secara langsung dari remote clients Pergunakan container’s caching options sebanyak mungkin Yakin transaksi yang kita jalankan di server adalah sependek mungkin, dan enkapsulasi semua operasi entity bean yang ingin diikutsertakan kedalam transaksi tersebut

Tips (Cont.) Gunakan container managed persistence jika memungkinkan Jika kita tidak ingin mengakses seluruh data entity beans pada setiap transaksi, lazy-load beberapa variabel lebih baik daripada memuat itu semua ketika entity bean di akses pertama kali.

Choosing Between Local Interfaces & Remote Interfaces ~ membolehkan untuk mengakses EJB components tanpa mengadakan hubungan dengan network Remote Interface ~ Untuk akses sistem remotely, ex. dari remote web tier. ~ Untuk menampilkan EJB components secara individual dengan akses dari standalone client. ~ Dapat memberikan lebih banyak pilihan pada container untuk distribusi workload & failover pada lingkungan clustered-server

How to Debug EJB Issues Me-load container menjadi debugger Tidak semua container bisa menjadi debugger. Solusi : menggunakan tried-and-true debugging method of logging Beberapa EJB containers mendukung IDE debugging environment Memeriksa database’s logfile Menggunakan JDBC driver wrapper yang me-log semua pernyataan SQL Menggunakan opsi keep generated Java files dari tools pada EJB Container Men-decompile the offending classes untuk melihat apa permasalahannya

Partitioning Your Resources Bean Specific Resources resources bean yang terikat ke specific data instance dalam penyimpanan khusus (ex. socket connection yang hanya digunakan saat me-load data bank account tertentu). Bean Independent Resources resources yang dapat digunakan berulangkali, apapun data yang direpresentasikan (ex. socket connection yang digunakan me-load data apapun yang direpresentasikan oleh bank account).

Assembling Components Masalah : membuat semua heterogenouse components work together EJB mendefinisikan interface standar bagi component untuk digunakan di container apapun. EJB tidak dapat menjelaskan bagaimana domain spesifik components interact.

Developing Components to be Reusable Ex. Membangun beans untuk di-reuse oleh departemen lain di dalam organisasi Enterprise beans adalah reusable => salah Enterprise beans bisa di-reuse jika didesain dengan benar. Three levels of bean reusability : ~Reuse as given ~Reuse by customization ~Reuse by extension (subclass)

When to Use XML in An EJB System Manfaat dari XML : ~Sebagai interface ke legacy system ~Sebagai dokumen persistence mechanism ~Sebagai web service interface Dont use XML for : on-the-wire format untuk komunikasi antar komponen-komponen EJB Gunakan XML jika diperlukan

Legacy Integration with EJB Dua pilihan dasar dalam Legacy Integration with EJB adalah : ~Me-rewrite sistem yang ada dengan meggunakan EJBs ~Gabung ke dalam sistem yang ada Pertimbangan dalam memilih ~sistem dengan data-oriented gunakan entity beans ~sistem dengan process-oriented gunakan session beans ~sistem dengan message-oriented middleware sebagai interfacenya gunakan message-driven bean.

Bride-System Bagaimana menghubungkan the bridge ke sistem yang ada dengan cara : ~proprietary bridges ~the Java Native Interface ~common objects request Broker Architecture (CORBA) ~Java Message Service (JMS) ~Web Services ~The J2EE Connecture Architecture (JCA)

Summary Bisa dengan baik menggunakan proyek EJB Menggunakan referensi strategi desain ini dalam membuat EJB

EJB Clustering

Konsep Clustering Application server system skala besar System yang memerlukan penggunaan satu atau lebih application server yang beroperasi dalam sebuah cluster Cluster :sekelompok server yang menyediakan layanan-layanan yang sudah digabungkan menjadi satu kepada client-clientnya

Karakteristik system skala besar Reliability mengukur apakah sebuah system bekerja pada level yang konstan meskipun tingkat stress pada system tersebut berubah Availability mengukur persentase waktu ketika system tersedia dan dapat digunakan oleh client Serviceability mengukur seberapa dapat diaturnya sebuah system

Terminology Cluster Node Load balancing Highly availability system Fail-over Request-level fail-over Transparent atau automatic fail-over Single access point simplicity

Terminology(2) Transactions per second (TPS) Requests per second (RPS) Arrivals per second (APS) Throughput Invocations per second (IPS)

Konfigurasi cluster dalam web-based system Arsitektur 3-tier Menjalankan komponen Web server (servlets dan JSP) dan komponen application server (EJB) dalam proses yang sama. Arsitektur 4-tier Memisahkan komponen Web server dan komponen application server ke dalam proses yang terpisah.

Konsep Idempotence Idempotent method method yang dapat dipanggil berulang-ulang dengan argument yang sama dan menghasilkan hasil yang sama tidak mempengaruhi state dari system dapat dipanggil berulang-ulang tanpa perlu takut akan mengubah system menjadi tidak dapat digunakan atau menghasilkan error

Kapan request yang gagal dapat terjadi? Setelah request dibuat, tapi sebelum invokasi method pada server mulai berjalan. Akan selalu terjadi fail-over request ke server lainnya. Setelah invokasi method pada server mulai dieksekusi, tapi sebelum method selesai. Fail-over request hanya terjadi apabila method idempotent. Setelah invokasi method selesai, tetapi sebelum respons berhasil dikirimkan ke remote client. Fail-over request hanya terjadi apabila method idempotent.

Meng-cluster Stateless Session Bean Load Balancing semua invokasi method pada remote home stub dan remote stub dapat di load balance Fail-Over fail-over pada remote home stub dapat terjadi secara otomatis fail-over pada remote stub hanya dapat terjadi apabila method yang dipanggil idempotent

Meng-cluster Stateful Session Bean Replikasi state Dapat terjadi di: Di akhir setiap method Setelah commit tiap transaksi Cara server EJB melakukan fail-over: In-memory replication Storage tetap pada shared hard drive atau database

Meng-cluster Stateful Session Bean(2) Load balancing remote home stub dapat melakukan load balancing dengan mudah Fail-over remote home stub dan remote stub hanya dapat melakukan fail-over secara otomatis apabila method yang dipanggil idempotent

Meng-cluster Entity Bean Load Balancing load balancing tidak dibutuhkan lagi Fail-Over fail-over hampir tidak mungkin terjadi Cache Read-Only Cache Distributed Shared-Object Cache Read-mostly Cache

Meng-cluster Message Driven Bean Tidak ada stub atau skeleton yang dapat melakukan load balancing atau fail-over logic untuk mereka Load Balancing Message-driven bean melakukan load balancing dengan menggunakan banyak EJB server bertype sama untuk satu JMS queue untuk mengkonsumsi message

Meng-cluster Message Driven Bean(2) Fail-Over Fail-over pada message-driven bean terjadi tiap kali ada message yang sedang diproses dikenal sebagai unsuccessful pada JMS server

Other Issues First Contact Client yang ingin menggunakan session atau entity bean mencari home stubnya. Client yang ingin membuat message JMS yang akan dikonsumsi oleh message-driven bean harus mencari object JMS ConnectionFactory dan Destination.

Naming server(server penamaan) dalam cluster Centralized Semua EJB server mendaftarkan komponen EJB mereka yang sama di sebuah server penamaan dan semua client mencari komponen EJB pada sebuah server penamaan Setiap node pada JNDI server memiliki server penamaan mereka sendiri yang berisi object replikasi yang dimiliki oleh server lainnya dalam cluster.

Other Issues(2) Initial Access Logic Cara akses client ke cluster pada server penamaan yang centralized tiap client dapat hard-code nama DNS atau IP address server penamaan ke semua pemanggilan InitialContext Cara akses client ke cluster pada server penamaan yang shared, replicated: DNS round robining Software proxies Hardware proxies

Persistence Best Practices

Kapan Menggunakan Entity Bean bagaimana cara menjaga informasi yang di-enkapusulasi melalui EJB. Sebuah session bean menjaga data secara manual, umumnya melalui JDBC. Penjagaan melalui entity beans, bisa BMP ataupun CMP.

Kapan Menggunakan Entity Bean (2) Control Pada intinya, session beans memiliki kontrol yang lebih banyak dibandingkan dengan entity beans. Parameter Passing Analogy Query pada session bean itu mirip dengan prinsip pass-by-value. Query melalui entity bean dapat dianalogikan seperti pass-by-reference. Procedural Versus Object-Oriented Session bean biasanya digunakan untuk tabular, data bisnis. Entity bean, adalah objek java.

Kapan Menggunakan Entity Bean (3) Caching Session bean tidak merepresentasikan data database sehingga tidak dapat di cache sama sekali. Entity bean dapa di cache pada transaksi yang bertingkat. Enforcement of Schema Independence Entity beans memaksa developer untuk melewati sebuah lapisan entity bean. Developer di isolasi dari schema. Session bean juga dapat mengisolasi dari schema. Penggunaan yang mudah Session bean lebih mudah secara konsep Entity bean lebih merupakan konsep yang baru. (susah)

Kapan Menggunakan Entity Bean (4) Migrasi Persistensi session bean adalah prosedural. Deployment dapat dilakukan dengan kopi kode SQL. Entity bean adalah object oriented. Memerlukan beberapa rewrite pada SQL. Rapid Application Development Sewaktu membangun sistem EJB baru, entity bean menyediakan sebuah aplikasi rapid development yang lebih baik dari session bean.

Memilih antara CMP dan BMP Reduksi code dan Rapid App Development Bila anda memberitahu kontainer EJB beberapa hal tentang bean anda, CMP dapat melakukan semua akses logic data untuk anda. Performa CMP entity bean, bila di tune secara tepat, dapat memiliki performa yang lebih tinggi dari BMP entity bean Bugs Sistem CMP biasanya susah untuk di debug dari BMP sistem.

Memilih antara CMP dan BMP (2) Control BMP memberikan kontrol lengkap untuk JDBC. Untuk CMP, banyak kontainer mensupport pemetaan kompleks. Namun ada beberapa kontainer yg tidak. App Server dan Database Independence Satu hal yang baik tentang container managed persistence adalah anda tidak men-hard-coding sebuah penyimpanan database API khusus ke dalam bean seperti JDBC. Hubungan EJB 2.0 CMP model menawarkan banyak keuntungan fitur relationship untuk provider bean.

Memilih antara CMP dan BMP (3) Kurva pembelajaran dan Cost BMP tidak memerlukan banyak kurva pembelajaran. Sebagai pembanding, beberapa server advance AJB diluncurkan dengan pemetaan O/R kompleks untuk CMP yang memerlukan pelatihan dan waktu yang banyak. Ini juga dapat meningkatkan cost.

Memilih Granularitas yang tepat untuk Entity Bean Granularitas mengacu pada seberapa besar sebuah entity bean. Jika anda menggunakan CMP, spesifikasi EJB mengacu pada class java sebagai dependent value classes. Beberapa peraturan untuk kelas-kelas nilai dependent: Didefinisikan sebagai field CMP, dan bekerja seperti field-field CMP. Dependent value classes bisa jadi merupakan field CMR. Tidak mengandung referensi ke entity bean yang lain. Harus dapat di serialisasi (serializable). Keuntungan paling utama dependent value classes, mudah dikembangkan

Tips dan Trik Persistensi Hati-hati terhadap Object-Relational Impedance Mismatch Hard-Coded Versus Soft-Coded SQL Bagaimana menggunakan prosedur tersimpan Normalisasi dan Denormalisasi Menggunakan EJB Object Model untuk men-drive Data Model Mengikuti Proses Desain Data yang baik Gunakan Surrogate Keys Memahami dampak dari Update Database

Tips dan Trik Persistensi (2) Memahami dampak dari Update Database Versioning Komponen EJB Hidup dengan Legacy Database Design Menangani Set-set hasil yang besar Highly availability system Fail-over Request-level fail-over Transparent atau automatic fail-over Single access point simplicity