Is it a good idea to implement middleware design for my non-HTTP business logic?

Most of us are now used to HTTP middlewares from recent implementations, starting with node.js ecosystem. We also have some business logic (in a separate business logic library that applications extend) that can be quite layered. This is more like a queue of operations (services in code), that respond to an external message given to this whole component, FILO style.

Pseudo-code would read something like this:

inviteFriendsOperation = createFIFOQueue(message)
inviteFriendsOperation.add(PrepareFriendsList)
inviteFriendsOperation.add(RemoveFamily)
inviteFriendsOperation.add(SendMobilePush { delete successfully pushed friends from message.friendList })
inviteFriendsOperation.add(SendWebPush { delete successfully pushed friends from message.friendList })
inviteFriendsOperation.add(SendEmail { here, message.friendList only contains those who failed for mobile and web push})
updatedMessage = inviteFriendsOperation.run()

print updatedMessage.successfulMobilePushes
print updatedMessage.successfulWebPushes
print updatedMessage.successfulEmails
print updatedMessage.friendList

So we would create a queue of objects that execute operations and update message that was sent to the queue. It starts running in the order of add, reaches SendEmail and then runs back to the first operation ending at PrepareFriendsList. It finally returns the updated message as the result of whole operation.

message would have a strongly applied interface, so misunderstandings would be minimalized.

Apart from HTTP middlewares, I haven't seen this pattern applied very often and when I researched, I found results for system architecture patterns, rather than code.

Is this a good method? Can you point me to some examples/papers/articles?