J2EE Nedir? 26/04/2003

J2EE Nedir ve Avantajları Nelerdir?

Bı bölümde Yağız ERKAN tarafından tarafından çok güzel bir şekilde yapılan tanımlamanın tekrarını yapmak yerine kendisinden alıntı yapmayı daha uygun gördüm.

<! -- YAĞIZ ERKAN

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: 

  1. İ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...
  2. 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 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
  3. 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
  4. 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
  5. 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ĞIZ ERKAN-->

 

J2EE nin çıkış amacı ve kullanımının gereksinimlerinden sonar yavaş yavaş teknik kısıma doğru yol alalım.

 

ENTERPRISE JAVA BEANS

Enterprise Java Beans sunucu taraflı ölçeklenebilir,işleme dayalı ve çok kullanıcılı güvenli enterprise uygulamalar oluşturmak için kullanılan bir standarddır.N katmanlı middleware uygulamalar geliştirmek için sabit bir bileşen mimari çatısı sunmaktadır.

Tipik bir EJB mimarisi

·         Bir EJB sunucusu

·         Bu sunucular üzerinde çalışan EJB konteynerleri

·         Bu konteynerlerde çalışan EJB’ler

·         EJB clientlar

·         JNDI(Java İsimlendirme ve Dizin Arayüzü)

·         JTS(Java İşlem Servisi)

·         JavaServer Pages (JSP)

·         Servlets

·         JDBC

·         XML desteği

·         Java Messaging

·         JavaMail

·         Java support for CORBA gibi yan sistemler

den oluşmaktadır.

Bu teknolojiler ile J2EE , Yahoo Mail gibi web uygulamaları,E-TRADE gibi web tabanlı stok ticaret sistemlerinin implementasyonları veya eBAY gibi onlline açık arttırma evi gibi web uygulamaları için çok kullanışlıdır.Bir veri kolleksiyonuna birçok kişinin dağıtık biri biçimde erişiminin sağlanması için J2EE spesifikasyonunun implementasyonu en uygun çözümlerden birini sunacaktır.

Şu an

·         Netscape/AOL iPlanet

·         BEA WebLogic

·         IBM WebSphere

·         The JBoss Group's Jboss

J2EE uyumlu ürünler sunmaktadırlar.

Bir Senaryo

Herhangi bir geliştirme ve konuşlandırma senaryosu uyarınca , üzerindeki EJB konteynerleri ile birlikte bir EJB sunucusu satan bir EJB sunucu sağlayıcı bulunacaktır.Bu kademeden sonra EJB leri geliştiren EJB uzmanları ve oluşturulan EJB leri uygulamalarda kullanacak uygulama birleştiricileri bulunacaktır.

EJB Sunucuları

EJB Sunucuları CORBA ORB ile benzerdirler.EJB sunucuları ham çalıştırma ortamı,çoklu işleme,yük dengeleme,cihaz erişimi,isimlendirme ve işlem servisleri gibi sistem servisleri sunar ve konteynerleri görünür hale getirirler.

EJB Konteynerleri

Bunlar EJB ve dış dünya arasındaki bir köprü görevi üstlenmektedirler.Bir EJB client hiçbir zaman bir EJB ye direk olarak erişemez.Herhangi bir EJB erişimi konteyner tarafından oluşturulan ve sonunda Bean üzerindeki metodları çalıştıran metodlar sayesinde gerçekleştirilir.İki çeşit konteyner,geçici ve kalıcı olmayan EJB leri barındrıan ve durumları hiçbir zaman korunmayan (session)oturum konteyneri ve kalıcı EJB leri barındıran ve çağrım aralarında durumları korunan entity(varlık) konteyner leridir.

EJB Client

EJB istemcileri kendi işlerinde EJB leri kullanan birimlerdir.JNDI arayüzü sayesinde istemciler ihtiyaç duydukları EJB yi barındıran konteyneri saptarlar.Daha sonra EJB metodlarını çağırmak için bu konteyneri kullanırlar.

İki çeşit EJB bulunmaktadır.Bunlar

·         Session Bean

·         Entity Bean

·         Mesaj Sürümlü Bean(EJB 2.0)

