design A or design B

[cardio]

I'm hoping to drag you you all into a (very short) debate about SOA standard / best practices. I think I can boil it down to a simple example. Even if you don't have time for a detailed post, I would really appreciate a short reply with just "A" or "B", your preferred language / platform / environment, and how many years of experience you have. Any additional insight you would like to provide is gravy.

In this example, we have a client that will need to be able to:
- update multiple fields of a user (ie- name, email, password, status, etc)
- update the password of a user
- update the status of a user (to any valid status)
- change status of user to "unlocked"

We have two suggestions for the web service implementation:

(A) A single general service to handle all four client needs:

UpdateUser service with appropriate optional fields that updates only the fields provided in the request.

(B) Four specific services, one for each client need:
- UpdateUser with all fields required that updates all changeable fields of the user
- UpdatePassword, UpdateStatus each change only that one field of the client
- UnlockUser only allows the status to change to the "unlocked" value

I don't think any of this is relevant to the issue, but a few insights into the context...
- client is .NET, server is Java/JBoss
- applications are long-lived (we'll have to live with our decision for years and through many software revisions)

Please speak up! Your opinion counts! Software development really is (not) a democratic process! We want you! Your exclamation here!

Many, many thanks,
Gridlocked

[Arjay]

I prefer B.

In general for WS clients, I work on a autogenerated proxy level or use shared interfaces and contracts (that allow me to get rid of the proxy layer) because I want to code to class or method rather than to a Soap interface/xml level. So, although I could track fields that change in a contract, I really haven't felt the need to do so. In my implementations, the contract rules - so whatever is in the request contract gets saved.

Lastly a consideration for A or B would be the volume of the service and what sorts of operations are performed more often. For low volume traffic, A would be fine (except for the part about only certain fields getting updated). For higher volume, more granular methods would probably yield better performance.

My preferred platform for Web services is WCF services in C#.