Working with AIA Design Patterns 25-7
25.1.4 Service Routing Pattern: How to Route the Messages to Appropriate Service Provider in AIA
Problem Requester applications should build tightly coupled services if they must send
information to a specific target system. The logic to identify the service provider, and in some cases the service provider instance when you have multiple application
instances for the same provider has to be embedded within the logic of caller service. The decision logic in the caller service has to be constantly undergoing changes as and
when either a new service provider is added into the mix or an existing service provider is retired from that mix.
For example, a customer might have three billing system implementations-two instances of vendor As billing system, one dedicated to customers who reside in
North America and the second dedicated to the customers residing in Asia-Pacific; one instance of vendor Bs billing system dedicated to customers residing in other parts of
the world. The requester service must have the decision logic to discern to whom to delegate the request.
Solution AIA recommends content-based service routing to appropriate target service
implementations to further process this message and send it to the target applications. AIA recommends externalizing the decision logic to determine the right service
provider from the actual requester application or service. This decision logic is incorporated in the routing service. This allows for declaratively changing the message
path when unforeseen conditions occur. The Enterprise Business Service acts as a routing service. This facilitates one-to-many message routing based on the
content-based filtering. A message originating from a requester can go to all the targets, some of the targets, or just one of the targets based on the business rules or
content filters.
The routing service evaluates the rule and deciphers the actual service provider that must be used for processing a specific message. Using this approach, the clients or
service requesters are totally unaware of the actual service providers. Similarly, the underlying service providers are oblivious to the client applications that made the
request. This enables you to introduce new providers and retire existing providers without making any changes to the actual requester service.
Figure 25–5 illustrates how a request sent by Req Impl Service requester service is
sent to either one of two target applications or to a trading partner B2B using context based routing by routing service.
25-8 Developers Guide for Oracle Application Integration Architecture Foundation Pack
Figure 25–5 Content-Based Service Instance Routing
Impact For the requester service to be loosely coupled with the actual service providers, the
routing service should act as the abstraction layer; therefore, its service interface has to be carefully designed. Its interface can emulate the actual service providers interface if
only one unique service provider exists or it can have a canonical interface.
Even though Mediator technologies allow for routing rules to be added in a declarative way, validation of different routing paths must be tested before deploying
them in production.
Managing the decision logic locally in each of the routing services can lead to duplication as well as conflict so having them managed in a centralized rule
management system such as Oracle Business Rules Engine is an option to be considered.
25.1.5 Competing Consumers Pattern: How are Multiple Consumers used to Improve Parallelism and Efficiency?
Problem When the requester application produces a huge number of business messages which
should be handled and sent to the target application, consuming all the messages to meet the expected throughput is a challenge. This becomes much more profound
when the processing of each message involves interacting with a multitude of systems thereby resulting in blocking for a significant period of time waiting for them to
complete their work.
For example, the order capture application submits orders in the order processing queue for the fulfillment of orders. Each of the order fulfillment requests must be
picked from the queue and handed over to the order orchestration engine for decomposition. Only upon the acknowledgment can the next message be picked up
Working with AIA Design Patterns 25-9
from the order processing queue. Unplanned outages of the order orchestration platform can result in a large accumulation of order fulfillment requests and serial
processing of these requests upon availability of platform can cause an inordinate amount of delay.
Solution AIA recommends setting up multiple consumers or listeners connected to the source
queue. AIA assumes that the requester application has published messages into the source queue.
Refer to Section 25.1.2, Asynchronous Fire-and-Forget Pattern
for more details. Figure 25–6
shows that setting up multiple listeners triggers consumption of multiple messages in parallel. Even though multiple consumers are created to receive the
message from a single queue Point-to-Point Channel, only one of the consumers can receive the message upon the delivery by JMS. Even though all of the consumers
compete with each other to be the receiver, only one of them ends up receiving the message. Based on the business requirements, this pattern can be used across the
nodes with each consumer set up on each node in an HA environment, or on a cluster to improve the scalability, or within the AIA artifact.
Figure 25–6 Setting Up Multiple Consumers or Listeners Connected to the Source Queue
Impact This solution only works for the queue and cannot be used with the Topic
Publish-Subscribe channel. In the case of Topic, each of the consumers receives a copy of the message.
Since multiple consumers are processing the messages in parallel, the messages are not processed in a specific order. If they must be processed in sequence without
compromising parallelism and efficiency for a functional reason, then you must introduce a staging area to hold these messages until a contiguous sequence is
received before delivering them to the ultimate receivers.
25-10 Developers Guide for Oracle Application Integration Architecture Foundation Pack
25.1.6 Asynchronous Delayed-Response Pattern: How does the Service Provider Communicate with the Requester when Synchronous Communication is not Feasible?
Problem When a service provider has to take a large amount of time to process a request, how
can the requester receive the outcome without keeping the requester in a suspended mode during the entire processing?
For example, the order capture application submits a request for fulfillment of an order. The order fulfillment process itself could take anywhere from several minutes to
several days depending upon the complexity of tasks involved. Even though the order capture application would like to know the outcome of the fulfillment request, it
cannot afford to wait idly until the process is completed to know the outcome.
Solution AIA recommends using the asynchronous delayed response pattern where the
requester submits a request to the integration layer and sets up a callback response address by populating the metadata section in the request message WSA Headers.
The callback response address points to the end point location of the original callers service that is contacted by service provider after the completion. Since multiple
intermediary services are involved before sending the message to the ultimate receiver, sending the callback address using the metadata section in the message is needed. In
addition to the callback address, the requester is expected to send correlation details that allow the service provider to send this information in future conversations so that
the requesters are able to associate the response messages with the original requests.
Since a request-delayed response pattern is asynchronous in nature, the requester does wait for the response after sending the request message. In the flow implementing this
pattern as shown in Figure 25–7
, it is recommended that all of the services involved have two one-way operations. A separate thread must be invoked to initiate the
response message. When the AIA provider service processes the message after getting a reply from the provider participating application, it creates a response thread by
invoking the response EBS. The response EBS uses the WSA headers to identify the requesting service and processes the response to invoke the callback address given by
the requesting application. The EBS has a pair of operations to support two one-way calls - one for sending the request and another for receiving the response. Both the
operations are independent and atomic. A correlation mechanism is used to establish the application or callers context.
Figure 25–7 Example of the Asynchronous Delayed Response Pattern
Working with AIA Design Patterns 25-11
Impact Provider applications must have the capability to persist the correlation details and the
callback address sent by the requester application and need these details populated in the response message.
25.1.7 Asynchronous Request Response Pattern: How does the Service Provider Notify the Requester Regarding the Errors?
Problem Integration architects should understand the transactional requirements, the
participating applications capability of participating in a global transaction, and the concept of milestones before deciding upon the asynchronous request-response
pattern implementation. The following sections present implementation solution guidelines for three different scenarios.
Solution: Success scenario calls the same requester but separate service for the Error Handling
In this solution, the interaction is divided into two transactions; that is, the error handling part is separated from the requester ABCS implementation. A new service
should be constructed to accept the error message from the response EBS and the error response service should forward it to the source participating application.
Figure 25–8 shows that if the request is processed successfully, then it is routed back to
the requester ABCS to complete the remaining process activities. If there is any error while processing the response, it follows the normal error handling mechanism and a
notification is sent back to the source participating application. If the error is sent back to the caller, then a web service call to the error response service should be made in the
error handling block of the requester ABCS implementation.
Figure 25–8 Example of Interaction Divided into Two Transactions: Error Handling and Requester ABCS
Solution: Using JMS Queue as a milestone In this solution, the interaction is divided into three transactions. The JMS queue
milestone should be used to enable the transaction boundaries. Figure 25–9
depicts the
25-12 Developers Guide for Oracle Application Integration Architecture Foundation Pack
error scenario. The success scenario will not have the JMS-2 queue. Instead the provider ABCS directly invokes the response EBS. So, for the success scenario, the
whole interaction is completed in two transactions.
Figure 25–9 Error Scenario when Using JMS Queue as a Milestone
Solution: Using parallel routing rule and Web Service call In this solution, the interaction is divided into three transactions.
Figure 25–10 depicts
the error scenario. The parallel routing rule in the mediator EBS and a web service call from the provider ABCS reference to response EBS should be used to enable the
transaction boundaries. The success scenario directly calls the response EBS using an optimized reference component binding. So, there would be only two transaction
boundaries for the success case.
Working with AIA Design Patterns 25-13
Figure 25–10 Error Scenario Using Parallel Routing Rule and Web Service Call
25.2 AIA Assets Centralization Patterns
Kategori