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:
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:
- Why not just expose an operation that composes the methods if a client needs it?
- 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?
- 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?