Delayed Response Pattern (Top)

If the response to an event does not need to be produced when the stimulus is detected, then the original event can be mapped into the delayed response pattern. The events in this pattern are:

Event: Client Makes Request
Message Stimulus:	Receive Request from Client
Update Response:	Create need response entry.
Update Response:	Save stimulus.

Event: Client Expects Response
Temporal Stimulus:	It is time to respond to the client.
Update Response:	Delete need response entry.
Message Response:	Send Response to Client

Note that the event that produces the response is usually a temporal event. However, in many practical situations, a temporal event that is processed in an automated partition is actually triggered by an operator in the manual partition who informs the automated partition that the time for the event has arrived.

The essential requirements may already contain a number of these patterns because it may be essential to delay the response to some event. But, when we assign different processing cycles and types to an event stimulus and response(s), we introduce new delayed response event patterns.

Processing Cycles (Top)

If the non-functional requirements allow the response to an event to be delayed, we can usually generate the responses for multiple events using a batch process that runs at a slower cycle than the detection of the stimulus. For example, consider the following essential event:

Event: Shipping Ships Order
Message Stimulus:	Receive Order Shipped Notice from Shipping
Update Response:	Update order state to invoiced.
Message Response:	Send Invoice to Customer.

Now, suppose the non-functional requirments require or permit us to make the following design choices:

• the shipped notice is received electronically at any time.

• the invoice must be delivered on paper using regular mail.

• the invoice is prepared and printed by the automated partition using a batch process that is run on a daily cycle.

These choices have several consequences:

• the essential event is split by the automation boundary.

• the response must be delayed.

Suppose that we also make the following design choice:

• the manual partition will start the batch process that produces the invoices by sending a message to the automated partition (usually by selecting the process from a menu).

This leads to the following practical events:

• Manual Partition (delegation pattern)
  

  Event: Customer Needs Invoice
  Temporal Stimulus:	It is time to prepare the day's invoices.
  Message Response:	Select "Prepare Invoices" from system menu.

  Event: Automated Partition Completes Invoices
  Message Stimulus:	Receive Invoices Printed Message with audible beep alert.
  Message Response:	Mail Invoices to Customers

  Event: Automated Partition Fails to Complete Invoices
  Temporal Stimulus:	It is ....
  Message Response:	Notify Systems Group

• Automated Partition (delayed response pattern)
  

  Event: Shipping Ships Order
  Message Stimulus:	Receive Order Shipped Notice from Shipping
  Update Response:	Update order state to shipped.

  Event: Operator Requests Invoice Preparation
  Message Stimulus:	Operator selects "Prepare Invoices"
  Update Response:	Update each shipped order state to invoiced.
  Message Response:	Send each invoice to printer.
  Message Response:	Send Invoices Printed Message to Operator with audible beep alert.

These interactions are illustrated in Figure 2.

Figure 2: Practical Event Interactions

Note that this scenario is a combination of the delayed response pattern because of the delay in sending the invoices and the delegation pattern because the essential event was split by the automation boundary. Also note the use of invoice states to keep track of the current state of each order.