Service Virtual Machine Interoperability
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing programming languages lack a unified mechanism to seamlessly invoke and manage virtual procedures and objects across different programming units, leading to complexity in interoperability and request forwarding between services.
Innovation Solution
The implementation of a Service Virtual Machine (SVM) that translates virtual programming unit invocations into native ones, providing an abstraction layer to support virtual procedures and objects by using Procedure IDs, Object IDs, and Service IDs, and enabling request forwarding through a network of interconnected SVMs.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If programming languages use hardcoded procedure names and manual reference management, then procedures can be invoked within the same language, but interoperability between different programming units and languages becomes complex and difficult to manage
Solution Approach 1:
The patent introduces an Actor Virtual Machine (AVM) as an intermediary layer between different programming units and languages. The AVM provides a standardized virtual procedure invocation mechanism that translates diverse calling conventions into a unified interface, enabling seamless interoperability without direct complexity management between different programming units.
Solution Approach 2:
The AVM implements a universal virtual procedure interface that can handle invocations from various programming units (procedures, objects, classes) and different programming languages through a common mechanism. This universal interface accepts virtual procedure names, parameter lists, and optional reply-to specifications, making it adaptable to diverse invocation scenarios.
2Adaptability or versatility
If programming languages provide standalone procedures and object methods with hardcoded references, then local invocation works, but distributed service invocation and request forwarding become complex
Solution Approach 1:
The AVM acts as a mediator for distributed service invocation by providing a uniform virtual procedure calling mechanism. Whether the target is a local procedure or a remote service, the caller uses the same virtual procedure invocation syntax with an optional reply-to parameter, and the AVM handles the complexity of distributed communication transparently.
Solution Approach 2:
The patent implements a reply-to mechanism where callers can specify a reply-to virtual procedure name. This creates a feedback loop for asynchronous operations and distributed service responses, allowing the system to automatically route responses back to the appropriate caller without manual intervention, simplifying distributed invocation management.
3Reliability
If programming languages require explicit reference management for procedures and objects, then type safety is maintained, but the overhead of managing references and pointers increases operational complexity
Solution Approach 1:
The patent uses virtual procedure names as copies or abstractions of actual procedure identifiers. Instead of managing complex object references and pointers, the system uses simplified virtual names that the AVM resolves to actual targets. This copying approach maintains type safety through the structured virtual procedure interface while reducing operational overhead by eliminating direct reference management.
4Adaptability or versatility
If programming languages use procedural organization with hardcoded names, then code structure is simple, but adaptability to objects and services is limited
Solution Approach 1:
The AVM implements a universal virtual procedure interface that works across multiple programming paradigms including procedural, object-oriented, and service-oriented programming. The same virtual procedure invocation mechanism handles calls from standalone procedures, object methods, and distributed services, providing multi-paradigm support without requiring separate invocation syntax for each paradigm.
Solution Approach 2:
The patent segments the invocation system into two independent layers: the caller side uses simple virtual procedure names and parameters, while the AVM layer handles the complexity of resolution, dispatch, and response routing. This segmentation allows each layer to remain simple while the system as a whole supports multiple programming paradigms.
Data Source
AI summary
Technology is disclosed for processing in a computer program a request received by a service virtual machine (SVM). The technology can receive a request in either a first form or a second form, wherein the first form includes a target textual identifier, a reply-to textual identifier, and a parameter, and the second form includes a target textual identifier and a parameter, but not a reply-to textual identifier; identify, based on the received target textual identifier, a procedure; invoke the identified procedure and providing a value of the received parameter to the invoked procedure; in an event the received request is in the first form: receive a result from the invoked procedure; form a reply-to request in the second form, the second form including as a target textual identifier the reply-to textual identifier in the received request, and as a parameter the result received from the invoked procedure, further wherein the second form does not include a reply-to textual identifier; and send, to the SVM, the formed reply-to request.