Protocol-Agnostic Middleware for IoT and Enterprise Integration
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing middleware technologies require proprietary APIs and protocols for integration, leading to increased costs and complexity, especially with the adoption of distributed SaaS models and IoT devices, and are not scalable to handle increased demand, lacking last mile guaranteed delivery and edge caching capabilities.
Innovation Solution
A protocol-agnostic message-oriented middleware system that supports all industry standard integration protocols, converting data between different protocols and providing a distributed, federated architecture with a mesh of messaging brokers for seamless integration across clouds and networks, enabling last mile guaranteed delivery and caching at the edge.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If proprietary APIs and protocols are used for integration, then integration can be achieved with existing middleware technology, but integration costs and complexity increase
Solution Approach 1:
The patent implements a universal adapter framework that supports multiple industry standard protocols (MQTT, AMQP, STOMP, WebSockets, REST, SOAP) through a single unified architecture. This allows the middleware to integrate diverse IoT devices, SaaS applications, and enterprise systems without requiring proprietary protocols, thereby reducing integration complexity while maintaining broad adaptability.
Solution Approach 2:
The patent introduces protocol adapters as intermediary components that translate between various industry standard protocols and the internal messaging format. These adapters act as mediators that enable communication between different systems without direct proprietary protocol bindings, simplifying integration while preserving protocol diversity.
2Ease of operation
If centralized Hub and Spoke architecture is used, then middleware platform can be managed centrally, but system cannot scale to increased demand and workload
Solution Approach 1:
The patent divides the centralized middleware platform into distributed broker nodes that can operate independently across multiple locations and cloud environments. Each broker handles local messaging workloads, and the system provides automated service discovery and message routing between brokers, enabling horizontal scaling while maintaining ease of operation through unified management interfaces.
Solution Approach 2:
The patent transitions from a single-dimensional centralized architecture to a multi-dimensional distributed architecture where brokers can be deployed across different geographic locations, cloud providers, and network environments. This dimensional expansion enables the system to scale horizontally while maintaining centralized management capabilities through the federation protocol.
3Device complexity
If centralized Hub and Spoke architecture is used, then message routing is simplified, but last mile guaranteed delivery and buffering capability at edge cannot be provided
Solution Approach 1:
The patent enables edge brokers to pre-establish connection pools, message queues, and buffering capabilities locally before messages arrive. This preliminary action at the edge allows brokers to handle incoming messages with guaranteed delivery semantics, providing local persistence and retry logic without requiring centralized coordination for each message transaction.
Solution Approach 2:
The patent introduces federated brokers as intermediary nodes between the centralized management plane and edge devices. These brokers provide localized message routing, delivery guarantee, and buffering capabilities while participating in the federated network, thereby distributing reliability functions from the center to the edge while maintaining simplified routing through the federation protocol.
4Adaptability or versatility
If sophisticated middleware systems are deployed, then integration functionality is comprehensive, but cost of running and deployment increases
Solution Approach 1:
The patent implements automated service discovery, dynamic broker registration, and self-configuring adapter deployment that eliminate the need for expensive specialized system administrators. The system automatically discovers available brokers, configures appropriate adapters based on protocol requirements, and manages message routing without manual intervention, thereby reducing operational costs while maintaining comprehensive integration functionality.
Solution Approach 2:
The patent enables dynamic adjustment of broker parameters such as message queue sizes, connection pool configurations, and adapter processing priorities based on actual workload conditions. This parameter optimization allows the system to efficiently allocate resources across distributed brokers, reducing overall operational costs while maintaining comprehensive integration capabilities across diverse protocols and platforms.
Data Source
AI summary
A method for providing a protocol agnostic message oriented middleware for IoT, SaaS and enterprise application integration. The method includes connecting a first application and device to a protocol-less integration middleware broker. Further, the method includes converting data of an industry standard integration protocol from the first application and device to a common protocol used within the protocol-less integration middleware broker. Furthermore, the method includes converting the data from the common protocol to a desired protocol pertaining to a second application and device. Moreover, the method includes exchanging data to the second application and device wherein the data is transformed from one protocol to another.