I use WebSphere MQ 7.0, followed necessary steps and configured it. Can I use same .binding file in another WebSphere MQ ?
WebSphere MQ\java\bin\JMSAdmin.config entries as below
INITIAL_CONTEXT_FACTORY=com.sun.jndi.fscontext.RefFSContextFactory
PROVIDER_URL=file:/C:/JNDI-Directory
The .bindings file is the backing store for the FileSystem JNDI provider. You would typically conenct the JMS based applications to this to load the Connection Factories and Destinations.
A single JNDI store can hold multiple objects and they don't all have to represent connections to a single Queuemanager.
So if you're asking do I need another JNDI store for another queuemanager, no not necessarily.
Related
Can you please let me know when to use .bindings file and when to use jndi properties file?
The .bindings file is created by the JNDI FileSystem context (com.sun.jndi.fscontext.RefFSContextFactory) when data is stored by the MQ JMSAdmin tool or other JNDI tool. It contains a representation of the JNDI data, for example your Connection Factory settings such as hostname, port, etc.
In the case of MQ, the .bindings file is not used directly by MQ code, it is used by the JNDI code to create the MQ JMS objects which are then returned to the application.
The JNDI properties file (or the JMSAdmin.config file if you're using JMSAdmin) stores the connection settings to allow the JNDI code to connect to the JNDI repository (for example, the FileSystem context, LDAP server etc.). It does not contain data such as Connection Factory settings.
I want high level steps to connect to remote JMS Provider.
I have some client application which wants to lookup in JNDI on FileSystem based to get the connection factory for JMS provider.
I understand that in JMS Administeration (MQ Explorer), we can create the Connection factories. This is creating .bindings file.How can I use this .bindings file into my client application system?
Should the Client Application system contain the JMS Administerator to create the .bindings in the same system or .bindings alone should be imported to the client system?
If Filesystem is used,then a path specifying the .binding is given as Provider url. This provider url (EG: F:/JMS) seems to be the path present in JMS Provider system.If .bindings file imported in client system, then how the client can recognise the path of .bindings file?
And What is the purpose of having ServerConnection channel in the Connection Factories definition when MQClient mode is used?When the JMS client connects through JNDI bindings, why Server Connection channel is required?
Q1)
How can I use this .bindings file into my client application system?
The .bindings file must be placed on file server that can be accessed by your client system. For example place the .bindings file on file server MyFileSvr's D:\JNDI-Directory folder. Then in your client machine D:\ folder must be mounted as a drive, say as F drive. Then in your application you can reference the .bindings file as
// Instantiate the initial context
String contextFactory = "com.sun.jndi.fscontext.RefFSContextFactory";
Hashtable<String, String> environment = new Hashtable<String, String>();
environment.put(Context.INITIAL_CONTEXT_FACTORY, contextFactory);
environment.put(Context.PROVIDER_URL, "file:/F:/JNDI-Directory");
Context context = new InitialDirContext(environment);
System.out.println("Initial context found!");
// Lookup the connection factory
JmsConnectionFactory cf = (JmsConnectionFactory) context.lookup(connectionFactoryFromJndi);
Q2)
Should the Client Application system contain the JMS Administerator to create the .bindings in the same system?or .bindings alone should be imported to the client system?
See the answer for Q1 above. It's good practice to keep the bindings file on a shared drive so that multiple client application can access.
Q3)
If Filesystem is used,then a path specifying the .binding is given as Provider url.This provider url (EG: F:/JMS) seems to be the path present in JMS Provider system.If .bindings file imported in client system,then how the client can recognise the path of .bindings file?
Again see answer for Q1.
Q4)
And What is the purpose of having ServerConnection channel in the Connection Factories definition when MQClient mode is used? When the JMS client connects through JNDI bindings ,why Server Connection channel is required?
A server connection channel defines the required properties for MQ client applications (JMS or otherwise) connect to a IBM MQ queue manager. A connection factory object in JNDI bindings will have, among others,the following defined for an application to connect to a IBM MQ queue manager
1) Host name where queue manager is running
2) Port where queue manager is listening
3) Server Connection channel name.
4) Queue manager name.
Bottom line JNDI bindings and Server connection channel are not same.
Please read through online documentation of IBM MQ as well as MQ Redbooks.
When we set up a queue connection factory, a topic connection factory, a queue, a topic in websphere application server throguh the console, what exactly happens?
The server stores the configuration details in an xml and at server startup, it creates the connection factory(ies), topic(s),queue(s) and puts them in a pool?
I ask because the actual queue(s) and topics(s) itself do not reside on the App server, they reside on a separate (remote) websphere MQ server. So why do we need to 'create' the queues in Websphere App server?
The configuration is metadata for connecting to the remote objects. When the server starts (or an app restarts, or configuration is refreshed), the server reads the .xml, then binds Reference objects into JNDI. The actual connection factories aren't created/pooled until the Reference is first looked up.
I don't have enough experience with JMS to answer your second question, but presumably the metadata is required for the queue in order to access it remotely.
I am developing a service for JMS messaging using IBM WMQ version 7.5 as Message oriented middleware. I am in a dilemma. The IBM specification says to use WebSphere MQ JMS API in JAVA EE environment. My sender and receivers will be in remote JBoss deployments. IBM provides a resource adapter to connect via JCA. This connection requires static administration of components such as Queue managers, queue channels, queue names.
Is JCA the best I can do ? Is there any other way where I can dynamically create the queues provided that I know other configuration details ? There will be multiple applications using this setup running on their own servers. If I use JCA, all have to make their own configurations. Can I make dynamic configurations ?
Typically within the application server environment resources would be created in some JNDI context. These would be Connection Factories and Destinations.
Depending on the app server, it may be possible to share this configuration across a network of individual servers. So typically there would be some set of static definitions.
However within say a servlet the MQConnectionFactory can be dynamically created.
In all cases the backing WMQ Resources do need to exist; though it is possible to send administrative command messages to WMQ to create queues and do other admin. The only exception is topics, accessing a topic string brings it into existence. Though this has default security properties that you might not want.
I wrote a java client to connect to jms in websphere.
I was able to connect and produce and consume message.
Problem I am facing is when I do Session.createQueue(), websphere jms is not creating a new queue.
Please could some one throw some light on this issue...
Thanks in advance...
If you are working with WebSphere MQ as the messaging provider within WebSphere Application Server the queue will need to be created on the WebSphere MQ QueueManager first. This can be done either via the graphical WMQ Explorer or via the command line using the 'runmqsc' tool.
Information can be found for these via the WMQ InfoCentre - suggest doing a websearch for "WMQ Library" to get the latest link, currently though it is http://www-01.ibm.com/software/integration/wmq/library/index.html
Topics though don't need to be pre-created - though they can be if required. Various properties can be set different to the default.
If the Queue doesn't need to be permanent, for example as a temporary reply to then look into creating a temporary queue from the JMS Connection.
createQueue doesn't create a new queue. It simply creates a javax.jms.Queue object from a vendor specific identifier. javax.jms.Queue objects are just references to existing queues. Typically, you retrieve javax.jms.Queue objects from JNDI; createQueue is only useful in scenarios where using JNDI is not possible or not desirable.
Note: there is one exception to this, namely JMS providers that support autocreation of queues (I think ActiveMQ has such a feature).