WCF/SOA - Why should I create parameter objects for simple requests
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.
WCF/SOA - Why should I create parameter objects for simple requests
===

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.