IRC ve mIRC Kullanıcılarının Buluşma Noktası
  Mobil Sohbet, Sohbet ve Sohbet Odaları




Yeni Konu aç Cevapla
 
LinkBack Seçenekler Stil
Alt 27 Nisan 2012, 13:19   #1
Çevrimdışı
EJB – Enterprise Java Beans




İ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 :

Kod:   Kodu kopyalamak için üzerine çift tıklayın!
1- Session Beans > Stateless Session Beans > Stateful Session Beans 2- Entity Beans 3- Message Driven Beans

Ö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’le
r 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...]
İ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 :

Kod:   Kodu kopyalamak için üzerine çift tıklayın!
1- Session Beans > Stateless Session Beans > Stateful Session Beans 2- Entity Beans 3- Message Driven Beans

Ö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’le
r 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...]
  Alıntı ile Cevapla

IRCForumlari.NET Reklamlar
radyo44.com.tr
Cevapla

Etiketler
beans, ejb, enterprise, java, kodlapaylas.com, –

Seçenekler
Stil

Yetkileriniz
Konu Acma Yetkiniz Yok
Cevap Yazma Yetkiniz Yok
Eklenti Yükleme Yetkiniz Yok
Mesajınızı Değiştirme Yetkiniz Yok

BB code is Açık
Smileler Açık
[IMG] Kodları Açık
HTML-Kodu Kapalı
Trackbacks are Kapalı
Pingbacks are Açık
Refbacks are Açık


Benzer Konular
Konu Konuyu Başlatan Forum Cevaplar Son Mesaj
Java Swing/AWT | FX Fonzerelli Java 3 21 Temmuz 2012 19:16
JRE (Java Runtime Engine - Java Çalışma Zamanı Motoru) toXic Java 2 18 Aralık 2011 13:40
Sorun söyleyeyim (Java,JSP,ASP.NET(C#),PL/SQL,jQuery,Java Script,Ajax) J2EE123 Java 2 03 Kasım 2011 12:57
JRE (Java Runtime Engine - Java Çalışma Zamanı Motoru) Stealth Java 1 29 Eylül 2010 22:19