 Hi, I'm David Ingham. I'm an engineering manager in the middleware team at Red Hat. I'm responsible for all of our messaging offerings. So that includes the AMQ product and the messaging subsystem in EAP and various other messaging bits and pieces. And I also lead our effort in middleware to support the Internet of Things. AMQ is a flexible, standards-based messaging platform for the enterprise, cloud and the Internet of Things. People use AMQ for a variety of purposes. Traditionally, it's used as an integration technology. So in the enterprise, AMQ is used to connect together different computing systems and connect them together in an asynchronous, decoupled way. And that gives you a lot of flexibility. AMQ provides temporal decoupling. And that allows different components of the application to be disconnected at any one time without bringing down the whole application. And this is useful if you want to upgrade a component or you have a problem and you need to repair a component. Temporal decoupling also provides you with the notion of load leveling. And what load leveling, a good example of load leveling is if you have a web application that's generating units of work that you're putting into a queue. And that web application may be popular at different times of the day, you know, in the morning and at lunch time and in the evening, for example. Having a queue mediating the web tier and the processing tier means that you only have to provision the application for average load rather than peak load. AMQ also helps to deal with heterogeneity in the enterprise. So if you have components that are written in different languages that want to be able to communicate with each other, then AMQ has client libraries that allow you to connect from those different languages. Recently, we've added support for AMQP protocol into AMQ. AMQP is a ISO, IEC, international standard protocol that defines how components exchange messages between themselves. Components being clients, so client-to-client, client-to-broker or broker-to-broker. AMQ is probably best known as a JMS provider and indeed it supports the JMS APIs and does a great integration with EAP to provide the JMS messaging subsystem of EAP, but it's much more than that. We have a support for a variety of protocols that allow you to connect components from arbitrary languages. So we have a text-based protocol called STOMP, which is very easy to use. It's a very simple protocol and that means that there are client libraries available for any language you might be interested in connecting to AMQ. More recently, we've added standards-based protocols like AMQP and MQTT and that extends the range further. I don't think anybody comes to AMQ for an exciting time. It's not about excitement, it's about reliability. It's about connecting your components together and knowing that there's a robustness of that interconnect that means that even if failures happen in your system, then important business-critical transaction messages won't be lost. So it's not the most exciting technology on the block, but it's a really critical foundational technology for connecting components of a distributed application. The Internet of Things brings an entirely new set of use cases for messaging. Connecting devices reliably to a back-end cloud is a really important aspect of the Internet of Things. Being able to do this in a way that scales to potentially very large numbers of devices and very large amounts of data is really important. So a platform like AMQ with its proven stability and scalability is ideal for this use case. To support the Internet of Things, AMQ provides MQTT protocol support. MQTT is a protocol that's designed specifically for the IoT use case. It's a very lightweight protocol and it offers a very low overhead on top of the business message in order to be able to scale to the very large numbers of devices that we tend to see in IoT use cases. In AMQ 7, we've built this messaging as a service platform, which is the AMQ 7 components running on OpenShift. And the goal here is to address messaging scale in multiple dimensions. We want to be able to support large numbers of connections. So for the Internet of Things style use cases, when you have a large number of devices, then connection scalability is important. We want to provide scalability in terms of the number of messaging destinations that you want to support with this infrastructure. So that's the numbers of queues and topics and direct routes that you want to support in that infrastructure. And then we want to support scale in terms of the throughput for a particular messaging destination. So you might have a particular queue that receives an awful lot of traffic that you need to shard over multiple machines in order to be able to accommodate the load. In messaging as a service, we separate the roles, we separate the developer who simply requires to deploy messaging destinations, queues, topics or direct routes. From the operator that is provisioning the underlying hardware, typically with traditional messaging being deployed on premise, it's the same administrator is looking after both of those roles. The separation of these roles means that it reduces the complexity for the developer who simply wishes to provision a queue or several queues in order to meet the needs of his application.