EJB Nedir? 1. Bölüm

EJB (Enterprise Java Beans) son zamanlarda sıkça kullanılan bir kısaltma. Temelleri daha 1997 yılında atılmaya başlanmış yeni bir teknoloji. Bu nedenledir ki bir çok bilişimci bu yeni sunucu-taraflı programlama (server-side programming) modeline yeni yeni ısınmakta veya bu model hakkında hiçbir fikir yürütememektedir.

EJB

Java ilk olarak “write once, run everywhere” sloganı ile ortaya çıkmış ve birçok programcıyı sadece bu yüzden peşinden sürüklemiştir. Buna örnek Applet kullanımındaki yaygınlıktır. Daha sonraki hamlesi JDBC (Java Database Connectivity) ile olmuş ve tek tip bir arayüzle tüm veritabanı sunucularına bağlanabileceğini garanti etmiştir. Ve en sonunda J2EE (Java 2 Enterprise Edition)... İşte EJB tam bu noktada ortaya çıkmıştır.


Basit bir tanım yapmak gerekirse:EJB tüm uygulama sunucularında çalışabilen bir bileşen (component) modeldir. Buradaki “tüm” kelimesinin aslında çok önemli bir manası vardır. Bunu ileride açıklayacağım. Bu tanımda iki farklı kavram vardır: “Uygulama Sunucusu” ve “bileşen model”. Ben burada uygulama sunucuları üzerinde durmak istemiyorum. Uygulama sunucuları hakkında geniş bilgiyi Uygulama Sunucuları I veUygulama Sunucuları II makalelerinde bulabilirsiniz.






Bileşen (component) Model


Bileşen model tüm sunucu-taraflı nesnelerin uyması gereken bir standarttır. Tanımı genişletmek gerekirse, uygulama sunucularıyla uygulama geliştiriciler arasındaki yapılması gereken işleri kesin çizgilerle ayıran bir belirtimdir (specification). Aslında buna bir çeşit kontrat da denilebilir. Çünkü hem uygulama sunucusu satıcısı, hem de EJB geliştirici bu belirtime uyacaklarını garanti etmişlerdir. İki taraftan birinin buna uymaması durumunda geliştirilen sistem ya hiç çalışmaz, ya da sorun çıkartır. Bu belirtim en son şekliyle EJB sitesinden indirilebilir. Peki uygulama geliştiriciler ile uygulama sunucularının görevleri nelerdir? EJB belirtimine göre uygulama sunucuları bazı düşük seviyeli servisleri sunucu tarafta çalışan nesnelere sağlamalıdır. Bunların bazılarını örnek olarak vermek gerekirse:


-İsimlendirme (naming)
-Dağıtık nesne teknolojileri (RMI,RMI-IIOP,CORBA vs.)
-Süreklilik (persistence)
-Nesne havuzu (instance pooling)
-Hareket (transaction)
-Eş zamanlı kullanım (concurrency)
-Güvenlik (security)


Yukarıda belirtilen servisler her zaman yazılımcıların başını ağrıtmıştır. Çünkü bu servislerin gerçekleştirimi (implementation) gerçekten zordur. Uygulama sunucularının ortaya çıkışının temel nedeni de burada yatmaktadır:Yazılımcıyı alt seviyedeki servislerle uğraşmaktan kurtarmak ve tamamen iş mantığına (business logic) yoğunlaştırmak. Burada tanımını yaptığımız bileşen model kavramının birçok avantajları vardır. Bunları çeşitli katagorilere ayırırsak:


Sistem geliştirme hayat devresi kısalır. Şirket gerçekleştirim evresini çok çabuk gerçekleştirir. Bunun şirketler için anlamı maliyetin düşürülmesidir. Çünkü maliyet sistemin gerçekleştirim süresi ile doğru orantılıdır. EJB kullanılarak bir uygulama geliştiriminin hızlı olmasının sebebi EJB bileşenlerinin sadece iş akışını kontrol etmesi ve alt-seviye servislerin gerçekleştirilmesini (isimlendirme,süreklilik,dağıtık nesne teknolojileri vs.) uygulama sunucusuna bırakmasıdır.


EJB bileşenleri uygulama sunucusundan bağımsızdır. Şirketlerin en çok başını ağrıtan konulardan bir tanesi de yazılımın sadece bir yazılım şirketi tarafından sağlanması ve SGHD (Sistem Geliştirme Hayat Devresi)’nin en uzun evresi olan bakım (maintenance) evresinde sadece bu şirkete bağımlı olunmasıdır (vendor lock-in). EJB bu durumu bileşen model ile ortadan kaldırır. Çünkü bileşen model yazılımcıya bileşenlerin nasıl oluşturulacağını gösterdiği gibi uygulama sunucularının bu bileşenlere hangi servisleri sağlayacağını da gösterir. Yani bir uygulama sunucusu satıcısı EJB belirtimini gerçekleştirirse aynı belirtime uygun yazılan bir bileşen de bu uygulama sunucusunda çalışır. Uygulama sunucularının uyumluluklarını Sun MicroSystems test eder ve testi geçenlere J2EE-uyumlu (J2EE-certified) sertifikası verir. Sonuç olarak J2EE uyumlu “tüm” uygulama sunucuları EJB bileşenlerini sorunsuz çalıştırır. Eğer bir uygulama sunucusunun performansını beğenmiyorsanız başka bir J2EE uyumlu uygulama sunucusunda EJB bileşenlerinizi rahatlıkla çalıştırabilirsiniz. Uygulama sunucuları arasındaki farklar ise genellikle performanstan ve sağladıkları sistem geliştirme araçlarının kalitesinden kaynaklanmaktadır. Geriye dönecek olursak daha önce kullandığımız “tüm” kelimesinin J2EE-uyumlu olan uygulama sunucularını belirttiğini anlayabiliriz.


