This is the before-final day of the PDC and I must say, the most interesting pieces of technology to me are Azure, Dublin and Oslo.
So this session was the more practical Dublin one. How do you use it, and what does it do.

So where does Dublin fit in?

And if we take a close look at Dublin itself?

Dublin extends IIS. You get new functionality there, where you can watch persisted instances of your service. Or look at the tracking data.
Dublin gives you Visual Studio templates for WF and WCF, so creating services using Dublin will be very easy.
Dublin allows you to Import and Export service applications within IIS!
Dublin will provide a “Model Deployment To Dublin” feature for Quadrant
Dublin will provide powershell commands
Dublin will provide tracking, monitoring, discovery out of the box

Also new is the forwarding service. It forwards messages based on filters (this can be content based rules!!) to different endpoints. So how cool is that? Just relay your message to different services without the service consumer ever notice?!

The overall message of this session : It Just Works

I hurried from the key note to this session room to be able to video call home a moment. Luckily, my little daughter wasn’t sleeping yet (time difference is 8 hours), and she still recognized me as her ‘papa’.
In this picture I made while the session had just begun, you can see here walking to her room to go to bed.

Anyway, Ed Pinto gave a great talk about this subject:

As a reminder: what is WF?

New in WF 4.0 are Arguments and Variables.
Arguments: types that flow in and/or out of your Activity
Variables: you can store values in variables while running an Activity

Activities have user defined Variables for data storage:

Activities bind Arguments to in-scope Variables:

So here is an example of a Parallel Activity within the new WF 4.0 designer:

And a Sequence with a Try Catch:

A BIG new thing within WF is extended Correlation. You can now define CorrelationHandle’s and bind your SendMessage and ReceiveMessage to it:

Finally, Ed told us that Dublin will easy all this tremendously. I’ll visit a Dublin session later on.

When should you write WCF Services using Workflow? And what are the other WCF 4.0 improvements?

To me it’s interesting that that WF is not positioned as just a Human Workflow engine any more. It’s now very suitable to use in your messaging applications and make use of it’s parallelism, correlation and tracking!

Immediately after the key note, I ran to the lunch session of Nicholas Allen.

I’m a close follower of his blog, because the guy knows so much about the inner workings of WCF. I’ve used his info lots of times when writing WCF stuff.

This talk was all about performance. About what bottlenecks there are at which level, and how to mitigate them.

He explained this by using a Push Pull principle. All communication flowing over the WCF stack will have several parts pushing or pulling data. Performance has a lot to do with optimizing the manner these parts interact.

When mapping this principle on WCF you can see parts that push and then parts that pull. Whenever a switch between the two takes place, you have an interesting performance case. Because at that point, message pumping and/or buffering will take place.

All these points have all sorts of configurable performance knobs to tweak and tune. The above gives us a much clearer insight of what you are indeed tweaking/tuning so you can understand what the knob does and what consequence it may have.

So when looking at the message pump of the server side part of a binding, you will see the following:

When zooming in a bit more, you soon get a lot of detail (and you might get lost!):

An important lesson you can take out of this last screenshot, is the fact that you can see that binding to a thread takes place in the 6th part of the pump. All that is before that is a potential performance issue.  So watch out with your authentication providers and message inspectors!!

So last week, we (Marcel de Koster and myself) presented the second issue of our Windows Communication Foundation Workshop. We were warmly welcomed in the south of Holland, in Eindhoven. It was my first visit to the Kennedytoren tower in the center of Eindhoven where Logica rents the two top most floors. I must say, the view was splendid and so was the rest of the evening.

The workshop itself went great; the attendees encountered a bit more difficulties than last time, but it was a challenge coping with them. Just like the first workshop, we handed out this great book:

“Programming WCF Services” by Juval Lowy

If you feel like wanting to know more about WCF, this book is a great starter. Is gives a well written overview of all that WCF has to offer, and is presented by Juval in a nice comprehensive way. We hope the winners of this book will learn a lot from it!

Together with my colleague Marcel de Koster, we are presenting an introductionary workshop about WCF.

On the 18th of September we held the first workshop at Logica Amstelveen, next week we will be in the South of Holland in Eindhoven hosting the same workshop. Besides the SOA and WCF theory, we also incorporated three exercises so the attendees get a profound first hands-on experience with WCF: building contracts, services and clients make a good start to get to know this very interesting technology!

So if you have received an invitation, respond fast and hopefully we will see you then!

A third workshop in the North of Holland might get planned soon.

