Çevrimdışı

İki farklı kurumda ya da iki farklı yerde çalışan projeler olduğunu düşünelim. Bu farklı yerlerdeki projeleri birbirleri ile nasıl haberleştireceğiz? İşte uzakta çalışan uygulamaları birbirleri ile haberleştirmek için teknolojiler geliştirilmiştir. Bunlardan biri web servisleri, bir diğeri RMI’dır. EJB ise Java dünyasında kullanılan bir diğer haberleşme teknolojisinin ismidir.
EJB çalışma mantığı :

Öncelikle amacımız istemci tarafından, sunucudaki EJB sınıfına erişmek. Bunun için istemci tarafında bir nesne oluşturulması gerekiyor. Oluşturulan nesnenin aynı isimdeki metodunu çağırmalıyız. O da gidip sunucudaki aynı isimdeki metodu çağıracak. İstemci tarafındaki EJB’ymiş gibi kullanılan nesneye proxy objesi adı veriliyor. Bu proxy objesini biz kendisi EJB’ymiş gibi kullanıyoruz. Uzaktan kullanılabilecek metot listesini içerisinde barındırıyor. Dolayısıyla istemci tarafında Remote interface’e ihtiyacımız var. Oluşturulan proxy objesinin tipi de bu remote interface tipinde oluyor.

Üç tane EJB bileşeni vardır :


Önemli : EJB kullanabilmek için uygulama sunucusunun mutlaka EJB Container’ı desteklemesi gerekir.

Stateless bean’ler, her istemci için yaratılan nesnenin bir havuzda saklanarak ihtiyaç duyulduğunda herhangi bir tanesini kullanmamızı sağlayan yapılardır. Stateful bean’lerde ise yapı tam ters şekildedir. Her bir istemcinin yaptığı her istek için bir instance oluşturulur. Dolayısıyla performans açısından sunucunun hafızası işgal edilmiş olur.

Stateless kullandığımızda sınıf değişkeni (global değişken) kullanmıyoruz. Çünkü istemci, her session bean istediğinde aynı bean instance’ına erişemeyebiliyor. Birden fazla istemciden gelen istekler aynı session bean tarafından yanıtlanabiliyor. Performans anlamında çok işimize yarıyor. Tüm istemciler için tek bir ejb instance’ı yaratılıyor. Herkes aynı nesneyi kullanıyor. Burada bean tek bir istemciye özel bilgi saklamıyor. Birçok istemcinin isteği aynı bean instance’ı tarafından cevaplanabiliyor. Bu da performans artırımı demek.

Bir session bean sınıfının stateless ya da stateful olduğunu annotation kullanarak söylüyoruz.

Genelde bir EJB çağırıyorsak peşinden de bir veri tabanı çağrımı yapılır. Çoğu projede bir veri tabanı kullanılıyor. Veri tabanı kullanmak, veri tabanına istek göndermek sıkıntılı bir işlem. SQL sorgularımızın yazıldığı katmanı, Connection’ın alındığı katmanı doğru yazmak, connection’ı açtıktan sonra kapatmayı unutmamak, aynı fonksiyonda iki farklı connection almamak gibi sıkıntılar var.

Bunun için EJB tarafında veri tabanına erişimi de kolay bir hale getirmek için frameworkler yazılmış. Bu frameworkler sayesinde veri tabanına connection açma, kapama işlemleri ile uğraşmadan erişip sorgu çekebiliyoruz. O kısımlar hazır kodlarla hallediliyor.

Entity bean’lerin çıkışı da yine bu amaçla olmuş. Veri tabanındaki her bir tablo için bir sınıf yaratıyoruz. Bu sınıflara entity bean deniyor.

5 tablomuz varsa, 5 tane bean yazılıyor. Tabloların özellikleri, ilişkileri bu sınıfların içerisinde tanımlanıyor.

Tablolarla uğraşırken tabloya karşılık gelen sınıfları istiyoruz. Muhattap olarak sadece sınıfları alıyoruz. Objelerle uğraşıyoruz. Bunun dışında veri tabanı ile ilgilenmiyoruz.

Entity bean’ler veri tabanına bağlanacak ama hangisi hangi connection bilgisi ile? Bunu da XML dosyasında tutuyoruz.

Message-driven bean’ler asenkron mesajlaşma için kullanılırlar. EJB’ler arasındaki haberleşmenin senkron olması gerekli değilse yani cevabını hemen beklemiyorsak asenkron haberleşmeyi kullanıyoruz. Mesajlarımızı bırakıyoruz bir ara okunuyor. Mesajların ne zaman okunacağı belli değil. Örneğin e-mail attık, karşı tarafın ne zaman okuyacağı bizi ilgilendirmiyor.

JMS API dediğimiz mesajlaşma servisi bir çok sınıf ve interface barındıran bir yapıdır.

Uygulama sunucusunun JMS’i desteklemesi için bazı ayarların yine sunucu tarafında yapılması gerekir.


[Üye Olmadan Linkleri Göremezsiniz. Üye Olmak için TIKLAYIN...]