Java uygulamamız bir Weblogic JMS Message Bridge aracılığıyla MQ Series kuyruklarına yazıyor. Gerçek MQ Serisi bağlantı/kuyruk detayları uygulama sunucusundaki MQ Series .bindings dosyasında saklanır. Kafamı hiçbir zaman bağlama dosyalarının etrafına almamıştım ve bütün kayıtların anlamı ne? Bu dosyayı anlamak için herhangi bir rehberlik sağlayabilir mi? Java İsimlendirme ve Dizin Arabirimi - -MQ Serisi bağlama dosyalarını anlama
.bindings dosyasını ele almadan önce, biz geri biraz adım ve JNDI bakmak gerekir ve JMS tarafından nasıl kullanılır. Sıra, Konu ve çeşitli Bağlantı Fabrikası türleri, tüm çalışma zamanı JMS nesneleri ve özniteliklerine sahip nesnelerdir. Ancak bunları önceden tanımlayabilir ve JMS uygulamasının JNDI aramalarını kullanarak alabileceği bir kayıt defterinde saklayabilirsiniz.
Nesneler, JMS tarafına ve sağlayıcıya özgü bir tarafa sahip oldukları için bozuk paralar olduğu için bu yararlıdır. JMS tarafında, yönetilen herhangi bir nesne aynı görünüyor. Altta yatan nakliye sağlayıcısından bağımsız olarak, bir ConnectionFactory aynı metot ve özelliklere sahiptir. Ancak, sağlayıcıya özgü tarafta, yönetilen nesneler bir aktarım sağlayıcısından diğerine çok farklı görünmektedir. Örneğin, bir WebSphere MQ aktarımı ile kullanılan ConnectionFactory, Kuyruk Yöneticisi için bir özniteliğe sahip olacaktır. Başka hiçbir aktarım sağlayıcısının "kuyruk yöneticisi" özelliği yoktur, bu nedenle bu özellik yalnızca bir WMQ bağlamında geçerlidir.
Uygulanan nesnelerin iki yönü, JMS'nin aktarım sağlayıcısından bağımsız olarak çalışmasına izin veren "yapıştırıcı" dır. Kodunuzda sadece bir ConnectionFactory'a bakmak zorundasınız ve metot çağrılarını gerçekleştirmeye uygun bir nesneyiniz olsun. Kapakların altında, sağlayıcının JMS sınıfları, jenerik JMS API çağrılarını sağlayıcıya özgü çağrılara dönüştürmek için içerik sağlamak için sağlayıcıya özgü nesne özelliklerini kullanır. Böylece, başlattığınız bağlantı nesnesi, bir QMgr adı, ana bilgisayar, bağlantı noktası, kanal ve diğer çeşitli parametreleri belirten bir WMQ CONNECT çağrısıyla sonuçlanır.
Tamam, .bindings dosyasına ulaşmaya söz verdim. Daha önce JNDI aramalarının "bir kayıt defterine" karşı olduğunu ve genellikle LDAP veya benzerlerini ifade ettiğini söyledim. Ancak Sun, JMS gibi JNDI'yi çalıştırarak programınızın kullandığı bir API ve kayıt defteri tarafından kullanılan bir SPI veya Hizmet Sağlayıcı Arayüzü var. Dolayısıyla, JNDI , LDAP'de uygulanabilmesine rağmen, , LDAP'de'un uygulanması gerektiğini söyleyen hiçbir şey yoktur. Sun'ın kutudan çıkardığı temel uygulamalardan biri, yerel dosya sistemini kayıt defteri olarak kullanmaktı. Bu uygulamada, kök bağlam bir dosya klasörüdür. Her içerik başka bir alt bağlam (başka bir dosya klasörü) veya nesne tanımlarını saklayabilir. Genellikle, kök bağlam için bir klasör vardır ve tüm nesneler bu düzeyde tanımlanır. Nesne tanımlarını tutan dosya ... siz tahmin ettiniz ... .bindings dosyası.
.bindings dosyasındaki nesneler Ad/Tür/Değer üçüzlerinde temsil edilir. Yani her .bindings dosyasının genellikle birçok nesnesi vardır. Her nesnenin birçok özelliği vardır. Her özelliğin bir adı, değeri ve değeri tutan değişken türü vardır. .bindings dosyasında bir tanıtımı elde etmenin en iyi yolu, tüm nesneleri ve niteliklerini bir araya getirip daha fazla insan tarafından okunabilir hale getirecek şekilde sıralamaktır. Olası özelliklerin listesi için bkz. the manual. Tabii
, .bindings dosyası derlenmiş eser olması gerekiyordu ve okunabilir insan olmanın tasarlanmamıştır. IBM, .bindings dosyasını oluşturmak ve okumak için JMSAdmin aracını sağlar. Bir .bindings dosyasında yönetilen nesneleri yönetmek için WMQ Explorer'ı da kullanabilirsiniz. Bunlar ayrıca yukarıda bağlantılı manüelde de tartışılmaktadır. Ayrıca developerWorks here'da iyi dersler de bulunmaktadır.