In my previous in this series I already announced that we will create a Service and Client now to work with. This service and client will share a contract and schema, so our first action will be defining this.

In these posts, I’ll work on a simplified case. I’ve chosen to implement some sort of Vehicle Registration System (VRS).  Here in The Netherlands, we have a couple of so called ‘Traject Controles’. Their sole purpose is identifying passing vehicles and registering their speed. If the average speed is above the allowed limit, a speeding ticket is created automatically and the driver can expect this ticket in the mailbox within some weeks.
So, why not create a simplified version of this system.

So, let's fire up VS2008 and start creating some services :)  For now, we focus on three services:

- Person Service, to maintain persons (drivers, license owners);

- Speed Measurement Service, to maintain the speed measurements themselves and the measurement points on the road;

- Vehicle Service, to maintain the vehicles on the road.

I’ll show you the SpeedMeasurementService in this post.

Create a new Class Library called ContractLibrary. We'll put our services in here, so they can easily be reused.

So what does a service interface look like? Check this:

   1: [ServiceContract]

   2:     public interface ISpeedMeasurementService

   3:     {

   4:         [OperationContract(IsOneWay=true)]

   5:         void AddSpeedMeasurement(SpeedMeasurement request);

   6:     }

Its just a normal interface! But we decorate it with some WCF attributes. First, the interface is decorated with the ServiceContract attribute. This indicates that the interface defines a service contract in a Windows Communication Foundation (WCF) application.
The methods on the interface resemble the service operations. These methods are decorated with the OperationContract attribute. This indicates that this method defines an operation that is part of a service contract in a Windows Communication Foundation (WCF) application.

The IsOneWay parameter on the OperationContract attribute, tells WCF that this operation is a One way shape (a shape is also known as a Message Exchange Pattern). I use this shape here, because I don’t have a return value, and I don’t care about the success of the operation call. It’s a sort of fire and forget.  Read this for more information about one way operations.

So, now we want to implement this service contract. We add a Web Application project to our solution and add a new class to it called ‘SpeedMeasurementService.svc.cs’:

   1: public class SpeedMeasurementService : ISpeedMeasurementService

   2:     {

   3:  

   4:         #region ISpeedMeasurementService Members

   5:  

   6:         public void AddSpeedMeasurement(ContractLibrary.SpeedMeasurement request)

   7:         {

   8:         }

   9:  

  10:         #endregion

  11:     }

To be able to host this service within our web application, this application needs an entry point to reach the service. That is why on the web server, the .svc extension is registered and mapped to the ASP.NET process.
As you can see, the content of this svc file just points to the implementation of the service:

   1: <%@ ServiceHost Language="C#" Debug="true" Service="VRS_Web.SpeedMeasurementService" CodeBehind="SpeedMeasurementService.svc.cs" %>

   2:  

Now this is in place, we only need some configuration for this service. In the web.config of the web application, we have the following configuration section:

   1: <system.serviceModel>

   2:         <behaviors>

   3:             <serviceBehaviors>

   4:                 <behavior name="VRS_Web.SpeedMeasurementServiceBehavior">

   5:                     <serviceMetadata httpGetEnabled="true"/>

   6:                     <serviceDebug includeExceptionDetailInFaults="false"/>

   7:                 </behavior>

   8:             </serviceBehaviors>

   9:         </behaviors>

  10:         <services>

  11:             <service 

  12:         behaviorConfiguration="VRS_Web.SpeedMeasurementServiceBehavior" 

  13:         name="VRS_Web.SpeedMeasurementService">

  14:                 <endpoint 

  15:           address="" 

  16:           binding="wsHttpBinding" 

  17:           contract="ContractLibrary.ISpeedMeasurementService">

  18:                 </endpoint>

  19:                 <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>

  20:             </service>

  21:         </services>

  22:     </system.serviceModel>

The WCF configuration is always contained within the system.serviceModel section. First, in lines 3-8 we define a behavior for our service. This behavior enables metadata exposure (this means that the WSDL can be requested), and it disables the leaking of exception details from our service.

From line 11-24 we define the service. At line 12 we couple the defined behavior to our service. At line 14 we define the first endpoint for this service. You can see the Address, Binding and Contract. The address is empty so WCF will use the web application URL. We choose to use the WSHttpBinding here; more info on bindings in a later post. The contract is our service contract. At line 19 we define the second endpoint. This is the endpoint where the WSDL will be exposed.

If we now start the web application and browse to the svc file, we will see this:

