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

Local Interface ~ 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 Resourcesresources 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

Centralized 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