Java EE 6

Java EE 6’da EJB’er İçin JNDI Adresleri

Java, Java Dersleri, Java EE , , , , ,

Java EE kullananların sıkıntı yaşadığı en temel konulardan birisi de, EJB’lerin JNDI adreslerinin ne olduğu konusudur. Bu konu Java EE 6’ya kadar bir standart üzerine oturtulmamış olduğundan, uygulama sunucusu (application server) üreticilerinin farklı yaklaşımlarını bilmek ve ona göre JNDI erişimleri yapmak söz konusudur. (Gerçi Java EE 5 ile başlayan bağımlılık  zerketme (dependency injection, DI) sayesinde yönetilen nesnelerde EJB erişimi çok kolaylaşmıştı ama yine de örneğin uzaktan erişimler için JNDI arama  (lookup) çağrıları gerekmekteydi.) Yani, her uygulama sunucusu için geçerli bir genel geçer adresleme mekanizması yoktu. Yoktu diyorum çünkü bu konu Java EE 6 ile gelen EJB 3.1’de çözüme kavuşturuldu.  Aşağıda standart hale getirilmiş JNDI’ın EJB isimlendirme yapısını kısaca aktaracağım.
okumaya devam …

Toplam görüntülenme sayısı: 2150

Java EE 6 Üzerine – I

Java EE , , , , , , ,

Giriş

Java’nın kurumsal uygulamalar için gerekli bileşenlerini içeren yapısının (Enterprise Edition EE) 6. sürümü piyasaya çıktı. Java EE’nin zaten 5. sürümünde başlattığı ciddi değişimini 6. sürümünde de, daha da geniş bir kapsamda devam ettirdiği görülüyor. Bu değişimin amacını “basitlik ve üretkenliği arttırmak” olarak özetlemek mümkün.

Java, eskiden bu yana basitlik/pratiklik ve üretkenlik ile yapısal ve tabiri caizse akademik olmak arasında, tercihini ikinciden yana kullanmakla eleştirilen bir dil olmuştu. Yani Java, daha karmaşık, daha yapısal ve kullanıcısına daha fazla insiyatif alanı veren ama buna karşın üretim hızının daha uzun vadede iyileştirebileceği bir geliştirme ortamı sağlamaktaydı. Evet nesne yapısı, mimari merkezli yaklaşımı ve mesela tasarım desenlerini yoğun bir şekilde kullanmayı teşvik eden pratikleri ile Java, kullanıcılarına devamlı olarak, çok büyük projelerin altından kalkabileceklerini fısıldamış ve onlara bu özgüveni vermeye çalışmıştı. Ama öte taraftan bu durum, dili ve onun etrafında gelişen bileşenleri, özellikle Java EE’yi bazen aşırı akademik yapmış ve zaman zaman kullananların üretim hızlarına fren de olmuştu. Buna, Java EE’nin en başından bu yana parçası olmuş EJB’leri ve Java nesnelerini ilişkisel veri tabanında kalıcı hale getiren (persistence) çözümlerini örnek olarak verebiliriz. Bu duruma, her ne kadar bu çapta bir kurumsal çerçeveyi (framework) kurma girişiminin ilk örneği olmanın getirdiği toyluk yol açmış olsa da, Sun’ın eskiden bu yana en iyi yaptığını düşündüğüm şey olan, Java toplumunun sesini dinleme ve ondan gelen eleştirilere değer verme tavrı, Java’nın çok daha iyi yerlere gelmesini sağlıyor. Bu durumu, Java’yı en başından bu yana uygulayarak takip eden birisi olarak, taa AWT’den Swing’e ya da Vector ve Hashtable döneminden nefis torba (collection) yapılarına geçişte ya da Javacılara en başlarda ciddi problemler çıkaran performans sorununun HotSpot gibi belki en ileri tekniklerle geliştirilmiş derleyici ile çözülmesinde bizzat yaşadım.

