Asynchronous Fire-and-Forget Pattern
Problem
The requester application should be able to continue its processing after submitting a
request regardless of whether the service providers needed to perform the tasks are
immediately available or not. Besides that, the user initiating the request does not have
a functional need to wait until the request is fully processed. The bottom line is, the
service requesters and service providers must have the capability to produce and
consume messages at their own pace without directly depending upon each other to
be present.
Also, the composite business processes should be able to support the infrastructure
services like error handling and business activity monitoring services in a decoupled
fashion without depending on the participating application. or the AIA functional
process flows.
For example, order capture applications should be able to keep taking orders
regardless of whether the back end systems such as order fulfillment systems are
available at that time. You do not want the order capturing capability to be stopped
because of non-availability of any of the services or applications participating in the
execution of order fulfillment process.
Solution
It recommends the fire-and-forget pattern using queuing technology with a
database or file as a persistence store to decouple the participating application from
the integration layer. The queue acts as a staging area allowing the requester
applications to place the request messages. The request messages are subsequently
forwarded to service providers on behalf of requester as and when the service
providers are ready to process them.
It is highly recommended that the enqueueing of the request message into the queue is
within the same transaction initiated by the requester application to perform its work.
This ensures that the request message is enqueued into the queue only when the
participating application's transaction is successful. The request message is not
enqueued in situations where the transaction is not successful. Care must be taken to
ensure that the services residing between two consecutive milestones are enlisting
themselves into a single global transaction.
AIA recommends having a queue per business object. All requests emanating from a
requester application for a business object use the same queue.
Figure shows how JMS queues are used to decouple the source application from
the integration layer processing. The source application submits the message to the
JMS queue and continues with its other processing without waiting for a response
from the integration layer.
The AIA composite business process may not be up and running while the application
continues to produce the messages in the JMS queue. When the AIA composite
business process comes up, it starts consuming the messages and processes them.
Figure also shows how the monitoring services can be decoupled from the main
AIA functional flows with the help of the JMS queue. All the AIA services and the
participating applications can fire a monitoring message into the queue and forget
about how it is processed by the downstream applications. In this pattern the services
or participating applications do not expect any response. Similarly, the AIA
infrastructure services capture the system or business errors from the composite
business processes and publish them to an AIA error topic, which is used by the error
handling framework for further processing (resubmission, notification, logging, and so
on).
Impact
The default implementation does not have inherent support for notifying the requester
application of success or the failure of messages. Even though the middleware systems
provide the ability to monitor and administer the flow of in-flight message
transmissions, there will be use cases where requester applications either want to be
notified or have a logical reversal of work done programmatically.
Figure : Fire-and-Forget Pattern Using Queuing Technology
