Duplex Messaging Bus for Heterogeneous Peer-to-Peer Integration
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional Service Oriented Architecture (SOA) systems, particularly Enterprise Service Buses (ESBs), do not support mutual peer-to-peer communication between heterogeneous participants, limiting the integration of legacy systems with newly deployed systems and the creation of clusters of heterogeneous servers, as they typically allow communication only in a client-server schema.
Innovation Solution
A duplex messaging bus system that integrates heterogeneous peer-to-peer communication participants by using duplex services coupled to multiple input queues, allowing messages to flow bi-directionally with message identifiers for pairing requests and responses, and applying operations on messages based on their direction of flow.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If conventional ESB uses client-server schema for communication, then infrastructure for SOA is established, but peer-to-peer communication between heterogeneous participants is not supported
Solution Approach 1:
The messaging bus is designed to perform multiple communication patterns (client-server and peer-to-peer) within a single unified architecture. The duplex service can handle both request-response interactions and direct peer-to-peer message exchanges, eliminating the need for separate communication infrastructures and enabling heterogeneous systems to interact in multiple modes without increasing overall system complexity.
2Adaptability or versatility
If duplex service processes messages in both directions, then peer-to-peer communication is enabled, but message flow management complexity increases
Solution Approach 1:
The duplex service employs asymmetric processing where the same service instance handles incoming messages from different sources with different routing logic. Messages from peer A to peer B follow one processing path, while messages from peer B to peer A follow another path, allowing the service to maintain simple, dedicated routing logic for each direction while achieving complex bi-directional communication capabilities.
3Loss of substance
If message operations are applied based on flow direction, then data transfer is reduced, but operation management complexity increases
Solution Approach 1:
Instead of applying the same operations to all messages regardless of direction, the system inverts the operation logic based on message flow direction. For example, if a message from peer A to peer B requires transformation from format X to Y, then a message from peer B to peer A automatically applies the inverse transformation from Y to X. This inversion approach reduces redundant data transfer while keeping operation management straightforward through symmetric inverse relationships.
Data Source
AI summary
An example method of integrating a plurality of heterogeneous peer-to-peer communication participants includes retrieving from a first input queue coupled to a duplex service a first message. The first message includes a message identifier and is from a sender. The method also includes applying a first operation on the first message, determining a first output of the first message based on the first operation, and sending the first output of the first message to a target. The method further includes retrieving from a second input queue coupled to the duplex service a second message. The second message includes the message identifier and is from a target. The method also includes applying a second operation on the second message, determining a second output of the second message based on the second operation, and sending the second output of the second message to the sender.