Benzer ilerlemeleri şimdi çok daha geniş bir düzlemde, kurumsal bileşenler düzeyinde yaşıyoruz. Ama kurumsal yapılarda üretkenliği sağlamak, performans problemini bir derleyici ile aşmak kadar yerel bir durum değil, çok daha geniş bir çerçevede ele alınması gerekiyor. Notlandırma (annotation), EJB’lerin 3.0 yapısı ve bu yapıda entity beanlerin artık hayatlarına son verilip, nesne-ilişkisel veri tabanı uyumsuzluğunun JPA (Java Persistence API) ile halledilmesi, bağımlılık zerketme (dependency injection, bu kavramın Türkçe’ye bağımlılık iletimi olarak çevrildiğini gördüm ama benim tercihim bu) gibi Java EE’yi çok daha tanım tabanlı (declarative) yapan desenlerin yoğun bir şekilde kullanılmaya başlanması gibi pek çok yenilik, Java EE’nin yeni sürümlerinin artık üretkenlik odaklı olacağının işaretlerini vermişti. Aslında bu durumu, biraz da 2000’li yılların başından itibaren varlıklarını yoğun bir şekilde hissettiğimiz, çoğu projelerde ürünlerini kullandığımız ve ciddi bir kısmı açık kaynak kodlu, üçüncü sahıs (third party)  girişimlere ve projelere borçluyuz. Örneğin Spring ve Struts gibi çerçeveler, Apache gibi pek çok açık kaynak kodlu projeyi barındıran topluluklar, Toplink, Hibernate ve Castor gibi Java’nın standartları içinde yeterince etkin çözülmeyen konuları halleden ürünler, hepsi Java EE 5’ten itibaren EE’ye ciddi derecede katkıda bulundular. Bu yapılar çoğunlukla geliştirici odaklı oldukları için, ürünlerinde basitlik ve üretkenlik ön plandaydı. Java’nın daha demokratik ve katılımcı tabanlı (Java Community Process, JCP) olarak geliştirilebiliyor olması da, Java toplumundan gelen isteklerin, basitlik, yüksek üretim hızı, rahat genişletilebilirlik gibi ihtiyaçların Java’nın standart bir parçası olmasını sağlıyor.

Java EE 5

Önce kısaca 2006 Mayıs’ında piyasaya çıkan Java EE 5’in neler getirdiğini hatırlayalım: JSR 244 ile gelişen Java 5 EE’nin en temel hedefi basitlikti. Kurumsal uygulamaların daha basit olarak gerçekleştirilebilmesine imkan vermek amacıyla, notlandırma (annotation) özelliğini EE için kullanmaya başladı. Java EE’yi daha tanım tabanlı yapmayı amaçlayan bu özellik, genel olarak bağımlılık zerketme deseni ile uygulanıyordu. Fakat bu özellik, yeni EJB 3.0 sürümü ile eski sürümlerdeki entity beanlerinin yerini alan ve Java nesnelerinin ilişkisel veri tabanında kalıcılığını sağlayan JPA ile Web servisleri tarafında kullanılırken, servlet, JSP ve JSF gibi diğer web bileşenlerinde kullanılmadı.
Web tarafında, 2004 yılı başında J2EE’den bağımsız olarak 1.0 sürümü çıkan JSF, yeni sürümü 1.2 ile Java EE 5’in bir parçası oldu. Ayrıca JSP 2.1 ve Servlet 2.5 sürümleri Java EE 5 içinde yer aldılar. Ayrıca Web Servislerinde ciddi yenilikler içeren sürümler de yer aldı.

Orta katmandaki EJB yapısı, 3.0 sürümü ile daha sadeleştirildi. Örneğin entity beanleri JPA’ye dönüştü ve gerek yönetilen (managed, yani uygulama sunucusu ortamı) gerek ise Java SE ortamlarında kullanılabilecek şekilde yapılandırıldı. JPA 1.0, Java dünyasında nesne-ilişkisel uyumsuzluğuna getirilen standart çözümlerin (JDBC, entity beanleri ve daha sonra da JDO) bir türlü istenileni verememesi ve Hibernate, Toplink vs. üçüncü şahıs çözümlerinin yaygın kullanım alanı bulması üzerine, entity beanlerden vazgeçilip, JDO’nun kenara itilmesiyle yepyeni bir API olarak karşımıza çıktı. JPA’in yapısı da bu konuda, Hibernate ve Toplink gibi revaçta olan pek çok üçüncü şahıs yazılımın katkılarıyla şekillendirildi. Ayrıca JPA’in gerek XML gerek ise notlar ile kullanılabilmesi, geliştiricilere esneklik sağladı.

