Synchronous Request-Reply Pattern: How to get Synchronous Response in AIA

25 Working with AIA Design Patterns 25-1 25 Working with AIA Design Patterns This chapter discusses the design patterns used in Oracle Application Integration Architecture AIA and provides solutions to specific problems that you may encounter. This chapter includes the following sections: ■ Section 25.1, AIA Message Processing Patterns ■ Section 25.2, AIA Assets Centralization Patterns ■ Section 25.3, AIA Assets Extensibility Patterns

25.1 AIA Message Processing Patterns

This section discusses AIA message processing patterns and provides solutions to specific problems that you may encounter. This section includes the following topics: ■ Section 25.1.1, Synchronous Request-Reply Pattern: How to get Synchronous Response in AIA ■ Section 25.1.2, Asynchronous Fire-and-Forget Pattern ■ Section 25.1.3, Guaranteed Delivery Pattern: How to Ensure Guaranteed Delivery in AIA ■ Section 25.1.4, Service Routing Pattern: How to Route the Messages to Appropriate Service Provider in AIA ■ Section 25.1.5, Competing Consumers Pattern: How are Multiple Consumers used to Improve Parallelism and Efficiency? ■ Section 25.1.6, Asynchronous Delayed-Response Pattern: How does the Service Provider Communicate with the Requester when Synchronous Communication is not Feasible? ■ Section 25.1.7, Asynchronous Request Response Pattern: How does the Service Provider Notify the Requester Regarding the Errors?

25.1.1 Synchronous Request-Reply Pattern: How to get Synchronous Response in AIA

Problem Many use cases warrant consumers to send requests synchronously to service providers and get immediate responses to each of their requests. These use cases need 25-2 Developers Guide for Oracle Application Integration Architecture Foundation Pack the consumers to wait until the responses are received before proceeding to their next tasks. For example, Customer Relationship Management CRM applications may provide features such as allowing customer service representatives and systems to send requests to providers for performing tasks such as account balance retrieval, credit check, ATP advanced time to promise calculation, and so on. Since CRM applications expect the responses to be used in the subsequent tasks, this precludes the users from performing other tasks until the responses are received. Solution AIA recommends using the synchronous request and response service interface in all the composites involved in processing or connecting the back-end systems. There should not be any singleton service in the services involved in the query processing. The general recommendation is for all of the intermediary services and the service exposed by the provider application to implement a request-response based interface - a two-way operation. Even though it is technically possible to design all services but the initial caller to implement two one-way requests, this implementation technique should be avoided if possible. Implementation should strive to ensure that no persistence of state information dehydration or audit details is done by any of the intermediary services or by the ultimate service provider. These techniques help keep the latency as low as possible. AIA also recommends that the intermediary services are co-located to eliminate the overheads normally caused by marshalling and un-marshalling of SOAP documents. Figure 25–1 illustrates how a business task implemented as an Enterprise Business Service EBS is invoked synchronously by the requester application. Figure 25–1 Invoking an EBS Synchronously by the Requester Application Impact ■ All the resources are locked in until the response from service provider goes back to the originating system or user. ■ Either a transaction timeout or an increased latency may result if any of the services or the participating application takes more time for processing. ■ Service providers must be always available and ready to fulfill the service requests. ■ Service providers doing real-time retrieval and collation of data from multiple back-end systems in order to generate a response message could put an enormous toll on the overall resources and increase the latency. The synchronous request-response design pattern should not be used to implement tasks that involve real-time complex processing. Off loading of work must be done; the design must be modified to accommodate the staging of quasi-prepared data so that the real-time processing can be made as light as possible. Working with AIA Design Patterns 25-3 ■ Services involved in implementing synchronous request-response pattern should refrain themselves from doing work for each of the repeatable child nodes present in the request message. A high number of child nodes in the payload in a production environment can have an adverse impact on the system.

25.1.2 Asynchronous Fire-and-Forget Pattern