EJB

EJB belirtimine göre üç temel bileşen çeşidi bulunmaktadır. Bunlar:

1- Entity Bean
2- Session Bean
3- Message-Driven Bean

Yukarıdaki ilk iki bileşen ilk kez EJB1.0 ve EJB 1.1 belirtimlerinde tanımlanmıştır. Bu yazıda verilecek bilgiler EJB1.1 belirtiminde tanımlanmış özellikleri kapsamaktadır. Message-Driven Bean ise EJB 2.0 belirtimiyle birlikte ortaya çıkmıştır. Message-Driven Bean ve EJB 2.0 ile gelen özelliklerden sonraki yazılarda bahsedilecektir.

Burada tanımlanan bileşen çeşitlerini detaylandırmadan önce bileşenlerin genel olarak sahip oldukları özellikleri belirtmekte fayda vardır.

EJB’nin İskeleti

EJB’nin öncelikle bilinmesi gereken özelliği dağıtık nesne teknolojilerini kullanmasıdır ve şu anda J2EE platformunun standart olarak kullandığı dağıtık nesne protokolü IIOP’dur. Ancak herhangi bir J2EE platformu (uygulama sunucusu da denilebilir) satıcısı kendi tescilli protokolünü bunun yanında kullanabilir. Bilindiği gibi dağıtık nesneler istemci tarafındaki bir vekil (stub) vasıtasıyla sunucu tarafındaki bir nesneye ulaşır. Bu mekanizma ile alakalı ayrıntılı bilgiyi bir önceki yazıda (EJB Nedir? -2) bulabilirsiniz. Tipik bir EJB bileşeni en azından şu üç sınıfı içerir:

1- Home Interface
2- Remote Interface
3- Bean Class

1) Home Interface

Bu “interface” bir EJB’nin yaşamsal döngüsünü belirleyen bir arayüzdür. Burada iki çeşit metod tanımlanabilir:

-create (yaratma) metodları
-finder (arama) metodları

Şunu baştan söylemek gerekir ki bir istemci bir bean'e her zaman uzaktan (remote) erişir. Bu kritere dayanarak home interface'i en basit ifadeyle şöyle tanımlayabiliriz. Sunucu tarafında varolan bir bean sınıfına erişimi sağlayan remote interface'i yaratmaya ya da bulmaya yarar. Aslında karmaşık gibi görünen bu ifade home interface’in görevlerinin büyük bir bölümünü oluşturur. Bu metodların özellikleri bileşenden bileşene (entity, stateful session, stateless session) değişir. Örneğin finder metodlar session bean’lerde bulunmazlar fakat entity bean'lerde en az bir tane (findByPrimaryKey) bulunmak zorundadır.

2) Remote Interface

Bu arayüz bean sınıfında tanımlanan tüm iş mantığı metodlarının aynısını içinde barındırır. Bu sayede istemci bean sınıfına direk olarak ulaşmadan bu arayüz vasıtasıyla bean sınıfının metodlarını çağırabilir. Buradan da anlaşılabildiği gibi bu arayüz bir kontrol mekanizması (controller) sağlar. Böylece “container” tarafından oluşturulan bu arayüzün implementasyon sınıfında çeşitli servisler sağlanabilir. Bu servisler böylece bean geliştiriciden bağımsız olarak gerçekleştirilmiş olur.

3) Bean Class

İş mantığının asıl gömüldüğü sınıftır. Bu sınıf sunucu tarafında bulunur ve sadece remote interface aracılığıyla erişilebilir.

Yukarıda bir EJB bileşenini oluşturan en temel üç parçayı gösterdik. Bunun yanında sadece entity bean’lerde kullanılan primary key sınıfı bulunur. Şimdi EJB bileşen çeşitlerini incelemeye başlayalım.

Entity Bean

Entity Bean EJB 1.0 belirtiminde opsiyonel olarak tanıtılmıştır ancak verinin objeleştirilmesinde gösterdiği başarı sayesinde EJB dünyasında yaygın bir şekilde kullanılmaya başlanmıştır. Bu yüzden EJB 1.1’de EJB Container’ların bu bileşen çeşidini desteklemeleri zorunlu hale getirilmiştir.

Entity bean herhangi bir veri kaynağındaki veriyi temsil eder. Örneğin ilişkisel bir veritabanında bulunan bir tablonun bir satırı bir entity bean instance’ına denk gelir. Bu bize ne avantaj sağlar? Sağladığı en büyük avantaj verinin objeleştirilmesidir. Bu sayede gerçekleştireceğimiz uygulamalarda veri kaynağı yerine nesnelerle uğraşırız. Ayrıca yazdığımız uygulamalar veri kaynağından bağımsız olur. Çünkü verinin veri kaynağından alınma işlemi bean sınıfından bağımsızdır ve container tarafından gerçekleştirilir. Biz bean uygulama geliştiricisiolarak uygulamalarımızı veri kaynağıyla alakalı sorunlardan bağımsız bir şekilde gerçekleştiririz.

Tanımlanmış olan iki tip entity bean vardır: CMP (Container-Managed Persistence) Entity Bean ve BMP (Bean-Managed Persistence) Entity Bean.

CMP Entity Bean

Bu bileşen çeşidinde veri kaynağı ile senkronizasyon işlemi tamamen container’a bırakılmıştır. Yani siz entity bean’i yazarsınız. Fakat bu bean’in veri kaynağından veriyi alma ve veri kaynağına veriyi yazma işlemleri container tarafından gerçekleştirir. Tabii ki bu geliştirici için idealdir fakat container üreticisi çok gelişmiş bir mapping özelliğini gerçekleştirmek zorundadır. Burada container üreticilerinin arasındaki performans farkları ortaya çıkar. Aslında J2EE sertifikalı tüm uygulama sunucuları bu işlemi gerçekleştirir fakat performans farkı kimin bu işi daha iyi yaptığını belirler.

