Persistent Finite State Machine for Service Broker Lifecycle Coordination
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Creating and maintaining applications across various platforms and multi-cloud computing environments is challenging for independent software vendors, as existing technologies lack a unified and efficient method for managing service lifecycle operations across different infrastructure and technologies.
Innovation Solution
Implementing a persistent finite state machine within the Open Service Broker API (OSB API) computing environment to coordinate distributed transaction workflows, including asynchronous instance OSB API lifecycle operations that span multiple entities, ensuring secure, automatic, and efficient creation of OSB API-compliant functions.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If a service broker manages lifecycle operations across multiple cloud platforms and technologies, then the system's adaptability and versatility improve, but the device complexity and difficulty of coordination increase
Solution Approach 1:
The patent segments the complex service lifecycle management into distinct finite states (e.g., CREATE, UPDATE, DELETE, FAIL) and transitions. Each state represents a specific operational phase, breaking down the monolithic coordination problem into manageable state-specific handling logic. This segmentation allows the service broker to manage multiple cloud platforms by treating each platform interaction as a state transition rather than a complex integrated problem.
Solution Approach 2:
The finite state machine acts as an intermediary layer between the service broker and multiple cloud platforms. Instead of directly managing complex interactions with each platform, the system uses the FSM as a mediator that standardizes lifecycle operations. The FSM receives high-level lifecycle commands and translates them into platform-specific state transitions, isolating the complexity of multi-platform coordination within the state machine's transition logic.
2Productivity
If asynchronous lifecycle operations span multiple entities, then the productivity and automation level improve, but the reliability and consistency of transactions deteriorate
Solution Approach 1:
The patent implements feedback mechanisms through state transitions and persistence. Each asynchronous operation updates the FSM state, and the current state is persisted to storage. This creates a feedback loop where the system continuously monitors operation status through state changes. If an operation fails or completes, the state transition reflects this, allowing the system to track and ensure transaction consistency across multiple entities while maintaining high productivity through asynchronous processing.
Solution Approach 2:
The system prepares for potential failures by implementing compensation logic within state transitions. Before committing changes across multiple entities, the FSM can enter intermediate states that allow for rollback or compensation operations. This beforehand cushioning ensures that if an asynchronous operation fails partway through, the system can recover and maintain consistency, preserving reliability while allowing asynchronous productivity.
3Stability of the object's composition
If state persistence is implemented across restarts, then the stability and reliability improve, but the use of energy and storage resources increase
Solution Approach 1:
The patent applies local quality by persisting only the essential FSM state information rather than entire system states. The persistence mechanism stores compact state representations (current state, history, compensation status) that are minimal yet sufficient for recovery. This selective local persistence maintains system stability across restarts while minimizing energy consumption and storage usage by avoiding redundant or unnecessary data retention.
Data Source
AI summary
Methods and systems may be associated with an Open Service Broker (“OSB”) Application Programming Interface (“API”) computing environment. A persistent finite state machine may be associated with an OSB API service broker, and a database may store a current state of the service broker. A computer processor of a state machine executor may retrieve the current state of the service broker from the database, and (based on the current state) use the persistent finite state machine to coordinate a distributed transaction workflow for the service broker, the distributed transaction workflow including asynchronous instance OSB API lifecycle operations that span multiple entities. The state machine may then update the database with state outputs for the service broker.