MQ

MQ

Join this online group to communicate across IBM product users and experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only

  • 1.  JMS .bindings file

    Posted Tue December 01, 2020 11:20 AM
    I have a running MQ server and need to create a bindings file for a new client connection that is using JMS.  This is our first time using a JMS client connection.  Our other clients are NodeJS using either AMQP or IBM MQI.  I have a few questions.
    • What is the purpose of the .bindings file?  Is this needed only for client, or for both client and server?
    • Does any of the configuration on the existing MQ server need to be changed or updated for this?
    • Is there a good site that documents the steps for creating this file from command line on Linux MQ installation? 
    • Is there a sample .bindings file that I can simply edit with existing server info to provide to clients?  
    Thanks,
    Jim

    ------------------------------
    Jim Creasman
    ------------------------------


  • 2.  RE: JMS .bindings file

    Posted Tue December 01, 2020 08:11 PM
    BTW, meant to add that the .bindings file is intended for establishing a JMS connection to an MQ topic (not queue).  Most of the examples seem to show how to connect with a queue, instead.

    ------------------------------
    Jim Creasman
    ------------------------------

    Original Message


  • 3.  RE: JMS .bindings file

    Posted Wed December 02, 2020 03:11 AM
    Hi Jim,

    The .bindings file is only needed if you are going to look up MQ JMS objects from JNDI. You can programmatically configure MQ JMS too. The benefit of using JNDI is that you separate your code from the configuration, making it easier to change which queue manager, or queues you use.

    To answer your questions:

    Q1) What is the purpose of the .bindings file?  Is this needed only for client, or for both client and server?
    A1) As mentioned above the .bindings file is used to contain information on connection factories, queues and topics configuration which can be read from a file based JNDI repository. This sort of JNDI repository is based on a series of .bindings files in a directory structure. JNDI doesn't have to be used with JMS at all, but can give flexibility. The file can be used to hold information on connection factories that connect in either bindings or client mode. The file is configured using JMSAdmin - lots of details here: https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.1.0/com.ibm.mq.con.doc/q123270_.htm
    Note that other JNDI repositories are possible and they don't use a .bindings file. For example there is a generic LDAP repository and app servers such as WebSphere Application Server have their own JNDI repository support too.

    Q2) Does any of the configuration on the existing MQ server need to be changed or updated for this?
    A2) The .bindings file isn't used by the queue manager, and nothing needs to be changed there. Obviously the channel information you enter into the JMSAdmin tool must match what's defined on the queue manager, just like the JMS queues need to map to real queues on the queue manager.

    Q3) Is there a good site that documents the steps for creating this file from command line on Linux MQ installation?
    A3) Hopefully the link in A2 helps with this.

    Q4) Is there a sample .bindings file that I can simply edit with existing server info to provide to clients?  
    A4) I'm not aware of one, but they are easy to create using the JMSAdmin tool

    Regards, Matt.
    Matt Leming
    Architect, IBM MQ for z/OS

    Email: lemingma@uk.ibm.com
     
     



    Original Message


  • 4.  RE: JMS .bindings file

    Posted Wed December 02, 2020 03:34 AM
    Hi Jim,

    a .bindings file is a source of information for JNDI. JNDI is a Java Directory Interface which provides an API for getting information from a standard place in a standard way via a standardized API. It is needed for both client and server bindings to the QM by the Java JMS application.

    The queue manager generally doesn't need special configuration for JMS connections. You just need the normal permissions, and channels if there's a client connecting.

    There are a couple of JNDI providers available, but the classic one which uses a ,bindings file is the Sun Reference File System JNDI Provider.

    IBM Provides several tools which can be used to create content in a JNDI directory using the API. If you configure these tools to use the SunFSRefAPI implementation they will create a .bindings file for you.

    I strongly recommend this approach over trying to use a text file editor to modify a .bindings file.

    The .bindings file (or other JNDI data source) generally provides 2 different types of information. First, it provides the Connection Factory information. This can be for client or server bindings.

    Then it provides destination information. Destinations can be either queues or topics. JMS doesn't care quite as much as MQ does about the distinction.

    There is a command line JMSAdmin tool. You have to configure it using a config file before it will run effectively. The provider class and information on the base directory (that will contain the .bindings file) have to be configured in the file. There's a pretty good write up for JMSAdmin usage at https://www.ibm.com/support/pages/detailed-example-running-jmsadmin-mq-71-75-and-80-unix. It's a bit out of date from a version perspective, but I think it all still applies.

    The manuals link for newer versions is: https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.2.0/com.ibm.mq.con.doc/q123270_.html

    On my system, JMSAdmin is at path /opt/mqm/java/bin/JMSAdmin.

    The default provider in the JMSAdmin.config file is now the file system provider, which makes like easier. That wasn't always the case. You will have to changed the default file location in the PROVIDER_URL though.

    Once you have the JMSAdmin tool running, you can create a connection factory and then some destinations. JMS Connection Factories map to MQ queue managers (basically) and provide information on how to connect. JMS destinations map onto MQ Queues or Topics.

    Good luck with it.

    Regards,

    ------------------------------
    Neil Casey
    Senior Consultant
    Syntegrity Solutions
    Melbourne, Victoria
    IBM Champion (Cloud) 2019-20
    +61 (0) 414 615 334
    ------------------------------

    Original Message


  • 5.  RE: JMS .bindings file

    Posted Wed December 02, 2020 02:47 PM
    Matt & Neal,

         Thanks for your replies.  I understand this much better now.  Following the info provided I was able to successfully create a .bindings file for our client connection.  I do find it interesting in that you only need host, port, topic and qmgr to set up the connection.  However, the bindings file that gets generated for our simple case (subscription to a single topic) is about 450 lines long!

    Jim

    ------------------------------
    Jim Creasman
    ------------------------------

    Original Message


  • 6.  RE: JMS .bindings file

    Posted Wed December 02, 2020 06:05 PM
    Hi Jim,

    congratulations on getting JMS working.

    You now understand why I recommended using the tool rather than trying to edit a sample .bindings file.

    I suspect that the .bindings file is produced by dumping an internal hash table into a text format, and because the hash table will have all the default values embedded into it, all of that comes out into the .bindings file.

    I've always found the ordering of information in the .bindings file to have no apparently logical structure, which is why I suspect it is a dump in sequential order of a hash table.

    Regards,


    ------------------------------
    Neil Casey
    Senior Consultant
    Syntegrity Solutions
    Melbourne, Victoria
    IBM Champion (Cloud) 2019-20
    +61 (0) 414 615 334
    ------------------------------

    Original Message


  • 7.  RE: JMS .bindings file

    Posted Thu December 03, 2020 03:04 AM
    Hi Jim,

    Yes they are quite large. Every property of each object gets serialised, including the defaults, and each property takes up three lines so the file gets large quickly!

    Regards, Matt.
    Matt Leming
    Architect, IBM MQ for z/OS

    Email: lemingma@uk.ibm.com
     
     



    Original Message


Related Content