cqrs eventstore dispatching to via web service

Question

Other than latency, is there a significant disadvantage to looping through a list of web services to post the event?

Dispatcher(event) {
    var services = getServices();
    for each service in services {
        callService(service, event);
    }
}

Edit:
As opposed to what? – Peter Ritchie

• Using web services as opposed to MSMQ or nServiceBus.

Other questions – Ruben Bartelink

• Using joliver's eventstore.
• A webservice would be a webapi restfull service (internally) or third party service that is "subscribed" to the event.
• Looping through the web services because each web service is an address that needs dispatching.
• No c# code yet because I haven't gotten to that point, yet.
• I'm still evaluating technologies across the project, had a question, decided to put it out here on stack overflow to see what everyone might be doing.

Supplemental info from my research yesterday:
In terms of choosing a communication method, its useful to know about enterprise service bus (ESB)http://en.wikipedia.org/wiki/Enterprise_service_bus. In the .net world, nservicebus seems to be popular, but is not free, and mass transit is free, but I'm having trouble building and running the samples. T.T

A good general overview of messaging vs web services by one of they guys behind mass transit: http://blip.tv/ineta-live/event-driven-architecture-by-chris-patterson-north-dallas-net-ug-on-02-03-2010-3193457

Answer 1

Publishing events by calling various web services directly from your user facing application layer may prove troublesome if:

1. The remote service is not available,
2. the remote service is broken and returns unexpected error codes,
3. the remote service is slooooow and your users are no big fans of waiting around,
4. etc.

By publishing the events via a queue to some working application, resposible for invoking the various web serivces, your front end application need not fail due to any of the above.