Weblogic - J2EE

Eskiden BEA firmasının olan, Oracle'ın yeni silahı... Application Server'ların arasında en iyisi olarak gösterilmekte. Üzerinde çeşitli uygulamaların çalışmasına olanak veren bir Java uygulamasıdır en basit ifadeyle.

Dışarıdan baktığınızda tek bir process olarak görürsünüz ama içinde birçok uygulama barındırır.
Şimdi önce şu soruyu soralım kendimize: bir bilgiyi kendinde değil de, bir veritabanında tutmak istersem ne olur? Bilgiyi üzerimde tutsam, istek geldiğinde direkt veririm. Ama veritabanındaysa bilgi, birçok teknik detay gerekecek. Yani bir standartizasyon sorunu belirecek. Bu sorunu ortadan kaldırmak için J2EE standartları ortaya çıkmış. Şirket olarak bu standartın üzerine çıkabilirsiniz ama en azından bunları sağlamakla yükümlüsünüzdür.


Diyelim ki müşteriden istek geldi ve bize maç sonucunu sordu. Ama sen, application server olarak, bunu senin yerine başka biri yapsın istiyorsun. Tam tabiriyle herkese "iş çakmak" esastır. :) Veritabanına gitmesi için JDBC kullanıyorsun. Bu görevlendirme, az önce bahsettiğim, J2EE standardıdır. Yoksa bu işi kendin de yapabilirsin. JDBC'ye, Beşiktaş - Sarıyer maçının skorunu getir diyorsun. O da getiriyor. Sen de bunu göstermek için bir sayfa ayarlıyorsun ve skoru gösteriyorsun.
Ama sayfayı neden sen yapıyorsun? Onu da başkasına itelemek lazım. :) Bu iş için de, yine J2EE  standatı gereği, JSP'yi görevlendiriyorsun. JSP'ye, JDBC'nin getirdiği bilgiyi alıp sayfalamasını söylüyorsun.
Peki ama bunların bilgiyi getirtmesiyle neden uğraşıyorsun? Bir istek geldiğinde, birine o isteği ver. Kim ne yapar, nasıl yapar ilgilenme. İşte EJB de tam da bunun için var.
Ancak bunların nerede olduğunu, adresini bilmen lazım ki JNDI da bu iş için emrinize amade. :)

Yani en baştan kısaca toparlamak gerekirse.. :) İstek size geldi. Bu işi yapacak EJB'nin adını biliyorsunuz, tanıyorsun ama adresini bilmiyorsunuz. JNDI'dan adresini alıyorsunuz(JNDI'ı katalog gibi düşünebilirsiniz). İşi EJB'ye verdik. O da ilgili JDBC adresi için, JNDI'ın kapısını çalar ve o da JDBC'ye işi verir.

Buraya kadar tamam isek, şu soruyu soralım: istek direkt gelebiliyor mu? Tabi ki hayır. JAAS isimli bir diğer bileşen de güvenlik işlerini yürütmekte. İstek authenticator'a gidiyor. Authenticator da token var mı diye elinde bakar. Yoksa login gibi bir güvenlik işlemine yönlendiriyor. Login olunca, isteğin artık bir token'ı oluyor. Authenticator'a tekrar gidiyor ve bu kez içeri giriyor ve isteği size iletebiliyor.

Daha çok kavram var ama kısaca mimarisinden de bahsedeyim. Clientı en üstte düşünecek olur isek, arada DMZ bölgesi vardır(kimseye ait olmayan bölgedir bu; production ortamında clienttan korumak içindir). Araya web server da konabilir. Bu ilk kısma web katmanı denmekte. Akabinde, application server'ların bulunduğu App Server katmanı var. En altta da backend katmanı(db'nin olduğu) bulunmakta. Yani güvenlik amacıyla 3 katmanlı bir mimari tasarlanmış oldu. Application server birden fazla olabilir. Ama bunun için web server'ın sayısını da arttırmanız lazım. Tabi web server sayısı artınca, client'ın nereye gideceğini bilebilmesi için Load Balancer'ı da client'ın peşine yerleştirmeniz gerekir. :) Bunlar uzar gider. :)

Domain, proxy gibi kavramlar da var ama onlara belki diğer yazımda girerim, şimdilik bu yeterli.

Görüşürüz birazdan.