Her mesajlaşma uygulaması için konfigure edilen iki tip yönetim objesi vardır.
- Destinations
- Connection Factories
Destinations denilen yapılar mesajları almak, tutmak ve yönlendirmek için kullanılırlar. Queue ve Topic Destination’lar olmak üzere ikiye ayrılırlar.
- Queue Destination : Point-to-Point mesajlaşma protokolü
- Topic Destination : Yayınla-al mesajlaşma protokolü
İstemci Queue’ya erişebilecek bir Connection sınıfı üzerinden bu Queue’ya erişebilir. Yani direk erişemez. Queue’ya erişmek için bu Connection sınıfını kullanıp session oluşturulur. Session üzerinden Queue’ya bağlanılır. Bu bağlantı sınıfına “connection factory” denir. Connection Factory uygulama sunucusu üzerinde tanımlanır.
İstemci tarafı Queue’ya erişebilsin diye Connection Factory oluşturulur.
Connection factory’ler JMS API Client tarafından JMS API Destination’a bağlanmak için kullanılır. İki kategoriye ayrılırlar.
- Queue Connection Factories
- Topic Connection Factories
İstemcilerin Mesaj Göndermesi :
İstemcileri mesaj gönderen uygulamalar olarak düşünebilirsiniz. Gönderilen mesajlar senkron ya da asenkon olabilir. Yani mesaj gönderildikten sonra cevabın ne zaman döneceği belli olmayabilir. Senkron mesajlarda gönderilen mesajın cevabı beklenir.
Mesajlar :
Uygulamaya ait bilgileri sarmalamaya yarayan objelerdir. Mesajın 3 parçası vardır.
- Header : Mesajı tanımlamak ve yönlendirmek için bilgi barındırır.
- Properties : Mesajları sınıflandırmak için kullanılır. Isim/değer tutulur. Mesajlar özelliklerine göre filtrelenebilir.
- Body : Mesajın içeriği bulunur.
5 adet mesaj tipi vardır. Sunucudaki queue ya da topic yapılarına bu beş tipte mesajdan ihtiyaca göre bir tanesi gönderilebilir.
Point-to-point Mesajlaşma (Queue) :
Bir mesaj kuyruğu (queue), mesajların tamamı tükenene kadar saklar. Queue ve topic arasındaki en büyük fark, Queue yapısında tek bir mesaj kullanıcısının olmasıdır. Mesajı gönderen ve alan arasında zaman anlamında bir bağımlılık yoktur. Queue’ya gönderilen tüm mesajlar alıcının yaratılmasından önce bile gönderilmiş olsalar sonradan alınabilirler.
Bir tüketici kuyruktan bir mesajı aldıktan sonra aynı mesaj başka birisi tarafından kullanılamaz.
Publish/Subscribe Mesajlaşma (Topic) :
Bir Topic’in birden fazla kullanıcısı olabilir. Mesajı üreten istemci mesajları Topic’e gönderir. Topic mesajların tamamı kullanıcılara dağıtılana kadar hepsini saklar. Burada iki taraf arasında zaman bağımlılığı vardır. Mesaj alacak kişiler, Topic’e kayıt olmadan ya da inaktif durumdayken mesaj alamazlar.
EJB bileşenleri (entity, session, message-driven beans) ile mesaj göndermek mümkün olabilir. Yalnız JMS API’nin ihtiyaç duyduğu metotların yazılması gerekir.
Senkron mesaj kullanıcıları sunucuyu bloke edip bağladıkları için session, entity ve message-driven bean’ler ile senkron mesaj göndermek sakıncalıdır.
Message-driven bean’ler
MessageListener interface’ini implement ederler. Yani asenkron mesajlaşma için kullanılırlar. MessageListener arayüzünde tanımı yapılmış
onMessage() metodunu override ederler. Container’a MessageListener kullanıldığının bir şekilde söylenmesi gerekiyor. Bunu da message-driven bean’lerin başında
@MessageDriven annotation‘ı ile ifade ediyoruz.
MDB’lerin local ya da remote interface’leri olmaz. MDB’ler Java EE bileşenleri ile direk olarak haberleşmezler. Önce mesajı queue ya da topic yapısına gönderirler. Container’lar mesajları göndermek için havuz kullanabilirler ki çoğu zaman kullanırlar.
Container MDB instance’ı yaratırken newInstance() adındaki metodu otomatik olarak çağırır. Instance yaratıldıkdan sonra çalışacak olan metot PostConstruct metodudur. (Bu metotları annotationlarla belirliyorduk.) Daha sonra Container beani havuza ekler. Bean daha sonra listener metodunun çağrılmasını bekler. Mesaj eklendikçe listener metodu çalışır.
- MDB’ler public tanımlanır ve aynı diğer beanler gibi final ya da abstract olmaz.
- Class tanımının başında @MessageDriven annotation’ı olur.
- mappedName özelliği ile MDB uygulama sunucusunda tanımlanmış olan destination’lara JNDI ismiyle bağlanır.
- finallize() metotları olmaz.
- Bean içerisinde event handler metotları tanımlanabilir. Eskiden bu metotları override etmek zorunluydu şimdi bean instance’ı yaratılmadan önce ve sonra eventler oluşuyor. İstersek PostConstruct ve PreDestroy metotlarını yazabiliyoruz. Aynı diğer bean sınıflarındaki gibi herhangi bir isimde void bir metot tanımlanıyor. Bu metot parametre almıyor. Herhangi bir modifier alabiliyor ama uygulamaya özel exception fırlatmaması gerekiyor. Runtime exception’lar önemli değil. Tanımlarının başına da @PostConstruct ya da @PreDestroy yazıyoruz.
EJB’ler arasındaki haberleşmenin senkron olması gerekli değilse yani cevabını hemen beklemiyorsak asenkron haberleşmeyi kullanıyoruz. Ne zaman okunacağı bizim için önemli olmadığında MDB kullanıyoruz. Mesajlarımızı bırakıyoruz bir ara okunuyor.
javauzmani 