Tuesday, October 26, 2004

Entity Bean'lerin Ölümü - Bir Analiz

Evet. Son haberlere göre Entity Bean'ler, EJB 3.0 tarifnamesine dahil edilmedi, ve Entity Bean'ler nihayet diğer kullanışsız teknolojiler ile beraber eski teknoloji mezarlığını boyladı. Bu yazımızın konusu, bir ceset analizi (postmortem analysis) olacak. Okurlarımız olan teknik liderler, programcılara, şahsım ve tanıdığım diğer teknik liderlerin niye Entity Bean teknolojisinden verem görmüş gibi kaçtığını, bunun sebeplerini ve o karara varışımızdaki düşünce çizgisini aktarmaya çalışacağım. "Canım kullanıldı işte, çâlışıyor" demekten özellikle kaçınmamız gerekir, çünkü eğer istatistiklere göre bir proje kodunun bakım zamanında harcanan zaman, projenin tümünün %70'i ise, projede kullanılan teknoloji elimizde öldüğü zaman, ileride bu teknolojiyi bilen insanları bulmakta zorlanırız, ve tabii ki proje esnasında da verimlilik düşüşüne sebebiyet vermiş oluruz. Tüm bu dezavantajlardan korunabilmek için, daha baştan doğru teknolojiyi seçmemiz çok mühimdir.

İlk İntibâlar

Geçmişe dönelim. EJB'ler bilgi işlem sektörüne büyük bir şaşa ile giriş yapmıştı. Şahsımızın bir önceki projesi CORBA üzerine olduğundan dağıtık, nesne bazlı bir teknolojide neler olması gerektiğini aşağı yukarı anlamıştık. Bu tür projelerin hepsinde gereklilikler: Bir nesneyi/servisi bulabilmek, uzaktan erişebilmek, nesnelerin rahat bir şekilde veri tabanına erişebilmesi, ve ölçekleme probleminin bir şekilde adreslenmesi idi. Üç katmanli mimaride iş mantığı nesneleri orta katmanda bulunuyordu. Teknik kitaplarda bu sürekli gördüğüm orta katmanın ne işe yaradığını uzun uzun düşündüğümü hatırlıyorum. O zamanki teknik "abilerimizin" cevabı aşağı yukarı şu idi:

"Eski çift katmanlı mimarilerde, görsel katman veri tabanına direk bağlanır. Ancak o zaman, veri tabanları ancak bir anda eşzamanlı açabildikleri bağlantı sayısı kadar (yâni sınırlı) bir sayıdaki kullanıcıya hizmet verebilirler. Fakat bu kullanıcıların erişim "tekrar kalıplarına" (pattern) bakacak olursak, aynı anda yapılan işlem sayısının daha az olduğunu görülmüştür. O zaman, görsel katman bağlantıları veri tabanına değil, nesnelere yaptırırsak, bu nesneler bir veri tabanı havuzundan ihtiyaçları olduğu zaman bağlantıyı alıp, işlerini görür, ve bağlantıyı havuza tekrar geri verebilirler. Orta katmana erişim hafıdaki nesneler üzerinden olacağından, bu katmanı daha fazla donanım ekleyerek rahatça ihtiyaca göre ölçekleyebiliriz. Böylece daha fazla kullanıcıya aynı anda hizmet verebilmiş oluruz. Ayrıca, üç katmanlı bir mimari, kodlama esnasında pür görsel kodu, pür işlem mantığından ayırmamız için bizi zorlayacağı için, daha temiz bir mimariyi ve kod bazını teşvik edecektir. Koşturma anına dönersek, işlem mantığı için önbellekleme gibi çetrefil işleri orta katmanda daha rahat halledebiliriz, çünkü elimizde daha fazla hafıza olacak, bu yüzden üç katmanlı mimarilerin, modern iş sistemleri için daha uygun olacağı düşünülüyor".

