Our company is starting a fairly large SOA initiative. We're doing a lot of stuff right: there's good communication; money for tools where appropriate; and we have brought on some good expertise to help us with the transition.
We're trying to develop standards that we can follow as a group, and one of the proposed standards is bothering me quite a bit:
We have standardized on the pattern where every operation takes a request object and returns a response object.
I realize that this is more or less a standard approach for a lot of folks, but I am asking why should I bother? (I'm not so good with received wisdom, I need some why).
Most of the services that I will be providing are simple organizational metadata retrieval. For example, find the security policy for a particular user. This needs a user id and nothing else. The standard tells me that I should wrap this request in an object and wrap the returned policy in a response object.
My unease is amplified by a look at the WSDL that is generated from our contracts. WCF generates request and response messages automatically and wraps even the request/response object.
I fully understand that if you're making a complex request then a complex input object is warranted. That's what you would do even if services wren't involved.
My question is why should I automatically wrap requests and responses when:
- It makes simple services less expressive
- You would do it anyway for a complex service
- WCF creates a request/response message anyway
I have found the following arguments in favor of this approach:
It supports versioning by allowing optional parameters to be slipped into the request object.
Back in the day, I did a fair bit of COM, and I would consider this almost an anti-pattern for versioning. For some things, I suppose it would help, but I expect that where it would help, you already have a parameter object anyway.
It allows common data and behavior to be isolated to a base class
This one carries some weight with me.
It steers people away from an RPC style behavior and towards a messaging behavior
I've read this on Microsoft's site and heard it from our guru, but I still don't have a clear idea what they mean or why it's valuable. Is it that natural looking interfaces make people tend to forget that they are calling a remote service?
I am looking at refactoring the signatures of perhaps 300 methods, so this is a non-trivial amount of pain. I'm a huge fan of consistency in implementations, so I'm willing to take on the pain, it will just help to know that it will all be worth it in the end.