Bileşen model çeşitliliği sağlar. Yazılım mühendislerinin aklına şöyle bir soru gelebilir. Eğer bir belirtim varsa ve bu herkese açık (public) ise EJB bileşenlerinin içinde çalıştıkları uygulama sunucularının hepsi de aynı işi görmez mi? Bu soruya sadece belirtime bağlı kalarak cevap verirsek “evet” dememiz gerekir. Ancak uygulama sunucularının aralarındaki fark, daha önce de ifade ettiğimiz gibi, ne yaptığında değil nasıl yaptığındadır (mesela veritabanı eşleme (database mapping) işleminde ne kadar iyi, ya da sunucu-tarafta çalışan nesneleri hangi veri yapısını kullanarak bellekte tutuyor; bu örneklerin açıklamalarını daha sonraki makalelerde bulacaksiniz). Buradaki “nasıl” sayesinde belli alanlarda uzmanlaşmış yazılım şirketleri (veritabanı, dağıtık nesne teknolojileri) uygulama sunucusunun belli kısımlarını optimum düzeyde meydana getirebilirler. Sonuç olarak bileşen model sayesinde bir EJB bileşenini çalıştıran birbirinden farklı özelliklere sahip birçok uygulama sunucusu ortaya çıkmıştır.


EJB’nin tanımını tekrar hatırlayalım. EJB tüm uygulama sunucularında çalışabilen bir bileşen modeldir. Önceki paragraflarda bileşen modelin ne demek olduğuna ve avantajlarına değindik. Fakat EJB bileşen model sadece belirtimden ibaret değildir. Bunun yanında EJB geliştiricileri bileşen geliştiriminde standart EJB paketinden faydalanırlar. Bu paket J2EE’nin standart API paketinin içinde mevcuttur. Bu pakette sadece EJB’ye ait arayüzler (interface) ve istisna işleme sınıfları (exception-handling classes) bulunur. Bu da EJB’nin sadece bir iskeleti meydana getirdiğini ve EJB geliştiricisinin de bu yapıya sadık kalarak iş akışını oluşturduğunu gösterir.


Basit Bir Senaryo


EJB'yi biraz daha somut bir örnekle açıklayabiliriz. Mesela bir otel rezervasyon sistemini inceleyelim. Müşterilerin rezervasyonlarını iki türlü gerçekleştirdiklerini varsayalım: Internet'ten otelin web sitesinden on-line olarak, veya dogrudan otele gidip rezervasyon memuruna başvurarak. Birinci durumda otelin web sitesine giren müşteri önce sitenin rezervasyon bölümüne geçecektir. Burada müşteri boş odaları gösterlinkine tıkladığında otel de boş olan odaları görebilmektedir. Müşteri karşısına çıkan sayfada bir oda beğenipodanın özelliklerini göster dediğinde o odaya ait özellikler ekrana gelmektedir. Bu odayı beğenen müşteri rezervasyon yap dediğinde sistemde o oda dolu olarak işaretlenir, müşterinin kredi kartından hesap düşülür ve müşteriye otele gittiğinde odayı kiraladığına dair bir numara döndürülür. Yukarıda altı çizili olarak gösterilen kısımlar küçük iş parçacıklarıdır.


boş odaları göster: Bir EJB tarafından veritabanındaki oda bilgilerinin aranıp boş olanların kullanıcıya döndürülmesi.
odanın özelliklerini göster: Bir EJB ile istenen odanın bilgilerinin döndürülmesi.
rezervasyon yap: Bir EJB ile seçilen odanın dolu olarak işaretlenmesi, bankaya bağlanıp kredi kartından ücretin düşürülmesi gibi işlemler.


Bu örnek üç-katlı (three-tier) mimariye basit bir örnek teşkil eder. Altı çizili olan işlemler uygulama katında (application tier) EJB’ler tarafından gerçekleştirilir.


Dikkat edilirse burada bir müşterinin rezervasyon memuruna dogrudan başvurarak nasıl rezervasyon yaptığını anlatmadım. Çünkü esas itibariyle yapılan işlem aynıdır. Fark sadece tarayıcı (browser) yerine başka bir arayüz kullanılmasıdır. Başka bir deyişle sadece kullanıcı arayüz katı değişmiştir. İstendiği takdirde bu sisteme kablosuz cihazlar yada Internet erişimi olan değişik cihazlar da rahatlıkla entegre edilebilir.


Aslında bu senaryoda üzerinden önemle durulması gereken bir başka konu vardır: Verilerin nesneleştirilmesi (data objectifying). Senaryoda anlatılan EJB’ler veritabanından bilgi okuyup, veritabanına bilgi yazmaktadırlar. Eğer yazılımcı isterse uygulama sunucusu bu işlemi kendi başına yapar ve uygulama geliştirici hiçbir şekilde SQL kodu yazmaz. Geliştirici sadece nesnelerle uğraşır ve nesnelerdeki değişimler otomatik olarak veritabanında güncellenir. (Bu özelliği "entity bean with container-managed persistence" sayesinde kullanabiliriz. İleriki makalelerde bu kavramları detaylı olarak açıklayacağım.)


Mesut Çelik