EJB teknolojisine bakarken beklentilerimiz bunlardı. EJB kitaplarını okurken, aklımızdaki ilk soru şöyle oldu: "Uzaktaki nesneye nasıl erişiliyor?". Cevap: Bir Session Bean yazılıyor, Java Naming ile isim kullanarak nesneyi buluyoruz, erişiyoruz, ve işimiz bitiyor.

Peki, Session Bean kodlanırken, neler yapılması gerekiyor? Temel ihtiyaçlarımız, herhangi yazdığımız bir metodun dışarıdan erişilebilir hâle getirilmesi.

Cevap: Bir Home Interface yazılıyor. Sonra bir Remote Interface yazılıyor. İstenilen metot iki değişik class'a konması gerekiyor. ???. Bazı tür mecburi kodlar, her EJB'de oluyor, ama illâki yazılmaları gerekiyor.

"Gereksiz kod gerektiren teknoloji" alarmımız bu noktada çalmaya başladı. Sebebini şöyle açıklayabilirim.

Her bilgi işlem problemine, aslında, bir yeni dil tanımı gibi bakabilirsiniz, EJB de sonuçta bir dildir. Bu dilleri de ölcüp biçerken de kıstasımız şudur: Aynı işi yapan daha kısa dil, her zaman tercih edilmelidir. Kısa dil, kısa kod demektir ve bakılması gereken daha az kod miktarı demektir. %70 sihirli oranını unutmayalım.

Ama tam bu noktada, Session Bean'ler için bu sefer pragmatik mühendis tarafımız duruma dahil oldu, ve şunları sordu: "Piyasada alternatif var mıdır?". Cevap: Yok. O zaman Session Bean'lerin külfeti çekilebilir demektir.

Daha İlerlerken

Kitaplarda ilerlerken açıkçası veriye erişim hakkında bir cevap bulacağımızı beklemiyorduk, çünkü böyle bir soru sormamıştık. Fakat bu konunun üzerine çok büyük bir odakla eğilmiş olunduğunu birdenbire farkettik. EJB'ler sanki tüm bilgi işlem sorunlarını bir kalemde çözmeye tâlip olmuştu. Veriye erişim çözümleri de Entity Bean'ler idi.

Hayretle gördük ki, veriye erişim de Session Bean türü bir nesnenin üzerinden, daha kötüsü aynı şekilde "tekrar gerektiren başka bir dil" ile yapılmaya çalışılmış. Veriye erişim problemi bir tablo kolonu ile nesne özelliğini eşlenmesinden ibarettir, ve dağıtık nesneler problemi ile bir alâkası olmamalıdır. Bir tabloya erişmek için niye Japonya'dan çağrılabilen bir nesne yazmam gerekiyor!? Entity Bean tasarımcılarının büyük bir kafa karışılıklığı yaşadığını hissetmeye başladım. Fakat onları da suçlamamak gerekirdi; Onlardan önce CORBA POS sektörde aynı hatayı yapmıştı, bu tasarımcılar herhalde POS başarısızlığını CORBA'nın IDL dilinin esnek olmamasına bağlamış olmalıydılar. Java ile ikinci bir şans ellerine geçmiş oluyordu.

Fakat bu şansta ellerinden kaçacaktı. EJB 3.0, Remote Interface ve Home Interface garabetlerini ortadan kaldırmakta kalmadı, Entity Bean'leri tamamen kaldırıp attı.

İşaretleri Tanımak

Kariyerimizde önümüzden geçen bir çok teknoloji ile boğuşurken, sürekli tekrar tekrar yapılması gereken işlemleri otomize etmeye bayılmışızdır. ABD'de de sektörün raconu, az zamanda daha çok iş yapmayı gerektirir, ve bir işi daha kısa ve temiz yapan programcı daha iyi görülmektedir. Bu kıstasa sistem admin'leri bile dahildir; Öyle ki bir sistem admin arkadaşım, biri sürekli çalışan ama bir diğeri oyun oynayan iki admin arasından, oyun oynayanın muhakkak daha iyi olacağını bana söylemişti, çünkü oyun oynayan, işini daha kısa bir şekilde (betik yazarak) yapmanın yolunu bulmuştu.

