Best Practices for Service Design

Topics: General Discussion Forum, Service Factory Modeling Edition Forum
Feb 5, 2008 at 7:54 PM
I've successfully installed the WSSF and built a simple service using the hands on lab as my guide. Now that I've got my feet wet, I'd like to start building some more complex services for an actual application I'm working on and have a few questions.

  • In general, how many operations should a single service contract support? Why would I want to use multiple service contracts? The currenct service I'm building has about 4 operations that I need to expose.

  • Can I (or should I) reuse a request message for multiple operations? Visual Studio doesn't seem to allow me to connect multiple messages to different operations. As an example, I have two operations called GetProduct and UpdateProduct which could potentially share the same request message, using a common Product data contract.

  • Is there any documentation floating around that might answer these questions?

I'm a rookie here, so I'll apologize ahead of time if my terminology above is way off!

Feb 5, 2008 at 8:59 PM
  1. There's no fixed rule about of operations per service but I would say that they will depend on the service design and its domain. Having just four ops sounds quite reasonable.
  2. The messages are used by each operations. You may have the same message as Reqesut/Response for an operation but you should define another message for a different operation. In your case, you can have different messages that shares DCs on each message (having Data Contract Message Parts on each message pointing to the same DC where you have all your properties).
  3. You can find info in the product documentation or this wiki (discussion group).

Feb 6, 2008 at 8:36 AM
Edited Feb 6, 2008 at 8:47 AM
I would like to share some of my comments and questions regarding best practices for a service design using the WSSF: Modeling Edition.

First, I don't think that the BlueYonderAirlines examples is a best practice example. My first comments is the use of word "Contract" on the Service Contract (MaterialMgmtContract). This is the name that is used to generate the service proxy and I think a better name would be MaterialManagemetService (should use full names).

Not sure about the Get/Set naming on operations - while I tend to do the same "mistake" myself, I don't think it's a very good practice, is it?

I would expect most services to use a single parameter which is a defined type in the data contract model. This makes for a cleaner abstraction and seperation of the service interface and the message contracts.

One issue I have with the single-parameter-message model is that you have to give unique names for the parameters, you are allowed by the model to use same name but when you run the .svc through a web server, you get an exception from WCF.

(Post edited: I used the Service Interface instead of Service Client when defining my service proxy... so I removed some of my requests)