Common Communication Port Protocol Conversion for Legacy Service Requests

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Legacy applications that predate Service Oriented Architecture (SOA) face communication barriers with Web Service servers due to their use of non-SOAP communication formats, requiring costly upgrades or the use of multiple Enterprise Service Bus (ESB) services and ports to handle diverse service request types, which is inefficient and costly.

Innovation Solution

Implementing a system that receives service requests through a common communication port, converting requests to a desired format if necessary, and routing them to a web service application, thereby reducing the need for multiple ESB services and ports, and ensuring seamless communication between client applications and servers without requiring them to upgrade their communication types.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If multiple ESB services and ports are used to handle diverse service request types from legacy applications, then communication compatibility is improved, but device complexity and maintenance costs increase

Engineering Contradiction:

Improvecommunication compatibilityVSAvoidESB service complexity

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent implements a universal communication port that can handle multiple service request types (SOAP, REST, legacy protocols) through a single interface. The port uses protocol detection and automatic conversion capabilities to accommodate diverse communication formats without requiring separate dedicated ports for each protocol type, thereby reducing overall system complexity while maintaining broad compatibility.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Solution Approach 2:

The patent introduces an intermediary conversion layer within the communication port that translates between different protocol formats and the internal service representation. This mediator component handles protocol detection, format conversion, and routing decisions, allowing legacy applications to communicate with modern services through a standardized interface without direct integration complexity.

Inventive Principle:

Principle #24Intermediary (Mediator)

2Adaptability or versatility

If legacy applications are upgraded to use SOAP communication format, then interoperability with Web Service servers is improved, but implementation costs and time increase

Engineering Contradiction:

ImproveinteroperabilityVSAvoidupgrade cost

Core Design Contradiction:

Adaptability or versatilityVSEase of manufacture

Solution Approach 1:

Instead of requiring legacy applications to upgrade to SOAP format, the patent inverts the approach by enabling the communication port to adapt to and convert from legacy formats. The system accepts diverse input formats from existing applications and internally converts them to the appropriate service representation, eliminating the need for costly application upgrades while maintaining interoperability.

Inventive Principle:

Principle #13The other way round (Inversion)

Solution Approach 2:

The communication port implements self-service capabilities through automatic protocol detection and format conversion. When a service request arrives, the port autonomously identifies the protocol type, performs necessary conversions, and routes the request appropriately without requiring manual configuration or intervention, thereby reducing implementation and maintenance costs.

Inventive Principle:

Principle #25Self-service

3Device complexity

If a common communication port is used to receive diverse service requests, then device complexity is reduced, but the ability to handle specific communication types accurately may worsen

Engineering Contradiction:

Improveport configurationVSAvoidprotocol handling accuracy

Core Design Contradiction:

Device complexityVSManufacturing precision

Solution Approach 1:

The communication port implements dynamic protocol detection and adaptation capabilities. Rather than being statically configured for a single protocol, the port dynamically identifies the incoming request format through content analysis and header inspection, then adapts its processing behavior accordingly. This dynamic approach maintains high protocol handling accuracy while preserving the simplicity of a unified port interface.

Inventive Principle:

Principle #15Dynamics

Solution Approach 2:

The patent utilizes parameter changes in message headers and content to identify and differentiate between various protocol types. The communication port monitors specific parameters such as Content-Type headers, message structure patterns, and protocol-specific markers to accurately determine the request format and apply appropriate conversion rules, thereby maintaining precision in protocol handling despite using a common port.

Inventive Principle:

Principle #35Parameter changes

Data Source

PatentUS8965952B1Processing service requests of multiple types on a common communication port for a service that accepts only one type

Publication Date: 2015.02.24 CELLCO PARTNERSHIP INC

AI summary

Web service requests, received through a common communication port in a server or network device from a variety of client applications, are analyzed to determine whether to convert one communication type request into another type. Any necessary conversions are performed, and converted and unconverted service requests of one type only are routed to a web service application that accepts only a desired communication type as input. In some circumstances, the response to the client application making the original service request is converted back into the communication type initially used although other response formats may be supported.