Biz de CORBA ile boğuşurken, hep aynı şekilde yazılan fazladan kodları (bunun ismi İngilizce boilerplate code'dur) , Perl gibi bir dil ile üreterek kısa bir şekilde işimizi görmenin yolunu bulmuştuk. Ama işte tam bu noktada, kendimize şu soruyu sormaya başlardık:

"Eğer daha kısa olan A dilini kullanarak, B kodunu üretiyorsam, bu teknolojiyi yazanlar niye A dili gibi daha kısa bir dili baştan kullanmamışlar?"

Hakkında bu soruyu sorduğumuz teknolojiler herhalde aynı şekilde başkaları tarafından da irdelenmişler ki, bir süre sonra miadı dolan teknolojiler çöpüne atıldılar.

Biz de bu tecrübelere dayanarak, şu kuralı geliştirdik: "Ne zaman ki X teknolojisini ayakta tutmak için kod üretmek gerekiyor, o zaman X teknolojisi yanlış tasarlanmışır ve miadı kısa süre içinde dolacaktır. Arkanıza bakmadan kaçınız."

Örnek

EJB 2.0 Session Bean'lerine bu kuralı uygulayalım: Şu anda EJB yazmak için şunlar yapılmaktadır: XDoclet denen bir "başka" teknoloji ile Bean şablonu yazılmakta, ve o şablondan Remote Interface ve Home Interface "üretilmektedir". Hattâ ve hattâ, bazıları daha da ileri gidip, Lomboz denen bir başka teknoloji (Eclipse eklentisi) üzerinden "tıklama" sureti ile XDoclet şablonu üretmektedirler! Yâni diller A-->B-->C hâline gelmiştir! Fakat temiz olmayan bir C dili, üretilse bile bakın nelere yol açmaktadır: XDoclet, her arayüz değişikliğinde tüm şablonların hepsini üretmektedir, ve üretilen kodlar da, aynı olsa bile, zaman damgası (timestamp) değiştiği için derleme sistemi tarafından "yeni kod" olarak algılanmaktadır. Yâni derleme sistemi tek bir EJB değişse de, herşeyi yeniden derlemektedir! Lomboz'a dönelim: Görsel olarak tıklama yapmak güzel, fakat arayüz tanımladıktan ve XDoclet üretildikten sonra arayüzde düzeltme yapmanız imkansızdır! Bunun sebebi: Lomboz yeni bir teknolojidir. XDoclet'te yenidir. E bu niye? EJB'den yanan insanların kod üreten teknolojilere yönelmesi için biraz zaman geçmesi gerekmiştir, bu da doğaldır. Fakat bu işin baştan yanlış olduğunun göstergesidir. Session Bean'lerdeki gibi alternatifiniz yoksa, EJB'leri buyrun kullanın. Fakat ya Entity Bean'ler?

Alternatif son 3 senedir mevcuttur. Toplink ve JDO doğru olarak veri erişimini eşleme problemi olarak çözmüşlerdir. JDO'dan bir çıta yukarıda da Hibernate vardır.

Peki Entity Bean'leri Seçenler, Niye Seçti?

Bunun sebebi şöyle gibi gözüküyor: Entity Bean'ler J2EE paketine dahildi, ve bu yüzden "J2EE bilmek", Entity Bean'leri bilmek gibi bir intiba ortaya çıkmıştır. Bir diğer sebep te, Entity Bean'ler J2EE'ye dahil olduğu icin geleceği daha sağlam bir teknoloji gibi görüldüğüdür. Fakat Sun gibi şirketler bile hata yapabilirler, bu yüzden paketten çıkan herşeyi didik didik tartmamız gerekmektedir. Ayrıca, çok tepki gören teknolojileri, Entity Bean örneğinde olduğu gibi, şirketler tedavülden kaldırabilmektedirler. Bunları da gözönüne almamız gerekmektedir.

No comments: