Previous
Next

JAVA - Java 2 Enterprise Edition (J2EE)

by Cem Kefeli 5. Ekim 2009 05:20

JavaYıllar önce J2EE teknolojisinin duyurulması ile birlikte klasik web yaşantımız oldukça fazla değişikliğe uğradı. Daha önceleri iki katmanlı olarak hizmet veren uygulamalar daha çok katmana yayılarak performansı, işletilebilirliği ve ölçeklenebilirliği arttırıldı. Daha sağlam ve daha güvenilir sistemler oluşturulmaya başlandı. Bu yazımda başlarda da söylediğim web teknolojisine yeni bir soluk getiren J2EE teknolojisinden kısaca bahsedeceğim.

Öncelikle şunu belirtmeliyim ki J2EE kısaltması içerisinde geçen '2' rakamı J2EE için bir versiyon numarası ifade etmemektedir. Java platformunun kendisi için bir teknoloji numarası belirtmektedir. J2EE için ayrıca versiyon numaraları vardır ve 2001 yılında 1.3 versiyonu ile başlayıp günümüze kadar 6.0'a kadar uzanmıştır. Aynı şekilde J2SE(Java 2 Standard Edition) ve J2ME(Java 2 Micro Edition) için de farklı farklı versiyon numaraları vardır. J2EE 1.4 ten sonra artık Java EE 5.0 olarak anılmaya başlanmıştır ve versiyon isimlendirilmesinde bazı farklılıklar oluşmuştur.

Java EE, uygulama geliştiricilerden fazlasıyla geri besleme almış ve çok fazla yankı bulmuştur. Çünkü sunduğu yapı şimdiye kadar sunulan klasik web teknolojisi yapılarından oldukça farklıdır. Daha önceleri iki, bazen üç, katmanlı olarak gerçekleştirilen uygulamalara çok katmanlı yapı mimarisi oturtulmuştur. Artık web uygulamalarının çok katmandan oluşabilmesi mümkün olmuştur bu teknolojiler ile.

Java 2 Enterprise Edition Multi-Tier ArchitectureÖnceleri sunucu(server)-istemci(client) taraflı, yani iki katmanlı, programlama tekniğini oldukça fazla sevdik. Sunucuda çalışan bir uygulama, ki bu genelde sunucuda host edilen bir veritabanı olacaktır, ve istemcilerde çalışan ve sunuculardan veri toparlayıp işleyen farklı bir uygulama. Bu ikisi bir araya geldiğinde ise uzaktan veritabanı işlemlerini kolaylıkla gerçekleştirebileceğiniz güzel bir uygulama ortaya çıkıyor. Fakat ortada şöyle bir problem var. Asıl işlemleri her zaman istemciler yapıyor ve iş yükünün çok büyük bir bölümü istemcilerin üzerine kalıyor. Acaba bu yük başka platformlar tarafından da paylaşılarak azaltılabilir mi? Evet azaltılabilir, zaten de tüm yapılan mimari değişiklikleri bunu sağlamaya yönelik artık son yıllarda. Bir başka problem ise uygulamanın kullanıcılara sunulmasında ortaya çıkan sorunlar. Bunun nedeni ise masaüstü uygulaması şeklinde dağıtılan ve kullanıcılar tarafından kullanılan yazılımların güncellenebilirliğinin sıkıntılı olması. Siz yaptığınız her bir güncelleme için bir üst versiyonu kullanıcılara dağıtmalı ve herbiri için tekrar kurulum gerçekleştirmelisiniz ki bu problemi aşabilesiniz. Bir diğer problem de uygulamayı kullanan kullanıcı sayısının artması durumunda sunucu makinenin yetersiz kalması. Tek çare ise uygulama sunucusunu daha güçlü bir makine ile değiştirmek. Ya da sisteme başka makineler ekleyerek ana makinenin işlem yükünü paylaştırabilmek. Fazlası...

JAVA - Garbage Collector nedir?

by Cem Kefeli 2. Ekim 2009 04:19

JavaHerhalde birçoğumuz o meşhur "Segmentation Fault" hatası ile karşılaşmışızdır. Hatanın isminin zaten başlı başına can sıkıcı olması bir yana bir de üstüne üstlük hata nerede? hani ne oldu? nerede problem? gibi soruların bir çoğunu da oldukça canınız sıkıldıktan sonra cevaplamanız mümkün olabilecektir. Bu iş en çok da C/C++ kullanırken başınıza gelecektir. Çünkü C/C++ da bellek yönetimi tamamen uygulama geliştiricilerin tasarrufuna bırakılmıştır. Yani siz sisteminizin belleğinin bir byte'lık bir gözüne dahi istediğiniz gibi erişebilirsiniz. Bunun bizim için münkün olmasını sağlayan olay pointer(işaretçi) kavramıdır. İşaretçiler ile istediğimiz gibi istediğimiz her yere erişebiliriz. Zaten sorunlara yol açan olaylar da tam olarak burada başlıyor. İstediğimiz yerlere erişiyoruz ama bazen de erişmememiz gereken bir yere erişme imkanı da veriyor bize. Hiç bir kontrol de yapılmıyor derleyici tarafından. Yani 'arkadaşım sen buraya erişmeye çalışıyorsun ama bak burası başkası tarafından kullanılıyor, ya da senin sınırlarının dışında.' gibi bir hata ile bizi uyarmıyor. İşi tamamen bizim bilincimize bırakmış durumda. Çok bilinçli kullanılması gereken bir bellek yönetimine sahip olmak gerekiyor. Bir yandan güzel bir yandan kötü bir özellik. Olayın bir başka yönü ise oluşturduğumuz nesnelerin kullanılmadıkça bir kenarda birikmesi ve bir süre sonra bellek sızıntısı(Memory Leak)'na yol açması. Bu olay C/C++ kullanan bir çok yazılımda, işletim sistemleri dahil, sık görülen birşeydir. Nesneleri oluşturup önerildiği şekilde uygun yollar ile bellek alanlarını boşaltmazsanız sağda solda birikirler ve gereksiz yer kaplayıp işletim sistemini felakete sürükleyebilirler. Bu olay dinamik bellek yönetimi olarak adlandırılmaktadır.