EJB’ler, 3.0 sürümü ile ciddi bir şekilde basitleştirildi. Örneğin home arayüzlerini kullanma gerekliliği ortadan kaldırıldı. Ayrıca EJB’lerde notlandırmaların kullanılabilemesi pek çok basitliği beraberinde getirdi. Örneğin EJB’lerin içinde bulunduğu kaptan (container) aldığı hizmetler, araya giren sınıflar (interceptor), geri çağrılar (callbacks) ve EJB istemcilerinin (client) kodlanması, notlar sayesinde çok daha kolay hale geldi.

Şimdi Java EE 6’nın yeniliklerine biraz daha yakında göz atalım.

Java EE 6

Hayatına 316 nolu JSR olarak 2007’de başlayan Java EE’nin 6. sürümünün son oylaması Kasım sonunda yapıldı ve 10 Aralık’ta da en son hali, piyasaya sürüldü. Java EE 6’nın hedefleri en başta, genişletilebilirlik (extensibility), profiller, budama (prunning), SOA ve diğer ekler olarak belirlenmişti.

Java EE 6’nın son haline bakınca, yukarıda genişçe bir şekilde açıklanan basitlik ve üretkenliğe yönelik ciddi ilerlemeler ve yenilikler yanında, Java EE’nin üçüncü sahıs çerçeve ve bileşenlerle daha rahat genişletilebilmesi için gerekli yapılara da önem verildiğini görüyoruz. JSR 299 ile gelen ortam ve bağımlılık zerketme (Contexts and Dependency Injection for the Java EE platform) ve bu yapılar ve notlandırma ile kurgulanabilen takılabilir çerçeveler (pluggable frameworks), Java EE 6’nın daha rahat genişletilebilir olmasına hizmet ediyorlar.

Notlandırma

Piyasaya çıkan Java EE 6 basitliği daha da arttırmak için notlandırmaları daha fazla yapıya yaydığı görülüyor. Örneğin artık servletler ve JSF’de de notlama yapmak mümkün. Yani örneğin servletleri ve filtreleri notlarla tanımlayabilecek ve web.xml’e yazmak zorunda kalmayacaksınız. Hatta web.xml’in içeriğini web parçaları sayesinde (web fragment) birden fazla yerde ifade edip, birkaç bin satırlık, devasa web.xml dosyalarından kurtulmuş olacaksınız. JSF’de de managed beanler, notlar ile tanımlanabilecek, etkinlik alanları (scope) belirlenebilecek.


@WebServlet(name="SelamServlet", asyncSupported=true,
urlPatterns={"/selam", "/SelamServlet"})

Bağımlılık Zerketme

Artık bağımlılık zerketme Java’nın içine o kadar girdi ki Java için bununla alakalı olarak JSR 330 altında Dependency Injection for Java adıyla standart bir yapı tanımladı. Yani bağımlılık zerketme amacıyla kendi notlarınızı ve ilgili yapılarınızı tanımlayabileceksiniz. Bağımlılık zerketme desenini Java EE platformunda kullanmak amacıyla da ayrı bir yapıyı JSR 299 altında ve Contexts and Dependency Injection for the Java EE platform adıyla ayrıca tanımlandı. Dolayısıyla mesela nelerin zerkedilebileceğini, @Inject gibi bir not ile belirleyebileceksiniz. Böylece kend geliştirdiğiniz yapıların Java ile rahat ve hızlı bir şekilde kullanımını sağlamış olacaksınız. İlk başta karmaşık gelse de kısa sürede Javacıların bundan faydalanacaklarını düşünüyorum.

Profiller

Bu sürümle ile birlikte Java EE’ye profil kavramı girdi. (Aslında profiller kavramı daha önce web servislerinde de vardı ama bu Java dışında gelişen bir yapılandırmaydı.) Java EE’nin gittikçe büyüyen yapısı, farklı uygulama tiplerine göre farklı yapıları içinde barındıracak şekilde profillendirilecek. Bu amaçla ilk oluşturulan Web profili, web uygulamalarına uygun bir şekilde bir alt bileşen ve API kümesini temsil ediyor ve örneğin JMS, JavaMail, Web Servisleri ile Java Connector Architecture bileşenlerini içermiyor. Web profilinin hangi yapıları içerdiğini daha detaylı bir şekilde bu tablodan görebilirsiniz. Bu durum, zamanında Java’nın da farklı uygulamalar için SE, ME ve EE olarak üçe bölünmesinden başka birşey değil. Böyle bir profil yapısı sanırım, uygulama sunucusu üreticilerin de lisanslarında farklılıklara gitmesini sağlayabilir.

