One of my big pet peeves (aside from the term "pet peeves") is seeing services that are tantamount to stored procedures or worse - single table oriented operations (hey...at least you can do more than one thing in a sproc, right??) . What this results in is an insanely chatty interface, which means more network hops and more duplicated data going over the wire. In fact, what they tend to end up being reminds me very much of Win32 calls where I have to make a call to get the count, for example, then call it again with the count to fill the buffer. Win32 != SOA.
So in addition to the four core tenants of SOA (a fun/interesting read)...here are a few of my own additions:
- Your service is not your database, don't treat it like one. Pretty simple...I shouldn't see a bunch of operations like GetCustomerBy{Name,Id, etc...}, GetOrder followed by GetOrderLineItems or (better!), GetOrderLineItem (note the lack of our friendly s).
- Thou shalt not return HRESULTs from your service. (this was actually suggested to me by one of the WSE product team members as being "correct" when WSE would conveniently sink your void service operation...sucked if you actually planned on it being synchronous. I guess it wasn't too correct since they fixed this bug later).
Returning 0s, 1s, 2s, 0xcffe923 isn't the right way to indicate failure of your service. Faults are.
- Services are points of abstraction, treat them as such. Largely related to the first point, but find a good abstraction and go with it. For example, I shouldn't see GetOrderProcessingTimes, GetOrderTakingTimes, GetCheezeburgurEatingTimes and so on. How about a nice simple, GetMetrics( string metricName ) and allow some magic to happen on the back end rather than bloating your interface.
- Thy service shall not talk more than thy mother. If you're looking at three or more calls to get the data you need (I'd posit that one should be sufficient in 99% of the cases), then you should get to work. Networks hops are the bane of distributed applications, particularly with verbose junk like SOAP (all the more so if you have an absurdly complex (and non-nillable) schema). Further, don't get in the habit of expecting an exceptionally speedy network or relying on new tech (e.g. 10Gb) to help you out. This is why we have a lot of software that can take up 512MB of RAM without even flinching...I mean...they have to start that fancy splash screen somehow, amirite?