If we click on the link, we will see the WSDL of this service:

So now our service is up and running, how are we going to call it?
In this post, I’ll create a Console app in which I will call the speed measurement service. First I add a console application to the solution.
Then, I choose the ‘Add Service Reference’ option and fill in the URL of the service as seen on the above screenshot.
Visual Studio will generate a client proxy for me (internally the svcutil.exe tool is used), which we will use to call the service.
Within the console application I add the following implementation:

   1: static void Main(string[] args)

   2:         {

   3:             SpeedMeasurementServiceClient client = new SpeedMeasurementServiceClient();

   4:  

   5:             SpeedMeasurement m1 = new SpeedMeasurement()

   6:             {

   7:                 License = "1234",

   8:                 Speed = 120,

   9:                 DateTime = DateTime.Now,

  10:                 Point = new SpeedMeasurementPoint()

  11:                 {

  12:                     Id = 1

  13:                 }

  14:             };

  15:  

  16:             SpeedMeasurement m2 = new SpeedMeasurement()

  17:             {

  18:                 License = "1234",

  19:                 Speed = 120,

  20:                 DateTime = DateTime.Now.AddSeconds(60),

  21:                 Point = new SpeedMeasurementPoint()

  22:                 {

  23:                     Id = 2

  24:                 }

  25:             };

  26:             

  27:             

  28:             client.AddSpeedMeasurement(m1);

  29:             client.AddSpeedMeasurement(m2);

  30:             client.Close();

  31:         }

At line 3 we create a new instance of the generated client proxy. In lines 5-14 and 16-25 I create two speed measurements using object initializers.
The SpeedMeasurementPoint objects are there to identify the point where the speed is measured.
In lines 28 and 29 we call our service with the measurements as parameters. If you set a breakpoint in the AddSpeedMeasurement service operation you will see the service operation getting called.

So there it is! A service, configured and running, and a client calling it´s service operation!
I will continue showing ins and outs of WCF using this application in the next posts.

This post is part of a series of WCF posts. The following list will updated and published with each post:

1. In Depth Windows Communication Foundation (Part 1) - Introduction & WCF Architecture
2. In Depth Windows Communication Foundation (Part 2) - Address, Binding & Contract
3. In Depth Windows Communication Foundation (Part 3) - Our first Service and Client
4. ...

In my previous WCF post, I gave you an introduction and a architectural overview of WCF. It already contained lots of concepts which on first hand might seem complex and unknown. In this post I'd like to explain the WCF mantra a bit more.

The following picture gives a basic understanding of client - service messaging:

You can find this ABC everywhere on the Internet, let me just summarize it for you:

"C" stands for Contract: What can the service do for me?

And so an endpoints is in fact the combination of an Address, a Binding and a Contract.

Remember this:

• The Service can expose itself on multiple endpoints (on different addresses using different bindings). What's a binding? Read on...
• The Client can only reference a service contract on one endpoint conforming the binding used on that endpoint. (of course it can reference other services on other endpoints)

An example of an ABC configuration :

 

 

 

 

You can see the Address, the Binding, and the Contract described in the endpoint element.

Here is a graphical representation of a service endpoint:

A ServiceEndpoint contains an EndpointAddress (where?), a Binding(how?) and a ContractDescription(what?).

Address

