Following this example: https://msdn.microsoft.com/en-us/library/jj591569.aspx (Figure 3)
How it fits in a http application?
The user should perform a http request to the PlaceOrderController, which will send a PlaceOrderCommand, but how would the Order Process Manager answers the "9. Order Confirmed" to the user? How is the controller aware of that, in order to return this info to the user?
Thanks
@Hippoom points you to the right direction.
CQRS Journey (what are you reading) says:
Here we are talking about eventual consistency of milliseconds or a few seconds in the worst case. So a P-R-G pattern fits perfect.
Anyway, here and here there you can read articles about eventualy consistency UI than can help you.
POST COMMENT EDIT:
Here Udi Dahan says:
So, I think your problem is not discover how CQRS works for HTTP application. Your problem is that with the process and use cases about you are questioning you should avoid CQRS.
You simply don't answer "Order Confirmed" immediately. Take a look at how Amazon and other shopping sites do it: Upon Order submission, you just receive an "Order Accepted confirmation (e.g., HTTP Code 202 Accepted). When the actual order has been handled by the order process manager, an "Order Confirmed" notification on a separate message/channel (e.g., email) is sent to the user.
Your Web/REST api is independent of your domain model but maps to it based on your use cases and user agent needs. One way to go is the submit a "job" and then poll the job for progress. There are many tradeoffs to consider. For example depending on your infrastructure sending a notification is probably the best way to go. If you want REST/HTTP you can try this:
User Agent:
Origin Server:
User Agent: