Pluggable Transport Pipeline Decouples Request Response Processing
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In Service-Oriented Architecture (SOA), the conventional requirement for using the same transport protocol for request and response messages in a request-response pattern can be inefficient, as it necessitates the client to hold the connection until the response arrives, and existing frameworks lack the ability to seamlessly decouple request and response processing and support custom transports transparently.
Innovation Solution
A computer-implemented system and method that decouples request and response processing by using a pipeline architecture where requests and responses are processed in separate pipelines, allowing for the use of pluggable transports, enabling efficient processing and resource utilization, and enabling new transport protocols to be added without modifying the SOA processing model.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If the same transport protocol is used for request and response messages in a request-response pattern, then the implementation is simple and conventional, but the client must hold the connection until the response arrives, reducing efficiency and resource utilization
Solution Approach 1:
The patent segments the request and response processing into separate pipelines, allowing independent configuration of transport protocols for each direction. The request pipeline handles outgoing requests while the response pipeline handles incoming responses, enabling decoupling of transport choices without increasing overall system complexity.
Solution Approach 2:
The patent introduces a transport factory as an intermediary component that manages multiple transport protocols. This mediator allows the system to select appropriate transports for requests and responses independently, resolving the contradiction by providing a structured way to handle transport decoupling without direct complexity in the message processing logic.
2Adaptability or versatility
If different transport protocols are used for requests and responses, then resource utilization improves and flexibility increases, but conventional SOA frameworks lack the ability to support this seamlessly
Solution Approach 1:
The transport factory is designed as a universal component that can manage multiple transport protocols (HTTP, SMTP, JMS, etc.) through a common interface. This multi-functional design allows the framework to support different transport protocols for requests and responses without requiring separate handling logic for each protocol, thus increasing adaptability while controlling framework complexity.
Solution Approach 2:
The patent implements dynamic transport selection where the transport protocol can be configured differently for requests and responses based on runtime conditions. The transport factory dynamically chooses appropriate transports based on configuration and message properties, enabling flexible adaptability without hardcoding complex framework logic for each protocol combination.
3Adaptability or versatility
If custom transports are plugged in transparently, then the system supports new protocols without modifying the SOA processing model, but the implementation requires a pluggable architecture
Solution Approach 1:
The patent extracts the transport protocol logic from the core SOA processing model by introducing a separate transport factory and transport interface. This extraction allows custom transports to be implemented independently as plug-in components that conform to the standardized interface, enabling custom transport support without modifying the existing message processing pipelines or service invocation logic.
Data Source
AI summary
A method, system, and computer-readable medium are described herein. An embodiment may read a configuration file. The configuration file may specify a first stage that specifies processing of a protocol-agnostic portion of a message. The embodiment may then add, by one or more processors, the first stage to a processing pipeline, where the processing pipeline is configured to process received messages according to the first stage and a second stage. The second stage is a stage of the processing pipeline that specifies processing of a protocol-specific portion of the message. The processing pipeline being further configured to transport the processed message to a service via a transport mechanism.