Bu olaya seneler önce java el attığında dedi ki: 'Ben nesneye yönelik bir yazılım dili olduğuma göre böyle şeyler ile ilgilenmem. İşaretçi kavramı filan benim için yoktur, yok gibidir. Benim gözümde herşey nesnedir. Dolayısı ile bellekte nesneler tutulur. Bellek yönetimine gelince o konuda da yazılımcıların işini çok kolaylaştıracak birşey sunuyorum. O da Garbage Collector(Çöp Toplayıcı)...'. Bu fikir C# tarafından da benimsendi. Birçok örneği olduğu gibi Microsoft bu güzelliği gözden kaçırmadı ve .NET Framework yapısı içerisine dahil etti. Nihayetinde oop dillerinin bir vazgeçilmezi haline geldi zamanla.

Garbage Collector(GC)'ın yaptığı iş temel olarak; kullanımı son bulmuş, hiçbir nesne örneği tarafından referans gösterilmeyen, bellek bölgelerini tesipit edip o bölgelerdeki bellek alanını boşaltmaktır. GC sizin yerinize yazılımınızı takip eder ve kullanılmaya bellek bölgelerini sisteme iade eder. Bu durum Java için de asla bellek sızıntısı olmadığı anlamına gelmez tabi ki ama daha öncelerine göre çok da az oranlara indirgenmiş ve bellek sızıntısı hatalarının tedavisi daha kolay hale gelmiştir. Az önce de söylediğim gibi Java pointer kavramını farklı bir alana taşıdı ve herşeye nesne gözü ile bakmaya başladı. GC ise bu nesnelerin aktif kullanımın bellek üzerindeki etkisi ile ilgilenir. Program çalıştığı sürece otomatik olarak bu işlemler gerçekleştirilebileceği gibi aşağıdaki biçimde manuel olarak da tetiklenebilmektedir.

Runtime.getRuntime().gc();  
//veya System.gc();	

JAVA - Enterprise Java Beans (EJB)

by Cem Kefeli 30. Eylül 2009 06:10

JavaJava yıllar önce ortaya çıktığında "Bir kere yaz, her yerde çalıştır!" gibi çok hoş bir sloganla çıktı uygulama geliştiricilerin karşısına. Bu slogan kısa sürede çok geniş bir yankı buldu. Çünkü duyurulan şey uygulama geliştiricilerin şimdiye kadar çok da fazla duydukları ve dile getirilmiş birşey değildi. Bu, programınızı bir kere yazıp derleyip istediğiniz platformda derlenilen yazılımın tekrar çalıştırılabilmesini mümkün kılıyordu ki, harika birşey olduğu çok açık. İşletim sistemlerinden ve donanımdan bağımsız bir programcık yazabilmek ne kadar güzel birşeydir sizler de hakkını verirsiniz diye düşünüyorum. Herhangi bir masaüstü bilgisayardan tutun da avuç içine sığan ufacık cep telefonlarında bile aynı yazımı kullanabilmek güzel birşey. Bu yazıda Java'nın gelişim süreci içerisinde çok önemli bir konuma sahip Enterprise Java Beans(EJB)'ten kısaca bahsetmeye çalışacağım.

