I'm working on Java JMS application connecting to Azure ServiceBus. Once I found out JMS is supported I did not expect any problems. However, when I started creating the connections and added Spring JmsTransactionManager I got an error which said my Azure subscription is "Base" tier and thus transactions are not supported. What I did was upgrading to "Standard" tier and the error was resolved. This is covered here.
However during testing I was not sure it is working as expected and I'm testing the behavior and in the meantime I got confused by another MS documentation saying "transacted sessions" are not supported in this JMS over AMQP protocol.
Question:
Can I rely the queue in Service bus will be transacted meaning the message won't be removed from queue until my transaction manager explicitly calls COMMIT?
How can anyone claim JMS compliance but at the same time say I don't support transacted sessions.
Thank you for any response because I'm confused.
Update:
The Azure Service Bus starter for Spring Boot has Qpid as dependency so that is what I'm using under the hood - I was not aware of this first:
<!--Qpid-->
<dependency>
<groupId>org.apache.qpid</groupId>
<artifactId>qpid-jms-client</artifactId>
</dependency>
There is not currently a specification for distributed (XA) transactions over AMQP and as such the Qpid JMS client does not offer an XA ConnectionFactory implementation so if you are using that then for sure you would not get any support for distributed transactions.
The Qpid JMS client itself does implement local transactions so in that sense you could use a standard locally transaction JMS session but it is possible that MS has disabled that through the spring boot bits to dissuade folks from using it as the benefit of local transactions is quite small especially for folks using spring how might think that they are participating in a larger distributed transaction when they are in fact not.
Related
I want to connect to the Microsoft Azure IoT Hub with Java to implement a device-gateway with some kind of identity translation. As I don't want to use the proprietary Azure SDK, I'm looking for a suitable AMQP-client-library.
I made first steps with the very high-level Vert.X AMQP client and was able to connect to the IoT Hub with SASL and exchange messages. But as a per-device-authentication is required, I came to the libraries limits fast, as sessions and links are not supported.
There are other AMQP-client-libraries like the parent-library of the Vert.X AMQP Client, Vert.X Proton, and of course the most detailed AMQP-client-implementations Apache Qpid Proton-J and Qpid JMS.
The question which arises now is which library too choose for my usecase? Currently I can't answer it myself satisfactorily, as the available online-resources (documentation and examples) to these libaries itself and the external AMQP-integration to the IoT Hub with other libraries then the Azure SDK are very rare. Apache Qpid seems to be the most powerful but also the most complex one. Vert.X Proton as an easier to use wrapper also supports sessions and links, but probably still doesn't support all required AMQP-features to connect to a IoT hub? It's hard to get an overview on the requirements.
The Azure IoT SDKs are fully open source under MIT license, so not proprietary per se. The Java SDK depends on Apache qpid Proton J and adds a light convinience layer to abstract the protocol itself. Allowing you to take full advantage of all the Azure IoT Hub features. I'm genuinely curious why you would prefer not to use an open source SDK that is supposed to make your life easier. Also curious to why you prefer AMQP rather than MQTT. Once again these are purely genuine questions as I am trying to understand better our developers needs and wants.
Also in case you have not found it there is a doc that explains how IoT Hub uses AMQP here: https://learn.microsoft.com/en-us/azure/iot-hub/iot-hub-amqp-support
I am new to Spring integration;If i understand right, spring integration has 3 key players;
1 Publisher
2 Subscriber
3 Channel.
I can understand the Publisher, subscriber frameworks where DB/File system is used as queue. Where does spring integration queue resides? If publisher and subscriber are individual process by itself, how do they share channel? Is channel accessible to both Publisher process and subscriber process because they run in same JVM?
Does that mean that, if publisher runs in one machine and subscriber runs in another machine, can't we use Spring integration?
The Spring Integration is Framework for developing integration solutions. It is lightweight and doesn't provide a Broker solution.
If your producer and consumer are in separate JVMs, you really have to use third-party Messaging Broker like ActiveMQ, RabbitMQ, Apache Kafka, Hazelcast etc.
Spring Integration just only provides building blocks, everything rest is up to use. The main feature of the channel that you always can switch it into different implementations without impacting producer and consumer. Right, if both producer and consumer are in the same JVM, there is no reason in the external network communication. In most cases you even don't need to use QueueChannel - the DirectChannel is enough to perform consuming in the producer's thread.
See Message Channels for more info.
Perhaps a silly question, but keep reading about SIs "lightweight messaging within Spring-based applications". I want to know how (if) SI uses messaging internally. When I run an SI (Boot) application (one that doesn't require AMPQ ... aka 'messaging' support), I don't have to run a Rabbit server. But, from what I gather, SI uses messaging internally. How is this accomplished? I can't seem to find any reference explaining this & what infrastructure is required to make this possible. Thanks!
The messages are simply Java objects (o.s.messaging.Message) passed between components. No external broker is needed, unless you need persistence.
I suggest you read Mark Fisher's book (Spring Integration in Action) and/or the reference manual.
The messaging inside spring integration are in-memory java objects passed from one service to another via channels/queue. It provides a mechanism to define the flow and order of processing, also allowing each service step to work in isolation. The spring integration queue is eventually an implementation of java.util.Queue interface.
It is different from commercial Messaging tools like IBM MQ or Active MQ as it doesnt offer persistence. Which means if you kill the jvm or the app process is stopped, all the messages in flight on the Spring queue/channel are lost. A lot if times this is acceptable if the process in idempotent, i.e When the application comes up, I can restart the process from beginning.
I'm trying to build MQTT support into my Spring application. For this I'm looking at the references provided by Spring, which can be found here here.
They provide sample code for inbound and outbound channel adapters, but this concept of adapters is unclear to me. I couldn't find a lot of information about it on the web.
What exactly are these adapters and why are they needed?
Where do I need to define these adapters and how do I access them?
I'm using eclipse as my IDE and maven as my buildtool.
The adapters are a concept from Spring Integration which is yet another Spring project that provides an implementation of the Enterprise Integration Patterns and provides an abstraction layer that standardizes the way you integrate with external system, whether they are based on JMS, FTP or as in your case MQTT.
As with so many other Spring projects, the driver behind it is a loose coupling and standardization that will enable you to swap your channel provider (e.g. if its a JMS provider swap RabbitMQ with ActiveMQ or vice-versa) with a minimal impact to the rest of you code.
Its comparable to Apache Camel, in case your more familiar with it, and this comparison is quite an interesting read
Spring integration is used to make the communication between two systems easier.
So does that mean the if two systems are talking using JMS queus, then we can remove queues and integrate two systems using Spring Integration Framework?
Looks like you should study more on the matter. I mean EIP-book, Spring Integration in Action or, at least the Reference Manual from Spring IO site.
The main Spring Integration goal is integration and JMS is only one way to do that.
If your two system can get deal with JMS, there is no stops to integrate them using Spring Integration: just provide JMS adapters for boht of them.
As per my understanding,
Spring Integration solution a framework level solutions to Design Patterns listed in http://eaipatterns.com/
I might be an alternate to ESB which is like one big tunnel & everything passes through that.
Spring Integration provides end to end message between different de-coupled, disparate connecting points.
On the other hand JMS is an API in the Java EE spec which can be used in conjunction with Spring-Integration.
You might as well want to read about AMQP which is a messaging protocol.