Ontology-Based Request Reply Service Dynamic Instantiation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current request-reply service (RRS) systems lack flexibility and efficiency, particularly in distributed environments, due to their reliance on standalone brokers that incur significant administration and performance overhead, and struggle with handling multiple service requests efficiently.
Innovation Solution
An ontology-based RRS system that dynamically instantiates services, manages transport connectivity, and provides a common API for clients and servers, allowing for efficient communication and service orchestration across multiple services, reducing the need for complex logic in clients and servers.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a standalone broker is used to manage request-reply services, then service communication can be provided, but administration overhead and performance overhead increase significantly
Solution Approach 1:
The patent extracts the service management functionality from a standalone broker and embeds it directly into the request-reply service mechanism itself. The service manages its own connections, routing, and communication protocols without requiring a separate broker infrastructure, thereby eliminating administration overhead while maintaining reliable service communication.
Solution Approach 2:
Each request-reply service is designed to be self-managing, handling its own connection establishment, message routing, and communication protocols. This self-service capability eliminates the need for a centralized broker to administer services, reducing administrative complexity while ensuring reliable service operation.
2Reliability
If a standalone broker is used to manage request-reply services, then service communication can be provided, but performance overhead increases
Solution Approach 1:
The patent removes the performance bottleneck by extracting the message routing and communication management functions from the standalone broker and implementing them directly within the request-reply service mechanism itself, eliminating the additional performance overhead associated with broker mediation.
Solution Approach 2:
The request-reply services perform their own message routing and communication management without requiring broker intervention, significantly reducing performance overhead and improving system throughput while maintaining reliable service communication.
3Ease of manufacture
If pre-determined APIs are used in classic RRS, then service functionality can be provided, but extensibility is lost and new functionalities cannot be captured
Solution Approach 1:
The patent introduces dynamic service definition mechanisms that allow services to be configured and extended at runtime without modifying the core RRS framework. Services can dynamically adapt to new functionalities and requirements while maintaining the established API structure, achieving both ease of manufacture and extensibility.
Solution Approach 2:
The system allows parameter changes in service definitions and configurations without requiring changes to the core RRS architecture. This enables new functionalities to be added by modifying service parameters and configurations while maintaining the stability of the underlying system, thus achieving extensibility without compromising ease of manufacture.
4Adaptability or versatility
If functionalities are combined in a travel agency API, then comprehensive service can be provided, but code sharing capability is lost
Solution Approach 1:
The patent segments the travel agency service into independent, reusable service components (flight booking, hotel booking, car rental) that can be shared and reused across different applications. Each segment maintains its own functionality while enabling code sharing through standardized interfaces, thus achieving both comprehensive service capability and code sharing.
Solution Approach 2:
The patent creates universal service components that can serve multiple functions and be reused across different applications. The segmented services maintain comprehensive functionality while being designed with universality in mind, allowing code sharing and reducing duplication across different service implementations.
Data Source
AI summary
In a method, system, or computer-readable medium for an ontology-based request/reply service (RRS), different request/reply services (RRS) are hosted, each different RRS dedicatedly represents a different unique service and provides connections from client to server instance of the unique service, each different RRS accessed by client and server instances through a same independent communication layer (ICL). A request from the client is received through the ICL. The RRS is determined by the unique service indicated in the request, and instantiated dynamically as needed, according to an individual RRS ontology which establishes a syntactical and semantical framework dedicated to the unique service. The request is routed to the RRS and then through a server instance of the unique service to process the request; then a response is returned to the client to satisfy the request. It provides transport connectivity and mutual communication between combinations of clients, different RRSs, and server instances.