Dennis van der Stelt : WCF

Databases and coupling

Dennis van der Stelt — Fri, 04 Jan 2013 22:36:12 GMT

We probably all learned this at school. When you build software, you analyze requirements, find the nouns and build an entity-relationship model, an ERD. You start with the first normal form and normalize the model until you start building software upon it. But when you’re building software in a distributed environment, multiple components will likely need to access the same data. In the most traditional of systems, you’ll have a single database with great value in it, because all data the is valuable to your company is in this database. And all those components are based on this data, so they need access to it. Being more concrete, you can think of this as multiple Visual Studio solutions with projects and they all have connection strings to this high value database.

We all know coupling is bad, however we don’t always know how to fix this. Because we don’t know where the worst coupling is. Let’s think about this for a minute. We build layers into our software, sometimes even separated through additional facades implemented through SOAP and XML. And than we tell ourselves the user interface is decoupled from the database. So that changes in the database can be made without affecting the upper layers and the user interface. We’ve hidden this behind a data-layer and use complex O/RM solutions to hide even more behind models with complex mappings to the database. Until even the slightest change means updating the model, the mapping, the data-layer and even business logic, facades and everything all the way up to the user interface. Even worse, this change, which took too long to build… it completely breaks other components in our distributed architecture.

I’ve seen so many solutions trying to fix this. From stored procedures that can be changed on the fly (but without proper testing), to additional tools that should fix problems, to ad hoc data changes. And I just deliberately mentioned the three worst solutions, in my humble opinion. Because too many people execute these so called fixes, ranging from junior developers on the maintenance team to the senior DBA. The problem is, that all of them do this without proper knowledge of the business rules. Because these are actually in the code. So how come we still think we can solve all problems using the mentioned solutions?

So coming back to our question, where the worst coupling is. It’s in the database! There’s so much hidden business logic in our data. Some of the data belongs together without anyone being able to notice this. One of the worst invisible coupling I’ve ever seen is where the status of a client was made up out of multiple records in a single table. The state of a client was reflected by a record and second record. Unless there was a third record with some information, than the client had another state. Unless the second record had its timestamp in the past, than it was in even another state. And this went on and on. In the end this resulted in hundreds of locations where all these conditions were checked. These states were however completely invisible in the database! One had to just know what they could possible represent. Until some developer came along and made up another combination of records to present another state.

So how can this be solved? That’s difficult to answer. But a good way to start is try to divide and conquer. Everything that can be taken out of the big database, should be put in another database. That will make the problem smaller and more manageable. Of course it’s ridiculous to just add more connection strings to every single component, so that they can still access the same database. We’d still have the same coupling, but with added complexity of querying the databases. We can’t directly join tables anymore, and don’t get me started on SQL Server’s linked servers.

Will SOAP and XML free us from the coupling? Not really. Or better yet, not at all. Not in the way most people intended to get rid of coupling. Coupling isn’t solved by taking out design time coupling. It’s the runtime coupling that’s difficult to solve. What if the webservice that queries your smaller database is offline, or it’s blocked by requests from other webservices. Or it’s simply not fast enough for your performance demands.

The solution is to decouple these services even during runtime. This means they can’t call each other anymore. We have to make sure they know the answer, before these services are asking the question. How this can be achieved, is something for another post.

What is messaging

Dennis van der Stelt — Wed, 25 Apr 2012 06:45:40 GMT

I’ve written in SDN Magazine about messaging and how it relates to RPC. It isn’t about messaging vs. RPC, but more or less an attempt to explain what benefits messaging can add to your software. Monday April 23rd I gave a presentation about the same subject. With this post I want to show the code so people can have a better look at it. Remember that there’s so much more possible than I show. I’m not going all the way, just showing how spatial coupling can be solved. Platform coupling is solved by WCF and nServiceBus self and temporal coupling can be achieved by doing it asynchronously over MSMQ, for example. nServiceBus does this by default, WCF can do this by marking operations as OneWay and selecting the msmqBinding.

So what did I show? First of all, let’s look at code that Visual Studio 2010 has in its WCF Service Application template. I sometimes get remarks that the info in a post is not complete, so here it goes

Do File –> New Project
Select “WCF” on the left and then the “WCF Service Application” template.

You can see IService1 interface with a method named “GetData” which expects a single parameter and returns a string value. The client knows the method to execute and when something changes, the coupling of the client to the service might break the client. Versioning is only on of the many problems that might hit you. This is the implementation in the Service1 class.

public string GetData(int value)
{
    return string.Format("You entered: {0}", value);
}

Add a new Console Application to your solution, add a Service Reference without changing anything of the defaults. Then create the code to call this service. Your console application should look like this.

class Program
{
    static void Main(string[] args)
    {
        ServiceReference1.Service1Client svc = new ServiceReference1.Service1Client();
        string result = svc.GetData(10);

        Console.WriteLine("Result : {0}", result);
    }
}

So the idea is that we don’t create separate methods for everything we want to send, but rather have something in place that finds the correct handler class for our message. So what we need is a single generic method in our service contract that accepts anything that conforms to a message we specify. Add the following method to your IService1 interface and make sure your code compiles. This means you’ll have to implement the method in the Service1 class.

[OperationContract]
void Execute(Message message);

As you can see we specified the class Message as parameter so we’ll need to define it as well.

public class Message
{
}

Now the Execute method on our Service1 class needs to call a handler class that will contain our code. We’ll specify a default interface so that all our handlers adhere to this interface. That way we’ll be able to easily find all handlers via reflection. Let’s have a look at the interface.

public interface IHandleMessages<T> where T : Message
{
    void Handle(T message);
}

Now all we need to do is create a real message and a handler that will be able to work with this message.

public class GameOfTheYear : Message
{
    public string Name { get; set; }
    public int Year { get; set; }
}

public class GameOfTheYearHandler : IHandleMessages<GameOfTheYear>
{
    public void Handle(GameOfTheYear message)
    {
        Debug.WriteLine("Game : " + message.Name);
    }
}

The message is quite simple and the implementation of our handler maybe even simpler. But these aren’t the point currently. What is important is how we actually execute the Handle method from our service. Here’s the code for it and we’ll go through it line by line.