Web

Web tarafında Servlet 3.0, JSP 2.2 ve JSF 2.0 ile gelen diğer önemli yenilikleri şöyle sıralayabiliriz.
• Eş zamanlı olmayan (asynchronous) servletler
• Çalışma zamanında programatik olarak servlet ve filtre oluşturabilme yeteneği
• JSF’lerin daha etkin geliştirilebilmesi için facelet ve şablon (template) yapısı
• JSF bileşenlerinde gömülü (built-in) AJAX desteği

Yukarıdakiler arasında sanırım en önemlisi eş zamanlı olmayan servletler. Yukarıdaki örnekte olduğu gibi @WebServlet notunun bir özelliği olarak tanımlanabilecek olan eş zamanlı olmama özelliği, servletin, işlemekte olan bir metodunun yaptığı diğer metod çağrılarını beklemesine gerek bırakmadan yoluna devam etmesini sağlayacak.

EJB

EJB tarafında da ciddi yenilikler var. Yenilikler daha çok session beanlerini ilgilendiriyor ve amaç da onları, Java EE 5 içinde EJB 3.0 sürümüyle başlayan süreçte,  daha da basitleştirip kullanılabilir kılmak. Bu seferki sürüm 3.1 (JSR 318) ve şu yenilikleri içeriyor:

  • Artık yerel (local) session beanler için arayüz tanımlamaya gerek yok, sadece bean sınıfını tanımlamak yeterli.
  • Bir uygulama için bir tek nesnesinin olması (singleton) garanti edilen session beanleri oluşturmak mümkün.
  • Session beanlerini eş zamanlı olmayacak (asynchronous) şekilde çağırabilmek mümkün.
  • EJBlerinizi artık illa ejb-jar dosyasına koymak zorunda değilsiniz. Örneğin bir web uygulamasının war dosyasının içindeki lib klasörü EJB jar dosyalarını içerebilir.
  • Ve EJBlerin daha hafif bir şekli olan EJB Lite J. EJB Lite, her uygulamada ihtiyaç olmayan, örneğin remote arayüzü ya da timer hizmeti gibi belli EJB özellik ve hizmetlerini budayan ve EJB’lerin daha yalın bir şekilde kullanılmasına izin veren bir yapı. Web profilinde EJB Lite var mesela.

JPA

JPA 1.0 hayatımıza zaten java EE 5 ile girmiş ve biz de onu çok beğenmiştik. Tabi ki bir seferde dört başı mamur bir bileşen yapmak kolay değil. İşte java EE 6’daki JSR 317 ile gerçekleştirilen JPA 2.0 sürümü de irili-ufaklı pek çok eksikliği gideriyor:

  • Nesne-ilişkisel karşılık getirmede bazı yenilikler
  • Soruglama diline (Query Language) bazı ekler
  • Criteri API’si
  • Kilitleme (locking) mekanizmalarıyla alakalı bazı yeni yapılar

Bean Doğrulama

Beanlerinize özelliklerinin değerlerini geçerken çağırdığımız setXxx() şeklindeki metodların içine kodlayarak koyduğumuz doğrulama (validation) kurallarını artık tanım tabanlı yapabileceğiz. Bu amaçla JSR 303 ile oluşturulmuş  Bean Validation API’i doğrulama mantığını koddan çıkarmayı ve tanım tabanlı yapmayı amaçlıyor.

RESTful Web Servisleri

Ülkemizde çok kullanılmasa da gittikçe daha yaygınlaşacağını düşündüğüm RESTful Web Servisleri, JAX-RS adını aldı ve JSR 311 altında geliştirildi. Amaç RESTful web servislerini aynı JAX-WS’de olduğu gibi daha hızlı geliştirebilmek.

Sonuç

Java EE 6’daki özellikler heyecan verici. Bu yeni yapılar ile daha basit yapıda ve hızlı bir şekilde kurumsal geliştirmeler yapmak mümkün olacak. Bu yazıyla Java EE 6’deki yenilikleri özetlemeye çalıştım. İleride geliştirdiğim örnekleri de burada paylaşacağım.

Kaynaklar

Java EE 5

Java EE 6




Toplam görüntülenme sayısı: 1657