NMS API + AMQP: The Benefits of Open Source and Open Wireline Protocols

In 2001, the first Java Message Service (JMS) specification revolutionized the message oriented middleware space by offering a standard API for the sending and receiving of messages, thus freeing application developers and architects from being locked into vendor specific APIs. More recently,  the Apache community created the .NET Message Service API (NMS) which offers a vendor agnostic .NET interface to a variety of messaging systems. The NMS API gives the flexibility to write .NET applications in C#, VB or any other .NET language, all while using a single API to connect to any number of messaging providers.

While these API’s have helped to reduce the code changes required when switching messaging implementations, they’re only a first step to achieving independence and freedom from all lock-in. Because NMS simply provides a set of .NET interfaces, it is up to each vendor or open source project’s community to match the interface to their wireline protocol (which is frequently non-standard) and the message broker it connects to. Idiosyncrasies in behavior due to non-standard protocols tend to arise when moving to a different messaging implementation, which leads to more test cycles, re-coding and anguish.

Solace has been a big supporter of open APIs and wireline standards for years, as demonstrated by our adoption of MQTT and REST. A year ago, Solace launched an initiative called “Open Data Movement” whereby we clearly defined our commitment to openness and standards. In keeping with that commitment, we developed our own implementation of the AMQP 1.0 standard wireline protocol to be completely interoperable with open source API implementations.  The key to enabling vendor independence and mass adoption of technology is to combine open source APIs and standard wireline protocols. To that end we at Solace are putting our money where our mouth is and, working with the Apache community, are creating the AMQP provider for NMS as an open-source Apache project.

Here’s how AMQP 1.0 support within NMS helps the .NET community:

• More Choice: As more message brokers and services implement the AMQP 1.0 standard wireline, .NET developers and architects will have more options for messaging technology. The .NET community will no longer be reliant on vendors to implement their own specific NMS provider implementation, so you will be able to choose the message broker that is right for your application.
• No Migration Risk: Since AMQP 1.0 is a wireline standard, you won’t run into the problems that used to happen when switching between implementations. Think about how seamless it is to switch web server implementations thanks to the HTTP standard protocol. Our CTO Shawn McAllister gives a good overview of this value prop in the video AMQP: What is it (really) and why do you care?.
• Innovation: Competition is a key component of technology innovation. Historically, messaging implementations have held market share through what I call API entrapment. Many vendors fear open standards because they know their product will eventually falter, so they want to make it harder for their customers to switch to a new solution, and they’re not incented to advance their technology. This thinking is inherently flawed and anti-competitive. Directly competitive messaging implementations, with seamless pluggability, forces vendors to innovate and differentiate.

If you are a .NET developer that doesn’t want to be locked into a messaging implementation, check out https://github.com/cjwmorgan-sol-sys/nms-amqp. There you will find the open source code base we are working on and since it is open source, you can provide comments and make your own enhancements. When ready, the project will be folded into the Apache community as they too feel that supporting AMQP with NMS is a worthwhile project.

We at Solace are all about openness which means not just supporting or tolerating open wireline standards and open source standard API’s but embracing them and actively helping to advance them.  Our mission is to make the use of messaging as painless as possible for developers while fostering technical innovation to ensure competition.

Jonathan Schabowsky

Field CTO

As Solace’s Field CTO, Jonathan helps companies understand how they can capitalize on the use of event-driven architecture to make the most of their microservices, and deploy event-driven applications into platform-as-a-services (PaaS) environments running in cloud and on-prem environments. He is an expert at architecting large-scale, mission critical enterprise systems, with over a decade of experience designing, building and managing them in domains such as air traffic management (FAA), satellite ground systems (GOES-R), and healthcare.

Based on that experience with the practical application of EDA and messaging technologies, and some painful lessons learned along the way, Jonathan conceived and has helped spearhead Solace’s efforts to create powerful new tools that help companies more easily manage enterprise-scale event-driven systems, including the company’s new event management product: PubSub+ Event Portal.

Jonathan is highly regarded as a speaker on the subject of event-driven architecture, having given presentations as part of SpringOne, Kafka Summit, and API Specs conferences. Jonathan holds a BS Computer Science, Florida State University, and in his spare time he enjoys spending time with his family and skiing the world-class slopes of Utah where he lives.

See all posts written by Jonathan Schabowsky