C#.Net and the connection factory
Good day,
I am trying to develop a service that will connect to an entity using the JMS functionality. The setup information provided by the vendor has a connection factory and jndi factory but I can't seem to find any reference to this in the tutorials for C#. I have found these references in the Java code bases. Is there such a thing in the .Net library?
Regards,
Marsden
Best Answer
-
Hello,
The Solace .Net API is not modelled on JMS and has no facilities for JMS-style connection factories and JNDI.
There is an Apache project called NMS which provides a JMS-like API to .Net applications. This has been combined with AMQP as the wireline to give the NMS API over AMQP 1.0 to supporting brokers.
Solace PubSub+ is an AMQP 1.0 broker and we have created a NMS over AMQP library available here: https://github.com/cjwmorgan-sol/nms-amqp
Other supporting links:
https://activemq.apache.org/components/nms/
https://solace.com/blog/nms-api-and-amqp/
Of course, you don't have to use NMS in your C# app. But if you are looking to write it in a JMS-style API, it's an option.
0
Answers
-
Hello,
The Solace .Net API is not modelled on JMS and has no facilities for JMS-style connection factories and JNDI.
There is an Apache project called NMS which provides a JMS-like API to .Net applications. This has been combined with AMQP as the wireline to give the NMS API over AMQP 1.0 to supporting brokers.
Solace PubSub+ is an AMQP 1.0 broker and we have created a NMS over AMQP library available here: https://github.com/cjwmorgan-sol/nms-amqp
Other supporting links:
https://activemq.apache.org/components/nms/
https://solace.com/blog/nms-api-and-amqp/
Of course, you don't have to use NMS in your C# app. But if you are looking to write it in a JMS-style API, it's an option.
0 -
Wow, I've never heard of someone trying to use "JMS" or JNDI with C#. That's interesting.
@Marsden is the JMS-like functionality a hard requirement? I always thought the only reason people use JMS is b/c it's a standard and allows for interoperability, but it is quite a restrictive API. You can use so much more Solace functionality using our native JCSMP or Java APIs.
And there's no "C# JMS" standard, so nothing regarding interoperability there. Even though it's not JMS-like, our C# API is much more functional in terms of capabilities and access to features than our JMS API.
0 -
@Aaron yes, the vendor we are connecting to is very restrictive on the requirements. I am using .Net as our security department has a major dislike of anything built with Java. I was able to get partial functionality out of the solace .Net API, was able to connect and send a message.
0 -
Connecting and sending one message is a start..! Obviously, our APIs are built to stay connected for the lifetime of the app, and pub and sub lots of messages.
What other functionality do you need? As I said, the C# API doesn't need to use JNDI or a connection factory. It can do everything – and more – of our JMS API.
0 -
Thanks for the follow up Aaron. I have indeed gone full circle using various APIs from NMS, to Apache ActiveMQ, Oracle weblogic and now back to Solace as it seems to be the only one able to communicate with the vendor's solace software created system. You are also correct about the sending of messages. I can do more than just the 1 test message with no issues.
They have a queue that I am supposed to connect to for receiving messages. This is where the software seems to be running into an issue. I am getting a "failed to provision endpoint" message when I try to provision the queue via the session. I tried the code snippet with the ProvisionFlag.IgnoreErrorIfEndpointAlreadyExists in the hopes that was the root issue but there has been no change to the error returned. I'll reach out to the vendor to have a look at the setup in case there is a configuration issue on their end for the account they provided me.
0 -
From the samples:
// Create the queue Queue = ContextFactory.Instance.CreateQueue(queueName); // Provision it, and do not fail if it already exists Session.Provision(Queue, endpointProps, ProvisionFlag.IgnoreErrorIfEndpointAlreadyExists | ProvisionFlag.WaitForConfirm, null); Console.WriteLine("Queue '{0}' has been created and provisioned.", queueName);
I don't know C#, I'm a Java guy. But our C# API is very similar to JCSMP. First: if the queue already exists, don't try to provision it. But you still need to "create" the queue in your app code, as that's actually just creating the Queue API object in your app, not actually creating a queue. 2nd: the ProvisionFlag.IgnoreErrorIfEndpointAlreadyExists thing should work even if you do try to provision. That's weird. I'm wondering if it's due to a mismatch in configuration properties between what you're specifying (maybe permissions or access-type), and what's on the broker.
Does it work if you just create the Queue object and then create the Flow to bind to the queue?
0 -
Hey Aaron. No, I tried to do the create queue with the flow first before attempting the provision root from the sample. The good news is that after a discussion with my manager I did get approval to proceed with Java. Woo Hoo. I have already had success in connecting to the queue and reading messages from it.
0