I have successfully sent/received messages from a java client to a JMS queue where wm Broker is the JMS Provider (on localhost). I use the following url:
Now I want to send/receive to a SeeBeyond provider. Knowing the following, how do I construct a url for the SeeBeyond provider?
SeeBeyond Hostname: hhh
Service Name (queue): qqq
My guess is something like this:
But that is just a wild guess. Can anyone help?
no, that won�t work.
A try would be: seebeyond://qqq@hhh:111
Remember to specify the SeeBeyond Naming Provider Jar-Files in the JAR-Section.
webMethods JMS Provider is only able to connect to JNDI-Server mentioned in the drop box of JMS Admin.
BTW: Which version of the JMS Provider do you use? SP3 or an version before that?
JMS Naming Provider from webMethods is known to be buggy in SP1.
On the other side wM JMS Naming Provider and file system JNDI are not supported by webMethods for production systems (according to JMS Provider Admin/Users Guide).
I have JMS Provider from SP3 (I don’t know how to auto-identify the version, but I see the Broker folder contains a file named JMS_61_SP3_Readme.html).
I think most of my problems relate to JNDI, not JMS itself. But it appears that one cannot create a JMS connector unless JNDI is in the picture. Without a connector there can be no JMS adapter service, and without a JMS adapter service there can be no JMS flow service.
I have succeeded in running a pure java service to send/receive to SeeBeyond (without using JNDI)
I could investigate the feasibility of writing a wm-java service which bypasses JNDI.
BTW, when I use the following provider url, I get the error shown below when I try to enable the JMS connection:
[ADA.680.201] Cannot connect to the JNDI Provider: “seebeyond://dccdosse03.agc.local:24183”.
[BRN.117.1012] URL Syntax Error: Missing protocol.
The connection parameters are shown below:
Connection Type JMS Adapter QueueConnection
Package Name ladson_JMS
Transaction Type LOCAL_TRANSACTION
JNDI Initial Context Factory com.wm.jms.naming.WmJmsNamingCtxFactory
JNDI Provider URL seebeyond://dccdosse03.agc.local:24183
JNDI Security Principal
JNDI Security Credentials
JNDI Other Properties
QueueConnectionFactory JNDI Name QueueConnectionFactory1
JMS user a6
JMS password ******
Connection Management Properties
Enable Connection Pooling true
Minimum Pool Size 1
Maximum Pool Size 10
Pool Increment Size 1
Block Timeout (msec) 1000
Expire Timeout (msec) 1000
Startup Retry Count 0
Startup Backoff Timeout (sec) 10
the Broker version can be detected via the WmBrokerAdmin-page.
It is on the Broker Servers overview page and in the Broker System Log.
It should read something like this for SP3:
For the “missing protocol”:
You cannot use the WM Naming Context when using the seebeyond url.
You will need to use the SeeBeyond Naming Context instead. Check the JAR-Files or the documentation from SeeBeyond for the exact name of that class.
Which JMS Provider are you planning to use?
wM Broker JMS Provider?
Requires a JNDI-Storage like SUNs FileSystem JNDI, BEA Weblogic, LDAP-JNDI or webMethods JMS Naming Provider. Maybe SeeBeyond can serve as a JNDI-Provider as well for this case.
Objects can be administrated via wM JMS Administrator 6.1 FP1.
SeeBeyond JMS Provider?
Try to use wM JMS Adapter for connecting. In this case SeeBeyond needs to have some sort of internal JNDI for registering its objects.
Objects need to be administrated using SeeBeyond.
I was able to send/receive messages to/from SeeBeyond by means of a wm-java service. The guts of the code for receive looks like this:
qcf = new STCQueueConnectionFactory(hostName, port);
queueConnection = qcf.createQueueConnection();
queueSession = queueConnection.createQueueSession(true, Session.AUTO_ACKNOWLEDGE);
queue = queueSession.createQueue(queueName);
queueReceiver = queueSession.createReceiver(queue);
receiveMsg = (TextMessage) queueReceiver.receive();
System.out.println("received msg= " + receiveMsg.getText());
The first line uses a class from a SeeBeyond-supplied jar. The remaining lines use classes in open-source jars.
This shows that communication is possible without JNDI. However, an adapter connection appears to be dependent upon JNDI.
Isn’t it possible to use the following configuration?
wm client (using adapter connection and JNDI naming)
wm broker as JNDI server
SeeBeyond as JMS provider
Or is it necessary for the JMS provider to also serve as the JNDI server?
from my understanding wM Broker cannot serve as a standalone JNDI-Provider.
wM JMS Naming is only provided as a JNDI-Provider for the wM Broker JMS Provider.
If you plan to use SeeBeyond as a JMS Provider you should try to use JMS Adapter for your connections. In this case SeeBeyond should either contain a JNDI-Provider or connect to an external JNDI-Provider.
Referring to your code, even the classes (interfaces) point to open-source-jars (this means jms.jar or j2ee.jar), there need to be classes in the SeeBeyond-jar implementing them, as the methods called will return the SeeBeyond specific implementations.