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.… Read the rest
Today Solace introduced something we’re calling Open Data Movement. I’m going to do just two things here: define Open Data Movement, and give an example in pictures.
Breaking Down the Term
Each of the words are important and we’ve chosen them carefully.
We see this as meaning free from proprietary lock in. Solace’s approach to real-time data movement favors:
- Open protocols – the defined and de facto standards that have emerged for posting, messaging and streaming, including REST, JMS, MQTT, AMQP 1.0 and WebSockets.
- Open APIs – where possible, we encourage use of open standard APIs like JMS, Paho or Qpid giving developers and enterprises maximum choice.
- Open to all the popular cloud environments – Solace works the same in private or public IaaS and PaaS platforms, including Amazon Web Services, Microsoft Azure, OpenStack, VMWare, Cloud Foundry, OpenShift and more.
- Delivering all the message patterns and classes of service – best effort, guaranteed or transactions for request-reply, publish-subscribe, fanin/fanout, and more
- Openly integrated with popular DevOps tools – Modern products need to be fully integrated from getting started with shared sample code in GitHub, all the way to automating the test, stage and deployment process in tools like Puppet or Bosh (and everything in between).
Since we founded our company with the goal of disrupting the enterprise messaging market, the application landscape has shifted dramatically. Back then, there was no cloud and the market for messaging was dominated by two commercial, closed, proprietary products: IBM MQ Series (now IBM WebSphere MQ) and TIBCO Rendezvous.
But in the last decade or so, the increasing popularity of open and de facto standard messaging APIs and protocols have brought enterprises and developers relief from those days of vendor lock-in. Namely, JMS for general Java-based messaging workloads, RESTful applications for point-to-point, MQTT for IoT, and WebSockets for streaming to browsers and mobile devices.
All that progress has allowed many more use cases to be addressed in an open way without the risk of vendor lock-in, and Solace has been championing these technologies and techniques. We’ve supported JMS for years, and more recently added REST capabilities and support for MQTT and Paho APIs to our platform.… Read the rest
Have you ever needed to map AMQP 0-9-1 semantics onto pub/sub style messaging? Or wondered if you could even do that?
Those of you working with AMQP know that versions pre-dating 1.0 describe a very different messaging style than most messaging systems. AMQP 0-9-1 (which predates the Oasis AMQP 1.0 standard, is used by RabbitMQ, and is the model I’ll be referring to here) revolves around exchanges and queues. Every message sent is being published to an exchange, and every message received is being delivered from a queue. In order to have any messages forwarded to queues, you have to bind them to the exchange that you want to receive messages from.
AMQP 0-9-1 also knows different types of exchanges, which influences how messages are being forwarded from exchanges to queues. There’s direct, fan-out, topic and header exchanges, plus you can write your own plug-in exchange with a custom routing algorithm.… Read the rest
The message bus, information bus, and enterprise service bus concepts are popular, and now old enough, that most large organizations find they have an entire fleet of such buses. Complicating matters is the fact that they tend to be heterogeneous in version and vendor and much of this middleware is really embedded legacy application infrastructure that cannot be easily changed. So how do you modernize your fleet of old buses?
1 ) Federate: Get them talking to one another so that they benefit from the network effect that returns greater value as more endpoints are inter-connected
2) Accelerate: Get rid of the road bumps and bottlenecks slowing down the real-time flow of information. Modern data movement is much lower latency, globally distributed, with active/active replication into in-memory datagrids and distributed cache.
3) Rejuvenate: Remodel a few key flagship implementations to take advantage of the new world of streaming big data, real-time analytics, mobile sensors, M2M, etc.… Read the rest
Earlier this week I attended the second annual AMQP Face-to-Face conference at the beautiful Scripps campus at the University of California San Diego. Even a somewhat dreary day in San Diego, which they call June Gloom, is better than a nice day back home in Ottawa, and I was inspired by the many surfer dudes and dudettes who braved the cool weather to venture into the waves. I kept my feet on dry land and the lifeguards no doubt appreciated that.
The first day of the event was open to the public, and over 50 attendees came to see what’s happened with AMQP over the past year. The agenda for the day included technical tutorials on the AMQP1.0 wireline specification, some sharing of user experiences, and a discussion of plans for 2010.
In summary, after six years in development the AMQP1.0 wireline spec is now in “recommended” state. That means it is frozen and the only technical changes will be errata.… Read the rest
Next week the 2nd annual AMQP “face to face” meeting will again be held in San Diego, California. As with last year, the first day will be open to the public (Jun 8), and the next two days (Jun 9, 10) will be for members only.
If you haven’t been paying attention, AMQP V1.0 is firming up . Last week the protocol was voted to “recommended” status which means no more changes (only provable defect fixes are allowed). The biggest change that comes with the V1.0 release is that future releases must maintain backwards compatibility, which significantly reduces the risk of building applications or products using AMQP.
I’ll post another update after the meetings with some detail from the official V1.0 announcement.… Read the rest
I was fortunate enough to participate in the AMQP working group’s 2009 Face-to-Face meeting at the University of California San Diego on April 1. I say fortunate for three reasons: first because it was nice to meet the really smart people that have been driving this exciting technology; second because it was great to be there for the public unveiling of version 1.0 of the specification; and third because San Diego’s weather is just a little nicer than my home town of Ottawa.
I’ll share my thoughts on the meeting and new specification below. As a quick aside, my favorite AMQP news of the week was that the working group formally approved Solace’s request for membership. We’re excited to join the group, and look forward to contributing to the development of the spec. Our goal is to bring to the table our expertise in hardware-based messaging and feedback from our own customers.… Read the rest
Company Joins AMQP Working Group to Support Open-Standard Information Exchange for Distributed Applications
Ottawa, Canada, April 2, 2009 – Solace Systems, the leader in messaging middleware and content networking hardware, today announced it is joining the Advanced Message Queuing Protocol (AMQP) Working Group. AMQP is a proposed open-standard application layer for messaging oriented middleware (MOM). AMQP specifies a wire protocol which would ensure interoperability between AMQP implementations from different vendors. Solace has been a licensed reviewer of AMQP for several months, and today is increasing its commitment by becoming a full member.
“We believe that development of an open standard for fully interoperable messaging between distributed applications is the missing link that will catapult messaging into the same category of protocols as TCP/IP, SMTP, and HTTP and will foster the development of new and exciting applications, ” said Ralph Frankel, Solace’s CTO. “AMQP is the protocol best positioned to break through and address the requirement for truly interoperable information exchange.”
Currently, messaging is either proprietary, built in-house, or compatible only at the API level like JMS.… Read the rest