Some comments on efficient SOA method composition

A couple of posts back I started talking about composing SOAPY operations efficiently, by shipping intent to the service.

An interesting debate ensued in my comments:

Kristofer (the guy behind the Huagati tools for DBML and EDMX, and it seems a man after my own heart) got all excited and suggested the name LINQ to WCF.

Frank de Groet, also liked the idea from the perspective of the potential latency savings but was concerned about getting agreement between platforms on how to share expressions. A valid concern, but I don’t think its insurmountable.

Mikael Henriksson added this: “That’s why architecting a service based application can sometimes be a bit difficult from a usability perspective…”, which I guess means Mikael thinks that a facility like what I described would make it easier to create useful services. I’m sure it’s no surprise that I totally agree with this hypothesis :)

Artem, on the other hand, had some strong objections. Now I won’t try to speak for him because I think (given that we disagree) I’d do a disservice to his arguments. But he and I debated questions like these:

  1. Why not just expose an operation that composes the methods if a client needs it?
  2. How could you do this without missing out on custom WCF rules and interceptors if you compose ‘under’ the layer where this interception takes place?
  3. What exactly would we be doing if the server re-wrote the client’s expressions? is that a form of AOP?

All good questions. Check out the comments for more.

And finally my mate Jimmy Zimmerman chimed with this:

Statement: Is this “sexy” from a technology perspective? Absolutely.
Statement: Is this a bad idea? Absolutely.

Which on first reading looks pretty damning. But as I found out over lunch yesterday, he is merely warning against taking this idea too far, by straying from pure operation composition into a land where predicates, order bys, and conditional logic can be applied intermingled in the expression.

Check out his follow-up post to hear his concerns.

Hmm… I love these kind of healthy debates.

Anyone got anything else to add?

Comments (2)

  1. Jimmy Zimmerman says:

    Funny you write this. I actually started playing around today with a linq provider to support this concept. More for my personal curiosity I was approaching this from the wire protocol perspective (e.g. how would an combinatorial expression actually look on the wire) than really caring about the lambda itself, that’s just a fun distraction. On the other hand, I happen to be sick enough of a human being that other engineers have to stop me from diving straight at the core WCF Message class when coding :)

    if anyone is interested in watching the flaming wreckage that is soon to be my ego, they’re welcome to pay attention to:

    Uhhhhgggg Alex. You’ve got me on another one of our intellectual obsessions agian :)

  2. Artem says:

    Hi Alex,

    I was thinking more about it. I mentoned that I don’t like your implemenation of the idea (as well as Ayende’s implementation). It is not good just to disagree without suggesting anything else. Though I had a suggestion to add method that composes the methods, and if  I’m the owner/designer of the contract I would do definitly it. However, it is interesting technical challenge – how to implement methods composition without touching the contract.

    Here is how I would do it.

    First of all, I think there should not be any expressions serialized and passed, meta services, dedicated contarcts or special contarct methods etc to handle batch/chain. Let’s consider just chains for brevity, for example one you gave in your initial post:

    Employee manager 

        = serviceProxy.GetManager(serviceProxy.GetDepartment(serviceProxy.GetEmployee(“alexj”)));

    Let’s start from client side. I think it’d be great if client side could automatically understand that this is a chain that by default should be executed with a single trip to server side. There’re various ways to change serviceProxy to implement it so it does transparently for caller (understands that it is a chain and instead of calling server 3 times create special message that describes the chain) – for example using dynamic proxies.

    Or, if we want to initiate chain call explicitly, it could be even easier. Would be to do something like:

    Employee manager 

        = serviceProxy.Chain((IService s) => s.GetManager(s.GetDepartment(s.GetEmployee(“alexj”))));

    We are passing expression  to client side Chain (extension) method, that internally analyzes expression tree and WCF extension or WCF natively creates message (special message that describes the chain) to call server.

    Server side receives this special message, from its format/metadata WCF understands that it is a chain (it can either be WCF extension or even native support of such messages  by WCF, even their standartization to allow cross-platform communication).

    After chain message has been ‘unpacked’ and server knows what methods to call, we need to do it in a way that all WCF interceptors/behaviours would trigger.

    If we extended WCF ourselves manually, quick and easy thing that comes into my head – we can use NullTransport ( to call each method from as if ‘outside’ (so that all WCF interceptors/behaviours would trigger). Or if  WCF would support it natively – it could avoid serialization/deserialization and call methods internally somehow still applying all WCF interceptors/behaviours.