Cutting out the middleman between enterprise data and internet streaming

Most internet streaming architectures consist of two very different technologies glued together at the DMZ. Inside the organization you’ll find integration-centric technology (i.e. messaging middleware) that efficiently shuttles data between internal systems. Outside the firewall, presentation-centric technology takes care of getting data in front of users via web or mobile applications.

In between is a gateway that has to understand both environments – corporate messaging semantics on one side, web and mobile application semantics on the other. Each part of this chain—internal message bus, gateway, and web streaming infrastructure—needs to be independently managed, monitored and scaled so none of the components become the weakest link, under normal or peak conditions.

With enough determination this approach can work, but it’s kind of like building your own car—it’s expensive, time-consuming, and you better keep a toolbox in the trunk, because it will break down and you’re the only one who’ll be able to troubleshoot and fix it.

Sending the Gateway to the Glue Factory

The gateways at the center of such systems are not simple passthroughs, they are quite complicated. They need to perform a wide range of functions:

• Termination and initiation of messages from the message bus
• Termination and initiation of internet data streams
• Mapping of message topics and queues to the equivalent in internet streaming (like Websocket channels)
• Synchronization and application of security policies, entitlements and subscriptions
• Scaling to support sufficient numbers of clients or message throughput

Operationally, each new user or queue needs to be provisioned in both the message bus and the internet streaming system, because they’re really two different systems, glued together with the gateway.

These architectures would be far simpler and more scalable if the gateways could simply be eliminated.

Unifying the Environments

Solace’s internet streaming takes a new approach to eliminate these bottlenecks and inefficiencies. Solace already supports many kinds of messaging (reliable, guaranteed, WAN, transactional) with a single platform and API. It was trivial to add support for internet protocols and streaming, and all the complex features one would expect in a sophisticated messaging environment were already built. Best of all, it isn’t two systems glued together—it is one system that spans the DMZ with no need for a gateway.

Unifying the messaging system from the back-end data sources to user-facing internet applications accomplishes a lot of things:

• Makes it easier to deploy, operate and scale the system by getting rid of the gateway and other moving pieces
• Makes the whole system more stable and reliable
• Shrinks the datacenter footprint
• Gives Web and mobile app developers more sophisticated data semantics
• Unifies management of topics, queues, and entitlements
• Accelerates time to market, as testing the app is comparatively trivial

Elegance in Simplicity

This kind of architecture just makes sense. Using our analogy above, rather than building your own car, this is like buying a new car with a worry-free, bumper-to-bumper warranty. Multi-tiered applications are notoriously hard to build and keep running over time. Unifying the development and operational environments takes the complexity and risk out of this process resulting in faster development and more stable, scalable applications.