public void Execute(Message message)
{
    Assembly assembly = (message.GetType()).Assembly;

    var allMessageHandlers =
            from type in assembly.GetTypes()
            where !type.IsAbstract
            from interfaceType in type.GetInterfaces()
            where interfaceType.IsGenericType
            where interfaceType.GetGenericTypeDefinition() == typeof(IHandleMessages<>)
            select type;

    Type messageInterface = typeof(IHandleMessages<>).MakeGenericType(message.GetType());
    var myMessageHandlers = allMessageHandlers
                                    .Where(type => type.GetInterfaces()
                                    .Any(it => it == messageInterface))
                                    .Distinct();

    foreach (var handler in myMessageHandlers)
    {
        object handlerInstance = Activator.CreateInstance(handler);
        MethodInfo methodInfo = handler.GetMethod("Handle");
        methodInfo.Invoke(handlerInstance, new[] { message });
    }
}

At line 3 we get the assembly of the message we’ve received. This is part of the convention over configuration you can use, which states that the handler for the message should be in the same handler. Of course you could scan every single assembly in the same folder as you. For performance benefits you can scan it a single time and store all handlers and its methods in memory. Again, we’re keeping it simple so it’s easier to understand. At line 5 we’re searching for all types that are not abstract (line 7), implement a generic interface (line 9) that are of type IHandleMessages (line 10).

Then in line 13 we compose a type of the generic IHandleMessages interface with the type of our message. In line 14 we filter our just selected handlers so that we’ll only have the ones that actually implement our exact interface. Now that we have our actual handlers, we can try to create an instance of it (line 21), find the Handle method and invoke it with our message as its parameter.

Now refresh your ServiceReference in your console application client by right-clicking the service reference and selecting the update item in the context menu. Now you should be able to create a GameOfTheYear object. However, although our service does recognize the “Execute” method, it has no knowledge of the GameOfTheYear class. This simply is because WCF doesn’t automatically provides every single class in its WSDL/MEX-endpoint so we need to provide this information to it. Open the IService1 interface again and change the contract for our Execute method so it looks like this.

[OperationContract]
[ServiceKnownType("GetKnownTypes", typeof(MessageTypeFinder))]
void Execute(Message message);

Now recompile the project and update the service reference again. Everything should work flawlessly again. If this works, we can try to see if we can do something very valuable; create an additional handler that logs our messages to disk.

public class GameOfTheYearLogHandler : IHandleMessages<GameOfTheYear>
{
    public void Handle(GameOfTheYear message)
    {
        Logger.Write("We've processed " + message.Name);
    }
}

The same code will execute both handlers without any changes. We’ve really decoupled the execution and handling of the message we’re sending from the initial service. As you can see we can create multiple handlers for a single message. What we can also do is create a single handler for multiple messages. We’ll first define the message and add an additional interface to our GameOfTheYearHandler.

public class GameReview : Message
{
    public string NameOfGame { get; set; }
    public string Review { get; set; }
}

public class GameOfTheYearHandler : IHandleMessages<GameOfTheYear>, IHandleMessages<GameReview>
{
    public void Handle(GameOfTheYear message)
    {
        Console.WriteLine("Game : " + message.Name);
    }

    public void Handle(GameReview message)
    {
        Console.WriteLine("Revied : " + message.NameOfGame);
    }
}

First thing to remember is that we need to make sure the GameReview message is specified as a KnownType to our service. As we don’t want many lines with ServiceKnownTypeAttribute statements there, we need a different solution. Add the following class to your code and then replace the original ServiceKnownType line with the last line in the following code.

public class MessageTypeFinder
{
    public static IEnumerable<Type> GetKnownTypes(ICustomAttributeProvider provider)
    {
        IEnumerable<Type> query =
                from type in typeof(Message).Assembly.GetTypes()
                where typeof(Message).IsAssignableFrom(type)
                select type;

        return query.ToArray();
    }
}

[ServiceKnownType("GetKnownTypes", typeof(MessageTypeFinder))]

Now we only need to tweak the execution of the handlers in the foreach loop to the following code.

foreach (var handler in myMessageHandlers)
{
    var methods = from m in handler.GetMethods()
                                where m.Name == "Handle"
                                from p in m.GetParameters()
                                where p.ParameterType == message.GetType()
                                select m;

    object handlerInstance = Activator.CreateInstance(handler);
    var methodInfo = methods.Single();
    methodInfo.Invoke(handlerInstance, new[] { message });
}

We can’t simply select the Execute method anymore, as there are multiple. So we’re checking the parameter type and see if it’s the same type as our incoming message. There obviously cannot be more than one method with the exact same parameters, so we can select Single() on line 10 and then we’ll be able to execute the method.

FYI: During the SDN event I forgot to create the actual instance of the handler and was trying to execute the Handle method on the type. This is obviously not possible. So now you know why it didn’t work during the presentation.

nServiceBus
So during the presentation I also mentioned nServiceBus. If you look at the code you need to write to use nServiceBus, this is exactly the handlers and messages as I’ve shown in the code above. However with nServiceBus you can use interfaces as messages so you can create message with complex inheritance trees. A method to “initiate” an interface is provided, which creates a proxy which you can then fill with your information. Since version 3.0 of nServiceBus you no longer need to implement the IMessage interface on your messages which makes creating libraries with messages that are shared, much easier, since you don’t need an assembly reference to nServiceBus anymore.

Of course we have no need to write plumbing code, as nServiceBus has done this all for you.

Transactions are supported in WCF, but with nServiceBus everything is transactional by default.
As said, in WCF you can mark messages OneWay and select the msmqBinding to use msmq. nServiceBus does this by default.
nServiceBus makes it possible to do request/reply asynchronously. Due to the nature of queuing, it’s not possible to immediately send a response. The sending application however can specify a return queue in it’s message (nServiceBus does this for you) and with a Bus.Reply(myMessage) you send the return message.
Retry of message is supported with a variable amount of retries. After final failure the messages get enriched with exception information and transferred to a (configurable) error queue.
Publish/Subscribe is possible where one publisher has no knowledge of any clients receiving the messages. A variable number of clients can subscribe to the messages and nServiceBus takes care of subscriptions. Since version 3.0 you can store these in RavenDB.
Long running processes (called sagas) are supported where you can wait for multiple incoming messages before continuing.
Timeouts are supported so when within a saga messaging don’t arrive on time, you can send yourself a warning. Since version 3.0 you can also send messages to yourself in the future. These messages don’t arrive before the time you specified.

