Introduction to WCF

This blog shows how to create a Visual Studio 2010 C# console application that hosts a Windows Communication Foundation (WCF) service exposing string manipulation methods.

The purpose of WCF is to simplify the communication of distributed applications on Windows. Because WCF uses RESTful communication and implements SOAP it can therefore operate with multiple platforms.

Creating the service

In Visual Studio 2010:
File > New > Console Application > Name: Service

Open the project’s properties and change the namespace to: Glyde.ServiceModel.Examples
Change the Program.cs namespace to use the Glyde.ServiceModel.Examples namespace.

Add System.ServiceModel.dll to the project.
Create a new public interface: IStringManipulator.cs, this will expose methods to add two strings together, replace part of a string and remove a substring.

Add a reference to System.ServiceModel in the interface.

Add a service contract to the interface:

[ServiceContract(Namespace = http://Glyde.ServiceModel.Examples)]

And add [OperationContract] to the exposed methods:

[OperationContract]
string Add(string s1, string s2);
[OperationContract]
string Delete(string s1, string s2);
[OperationContract]
string Replace(string s1, string s2, string s3);

Next we create a WCF service contract.

Create a StringManipulatorService class to implement the interface methods.

public string Add(string s1, string s2)
{
return s1 + s2;
}

public string Delete(string s1, string s2)
{
return s1.Replace(s2, string.Empty);
}

public string Replace(string s1, string s2, string s3)
{
return s1.Replace(s2, s3);
}

In the Program.cs create a URI object to serve as the base address – this will be used by the client to call the service:

Uri baseAddress = new Uri("http://localhost:8000/GlydeServiceModelExamples/Service");

Create a service host for the StringManipulatorService

ServiceHost selfHost = new ServiceHost(typeof(StringManipulatorService), baseAddress);

Add a service end point

selfHost.AddServiceEndpoint(
typeof(IStringManipulator),
new WSHttpBinding(),
"StringManipulatorService");

Enable the metadata exchange, for HTTP:

ServiceMetadataBehavior smb = new ServiceMetadataBehavior(); smb.HttpGetEnabled = true;
selfHost.Description.Behaviors.Add(smb);

Start the service
selfHost.Open();
Add a
Console.ReadLine();
…to keep the service running.
Call close to stop the service from running:
selfHost.Close();

Create a WCF client

Create a console application called Client, implement this in a separate application so the service and client can be run from a separate debug solutions – this will help your understanding and allow you to debug both.

Add System.ServiceModel.dll to the project and add the reference to Program.cs

How to use the service utility to create the client proxy

Switch back to the service solution and start the console application by F5

Start the Visual Studio command promptNavigate to the client projectRun the ServiceModel

Metadata Utility Tool to create the client code and configuration file (generated proxy):

svcutil.exe /language:cs /out:generatedProxy.cs /config:app.config http://localhost:8000/GlydeServiceModelExamples/Service

This will generate the files in the client project folder:
generatedProxy
app.config

Add these to the client project by using ‘Add existing item’.

Remember, if you modify or add new methods in the service, the client proxy will have to be recreated.

The app.config specifies the location of the service, the binding and contract interface.
Call the service via the proxy

Create an endpoint address and a WCF instance client in the Program.cs.

StringManipulatorClient client = new StringManipulatorClient();

By adding the app.config and generatedProxy.cs the StringManipulatorClient is automatically available in the project.

Don’t forget to add System.ServiceModel to the project and add a reference in the Program.cs file.

Make a call to the client:

string value1 = "Hello Hannah, ";
string value2 = "how are you today";
string result = client.Add(value1, value2);
Console.WriteLine("Add({0},{1}) = {2}", value1, value2, result);

value1 = result;
value2 = "Hannah";
string value3 = "Emma";
result = client.Replace(value1, value2, value3);
Console.WriteLine("Replace({0},{1}) = {2}", value1, value2, result);

value1 = result;value2 = ", how are you today";
result = client.Delete(value1, value2);
Console.WriteLine("Delete({0},{1}) = {2}", value1, value2, result);

Close the client after use:

client.Close();

So that’s it, I hope I have wept your appetite to learn more about WCF – As ever I have uploaded my source to GitHub click here to get the source from my introduction to WCF.

Agile Software Development

What does it mean to be Agile?

There are a number of strategies and working practices available for Agile software development, I have included the process that works for me; this is based on my real life experiences working with stakeholders (more about these in a moment), developers and testers.

Scrum

What is Scrum? During a project the customers can change their minds about what they want and need (also called churn) these challenges cannot be addressed in a planned manner. Scrum uses a pragmatic approach, in most instances these problems cannot be fully understood therefore a focus on capitalising on the team's ability to delivery quickly and respond to emerging requirements.

Daily Scrum

A stand up meeting called a Daily Scrum takes place at precisely the same time every day - 10 am is a good time as the team members have had the time to know what they are doing by this point. If your team is distributed then use a video conferencing tool (e.g. Skype).

There are three roles in a Daily Scrum:

On the officials in the 2007 Tech-Texas game in Austin:

"It's a little like breakfast; you eat ham and eggs. As coaches and players, we're like the ham. You see, the chicken's involved but the pig's committed. We're like the pig, they're like the chicken. They're involved, but everything we have rides on this."

Pigs

The developers and testers play the part of Pigs, they have no longer than one minute to describe what they did since the last Daily Scrum, what they are doing today and what blockers they think they may have to do today's tasks.

If anyone has an questions or comments they should take place outside of the Daily Scrum.

Chickens

The stakeholders (customers) play the role of chickens - they can listen but not speak. If they have any questions they should go through the Scrum Master outside of the Daily Scrum meeting.

Scrum Master

The senior member of the software team usual a Team Leader will take the role of Scrum Master, they ensure the Daily Scrum starts on time and that everyone takes turns to speak. The Scrum Master can also be a Pig.

Sprint

Sprints are a part of the Scrum methodology.

Sprint planning meeting

A sprint cycle lasts for two weeks.

Select the work to be done

User Stories

The Scrum Master meets with all the Stakeholders in a single meeting to gather the user stories.

In order to process the user stories quickly cards should be used to write a short sentence that describes the functionality in the form:

As a [role] I want [requirement] so that [business need].

The Stakeholder writes the card and passes it back to the Scrum Master, only one card is completed at a time after being discussed with the other Stakeholders.

The number of User Stories gathered in the Sprint Planning Meeting will vary depending on the size of the team for a small team of four developers, ten User Stories would be a fair number.

Each User Story will have a number of scenarios written on the back; these will form the tests.

Story Points and Planning Poker

After the User Stories are gathered the Software Developers and Testers go through each User Story and assign it a number of Story Points.

The highest number is the most complex and time consuming, the lowest is the simplest and shortest: 0,1,2,3,5,8,13,20,100. 100 alerts you to the fact that you have an Epic Story which should be split in to multiple stories.

A game of Planner Poker should be played, this can be done with Planning Poker cards or if your team are distributed - this can be done over an IM - The Scrum Master asks everyone to get their numbers ready and all hit Enter at the same time.

The Scrum Master records the Story Points against each User Story, no more than 5 minutes should be spent on each User Story.

Prioritisation

The User Stories with Story Points should be reported to the Stakeholders in person, they then order the cards by relative priority.

Tasks and durations

The Scrum Master asks each of the Developers if they have any holiday booked for the next two weeks, this is subtracted from the number of hours in the Sprint.

A Sprint is always two weeks long, due to outside forces, answering emails, meetings, urgent issues (real life) I allow for six hours per day on a Sprint. So if a Developer is in then they are available for sixty hours for the two weeks. I recommend using Pair Programming so this will be the hours shared between your developers (i.e. sixty hours for two Developers).

Get the Developers and Testers together, take each User Story ordered by highest priority first, split in to Tasks i.e. Analysis, Design, Database schema changes, Development, Testing, Deployment. Speak directly to the individuals most likely to implement the User Story (Developers and Testers should work on a single User Story rather than a single Task), ask them to say how long they think the Tasks will take. The other Developers and Testers can verify this.

Create a table in a spreadsheet with sixty at the top and subtract the hours for each User Story from the Developers available hours, eventually this will get to less than zero, all User Stories in positive numbers will be what the team can commit to.

The Scrum Master meets with the Stakeholders and provides them with the list of User Stories that can be committed to in the two week Sprint.

Story board

A Story board is created for each Sprint, User Stories have a state during the Sprint:

Backlog > In progress > Code ready for review > Code reviewed > QA Ready > [QA Passed][QA Failed] > Deployed

There is another state called Waste, this is used for any duplicate or erroneous User Stories.

The Developers are encouraged to move their User Story to the next Sprint, this should be viewable by the Stakeholders, web based story boards are available this is useful for distributed teams.

Sprint review meeting

Once the two week Sprint is completed, the Developers and Testers meet with the Stakeholders to review the work that was completed and not completed. A demonstration of the completed work is shown to the Stakeholders. There should be a four hour limit to this meeting.

Any User Stories not completed in the Sprint go in to the Sprint Backlog.

Velocity

The number of Story Points completed in the Sprint gets recorded against the User Story, this becomes the velocity of the team.

After three Sprints the velocity will start to even out and give the Stakeholders an idea of the amount of work that can be done in a Sprint.

Charts

There are two charts I have found useful, the first is a Daily Burndown Chart, this is where the number of hours the Developers spent on the Sprint each day is recorded against the number of available hours.

The second is the Release Burndown Chart, this shows the estimated number of Story Points in the Sprint against the actual Story Points completed, this chart can be extended to also include the velocity.

Sprint retrospective

This meeting is attended by the Developers and Testers, all team members reflect on the past Sprint, make continuous process improvements , what went well and what can be improved, there should be a three hour limit to this meeting.

Extreme Programming (XP)

There are a number of XP elements, the one I find most useful is Pair programming. Software developers sit at a single Development workstation they take it in turns to be at the keyboard - known as the Driver, as a Developer types they describe what they are doing to the Observer. The Observer reviews the code as it is being typed, therefore code reviews do not need to be done after a task is completed and the quality of the code is far superior than if done on their own.

One common issue is one of swapping, if this does not feel natural then switching every thirty minutes is a good compromise. Other benefits include a lack of fatigue, knowledge sharing, a boost in morale, not skipping unit tests. New Developers can pick up the workings of the team quickly and people are less likely to interrupt a pair of programmers.

Other distractions can be email, one solution to this is to have a separate PC that individuals can use to read their email.

Summary

By employing these Agile Software Development methods my team are able to work in a more efficient way, there is little or no context switching between tasks, the quality of work has improved and the implementation matches the requirements closely. The Stakeholders feel engaged with the development process and see results more frequently than through the waterfall model.