Service Plugin Architecture for Scalable Collaborative Frameworks

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing ITSM collaboration systems face challenges in efficiently and reliably interacting with complex software application frameworks comprising numerous interdependent services and microservices, leading to substantial computational complexity and obstacles in scalable deployment due to varying authentication logics and API schemas across internal and external service components.

Innovation Solution

The implementation of service plugins with asynchronous processing queues and continuous execution threads for each service component, allowing ITSM collaboration systems to manage interactions with internal and external components efficiently by processing requests in parallel, reducing computational complexity to a constant level.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If ITSM collaboration systems interact with multiple service components using traditional synchronous processing, then the system can process requests sequentially, but the computational complexity increases substantially and scalability is limited

Engineering Contradiction:
Improverequest processing throughputVSAvoidcomputational complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The patent segments the service component interactions into separate asynchronous processing queues, with each queue dedicated to a specific service component. This segmentation allows independent processing of requests for different components, reducing the computational complexity of managing multiple service interactions simultaneously while maintaining high throughput capability.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces asynchronous processing queues as intermediary components between the ITSM collaboration system and service components. These queues act as buffers that decouple the request sender from the service component, enabling non-blocking processing and reducing the computational burden on the main system while maintaining scalability.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Adaptability or versatility

If the system uses a single processing thread for all service components, then the implementation is simple, but the system cannot efficiently handle multiple service components with varying authentication logics and API schemas

Engineering Contradiction:
Improvecapability to handle varying authentication logics and API schemasVSAvoidprocessing architecture complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent divides the processing architecture into separate threads, each dedicated to processing requests for a specific service component. This segmentation allows each thread to be optimized for its specific service component's authentication logic and API schema, enhancing adaptability while keeping the overall architecture manageable through modular organization.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent implements a dynamic processing architecture where threads are created and managed based on the specific requirements of different service components. This dynamic approach allows the system to adapt to varying authentication logics and API schemas by allocating dedicated processing resources to each component type, improving versatility without creating a monolithic complex system.

Inventive Principle:
Principle #15Dynamics

3Reliability

If the system processes all service component requests synchronously, then the implementation is straightforward, but the system lacks scalability when dealing with numerous interdependent services and microservices

Engineering Contradiction:
Improveinteraction reliability with service componentsVSAvoidscalability
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent introduces asynchronous processing queues as intermediary components that ensure reliable interaction with service components while enabling scalability. These queues act as buffers that guarantee request processing completion and maintain interaction reliability, while simultaneously allowing the system to scale by distributing processing across multiple independent threads that can handle numerous services concurrently.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent implements continuous execution threads that continuously process requests from their respective queues without interruption. This continuous processing ensures reliable service component interactions by maintaining persistent connections and processing pipelines, while also enabling high scalability through parallel continuous processing across multiple threads for different service components.

Inventive Principle:
Principle #20Continuity of useful action

Data Source

PatentUS12530203B2Collaborative software application frameworks using internal service plugins and external service plugins
Publication Date: 2026.01.20 ATLASSIAN US INC
  • US12530203B2 patent drawing
  • US12530203B2 patent drawing
  • US12530203B2 patent drawing

AI summary

Various embodiments of the present invention provide methods, apparatuses, systems, computing devices, and/or the like that are configured to enable effective and efficient solutions for designing software architecture of collaborative software application frameworks. For example, certain embodiments of the present invention provide methods, apparatuses, systems, computing devices, and/or the like that are configured to enable communications between a collaboration service computing device and a set of m service components via m service plugins comprising internal service plugins and external service plugin, where each service plugin comprises an asynchronous processing queue and a continuous execution thread.