Ayende doesn’t have a service bus.
Ayende has several posts about approaches to batching, but not about building ESB.
Ayende is talking about himself in the 3rd person, and is really disturbed by it.

If your requirement is batching, not an ESB, you’re best off sticking with pure WCF and not amalgamating in Ayende’s version of a service bus. In short, an ESB puts a lot of unnecessary overhead on your app if all you need is batching On the other hand, if what you need is the ability to simply fire off a message and eventually receive a response, an ESB may be the right answer. If that doesn’t make sense, spend some time reading up on ESBs and classic examples of where they are used. It’s highly unusual to see a need for an ESB in an environment where you control both server and client.

it might be… it looks interesting, allthough i’m not too happy about the following requirement:

“only messages sent from operations marked with TransactionScopeRequired = true and TransactionAutoComplete = true are considered for a batch”

Still, just from reading that i’m not sure if it actually allows me to do the same thing as i do here:
http://davybrion.com/blog/2008/06/batching-wcf-calls/

Not sure if this is what you are looking for:

http://msdn.microsoft.com/en-us/library/ms788973.aspx

I’m not sure the specific service interfaces are really that much easier to use… With the approach i use, specific service interfaces still require you to pass in a ${OperationName}Request instance to each method and they return an ${OperationName}Response instance. If you publish the available request/reply types and you only need to provide one proxy type to access the service with some syntactical sugar to make it easy to use, i don’t think it would be harder to understand or to use.

And i agree with some of the advantages of WCF that you list… However, remote calls of any kind are expensive, so minimizing the amount of remote calls is really important to me, which is why i consider batching of operations as a must-have feature. That requirement is more important to me than the ones you list.

@Bart:

In situations where it’s ‘easy’ to define a coarse-grained interface then i wouldn’t want to use batching either. I understand the importance of coarse-grained service interfaces and making sure service interfaces aren’t chatty. But i often feel that these coarse-grained interfaces are somewhat influenced by the client’s needs. Which should be avoided by a service because then there’s in an implicit coupling of the service to the client. When another client needs to use that service, the coarse-grained interface might not be ideal for that client. In those cases, the ability to batch operations allows each client to go for the ideal usage scenario without having to modify the service.

Just recently finished a Business Intelligence application and I had the same issue tens of methods that can be called (even all of them):
- coupling some of the configuration/filtering methods together inside their own objects
- delay loading/calling when needed with an event driven model
- making the service an API (access to one of our spokes in a hub and spoke data warehouse/mart)
- off-load interactive work on the data structure on the client

To me its a lot clearer with this design and especially with the fact that we deal with aggregating 500,000 – 2 million records on the fly. I would never want to batch these calls. I want to make these expensive calls only absolutely when necessary.

If your service layer is a front end for other applications, which you do not control, I’d keep adding those specific services / service methods. They are just easier to understand than that one process method. Granted, if documented you could tell every consumer that they have to use the service with the process method.

More important however, isn’t one of the goals of WCF to have an abstraction on the underlying transport mechanism? You can host a service in several environments, turn features on and off(security, compression,…), just by changing the configuration files? I think that’s one of the, if not the, most important reason to use WCF.