IoT Developer Experience
We have already touched on “Why MAS?” in a previous post. Let’s zoom in on some relevant aspects of the Internet of Things, a topic hard to avoid these days. It turns out that you don’t need to go far to discuss use cases for IoT because our customers have been building out IoT solutions for some time with existing products like CA Mobile API Gateway. This gives us an incredible source of real-world use cases and exposes business challenges that need to be solved in Healthcare, Retail, Finance, Utilities, and Automotive vertical perspectives. Our customers are world-known brands that are pushing limits from a technical and business perspective. To some extent these are all separate verticals, but it turns out there are cross cutting concerns, and similar challenges that can be addressed using common tools. From a business perspective, this is healthy because we can learn from each other and leverage scale and ultimately lower costs. At the same time, you need to ensure that the technology stack is flexible enough to tailor your product to the end user to deliver that stellar experience.
A challenge that arises with IoT is enabling developers to build apps that can leverage the new capabilities that IoT brings. To unlock the real value of IoT, that is, to move from Michael Porter’s new product capabilities like Monitoring and Control, towards more advanced capabilities such as Optimization and Autonomy, you need an integration fabric and ensure that app developers can easily leverage IoT systems. This implies that app developers must be enabled to write apps that observe a resource, get updates on its state, and is able to react to this change. But the question quickly becomes, how.
The answer is found in a rather old pattern. Publish/Subscribe. Yeah, you heard that right, that old pattern of asynchronous messaging is extremely important in the new world of IoT. PubSub has been a key ingredient in distributed computing since the 80s. There are a number of protocols available for asynchronous messaging passing, such as AMQP, XMPP, DDS and MQTT. CA APIM already supports proxying a few like XMPP and AMQP, and with MAS, we added MQTT 3.1.1 support both on the gateway and client side to allow for sophisticated messaging support for app developers.
API Endpoints As with everything we do – “APIs Everywhere” is our mantra. This means you can access endpoints for every aspect of MAS and MAG. In the case of connecting a client to a MQTT broker using an API gateway: Connection Options
SDKs To provide app developers with conveniences, MAS provide a number of client side SDKs. For leveraging PubSub in a mobile client, the MASConnecta SDK should be used: MASConnecta
This provides a MASMQTTClient class with a number of methods that simplify coding: publishing to topics, subscribing to topics, and setting QoS. This MQTT functionality is provided over the MAG standard security with OAuth and mutual SSL.
Regarding IoT protocol wars, and without throwing more fuel to fire, with our customers and in wider market, we observed an uptake of MQTT and decided that this fit well with our overall requirements for message passing between mobile clients and the API gateway. That doesn’t mean that other approaches are not valid – it means that we offer an excellent DX for our customers who needs to write apps that require async message passing when building or integrating into IoT systems.
In my next post, we will discuss another feature built on this PubSub fabric: User-to-User and User-to-Group messaging.