C＃Web服务在返回响应后执行某些操作

Question

I have a web service called S

My client have a web service called C

• My client send a request to my web service ( web service S )
• Web service S will send a response to client ( C )
• After that, my service ( S ) will create 1 invoice message and send it to client web service ( C )
• Client web service return result to my web service ( S )

How to implement it?

Answer 1

As I understand, you want to return a response to client app, but still continue with some processing. There are a few possibilities here:

1. Start a new thread in 2., that will create the invoice and send it to client WS. This however can be error-prone - your web service might die or be shut down in the middle of creating the invoice and client WS will never know.
2. Use something like hangfire to schedule invoice creation. Hangfire stores scheduled tasks in DB, so it will be eventually executed, even in case of failure. This does not require additional configuration other than setting up the backend db. Processing happens in the same hosting process of your Service.
3. Use a ServiceBus or MSMQ - the idea is simmilar as with Hangfire - you send a message (saying like "create invoice with parameters X") to the Bus, the Bus makes sure the message gets delivered to anyone that listens for it. Then you register a listener that would handle that kind of message and create the invoice. This would require more work, since you have to choose the Service Bus engine , take a moment to understand it, install, configure, etc.

Answer 2

This is a good case for a domain event. I don't know what the first request is - perhaps placing an order? When the order is placed then you would raise an event indicating that an order was placed. The event could contain either some information about the order or a reference (id) that can be used to retrieve it. Then other listeners would respond accordingly.

One benefit is that it keeps different parts of your application decoupled. For example, the class that submits an order doesn't need to know that there's going to be an invoice. It just raises an event indicating that an order has been placed and then goes on its way.

That becomes even more important if you want to have multiple behaviors when an order is placed. Perhaps you also want to send an email confirming that your received the order. Now you can add that additional behavior as an event listener with no modification to the code that places the order.

Also, your application could grow so that perhaps there's another service for placing orders. (I'm running with "placing orders" although I don't know what the specific event is.) You don't want multiple points in your application that follow all of the post-ordering steps. If those steps change then you'd have to modify code in all of those places. Instead you just raise the event.

Here's a popular article that describes the concept well. There are numerous implementations of an event bus. Here's one .

In pseudocode, you could now have a few event handlers, each of which is completely decoupled from your ordering code.

The event itself is raised immediately after the order is submitted.

var order = SubmitOrder(info); 
eventBus.Raise(new OrderSubmitEvent(order));

Then you have some event handlers which are registered to respond to that event.

public class SendInvoiceOrderEventHandler : IEventHandler<OrderSubmitEVent>
{
    public void HandleEvent(OrderSubmitEvent e)
    {
        //e contains details about the order. Send an invoice request
    }
}

public class SendConfirmationOrderEventHandler : IEventHandler<OrderSubmitEVent>
{
    public void HandleEvent(OrderSubmitEvent e)
    {
        //send an email confirmation
    }
}