Hot Software Deployment via Dual Engine Alternation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing hot deployment methods for mission-critical systems require additional servers or significant modifications, leading to increased costs and potential instability, and do not achieve full hot deployment as they still necessitate restarting sub-modules or the entire system during updates.

Innovation Solution

Implementing a system with at least two service processing engines that alternate between operation and wait statuses, allowing for seamless updates of service rules and settings without restarting the system, enabling dynamic updating and improved availability without the need for server backups.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If traditional hot deployment methods are used with server backup, then system availability is maintained during updates, but additional servers are required increasing cost and complexity

Engineering Contradiction:
Improvesystem availabilityVSAvoidnumber of servers
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The service processing engine is segmented into two instances (first and second service processing engines) that share the same service processing memory. This segmentation allows one instance to handle service requests while the other undergoes updates, enabling hot deployment without requiring additional servers beyond the segmented instances.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

Both service processing engines share the same service processing memory, merging the memory resource between the two engines. This shared memory architecture reduces overall system resource requirements and eliminates the need for separate backup servers, while still maintaining the ability to switch between engines for uninterrupted service.

Inventive Principle:
Principle #5Merging (Combining)

2Reliability

If the service processing engine is updated during operation, then system availability is maintained, but the entire system must be restarted which interrupts service

Engineering Contradiction:
Improvesystem availabilityVSAvoidservice interruption time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The service processing engine that is not currently handling requests is updated in advance before it needs to take over service. This preliminary action ensures that the updated engine is ready to immediately handle service requests without requiring a restart of the entire system, thus maintaining continuous availability.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system alternates between two service processing engines in periodic fashion, with one engine handling service requests while the other undergoes updates. This periodic switching allows continuous service availability while enabling regular updates without interrupting the overall system operation.

Inventive Principle:
Principle #19Periodic action

3Reliability

If multiple servers are used for hot deployment, then uninterrupted service is achieved, but system cost increases

Engineering Contradiction:
Improveuninterrupted serviceVSAvoidnumber of servers
Core Design Contradiction:
ReliabilityVSQuantity of substance

Solution Approach 1:

The two service processing engines share a common service processing memory, merging the memory resource between them. This shared memory architecture reduces overall system resource requirements and eliminates the need for separate backup servers, thereby reducing system cost while maintaining uninterrupted service capability.

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

Both service processing engines are configured to perform the same service functions and share the same service processing memory, making them universal and interchangeable. This multi-functionality allows either engine to handle service requests, reducing the need for specialized additional servers and lowering overall system cost.

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

4Adaptability or versatility

If service rules are updated frequently, then system adaptability is improved, but system stability deteriorates due to repeated restarts

Engineering Contradiction:
Improveservice rule flexibilityVSAvoidsystem stability
Core Design Contradiction:
Adaptability or versatilityVSStability of the object's composition

Solution Approach 1:

Service rules are updated in advance in the service rule library before the service processing engine needs to use them. This preliminary action allows frequent updates to service rules without requiring system restarts, as the updated rules are already prepared in the shared memory, thus maintaining both adaptability and stability.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The service processing engine continuously operates without interruption while service rules are updated in the shared service processing memory. The engine can immediately access updated rules without restarting, ensuring continuous useful action is maintained while allowing frequent rule updates for adaptability without compromising system stability.

Inventive Principle:
Principle #20Continuity of useful action

Data Source

PatentEP2539814B1Hot deployment of software
Publication Date: 2016.10.12 ALIBABA GROUP HOLDING LTD
  • EP2539814B1 patent drawingFigure 1
  • EP2539814B1 patent drawingFigure 2
  • EP2539814B1 patent drawingFigure 3

AI summary

Hot deployment of software includes: configuring a first service processing engine and a second service processing engine, wherein each of the first and the second service processing engine is configured to perform a service; setting the first service processing engine into an operation status and the second service processing engine into a wait status; detecting a change that is to affect performance of the service; and updating the second service processing engine in the wait status based at least in part on the detected change.