Best practice for large WCF service?

Question

What is the best practice for writing a rather large wcf service, containing a lot of OperationContracts and DataContracts?

How would I separate functional areas into se

Answer 1

I know this is an old post but I am thinking of services in the same way as I think of objects in programming.

Keep them to their bare minimum for what they must do. Of course not to go to the extreme, but I am making my decisions based on data entities.

One service for Account, one for Product etc.

Not sure what anyone would think of that though...

Answer 2

I'll go off the track here and say I've used monolithic WCF contracts, functionally separated contracts (with a maximum of ten methods along Juval's guidelines in his book), and I've also tried a message handling architecture where a service has a single method that takes a base message, and handlers that 'know' how to unwrap and process the message after it crosses the wire.

I'm a big fan of the latter if you've got .NET on both sides of the fence. Oren has a screencast on the idea with code. I don't know what your needs are but this is working for me.

http://ayende.com/Blog/archive/2008/03/30/Hibernating-Rhinos-8--Going-Distributed-amp-Building-our-own.aspx

That said if you're already coming from "I need a large WCF service" then going to one method is probably not going to cut it for you. If that's true then Juval Lowy's Programming WCF Services is the standard you should uphold in your design.

Answer 3

I have a post here about how individual operations should differ from traditional code operations:

http://www.iserviceoriented.com/blog/post/Introduction+to+Service+Oriented+Architecture.aspx

You should end up only with operations for actual business events. If you ever stop and think "I need to enable transaction support on my web service" that means you haven't designed the operation with a wide enough scope. You should never have to enable web service transaction support.

I highly recommend Bill Poole's blog for higher level SOA concepts. Here's a post to get started:

http://feeds.feedburner.com/~r/BillPoolesCreativeAbrasion/~3/328955489/service-contract-stability.html

Answer 4

This has been helpful to me it comes from the idesign.net website and it was authored by Juval Lowy:

WCF Coding Standard

Answer 5

That's been a big question surrounding services since their inception. SOA done successfully is SOA planned to the extent you're talking about. Having said that, I've always leaned more toward splitting services out, but using them in a composite manner. That is, several endpoints when you have several contracts, but most of them are only consumed by a few endpoints that are consumed by non-service callers. (wow, that was a mouthful, did it even make sense?)

Also, I would advise to have as few contracts as possible. Too many contracts can lead to poor manageability. Good contract design will help limit the number of endpoints and service calls. Removing OO concepts from contract design is one way of doing so. Contract design is a massive topic in itself, but suffice it to say that through good contract planning (up front), comes good service design.

Maarten Mullender writes a great blog on WCF design, and is a must read. There are also some great SOA/WCF books emerging as well.

Some good books:

• Pro WCF: Practical Microsoft SOA Implementation
• Programming WCF