Can someone tell me why i shouldn’t drop WCF?

10 commentsWritten on July 12th, 2008 by
Categories: WCF

I've written a few posts about WCF lately... mostly about how to batch WCF service calls. In case you didn't know, i consider batching support a MUST-HAVE feature. Since then, my WCF services all extend the following interface:

    [ServiceContract]

    public interface IService : IDisposable

    {

        /// <summary>

        /// Processes each request within the same service call

        /// </summary>

        /// <param name="requests">each request</param>

        /// <returns>the corresponding responses</returns>

        [OperationContract]

        [ServiceKnownType("GetKnownTypes", typeof(KnownTypeProvider))]

        Response[] Process(params Request[] requests);

    }

I wanted to keep providing specific service methods for each kind of request, but each service implementation would delegate the handling of the requests to the Process method, which in turn would delegate the handling of the request to a specific request handler type which was associated with the request type. So basically, all of these specific service contracts which extend this service don't really offer me anything extra.

So now i'm wondering why i'm even bothering with the specific services anymore... it only leads to more work: more service interfaces and more proxies and in the end, everything is routed to the Process method. So what's the point of these specific services anymore if you don't have batching support out of the box? If i have to go with a generic Process method to get batching support (again, which i consider a MUST-HAVE feature), why am i even bothering with Services at all? Essentially, i'm using a service bus with WCF. Why shouldn't i just move to NServiceBus which is actally perfectly suited for this kind of work?

For the record, i'm not trying to flame or anything... i really want to get some answers to the following question: why shouldn't i drop WCF and the whole service layer thing in favor of a real service bus and Messaging in general?

« Mocking expensive template methodsIntroducing… Stuff! »

This entry was posted on Saturday, July 12th, 2008 at 16:39 and is filed under WCF. You can subscribe to any comments to this entry via RSS 2.0. You can leave a response, or trackback from your own site.

  • http://www.bennymichielsen.be Benny Michielsen

    I’m not up to par with WCF, I’m actually looking into it at the moment. But here are my .02$.

    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.

  • Bart Czernicki

    To me this is an interesting topic and it is one of those things why I think some architects spend too much time on plumbing rather than designing.

    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.

  • http://davybrion.com Davy Brion

    @Benny:

    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.

  • Tony

    Davy,

    Not sure if this is what you are looking for:

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

  • http://davybrion.com Davy Brion

    Tony:

    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/

  • Mark Stafford

    ESBs (the class of architecture which NServiceBus fits into) aren’t so much about batching as they are about fire-and-forget. Batching happens to be an artifact of that fundamental nature. The principle of an ESB is to drop a message onto the wire and trust that the appropriate handler is or will be listening, and will eventually pick up and process that message. Reply is not a concept in an ESB – rather, the handler would drop a new message (the “reply”) onto the wire and the new handler (the original source) would pick that message up and process 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.

  • http://davybrion.com Davy Brion

    Good points :)

  • http://hsidev.wordpress.com Nathan

    We’re using NServiceBus on our project instead of pure WCF, and we control all endpoints. Personally I find that the asynchronous (fire-and-forget) nature of the style of messaging NServiceBus promotes dramatically simplifies cross process communication even on smallish projects where all endpoints are under our control, because of the reduced coupling of the client and server and the ability to grow the system in unknown ways (for scaling or adding functionality) without much effort. The architecture is just so much more flexible (in my opinion) and doesn’t really add complexity. Also, using an asynchronous messaging framework as the core of the messaging system doesn’t preclude you from exposing operation specific, proxy-friendly WCF endpoints to external or internal partners as required, the service implementation can simply marshal such calls to the bus behind the scenes. Plus with an ESB you get the Pub/Sub message exchange pattern, which is required for an event driven system, and which you would have to build yourself in WCF.

  • http://www.ayende.com/Blog/ Ayende Rahien

    > Ayende’s version of a service bus.

    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.

  • Pingback: Blue Onion Software - Onion Peels Blog - Friday Links #8

Meta

Recent Posts

Categories