Understanding MQ Series bindings files

Question

Our Java app writes to MQ Series queues via a Weblogic JMS Message Bridge. The actual MQ Series connection/queue details are stored in the MQ Series .bindings file on the app server. I've never really got my head around the bindings file and what all the entries mean. Can anyone provide guidance to understand this file?

Answer 1

Before addressing the .bindings file, we need to step back a bit and look at JNDI - the Java Naming and Directory Interface - and how it is used by JMS. The Queue, Topic and various types of Connection Factory are all run-time JMS objects with methods and attributes. But you can pre-define them and store them in a registry where the JMS application can retrieve them using JNDI lookups.

This is helpful because the objects are like coins in that they have a JMS side and a provider-specific side. On the JMS side, any administered object looks about the same. Regardless of the underlying transport provider, a ConnectionFactory has the same methods and attributes. However, on the provider-specific side, the administered objects look very different from one transport provider to the next. For example, the ConnectionFactory used with a WebSphere MQ transport will have an attribute for the Queue Manager. No other transport provider has a "queue manager" so this attribute is only valid in a WMQ context.

The two aspects of administered objects are the "glue" that allows JMS to work independently of transport provider. In your code you just have to look up a ConnectionFactory and you get an object suitable to perform method calls against. Under the covers, the provider's JMS classes use the provider-specific object attributes to supply context to convert the generic JMS API calls into provider-specific calls. Thus the connection object that you instantiate results in a WMQ CONNECT call which specifies a QMgr name, host, port, channel and a variety of other parameters.

OK, I promised to get to the .bindings file. I said previously that the JNDI lookup was against "a registry" and that usually means LDAP or similar. But Sun engineered JNDI like JMS in that there is an API that your program uses and an SPI or Service Provider Interface that is used by the registry. So, although JNDI can be implemented in LDAP, there is nothing that says it must be implemented in LDAP. One of the base implementations that Sun provided right out of the box was to use the local filesystem as the registry. In this implementation, the root context is a file folder. Each context can store either another sub-context (another file folder) or object definitions. Typically there is one folder for the root context and all of the objects are defined at that level. The file that holds the object definitions is...you guessed it... the .bindings file.

The objects in the .bindings file are represented in Name/Type/Value triplets. So each .bindings file typically has many objects. Each object has many attributes. Each attribute has a name, a value and the type of variable that holds the value. The best way to get a handle on the .bindings file is to sort it which will put all the objects and their attributes together and make it more human-readable. For a list of possible properties, see the manual.

Of course, the .bindings file is supposed to be a compiled artifact and not intended to be human readable. IBM provides the JMSAdmin tool to generate and read the .bindings file. You can also use WMQ Explorer to manage the administered objects in a .bindings file. These are also discussed in the manual linked above. There is also a (some say) good tutorial in developerWorks here.