Ứng dụng Java của chúng tôi ghi vào hàng đợi MQ Series thông qua một cây cầu thông báo JMS Weblogic. Chi tiết kết nối/hàng đợi MQ Series thực tế được lưu trữ trong tệp MQ Series .bindings trên máy chủ ứng dụng. Tôi đã không bao giờ thực sự có đầu của tôi xung quanh tập tin ràng buộc và những gì tất cả các mục có ý nghĩa. Bất cứ ai có thể cung cấp hướng dẫn để hiểu tập tin này?Tìm hiểu các tệp ràng buộc MQ Series
Trước khi giải quyết tệp .bindings, chúng ta cần lùi lại một chút và xem JNDI - Giao diện đặt tên và thư mục Java - và cách nó được JMS sử dụng. Hàng đợi, Chủ đề và các loại Nhà máy kết nối khác nhau đều là các đối tượng JMS thời gian chạy với các phương thức và thuộc tính. Nhưng bạn có thể xác định trước chúng và lưu trữ chúng trong một cơ quan đăng ký nơi ứng dụng JMS có thể lấy chúng bằng cách sử dụng các tra cứu JNDI.
Điều này rất hữu ích vì các đối tượng giống như tiền kim loại ở chỗ chúng có mặt JMS và bên dành riêng cho nhà cung cấp. Về phía JMS, mọi đối tượng được quản lý đều trông giống nhau. Bất kể nhà cung cấp dịch vụ vận tải nằm bên dưới, ConnectionFactory có cùng các phương thức và thuộc tính. Tuy nhiên, về phía nhà cung cấp cụ thể, các đối tượng quản lý trông rất khác nhau từ một nhà cung cấp vận chuyển đến tiếp theo. Ví dụ, ConnectionFactory được sử dụng với một vận tải WebSphere MQ sẽ có một thuộc tính cho Trình quản lý hàng đợi. Không có nhà cung cấp dịch vụ vận tải nào khác có "người quản lý hàng đợi" để thuộc tính này chỉ hợp lệ trong ngữ cảnh WMQ.
Hai khía cạnh của đối tượng được quản lý là "keo" cho phép JMS hoạt động độc lập với nhà cung cấp dịch vụ vận tải. Trong mã của bạn, bạn chỉ cần tìm một ConnectionFactory và bạn nhận được một đối tượng phù hợp để thực hiện các cuộc gọi phương thức. Trong phần giới thiệu, các lớp JMS của nhà cung cấp sử dụng các thuộc tính đối tượng cụ thể của nhà cung cấp để cung cấp ngữ cảnh để chuyển đổi các cuộc gọi API JMS chung thành các cuộc gọi của nhà cung cấp cụ thể. Do đó đối tượng kết nối mà bạn khởi tạo kết quả trong một cuộc gọi WMQ CONNECT chỉ định tên QMgr, máy chủ, cổng, kênh và một loạt các tham số khác.
OK, tôi đã hứa sẽ truy cập tệp .bindings. Tôi đã nói trước đây rằng tra cứu JNDI đã chống lại "một đăng ký" và thường có nghĩa là LDAP hoặc tương tự. Nhưng Sun đã thiết kế JNDI như JMS ở chỗ có một API mà chương trình của bạn sử dụng và một SPI hoặc Giao diện nhà cung cấp dịch vụ được sử dụng bởi cơ quan đăng ký. Vì vậy, mặc dù JNDI có thể được triển khai trong LDAP, không có gì có nghĩa là phải được triển khai trong LDAP. Một trong những triển khai cơ bản mà Sun cung cấp ngay trên hộp là sử dụng hệ thống tệp cục bộ làm sổ đăng ký. Trong triển khai này, ngữ cảnh gốc là một thư mục tệp. Mỗi ngữ cảnh có thể lưu trữ một ngữ cảnh phụ khác (một thư mục tệp khác) hoặc các định nghĩa đối tượng. Thông thường có một thư mục cho bối cảnh gốc và tất cả các đối tượng được xác định ở cấp đó. Tệp chứa các định nghĩa đối tượng là ... bạn đoán nó ... tệp .bindings.
Các đối tượng trong tệp .bindings được thể hiện trong Tên/Loại/Giá trị ba. Vì vậy, mỗi tệp .bindings thường có nhiều đối tượng. Mỗi đối tượng có nhiều thuộc tính. Mỗi thuộc tính có một tên, một giá trị và kiểu biến chứa giá trị. Cách tốt nhất để có được một xử lý trên các tập tin .bindings là để sắp xếp nó mà sẽ đặt tất cả các đối tượng và các thuộc tính của họ với nhau và làm cho nó dễ đọc hơn. Để biết danh sách các thuộc tính có thể, hãy xem the manual.
Tất nhiên, tệp .bindings được cho là một tạo phẩm được biên dịch và không có ý định là người có thể đọc được. IBM cung cấp công cụ JMSAdmin để tạo và đọc tệp .bindings. Bạn cũng có thể sử dụng WMQ Explorer để quản lý các đối tượng được quản lý trong tệp .bindings. Chúng cũng được thảo luận trong sách hướng dẫn được liên kết ở trên. Ngoài ra còn có một hướng dẫn tốt (một số nói) trong developerWorks here.