Receiver-Processor-Dispatcher Inbound Connector Architecture
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The J2EE Connector Specification does not provide detailed guidance on how connectors should handle inbound communication, specifically how to solicit and accept messages from Enterprise Information Systems (EIS), select message endpoints, and manage message delivery to the appropriate components within application servers.
Innovation Solution
The implementation of a Receiver-Processor-Dispatcher (RPD) architecture for inbound connectors, which segments the message delivery process into receiving messages from EIS, processing to determine the appropriate message endpoints, and dispatching messages to those endpoints, providing a common framework with customizable components for specific EIS and application requirements.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If the connector delivers incoming messages only to one or more message-driven beans (MDBs) as mandated by the J2EE Connector Specification, then the system maintains compliance with the standard, but the flexibility to deliver messages to other application components is restricted
Solution Approach 1:
The connector is divided into distinct functional components: a receiver component that receives messages from the EIS, a processor component that determines the destination, and a dispatcher component that delivers messages to the appropriate application component. This segmentation allows the connector to go beyond the standard MDB delivery requirement while maintaining modularity and manageability.
Solution Approach 2:
The dispatcher component is designed to deliver messages to multiple types of application components including MDBs, session beans, and other enterprise beans. This multi-functionality allows the same connector architecture to serve both standard J2EE requirements and extended delivery needs without requiring separate specialized components.
2Ease of manufacture
If the connector uses a common framework for handling inbound messages from various EISs, then the ease of implementation is improved, but the ability to handle EIS-specific communication protocols may be compromised
Solution Approach 1:
The receiver component is designed to be customizable for specific EIS protocols while the processor and dispatcher components remain standardized. This allows the connector to use a common framework for message processing and delivery while maintaining the ability to handle EIS-specific communication protocols through localized customization of the receiver component.
Solution Approach 2:
The processor component acts as an intermediary between the receiver and dispatcher, standardizing the message format and processing logic. This intermediary layer allows EIS-specific protocols to be handled at the receiver level while the core processing and dispatching mechanisms remain generic and reusable across different EIS connections.
3Measurement precision
If the connector processes and determines message endpoints synchronously, then the message delivery accuracy is improved, but the message processing speed may be reduced
Solution Approach 1:
The system dynamically adjusts the processing mode based on the specific message and routing requirements. For complex routing scenarios requiring high accuracy, synchronous processing is used. For simpler messages or when throughput is prioritized, asynchronous processing is employed. This dynamic approach allows the connector to optimize between accuracy and speed based on real-time conditions.
Solution Approach 2:
The processor performs partial processing of message routing information in advance, determining the general destination category before full synchronous processing. This allows the system to handle messages more quickly for routine cases while maintaining the option for detailed synchronous processing when precision is required, thus achieving acceptable throughput without completely sacrificing accuracy.
Data Source
AI summary
System and method for receiving inbound messages from external systems and delivering the messages to applications within application servers are described. Embodiments may provide implementations of a Receiver-Processor-Dispatcher (RPD) architecture for inbound connectors that segments the work of delivering inbound messages from an Enterprise Information System (EIS) to an application into the discrete stages of receiving messages from the EIS, processing the messages to determine which components in the application should receive the messages, and dispatching the messages to the components. The delivery of messages from an EIS to an application is performed by receiver, processor, and dispatcher components of an RPD connector. RPD connectors implemented according to the RPD architecture may provide a common framework for delivering messages from an EIS to an application. Developers may implement RPD connectors according to the common framework, while customizing the RPD connectors according to the particular requirements of the EIS and/or application.