Spring ve Java EE 6

Spring ve Java EE 6 kıyaslamalarındaki belki en büyük hata bunların "ya hep ya hiç" mantığı
ile yapılmalarıdır. Java EE içine pek çok değişik APInin dahil olduğu şemsiye bir
spesifikasyondur. Spring ise bu pek çok API'nin büyük bir kısmı ile beraber problemsiz
biçimde çalışmaktadır.

Dün, Bugün ve Yarın dönemde Spring, geliştiriciler arasında

J
"glue-framework" olarak tasvir edilirdi.
2EE veya yeni isimlendirmesi ile Java Ancak zaman içerisinde SpringSource
EE 6 önceleri ağırlıklı olarak EJB firması ürün portföyünü uygulama
etrafında şekillenen bir spesifikasyon sunucusundan, Spring uygulama çatısına,
olmasına rağmen, zaman içerisinde geliştirme ortamından, monitör ve yönetim
bünyesine Servlet, JSP, JPA, JSF, JAX-WS araçlarına kadar çeşitlendirmiş, Spring de
gibi spesifikasyonları da dahil ederek Java dünyasında "full stack" bir çözüm
bugün bir şemsiye spesifikasyona olarak algılanmaya başlanmıştır. Zaman
dönüşmüştür. İlk yıllarda özellikle EJB içerisinde SpringSource monolitik olarak
spesifikasyonunun vaaz ettiği hantal tanımladığı uygulama sunucularındaki
mimari ve programlama modeli yüzünden değişik kabiliyetleri kendi ürün ailesi ile
Java EE ile proje geliştirenler ciddi karşılar duruma gelmiştir.
sıkıntılar yaşamışlardır. Tek veritabanı
kullanılmasına rağmen JTA ve 2PC Geçmişte EJB 1.0, 2.0 ve 2.1
transaction yönetimi ile uğraşılması, web spesifikasyonları ortaya konarken yapılan
container ile EJB container'ların aynı en büyük yanlışlık bu alandaki
fiziksel makinalarda olmalarına rağmen pratiklerden, olumlu ve olumsuz
katmanlar arası iletişimin RMI ile deneyimlerden ve ortaya çıkmış güzel
yapılması, spesifikasyonun ORM, web çözümlerden faydalanılmamasıydı. Sonuç
servisleri, güvenlik gibi pek çok alandaki olarak da gerçek dünyadan kopuk,
eksiklikleri ve muğlaklıkları nedeni ile çoğu eksiklerle dolu ve kullanılması,
proje gereksiz biçimde kompleks bir hal uygulanması güç spesifikasyonlar ortaya
almış, geliştirme süreçleri sancılı hale çıkıyordu. Java EE "expert grup"ları hem 5
gelmiş, üretim ortamında performans hem de 6 spesifikasyonlarının
sorunları ile karşılaşılmıştır. oluşturulmasında bu yaklaşımı terk etmiş
görünüyorlar. Artık "expert
Spring'in temelleri ise 2004 yılında Rod grup"lar spesifikasyonları Spring,
Johnson'ın yazdığı, yukarıda bahsettiğimiz Hibernate, Seam, Guice gibi açık kaynak
problemlere eleştirel bir yaklaşım getiren kodlu projelerde ortaya çıkan işe yarar
ve alternatif çözümler sunan "J2EE without fikirlerden yola çıkarak oluşturmaya gayret
EJB" kitabı ile atılmıştır. Kısa sürede ediyorlar. Bu tür spesifikasyonların
kurumsal Java teknolojileri ile geliştirilen oluşturulması, Java teknolojileri ile yazılım
uygulamalar için vazgeçilmez bir uygulama geliştirenler arasında ortak bir platformun
çatısı haline gelmiştir. Spring sayesinde, ve çözüm yapılarının oluşmasını
kurumsal Java projelerinde EJB kullanarak sağlamaktadır. Bir nevi spesifikasyonlar
bahsedilen problemlerle boğuşmanın şart Spring, Hibernate vb. açık kaynak kodlu
olmadığı, POJO tabanlı bir programlama çözümlerin devamında, bir sonraki
modeli ile test güdümlü çevik bir kurumsal aşamada ortaya çıkacak yeni innovatif
yazılım geliştirme sürecinin projelere çözümler için temel teşkil etmektedir. Aksi
uygulanabileceği anlaşıldı. İlk çıktığı takdirde ortalıkta hiç spesifikasyon
olmasaydı Java dünyasındaki geliştiriciler getirdiği zorluklar ve yavaşlıklar da Java
için edinilmiş bilgi birikimi ve deneyimin geliştiriciler için ciddi problemler
diğer projelere aktarılması, taşınabilir doğurmaktadır. Spring ise spesifikasyon
çözümlerin ortaya çıkması zorlaşacaktır. yükünü tam olarak üzerinde hissetmediği
için güncel trendlere kendini çok daha
Gelinen noktada Java EE 6'daki yeniliklerin kolay adapte edebilmektedir.
pek çoğunun Spring, Hibernate, Seam gibi
çatılardan esinlenmelerle, test güdümlü
Spring mi, Java EE 6 mı?
yazılım geliştirme ve çevik metodolojilerle
çalışma yaklaşımlarının sonucunda ortaya
çıktığını söyleyebiliriz. Bu nedenle aslında
Java EE 5'den sonra 6'nın biraz daha
"Spring"leştiğini söylemek yanlış olmaz
sanırım. Spring ilk çıktığında her katmanda
farklı farklı teknolojilerin bir araya getirilip
kullanılması, bu teknolojilerin
kullanımlarının kolaylaştırılması gibi
noktalardan da reklamını yapıyordu. Ancak
5 ve 6 spesifikasyonlarındaki yenilikler ve
iyileştirmelerle Spring'in elinden bu
ayrıcalık alınıyor diyebiliriz. Örneğin
Spring ve Java EE 6 kıyaslamalarındaki
JdbcTemplate veya HibernateTemplate
belki en büyük hata bunların "ya hep ya
JDBC ve Hibernate ile çalışmayı oldukça
hiç" mantığı ile yapılmalarıdır. Java EE
kolaylaştırmalarına rağmen zaman
içine pek çok değişik APInin dahil olduğu
içerisinde Hibernate 3 ve JPA 'nın ortaya
şemsiye bir spesifikasyondur. Spring ise
çıkması ile HibernateTemplate ve
bu pek çok API'nin büyük bir kısmı ile
JpaTemplate'in geliştiricilere
beraber problemsiz biçimde çalışmaktadır.
sağlayabileceği fazla birşey kalmadı. Yine
Hatta bu API'lerin kullanımını daha kolay
de şu an için bile bu teknolojileri
ve daha verimli bir hale getirmeye gayret
kullanırken Spring'in veri erişim katmanı
etmektedir. Tabi bunun yanında kendine
üzerinden kullanılmaları, JDBC ve ORM
has diğer pek çok kabiliyeti de
işlemlerinin aynı transaction içerisinden
geliştiricilere sunmaktadır.
yürütülmesi ve lokal veri kaynağı
kullanılması, exception hiyerarşisinin ortak
bir yapı ile ifade edilmesi gibi noktalardan Java EE 6'nın tasarımında öne çıkan
özelliklerinden birisi "convention over
kolaylıklar arz etmektedir.
configuration" yaklaşımının APIlerinde
sistematik biçimde uygulanmasıdır. Java
Bugün insanların yavaş yavaş Spring'e
EE 6 API'lerini, örneğin EJB 3.1'i
karşı cephe almalarının arkasındaki temel
kullanmaya başladığınızda mevcut ayarlar
neden belki biraz da SpringSource'un içine
sisteminizin ilk çalışması için yeterli
girdiği dönüşümdür. SpringSource kısaca
olacaktır. Ne annotasyonlara, ne de
özetlemek gerekirse tc ve dm
herhangi bir XML konfigürasyon dosyasına
Server'lardan başlayarak geliştirme
ihtiyacınız vardır. Spring için ise durum
ortamına kadar kendi Java EE platformunu
tam tersidir. Daha doğrusu Spring'in
oluşturmaya yönelmiştir. VmWare
yaklaşımında sistem size gizliden birşeyler
firmasına satılmasıyla birlikte artık iyice
daha sunmaya çalışmamaktadır. Siz ne
kapalı bir sistem olduğu yönünde kaygılar
isterseniz Spring o kadarını sağlamaktadır.
had safhaya ulaşmıştır. Kurumsal Java
Örneğin servis metodlarınızın transactional
dünyası ise spesifikasyon üzerinden
olması için Spring'e bunu açık biçimde
ilerleyerek, değişik üreticilerin yer aldığı
belirtmeniz gerekir. EJB 3.1'de ise
açık bir platform olarak kalmaya önem
metodlar varsayılan durumda halihazırda
vermektedir. Ancak zaman zaman
transactionaldır. Ancak Spring size bu
spesifikasyon üzerinden ilerlemenin
konfigürasyonları tekrar tekrar yapmak yöntemlerindeki çeşitliklik Spring tarafında
yerine bir kere yapıp, müteakip daha fazladır. Hatta @Configurable
durumlarda yeniden kullanabilmenizi de annotasyonu ve AspectJ sayesinde Spring
mümkün kılmıştır. Örneğin, @Service tarafından yönetilmeyen nesnelere bile
steryotipini genişleterek kendinize özel "dependency injection" yapmak
servis annotasyonu oluşturup, mümkündür. CDI içerisinde yer alan
metodlarınızın varsayılan durumda scope'lar ise Java EE'yi Spring'e kıyasla
transactional olmasını sağlayabilirsiniz. Her öne çıkarmaktadır. Özellikle web
iki yaklaşımın da kendine has artı ve programcılarının uzun zamandır ihtiyacını
eksileri vardır. "Convention over duyduğu ve Seam, WebFlow gibi çatılarla
configüration" yaklaşımı sistemin ilk dışarıdan projelerine dahil ettikleri
oluşturma ve çalıştırma süresini "conversation scope" desteği
kısaltmasına rağmen, mevcut yapıyı da bir spesfikasyona dahil edilmiştir. Spring de
kalıp içerisine sokmaktadır. Örneğin, eğer conversation scope ve tarayıcı pencere
EJB'lerinizi varsayılan durumda yönetimini 3.1 sürümünde kullanıcılarına
transactional yapmak istemiyorsanız bu sunmayı planlamaktadır.
sizin için problem olacaktır. Spring için ise
uygulamanın ilk oluşturulma ve çalışma Neredeyse bir asırdır bekliyoruz
safhası daha uzun olmakta, ancak diyeceğimiz [Link]'in parça parça
uygulamanın yapısı üzerinde her türlü tanımlanabilmesi ve profil desteği
farklılandırmaya gitmek de daha kolaydır. spesifikasyondaki temel yeniliklerden bir
Örneğin, istediğimiz zaman Spring diğeridir. Bu sayede her proje tipine göre
tarafından yönetilen servis beanlarımızı bir takım teknolojilerin bir araya
transactional yapabiliriz, istediğimiz zaman getirilmesi ile oluşturulacak konfigürasyon
da bunların transactional özelliklerini yığıtları mümkün olabilecektir. Java EE 6
kaldırabiliriz. web profili sadece Servlet ve JSP gibi
APIleri içeren hafif sıklet profildir. Bunun
Spring sayesinde yaygınlaşan, üzerine EJB 3.1, JTA, JPA, JSF ve
bağımlılıkların container tarafından WebBeans konarak bir diğer profil
yönetilmesi yani "dependency injection" oluşturulmaktadır. Bu profilin üzerine de
yaklaşımı bu versiyonda spesifikasyona JMS, JAX-WS gibi APIler eklenerek bütün
"Context and Dependency Injection" (CDI) platformu kapsayan tam bir profil
adı ile girerek, EJB ve container tarafından sunulmaktadır. Java EE profilleri, Spring'in
yönetilen diğer kaynakların yanında neye ne kadar ihtiyacınız varsa o kadarını
POJOlar için de uygulanabilir hale kullanın yaklaşımının spesifikasyona bir
gelmiştir. Dependency injection'ın JavaEE yansımasıdır diyebiliriz.
spesifikasyonuna girmesi ile birlikte
Spring'in xml ve annotasyonlarının İlgi yönelimli programlamanın (AOP)
standart dışı olması onun hanesine eksi uygulama geliştirmede kullanılması
puan olarak yazılmaya başlamıştır. açısından Spring, spesifikasyona göre çok
İnternet üzerindeki blogların ve yazıların daha öndedir. Java EE 6 ile "interceptor"
pek çoğunda da temel eleştirilerden birisi desteği sağlanmış ve "around advice" bir
Spring'in XML tabanlı konfigürasyonudur. biçimde karşılanır olmuştur. Ancak AspectJ
Oysa ki uzun bir zamandır neredeyse hiç gibi bir AOP dilinin doğrudan projeniz
XML kullanmadan Spring bean'larını içerisinde kullanımı ve bu AOP dilinin
tanımlamak ve kullanmak mümkündür. bütün kabiliyetlerinden yararlanmak
Annotasyon tabanlı veya programatik bean Spring ile çok daha kolaydır. Bununla
konfigürasyonu kabiliyetleri Spring 3 ile beraber spesifikasyonla birlikte gelen
daha da geliştirilmiştir. Ayrıca Dependency "metod interceptor"ler, annotasyonlarla
injection'ı sadece bir bean'ı başka bir ilgili sınıfla ilişkilendirildiklerinden iki yapı
bean'a enjekte etmek olarak görmek arasında sınıf düzeyinde bir bağımlılık
doğru olmaz. Nesneler arası bağımlılıkları ortaya çıkarmaktadır. Bu da farklı
oluşturma ve birbirine enjekte etme nesnelerin farklı interceptorler ile
ilişkilendirilmelerine engel teşkil
etmektedir. Aslında bu annotasyon
merkezli konfigürasyonların temel bir Sonuç
zaafıdır.
Java dünyasının spesifikasyonlardan en
büyük beklentisi, ilgili teknolojilerde
Java EE 6'nın Spring ile arasındaki standartlaşmayı sağlamasıdır. Ancak
mesafeyi oldukça kapadığı doğrudur, spesifikasyonların, hemen herkes
ancak hala bazı konularda Spring'in açık tarafından gerekli görülen bazı özellikleri
ara önde olduğunu söyleyebiliriz. üreticilerin kararına bırakması bu
Bunlardan birisi de güvenliktir. Önceleri standartlaşmayı zorlaştıran durumlardan
"Acegi Security Framework" adı ile ortaya birisidir. Örneğin JPA 1.0 içerisinde Criteria
çıkan ve Spring üzerine kurulu, web API'nin yer almamış olması JPA kullanan
uygulamaları için güvenlik çatısı olan bu her projenin pratikte alttaki ORM
framework daha sonra Spring'in ürün ailesi gerçekleştirimine bağımlı olması demekti.
içerisinde dahil edilmiştir. Spring Security Bu durum ancak JPA 2 spesifikasyonunda
olarak tanınan çözüm, kurumsal web giderilebilmiştir. Güvenlik tarafında da
uygulamalarındaki kimliklendirme ve spesifikasyonun açık bıraktığı pek çok
yetkilendirme ihtiyaçlarına konu vardır. Dolayısı ile kurumsal
spesifikasyondan çok daha iyi ve platform uygulamaların kimliklendirme ve
bağımsız çözümler sunmaktadır. Java EE yetkilendirme ihtiyaçlarında ya üreticiye
spesifikasyonu hala güvenlik konusundaki bağımlı olmaları, ya da kendilerine has
açıkları ve belirsizlikleri giderip, çözümler geliştirmeleri kaçınılmaz
containerdan bağımsız bir hale olmaktadır. Sonuçta kurumsal projelerin
gelememiştir. Spesifikasyondaki güvenlik farklı üreticiler arasında geçişler
mekanizması ile geliştirdiğiniz sağlayabilecek oranda platform bağımsız
uygulamanızı Weblogic, Websphere ve geliştirilmesi pratikte mümkün
Tomcat gibi üç ayrı container'a deploy olamamaktadır. Bütün bu standartlaşma
etmeye çalışırsanız, ne demek istediğimizi çabalarının, Spring geliştiricileri ve Java
daha kolay anlayabilirsiniz. Bütün bunlara "expert grup" arasındaki mücadelenin biz
ilaveten FactoryBean, post processor'lerin, kurumsal Java teknolojileri ile yazılım
constructor injection'ın, list ve map geliştirenler açısından yararlı sonuçlar
tanımlamalarının ve geliştirme sürecinde doğuracağını söyleyebiliriz. Kısacası nasıl
ihtyaç duyulan daha pek çok yardımcı ki JPA yeni Hibernate oldu, Java EE 6,
sınıfın Spring'le beraber olması hala onu belki Java EE 7 de yeni Spring olma
Java EE spesifikasyonundan birkaç adım yolunda ilerliyor diyebiliriz.
öne koymaktadır.

Yazar: ODTÜ Bilgisayar Mühendisliği'nden 1999 yılında mezun olan Kenan

Sevindik o dönemden bu yana pek çok büyük ölçekli kurumsal yazılım
projesinde görev yapmıştır. Halihazırda kurumsal Java teknolojileri ile yazılım
geliştirme, eğitim ve danışmanlık hizmeti sunan yazarımız, değişik ortamlarda
teknoloji içerikli konuşma ve sunumlar da yapmaktadır. Edindiği bilgi birikimi
ve deneyimleri [Link] adresinden sanal alemde
sizlerle paylaşmaktadır. Kendisi ile iletişime geçmek için ksevindik@[Link] adresine
mesaj gönderebilirsiniz.