Bundan önceki yazımda (EJB NEDİR? -1) EJB bileşeninin özellikleri ve bileşen (component) model konularına değinmiştim. Bu yazının bir devamı olan şimdiki makalede EJB’nin özelliklerini anlatmaya devam edeceğim ve soyut olan kavramlardan biraz daha somut olarak bahsedeceğim. En alt kısımda bu yazıda kullanılan tüm kısaltmaların açılımını görebilirsiniz.
Neden EJB’ye ihtiyaç duyuldu?
Birkaç başlık altında bu gereksinmeleri yazacak olursak:
- Bileşen modellerde bir standart oluşturmak
- Sunuş ile iş mantığını ayırma gereksinimi
- Sistemlerin dağıtıklaşması
- Nesneye dayalı programlama dili desteği
Bileşen model uygulama sunucu bağımsızlığını sağlar. Bu sayede herhangi bir geliştirici tarafından geliştirilen uygulamalar tüm J2EE uyumlu uygulama sunucularında çalışır.
Sunuş ile iş mantığının ayrılması çoklu istemci desteği sağlar. Böylece gerçekleştirdiğimiz uygulama şu anda sahip olduğumuz veya ileride sahip olacağımız tüm istemcilerle çalışabilme garantisi verir.
Sistemler dağıtıklaştıkça uygulamalar parçalara ayrıldı. J2EE platformu şu anda dört tane katmandan söz etmektedir. Bunlardan bir tanesi EJB katmanıdır. Bu katman farklı bir platformda tamamen iş mantığını gerçekleştirebileceği gibi diğer katmanlarla aynı platformda da çalışabilir.
Tam Java desteği EJB’yi diğer bileşen modellerden ayırır. Java geliştiricileri çok az bir efor sarfederek EJB geliştiricisi olabilirler. Böylelikle Java’nın tüm özelliklerinden ve gücünden yararlanabilirler.
Soket, RPC, Dağıtık Nesneler
İstemci/Sunucu sistemler ve TCP/IP yaygınlaşmaya başladığı zamanlarda programcılar soket programlamaya yöneldiler. Soket programlama en alt seviyede kullanılan ve veriyi doğrudan “byte stream” olarak alıp işleyecek bir mekanizma gerektiriyordu. Bu da programcıların zorlanmasına ve hata yapma olasılıklarının artmasına neden oluyordu. Belli bir süre sonra bu sisteme alternatif olarak RPC kullanılmaya başlandı. RPC’de soket programlamada alt seviyede gerçekleşen işlemlere karşı bir yordam (procedure) arayüzü oluşturuldu. Artık programcı “byte stream” alıp işlemek yerine doğrudan yordam çağırımı ile işini halledebilmekteydi. Tüm veri alışverişi alt kademede yine soketlerle gerçekleştiriliyordu, fakat programcı bu ayrıntılarla uğraşmıyordu. Programcıya büyük rahatlık sağlayan RPC, fonksiyonel diller (C, Cobol, vb.) için idealdi ama nesneye dayalı programlama dilleri (Java, C++, vs.) için yeterli değildi.
RPC uygulamalarında programcı bir yordama argümanlar gönderir, yordam da ürettiği sonucu geri döndürür. Bu basit yapı nesneye dayalı programlama dillerinde sadece statik metot çağrımına karşılık gelir ve bu dillerin diğer özelliklerinin atıl kalmasına neden olur. Nesnelerin dağıtık ortamlarda kullanılmasını sağlayan dağıtık nesne teknolojileri bu yüzden ortaya çıkmıştır.
Dağıtık nesneler üç parçadan oluşur.
1- İstemcide bulunan "stub" nesnesi
2- İstemci ile sunucu arasındaki iletişimi sağlayan protokol
3- Sunucuda bulunan "skeleton" nesnesi ve gerçek nesne
Basit bir dağıtık nesne uygulaması şöyle gerçekleştirilebilir:
Sunucu tarafından sağlanan isimlendirme (naming) servisiyle istemci aradığı nesnenin "stub" nesnesini ister. İstemcide bulunan "stub" nesnesi ile gerçekte iletişim kurmak istediğimiz nesne aynı arayüzü paylaştıkları için "stub" nesnesi gerçek nesnede bulunan bütün metodlara sahiptir. İstemci "stub" üzerinden bir metodu çağırır. Bu metodun ismi ve argümanları iletişim protokolü aracılığıyla "skeleton" nesnesine aktarılır. Sunucuda bulunan "skeleton" nesnesi aldığı metot ismini ve argümanları kullanarak gerçek nesne üzerinde metot çağırımını gerçekleştirir. Metot tarafından döndürülen sonuç "skeleton" nesnesi tarafından iletişim protokolü kullanılarak "stub" nesnesine döndürülür ve sonuç istemci tarafından kullanılır.
Dağıtık nesne teknolojilerine bir örnek CORBA’dır. CORBA standardına uygun ORB’lar istemci ile sunucu arasında bir omurga kurarak bu iki platformu birbirine bağlar ve sunucu taraftaki nesneleri isimlendirme (naming) servisiyle kullanıma açar.
Şekil-I:ORB-RPC farkı
*Resimde istemci tarafından bulunan nesneler gerçek nesneler değil, sunucu tarafındaki nesnelere ulaşmayı sağlayan vekil (proxy, stub vs.) nesnelerdir.
Yukarıda tipik bir istemci-sunucu etkileşimi görülmektedir. Şekil (a)’da istemci RPC’yi kullanarak sunucuda bulunan bir yordamı çağırmaktadır. Bu yaklaşım fonksiyonel dillerde geçerlidir. Şekil (b)’de ise çağırılan yordam her nesne için farklı sonuçlar üretir. Bunun nedeni nesnelerin verilerini kendi içlerinde barındırmalarıdır.EJB’nin Doğuşu
Şimdi EJB ve bileşen modelin nasıl ortaya çıktığına değinmek istiyorum. Burada üç tip sunucu taraflı platformdan bahsedebiliriz.
-TP (Transaction Processing) Monitörler
-ORB (Object Request Broker)
-CTM (Component Transaction Monitor)
Bu platformların amacı yazılan uygulamaların sunucu tarafında bir çevreye (environment) gömülmesini ve istemcinin bu uygulamalara rahatlıkla ulaşabilmesini sağlamaktır.
TP sistemler 1968 yılında ortaya çıkmaya başladı. Bilinen TP sistemler arasından CISC ve TUXEDO örnek verilebilir. Bu platformlarda çalışan uygulamalar Cobol gibi fonksiyonel dillerde yazılıyordu. TP monitörler güçlü sistemlerdi.Bu sistemlerin güçlü olmasının sebebi uygulamalara her türlü alt seviyeli servisleri (transaction, resource management vb.) sağlayabilmeleriydi. Bu servisler sayesinde uygulama geliştirici sadece çözmesi gereken problem üzerinde yoğunlaşıyor ve alt seviyeli işlemlerle uğraşmıyordu.TP monitörler uygulamaları çok iyi bir çevrede (environment) barındırabiliyorlardı. Sistemin dağıtıklığı ise RPC ile sağlanıyordu. RPC belli bir zaman sonra yetersiz kalmaya başladı çünkü uygulama geliştiriminde kullanılan Cobol, C gibi diller yerlerini Java, C++, Smalltalk gibi nesneye dayalı dillere bıraktı. Artık TP Monitörlerin kullandığı RPC yerine yeni bir teknoloji kullanılması gerekiyordu. Bunun sonucunda OMG CORBA standardını yazılımcılara sundu ve bu standarda uygun ORB’lar piyasaya çıkmaya başladı.
ORB'la anılan bir diğer kavram da dağıtık nesneler kavramıdır. ORB ile TP’nin temel farkı TP’nin uzaktan erişimi yordam tabanlı (procedure based) RPC ile yapmasıdır. (Bkz. Şekil-I) ORB’da ise çağırım (call) statik bir yordama değil de bir nesnenin metoduna yapılır. Her nesnenin kendine ait bir kimliği olduğu için her bir objeye yapılan metot çağrımı RPC’nin aksine farklı sonuçlar verebilir. Fakat ORB programcıya TP'nin sağladığı alt seviyeli servisleri sağlamaz. Bunların yazılımını programcıya bırakır. Sadece nesnelerin dağıtık bir şekilde iletişimini sağlayan bir omurga (backbone) tanımlar.
Yukarıdan da anlaşılacağı gibi iki platformda da eksiklikler vardır. Bu eksiklikleri ise CTM’ler ortadan kaldırır. CTM bir çeşit ORB-TP karışımıdır. ORB’nin dağıtık nesne yapısıyla TP’nin sağladığı servisleri bir araya getirerek daha geniş ve kapsamlı bir platform ortaya çıkartır. Günümüz uygulama sunucuları CTM’ye örnek teşkil eder. CTM’nin üç temel özelliği vardır.
- Dağıtık nesneler (RMI, RMI-IIOP, DCOM, CORBA)
- Sunucu taraflı platform (J2EE uygulama sunucuları, MTS)
- Bileşen model (EJB, COM)
İlk CTM’lerden birisi MTS’dir. MTS dağıtık nesne altyapısı olarak DCOM’u kullanır. Bileşen modeli ise COM’dur. MTS Microsoft’un tescilli ürünü olduğu için sadece Microsoft’un kendi platformunda çalışmaktaydı. Bu durum da müşterilerin Microsoft’a bağımlı olmasını gerektiriyordu. Bu sıralarda diğer şirketler de kendi CTM’lerini piyasaya sürmeye başladılar. Bu sistemlerin çoğunun ortak özelliği CORBA’yı kullanmalarıydı, ama kullandıkları bileşen modeller farklıydı. Bu yüzden bir platformda çalışan bir uygulama diğer platformda çalışmıyordu.
EJB Doğdu
1997 yılında Sun Microsystems sunucu taraflı bileşenler için bir standard olan Enterprise JavaBeans’i geliştirdi. Sun şirketinin diğer yazılım şirketleriyle ortak çalışma stratejisi ve açık standartlara önem vermesi EJB’nin hızla yayılmasına ve gelişmesine olanak sağladı. Bu bileşen model CTM satıcıları tarafından benimsendi ve uygulanmaya başlandı.
Burada bahsettiğimiz CTM ifadesi günümüzde uygulama sunucusu olarak kullanılmaktadır. EJB şu anda piyasada bulunan uygulama sunucularının beyni olarak ifade edilebilir. Tüm iş mantığı EJB bileşenleriyle birlikte uygulama sunucularına gömülerek 7x24 çalışan sunucularda binlerce istemciye servis sağlayabilmektedir.
EJB aslında J2EE platformunun bir parçasıdır. J2EE uygulama geliştiricilere kompleks bir sunucu taraflı ortam sağlar. Yazılımcılar kendilerine sağlanan J2EE API’lerini kullanarak yazılımları hızlı ve kolay bir şekilde gerçekleştirebilirler ve J2EE uyumlu uygulama sunucularına gömebilirler.
Kısaltmalar
CORBA: Common Object Request Broker Architecture
CTM: Component Transaction Monitor
DCOM: Distributed Component Object Model
IIOP: Internet Inter-ORB Protocol
MTS: Microsoft Transaction Server
OMG: Object Management Group
OTM: Object Transaction Monitor
RMI: Remote Method Invocation
RPC: Remote Procedure Call
TP: Transaction Processing
Kaynaklar
1-Monson-Haefel, R.; ”Enterprise JavaBeans”, 2nd Edition, O’Reilly & Associates, Inc., 2000
2-Orfali, R.; Harkey, D.; “Client/Server Programming with Java and CORBA”; JOHN WILEY & SONS, INC.; 2nd Edition; 1998
3-RMI Specification; http://java.sun.com/j2se/1.3/docs/guide/rmi/spec/rmiTOC.html
Mesut ÇELİK
Hiç yorum yok:
Yorum Gönder