Protocol-Neutral Application Server Using Actor-Based Event Broker
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Traditional web applications built using HTTP Servlet specifications are limited by their interaction models, leading to conflicts when interacting with multiple and diverse protocols, resulting in unsupported applications or un-maintainable workarounds, and lack of protocol neutrality, concurrency, atomicity, and fault tolerance.
Innovation Solution
A protocol-neutral application server employing an actor-based model with an event broker layer for asynchronous event handling, allowing multiple protocols to be consumed in one process and decoupling the programming model from specific protocols, using a basic toolkit layer and CSP adaptation layer for protocol abstraction and state management.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If traditional HTTP Servlet specifications are used for web application development, then the application can be built using established web protocols, but the application becomes limited and conflicts arise when interacting with multiple diverse telecommunications protocols
Solution Approach 1:
The patent introduces an event broker as an intermediary layer between protocol adapters and application components. This event broker receives events from multiple protocol adapters (SIP, HTTP, SMTP, etc.) and routes them to appropriate application components without requiring the components to understand protocol-specific details. This mediator architecture enables the application to interact with multiple diverse protocols while maintaining a unified, simplified internal structure, directly resolving the contradiction between protocol versatility and structural complexity.
2Reliability
If protocol-specific entry points are implemented for each protocol, then each protocol can be handled according to its specific requirements, but the programming model becomes coupled to particular protocols and loses neutrality
Solution Approach 1:
The patent implements a universal event broker that handles multiple protocol types through a single, protocol-agnostic interface. The event broker is designed to work with any protocol that implements the standard adapter interface, making it multi-functional rather than protocol-specific. This universal approach allows the system to maintain reliability for protocol-specific handling while simultaneously achieving protocol neutrality, as the same event broker infrastructure serves all protocols equally without being coupled to any single protocol's entry points.
3Adaptability or versatility
If multiple protocols are integrated into a single application process, then the application can span multiple environments and protocols, but the concurrency and state management become more complex
Solution Approach 1:
The patent segments the application architecture into distinct, loosely-coupled components: protocol adapters, event broker, and application components. Each protocol adapter handles a specific protocol independently, and each application component manages its own state and concurrency requirements. This segmentation allows multiple protocols to be integrated in a single process while keeping concurrency management simple, as each component operates independently with well-defined interfaces through the event broker, eliminating the need for complex global concurrency control mechanisms.
Data Source
AI summary
An application server is described for development of telecommunications-based software applications. The application server provides a protocol-neutral programming model for application developers. Rather than having to account for specific protocol entry points into the server, all interactions in the server are abstracted as asynchronous events through the event broker layer. State management and concurrency are implemented as an actor-based model, where each actor owns its own segment of state and other actors wishing to update that state send asynchronous events to the owner. Thus, any communication in the various protocols can be expressed as an asynchronous event passed to, from and between the actors, who are each responsible for maintaining their own segment of state locally. This architecture allows multiple protocols to be consumed in one process, allow applications sessions to span multiple environments and protocols, and allows the programming model to be decoupled from any particular protocol entry point.