Nazar değmesin kendisi tam bir cadıdır fotoğraflarına bakıp aldanmayın.
Bugün kendisi bana bi soru sordu "Abi aşk güzel birşey mi?"...
Zaman
2 yıl önce
24 Kasım 2007 Cumartesi
Kardeşim ve Ben
Nazar değmesin kendisi tam bir cadıdır fotoğraflarına bakıp aldanmayın.
Bugün kendisi bana bi soru sordu "Abi aşk güzel birşey mi?"...
Iron Maiden - Paschendale
Iron Maiden - Paschendale Sözleri[TR]
yabancı topraklarda, bilinmeyen bir mezarda
yalnız bir asker yatıyor.
ölürken son sözlerinde dua ediyor.
paschendale'i anlatıyor...
ruhundan geriye kalanlar
yaşadıklarını tekrar yaşıyor.
son gözyaşlarıyla mermilerini paslandır..
bırak sana onun son anılarını anlatayım.
''kan havuzuna dönmüş siperde eğilmiş bekliyorum.
kendi ölümüme kadar burası benim öldürme yerim.
yüzüme düşen yağmuru hissediyorum.
arkadaşlarımı bir daha asla göremeyeceğimi biliyorum.
sis ve çamurun içinde ilerliyorum.
korkunun kokusunu alıyorum
ve hissediyorum dehşeti.
birazdan siperden atlama zamanı gelecek hücum için.
yaylım ateşi..ve hepimizin sonu gelecek.
ıslıklar, çığlıklar ve daha fazla silah ateş ediyor.
cansız bedenler dikenli tellerde ızgara oluyor.
savaş alanı kanlı bir mezardan başka bir şey değil.
yakında ölü arkadaşlarımla tekrar buluşacağım.
çoğu asker on sekizinde bile değildi.
çamura daha fazla gözyaşı düşüyor.
kimsenin kazanamayacağı bir savaş bu.
öldürme zamanı başlamak üzere..
ev, çok uzakta savaştan..tekrar bir yaşama şansı.
ev, çok uzakta...ama savaş..yaşamak için bir şans yok.
bizim ve düşmanlarımızın cesetleri
taşan bir ölüm denizi gibi.
tanrı bilir, kimsenin olmayan ve olmayacak bu topraklarda...
ölümün dişlerine doğru hücum ediyoruz.
sanki çarmaha gerilmiş gibi ölüler.
müttefik askerler kendi kayıplarına yanıyor.
alman savaşı daha önce hiç görülmemiş bir propaganda makinesi.
yemin ederim ki melekleri ağlarken duydum.
artık daha fazlası ölmesin diye tanrıya yalvarıyorlardı.
insanlar gerçeği bilsin diye..
paschendale'ın öyküsünü anlatsınlar diye.
zulüm bir ''insan kalbine'' sahip
ve her insan kendi rolünü oynuyor.
öldürdüğümüz adamların dehşetine rağmen
''insan kalbi'' hala aç..
son ana kadar yerimde kalıyorum.
beklerken silahım hazır.
top mermesinin ıslığı bitip patlayana kadar sinir bozucu bir bekleyiş başlıyor.
sonra kan fışkırıyor her tarafa ve işte gidiyoruz.
kan yağmur gibi yağıyor.
gökyüznün kızıl pelerini bir kez daha ortaya çıkıyor.
silahların sesi günahlarını saklayamaz.
ve işte paschendale'da ölüyoruz.
şarapnellerden ve dikenli tellerden kaçarak
dümdüz top ateşine hücum ediyorum.
nefesimi tutup körlemesine koşuyorum.
bu ölüm senfonisine bir dua okuyorum.
ateş başlıyor biz düşman hatlarına saldırırken
hepimiz düşüyoruz..
bir çığlık atıyorum ama kimse duymuyor.
boğazıma kadar kana batıyorum.
ev, çok uzakta savaştan..tekrar bir yaşama şansı.
ev, çok uzakta...ama savaş..yaşamak için bir şans yok.
rüzgarda ruhumu seyret uçarken..siperlerde ve tepenin ardında.
biz paschendale'de ölenler, düşman ve ya dost, gene buluşacağız.''
Iron Maiden - Paschendale Lyrics[ENG]
in a foreign field he lay
lonely soldier unkown grave
on his dying words he prays
tell the world of paschendale
relive all that he's been through
last communioun of his soul
rust your bullets with his tears
let me tell you 'bout his years
laying low in a blood filled trench
kill tim 'til my very own death
on my face i can feel the falling rain
never see my friends again
in the smoke in the mud and lead
smell the fear and the feeling of dread
soon be time to go over the wall
rapid fire and the end of us all
whistles, shouts and more gun fire
lifeless bodies hang on barbed wire
battlefield nothing but a bloody tomb
be reunited with my dead friends soon
many soldiers eighteen years
drown in mud no more tears
surely a war no-one can win
killing time about to begin
home, far away
from the war, a chance to live again
home, far away
but the war, no chance to live again
the bodies of ours and our foes
the sea of death it overflows
in no man's kand god only knows
into jaws of death we go
crucified as if on a cross
allied troops they mourn their loss
german war propaganda machine
such before has never been seen
swear i heard the angels cry
pray to god no more may die
so that people know the truth
tell the tale of paschendale
cruelty has a human heart
everyman does play his part
terror of the men we kill
the human heart is hungry still
i stand my ground for the very last time
gun is ready as i stand in line
nervous wait for the whistle to blow
rush of blood and over we go
blood is falling like the rain
it's crimson cloak unveils again
the sound of guns can't hid their shame
and so we die on paschendale
dodging shrapnel and barbed wire
running straight at the cannon fire
running blind as i hold my breath
say a prayer symphony of death
as we charge the enemy lines
a burst of fire and we go down
i choke a cry but no-one hears
fell the blood go down my throat
home, far away
from the war, a chance to live again
home, far away
but the war, no chance to live again
see my spirit on the wind
across the lines beyond the hill
friend and foe will meet again
those who died at paschendale
22 Kasım 2007 Perşembe
11'09''01" September 11
11'09''01" September 11 - Sean Penn
11 Eylül hakkında 11 farklı ülkeden 11 yönetmenin 11 dakika 9 saniye ve 1 kare uzunluğundaki kısa filmlerinden oluşan harika bir sanateseri.Ben dün 10. filme yetişebildim 11. filmin yarısındada uyuya kaldım.10. film Amerikayı temsil eden Sean Penn'in filmi izlediğimde ağzım açık kaldı sonradan araştırdığıma göre 11 filmden en iyi 3 film arasında bulunuyormuş zaten.Çok fazla anlatmak istemiyorum ama filmdeki simgesel mesajlar, harika çekim açılarını ve uyumlu müziği gölgede bırakacak derecede insanı hayrete düşürüyor, Sean Penn resmen dehanın tanımını yapmış dedirtiyor insana.Bir konu daha var ki Emre Altuğun Ask-ı Kıyamet adlı şarkısının klibi bu filmden çalıntıdır hatta Emre Altuğun klibinde oynayan Erol Günaydın ile Sean Pennin filminde oynayan Ernest Borgnine birbirlerine ikiz kadar benziyorlar
21 Kasım 2007 Çarşamba
Nói albínói
Çok güzel bi film dün cnbc-e de yayınlanmış benim haberim yoktu bu filmi 2 ay önce izlemiştim çok etkilendiğim bir film yalnızlığı iliklerinize kadar hissettiriyor...
19 Kasım 2007 Pazartesi
18 Kasım 2007 Pazar
Neden Mi Sen?
İnsanların verdiği hayat sevgidir. Niçin yalnız sana yazdığımı sorma, niçin yalnız sana geldiğimi...
Sana gelişim işte bundan. Sen aşkı anlatıyorsun, yaşatıyorsun bana. Çünkü yaşıyorsun.O sözlerin kalbinden geldiğini kalbime vuruşundan anlıyorum ben. Sözlerin değil beni sana bağlayan, O sözlerini manasına vurgunum.
Niçin mi sen?
Sen benden önce vardın, varoluşun bu yüzden. Ve sen benden sonrada varsın, sana tutunmam aşka ve varlığa duyduğum özlemden!
Sen benim sözlerimsin. Seni kalbime koyuşum bundan. Ve sen dostsun. Ruhuma sığınak ararken haykırmam hep bu yüzden...
Ve sen dostsun, arkadaşsın. Sen içimi koruyan bir elbisesin. Ben ruhunun çıplaklığını örtüğün tenim. Sen de bunları yaşıyorsun ama saklıyorsun kendinden. Kalbinin sesini dinle bir an. Duyacak o zaman sevginin ve aşkın sesini. Bir liman aradığını ve bu limana sığınmak istediğini...
Sana gelişim işte bundan. Sen aşkı anlatıyorsun, yaşatıyorsun bana. Çünkü yaşıyorsun.O sözlerin kalbinden geldiğini kalbime vuruşundan anlıyorum ben. Sözlerin değil beni sana bağlayan, O sözlerini manasına vurgunum.
Niçin mi sen?
Sen benden önce vardın, varoluşun bu yüzden. Ve sen benden sonrada varsın, sana tutunmam aşka ve varlığa duyduğum özlemden!
Sen benim sözlerimsin. Seni kalbime koyuşum bundan. Ve sen dostsun. Ruhuma sığınak ararken haykırmam hep bu yüzden...
Ve sen dostsun, arkadaşsın. Sen içimi koruyan bir elbisesin. Ben ruhunun çıplaklığını örtüğün tenim. Sen de bunları yaşıyorsun ama saklıyorsun kendinden. Kalbinin sesini dinle bir an. Duyacak o zaman sevginin ve aşkın sesini. Bir liman aradığını ve bu limana sığınmak istediğini...
17 Kasım 2007 Cumartesi
James Blunt - No Bravery
there are children standing here,
arms outstretched into the sky,
tears drying on their face.
he has been here.
brothers lie in shallow graves.
fathers lost without a trace.
a nation blind to their disgrace,
since he's been here.
and i see no bravery,
no bravery in your eyes anymore.
only sadness.
houses burnt beyond repair.
the smell of death is in the air.
a woman weeping in despair says,
he has been here.
tracer lighting up the sky.
it's another families' turn to die.
a child afraid to even cry out says,
he has been here.
and i see no bravery,
no bravery in your eyes anymore.
only sadness.
there are children standing here,
arms outstretched into the sky,
but no one asks the question why,
he has been here.
old men kneel and accept their fate.
wives and daughters cut and raped.
a generation drenched in hate.
yes, he has been here.
and i see no bravery,
no bravery in your eyes anymore.
only sadness.
13 Kasım 2007 Salı
Haftanın Filmleri
Perşembe akşamı saat 23:15 te Tv8'de. Hayatımda izlediğim en iyi aşk filmi ama Tv8 dublaj konusunda berbattır yabancı filmler pek izlenmio orda.
Bu akşam saat 22:00'da cnbc-e de. Harika bi aşk filmi, filmde sık sık gösterilen San Francisconun harika manzarası ve mimari yapısı bile insanın içini hoş edio ...
12 Kasım 2007 Pazartesi
11 Kasım 2007 Pazar
EJB Nedir?
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 ve Uygulama 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öster linkine tıkladığında otel de boş olan odaları görebilmektedir. Müşteri karşısına çıkan sayfada bir oda beğenip odanı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
Bu yazıdaki amaç Enterprise Java Beans hakkında yüzeysel bir açıklama yapmak ve bu alana kaymak isteyen yazılımcılara bir fikir vermekti. Daha sonraki makalelerde biraz daha detaya inip EJB’nin teknik özelliklerini ve sağladığı avantajları anlatmayı düşünüyorum.
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 ve Uygulama 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öster linkine tıkladığında otel de boş olan odaları görebilmektedir. Müşteri karşısına çıkan sayfada bir oda beğenip odanı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
Bu yazıdaki amaç Enterprise Java Beans hakkında yüzeysel bir açıklama yapmak ve bu alana kaymak isteyen yazılımcılara bir fikir vermekti. Daha sonraki makalelerde biraz daha detaya inip EJB’nin teknik özelliklerini ve sağladığı avantajları anlatmayı düşünüyorum.
J2EE
J2EE (Java 2 Enterprise Edition) Nedir?
J2EE, Java'nın çok katmanlı kurumsal uygulama geliştirme standardıdır. J2EE, standart ve modüler bileşenlerden oluşan bir yapının karmaşık işlemler yapmadan, otomatik olarak geliştirilebilmesini sağlar. Çok sayıda makine, sunucu, veritabanı ve uygulamadan oluşan bir ortamın uyumlu çalışması için bir alt yapı oluşturur.
Sadece bir kaç kişilik bir ekibiyle geliştirilen basit uygulamalar, sadece bir veritabanı, bir sunucu ve az sayıda kullanıcıdan oluşan ağlar için yapılan sistemler için J2EE çok anlamlı gelmeyebilir. Ancak çok sayıda veritabanı, çok sayıda makine, çok sayıda sunucu birbirinden farklı yeteneklere ve gereksinmelere sahip çok sayıda kullanıcıdan oluşan büyük sistemler için uygulama geliştirmek oldukça karmaşık bir hal almaktadır. Hatta sistemden beklenen işlevler ve kullanıcı sayısı büyüdükçe basit mimariler bile tek makinenin tek sunucunun ve tek veritabanının kaldıramayacağı hale gelir. Bu durumlarda zorluk asıl işlevlerin gerçekleştirilmesinden daha çok bir üşlevleri gerçekleştirilmesinide kullanılan bileşenlerin entegrasyonunda çıkmaktadır. Bu tip ortamlarda 'dağıtık' uygulama geliştirme kavramı devreye girmektedir. Dağıtık sistemler, bütün sistemin ayrı makinelere, hatta ayrı networklere dağıtıldığı, birbirileriyle iletişim kuran bileşenlerden oluşan sistemlerdir. J2EE, bu tip ortamlarda yapılacak işlemleri kolaylaştırmakta, hatta bazı işlemleri otomatik olarak yapmaktadır.
J2EE Hangi Teknolojileri İçerir?
Java API for XML-Based RPC (JAX-RPC) : Farklı makinelerdeki nesnelerin birbirleriyle XML konuşarak haberleşmesini sağlar
JavaServer Pages & Java Servlets : Web programlama teknolojileri
Enterprise JavaBeans components : Nesnelerin veritabanında saklanması, networkteki herhangi bir makineden erişilmesini sağlar
J2EE Connector Architecture : Başka tekonolojilerler geliştirimiş sistemleri J2EE ilei birlkte çalışmasını sağlar.
J2EE Management Model : Network yönetim sistemleri ve protokolleriyle entegrasyon
J2EE Deployment API : J2EE bileşenlerinin geliştirilmesi ve sisteme yüklenmesi
Java API for XML Registries (JAXR) : Web servislerinin yaratılması, kurulması ve erişilmesi
Java Message Service (JMS) : Uygulamaların ve nesnelerin eşzamansız (asenkron) iletişimi için.
Java Naming and Directory Interface (JNDI) : Nesneleri belli bir isimler veya belli bir dizinde saklamak için
Java Transaction API (JTA) : Transactional veri erişimi için.
CORBA : Java Dışında C++ gibi diğer dillerin de nesneleriyle iletişim kurabilmek için
JDBC data access API : SQL Veritabanlarına erişim için
Java Mail : Mail sunucularına erişip mail alma/verme işleri için
JavaBeans Activation Framework (JAF) : Belli bir veri tipinde çeşitli komutların çalıştırlması için
J2SE : Java 2 Standart Edition : Standart Java'daki her şeyin enterprise da kullanılması için
EJB (Enterprise Java Beans) Nedir? Entity Bean, Session Bean, Message-Driven Bean Nedir?
Enterprise Bean, business logic'i (belli bir işlevin çalışma mantığını) sunucu tafında barındıran özel bir nesne türüdür. İşlev sunucu tarfında tanımladığı için kullanıcı tarafındaki nesneler sadece enterprise bean'leri çağırırlar herhangi bir işlevi yapmak için. J2EE sunucuları, enterprise bean'lerin dağıtık yapısını, güvenliği, ağdaki yeri saklanması gibi konuları hallederler. Programcıya sadece bean'de neyin nasıl yapılacağını belirtmek kalır. J2EE'nin temel bileşeni EJB olarak düşünülebilir. Ancak EJB olmadan da server side enterprise application'ları geliştrilebilir. Enterprise Bean'ler 3 Tiptir Entity Bean, Session Bean, Message-Driven Bean. Entiy Bean, verinin saklanması ve erişilmesi için, Session Bean, belli bir sürede başlayıp biten süreçler için, Message-Driven Bean, doğrudan çağrılarak çalıştırılmayan, belli bir mesaj alındığında yapılan işler için.
CMP (Container-Managed Persistence) & BMP (Bean-Managed Persistence)
J2EE'nin somut olarak işlevlerine örnek olarak CMP (Container Managed Persistent) verliebilir. CMP ile programcılar isterlerse nesnelerini veritabanında otomatik olarak saklanmasını sağlayabilirler. Hiç SQL yazmadan sadece hangi alanların veritabanın saklanacağını (persistent olduğunu) belitmeleri yeterli olur. (Elbette istenirse veritabanında saklama işini kendileri de hallede bilirler ki buna da Bean )
Kaynak : http://www.godoro.com
JAVA Terimler
Applet nedir?
Applet, bir tarayıcı içerisinde çalışan program parçasıdır. Bir web sayfasında bir image veya tablo gibi belli bir dikdörtgen içerisinde çalışır ve programalamayla yapıbilecek bir çok işlemi gerçekleştirebilir. İndirildiği makineye bağlanıp veri alış verişinde bulunabilir, kullanıcıyla etkileşimli olarak çalışabilir.
JavaBean'i nedir?
Belli bir standarda göre yazılmış nesnedir. Örneğin xxx adlı bir veriyi değiştiren method setXxx(), erişim sağlayan method'da getXxx() şeklinde yazıılır. Teknik olarak bir nesnenin bean olması default (parametresiz) bir constructor'u olması ve serializable (dosyaya veya başka bir stream'a yazılıp oklunabilmesi) gerekir.
Servlet ve JSP nedir?
Sunucularda belli bir application server içerisinde çalışan programlardır. Tıpkı client'ta appletlerin çalışması gibi.Tipik olarak servlet'lere HTTP üzerinden erişilir. Servlet'ler çıktı olarak HTML üretir. JSP ise, bir Java kodunun HTML kodu içerisinde gömülmesini sağlayan yapıdır. JSP sayfası statik bir HTML sayfası gibidir sadece belli yerlerde Java kodu bulunur. (ASP ve PHP gibi.)
Kaynak : http://www.godoro.com
Object-Oriented Programming
Object, Class ve Instance ne demek?
Object, içerisinde veri ve fonskiyon barındıran yapıdır. Veri tutan birimler 'property', belli bir işlev gören birimlere de 'method' denir. Bir insanın boyu bir property dir ve yürümek bir method'dur. Bir nesnede ne gibi property ve methodlar olacağını belirleyen yapıya class denir. Bu class'a uygun olarak yaratılan nesneye de instance denir. 'Web Sitesi' bir class'dır, 'godoro.com' bunun bir instance'dır. İnsan bir class'tır, Remzi de bunun bir instance'ı.
Object-Oriented Programming ne demek?
Gerçek hayattaki nesneleri ve kavramları belirtmek için kullanılır. Object-Oriented Programlama'da programcının öncelikle yapması gereken belli bir programı yapmak için gerekli nesneleri belirlemek ve bunlar arasındaki ilişkileri tanımlamaktır. Bir şirketle ilgili program yapılırken, örneğin, Department, Employee, Manager, Customer, Supplier gibi class'lar yapılır. Bunlara gerçek hayattaki karşılıklarına uygun olarak işlevler eklenir.
Inhertiance ne demek?
Bir nesnenin başka bir nesnenin özel olması ve ondaki bütün özellekileri içerimesini sağlayan yapı. Manager, örneğin, Employee'nin özel bir halidir. Çünkü her manager aynı zamanda bir Employee'dir. Sigorta işlemelri örneğin her ikisininde de olduğu için, manager için ayrı bir işlem yapmaya gerek yoktur.
Encapsulation ne demek?
Bir nesnenin bazı özellik ve işlevlerini diğerlerinden saklanabilmesi, erişimin sınırlandırılabilmesidir. Encapsulation'u televizyonun kasası olmasına benzetebiliriz. Bazı düğmeler ortada ('public') dururuken bir çok parça kasanın içerisinde gizildir (private). Zaten bir kullanıcının bunları kullanması gerekmez hatta dokunmaması gerekir. Aynı şekilde bir nesnenin kendinde bulunan bileşenleri kötü niyetli veya bilinçis kullanımlardan gizlemesi gerekir. Encapsulation programcıya nesneleri koruma gücünü verir.
Polymorphism ne demek?
Birbirine benzer nesnelere, aralarındaki farklarl ilgilenmeden aynı şekilde erişebilmektir. Her aygıtın bir on/of düğmesi vardır. "Aç" düğmesine basılınca açılır, "Kapa" düğmesine basılınca kapanır. Ama her aygıtın açılması ve kapanma süreçleri farklıdır. Ancak kullancı bunlarla ilgilenmez. Bu kavramın porgramlama dillerindeki nesnenlere uygulanmış hali polymorphism'dir.
Kaynak : http://www.godoro.com
Sistem Mimarileri
Bundan birkaç sene öncesine kadar, şirket bazındaki yazılımlarda en çok kullanılan teknolojiler istemci-sunucu alanındaydı. Bu eğilim, her geçen gün, dağıtık sistemlerin sundukları avantajlar sebebiyle çok katlı (n-tier ya da multi-tier) mimarilere doğru kayıyor.
2 Katlı Mimari
Klasik istemci-sunucu sistemler 2 katlı (2-tier) mimariler üzerine kurulmuşlardır. Bu tür sistemlerde, uygulama direk olarak veritabanı sunucusuyla ilişkidedir.Genel olarak, üretilen işin büyük bir bölümü istemci tarafından yapılırken, çoğu zaman sunucu sadece veritabanı sunucusu görevi görür. Bu, uygulamanın kabul edilebilir bir hızla çalışması için güçlü bir istemci donanım gereksinimini ve bilgisayar ağı olanaklarının gereğinden fazla kullanımını doğurur. Bunun nedeni, iş mantığının işlenmesinin büyük bir bölümünün istemci tarafından yapılıyor olması ve uygulamanın, her gerekli veri parçası için, veritabanına bağlanıyor olmasıdır. Deneyimli okuyucular, şu anda mutlaka "bilgi işlemenin bir bölümü veritabanı sunucusuna kaydırılabilir" diyorlardır: İş mantığının istemci yerine veritabanına kaydırılması ise veritabanına özel, yeniden kullanılması çok zor olan bir uygulama yaratır (genelde stored procedure ler kullanarak).
2 katlı sistemlerde ortaya sıkça çıkan başka bir problem de uygulamanın bakımı ve yapılan değişikliklerdir. İstemcilerin iş mantığının bir bölümünü içlerinde bulunduruyor olmaları sebebiyle, iş mantığında yapılmak istenen küçük bir değişiklik bile tüm istemci bilgisayarlara yeniden yükleme yapılmasına neden olur. Bu işlemin otomatik hale getirilmesi bile her bilgisayarın güncelleştirilmesi gerçeğini ve bir takım şirket içi kullanıcı problemlerini ortadan kaldırmaz (Genelde kullanıcılar yeni gelen uygulama değişikliklerini hoş karşılamazlar veya işleri gereği buna hazır olmayabilirler, v.b.).
İstemci-sunucu sistemlerinin büyük bir dezavantajı da, uygulamanın kullanımının artması halinde (kullanıcı sayısının artması halinde), sistemin ölçeklenirliğinin (scalability) artamamasıdır. Veritabanı sunucusunun donanım kapasitesi dolduğu anda tek çözüm, onu daha güçlü bir bir sunucuyla değiştirmektir. Bu da pahalı bir operasyondur. Daha sonra da göreceğimiz gibi, dağıtık bir mimaride aynı gereksinme doğduğu takdirde, sisteme yeni bir bilgisayar eklemek yeterli ve daha ucuz bir çare olur.
3 Katlı Mimari
2 katlı mimarilerin sık karşılaşılan problemleri karşısında, yazılım endüstrisi 3 katlı mimari kavramını geliştirdi
3 katlı mimariler uygulama görevleri ve sorumlulukları açısından birbirinden farklı 3 bölüme ayrılır. Genellikle bu ayrım fiziksel, somut bir ayrımdır. İlk bölüm, sunuş katı (presentation tier), genel olarak herhangi bir tip grafik kullanıcı arayüzünden oluşur. İkinci bölüm, iş katı (business tier) ya da uygulama katı (application tier), uygulamanın işlem mantığını içerir. Son bölüm, veri katı (data tier), uygulamanın ihtiyacı olan veriyi sunan kattır.
İlk iki katın birbirinden ayrımı, verinin işlenişini sunuluşundan ayırır. Bu da veri işlem mantığını değiştirmeden uygulamaya değişik kullanıcı arayüzleri eklenebilmesi olanağı sağlar. Buna güncel bir örnek vermek gerekirse, bugünün Internet kullanımı güzel bir örnek olur. Bundan birkaç sene öncesine kadar sadece bilgisayarlarımızdaki Internet tarayıcılarıyla ulaşılabilen milyonlarca sayfa değişik bilgi hızla taşınabilir küçük elektronik araçlarla ulaşılabilir hale geliyor. Ya da, şirketler elemanlarının şirket dışı kullanımı için geliştirilen ve genellikle diz üstü bilgisayarlarında çalışan uygulamaların daha önce bahsettiğim elde taşınabilen elektronik araçlarla da ulaşılabilir hale gelmesini istiyorlar. Bu gibi senaryolarda, verinin işlenişinin sunuluşundan ayrı geliştirilmiş olması, varolan uygulamayı değiştirmeden yeni bir kullanıcı arayüzü eklenmesini kolaylaştırır (çoğu zaman olağan kılar). Bundan sonraki yazılarımdan birinde bu ayırımın avantajlarına somut yazılım örnekleri vereceğim.
Aynı tip avantajlar, veri katının uygulama katından ayırımından da elde edilebilir. Bugünün uygulamaları verilerini değişik teknolojiler arayıcılığıyla değişik tip kaynaklardan bulabilirler. Bu bir ilişkisel veritabanı, nesne veritabanı, LDAP (Lightweight Directory Access Protocol) veritabanı ya da XML (eXtensible Markup Language) dosya grubu olabilir. Uygulama geliştirilirken, bu iki kat arasında önceden belirlenmiş, sabit arayüzler kullanılırsa, yeni bir teknoloji kullanmak zahmetsiz hale gelebilir.
Çok Katlı Mimari
Uygulamalarda görev ve sorumluluk ayırımını bir adım daha ileriye götürürsek, çok katlı (n-tier ya da multi-tier) mimari adını verdiğimiz ve bugünün uygulama sunucularının yaygın hale gelmesini sağlayan kavrama varırız. Bu yazı dizisinde inceleyeceğimiz J2EE teknolojisi bu tip mimariler üzerine kurulmuştur. Çok yeni olmayan bu kavram ancak yeni yeni kabul görüyor. Bu hızlı değişimin nedeni, şirket ihtiyaçlarının hem hacim hem de karışıklık olarak artmasıdır. Artık şirketler değişik platformlar ve değişik yazılım dilleri kullanan ve karışık hetorojen ortamlarda çalışan uygulamalardan fazla zaman harcamadan yararlanmak istiyorlar.
Bu tür mimarilerin esnekliklerinin önemli bir avantajı da, farklı teknolojiler ve farklı ortamlardan yararlanan yazılımlar kullanan şirketlerde hissedilir. Bu şirketler, çoğu zaman uygulama sunucularının yardımıyla, varolan uygulamalarını yeni geliştirilenlerle beraber kullanma olanağı bulurlar. Bu da milyarlarca liralık yatırımı ve birçok yıllık deneyimi çöpe atmadan, hızla gelişen haberleşme ve bilgi işlem sektörünün yeni taleplerine "Evet, biz de varız!" diyebilmeyi sağlar.
Çok katlı mimariler birden fazla düzenleşim ortamında varolabilirler. 2 ve 3 katlı mimarilerde katlar genel olarak somut katları gösterirken, çok katlı mimarilerde bu soyut katlar haline gelir ve genelde bu dağılım değişik tip görevlere göre yapılır.
Genel olarak, J2EE uygulama mimarileri 5 ana kattan oluşur:
İstemci Katı (Client Tier): Bu kat, geliştirilen uygulamaya ya da sisteme bağlanan diğer uygulamalar ya da cihazlardan oluşur. Örneğin: Internet tarayıcısı, Java applet, WAP telefon...
Sunuş Katı (Presentation Tier): Bu kat, sistemin istemcileri için gerekli olan her türlü sunuş mantığını içinde bulundurur. Uygulamaya bağlanan istemcilerin taleplerini kaydeder, gerekli iş mantığının uygulanmasını sağlar, talebin işlenmesi sonucu ortaya çıkan veriyi sunulur hale getirip istemciye cevap yollar. J2EE'yi oluşturan teknolojilerden ikisi JSP (JavaServer Pages) ve Java Servlet bu katta bulunur.
Uygulama ya da İş Katı (Applıcation/Business Tier): Uygulamanın hedef aldığı ve gereklerini tatmin etmek için geliştirildiği işe dayalı tüm bilgi işlem bu katta toplanır. Bu görev, J2EE'yi oluşturan bir diğer teknoloji olan EJB (Enterprise JavaBeans)'ler tarafından sağlanır.
Entegrasyon Katı (İntegration Tier): Bu kat, uygulamanın görevini yerine getirmesi için gerekli olan sistem dışı yazılımlara, sistemlere ya da veri tabanlarına bağlantıları sağlamakla yükümlüdür. J2EE uygulamalarının bu bölümleri, genelde, JDBC (Java DataBase Connectivity), J2EE Connector ya da bağlantı kurulan yazılımlara özel arayüzleri kullanırlar.
Kaynak Katı (Resource Tier): Bilgiişlem için gerekli veriler ve dış servisler bu katı oluşturur.
Unutmamak gerekir ki, çok katlı bir uygulamayı oluşturan ve yukarıda saydığım katlar soyut kavramlar. Bu katları, uygulamanın ihtiyaçlarına göre düzenlemek ve daha da detaylı hale getirmek mümkün.
Çok katlı bir mimarıyı baz alarak, bir uygulama sunucusu etrafında geliştirilen yazılımların dağıtık görevlerine, uygulama sunucusunun servisleri de katılır. Bu servisleri, J2EE çerçevesinde kalarak sonraki yazılarda daha detaylı inceleyeceğiz.
Kısaca...
Kısaca özetlemek gerekirse, bu yazımda, yazılım alanında kullanılan uygulama mimarilerinin yaygın çeşitlerine ve giderek nasıl geliştiklerine değindim.
J2EE, son olarak açıkladığım "çok katlı" mimarı ve onunla beraber gelen tasarımlar üzerine kurulmuş yeni, güçlü ve çabuk kabul gören bir teknoloji. Genç ve kompleks bir teknoloji olması, beraberinde bir takım tehlikeleri de getiriyor. Umarım bu yazı dizisinin sonunda, J2EE'yi oluşturan teknolojileri ve kullanım alanlarını yeterince tanımış olup, öğrendiklerinizi ya da hatırladıklarınızı uygulamaya koyma fırsatı bulursunuz.
Yağız ERKAN
2 Katlı Mimari
Klasik istemci-sunucu sistemler 2 katlı (2-tier) mimariler üzerine kurulmuşlardır. Bu tür sistemlerde, uygulama direk olarak veritabanı sunucusuyla ilişkidedir.Genel olarak, üretilen işin büyük bir bölümü istemci tarafından yapılırken, çoğu zaman sunucu sadece veritabanı sunucusu görevi görür. Bu, uygulamanın kabul edilebilir bir hızla çalışması için güçlü bir istemci donanım gereksinimini ve bilgisayar ağı olanaklarının gereğinden fazla kullanımını doğurur. Bunun nedeni, iş mantığının işlenmesinin büyük bir bölümünün istemci tarafından yapılıyor olması ve uygulamanın, her gerekli veri parçası için, veritabanına bağlanıyor olmasıdır. Deneyimli okuyucular, şu anda mutlaka "bilgi işlemenin bir bölümü veritabanı sunucusuna kaydırılabilir" diyorlardır: İş mantığının istemci yerine veritabanına kaydırılması ise veritabanına özel, yeniden kullanılması çok zor olan bir uygulama yaratır (genelde stored procedure ler kullanarak).
2 katlı sistemlerde ortaya sıkça çıkan başka bir problem de uygulamanın bakımı ve yapılan değişikliklerdir. İstemcilerin iş mantığının bir bölümünü içlerinde bulunduruyor olmaları sebebiyle, iş mantığında yapılmak istenen küçük bir değişiklik bile tüm istemci bilgisayarlara yeniden yükleme yapılmasına neden olur. Bu işlemin otomatik hale getirilmesi bile her bilgisayarın güncelleştirilmesi gerçeğini ve bir takım şirket içi kullanıcı problemlerini ortadan kaldırmaz (Genelde kullanıcılar yeni gelen uygulama değişikliklerini hoş karşılamazlar veya işleri gereği buna hazır olmayabilirler, v.b.).
İstemci-sunucu sistemlerinin büyük bir dezavantajı da, uygulamanın kullanımının artması halinde (kullanıcı sayısının artması halinde), sistemin ölçeklenirliğinin (scalability) artamamasıdır. Veritabanı sunucusunun donanım kapasitesi dolduğu anda tek çözüm, onu daha güçlü bir bir sunucuyla değiştirmektir. Bu da pahalı bir operasyondur. Daha sonra da göreceğimiz gibi, dağıtık bir mimaride aynı gereksinme doğduğu takdirde, sisteme yeni bir bilgisayar eklemek yeterli ve daha ucuz bir çare olur.
3 Katlı Mimari
2 katlı mimarilerin sık karşılaşılan problemleri karşısında, yazılım endüstrisi 3 katlı mimari kavramını geliştirdi
3 katlı mimariler uygulama görevleri ve sorumlulukları açısından birbirinden farklı 3 bölüme ayrılır. Genellikle bu ayrım fiziksel, somut bir ayrımdır. İlk bölüm, sunuş katı (presentation tier), genel olarak herhangi bir tip grafik kullanıcı arayüzünden oluşur. İkinci bölüm, iş katı (business tier) ya da uygulama katı (application tier), uygulamanın işlem mantığını içerir. Son bölüm, veri katı (data tier), uygulamanın ihtiyacı olan veriyi sunan kattır.
İlk iki katın birbirinden ayrımı, verinin işlenişini sunuluşundan ayırır. Bu da veri işlem mantığını değiştirmeden uygulamaya değişik kullanıcı arayüzleri eklenebilmesi olanağı sağlar. Buna güncel bir örnek vermek gerekirse, bugünün Internet kullanımı güzel bir örnek olur. Bundan birkaç sene öncesine kadar sadece bilgisayarlarımızdaki Internet tarayıcılarıyla ulaşılabilen milyonlarca sayfa değişik bilgi hızla taşınabilir küçük elektronik araçlarla ulaşılabilir hale geliyor. Ya da, şirketler elemanlarının şirket dışı kullanımı için geliştirilen ve genellikle diz üstü bilgisayarlarında çalışan uygulamaların daha önce bahsettiğim elde taşınabilen elektronik araçlarla da ulaşılabilir hale gelmesini istiyorlar. Bu gibi senaryolarda, verinin işlenişinin sunuluşundan ayrı geliştirilmiş olması, varolan uygulamayı değiştirmeden yeni bir kullanıcı arayüzü eklenmesini kolaylaştırır (çoğu zaman olağan kılar). Bundan sonraki yazılarımdan birinde bu ayırımın avantajlarına somut yazılım örnekleri vereceğim.
Aynı tip avantajlar, veri katının uygulama katından ayırımından da elde edilebilir. Bugünün uygulamaları verilerini değişik teknolojiler arayıcılığıyla değişik tip kaynaklardan bulabilirler. Bu bir ilişkisel veritabanı, nesne veritabanı, LDAP (Lightweight Directory Access Protocol) veritabanı ya da XML (eXtensible Markup Language) dosya grubu olabilir. Uygulama geliştirilirken, bu iki kat arasında önceden belirlenmiş, sabit arayüzler kullanılırsa, yeni bir teknoloji kullanmak zahmetsiz hale gelebilir.
Çok Katlı Mimari
Uygulamalarda görev ve sorumluluk ayırımını bir adım daha ileriye götürürsek, çok katlı (n-tier ya da multi-tier) mimari adını verdiğimiz ve bugünün uygulama sunucularının yaygın hale gelmesini sağlayan kavrama varırız. Bu yazı dizisinde inceleyeceğimiz J2EE teknolojisi bu tip mimariler üzerine kurulmuştur. Çok yeni olmayan bu kavram ancak yeni yeni kabul görüyor. Bu hızlı değişimin nedeni, şirket ihtiyaçlarının hem hacim hem de karışıklık olarak artmasıdır. Artık şirketler değişik platformlar ve değişik yazılım dilleri kullanan ve karışık hetorojen ortamlarda çalışan uygulamalardan fazla zaman harcamadan yararlanmak istiyorlar.
Bu tür mimarilerin esnekliklerinin önemli bir avantajı da, farklı teknolojiler ve farklı ortamlardan yararlanan yazılımlar kullanan şirketlerde hissedilir. Bu şirketler, çoğu zaman uygulama sunucularının yardımıyla, varolan uygulamalarını yeni geliştirilenlerle beraber kullanma olanağı bulurlar. Bu da milyarlarca liralık yatırımı ve birçok yıllık deneyimi çöpe atmadan, hızla gelişen haberleşme ve bilgi işlem sektörünün yeni taleplerine "Evet, biz de varız!" diyebilmeyi sağlar.
Çok katlı mimariler birden fazla düzenleşim ortamında varolabilirler. 2 ve 3 katlı mimarilerde katlar genel olarak somut katları gösterirken, çok katlı mimarilerde bu soyut katlar haline gelir ve genelde bu dağılım değişik tip görevlere göre yapılır.
Genel olarak, J2EE uygulama mimarileri 5 ana kattan oluşur:
İstemci Katı (Client Tier): Bu kat, geliştirilen uygulamaya ya da sisteme bağlanan diğer uygulamalar ya da cihazlardan oluşur. Örneğin: Internet tarayıcısı, Java applet, WAP telefon...
Sunuş Katı (Presentation Tier): Bu kat, sistemin istemcileri için gerekli olan her türlü sunuş mantığını içinde bulundurur. Uygulamaya bağlanan istemcilerin taleplerini kaydeder, gerekli iş mantığının uygulanmasını sağlar, talebin işlenmesi sonucu ortaya çıkan veriyi sunulur hale getirip istemciye cevap yollar. J2EE'yi oluşturan teknolojilerden ikisi JSP (JavaServer Pages) ve Java Servlet bu katta bulunur.
Uygulama ya da İş Katı (Applıcation/Business Tier): Uygulamanın hedef aldığı ve gereklerini tatmin etmek için geliştirildiği işe dayalı tüm bilgi işlem bu katta toplanır. Bu görev, J2EE'yi oluşturan bir diğer teknoloji olan EJB (Enterprise JavaBeans)'ler tarafından sağlanır.
Entegrasyon Katı (İntegration Tier): Bu kat, uygulamanın görevini yerine getirmesi için gerekli olan sistem dışı yazılımlara, sistemlere ya da veri tabanlarına bağlantıları sağlamakla yükümlüdür. J2EE uygulamalarının bu bölümleri, genelde, JDBC (Java DataBase Connectivity), J2EE Connector ya da bağlantı kurulan yazılımlara özel arayüzleri kullanırlar.
Kaynak Katı (Resource Tier): Bilgiişlem için gerekli veriler ve dış servisler bu katı oluşturur.
Unutmamak gerekir ki, çok katlı bir uygulamayı oluşturan ve yukarıda saydığım katlar soyut kavramlar. Bu katları, uygulamanın ihtiyaçlarına göre düzenlemek ve daha da detaylı hale getirmek mümkün.
Çok katlı bir mimarıyı baz alarak, bir uygulama sunucusu etrafında geliştirilen yazılımların dağıtık görevlerine, uygulama sunucusunun servisleri de katılır. Bu servisleri, J2EE çerçevesinde kalarak sonraki yazılarda daha detaylı inceleyeceğiz.
Kısaca...
Kısaca özetlemek gerekirse, bu yazımda, yazılım alanında kullanılan uygulama mimarilerinin yaygın çeşitlerine ve giderek nasıl geliştiklerine değindim.
J2EE, son olarak açıkladığım "çok katlı" mimarı ve onunla beraber gelen tasarımlar üzerine kurulmuş yeni, güçlü ve çabuk kabul gören bir teknoloji. Genç ve kompleks bir teknoloji olması, beraberinde bir takım tehlikeleri de getiriyor. Umarım bu yazı dizisinin sonunda, J2EE'yi oluşturan teknolojileri ve kullanım alanlarını yeterince tanımış olup, öğrendiklerinizi ya da hatırladıklarınızı uygulamaya koyma fırsatı bulursunuz.
Yağız ERKAN
8 Kasım 2007 Perşembe
Three Doors Down - Here Without You
Three Doors Down - Here Without You Lyrics
a hundred days had made me older
since the last time that i saw your pretty face
a thousand lights had made me colder
and i don’t think i can look at this the same
but all the miles had separate
they disappeared now when i’m dreaming of your face
i’m here without you baby but your still on my lonely mind
i think about you baby and i dream about you all the time
i’m here without you baby but your still with me in my dreams
and tonight it’s only you and me
the miles just keep rolling as the people either way to say hello
i hear this life is overrated but i hope it gets better as we go
i’m here without you baby but your still on my lonely mind
i think about you baby and i dream about you all the time
i’m here without you baby but your still with me in my dreams
and tonight girl it’s only you and me
everything i know, and anywhere i go
it gets hard but it won’t take away my love
and when the last one falls, when it’s all said and done
it get hard but it won’t take away my love
i’m here without you baby but your still on my lonely mind
i think about you baby and i dream about you all the time
i’m here without you baby but your still with me in my dreams
and tonight girl it’s only you and me
i’m here without you baby but your still on my lonely mind
i think about you baby and i dream about you all the time
i’m here without you baby but your still with me in my dreams
but tonight girl it’s only you and me
Kaydol:
Yorumlar (Atom)
Kayıtlar