BMP Entity Bean

Buradaki mapping işlemi tamamen geliştirici üzerine yüklenmiştir. Bazı durumlarda uygulamanın performansının artması için bu kaçınılmazdır. Bazen container’ın başedemeyeceği kadar büyük mapping sorunları da çıkabilir. Ayrıca sizin etkileşimde bulunmak istediğiniz veri kaynağını container satıcısı desteklemeyebilir. Bu sorunlar karşısında geliştirici kılıcını kuşanır ve senkronizasyon işlemini üstlenir. BMP’nin dezavantajlarından biri ise bileşene veri senkronizasyon kodu gömüldüğünden veri kaynağına bağımlı hale gelmesidir. Fakat bu da değişik mekanizmalarla önlenebilir. Bunlardan biri DAO (Data Access Object) pattern kullanımıdır.

Session Bean

Uygulamadaki iş akışını kontrol eden bileşenlerdir. Entity bean’in veriyi objeleştirdiğini yukarıda belirtmiştik. İşte bir uygulamanın ortaya çıkması için bu verinin bir şekilde işlenmesi gerekir. Çünkü bir uygulamanın çalışması demek sistemde bulunan verilerin anlamlı şekilde değişmesi demektir. Bu görevi session bean gerçekleştirir. Session bean, entity bean’leri kullanarak ve işleyerek, örneğin, bir ticari işletmenin iş akış süreçlerini gerçekleştirebilir. Bir diğer değişle ünlü iş mantığı (business logic) çoğunlukla session bean’ler tarafından gerçekleştirilir. Session bean de kendi içinde iki parçaya ayrılır.

- Stateful Session Bean (SFSB)
- Stateless Session Bean (SLSB)

Stateful Session Bean

Bu session bean çeşidi sunucu tarafındaki bir bean’nin istemci tarafındaki uzantısı olarak düşünülebilir. Sadece bir istemcinin isteklerini gerçekleştirir. SFSB’nin özelliği bean instance'ın yaşam süresi boyunca bir durum bilgisi (state) tutmasıdır. Kısaca bean üzerinde çağrılan farklı metodlar birbirlerinden haberdar olabilirler. Bu state bean sınıfının değişkenlerinde tutulur. Bunu basit bir örnekle açıklayalım. Örneğin bir istemci bir e-ticaret sitesine girsin. Bu ziyaretçinin bu siteden istediği malları alış-veriş sepetine attığını düşünelim. Bu istemci siteden malları seçtikçe bu alışveriş sepeti dolmaya başlayacaktır. İşte bunun anlamı bu istemci için sunucuda tutulan bir SFSB’nin bu malları bellekte tutması demektir. Eğer istemci bu malları almaktan vazgeçerse ya da satın alma işlemini başlatmazsa bu alış-veriş sepetindeki mallar istemci sunucuyla ilişkiyi kestiğinde kaybolur. (Aslında çoğu e-ticaret sitesi bu malları bir veritabanına yazar ve aynı istemcinin bir sonraki ziyaretinde karşısına çıkartabilir. Fakat biz burada bunların kaydedilmediğini varsayıyoruz). Bunun anlamı sunucudaki SFSB’nin yok edilmesidir.

SFSB bir diğer ifadeyle iş akışlarındaki senaryoların gerçekleştirilmesi anlamına da gelir. Bu senaryoları yazılımcı SFSB olarak tasarlar ve entity bean’leri bu senaryolara göre işleyerek işletmenin ihtiyaçlarını karşılar.

Stateless Session Bean

Stateless session bean küçük iş parçacıklarıdır. SFSB’den farkı hiçbir istemciye bağımlı olmayışıdır. İstemcilerle alakalı bilgi tutmaz. Fonksiyonel dillerde kullanılan RPC (Remote Procedure Call) ile eşdeğerdedir. Çünkü istemci metod çağrımını yapar ve sonucunu alır. Sistemde bu işlemle alakalı hiçbir durum bilgisi tutulmaz.

Performans bakımından en verimli olan bean'dir. Tüm ihtiyaç duyduğu bilgiyi parametre olarak alır ya da bir veri kaynağından elde eder. SLSB’lere en güzel örneklerden biri onaylama işlemleridir. Mesela bir transaction içerisinde bir öğrencinin bir dersten yeterli notu alıp almadığını kontrol etmek istersek bunu bu tip işlerin toplandığı bir stateless session bean içerisindeki bir metod vasıtasıyla gerçekleştirebiliriz. Bu metod çağrımı sonucunda bize sadece doğru ya da yanlış diye bir yanıt döndürülür.

Şimdi burada önemli bir noktaya değinelim. Yukarıdaki örnekte neden entity bean kullanmadık? Aslında ilk bakışta entity bean kullanmak mantıklı gelebilir. Ancak performans açısından bakıldığında SLSB kullanımı ön plana çıkar. Çünkü entity bean'in yaratılması sisteme SLSB’nin yaratılmasından daha fazla yük getirir. İkincisi ise entity bean yaratılırken sadece gerekli olan değişkenin değil tüm değişkenlerin veritabanıyla senkronizasyonu sağlanması gerekir. Fakat SLSB kullanıldığında yapılan tek şey yaratılan stateless bean'e öğrencinin numarasının verilmesi ve bu numara kullanılarak veritabanından istenen bilginin elde edildikten sonra karşılaştırma işleminin sonucunun döndürülmesidir. Bu gibi performans arttırımı sağlayan yaklaşımlarda her zaman SLSB kullanılmalıdır.

Kaynak
http://www.teknoturk.org/docking/yazilar/tt000093-yazi.htm