Conclusion
Again, messaging isn’t the silver bullet to your problems. It is however another way to communicate out of process to other applications or business components. It should provide additional options to implement without your architecture and you should seriously consider it if you haven’t used messaging and/or queuing frameworks before. Messaging has a lot of additional perks which I wrote about in my SDN article. When the new magazine arrives, I’ll post the PDF on my weblog. Until then, you are allowed to contact me and request the article.

Download the source here.

WCF Simple Example in Visual Studio 2010 – part 2

Dennis van der Stelt — Sat, 19 Jun 2010 20:24:00 GMT

This topic is covered in multiple posts

Creating simplest solution with default endpoints
Manually adding and configuring the endpoints (you're reading it right now)
More to come...

The previous post was the most simple example of creating a WCF service and calling it from a client application. In this post you can read how you can achieve the exact same behavior, but now manually adding every bit of configuration. So we’ll basically override the default endpoints, configure our won, resulting in exactly the same behavior.

The idea behind this is that you understand what WCF does and that you can do it yourself. Besides that, the previous .NET Framework versions don’t support the default endpoints, meaning that the solution at the end of this article also works in Visual Studio 2008.

What will we do?

Add BasicHttpBinding endpoint
Add MEX endpoint
Add Metadata behavior

Metadata behavior
We’ll start with bullet three, simply because almost everything is already in place. The solution from the previous weblog post ended with this in the application configuration from the ConsoleHost application.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <system.serviceModel>
        <behaviors>
            <serviceBehaviors>
                <behavior>
                    <serviceMetadata httpGetEnabled="True"/>
                </behavior>
            </serviceBehaviors>
        </behaviors>
    </system.serviceModel>
</configuration>

The service behavior has no name, making it the default for all services in WCF4. All we have to do is give it a name. Change line 6 into the following.

                <behavior name="MyBehavior">

Adding BasicHttpBinding endpoint
We’ll now add the first endpoint using the BasicHttpBinding. Right under <system.serviceModel> we’ll add the <services /> tag and add our service. Completely empty this will result in the following.

<services>
    <service name="">
        <endpoint 
            address="" 
            binding="" 
            contract="" />
    </service>
</services>

Now we have to fill in the blanks. More information can be found in the articles about the WCF ABC and hosting the service.

Name
This is a bit misleading, as you can’t just enter any name, it’s actually the type of the service.
This must be the fully qualified name of the implementation of our service. This means not the interface, but the class. Its name is EmailValidator but its full name includes the namespace, resulting in EmailService.EmailValidator.
Address
The address we don’t have to fill in, because the base address in our code already defines it. You can also define this in configuration as you can read in the post Address.
Binding
The binding is simply basicHttpBinding. Note the camelCasing.
Contract
Here we should enter the contract, which is our interface. As with the name attribute, we need to enter the fully qualified name, resulting in EmailService.IEmailValidator.

You can view the end result at the end of this article and in the download, also at the end of this article.

Adding MEX endpoint
The MEX endpoint needs the metadata behavior configured, but we’ll get back to that. First we need to add the endpoint. Again the WCF ABC, an address, binding and contract.

Address
Because we cannot have this endpoint at the same address as the BasicHttpBinding endpoint, we need to enter “mex” here.
Binding
This is simple, it’s just mexHttpBinding
Contract
This is simple as well, although a bit weird, it HAS to be IMetadataExchange. Not the fully qualified name or anything, it has to be just this.

Enabling the metadata behavior
Now all we have to do is add the metadata behavior. This is done at the root of the service, where we first entered the name. There’s another attribute there called behaviorConfiguration. We have to enter the name of our behavior configuration there, which is MyBehavior.

End result
This results in the following configuration.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <system.serviceModel>
        <services>
            <service name="EmailService.EmailValidator" behaviorConfiguration="MyBehavior">
                <endpoint 
                    address="" 
                    binding="basicHttpBinding" 
                    contract="EmailService.IEmailValidator" />
                <endpoint 
                    address="mex" 
                    binding="mexHttpBinding" 
                    contract="IMetadataExchange" />
            </service>
        </services>
        <behaviors>
            <serviceBehaviors>
                <behavior name="MyBehavior">
                    <serviceMetadata httpGetEnabled="True"/>
                </behavior>
            </serviceBehaviors>
        </behaviors>
    </system.serviceModel>
</configuration>

You can download the Visual Studio 2010 and the Visual Studio 2008 solution right here.

WCF Simple Example in Visual Studio 2010

Dennis van der Stelt — Wed, 16 Jun 2010 18:36:00 GMT

This topic is covered in multiple posts

Creating simplest solution with default endpoints (you're reading it right now)
Manually adding and configuring the endpoints
More to come...

It’s been a long, long time since I wrote the original WCF Simple Example post. It was even before Visual Studio 2008 and since then, a lot of things changed. As still a lot of folks place comments and questions to that post, let’s have a look at what we currently have to do to get a service up and running and consume it in a client.

This time we’ll start with a class library assembly (a .dll) and we’ll host the service inside a console application. The client will use a Windows Forms application again. Although we do everything in Visual Studio 2010, most will be usable in VS2008. I will mention it when it isn’t and provide an alternative. I’ll be a bit more descriptive about what we have to do, so this post is a little longer than the original.

Create Project
First create a new "class library", this will become the implementation of our service. Choose New Project and select the Class Library as project template. At the bottom, set as name for the project “EmailService” and the solution name “WCFSimpleExample2010”. If you can’t set the solution name, check the Create directory for solution box.

Create the contract
We’ll first create the contract with only one method; or operation as they are called in WCF. The "class library" should have added a class called "Class1", you should rename it to IEmailValidator.cs and make it an interface with the same name.

Now add a single method signature called ValidateAddress that takes one string argument called emailAddress and returns a boolean. This is a normal interface, nothing fancy and the end result is as follows:

public interface IEmailValidator
{
    bool ValidateAddress(string emailAddress);
}

Now we need to tell WCF that this is our contract. We do that by adding attributes, but first we need to add a reference to System.ServiceModel. Right-click the project and select Add reference and select System.ServiceModel from the list. I’m using the Visual Studio 2010 Pro Power Tools so my screen might look different from yours, but the idea is the same.

Now you can add the attributes to your interface. On top of the interface place the ServiceContract attribute and on the operation place the OperationContract attribute. Add the using System.ServiceModel at the top of your codefile, or let Visual Studio do it for you by having your cursor in on of the attribute names. When you typed it in correctly and case sensitive, you can press CTRL + . and a context menu should appear to let you add the using automatically. Your interface should finally look like this:*

[ServiceContract]
public interface IEmailValidator
{
    [OperationContract]
    bool ValidateAddress(string emailAddress);
}

Create the service implementation
Now that we’ve created the contract we need to write code for the service to actually do what we want it to do. Create a new class and make it implement the interface. After that, use a regular expression to verify the email address and return true value if it’s correct. You should have something like the following code, or make up your own. :-)

public class EmailValidator : IEmailValidator
{
    public bool ValidateAddress(string emailAddress)
    {
        Console.WriteLine("Validating: {0}", emailAddress);
        
        string pattern = @"^([0-9a-zA-Z]([-.\w]*[0-9a-zA-Z])*@(([0-9a-zA-Z])+([-\w]*[0-9a-zA-Z])*\.)+[a-zA-Z]{2,9})$";
        return Regex.IsMatch(emailAddress, pattern);
    }
}

Now you have the two most important classes for your service. You don’t actually have to use an interface, but it’s a best practice. That way you can inherit multiple interfaces for or do versioning with different interfaces.

Creating the host
As said, for our host we’ll initially use a console application. Choose to add a new project and now have a Console Application as project template. Name it “ConsoleHost”.

Add the reference to System.ServiceModel again and also to your EmailService project. In your Main method, create a ServiceHost object and give it the correct arguments in the constructor, as shown below.

Type serviceType = typeof(EmailValidator);
Uri serviceUri = new Uri("http://localhost:8080/");

ServiceHost host = new ServiceHost(serviceType, serviceUri);
host.Open();

On line 4 is the creation of the ServiceHost object. As first argument it receives the implementation of our service as a type. And a base address as second argument. Read more about base addresses here and more about hosting here. The type is defined on line 1 and the base address on line 2. Finally on line 5 our host is started.

WCF4 : Default endpoints
Now here’s a difference in .NET Framework 4.0 because this is not possible in previous version of .NET. Currently the default endpoints are used, which is a new feature to make configuration of your services less of a hassle. I like to explicitly define everything in detail so everyone knows what happens. But for our example, this works quite well. If you’re not using .NET 4.0 you might want to continue to part 2 of this weblog post, which will be posted later.

You could add the default endpoints yourself by adding host.AddDefaultEndpoints(); to the code, right before the host.Open(); statement.

How can we see what endpoints are configured by default? I have a little script from way back that displays everything currently running. I won’t go into details, just paste the following after the host.Open(); part.

#region Output dispatchers listening
foreach (Uri uri in host.BaseAddresses)
{
    Console.WriteLine("\t{0}", uri.ToString());
}

Console.WriteLine();
Console.WriteLine("Number of dispatchers listening : {0}", host.ChannelDispatchers.Count);
foreach (System.ServiceModel.Dispatcher.ChannelDispatcher dispatcher in host.ChannelDispatchers)
{
    Console.WriteLine("\t{0}, {1}", dispatcher.Listener.Uri.ToString(), dispatcher.BindingName);
}

Console.WriteLine();
Console.WriteLine("Press <ENTER> to terminate Host");
Console.ReadLine();
#endregion

Now you should be able to see the endpoints like in the first following screenshot. You can use a browser like Internet Explorer to go to the service uri and look at the default MEX endpoint.

As you can see it’ll tell you that a MEX endpoint (aka metadata) isn’t configured yet. Now an easy way would be to do this via the new default endpoints. My first impression was that this would work.

Type serviceType = typeof(EmailValidator);
Uri serviceUri = new Uri("http://localhost:8080/");

ServiceHost host = new ServiceHost(serviceType, serviceUri);
host.AddDefaultEndpoints();
// This actually doesn't just simply work.
host.AddServiceEndpoint(new ServiceMetadataEndpoint());

On line 5 you can see that we add the default endpoints and line 7 adds the ServiceMetadataEndpoint, or the MEX endpoint. Unfortunately it cannot add the Metadata behavior itself, so you still have to do this yourself. The other way it to specify in configuration that you want metadata enabled. Also new in WCF4 is that you can inherit configuration. You can specify in either the machine.config or in your local configuration what should be enabled by default for WCF services. I recommend you don’t do this in machine.config, but that’s just my opinion. Here’s how I enabled it in my project configuration, the app.config of our console host. Remember that in the follow up post to this, we’ll do this the old fashioned way, which will work in Visual Studio 2008 and has my preference.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <system.serviceModel>
        <behaviors>
            <serviceBehaviors>
                <behavior>
                    <serviceMetadata httpGetEnabled="True"/>
                </behavior>
            </serviceBehaviors>
        </behaviors>
    </system.serviceModel>
</configuration>

As you can see, I have not specified a name for the behavior so in WCF4 this means it’ll be used by all services. This also means that every service needs a base address for http endpoints.

For reference, here’s the code for our console host:

static void Main(string[] args)
{
    Type serviceType = typeof(EmailValidator);
    Uri serviceUri = new Uri("http://localhost:8080/");

    ServiceHost host = new ServiceHost(serviceType, serviceUri);        
    host.Open();

    #region Output dispatchers listening
    foreach (Uri uri in host.BaseAddresses)
    {
        Console.WriteLine("\t{0}", uri.ToString());
    }

    Console.WriteLine();
    Console.WriteLine("Number of dispatchers listening : {0}", host.ChannelDispatchers.Count);
    foreach (System.ServiceModel.Dispatcher.ChannelDispatcher dispatcher in host.ChannelDispatchers)
    {
        Console.WriteLine("\t{0}, {1}", dispatcher.Listener.Uri.ToString(), dispatcher.BindingName);
    }

    Console.WriteLine();
    Console.WriteLine("Press <ENTER> to terminate Host");
    Console.ReadLine();
    #endregion
}

Accessing the metadata
Because we now have enabled our service and our metadata endpoint, the MEX endpoint, we can view it through Internet Explorer or another browser. Execute the console host (it has to be alive or the endpoints won’t be accessible) and browse to the URI of your service : http://localhost:8080/

If this shows a nice screen with a link to the WSDL you’re very likely done with the service.

Create client application
We’ll now add another project that will consume the service and will be able to verify if entered email addresses are valid, or at least according to our regular expression.

Add a new console application like before and this time call it ConsoleClient. Make sure your service (the host) is running, but don’t have it running in debug mode. Easiest way is to set the ConsoleHost project as startup project en press CTRL + F5 to run it without debugging turned on.

We now need a proxy class that sits between our client and service. There are two ways to create a proxy for our service. I have a preference for doing it manually, so you know what exactly is happening. I’ll show that first.

Manually create proxy
First start up a Visual Studio 2010 (or Visual Studio 2008) Command Prompt and move to the location of the ConsoleClient. Because it’s a Visual Studio command prompt you should have access to the proxy generator svcutil.exe. Input the following commandline

svcutil http://localhost:8080/ /o:ServiceProxy.cs /config:App.Config /n:*,ConsoleClient

This should generated two files, the service proxy and an application configuration file. Go back to Visual Studio and in your ConsoleClient application make all files visible through the icon at the top of the Solution Explorer, as seen in the right screenshot. The App.Config and ServiceProxy.cs should become available and you can include these.
Update : The console window screenshot shows ConsoleHost as namespace, this is incorrect and should be ConsoleClient as the full commandline statement above states.

When we ran svcutil.exe the first argument was the location of our service as specified in the host. This is the base address. The second argument is what the tool should output, our proxy. The third argument is that we also want it to update our application configuration and if it’s not available, create it. The last argument is the namespace our proxy should be placed in (or should have), which should now be the same as our application itself.

Call the service
Now we can finally start consuming the service. When you go to your Main method in your Program class again, you can access the proxy class, which is the name of your service with Client suffixed. So ours is EmailValidatorClient.

EmailValidatorClient svc = new EmailValidatorClient();
bool result = svc.ValidateAddress("dennis@bloggingabout.net");

In line 1 you can see the proxy being initialized. Does doesn’t mean the connection is set up, this is done on first call. Line 2 shows the calling of the service and getting the result back.

This is our entire method Main which will continue to ask for email addresses until you enter none.

static void Main(string[] args)
{
    while (true)
    {
        Console.WriteLine("Enter an email address or press [ENTER] to quit...");
        string emailAddress = Console.ReadLine();

        if (string.IsNullOrEmpty(emailAddress))
            return;

        EmailValidatorClient svc = new EmailValidatorClient();
        bool result = svc.ValidateAddress(emailAddress);

        Console.WriteLine("Email address is valid : {0}", result);
    }
}

Creating proxy through Visual Studio, the easy way.
Instead of creating the service proxy manually, via svcutil.exe, you can also let Visual Studio create it for you. Just right-click the project and select ‘Add Service Reference...’ You’ll get a dialog window where you enter the address of your service and the namespace.

Now we entered ConsoleClient as namespace, but it concatenates this to the already existing namespace. So now you can access the EmailValidatorClient via ConsoleClient.ConsoleClient.EmailValidatorClient. One of the reasons I don’t like to use this automatically generated proxy class. You should now not forget to add a using statement to this namespace at the top of your class. Probably a better solution is to set the namespace to Proxies or something, in the dialog, so the complete namespace makes more sense.

Run the client
While the service is still running (of not, restart it) you can right-click your ConsoleClient and select Debug and Start new instance and you’re done.

What next?
Next we’ll extend this blogpost with at least two more, step-by-step blogposts explaining how to manually add endpoints and how to host your service in IIS. You can read more about it here.

Download
Here's the download for VIsual Studio 2010. In the follow up article a Visual Studio 2008 solution is available.

Microsoft AppFabric explained for SDN

Dennis van der Stelt — Tue, 25 May 2010 05:31:19 GMT

Last Tuesday, may 18th 2010, I gave a presentation on Microsoft’s AppFabric. I explained that there are actually two themes of it; Windows Server AppFabric and Windows Azure AppFabric. They both have their own products.

Windows Server AppFabric

Services and Workflow Management
This is sometimes called “Hosting” and was known under its codename “Dublin”
Caching
Distributed caching which was known under its codename “Velocity”

Windows Azure AppFabric
This was known under its previous name as “.NET Services”

ServiceBus
This is used to connect applications through firewalls, proxies and NAT.
Access Control
Once you’ve connected your applications, you might want to secure the connection.
This is also used to map different identity stores so you don’t need federated identities.

You can download the slidedeck and the demos.

A short review on all 4 products

Services and Workflow Manangement
This seems quite cool and quite stable. Surely something you’d want to use asap if you’re running WCF services and/or WF workflows.
Caching
This one is quite hard to grasp at first, especially the terminology used. It’s also a shame there are no decent tools to work with and monitor stuff. Try to introduce this within your IT department as they need to provide one or more machines as a caching server. I’m going to try though!
ServiceBus
Not very difficult to grasp and use, but you sure need to find a good project to be able to introduce this.
Access Control
One of the hardest parts of the AppFabric, but isn’t security always a ***? But Access Controls probably tops those all as there aren’t any good examples for mapping identities and no tools whatsoever to support it.

Let me know if you have any experience with these or if you’re planning on using it!

AppFabric : Configuration binding extension could not be found.

Dennis van der Stelt — Sat, 27 Feb 2010 20:34:00 GMT

I have recently installed the Windows Azure AppFabric SDK because I’m writing an article for the Dutch .NET Magazine. Problem is I try to do everything in Visual Studio 2010 these days, just because it’s so cool to have something that’s buggy. Seriously! Sometimes you get headaches because you just can’t figure out why something’s not working, only to find out it’s because it really isn’t working because of the current beta version you’re working with. But on the other side it’s really fun and you learn a lot.

As now, when I got the following message.

Configuration binding extension 'system.serviceModel/bindings/netTcpRelayBinding' could not be found. Verify that this binding extension is properly registered in system.serviceModel/extensions/bindingExtensions and that it is spelled correctly.

It’s a System.ConfigurationErrorsException which can mean that you might be right with what you configured, the .NET runtime just can’t figure out what it is that is wrong. This time it’s because some extensions to WCF weren’t added to the machine.config of .NET 4.0 RC. It was however added to the machine.config of .NET 2.0 so I took it from there. And for future reference for my dear readers and all others that come in via Google, I’m posting the fix here.

Sidenote : I’m using 2.0.50727 and 4.0.30128 version of the .NET Framework, but the versions might differ on your machine.

Go to C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\ and read the machine.config from there. In the node configuration\system.servicemodel\extensions\ you find two nodes. The first is bindingElementExtensions and the second is bindingExtensions. You’ll see some bindings with a name that contains “relay” in it. Copy these into notepad or so.

Now open up C:\Windows\Microsoft.NET\Framework\v4.0.30128\Config\ and edit the machine.config there. Copy the lines from the 2.0 config that are missing in the 4.0 config and your AppFabric service should be able to start.

"Add service reference" is disabled

Dennis van der Stelt — Fri, 28 Mar 2008 20:14:23 GMT

In Visual Studio 2008 you can right-click a project and choose for "Add service reference" to create a proxy class for your web service. WCF preferred, of course.

But for some reason, the Visual Studio team disabled it when you're in debug mode. Something that used to work in Visual Studio 2005, so after starting a host, you could add the reference. In VS2008 this is disabled, or grayed out'.

The solution is to set your host as startup project, press CTRL-F5 so it'll be started without debugging and then you're able to choose to add the service reference.

Hosting a WCF service in a Windows Service

Dennis van der Stelt — Thu, 28 Feb 2008 08:52:55 GMT

In my last post I explained how you could use WCF and MSMQ to respond to messages asynchronously. We've setup a class library with our service, a console application for our host and a console application for our client. In this post I'll explain how we can use the class library again for hosting our WCF service in a Windows Service.

1: Add the Windows Service

Add a new Windows Service project. Right-click the solution, choose "Add" -> "New Project..." and select "Windows" from the tree on the left. Then select "Windows Service" from the project templates. Call it "MailServiceHost" for example. It'll create the project with a file (class) called 'Service1.cs". Rename it to 'MailService.cs' using the solution explorer.

2: Implement OnStart and OnStop methods

When you look into your MailService class, you'll see that it's derived from ServiceBase and that two methods are already defined. We'll first implement the OnStart method. Here we'll do exactly the same as in the console application created in the previous article.

Create the message-queue of it does not exist yet.
Create and open the ServiceHost

The only difference now is that it's a private member variable (defined on class level) because the OnStop method must have access to it as well.

1 ServiceHost _host = null;

3 protected override void OnStart(string[] args)

4 {

5 string queueName = ConfigurationManager.AppSettings["SendMailQueueName"];

7 Trace.WriteLine("Starting Class-A E-mail Service...");

9 if (!MessageQueue.Exists(queueName))

10 {

11 Trace.WriteLine("Creating queue : " + queueName);

12 MessageQueue.Create(queueName, true);

13 }

15 _host = new ServiceHost(typeof(SendMailService));

16 _host.Open();

17 }

Here's a quick overview

Line 1 declares the ServiceHost as member variable.
Line 5 retrieves the queue name from your configuration file.
Line 9 & 12 create the queue if it doesn't exist yet.
Line 15 & 16 instantiate and open the host.
I've also added a few trace messages. The easiest way to see these is to get DebugView from SysInternals.

Now we have to implement the OnStop method.

protected override void OnStop()

{

Trace.WriteLine("Shutting down Class-A E-mail Service...");

if (_host != null)

{

_host.Close();

_host = null;

}

Note that the above code does not do any error handling or check if the ServiceHost its state is actually open, etc, etc.

3: Configuration

Now we have to add configuration. Add a new Application Configuration file and just copy & paste the entire configuration file from our previous Console Application host project.

4: ProjectInstaller

We've created our service, but aren't done yet. For Windows Services it's best if you add a ProjectInstaller so the service can easily be installed. Choose to add a new item to the project and select the "General" category and then the "Installer Class" template.

[RunInstaller(true)]

public partial class ProjectInstaller : Installer

{

public ProjectInstaller()

{

InitializeComponent();

ServiceProcessInstaller processInstaller= new ServiceProcessInstaller();

ServiceInstaller serviceInstaller = new ServiceInstaller();

processInstaller.Account = ServiceAccount.LocalSystem;

serviceInstaller.StartType = ServiceStartMode.Automatic;

serviceInstaller.ServiceName = "Class-A E-Mail MSMQ Service";

Installers.Add(serviceInstaller);

Installers.Add(processInstaller);

}

In the above code we've added a ServiceProcessInstaller and a ServiceInstaller. The ServiceProcessInstaller is used by InstallUtil.exe and we're using it to specify that we want to use the Local System account to run our service. If you specify ServiceAccount.User and don't provide a username and password, it'll request these during installation of the service. With the ServiceInstaller we're specifying that our service has to start automatically on Windows startup and the name of our service.

That's it, our WCF service is now running inside a Windows (Managed) Service.

Download the solution for a complete view on what we've done.

WCF and MSMQ

Dennis van der Stelt — Thu, 28 Feb 2008 08:52:33 GMT

It's been a while since I blogged about one of my favorite topics, Windows Communication Foundation.

In this article I'll explain how you can use MSMQ with WCF to really process messages asynchronously. It's unbelievable how easy this is. Read my complete WCF series on how to set up your first service. The idea in this example is that we have to send some e-mails, but we don't want that to be done immediately.

We'll setup the service with a Console Application. In another post we'll host our service using a Windows Service.

1: Make sure MSMQ is installed.

MSMQ must of course be installed. Check your Windows components to see if it's installed. In Vista this is under "Control Panel" -> "Programs and Features" -> "Turn Windows features on or off".

On the right you can see I've turned on everything. If it's already installed you should be able to take a look at the queues. Right-click on the "Computer" icon and choose "Manage". It's under "Services and Applications".

2: Setup a class library.

Create a new project and make it a class library. Add a really simple interface. Again, if you want to know the how and why, read my complete WCF series.

[ServiceContract(Namespace="http://schemas.class-a.nl/msmq/example01/2008/02/", SessionMode=SessionMode.NotAllowed)]

public interface ISendMail

{

[OperationContract(Name = "SubmitMessage", IsOneWay = true)]

void SubmitMessage(MailMessage message);

}

Now we need an implementation for our service. In the code below I only output the message to the console. Normally you'd use tracing or logging for this, but in a bit we'll build a console application to host everything.

public class SendMailService : ISendMail

{

public void SubmitMessage(MailMessage message)

{

Console.WriteLine("To : " + message.ToAddress);

Console.WriteLine("From : " + message.FromAddress);

Console.WriteLine("Subject : " + message.Subject);

Console.WriteLine("Body : " + message.Body);

}

As you can see I'm transferring a MailMessage. Here's the datacontract for it.

[DataContract(Name="MailMessage", Namespace="http://schemas.class-a.nl/msmq/example01/2008/02/")]

public class MailMessage

{

[DataMember(Name="ToAddress", IsRequired=true, Order=1)]

public string ToAddress { get; set; }

[DataMember(Name = "FromAddress", IsRequired = true, Order = 2)]

public string FromAddress { get; set; }

[DataMember(Name = "CCAddress", IsRequired = false, Order = 3)]

public string CCAddress { get; set; }

[DataMember(Name = "BCCAddress", IsRequired = false, Order = 4)]

public string BCCAddress { get; set; }

[DataMember(Name = "Subject", IsRequired = true, Order = 5)]

public string Subject { get; set; }

[DataMember(Name = "Body", IsRequired = true, Order = 6)]

public string Body { get; set; }

}

That's our service, let's get to hosting

3: Create a host

In a next post I will explain hosting this WCF service in a Windows Service. For now, a Console Application will do. It's also much simpler to debug and test our application that way. Add a new Console Application to your solution.

First thing we need to do, is make sure we have a queue. First create a reference to the System.Messaging assembly. Then past the following code in your Main() method.

string queueName = ConfigurationManager.AppSettings["SendMailQueueName"];

if (!MessageQueue.Exists(queueName))

MessageQueue.Create(queueName, true);

As you can see, we're getting the SendMailQueueName from the configuration and if it doesn't exist yet, we'll create it. For the configuration, just download the complete solution.

Now just create a ServiceHost and open it.

Type serviceType = typeof(SendMailService);

using (ServiceHost host = new ServiceHost(serviceType))

{

host.Open();

}

Beside the fact we've checked for existence of the queue using System.Messaging, we did nothing so far concerning MSMQ. The only thing noticeable is setting the operation as a OneWay operation.

4: Setting up the host configuration

Let's have a look at the services configuration. We've configured a single service, based on the SendMailService. It as two endpoints, but one's for exchanging metadata (MEX endpoint). As you can see from the binding and the address of the other endpoint, this is the first time we're specifying that we want to use MSMQ. We're using the NetMsmqBinding and a private queue for our service.

<system.serviceModel>

<endpoint

address="net.msmq://localhost/private/ClassA_SendMail"

binding="netMsmqBinding"

contract="EmailService.ISendMail"

bindingConfiguration="SendMailNetMsmqBinding" />

<endpoint

address="mex"

binding="mexHttpBinding"

contract="IMetadataExchange" />

<host>

</baseAddresses>

</host>

</service>

</services>

</system.serviceModel>

Pay attention to the 'behaviorConfiguration' attribute on the service and my 'SendMailNetMsmqBinding binding configuration'. The behavior configuration isn't interesting, it's just enabling the MEX endpoint to work. The binding configuration for the endpoint is slightly interesting. As you can see below I've set the security to 'None'. That's because my laptop isn't attached to a domain. By default it's on transport security, meaning it'll use Active Directory integration, which won't allow me to connect in my situation. You'll get a nice :

Binding validation failed because the binding's MsmqAuthenticationMode property is set to WindowsDomain but MSMQ is installed with Active Directory integration disabled. The channel factory or service host cannot be opened.

The deadLetterQueue attribute is Windows version specific, because I can only set it to custom on Vista and Windows Server 2008. No need for a custom created queue here, it'll just group the messages in the dead-letter queue, so you'll know they're yours. Read this article on MSDN for more info.

</binding>

</netMsmqBinding>

</bindings>

5: Creating a client

Normally our client is calling the service directly. We can't do that, but we can get the metadata from our service, because we've set up a MEX endpoint. Add a new console application to your solution and create a service reference to the service. You can add a service reference by starting your service WITHOUT debugging. This way the option isn't disabled in your console client.

Now open the proxy code and insert a message!

static void Main(string[] args)

{

SendMailClient svc = new SendMailClient();

MailMessage msg = new MailMessage();

msg.ToAddress = "dennis@nospam.class-a.nl";

msg.FromAddress = "dvdstelt@nospam.gmail.com";

msg.Subject = "Test mail";

msg.Body = "Wow, is this going to work?";

svc.SubmitMessage(msg);

}

Isn't that extremely simple?! The only difference is in the configuration. This proves a lot of what's WCF is in the configuration.

Test MSMQ by stopping the service and just running the client. You can see the message in MSMQ. Start your host and it should disappear almost immediately.

Download the solution for a complete view on what we've done.

Mobile development

Dennis van der Stelt — Wed, 24 Oct 2007 10:13:20 GMT

Two weeks ago Mike Schroepfer, a Mozilla developer, announced that they'll launch a version of Firefox that can be run mobile devices. If you own a Windows Mobile device, you're probably craving for a better browsing experience, just like I am. I've seen Deepfish, a new browser by Microsoft, but it's in early betas.

The interesting part however is that, according to Mike Schroepfer, mobile devices currently outsell computers 20 to 1. I remember Microsoft saying in some article or at some conference that by 2010 a total of 1 billion people will be accessing the internet using mobile devices. These numbers hopefully make you consider if the mobile market is worth investing in, especially being a developer.

At Class-A we're busy with our own mobile development training. We're not using standard Microsoft (MOC) material, but creating our own, so we can incorporate best practices and use .NET Compact Framework 3.5, which Microsoft probably won't have material for, for a long time. This features LINQ and WCF which are great enhancements. I've just blogged about the .NETCF 2.0 application I've been building, and the next step is to build it again in .NETCF 3.5.

If you experience the Compact Framework for the first time, it might be a though start. But once you get it, it's a really fun experience building on an entirely different platform. It's not the C# that's difficult, it's the new challenges like the user interface, different screen resolutions, connections and synchronizing data between your device and the server, performance considerations that are completely different from the full .NET Framework, etc. But when you put some time in it, it's really rewarding to see your application running on a mobile device and having other people enthusiastic about it.

Although LINQ is the 'expected' next evolution in programming, I think people can't even start to wonder what will happen in the mobile world. How it will advance on both hardware and software. Will we keep small screens or walk around with large origami like pc's? What will be possible on your mobile, especially with Silverlight mobile on the way.

The mobile platform is sure something that has my attention and I hope more people will join me. Together we can create a great future.
Wow, does that sound like a dull marketing line! ;-)

Technorati Tags: Windows Mobile, Compact Framework

Class-A Summer Classes become Winter Classes

Dennis van der Stelt — Thu, 04 Oct 2007 07:08:16 GMT

As I really enjoyed giving the Summer Classes a few weeks ago, the first ever real .NET 3.5 class world wide, I'm really pleased to announce the Winter Classes. Although the date hasn't even been set, we're planning it around the end of January or start of February. The classes will be the same as last time

.NET 3.5 Summer Class
Business Intelligence Summer Class

The location to be will again be the Badhotel Domburg. We really enjoyed it there last time with great facilities and a great bar to hang out and reflect on the things learned that day.

We'll redo the subjects from the last time, but update everything for the then expected to be released .NET Framework 3.5, with perhaps some new stuff that'll be released by then. Subjects we covered in our .NET 3.5 class last time are:

Language enhancements in C# 3.0 and VB 9.0
Visual Studio 2008 enhancements
ASP.NET AJAX extensions
LINQ and LINQ to XML
LINQ to SQL
Where does LINQ (and LINQ to SQL) fit in my architecture?
WCF and WF integration
Programming the web with WCF v2
.NET Compact Framework 3.5
Silverlight
Entity Framework
What else is new in .NET 3.5 (for everything we didn't cover yet)

This means a complete coverage of everything new in .NET Framework 3.5. So when you've visited our class, you'll know everything there is to know in a weeks time! And of course with the Class-A labs that make you think about the solution, instead of bothering you with setting colors on buttons and div's! ;-)

We'll also have enough discussion about everything new and you can ask questions just about anything. We'll also prepare a few games so we can have some fun if you enjoy this!

For the Business Intelligence class and more info about the .NET 3.5 class you can visit the Class-A website. It's currently not updated yet for the Winter Class, but it soon will be.

Technorati Tags: WCF, Silverlight, .NET Framework 3.5, .NET Compact Framework 3.5, Mobile Development, LINQ, LINQ to SQL

WCF serving AJAX troubleshooting

Dennis van der Stelt — Tue, 14 Aug 2007 13:15:51 GMT

I hope in the RTM you'll get more help solving your WCF Ajax problems then I currently get, because I'm getting mad from time to time. In my quest for getting things to work, I learned some stuff I wanted to share. Read: have a checklist for myself because I tend to forget this kind of stuff! ;-)

First, have a look at the errors your service reports. Right-click your service's .svc file in Visual Studio 2008 and choose "View in browser".
If you're using the WebScriptServiceHostFactory in your .svc file you don't need anything in your web.config and you can remove the entire <System.ServiceModel> part. This is how the .svc then should look like:
<%@ ServiceHost Language="C#" Debug="true" Service="WebApplication1.WCFAjaxService" CodeBehind="Service.svc.cs" Factory="System.ServiceModel.Activation.WebScriptServiceHostFactory"%>
The default namespace of your service is http://tempuri.org. You need this in your javascript creating your proxy.

var proxy = new tempuri.org.IWCFAjaxService();

When Internet Explorer tells you the object tempuri isn't know, you can take a look at the generated javascript to see what the correct objectname is. By placing /js behind your service you can download the javascript.

Example : http://localhost/service.svc/js
The service can't handle multiple authentication schemes; meaning you can only have anonymous access or integrated security or another option. In IIS Management right-click your website (or virtual directory) and select the "Directory Security" tab, press the first "Edit" button for Authentication and access control and select only one checkbox.
After this you'll have to stop and start the website which can be done by using IISRESET in the command prompt.

When I come across more I will post them here, including an update comment.

Technorati Tags: WCF, .NET 3.5, ASP.NET, ASP.NET AJAX, AJAX

Just to late: WF & WCF beta 2 samples

Dennis van der Stelt — Sat, 11 Aug 2007 17:16:04 GMT

Arrgh, these come out just a day or two too late. But that's life when you're always one step ahead. ;)

WF & WCF samples
http://www.microsoft.com/downloads/details.aspx?familyid=2611a6ff-fd2d-4f5b-a672-c002f1c09ccd&displaylang=en&tm

Silverlight tools for beta 2
http://www.microsoft.com/downloads/details.aspx?familyid=b52aeb39-1f10-49a6-85fc-a0a19cac99af&displaylang=en&tm

Microsoft® Visual Studio 2005 Team Edition for Database Professionals Power Tools
http://www.microsoft.com/downloads/details.aspx?familyid=da3f11ad-bd54-4eda-b08c-4df84df0d641&displaylang=en&tm

Summer Class .NET 3.5, preparation

Dennis van der Stelt — Tue, 07 Aug 2007 21:58:31 GMT

As said before, we're currently on location at the "middle of nowhere", creating material for the upcoming .NET 3.5 Summer Class. We're having a blast, creating slides and hands on labs until way past midnight. I'm busy with the WCF Web stuff, Alex is creating Linq to SQL/XML stuff and Pascal is currently doing Silver (WCF/WF). Yesterday Mike came by to have some fun with us.

Click the images for larger views.

Picture on the left, from left to right are Mike, Alex and Pascal. Second picture is me, Alex and Pascal.

Technorati Tags: WCF, WF, .NET 3.5, SilverLight, Linq

WCF Test Client

Dennis van der Stelt — Tue, 07 Aug 2007 12:48:51 GMT

Two things that should've been there since WCF v1. My colleague Alex Thissen already blogged about the WCF Library projects and the service host that comes with it. In beta 2 there's a new test client that'll connect to your service and will show you the available operations, configuration and allows you to invoke the operations.

When you take a look at the properties of your service library, you'll notice that under the "Debug" tab page, a command line argument has been added: /client:"WcfTestClient.exe". This allows it to start and connect to your service.

After a default installation, this client will crash upon connecting to your service. That's because svcutil.exe isn't signed in Beta 2, as you can read here and here. Unfortunately both bloggers don't tell you where you can find svcutil. You can find it right here:

C:\Program Files\Microsoft SDKs\Windows\v6.0a\bin\

Open the Visual Studio 2008 command prompt, browse to that folder and delay sign it by executing the following command:

sn.exe -Vr svcutil.exe

Now both Service Util and the WCF Test Client work.

Technorati Tags: WCF, .NET 3.5, Visual Studio 2008