Olarak adlandırılmaktadır.

Session Bean

Session Bean genel olarak istemci tarafından kullanılacak olan EJB sunum katmanını oluşturmaktadır.Her Session Bean genel yaklaşım ile bir EJB İstemcisi ile ilişkilendirilmektedir.Session Bean ler ilişkilendirildiği EJB İstemcisi ile oluşturulup yok edilmektedirler.Session Bean ler durumlu ve durumsuz olarak ikiye ayrılmaktadır.Sistem kapatımı sonunda Session Bean ler her iki koşulda da durumlarını koruyamamaktadırlar.

Entity Bean

En genel tanım olarak EJB,veritabanındaki bir tablo ve bu bean den olulturulmuş bir nesne ise o tablodaki bir kayıt anlamına gelmektedir.Entity Bean ler daima bir duruma sahiptirler.Her Entity Bean birden fazla EJB İstemcisi arasında paylaşılabilmektedir.Durumları korunmakta ve birden fazla çağırım sonucunda kaydedilmektedir.Böylelikle sistem kapatımları sonucunda Entity Bean durumları korunmaktadır.

 

Genel Yapı

EJB Sunucuları çalışma kümelerinin denetimini gerçekleştirmektedirler.Pasivasyon bir bean durumunun kaydedilmesi ve daha sonra değiştirilmesi işlemidir.Aktivasyon ise yine bean değişimi sonucunda kayıdın okunması ve tekrar kullanıma getirilmesidir.Bu işlemler hem Entity hem de Session Bean için geçerli operasyonlardır.

İki çeşit Session Bean bulunmaktadır.Bunlar

·         Stateless SB

·         Stateful SB

olarak ikiye ayrılır.Stateless SB bir iç duruma sahip değildir.Herhangi bir duruma sahip olmadıklarından dolayı pasivasyon işlemi ile bu durumlarının korunması gerekmemektedir.Durumsuz olduklarından dolayı servis çoklu istemcisi içerisinde bir havuz sistemi ile çalışabilirler.Stateful SB ise iç duruma sahip session bean lerdir.Bu sebepten Aktivasyon ve Pasivasyon işlemlerini ele almalıdırlar.Herhangi bir EJB istemcisi için yanlızca bir adet Stateful SB bulunabilir.Kalıcı olabileceklerinden dolayı Kalıcı Session Bean olarak da adlandırılmaktadırlar.Bu çeşit EJB ler istemci oturumları arasında kaydedilip yeniden yüklenebilirler.Kaydetmek için , EJB nin getHandle() metoduna bir çağrı yapılarak bir handle nesnesi elde elde edilir.Yeniden yüklemek için ise handle nesnesinin getEJBObject metodu çağrılır.

Entity Bean ve Veritabanı

Entity Bean ler ile gerçekleştirilen kalıcılık iki şekilde gerçekleştirilmektedir.

·         Konteyner yönetimli kalıcılık

·         Bean yönetimli kalıcılık

Konteyner yönetimli kaılıcılıkta Bean in durumunun kaydedilmesi konteynerin görevidir.Konteyner yönetimli olduğundan dolayı implementasyon , veri kaynağından bağımsız olarak geöekleştirilmektedir.Konteyner yönetimli alanlar Konuşlandırma Tanım dosyasında belirtilmeli ve kalıcılık otomatik olarak konteyner tarafından denetlenmelidir.

Bean yönetimli kalıcılıkta ise EJB direk olarak kendi durumunu kaydetmek ile sorumludur.Konteynerin herhangi veritabanı çağrısı yapması bu durumda gerekmemektedir.Bu sebepten dolayı SQL çağrılarının kodda yazılması bu yöntemin öncekinden daha az uyumlu olmasına neden olmaktadır.

Konuşlandırma Tanımlayıcıları(Deployment Descriptors) bir sınıfın derilenmiş örneklemeleridir.Bir EJB nin seçenekleri ve konteyner için gerkli olan konuşlandırması için gerekli olan bilgiyi aktarmak için kullanılırlar.EJB geliştirici bean ile birlikte bir deploymeny decriptor yapmak ile sorumludur.