Client - Server - DatabaseJava'nın duyurulmasının ardından yıllar geçti ve bu yıllar içerisinde Java oldukça fazla da gelişme kaydetti. Önceleri sunucu(server)-istemci(client) taraflı, yani iki katmanlı, programlama tekniğini oldukça fazla sevdik. Sunucuda çalışan bir uygulama, ki bu genelde sunucuda host edilen bir veritabanı olacaktır, ve istemcilerde çalışan ve sunuculardan veri toparlayıp işleyen farklı bir uygulama. Bu ikisi bir araya geldiğinde ise uzaktan veritabanı işlemlerini kolaylıkla gerçekleştirebileceğiniz güzel bir uygulama ortaya çıkıyor. Fakat ortada şöyle bir problem var. Asıl işlemleri her zaman istemciler yapıyor ve iş yükünün çok büyük bir bölümü istemcilerin üzerine kalıyor. Acaba bu yük başka platformlar tarafından da paylaşılarak azaltılabilir mi? Evet azaltılabilir, zaten de tüm yapılan mimari değişiklikleri bunu sağlamaya yönelik artık son yıllarda. Bir başka problem ise uygulamanın kullanıcılara sunulmasında ortaya çıkan sorunlar. Bunun nedeni ise masaüstü uygulaması şeklinde dağıtılan ve kullanıcılar tarafından kullanılan yazılımların güncellenebilirliğinin sıkıntılı olması. Siz yaptığınız her bir güncelleme için bir üst versiyonu kullanıcılara dağıtmalı ve herbiri için tekrar kurulum gerçekleştirmelisiniz ki bu problemi aşabilesiniz. Bir diğer problem de uygulamayı kullanan kullanıcı sayısının artması durumunda sunucu makinenin yetersiz kalması. Tek çare ise uygulama sunucusunu daha güçlü bir makine ile değiştirmek. Ya da sisteme başka makineler ekleyerek ana makinenin işlem yükünü paylaştırabilmek. Ne dersiniz böyle birşey sizce mümkün olabilr mi? Bir makine iş yapsın diğerleri de ona gerektiğinde yardım etsin diye birşey olabilir mi? Evet, bu da mümkün. Yani makinelerin kendi iş birliği...Fazlası...

JAVA - Late Binding(Geç Bağlama) ve Early Binding(Erken Bağlama) nedir?

by Cem Kefeli 29. Eylül 2009 07:03

JavaDaha önce buradaki yazımda polimorfizm(çok biçimlilik) konusunda bilgi verirken late binding(geç bağlama) konusundan söz açılmıştı aslında. Çünkü geç bağlama kavramı çok biçimliliğin doğal bir sonucu olarak ortaya çıkmaktadır. Yani çok biçimliliğin olmadığı bir yerde geç bağlamadan söz etmek olanaksızdır. Geç bağlamayı en genel olarak çok biçimliliğin oluştuğu anda, yani run time(çalışma zamanı) sırasında, nesne örneğinin bağlanacağı nesne türünün belirlenmesi ve buna uygun işlemlerin tamamlanması sürecinde yapılan işler olarak tanımlayabilirim. Güzel tanım oldu :) Fakat birçoğumuz için birşey ifade etmediği de çok açık. Şimdi sıra bu hipotezimizin içini doldurmaya geldi. Bu hipotezin içini doldurabilmek için "Polymorphism(Çok biçimlilik) nedir?" başlıklı yazımın içerisindeki nesne yapılarından ve kalıtım şemasından faydalanacağım. Kalıtım demişken, kalıtım ile ilgili buradaki yazımı da okuyarak az sonra anlatacaklarıma alt yapı oluşturabilirsiniz. Bu konuları anlamanızı öneriyorum çünkü kalıtımın olmadığı yerde çok biçimlilikten, çok biçimliliğin olmadığı yerde de geç bağlamadan söz etmek olanaksızdır.

Late Binding UMLSağ tarftaki UML diagramında bir kalıtım yapısı bulunmakta. KISI ana sınıfından PERSONEL isimli yeni bir sınıf ve PERSONEL sınıfındanda da MUHENDIS ve TEKNISYEN olmak üzere iki farklı sınıf türetilmiştir. MUHENDIS ve TEKNISYEN bir PERSONEL'dir. PERSONEL ise bir KISI'dir türünde ifadelerin kurulabildiği her yerde kalıtımdan söz etmek mümkündür. Böylece bu nesnelerin arasında artık kalıtımı ilişkisi kurulmuş olur. PERSONEL sınıfı KISI sınıfında yer alan BenKimim isimli fonksiyonu override etmiş yani geçersiz kılmıştır. Bu fonksiyon için kendisi bir içerik oluşturmuştur. Aynı şekilde MUHENDIS ve TEKNISYEN sınıfları da kendi içeriklerini BenKimim fonksiyonu içerisine yerleştirmiştir. Sınıfların tanımlamalarını da aşağıda vermekteyim. Fazlası...

Hakkımda...

Cem KEFELİ

Electronics and
Telecommunication Eng.
devamı...


Son yapılan yorumlar...

Comment RSS

Yasal bir uyarı...

Disclaimer"Bu web sitesinde görmüş olduğunuz bilgilerin, dokümanların ve diğer materyallerin kullanılmasından doğabilecek hiç bir sorumluluktan site sahibi sorumlu tutulamaz. Web sitesi içerisinde yer alan yazılar, yorumlar, resimler ve diğer tüm içerikler yalnızca sahibinin görüşünü yansıtmakta olup içeriğin sahibi kişilerin çalıştığı kurumları bağlayıcı hiç bir nitelik taşımamaktadır. Yapılan tüm alıntılar mutlaka kaynak gösterilerek verilmeye çalışılmaktadır. Web sitesi içerisinde bulunan ilgili materyaller, ilgili yasal kurumlar tarafından uygun görülmemesi durumda kaldırılacaktır."
General