Native REST Pipeline in Service Bus Runtime

Solution Overview

Problem

Service bus systems face challenges in optimizing data pass-through for increasing messages between mobile applications and cloud services, particularly in supporting Representational State Transfer (REST) services natively without converting payloads to or from Simple Object Access Protocol (SOAP) formats.

Innovation Solution

The system and method include native REST proxy services, pipelines, and reference services within the service bus runtime, allowing message payloads to be processed in REST native formats like JSON without conversion to SOAP, with JavaScript code support for message manipulation and routing based on HTTP verbs and URL paths.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If message payloads are converted to SOAP format for processing in service bus runtime, then compatibility with existing service bus infrastructure is maintained, but processing efficiency is reduced and additional conversion overhead is introduced

Engineering Contradiction:
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The patent extracts the conversion overhead by introducing a native REST pipeline that bypasses the SOAP conversion process entirely. REST-specific processing logic is separated from the general SOAP-based service bus runtime, allowing REST messages to be processed natively without being converted to SOAP format, thus eliminating the conversion complexity and improving processing efficiency.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The patent introduces a REST adapter as an intermediary layer between REST services and the service bus runtime. This adapter enables REST messages to be processed natively in the service bus environment without requiring full conversion to SOAP format, acting as a mediator that preserves processing efficiency while maintaining compatibility with the existing service bus infrastructure.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Productivity

If REST services are supported natively without SOAP conversion, then data processing efficiency is improved, but support for heterogeneous service formats is reduced

Engineering Contradiction:
Core Design Contradiction:
ProductivityVSAdaptability or versatility

Solution Approach 1:

The service bus runtime is enhanced with multi-functionality to support both traditional SOAP-based services and native REST services. The system can selectively process messages based on their format: REST messages are processed natively through the REST pipeline for efficient data processing, while SOAP messages continue to be processed through the existing SOAP infrastructure, thus maintaining versatility across different service formats.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The patent changes the processing parameters for REST messages by introducing a dedicated REST pipeline with REST-specific configuration. This allows the service bus runtime to handle REST messages with different processing parameters (native format preservation, JavaScript support, REST routing) while maintaining the original SOAP processing parameters for compatibility, enabling efficient REST processing without sacrificing broad service format support.

Inventive Principle:
Principle #35Parameter changes

3Measurement precision

If SOAP format conversion is used for all messages, then unified processing protocol is maintained, but message routing precision based on HTTP characteristics is lost

Engineering Contradiction:
Core Design Contradiction:
Measurement precisionVSDevice complexity

Solution Approach 1:

The routing logic is segmented into two distinct pathways: REST routing and SOAP routing. The REST pipeline includes REST-specific routing capabilities that can precisely route messages based on HTTP verbs, URL paths, and other REST characteristics. This segmentation allows for high-precision REST message routing without requiring all messages to go through complex unified SOAP conversion logic.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The REST adapter acts as an intermediary that preserves HTTP routing characteristics before messages enter the service bus runtime. It maintains HTTP verb and URL path information, enabling precise routing decisions based on REST characteristics without requiring full SOAP conversion, thus improving routing precision while keeping routing logic manageable through the adapter layer.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentUS10210029B2System and method for supporting representational state transfer services natively in a service bus runtime
Publication Date: 2019.02.19
  • US10210029B2 patent drawing
  • US10210029B2 patent drawing
  • US10210029B2 patent drawing

AI summary

In accordance with an embodiment, described herein is a system and method for supporting REST services natively in a service bus runtime. The service bus runtime can include one or more native REST proxy services, one or more native REST pipelines, and one or more native REST reference services. A native REST proxy service can deliver a message payload of a REST native format into a native REST pipeline, which can process the payload without converting the payload to or from an XML-based Simple Object Access Protocol (SOAP) format. JavaScript code can be supported in the pipeline to manipulate the message payload. A REST branch node can be used in the service bus runtime to route a message based on an HTTP verb or a relative URL path in a header of the message.