Software, a factory approach - services

This is the fourth post in this series, you can find the landing page here. 
The code for this step of the series can be downloaded here.

In the previous post we created the data model for our tracker application, now we'll tackle the services model.  For the sake of brevity I'll only discuss creating one of the two services that are in the example code, the second is completely similar.

Services

First  off, right click the Tracker node in the solution explorer, and click Add\New model

Once more, you're greeted with a blank designer surface, one that's just yearning for some service model components. 
The following images shows you the Toolbox items you get for this designer:

You can put the components on the designer surface in any order, connecting them as you want.  I mostly start by adding a service, then the contract and using the connector to connect them, as per the following image.

Of note here is that you create a service contract without the habitual I prefix, the I will get added automatically.

Operations

Next step is adding the operations to the service contract. You start by dragging an operation shape onto the designer, renaming it to CreatePickupRequest and connecting it with the service contract with the connector tool.

So now you've created a void method on the contract.  However, seeing as this probably isn't what you want, you should add some parameters.

Add two messages onto the designer surface, and rename them to CreatePickupRequestIn and CreatePickupRequestOut.  Using the connector tool create a connection from the CreatePickupRequestIn message to the operation and from the operation to the CreatePickupRequestOut message.

This should give you the following result:

Right clicking the message allows you to add either a primitive data type or a data contract type, which is similar to designing data contracts.

Faults

As stated in the previous post, and as the image above already shows, each operation allows you to add faults to it. 
For the fault unsavy, this is what Mr Wcf himself, Juval Löwy, has to say about faults in his most excellent book "Programming WCF Services":

Any service operation can at any moment encounter an unexpected error. The ques-
tion is how (if at all) that error should be reported back to the client. Concepts such
as exceptions and exception handling are technology-specific and should not tran-
scend the service boundary. In addition, typically error handling is a local implemen-
tation detail that should not affect the client, partly because the client may not care
about the details of the errors (other than the fact that something went wrong), but
mostly because in a well-designed application, the service is encapsulated so that the
client does not have anything meaningful to do about the error anyway. A well-
designed service should be autonomous as much as possible, and should not depend
on its client to handle and recover the error. Anything beyond a blank error notifica-
tion should in fact be part of the contractual interaction between the client and the
service.

The pickup service requires you to specify a number of parameters to create a pickup request:

• Pickup (Location)
• Delivery (Location)
• CustomerId (long)

For the sake of simplicity I've identified two possible faults for this service:

• missing parameter
• unknown customer id

For this next step, I normally create a new DataContract model, with the namespace http://company.com/Tracker/Services/Faults/2008/04, but this is a matter of taste more than anything else, you could also add these to the existing data contract model.

In the end you'll have the following faults (I added a Message member):

After which you can update your service model :

So this concludes the services part of our example application.
Validating the models should give some errors concerning the fact that you haven't chosen an implementation technology, but we'll deal with that in the next installment.