Posts

Introducing Open Data Movement

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.

Open

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).
Read the rest

Introducing SEMP v2 – Solace Message Routers configuration reinvented!

Solace has always had a programmatic interface for managing Solace message routers, called the Solace Element Management Protocol or “SEMP.”

Among the many exciting developments we’re announcing today is the reinvention of SEMP as a REST API that will simplify the creation of self-serve portals, enable the integration of messaging into CI/CD pipelines, and be more natural in cloud deployments. I’ll try to give you a better understanding of this new version (which we call SEMP v2) and how it will be used.… Read the rest

RESTful Messaging – Your New Favorite Technology Mashup

iStock_000021512770LargeIt used to be pretty easy to pick the technology you’d use to connect applications to information sources, services and people.

  • If you were developing an enterprise application to manage inventory in your supply chain or automating some business process, calling upon multiple internal systems and databases, you’d use messaging middleware like JMS, MQ, or Solace.
  • If you were building a web or cloud app aimed at mobile workers or end users, on the other hand you’d use app servers, open source tools and REST/HTTP to move the data.

But increasingly, most applications look like “all of the above.” A corporate mobile app might need information from several back-end data sources to support a field sales team. And an Internet of Things application may push data over the wireless internet to cloud-based storage and an internal big data store so it can be analyzed by a CEP engine. Which is the best choice then – a messaging architecture, or a REST-based web architecture?… Read the rest

Adding REST to your Message Bus

hIf you are a veteran of messaging-based application design, you’ve gotten used to a rich set of services that help you get data where it needs to be. Messaging handles a diverse range of tough problems such as ensuring that information is received by each recipient once and only once, distributed to thousands of endpoints within microseconds or delivered even in the event that an application suddenly disconnects from the network.

Making HTTP and REST APIs “first class citizens” of your message bus opens up development and deployment options that let you can embrace everything that’s great about web and mobile programming without giving up the level of service you’re used to. Here are some examples:

  • Zero client install: Anything with a browser, or a simple mobile app, can easily interact with back end services using HTTP, the most open and standard of protocols, without you needing to distribute your API in advance.
Read the rest

Bringing Messaging to REST Applications

iStock_000016561354LargeIf you’re an enterprise developer of mobile or web applications, you’ve probably used HTTP and a RESTful API to post data into your app server which in turn connected to a message bus for distribution to back-end assets. Getting data flowing back and forth is the tip of the iceberg – the real work lies in making it performant and resilient, and of course testing the heck out of it. That’s where direct easy access to a message bus can seriously accelerate your coding by taking care of those tedious parts of building, testing and deploying bulletproof services.

Here are some examples of what you get when a fully featured message bus is available to your application development:

  • Publish/Subscribe: Your applications can use REST/HTTP to post information to a message broker which reliably delivers it to any number of recipients, from a few to many thousands.
  • Fire and Forget: Once your application has posted whatever data to a message bus, it can take responsibility and guarantee that the information gets everywhere it needs to go.
Read the rest

oneM2M Aims to set Standards for M2M and IoT

In order to achieve plug-and-play interoperability between connected devices, what’s commonly called machine to machine (M2M) communications or the Internet of Things (IoT), there needs to be agreed-upon standards for connectivity, security and information sharing between the devices and back-end applications.

The first significant step in that direction came earlier this month when oneM2M, a global organization of over 200 companies, published a set of 10 documents that propose standards for IoT architecture, security, service definition, management, and specifying protocol bindings to the most commonly used IoT protocols CoAP, MQTT and HTTP.

The momentum behind this initiative is encouraging, and it’s good to see such an apparently complete standard proposed relatively early in the evolution of IoT. The devil will be in the details as we learn how comprehensive the specifications are, and to what degree early adopters must extend them to deliver production grade systems.

Still, something is better than nothing.… Read the rest

How Rich Internet and Smartphone Apps are Driving a Return to Client-Server Architecture

Solace recently announced a new network card that can boost the capacity of each Solace’s appliance to 80Gbps of bandwidth. As more companies embrace real-time computing and “big data” fueled by information flowing between mobile devices, sensors and social networks, this kind of capacity will enable some seriously cool innovation. But I believe there’s even more to it than that – I think this kind of massive capacity will influence the very nature of enterprise applications.

Think about the fact that smartphones didn’t exist just ten years ago. Think about the server-side ramifications of all that recent change, and where we are today. Having a hardware-based HTTP termination point, WebSocket wireline support, higher connection density and using messaging as a communication paradigm even over HTTP is allowing front end applications to become much more scalable, faster, and most importantly easier and more intuitive.

Lets examine this from an application developer’s perspective to see if we can extrapolate what’s next.… Read the rest

The Art of One Handed Programming

I’ve been playing around with MuleStudio from MuleSoft lately, and am very impressed with how easy it is to create integrations with the Eclipse-based IDE. The product comes with a long list of commonly needed endpoint connectors for talking to files, databases, HTTP, IBM WebSphere MQ, or even end systems like SAP.

This was all it took to customize the included JMS Endpoint to work with a Solace appliance, which we make available in the public Internet as a messaging service:
xml

jmsWith the Solace JMS endpoint configured, the rest was “one handed programming.” Dragging and dropping icons and connecting endpoints from the pallete was quick and easy, and before I knew it  I was running a REST API for publishing messages to Solace topics and queues.

After that, I wanted to explore further and make a more “cloudy” demo so I picked up on the available Cloud Connectors which include integration components for Amazon, Salesforce.com, Facebook, and Google.… Read the rest