Microsoft and Java relationship
Microsoft has been working towards bridging the gaps between theirs and Java services for quite some time. Last year Microsoft started providing the support for Java in Visual Studio Code through a wide range of extensions. Recently Microsoft’s development team has also released a new update for VS code that greatly improves the “getting started” experience for java coders. Microsoft has also announced OpenJDK for Windows 10 on ARM.
Now a recent update from Microsoft have been announced related to java message services. Microsoft announced the preview support for Java Message Service 2.0 over AMQP in the Azure Service Bus Premium tier.
Azure Service Bus
Azure Service Bus itself is a popular service by Microsoft. It is a fully-managed messaging broker service on Azure. It also supports messaging and decoupling of applications and services. Best talent of Microsoft has been working on Azure for quite some time due to which it has greatly evolved over the years. Initially, it has the support for messaging protocols like AMQP and JMS 1.1 and now the service has also announced the supports for JMS 2.0 over AMQP.
Ashish Chhabria, a program manager of Azure Messaging at Microsoft, made this announcement in a blog post, He expressed that Java Enterprise community has done remarkable work with the Java Message Service specifications of both JMS 1.1 and JM 2.0. Their attempt to standardize the APIs used by the producer and consumer applications when communicating with an enterprise messaging broker offers extreme convenience for everyone including developers, producers and consumers irrespective of what type of application he is working on.
It is not just Microsoft, The Apache QPID community has also implemented JMS 2.0 API specification over AMQP. QPID-JMS.
Why Microsoft is showing such interest in Java Message service 2.0?
Elite software engineers at Microsoft had recognize the potential of Java services as they have the support for JMS 1.1, which was released way back in 2002. JMS 2.0 is the first specification update for it released in April 2013. It is an obvious thought that in such a dynamic industry, an API that has remained unchanged for more than a decade would be a legacy by now and unusable, but still, JMS 1.1 is one of the most successful APIs around due to its performance and features offered. So far JMS 2.0 has also been released for more than five years, but now Microsoft must have realized the need for to apply the significant improvement that comes with JMS 2.0 in their Azure service bus.
Following are some of the factors that must be considered by Microsoft Architectures before providing JMS 2.0 Support.
· Simplified API
The most prominent change in JMS 2.0 is the introduction of a new API for sending and receiving messages. The JMS 1.1 API, which is now referred to as the classic API was fairly complicated. As the name suggests, Simplified API was designed by the top developers prioritized to make it relatively simpler and straightforward in terms of usage. To achieve that, they have significantly reduced the amount of code a java developer needs to write. It also supports resource injection which allows the application server to control the creation and management of JMS objects, but it is only limited for the applications that run in a Java EE application server.
· Default Connection Factory in Java EE
Along with JMS 2.0, Java EE 7 introduced a platform default JMS connection factory. It is a built-in connection factory for JMS that connects to the application server’s built-in JMS provider.
Applications can easily use this connection factory by performing a JNDI lookup using the following command,
This connection factory was primarily targeted for the applications that use the built-in JMS provider and do not need to add any application-specific configuration.
· Multiple Consumers can use the Same Topic Subscription
Previously in JMS 1.1, It was not allowed to have multiple consumers to have a subscription on a topic. It limited the scalability of the application as it was not permitted to share the work of processing messages on a topic subscription between multiple or Java Virtual Machines (JVMs), threads and connections.
Top software engineers realized this restriction and they finally removed it in JMS 2.0 by introducing shared subscription.
· Asynchronous Messaging
Facility to send a message asynchronously was another remarkable feature introduced in JMS 2.0. When a message is sent asynchronously, the message is sent through a send method to the server and then returns control to the application without waiting for a reply from the server. In Asynchronous messaging, the application can easily utilize the time Instead of being blocked unproductively while the JMS client waits for a reply. It was a genius move as it not only saves time and resources but also speeds up the messaging.
· Pre-existing Provider
Microsoft’s top developers expressed that the JMS 2.0 support for AMQP in the Azure Service is a revolutionary step since now they did not require to implement a new provider, instead, they are now collaborating with an existing JMS provider and user, Apache Qpid JMS.
Apache Qpid JMS is a well-revied JMS provider that is now used by three families of brokers: Apache Qpid, Apache ActiveMQ, and newly added in the list, Azure Service Bus.
· Seamless process for Connecting the existing applications with Azure Service Bus
It is mentioned in the list of features that are supported with this preview, Azure Service Bus will now support all Java Message Service API contracts, allowing customers to shift their existing applications to Azure without any need for rewriting the application.
By providing such ease, Users are now promoted to use Azure Bus Services as they can now connect their existing JMS applications to the service bus just by adding the Azure Service Bus JMS Maven package or the Azure Service Bus starter for Spring boot (if you are working on Spring boot) to their application’s pom.xml. Then it is only required to add the Azure Service Bus connection string to the configuration parameters and the application will be connected.
Tech giants like Microsoft have realized now that provision of such supports and feature not only facilitate developers but it also helps companies in offering better features to their customers and also open the possibility of gaining new customers. As Microsoft is not open source, it requires customers to buy their services and products.
Such associations can also result in uncovering and resolving vulnerabilities in both party’s services, it will be especially beneficial for Microsoft as Java has a rich community filled with top software developers. It can also result in better compatibility between Microsoft and java products and will result in more ease for developers as well as for consumers of their products. Active Microsoft blogs for providing regular support and assistance for java coders using Microsoft products indicates that more supporting features are yet to come from Microsoft.