Voice Browser EJB Scalability via J2EE Mediator
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current voice browser implementations face challenges in scalability and efficiency due to their stand-alone nature, requiring complex routines for managing distributed components and incurring latencies, making it difficult to implement them as platform-independent middleware components.
Innovation Solution
A voice browser is developed as an Enterprise Java Bean (EJB) within a middleware solution like WebSphere Application Server, allowing it to leverage J2EE infrastructure and interoperate with remote services, reducing software overhead and latency.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If a voice browser is implemented as a stand-alone solution, then it can independently manage distributed software segments and process tasks from multiple clients, but it requires complex routines for managing distributed components and prioritizing tasks, increasing device complexity and software overhead
Solution Approach 1:
The patent introduces an EJB container as an intermediary between the voice browser and the distributed system resources. The container manages the complexity of distributed component management, task prioritization, and resource allocation, while the voice browser focuses on its core functionality. This mediator pattern resolves the contradiction by offloading complex management routines to a specialized intermediary component.
Solution Approach 2:
The patent segments the voice browser into two distinct parts: the voice browser EJB itself (handling core voice processing functions) and the EJB container (handling distributed system management). This segmentation allows each component to specialize in its specific function, reducing the complexity within each segment while maintaining overall system independence.
2Productivity
If a voice browser is implemented as a stand-alone solution, then it can process real-time voice tasks, but external interface usage adds inefficiencies resulting in latencies that are unacceptable for real-time processing
Solution Approach 1:
The patent merges the voice browser with the EJB container, allowing them to reside in the same program space and communicate through efficient internal mechanisms rather than external interfaces. This combining eliminates the latency associated with external interface calls while maintaining real-time processing capability. The voice browser EJB can directly access container services without crossing process boundaries.
3Adaptability or versatility
If a voice browser is implemented as a distributable middleware component, then it can leverage J2EE infrastructure for security, task management, and signal routing, but it requires components to interoperate within a single program space or use external interfaces, creating a trade-off between infrastructure leverage and processing efficiency
Solution Approach 1:
The EJB container serves as an intermediary that provides J2EE infrastructure services (security, task management, signal routing) directly to the voice browser EJB through efficient internal mechanisms. This intermediary pattern allows the voice browser to leverage full J2EE infrastructure capabilities while avoiding the latency of external interface calls, as both components operate within the same container environment.
Data Source
AI summary
A system for implementing voice services can include at least one virtual machine, such as a Java 2 Enterprise Edition (J2EE) virtual machine. The virtual machine can include a bean container for handling software beans, such as Enterprise Java Beans. The bean container can include a voice browser bean. The voice browser bean can include a VoiceXML browser.