Intermediate State Message pattern

Jump to: navigation, search
Next: Second Channel pattern | Return to ACP Patterns

This pattern first appeared in the paper "A Pattern Language for Application-level Communication Protocols"[1] published at IARA-ICSEA 2016 by Jorge Edison Lascano and Stephen Wright Clyde (authors of the page).

Intermediate State Message pattern

Name and Overview

Intermediate State Message(ISM)

The ISM pattern is perhaps the most used pattern for long-running processing requests. Instances of this pattern are found in big data processing, online bakcup systems, cloud-based storage services. It involves one process sending sending a request, that needs a long-processing time, to another process and waiting for partial replies (state1, state2, ... , staten) telling something about the state of its request. The initiator process waits for the final reply from the responder to finish the conversation.


Intermediate State Message, is similar to Request-Reply, but addresses the problem of long-running conversations due to request actions taking substantial amounts of time to complete.



A client needs to access a shared service provided by a resource manager (process B), but the execution of that service is long-running and the client would like to know when key milestones in the processing are reached. And at the end of the communication B sends the final message to A.


The processing of the request is long-running with intermediate milestones. "At most once" semantic [2] is needed.


After A sends a request to B, it has B send A one or more intermediate messages that reflect its current state. For example, B may send a message immediately after receiving the request to let A know that it got the request, another message when the processing is 10%, another at 20% complete, and so on. Each intermediate message provides state information about B, which improves synchronization in the presence of time-consuming actions. The last reply will inform A that the process has been completed, and the communication can be terminated. B disposes its temporal storage data.

In a variation, of some data needs to send back to A a piggy-backed acknowledge [3] variation implementation could be useful. Additional to the state reply, the message could carry back some information.

Process Roles

Initiator, Responder


Request, State1, State2, ..., Staten, Reply


Initiator -> |Request| -> Responder
(Responder starts some processing)
Responder -> |State1| -> Initiator
(Responder more processing)
Responder -> |State2| -> Initiator
(Responder more processing)
Responder -> |Staten| -> Initiator
(Responder more processing)
Responder -> |Reply| -> Initiator

Semantics and Behavior

  • The initiator and Responder have similar behavior to the corresponding processes in the RR pattern, except that the initiatior needs to receive the state of the processing request and waits (locked by the responder) until it receives the reply. A timeout/retry behavior is implemented based on the n-states and the reply messages.


One message is sent from A to B requesting long processing in B with a high level of Reliability and keeping both processes fully synchronized. The request is processed by B and it kept informed A about its processing request at all time.

Quality Rating Justification
This pattern can provide high level of reliability. Specially when a long running processing is sent from A to B, and B sends back temporal replies (states) informing A that its request is being processed and its condition at certain intervals, based either on time or advance of processing. If the last message or any of the temporal replies is not received by A in an established timeout, A will resend its request to assure the "at most once" semantic alongside B. Although reliability seems to be limited to the initiator, when this does not receive a reply, either a state or the reply, it can tell B that something wrong is happening, hence the responder is also aware of the state of A.
This pattern allows a complete synchronization between A and B. Specially when B receives a request from A, both processes lock each other until the final reply is sent to A. A knows everything about the state of B processing action, B does not know persistently about A, but after a timeout, if A does not receive a reply from B, this will send a duplicated request, then B knows something is happening or not.
This pattern proves a good way to manage long-running processing requests alongside a reliable implementation of the communication. The initiator must implement its timeout/reply mechanism according to a predictable time for completing the request.
Adaptability for Scalable Distribution
This pattern does not directly address scalable distribution, but could be combined with patterns that do allow for scalable distribution

Known uses

  • Remote File Managers
  • Remote backups
  • Long transaction processes
  • Remote file transfers, in some cases. This use is more directly related to the 2CH pattern though.

Aliases and Related Work


Related work

  • Long-running transactions [4]
  • REST and long-running jobs [5]. Although this is an asynchronous implementation, it is related to long-running processing needs.
  • Protocols For Long Running Business Transactions [6].

Although the next three implementations are directly related to multiple responders, they also deal with long-running processing requests.

  • Participation Protocol Framework [7]
  • WS Coordination Framework, which supports long-running transactions. [8]
  • Collaboration Protocol Agreement [9]

Examples of Application

Implementations of this type of behavior are file transfer protocol applications such as ftp (RFC959 [10] or wget. Also Remote Backup Services [11] such as those provided by Cloud Computing storage and database services. Actually, the ftp protocol is a complete implementation of a 2CH pattern, its implementation of the data connection relies on this pattern. Besides this, anything on a website with a progress bar, which may rely on web sockets is a clear implementation of the IMS pattern

FTP Data Connection Scenario [10]

(I have to look for a better example, since this looks more like a 2CH)

- Pre-connection actions ...
-  the User Data Transfer Process (DTP) sends file data to the server DTP or vice-versa.
-  the data is sent until EOF is received.
- Post-connection actions.
Next: Second Channel pattern | Return to ACP Patterns


  1. Jorge Edison Lascano, Stephen Wright Clyde, A Pattern Language for Application-level Communication Protocols, in, Proceedings of The Eleventh International Conference on Software Engineering Advances ICSEA 2016, 2016, pp. 22-30
  2. K. A. Robbins and S. Robbins, UNIX Systems Programming: Communication, Concurrency, and Threads. Prentice Hall Professional, 2003.
  3. Z. Shelby, K. Huartke, and C. Bormann, “The Constrained Application Protocol (CoAP).” [Online]. Available: [Accessed: 17-Feb-2017].
  4. “Long-running transaction,” Wikipedia. 09-May-2016.
  5. “REST and long-running jobs.” [Online]. Available: [Accessed: 09-Mar-2017].
  6. B. Kratz, “Protocols for long running business transactions,” Technical Report 17, Infolab Technical Report Series, 2004.
  7. N. Schuster, Coordinating Service Compositions : Model and Infrastructure for Collaborative Creation of Electronic Documents. KIT Scientific Publishing, 2013.
  8. “Web Services Coordination (WS-Coordination) Version 1.1 OASIS Standard incorporating Approved Errata.” [Online]. Available: [Accessed: 09-Mar-2017].
  9. K.-P. Mehdi, Consumer Behavior, Organizational Development, and Electronic Commerce: Emerging Issues for Advancing Modern Socioeconomies: Emerging Issues for Advancing Modern Socioeconomies. IGI Global, 2008.
  10. 10.0 10.1 [1]J. Postel and J. Reynolds, “File Transfer Protocol.” [Online]. Available: [Accessed: 21-Feb-2017].
  11. “Remote backup service,” Wikipedia. 23-Dec-2016.