"Provides a unique network address that a client uses to communicate with a service endpoint." (http://msdn2.microsoft.com/en-us/library/system.servicemodel.endpointaddress.aspx)

Binding

A binding "represents a collection of binding elements, each of which describes an aspect of how an endpoint communicates with other endpoints and that are built, consistently, into a channel factory on the client and into a channel listener on the service. A binding contains a collection of binding elements that correspond to protocol channels, transport channels, and message encoders. There can be any number of binding elements for protocol channels but one and only one binding element for each the transport and message encoder." (http://msdn2.microsoft.com/en-us/library/system.servicemodel.channels.binding.aspx)

There is a lot to say about bindings. They make all sorts of transport, security and interoperability happen. WCF provides system-defined bindings and its possible to extend WCF with custom bindings.
First lets take a look what a binding looks like:

So a binding as a Name, a Namespace and a set of BindingElements. A BindingElement is an abstraction of a Channel... and what is a channel?

(There is a nice mini book about WCF Channels available at
http://wcf.netfx3.com/files/folders/product_team/entry3550.aspx)

Quotes from "Channel Model Overview":

A Binding... "is a layered communication stack with one or more channels that process messages. At the bottom of the stack is a transport channel that is responsible for adapting the channel stack to the underlying transport (for example, TCP, HTTP, SMTP and other types of transport.). Channels provide a low-level programming model for sending and receiving messages. This programming model relies on several interfaces and other types collectively known as the WCF channel model."

So a channel is a shackle in the Binding communication chain and allowes us to influence to message passing through.. Let's compare it with a TCP stack:

"First, the similarities: In both cases, each layer of the stack provides some abstraction of the world below that layer and exposed that abstraction only to the layer directly above it. Each layer uses the abstraction of only the layer directly below it. Also in both cases, when two stacks communicate, each layer communicates with the corresponding layer in the other stack, for example, the IP layer communicates with the IP layer and the TCP layer with the TCP layer, and so on.

Now, the differences: While the TCP stack was designed to provide an abstraction of the physical network, the channel stack is designed to provide an abstraction of not only how the message is delivered, that is, the transport, but also other features such as what is in the message or what protocol is used for communication, including the transport "

"Messages flow through the communication stack as Message objects. As shown in figure above, the bottom channel is called a transport channel. It is the channel that is responsible for sending and receiving messages to and from other parties. This includes the responsibility of transforming the Message object to and from the format used to communicate with other parties. Above the transport channel there can be any number of protocol channels each responsible for providing a communication function such as reliable delivery guarantees."

I already mentioned it, WCF gives us a set of system-defined Bindings made up by system defined BindingElements. All of these BindingElements can in a way be reused in custom Bindings and of course we can write our own BindingElements/Channels to make up new Bindings!
A complete list of standard WCF bindings (including the new 3.5 ones) is given here.

Wow.. does your developers heart beats twice as fast now? :)  This model provides us endless extensiblity options! and believe me, this is just the beginning, because 'extensibility' is WCF's middle name!

All services out there implement some communication pattern... Often they are called Message Exchange Pattern's (MEP's) but within WCF documentation they are often refered to as Shapes.
You propably recognize some of them :

• One-Way - the client is the initiator and messages go from client to service.
• Request-Response  - the client is the initiator and sends a message after which a response is sent back
• Duplex - both client and service can be the initiator and messages flow back and forward.

A channel always implements one or more of these Shape interfaces: IInputChannel/IOutputChannel/IDuplexChannel and IReplyChannel/IRequestChannel for request/response pattern.

Contract

"A WCF Contract is a collection of Operations that specifies what the Endpoint communicates to the outside world." (http://msdn2.microsoft.com/en-us/library/aa480210.aspx)

Remember that SOA tenet "Services share schema and contract, not class or type" Don gave us in my previous post?  This is the service contract. This way, nice interoperable messaging can be established between all sorts of communication stacks based on different plantform technologies. These stacks of course have to comply to some mutual standards; for example SOAP, WSDl and WS-* standards. I'll write more about those subjects later..

A ServiceContract might look like this:

1 [ServiceContract]

2 public interface IService1

3 {

4     [OperationContract]

5     string GetData(int value);

6  

7    [OperationContract]

8     CompositeType GetDataUsingDataContract(CompositeType composite);

9 }

(pictures from http://msdn2.microsoft.com/en-us/library/aa480210.aspx)

Next time, I'll start working with a code example which I'll use throughout all next posts.

More to read in my next post in this series:

In Depth Windows Communication Foundation (Part 3) - Our first Service and Client

This post is part of a series of WCF posts. The following list will updated and published with each post:

1. In Depth Windows Communication Foundation (Part 1) - Introduction & WCF Architecture
2. In Depth Windows Communication Foundation (Part 2) - Address, Binding & Contract
3. In Depth Windows Communication Foundation (Part 3) - Our first Service and Client
4. ...

Introduction

At my current assignment, the last couple of months I've worked a lot with WCF.  During this time I had many challenges to cope with and it seems to me that the WCF learning curve can be rather steep.
There are a lot of books and blogs out there, describing different WCF subjects and I've used a lot of them.
As a start on this website, I have now planned a series of (more or less) 17 posts about WCF. It will begin with covering the basics but will advance pretty soon to more complex parts of using the WCF framework.
I'll try to get rather fast to the more interesting advanced scenario's, but I think it is important to also give the basic information for those who have not yet looked into WCF (at all).
I will use information and pictures found on other web sites and I will try to always give credits to the original owners... so please give me a hint when I've forgotten about you :)
In this first post I'd like to list the books, and URL's that I found useful and I'll describe the general architecture of WCF.
(I'll update these lists as frequently as possible)

I think the following books are of great assistance while exploring WCF:

Programming WCF Services - Juval Lowy

Inside Windows Communication Foundation

Further, I recommend to read the following blogs :

• Windows Communication Foundation From the Inside - Nicholas Allen (almost daily post about WCF)
• Das Blonde - Michelle Leroux Bustamente
• Smells like service spirit - Christian Weyer

WCF Architecture

Overview

In October 2003 the first official anouncement about "Indigo", the new communication platform now known as WCF, was done by Don Box on the Professional Developers Conference in Los Angeles. It was supposed to be one of the four pillars (the other pillars are: Avalon-now knowns as Windows Presentation Foundation WPF-,    WinFS-the revolutionary new file system and     WinFX-now known as the .NET framework 3.0) of the new "Longhorn" operation system.

In 2004 Don Box published an article on MSDN called "A Guide to developing and Running Connected Systems with Indigo" in which he explained the principles of WCF with the help of four SOA tenets:

• Boundaries are explicit
• Services are autonomous
• Services share schema and contract, not class or type
• Service compatability is based upon policy

These tenets are nicely described by the BPM Institute.

So WCF is build from the ground up with these SOA tenets and SOA vision in mind.. what does it look like?

Because a picture says more than a 0x3E8 words, the following picture gives a clear view of the WCF architecture.
The 'Contracts' and 'Service runtime' parts can be seen as the service model;
the 'Messaging' part can be seen as the channel model.

Windows Communication Foundation Architecture

The individual parts are explained on the Microsoft site:

• Contracts

"Contracts define various aspects of the message system. The data contract describes every parameter that makes up every message that a service can create or consume"

"The message contract defines specific message parts using SOAP protocols, and allows finer-grained control over parts of the message, when interoperability demands such precision. The service contract specifies the actual method signatures of the service, and is distributed as an interface in one of the supported programming languages, such as Visual Basic or Visual C#."

"Policies and bindings stipulate the conditions required to communicate with a service. For example, the binding must (at a minimum) specify the transport used (for example, HTTP or TCP), and an encoding. Policies include security requirements and other conditions that must be met to communicate with a service."

• Service Runtime

"The service runtime layer contains the behaviors that occur only during the actual operation of the service, that is, the runtime behaviors of the service. Throttling controls how many messages are processed, which can be varied if the demand for the service grows to a preset limit. An error behavior specifies what occurs when an internal error occurs on the service, for example, by controlling what information is communicated to the client. (Too much information can give a malicious user an advantage in mounting an attack.) Metadata behavior governs how and whether metadata is made available to the outside world. Instance behavior specifies how many instances of the service can be run (for example, a singleton specifies only one instance to process all messages). Transaction behavior enables the rollback of transacted operations if a failure occurs. Dispatch behavior is the control of how a message is processed by the WCF infrastructure.

Extensibility enables customization of runtime processes. For example, message inspection is the facility to inspect parts of a message, and parameter filtering enables preset actions to occur based on filters acting on message headers."

• Messaging

"The messaging layer is composed of channels. A channel is a component that processes a message in some way, for example, by authenticating a message. A set of channels is also known as a channel stack. Channels operate on messages and message headers. This is different from the service runtime layer, which is primarily concerned about processing the contents of message bodies. There are two types of channels: transport channels and protocol channels. Transport channels read and write messages from the network (or some other communication point with the outside world). Some transports use an encoder to convert messages (which are represented as XML Infosets) to and from the byte stream representation used by the network. Examples of transports are HTTP, named pipes, TCP, and MSMQ. Examples of encodings are XML and optimized binary.

Protocol channels implement message processing protocols, often by reading or writing additional headers to the message."

• Activation and Hosting

"In its final form, a service is a program. Like other programs, a service must be run in an executable. This is known as a self-hosted service.

Services can also be hosted, or run in an executable managed by an external agent, such as IIS or Windows Activation Service (WAS). "

These quotes contains lots of concepts that will be explained in later posts.. for now, try to get the broad pictrure of WCF... details will follow soon..

Lots of developers who build services and clients in .NET will only interact with the service model. It's the WCF programming model when using standard WCF functionality and its an abstraction of the underlying Channel Model. But, if you need to support advanced scenario's like custom interoperability, a different transport protocol or your custom serializer you will need to dive deeper into the WCF architecture and more particular its extensibility points.

More in the next WCF post:

In Depth Windows Communication Foundation (Part 2) - Address, Binding & Contract