Javi's technical blog

ETags and optimistic concurrency control with WCF Web Apis

2011-06-28T18:45:00.000+02:00

In my previous post I wrote about how to take advantage of ETags to implement HTTP cache validation with WcfWebApis, but this is not the only use of ETags, you can also use them to implement optimistic concurrency control over HTTP. The following workflow illustrates this feature:

The client wants to get a resource and for that it sends a GET request and the server answers with the resource representation and its ETag.
The client decides to update the resource and for that it sends a PUT request with the modified resource representation along with the ETag from the previous step.
The server checks the incoming ETag against the current resource representation ETag from its repository (i.e: Cache, DB).
- If they match, the server carries on with the resource update and returns a 200 HTTP status if it succeeds.
- If they don’t match, it’s because someone else has updated the resource in the meantime. Therefore the server invalidates the request and returns a 402 Precondition Failed status. (Concurrency error)

Now replace “GET” by “SELECT” and “PUT” by “UPDATE… WHERE” and this is exactly the same optimistic concurrency mechanism that you can usually find implemented in relational databases.

Enough of theory, we can implement step 3 from the workflow with a DelegatingChannel. The channel takes advantage of the ETag cache that I used in my previous post.

public class EntityTagConcurrencyChannel : DelegatingChannel{    private readonly ETagCache _eTagCache = ETagCacheProvider.Instance;     public EntityTagConcurrencyChannel(HttpMessageChannel innerChannel)        : base(innerChannel)    {     }     protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request,                                                   CancellationToken cancellationToken)    {        if (request.Method == HttpMethod.Put &&             request.Headers.IfNoneMatch.Any())        {            var etag = request.Headers.IfNoneMatch.First().ToString();            if (etag != "*")            {                var cached = _eTagCache.Get(request.RequestUri.ToString());                return etag != cached                  ? Task.Factory.StartNew(() => CreatePreconditionFailedResponse(),                                                    cancellationToken)                  : base.SendAsync(request, cancellationToken);            }        }        return base.SendAsync(request, cancellationToken);    }     private static HttpResponseMessage CreatePreconditionFailedResponse()    {        return new HttpResponseMessage(HttpStatusCode.PreconditionFailed,                                         "If-None-Match");    }}

As per the HTTP specification, the special wildcard “*” value makes the server not to run the validation.

ETags with WCF Web APIs Preview 4

2011-06-25T19:01:00.001+02:00

Jose Romaniello wrote a very nice blog post about to handle HTTP cache validation with ETags and the WCF Web APIs. For the ETags server implementation there are two different aspects to be considered: the code that checks if a resource has been modified based on the incoming request ETag value (this is handled by a DelegatingChannel in Jose’s implementation), and the part where the resource ETag is added to the response so the client can use this value to make further requests (In Jose’s implementation this is handled on case by case basis in every resource handler). I was interested to see if the second part could be handled in a generic and automated way by using some conventions, so the custom logic in the resource handler could be spared. So let’s get started!

First of all, let’s define the resource.

public class ProductResource

    public int Id { get; set; }

    public string Name { get; set; }

    public float Price { get; set; }

    public string ETag { get; set; }

As in Jose’s post, for the ETag value we can use the DB version field for example. The resource handler goes as follows.

[ServiceContract]public class ProductResourceHandler{    private readonly ProductRepository _productRepository = new ProductRepository();     [WebGet(UriTemplate = "{id}")]    public HttpResponseMessage<ProductResource> Get(int id)    {        var product = _productRepository.Get(id);        return product == null ? new HttpResponseMessage<ProductResource>(HttpStatusCode.NotFound)                                : new HttpResponseMessage<ProductResource>(product);    }     [WebInvoke(UriTemplate = "{id}", Method = "PUT")]    public ProductResource Put(int id, ProductResource product)    {        _productRepository.Save(product);        return product;    }     [WebInvoke(UriTemplate = "{id}", Method = "DELETE")]    public HttpResponseMessage Delete(int id)    {        var product = _productRepository.Get(id);        if (product == null)            return new HttpResponseMessage<ProductResource>(HttpStatusCode.NotFound);        _productRepository.Delete(product);        return new HttpResponseMessage(HttpStatusCode.OK, "Deleted");    }}

The EntityTagResponseHandlerChannel handles the ETag injection to the responses. On top of that, when a PUT or DELETE request succeeds, the channel removes the ETag associated to the incoming url from the cache. This ensures that further GET request won’t get a stale version of the resource.

   1: public class EntityTagResponseHandlerChannel : DelegatingChannel   2: {   3:     private readonly ETagCache _eTagCache = ETagCacheProvider.Instance;   4:     5:     public EntityTagResponseHandlerChannel(HttpMessageChannel innerChannel)   6:         : base(innerChannel)   7:     {   8:     }   9:    10:     protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request,   11:                                                             CancellationToken cancellationToken)  12:     {  13:         return base.SendAsync(request, cancellationToken).ContinueWith(task =>  14:         {  15:             var response = task.Result;  16:             if (response.StatusCode != HttpStatusCode.OK) return response;  17:             var requestMethod = response.RequestMessage.Method;  18:             if (requestMethod == HttpMethod.Put || requestMethod == HttpMethod.Delete)  19:             {  20:                 _eTagCache.Remove(response.RequestMessage.RequestUri.ToString());  21:             }  22:             else if (requestMethod == HttpMethod.Get || requestMethod == HttpMethod.Head)  23:             {  24:                 if (SetETag(response))  25:                 {  26:                     _eTagCache.Add(response.RequestMessage.RequestUri.ToString(),   27:                                     response.Headers.ETag.ToString());  28:                 }  29:             }  30:    31:             return response;  32:         });  33:     }  34:    35:     private static bool SetETag(HttpResponseMessage response)  36:     {  37:         if (response.Headers.ETag != null || response.Content == null)  38:             return false;  39:         dynamic content = response.Content;  40:         response.Headers.ETag = ETagProvider.GetETag(content.ReadAs());  41:         return response.Headers.ETag != null;  42:     }  43: }

Note that we check if the ETag has been previously been set (line 37) meaning that custom ETag handling logic in the resource handler overrides the Channel logic.

The tricky part here is to get the ETag value from the resource associated to the response. The object contained in the response variable is a generic HttpResponseMessage<TResource> that contains the original resource. The problem is that, as the DelegatingChannels are non-generic objects, they can only reference the non-generic versions of the response entities (HttpResponseMessage, ObjectContent base classes) which don’t have access to the original resource object. Since casting to the generic version is out of the question (this Channel should handle any resource type request), we take advantage of a dynamic variable to execute the generic ReadAs method that gives us the original resource entity (line 40).

Finally the ETagProvider retrieves the ETag from the resource object if exists.

   1: static class ETagProvider   2: {   3:     private static readonly ConcurrentDictionary<Type, PropertyInfo> ETagPropertyInfoByType =    4:         new ConcurrentDictionary<Type, PropertyInfo>();   5:     private const string ETagPropertyName = "ETag";   6:     7:     internal static EntityTagHeaderValue GetETag(object resource)   8:     {   9:         if (resource == null) return null;  10:         var resourceType = resource.GetType();  11:         PropertyInfo propertyInfo;  12:         if (!ETagPropertyInfoByType.TryGetValue(resourceType, out propertyInfo))  13:         {  14:             propertyInfo = resourceType.GetProperty(ETagPropertyName);  15:             ETagPropertyInfoByType.AddOrUpdate(resourceType, propertyInfo, (t, p) => p);  16:         }  17:         return GetETag(resource, propertyInfo);  18:     }  19:    20:     private static EntityTagHeaderValue GetETag(object resource, PropertyInfo propertyInfo)  21:     {  22:         return propertyInfo == null ? null  23:                                     : new EntityTagHeaderValue(String.Format(CultureInfo.InvariantCulture,  24:                                                                 "\"{0}\"",  25:                                                                 propertyInfo.GetValue(resource, null)));  26:     }  27: }

The ETag property is retrieved by using Reflection and a dictionary of PropertyInfos by type is used to improve performance.

In closing

HTTP cache expiration could be implemented in a similar way by using for example a .NET attribute defining the resource MaxAge, then a DelegatingChannel would grab this value and add it to the associated response.

Nevertheless, bear in mind that this is by no means production-ready code! My main purpose with this post was to show how the Wcf Web Apis infrastructure can be leveraged to implement HTTP protocol features such as cache validation.

AppFabric Cache: Setting MaxBufferSize in a SQL Sever-based cluster configuration

2011-06-10T17:54:00.001+02:00

The AppFabric Cache limits by default the size of individual items to 8MB. If you've gone over that limit, you have probably got this error already:

ErrorCode<ERRCA0016>:SubStatus<ES0001>:The connection was terminated, possibly due to server or network problems or serialized Object size is greater than MaxBufferSize on server. Result of the request is unknown.

To increase the limit, you can override the default MaxBufferSize value in the cluster XML configuration file.

<advancedProperties>

      <transportProperties maxBufferSize="10000000" />

</advancedProperties>

But what happens if you're using SQL Server as the AppFabric Cache cluster configuration store? If you take a look at the Config DB, you'll quickly realize that the data stored over there looks nothing like the original xml. So how can we change this setting?

PowerShell to the rescue! Use the command below to extract the configuration file that represents your cluster configuration. The command works regardless of the underlying configuration stored being used.

Export-CacheClusterConfig -File c:\config.xml

Do the change in the file, stop the cluster, import the ammended config file and start the cluster again.

Stop-CacheCluster

Import-CacheClusterConfig -File c:\config.xml -Force

Start-CacheCluster

Hope this helps!

Tunnelling PUT and DELETE with WCF Web APIs Preview 4

2011-04-16T18:05:00.001+02:00

PUT and DELETE are first class citizen HTTP methods in REST resource implementations but unfortunately not all clients support these methods and in fact the XHTML4 specification defines GET and POST as the only valid Form methods. Browsers can use Javascript and the XmlHttpRequest to get around this limitation, but other issues such as the fact that some firewalls block PUTs and DELETE requests, recommend having an alternative strategy to convey these methods semantics in the cleanest possible way.

Existing REST frameworks implement a tunnelling technique that solves this issue: clients make POST request and provide the “real” method somewhere in the request. For example, Ruby On Rails uses a hidden form field called _method and users of the Google GData API store the real method in the X-HTTP-Method-Override Custom HTTP header.

Implementing PUT and DELETE tunnelling is a very easy task thanks to the new extensibility point: Message Channels. Message Channels can influence what Resource Method is to be executed by the framework and that’s precisely what we’re going to do:

public class HttpMethodTunnelChannel : DelegatingChannel

    public HttpMethodTunnelChannel(HttpMessageChannel innerChannel)

        : base(innerChannel)

    protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request,

                                                           CancellationToken cancellationToken)

        request.SetOverrideMethodIfAny();

        return base.SendAsync(request, cancellationToken);

SetOverrideMethodIfAny is a custom extension method of HttpResponseMessage.

public static class HttpRequestMessageExtensions{    public static void SetOverrideMethodIfAny(this HttpRequestMessage request)    {        var method = request.GetOverrideMethod();        if (method != null) request.Method = method;    }     public static HttpMethod GetOverrideMethod(this HttpRequestMessage request)    {        var method = HttpUtility.ParseQueryString(request.RequestUri.Query)["_method"];         if (String.IsNullOrEmpty(method))            method = request.Headers                .Where(h => h.Key == "X-HTTP-Method-Override")                .SelectMany(h => h.Value)                .FirstOrDefault();         return MapMethod(method);    }     private static HttpMethod MapMethod(string method)    {        if (String.IsNullOrEmpty(method)) return null;        if (String.Compare(method, HttpMethod.Put.Method, true) == 0)            return HttpMethod.Put;        if (String.Compare(method, HttpMethod.Delete.Method, true) == 0)            return HttpMethod.Delete;        if (String.Compare(method, HttpMethod.Options.Method, true) == 0)            return HttpMethod.Options;        if (String.Compare(method, HttpMethod.Head.Method, true) == 0)            return HttpMethod.Head;        return null;    }}

In the sample, the query string _method takes precedence over the custom HTTP Header. Bear in mind that the code above not only tunnels PUT and DELETE requests, clients could actually do weird things such as tunnelling GETs over POST or the non-recommended practice of tunnelling unsafe operations (i.e. DELETE) over safe requests (i.e.: GET) which could end up with Google deleting your data when it crawls your site!

UPDATE: You can find a more complete implementation here. The idea is that safe methods should not become unsafe when tunnelled and the other way around.

Finally, let’s use the new fluent API to bind our message channel.

public class Global : System.Web.HttpApplication

    protected void Application_Start(object sender, EventArgs e)

        var config = HttpHostConfiguration.Create().

            AddMessageHandlers(typeof(HttpMethodTunnelChannel));

        RouteTable.Routes.MapServiceRoute<ContactResource>("Contact", config);

And that’s it! As you can see, I’ve just scratched the surface of Message Channels and you may have already realized their potential for implementing cross cutting concerns such as logging, exception handling or security for example.

WCF Web APIs: Embrace the Web

2011-04-16T16:20:00.001+02:00

The new WCF Web APIs preview 4 is available and so far I’m very impressed with the quality of the release and the new features. Previous attempts by Microsoft to implement a HTTP/REST framework have been discouraging to say the least, but it seems that the technical debt they went into with the infamous WCF REST Starter Kit is being paid.

The REST Starter Kit library was built on top of a SOAP framework, so it was inevitable that the SOAP details would not leak all over the place. Things like the WCF Message class and its SOAP related stuff, (WS-Addressing headers, tight coupling with XML formats, etc) really get in the way once you want to do something more advanced than the simple Hello World app.

The new WCF Web APIs takes a completely different approach, instead of abstracting the web, it embraces it. Abstractions are good, otherwise we’d still be developing in assembler, but the web is one of the mediums that by only staying as close as possible to the metal you’ll be able to make the most of it.

C# Regions and the Single Responsibility Principle

2011-03-07T18:19:00.000+01:00

I've been doing a few code reviews lately and I think I can formulate these two rules:

If you find yourself needing to use C# Regions with different business terms/concepts in the same class, you've got a very good hint that you're breaking the SRP and that it's time to refactor out.

If you find yourself needing to use C# regions within a method, go take a break!

Actually, if regions weren't part of C#, I don't think they would be missed much.

Securing WCF REST services for smartphone clients

2010-09-24T18:07:00.001+02:00

In one of the projects that I’m working on we have to define the security model for calling REST services (WCF) from smartphone apps (iPhone/iPad, Android). The security requirements are the following:

Both the clients and servers are owned by the same organization so it’s basically the smartphone calling “home”.
The data to be transferred is not sensitive, so we can safely skip confidentiality concerns.
The services are read-only so integrity is ruled out as well.
Even though data is not confidential, users need to be authenticated (so for example we can establish quotas per user).

As REST over HTTP is all about HTTP standards, let’s have a look at what standard methods we can use for authenticating our users

HTTP Basic: The username and password are sent in clear text over the wire, this is not really an option unless you want to use HTTPS as well. As there is no need for confidentiality in our scenario, we’d rather not take the overhead of HTTPS on the smartphone devices which in some cases may be using slow internet connections.
HTTP Digest: The request is signed with a secret shared between the client and the server (password) and a salt (challenge) obtained by the client in a previous request to the server. The shared secret is not sent over the wire (no need for HTTPS), but an extra request is needed to get the challenge from the server .
WSSE Username token: This is an OASIS standard used by the SOAP WS-Security. The ATOM 1.0 protocol design committee, not having the possibility to use HTTP Basic or HTTP Digest, went for this option for providing an authentication mechanism to the ATOM API. Like the Digest method, it uses the shared secret to sign some parts of the message. More info here: http://www.xml.com/pub/a/2003/12/17/dive.html
OAuth 1.0: OAuth is an open standard for authorization delegation: You can authorize 3rd party sites to access, for example, your profile in Facebook or Twitter without having to hand out your credentials to those sites. In our case we don’t need credential delegation but OAuth defines another workflow, known as 2-legged authentication (as opposed to the 3-legged default one) which follows a similar approach of the HTTP Digest and WSSE: the request is signed and verified with the shared secret.

WCF implementation

IIS implements HTTP Basic and HTTP Digest but it's tightly coupled to the company Active Directory, so obviously this is not suitable for Internet scenarios. The WCF REST Starter kit defines some extensibility points that allow to implement custom authentication methods like it’s explained here for HTTP Basic:

http://weblogs.asp.net/cibrax/archive/2009/03/20/custom-basic-authentication-for-restful-services.aspx

I've implemented HTTP Digest and WSSE UsernameToken methods (along with the HTTP Basic sample) by following that same approach. The code is available in github under the name WcfRestAuth. If you don’t use git, you can get the source code here. Any feedback will be welcome!

For OAuth and WCF you can check DevDefined.OAuth

Using soapUI to consume a WS-Addressing service

2010-09-17T18:16:00.000+02:00

soapUI is a handy tool to test web services. You receive a WSDL document of an external service and you can use this tool do some quick testing before actually getting to write some code to consume the service.

If the service implements WS-Addressing you should know that when generating requests, by default soapUI 3.5 will only add the Action header (the SOAP RPC operation name)

<soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">

   <wsa:Action>http://myuri/IHello/SayHello</wsa:Action>

</soapenv:Header>

When you send a request like that to a WCF service, you’ll get an exception like this from the server:

<s:Fault>
         <faultcode>a:DestinationUnreachable</faultcode>
         <faultstring xml:lang="en-US">
                  The message with To '' cannot be processed at the receiver, 
                  due to an AddressFilter mismatch at the EndpointDispatcher.  
                  Check that the sender and receiver's EndpointAddresses agree.
          </faultstring>
</s:Fault>

Indeed there was no “To” header in the request message. We can edit the WS-Address headers in soapUI though: just open the Message Editor window and click on the WS-A tab button at the bottom. You can set values for headers like MessageId or From but just setting the To value by clicking this checkbox will do the trick

Now your request messages will look like this

<soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">
        <wsa:Action>http://myUri/IHello/SayHello</wsa:Action>
        <wsa:To>http://localhost/Hello/HelloWorld.svc</wsa:To>
</soapenv:Header>

Where the To header value is the service URI.

The WCF service won’t complaint anymore about WS-Addressing issues.

Replay detection in a web farm with WCF

2010-09-16T18:51:00.000+02:00

If you are securing web services, replay attacks is one of the things that you should watch out for. Replayed messages can cause duplicate transactions and can be used to create DOS attacks. Note that replay messages don’t necessarily have to come from malicious users; in environments where exactly-once message delivery is not guaranteed, they are actually expected to happen.

The countermeasures to detect these situations are basically these two:

Timestamping: Incoming messages include a timestamp field that is checked by the server against its clock. If the timestamp from the client message differs by a predefined factor from the current server time, then the message is suspicious of being replayed an it’s discarded. With timestamping we can avoid replay attacks that happen over the server replay window maximum value (for example 5 minutes) but what if the hacker manages to replay the message within the window? Nonces to the rescue.
Nonce tracking. Incoming message includes a nonce (randomly generated string by the client). The server keeps track of the nonces arrived within the replay window. When a new message arrives with a timestamp that falls within the valid window, the server checks if the message nonce can be found in its nonce cache and if it does, we have proof that the message has been replayed. In a server farm scenario, all nodes in the farm should share the same nonce cache, otherwise in the worse-case scenario messages could be successfully replayed N-1 times, where N is the number of nodes in the farm.

Note: It goes without saying that both Timestamp and Nonce must be signed otherwise they could (and they would) be tampered.

Now, WCF implements a replay detection mechanism and provides a bunch of configuration options to tune the Timestamping and nonce tracking procedures (i.e: ReplayWindow, ReplayCacheSize for the nonce cache).

However, there doesn’t seem to be any extensibility point for custom nonce cache implementations. Internally (thanks Reflector!), WCF uses the class NonceCache (declared as Internal and Sealed) which is a in-memory cache. If you’re using IIS to host your services, you can imagine what happens to the cache when IIS pool is recycled!

Interestingly enough, the missing hook in WCF was available in WSE 3.0. In you look at that WSE article, you’ll see that for that sample, they used back then a DB table as a nonce cache; today I’d probably go for an AppFabric cache for a better performance and high availability, but this is a different story!

Maybe in WCF 5.0?

I started a thread in the msdn forums regarding this.

Using SQL Service Broker in NET applications

2009-03-02T21:52:00.003+01:00

I've been doing some work with SQL Service Broker lately and I thought I could speak about my experience with it. I was interested in the possibility of using NServiceBus or any other popular implementation of a Enterprise Service Bus in .NET (MassTransit, RhinoServiceBus) with an underlying transport different from Msmq and I thought SQL Service Broker could be a good candidate for the replacement.

This implementation exercise shouldn't be a very complicated task taking into account the great deal of extensibility of a framework like NServiceBus (you just need to implement an interface called ITransport to start using your own transport layer along with the bus), but unfortunately up to this point of time there is no API implementation for Service Broker in .NET framework so things get a bit trickier. Actually, while dealing with the implementation of a custom API for Service Broker I've hit some limitations/design decisions which, in my opinion, make SQL Broker not the best option for the transport layer of an Enterprise Service Bus framework.

Distributed Transactions

I don't want to get into the details about how SQL Service Broker works, but if you have ever used it, you know that messages are retrieved from queues using the TSQL instruction RECEIVE which is a not blocking call but you can combine it with the WAITFOR command for the blocking effect so you avoid polling the queue for dealing with new coming messages. The main problem with WAITFOR instruction is that it sets a transaction savepoint which makes the current transaction not suitable for enlistment; putting it in other words the message handling from the queue cannot be used in the context of a distributed transaction.

So what's the big deal? Actually, I read in msdn forums that SQL broker team wants to discourage the use of distributed transactions because of their performance hit. Besides, you might argue that you can get by without DT keeping all the work related to the message handling in the same database and so there is no need for enlistment. I'm afraid this covers some scenarios but it falls short in others, you have to bear in mind that:

Not every transactional resource is a SQL Server instance, it doesn't even need to be a SQL engine at all
Even if all your transactional resources are SQL Server instance because of scalability you might have to keep queues in a different instance from where your mainstream/business data is.
Regarding security you might have to use different sql user accounts to handle messages and handle application data

For all these scenarios distributed transactions are needed to provide reliable message handling and avoid situations like repeated or lost messages...Can you imagine a bank system where messages that increase/decrease account balance could be handled twice or not handled at all?

There is an alternative provided by SQL Broker that could help to get around this limitation (apart from polling) called External Activation which in few words is sort of a SQL trigger where custom logic can be placed to be executed upon messages arrival to a queue. Then the trick is to use a second queue to store notifications of new coming messages so the consumer application reads and waits from this event queue out of transaction and when a new message arrives it doesn't need to use WAITFOR to go to the main queue to receive the real message within a transaction. I think that this overcomplicates things as you have to handle two queues for what you could do with one and you have to make sure that both queues stay in sync so for example you don't face situations where there are messages outstanding in the main queue and available consumers to handle them but the messages don't get served because the event queue is empty.

Poison messages handling

An aspect that has to be always taken into account while developing a messaging solutions is the poison messages handling and the replayable message strategy. A valid strategy would be that, on the event of error during message handling, retry up to n times and after it goes over the limit the message can be sent to a dead/error message queue.

But what do we do when there is an error while handling the message, for example an external subsystem needed for processing the message is down for some time? A straight forward answer would be to rollback the current transaction so all inconsistent business work would be undone and the current message would come back to the queue so it could be handled again later when maybe the subsystem would come back (you can keep counters at message level for the retries to identify poison messages).

Well this strategy clashes with the way SQL Service Broker deals with poison messages: A queue is disabled upon 5 consecutive times transaction rollbacks when RECEIVE is used... Once the queue is disabled it cannot be used for processing until an user with administrator right enables it back. This automatic poison message detection it's not message bound, it can't be disabled and the number of consecutive times can't even be changed!
To sum up, on one hand we should always try to commit the transaction to avoid this behavior to be triggered but on the other hand we don't want to leave our business data in a inconsistent state, which leads us to split up the transaction in two: one for the message and the other for the business logic; pretty much we are back to square one with the risk of repeated/lost messages...

There are a couple of ways around that behavior though, one of them is another sort of a trigger where custom logic can be placed to be executed upon queue disabled event. The other one is to follow the strategy explained here, which in few words consists of creating a transaction savepoint (bye bye distributed transaction again) before receive is executed and rollback from that transaction savepoint in case of error, so technically the receive statement is not rollbacked.

Wrapping up

Despite the issues above, I think that this has been a good experience as I have got to know better SQL Broker and I've had the chance to dig a bit into NServiceBus internals and understand a bit more how it works under the hood.
The general idea that I get of SQL Broker is that it can be a good solution in an applications where the message handling business logic is included in the database, but for .NET applications I'd rather go for MSMQ queues which, on top of providing an API implementation in .NET framework, don't suffer from the problems that I've talked about.

I'm no expert in SQL Broker though, so if I'm missing something, don't hesitate to say it, I'll appreciate it!

Moving this blog to a custom domain

2009-02-28T09:47:00.002+01:00

I’ve moved this Blogger blog to the custom domain that you can see in your navigation bar, the former blogspot url will keep redirecting to the new domain though.

You may already know that a new domain means a new PageRank, and as I have already noticed in the traffic figures of this site, a poorer PageRank :) (you can read about this subject here).

So my advice is that if you have a blog engine subdomain url (blogger, wordpress, etc) and you are thinking of going for your own custom domain, the sooner the better!

ASP.NET Custom Button Controls Source Code

2009-02-09T20:14:00.001+01:00

I’ve uploaded the source code of the Confirmation Button control here and the Multiple Validation Group Button control here. Besides, for the former I have fixed a bug regarding ASP.NET validation and I have extended the original javascript file to support confirmation popups on html link clicks, and for the latter I have created a separate library project with the custom controls and their associated javascript embedded.

Any feedback will be welcomed!

ASP.NET Multiple Validation Group Button

2009-01-11T21:58:00.001+01:00

In ASP.NET validation controls, the Validation Group allows to break down the set of page validation controls into different units that can be executed independently from each other. Then, a single validation group can be specified at button level so a particular action is glued to a validation controls subset. There are some situations though, where you might be interested in binding a button to multiple validation groups, one of these situations is described in this feedback entry at Microsoft Connect site.

That was back in 2005 when the Validation Group concept was a brand new upcoming feature in .NET 2.0, which by that time was still in beta version. Well, despite the fact that guys from Microsoft seemed to be receptive to the suggestion, it's 2009, ASP.NET is in it 3.5 version and we all know that this feature hasn't quite made it :(. The workaround suggested is to call Page.Validate(group) in server-side but then it means that we'd need to ditch client-side validation which I'm not very happy about.

So let's pick up this suggestion and create a new asp.net button control that includes a coma delimited validation group list property.

public class MultipleValidationGroupButton: Button

  /// <summary>

  /// Gets or sets the validation group list

  /// comma delimited.

  /// </summary>

  /// <value>The validation group list.</value>

  /// <remarks>

  /// Empty string represents validation controls that

  /// don't define validation group property

  /// </remarks>

  public string ValidationGroupList

get

          return ViewState["ValidationGroupList"] as string;

set

          ViewState["ValidationGroupList"] = value;

  protected override void OnPreRender(EventArgs e)

      if (!String.IsNullOrEmpty(this.ValidationGroupList))

          this.CausesValidation = false;

          string script = String.Format("ValidateGroups('{0}','{1}');",

              this.ClientID, this.ValidationGroupList);

          if (Page.IsAsyncPostBack())

              ScriptManager.RegisterStartupScript(Page, typeof(Page), this.ClientID, script, true);

          else

              Page.ClientScript.RegisterStartupScript(typeof(Page), this.ClientID, script, true);

      base.OnPreRender(e);

  /// <summary>

  /// Validates the groups.

  /// </summary>

  public void ValidateGroups()

      if (!String.IsNullOrEmpty(this.ValidationGroupList))

          string[] list = this.ValidationGroupList.Split(',');

          foreach (string item in list)

              Page.Validate(item);

The server side implementation is pretty straightforward: we check if the ValidationGroupList propety has been set and if so we disable the regular ASP.NET validation mechanism (CausesValidation=false) and we register the call to the script that will actually do the job (For the client-side registration I use the Page.IsAsyncPostBack partial method already implemented while creating my jQuery ConfirmationButton). The purpose of ValidateGroups method is to remove the need of hardcoding the validation groups in code behind to enforce server side validation, so instead of doing this:

protected void Button_Click(object sender, EventArgs e)

   Page.Validate("Group1");

   Page.Validate("Group2");

   Page.Validate("Group3");

   if (Page.IsValid)

       //Button Actions

We don’t need to scatter our validation groups in both markup and code-behind because we can do this:

protected void Button_Click(object sender, EventArgs e)

   this.Button.ValidateGroups();

   if (Page.IsValid)

       //Button Actions

And to end with, server-side wise, this is how we define our button in ASP.NET markup language.

<cc:MultipleValidationGroupButton ID="btn" runat="server"
       ValidationGroupList="Group1,Group2" onclick="Button_Click" Text="Click" />

Now it's time to code the javascript function that performs validation on button click. For the implementation, I've used some of the syntactic sugar that jQuery offers but as I'm not using a great deal of things of it you could potentially rewrite this function with plain javascript without much complexity, although I must say that after you start using jQuery (if you haven't yet), you will never want to go back to plain javascript again!

function ValidateGroups(buttonId, validationGroupList) {

    //Bind the logic to the specified button with jQuery

    $("#" + buttonId).click(function(e) {

        var list = validationGroupList.split(',');

        //Loop through the entire set of page validators

        $.each(Page_Validators, function() {

        if ((this.validationGroup && ExistsGroup(list, this.validationGroup))

            ||(!this.validationGroup && ExistsGroup(list, ''))) {

                ValidatorValidate(this, this.validationGroup);

                Page_IsValid = Page_IsValid && this.isvalid;

});

        //Reflect validation in ValidationSummary's if there are any in the page

        $.each(list, function() {

            ValidationSummaryOnSubmit(this);

});

        //If Page_IsValid is false the execution flow will be interrupted

        return Page_IsValid;

});

function ExistsGroup(list, group) {

    var found = false;

    for (i = 0; i < list.length; i++) {

        if (list[i] == group) {

            found = true;

            break;

    return found;

And that’s it, the implementation is ready but before we wrap it up, there are a few things that are worth mentioning: The second clause in the if statement is there to support the scenario where we would potentially want to combine “ungrouped” with “grouped” validation controls and in that situation we’d define our control like this:

<cc:MultipleValidationGroupButton ID="btn" runat="server"
       ValidationGroupList=",Group1" onclick="Button_Click" Text="Click" />

Finally, you may have noticed that I've used extensively the ASP.NET validation client-side API (ValidatorValidate, Page_Validators, etc), if you want to have more details about this API I recommend you using our friend Reflector to get acquainted to this library (System.Web assembly, Resources folder, WebUIValidation.js resource), that helped me a lot.

Hope this helps!

UPDATE: I've uploaded the code for this post here.
I've created a library project with ASP.NET custom controls for Button, ImageButton and LinkButton; the associated javascript code is embedded in that project (apart from jQuery js file).

ASP.NET Confirmation Button using JQuery

2008-12-14T22:19:00.001+01:00

Quite often in business applications the use of confirmation modal popups is required in order to get confirmation from the user of a specific action he’s going to carry out. In web environment the “gorgeous” built-in javascript confirm function is a valid option, but we are living in the XXI century and we can do much better! Particularly with JQuery and the SimpleModal plug-in we can achieve something like this with very little effort:

So, let's get started! First of all we’ll download jQuery js file, SimpleModal js file and css file and add references to them in our master page:

<script src="/Sample/Scripts/jquery-1.2.6.js" type="text/javascript"></script>
<script src="/Sample/Scripts/SimpleModal/jquery.simplemodal.js" type="text/javascript"></script>
<link type='text/css' href='/Sample/Scripts/SimpleModal/css/confirm.css' rel='stylesheet' />

Then we can create the actual html that will be used as modal popup. The html will be reused in any call to the jQuery plugin so we’ll put it in the master page anywhere within the body tag.

<div id='confirm' style='display: none'>

    <div class='header'>

        <asp:Literal ID="ConfirmLiteral" runat="server"

            Text="<%$ Resources:Global, Confirm %>"/>

    </div>

    <p class='message'></p>

    <div class='buttons'>

        <div class='no modalClose'>

            <asp:Literal ID="NoLiteral" runat="server"

                Text="<%$ Resources:Global, No %>"/>

            </div>

            <div class='yes'>

                <asp:Literal ID="YesLiteral" runat="server"

                    Text="<%$ Resources:Global, Yes %>"/>

            </div>

    </div>

</div>

If you don’t need to localize the popup, of course you can get rid of the resources and the Literal controls. Now we can create the javascript function that uses the plugin to show the modal popup.

function confirm(message, callbackYes) {

   $('#confirm').modal({

        close:false,

        overlayId:'confirmModalOverlay',

        containerId:'confirmModalContainer',

        onShow: function (dialog) {

            dialog.data.find('.message').append(message);

            // if the user clicks "yes"

            dialog.data.find('.yes').click(function () {

                // call the callback

                if ($.isFunction(callbackYes)) {

                    callbackYes.apply();

                // close the dialog

                $.modal.close();

});

We already have the means to show the popup but we still need to trigger it on button clicked.

var Page_IsValid = true;

function SetConfirmation(buttonId, message)

    $("#" + buttonId).click(function(e) {

        //We keep the original click event so

        //it can be executed as a callback

        var target = $(e.target);

        //We prevent the form from posting back

        e.preventDefault();

        if(Page_IsValid)

            confirm(message,function() {target.click();});

});

The SimpleModal plugin provides asynchronous and non-blocking functionally (not like the builtin javascript confirm) and that means that we need to prevent the original button’s click event from happening (e.preventDefault();) but at the same time we need to keep it as a callback function to be used in case the user confirms the action to be executed (e.target.click();).

If we you are using ASP.NET validators you might want to show the confirmation pop up only the page is valid (Page_IsValid), there is no point of asking for confirmation if the action cannot be carried out anyways! The variable initialization outside the function guarantees that our function won’t break if there is no ASP.NET validator in the page.

Well, client-side wise we are done, here it goes a usage sample.

SetConfirmation('<%= myButton.ClientID %>','Are you sure of this?');

Let’s focus on server-side now, is there anything we can do? Well, we can create a asp.net control that hides the javascript event subscription to the consumer, so dropping this line in the Page/UserControl markup would be enough to have the confirmation button functionality all in a single place.

<sample:ConfirmButton ID="actionButton" runat="server" Text="<%$ Resources:Global, Action %>"

 OnClick="actionButton_Click" Message="<%$ Resources:Global, ConfirmationMessage %>" />

Here goes the implementation of the ConfirmButton control

public class ConfirmButton : Button

    public string Message

        get;

        set;

    protected override void OnPreRender(EventArgs e)

        base.OnPreRender(e);

        if (!String.IsNullOrEmpty(this.Message))

            string script = String.Format("SetConfirmation('{0}','{1}');", this.ClientID, this.Message);

            if (Page.IsAsyncPostBack())

                ScriptManager.RegisterStartupScript(Page, typeof(Page), this.ClientID, script, true);

            else

                Page.ClientScript.RegisterStartupScript(type, this.ClientID, script , true);

A few things to point out in the implementation: the javascript call is only rendered if a message text has been assigned to the control, which means that we could potentially use the ConfirmButton as our regular button and provide the confirmation message only when needed. The second thing is that we could extract a helper method from the logic in the OnPreRender method, so we could use this helper method to set confirmations programmatically upon any sort of button control (Button, ImageButton, LinkButton). Finally, note that the ScriptManager has to be used to register the javascript in the page when the control is rendered as a part of an UpdatePanel partial postback. The following page extension method is defined to identify those scenarios.

public static class PageExtensions

    public static bool IsAsyncPostBack(this Page page)

        var result = false;

        var scriptManager = ScriptManager.GetCurrent(page);

        if(scriptManager != null)

            result = scriptManager.IsInAsyncPostBack;

        return result;

And that's it, I hope this helps!

UPDATE: You can find the code of this post here

Besides, I've added some code to enable confirmation popup on link click and I've fixed a bug regarding validation.

UPDATE #2:I've updated the javascript code in order to fix an issue that I ran into when using the confirmation buttons with Update Panels (The javascript event handler binder was getting executed on every partial post back which was causing some issues with the popup callback. Check out the implementation for more details, all the changes I did are documented in the js file)

Team Build notification on test failed

2008-12-08T23:41:00.009+01:00

A nice feature in a Continuous Integration environment is the ability to notify developers (or even managers yuk!) when a build breaks. The command Biisubscribe in TFS 2008 allows to hook up email alerts on build completion, for example this is how we can configure email notifications on build failure due to compilation errors:

bissubscribe /eventType BuildCompletionEvent /address myemail@domain.com
/deliveryType EmailPlaintext /server tfsserver1
/filter "TeamProject = 'MyTeamProject' AND CompletionStatus='Failed'“

If you are running tests as a part of the build process though, you might want to take it to the next level and send notifications when any of your tests has failed. Tests are one of the most important pieces of a Continuous integration environment and as such they deserve to be taken in consideration in the notification process :)

In TFS 2008 “Failed” builds are builds that have failed during compilation time while “Partial Succeeded” builds are builds that have gone through the compilation process correctly but have failed in any of the post build actions… such as the test runner! So we have all the info needed to modify the filter from the previous command and get notifications when our tests fail :

bissubscribe /eventType BuildCompletionEvent /address myemail@domain.com
/deliveryType EmailPlaintext /server tfsserver1
/filter "TeamProject = 'MyTeamProject' AND
       (CompletionStatus='Failed' OR CompletionStatus='Partially Succeeded')“

Hope this helps!

Singleton WCF Proxy

2008-09-25T12:23:00.008+02:00

In WCF, creating a proxy is a heavy operation, so if you are experiencing performance slowdown you should definitely look at this area. One of the possible solutions to tackle this problem is to reuse your proxies across your application threads, either implementing a singleton or a pool, but in any case bear in mind that proxy reusability is only advisable in some scenarios (see this and this for the considerations).
Ok, so let's say that we want to go for a singleton proxy and we use Castle as a DI container to handle the proxy instances.
In theory the implementation would be as easy as this


<configuration>
  <components>
      <component id="TestService"
                 service="WCFTest.Contracts.ITestService, WCFTest.Contracts"
                 type="WCFTest.Proxies.TestProxy, WCFTest.Proxies"
                 lifestyle="singleton">
      </component>
  </components>
</configuration>

Where ITestService is the WCF contract and TestProxy is the proxy for that contract... End of the story? Not quite. The problem here arises when for any reason the channel associated to the proxy gets faulted. You probably already know that a faulted proxy can no longer connect to a service and in order to connect again to it there is no option than throwing away the faulted proxy instance and using a new one.
So it seems that the singleton approach doesn't suit our needs; we need to find a way of recreating proxy instances only when a proxy is in faulted state, something like this approach but fit in our DI container. Good news is that Castle gives the possibility to define custom lifestyle managers for our instances; we just need to implement the ILifestyleManager interface (or like in the following code snippet, the abstract class AbstractLifestyleManager) and provide the expected behavior.

/// <summary>
/// Singleton WCF Proxy Lifestyle Manager
/// </summary>
public class SingletonWCFProxyLifestyleManager : AbstractLifestyleManager
{
   #region properties
   private object instance;
   #endregion

   #region overriden methods

   /// <summary>
   /// Resolves the specified instance from the context.
   /// </summary>
   /// <param name="context">The context.</param>
   /// <returns>The resolved object</returns>
   public override object Resolve(Castle.MicroKernel.CreationContext context)
   {
       lock (base.ComponentActivator)
       {
           //If the instance does not exists it is resolved
           if (this.instance == null)
           {
               this.instance = base.Resolve(context);
           }
           else
           {
               ICommunicationObject communicationObject = this.instance as ICommunicationObject;
               //If the proxy is in faulted state, it's aborted and
               //a new proxy is created
               if (communicationObject != null &&
                   communicationObject.State == CommunicationState.Faulted)
               {
                   try
                   {
                       communicationObject.Abort();
                   }
                   catch { }

                   this.instance = base.Resolve(context);
               }
           }
       }
       return this.instance;
   }

   /// <summary>
   /// Releases unmanaged and - optionally - managed resources
   /// </summary>
   public override void Dispose()
   {
       if (this.instance != null)
       {
           base.Release(this.instance);
       }
   }

   /// <summary>
   /// Releases the specified instance.
   /// </summary>
   /// <param name="instance">The instance.</param>
   public override void Release(object instance)
   {

   }
   #endregion
}

Then we need to change the objects configuration file to use our custom implementation.

<configuration>
  <components>
      <component id="TestService"
                 service="WCFTest.Contracts.ITestService, WCFTest.Contracts"
                 type="WCFTest.Proxies.TestProxy, WCFTest.Proxies"
                 lifestyle="custom"
                 customLifestyleType="WCFTest.Common.SingletonWCFProxyLifestyleManager, WCFTest.Common">
      </component>
  </components>
</configuration>

Well, I hope that if you are using Castle to manage singleton WCF proxies, this post will be helpful.

ADO.NET 3.5 certification exam results

2008-07-23T20:37:00.007+02:00

Back in April I blogged about my experience sitting for the new ADO.NET 3.5 exam beta. Well, Microsoft published last week the results for this exam and for ASP.NET 3.5 one too, and I'm glad to say that I passed; here it goes my new logo :)

These exams should be live shortly, so if you are interested in taking them, you might want to check out Gerry's blog for the latest news.
Btw, I highly recommend taking beta exams: they help to keep up to and discover new technologies and they have the advantage of being free of charge!

TFS wish list

2008-07-07T20:05:00.006+02:00

I've been using TFS 2008 for a while, and despite the new good features (easier installation, offline support, better build management, built-in continuous integration, etc), I'm a little bit disappointed to see that some limitations existent in the previous TFS 2005 haven't been solved yet in this new release.
Don't get me wrong; I think that TFS is a great product but, moving forward, this would be my wish list for the following TFS version, codename Rosario.

Server Side Check-in policies
Checkin policies are a very nice feature in TFS; for example you can enforce that before anyone checks a changeset in, he has to associate it with a Work item, or he's had to build the solution and run FxCop, etc... The concept is good, but I don't like the way that it has been implemented: Checkin policies are enforced at client side rather than at server side and this has some bad implications, for example the inconvenience of deploying custom checkin policies.
TFS explorer comes along with some policies but as you may have expected you can create your own custom policies; actually you might want to check the policies that TFS 2008 Power tools provides before creating a new one.
So far so good, the catch is that after getting one way or another your custom policy, in order to enforce it, you have to make sure that everyone in your team deploys it in his workstation or it won't be run when they check in and, on top of that, they will get a nasty policy loading error :( As you can see here, there are people out there that have the same frustration...
I've been focusing in the inconvenience of deployment that this client-side model implies, but what about security? So what if a developer decides to change any of the policies implementation to disable check-in validation?... Well, you might be wondering why somebody would want to do that, but if check-in policies were enforced at server side you wouldn't be wondering.

TFS application tier running in a 64bit box
There is not much to say about this, the header text is self explanatory :)
Even if you go for a non single server deployment where you could use a x64 for the data tier (SQL Server), TFS application tier still needs to be installed in a x32 bit machine.

Branching: carry source history to the branch
As Brendan Lawlor pointed out here, when a branch is created in TFS 2005, its history starts from its creation point of time so the branch doesn't "remember" any of the changes that were made on its source.
This means, for example, that comparing a changeset from the branch against a change made back in time on the head becomes a non straightforward task, especially if you happen to be in a situation where nested branches are required.
Unfortunately, after a simple test in TFS 2008, you will notice that this problem hasn't been solved yet.

TFS event subscription GUI tool
It would be great if TFS came along with a proper GUI tool to handle subscriptions for events remotely, something like this open source tool provides but not only limited to work item events.
Even for something so simple like sending a notification email when a build fails the TFS Project Alerts screen is useless so you have to end up using the bissubscribe command tool, which by the way can only be run locally on the TFS application server.

That was my list; feel free to post your own thoughts and comments about it.

Dependency Injection in WCF Services Part 4

2008-06-08T14:47:00.013+02:00

In the last post of these series, I showed a first approach on how to use Castle Interceptors along with WCF Castle Facility to apply cross-cutting concerns in the Service Layer. The Log sample interceptor that I used for this last post was hopefully enough to get the flavour, but I think that a more compelling sample is needed to demonstrate what these interceptors are really capable of.
I won't leave the Enterprise Library though, but instead of the Logging Application Block I'll use the Validation Application Block for this demo.

Let's take the sample that I've been using in these series and add a Save function in the Customer Service.

namespace DISample.Service
{

  public class CustomerService:ICustomerService
  {
      #region properties
      private ICustomerDataAccess customerDataAccess;
      public ICustomerDataAccess CustomerDataAccess
      {
          get { return customerDataAccess; }
          set { customerDataAccess = value; }
      }
      #endregion

      #region ICustomerService Members
      public Customer GetCustomer(long id)
      {
          return CustomerDataAccess.GetCustomer(id);
      }
      public Customer SaveCustomer(Customer customer)
      {
          return customerDataAccess.SaveCustomer(customer);
      }
      #endregion
  }
}

And the unrealistically simple Customer class goes as follows

namespace DISample.Entity
{
  [DataContract]
  public class Customer
  {
      [DataMember]
      public int CustomerId { get; set; }
      [DataMember]
      public String Name { get; set; }
  }
}

Now we need to meet the requirement that for saving a Customer its Name must be at least 5 characters long and it cannot be longer than 35 characters... The Validation Application Block gets into the game!

The Validation Application Block added value is that it provides a central repository of rules that can be used across the entire application layers so we don't end up coding the same rule in UI, Service, Data Access...

The rules can be defined either in configuration files or through .NET attributes; for this sample I'll use the latter, particularly, the StringLengthValidator through its attribute.

namespace DISample.Entity
{
  [DataContract]
  public class Customer
  {
      [DataMember]
      public int CustomerId { get; set; }
    
      [StringLengthValidator(5, 35)]
      [DataMember]
      public String Name { get; set; }
  }
}

The validator is already declared, but we still need to kick it off. The Enterprise Library provides some API helper methods to instatiate validators so as to fire them, for now we'll put that code in the Service implementation.

  public class CustomerService:ICustomerService
{
    ....
    #region ICustomerService Members
    ......
    public Customer SaveCustomer(Customer customer)
    {
        ValidationResults validation = Validation.ValidateFromAttributes<Customer>(customer);
        if (!validation.IsValid)
            throw new InvalidOperationException();

        return customerDataAccess.SaveCustomer(customer);
    }
    #endregion
}

And the validation requirement is already fulfilled with this code. If we follow this approach though, we would need to produce a similar code snippet for every method in the service and for each parameter that a method receives. In other words, this looks like a situation where an interceptor would be more than welcome :)

Let's remove the validation code from the Save method and create the ValidationInterceptor class.

namespace DISample.Interceptor
{
  public class ValidationInterceptor:IInterceptor
  {
      #region IInterceptor Members

      public void Intercept(IInvocation invocation)
      {
          foreach (object argument in invocation.Arguments)
          {
              if (argument != null)
              {
                  Validator validator = ValidationFactory.CreateValidator(argument.GetType());
                  ValidationResults result = validator.Validate(argument);
                  if (!result.IsValid)
                      throw new InvalidOperationException();
              }
            
          }
      }

      #endregion
  }
}

As easy as it looks; input parameters are available through the Arguments property of the IInvocation interface so we just need to loop through them and use Enterprise Library Helper methods to fire the validators.

You may have noticed that I haven't been very informational throwing an InvalidOperationException with no message; however it would be pretty straightforward to create a custom Exception that will carry the information that the Enterprise Library ValidationResult class provides.

We are almost done, the only thing left is to declare the validation interceptor through Castle configuration file

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<components>
  <component id="CustomerService"
             service="DISample.Service.ICustomerService, DISample.Service"
             type="DISample.Service.CustomerService, DISample.Service">
    <interceptors>
      <interceptor>${ValidationInterceptor}</interceptor>
    </interceptors>
  </component>
  <component id="ValidationInterceptor"
             type="DISample.Interceptor.ValidationInterceptor, DISample.Interceptor"/>

  <component id="CustomerDataAccess"
             service="DISample.DataAccess.ICustomerDataAccess, DISample.DataAccess"
             type="DISample.DataAccess.CustomerDataAccess, DISample.DataAccess">
  </component>
</components>
</configuration>

So before any method of the Customer class gets call, our interceptor will verify the correctness of the input parameters according to the rules defined through the Validation Application Block. No wonder that there is room for many improvements in that code, but the point that I was trying to make is that the task of apply cross cutting concerns gets much simpler using Castle Interceptors and Enterprise Library Application blocks.

Unique Index Schema Information in SQL Server

2008-05-22T22:00:00.011+02:00

Unique indexes along foreign key constraints are used to model One-To-One relationships in Database model design. In fact, when it comes to the DB design, the only difference between a One-To-One relationship and a One-To-Many relationship is that Unique index. For Data Access code generation purposes the existence of the unique index will effectively tell you, for example if you are generating navigation properties, whether to create a simple entity type navigation (One-To-One) or an entity array type navigation (One-To-Many) between the two entities that take part in the data base relationship.

In ADO.NET the GetSchema methods can be used to get Schema information from different Data base provider types; unfortunately for SQL Server Databases unique index information is not provided with that API. Don't panic though, one way or another SQL Server hast to store the unique index information in its catalog tables so after digging into the master database views list for a while, we bump into the table sys_indexes and its is_unique column. An index can be applied upon many columns therefore we'll need to join with sys.index_columns and sys.columns in order to get the column name as well.

SELECT c.[name] as column_name, a.[name] as index_name, is_unique
FROM sys.indexes a INNER JOIN sys.index_columns b
ON a.object_id = b.object_id AND a.index_id = b.index_id
INNER JOIN sys.columns c
ON b.object_id = c.object_id and b.column_id = c.column_id
WHERE a.object_id = OBJECT_ID(N'dbo.yourTable')

Dependency Injection in WCF Services Part 3

2008-05-17T13:15:00.006+02:00

In the first post of these series, I explained the problems you may run into when applying Dependency Injection in your distributed service layer, and in the second one I put the theory in practice using Castle Windsor WCF Facility.

Now that our DI container instantiates our services, we can take advantage of other features not necessarily related to Dependency Injection available in the container. Particularly in this post I'll drift away a bit from dependency injection and I'll focus on the interception capabilities that Castle Windsor framework offers.

Let's take the sample that I've been using for these series and say for example that we want to use Enterprise Library Application Loggin Block so as to log every method execution in our service object.
A simple implementation would be to include the logging call in the service implementation.

namespace DISample.Service
{
   public class CustomerService:ICustomerService
   {
       #region properties
       private ICustomerDataAccess customerDataAccess;
       public ICustomerDataAccess CustomerDataAccess
       {
           get { return customerDataAccess; }
           set { customerDataAccess = value; }
       }
       #endregion
       #region ICustomerService Members
       public Customer GetCustomer(long id)
       {
           Logger.Write("GetCustomer Start");
           Customer customer = CustomerDataAccess.GetCustomer(id);
           Logger.Write("GetCustomer End");
           return customer;
       }
 
       #endregion
   }
}

So we are leaving the logging responsability to the service class itself... That doesn't sound quite right, does it? The service responsability is to interact with the Data Access layer and/or carry out business process but logging is a cross cutting concern that has nothing to do with the actual service implemenation. Besides, for the sake of code cleanignless and reusability, in my Service code I don't want stuff that is not related to the Service main purpose.

Then, how we can possibly achieve logging in our service object leaving the logging calls out of our service implementation? Well, we might use the Decorator pattern for that. This pattern gives the ability to extend the functionality of a class without changing its orginal implementation.
Let's create the CustomerServiceLogginDecorator logging decorator in order to include logging capabilities to our service.

namespace DISample.Service
{
   public class CustomerServiceLoggingDecorator:ICustomerService
   {
       #region properties
       private ICustomerService customerService;
       public ICustomerService CustomerService
       {
           get { return customerService; }
           set { customerService = value; }
       }
       #endregion
       #region ICustomerService Members
       public Customer GetCustomer(long customerId)
       {
           Logger.Write("GetCustomer Start");
           Customer customer = CustomerService.GetCustomer(customerId);
           Logger.Write("GetCustomer End");
           return customer;
       }
       #endregion
   }
}

Notice that the decorator implements the same interface that our service implementation; that's the whole point of the Decorator pattern. The service consumers use the service through its interface (ICustomerService) and it's through the DI container that we specify a particular service implementation for that interface. Therefore, we can create our decorator as a service frontend and inject the actual service implementation into the decorator.

<configuration>
 <components>
   <component id="CustomerService"
              service="DISample.Service.ICustomerService, DISample.Service"
              type="DISample.Service.CustomerServiceLoggingDecorator, DISample.Service">
   </component>
   <component id="CustomerServiceImpl"
              service="DISample.Service.ICustomerService, DISample.Service"
              type="DISample.Service.CustomerService, DISample.Service">
   </component>
   <component id="CustomerDataAccess"
              service="DISample.DataAccess.ICustomerDataAccess, DISample.DataAccess"
              type="DISample.DataAccess.CustomerDataAccess, DISample.DataAccess">
   </component>
 </components>
</configuration>

Notice as well that, since the decorator uses ICustomerService interface as dependency, the underlying implementation of the service remains hidden and therefore we can use the DI container to inject as many ICustomerService decorators as we wish upon the real service implementation. Let's imagine that we want to add an exception decorator...

<configuration>
 <components>
   <component id="CustomerService"
              service="DISample.Service.ICustomerService, DISample.Service"
              type="DISample.Service.CustomerServiceExceptionDecorator, DISample.Service">
   </component>
   <component id="CustomerServiceLogging"
              service="DISample.Service.ICustomerService, DISample.Service"
              type="DISample.Service.CustomerServiceLoggingDecorator, DISample.Service">
   </component>
   <component id="CustomerServiceImpl"
              service="DISample.Service.ICustomerService, DISample.Service"
              type="DISample.Service.CustomerService, DISample.Service">
   </component>
   <component id="CustomerDataAccess"
              service="DISample.DataAccess.ICustomerDataAccess, DISample.DataAccess"
              type="DISample.DataAccess.CustomerDataAccess, DISample.DataAccess">
   </component>
 </components>
</configuration>

Ok, so we got it, there are no longer cross cutting concerns in my service implementation but probably you´ll have already realized that this solution is not the best either. If we carried on with this approach we'd need to create a decorator for each cross cutting concern in each service, it means that we could end up with a number of decorator classes up to (number of Services)*(number of cross cutting concerns) = let´s call this idea off now!

Well, it looks like the Decorator Pattern can be the way but we need something to remove from us the burden of creating for a single aspect a bunch of service specific decorators. Fortunately, castle framework comes to our rescue and offers us the Interceptor functionality which allows to create independent and reusable cross cutting concern implementations.
Let´s create our reusable logging interceptor.

using Castle.Core.Interceptor;
using Microsoft.Practices.EnterpriseLibrary.Logging;

namespace DISample.Interceptor
{
   public class LogginInterceptor:IInterceptor
   {
       #region IInterceptor Members
       public void Intercept(IInvocation invocation)
       {
           Logger.Write(invocation.Method.Name + " Start");
           invocation.Proceed();
           Logger.Write(invocation.Method.Name + " End");
       }
       #endregion
   }
}

And to start using it, we just have to define it in the castle configuration file.

<configuration>
 <components>
   <component id="CustomerService"
              service="DISample.Service.ICustomerService, DISample.Service"
              type="DISample.Service.CustomerService, DISample.Service">
     <interceptors>
       <interceptor>${LoginInterceptor}</interceptor>
     </interceptors>
   </component>
  
   <component id="LoginInterceptor"
              type="DISample.Interceptor.LoginInterceptor, DISample.Interceptor"/>
  
   <component id="CustomerDataAccess"
              service="DISample.DataAccess.ICustomerDataAccess, DISample.DataAccess"
              type="DISample.DataAccess.CustomerDataAccess, DISample.DataAccess">
   </component>
 </components>
</configuration>

That's great, isn't it? We define independent interceptors that can be applied upon any class regardless of its type; Castle will take care of the call flow an interception for us.

To that's it, we have used Castle framework to apply cross cutting concerns in our WCF Service... But that's not what WCF Custom Behaviours are for? Yes, Custom Behaviours get injected in the WCF call stack and in there you can implement some aspects not related to your service implementation like logging, catching, transaction handling, etc. Besides the Enterprise Library 3.1 comes along with a set of Custom Behaviors for WCF that are nothing more that thin wrappers upon the Application Blocks like the Validation Block Custom Behavior. Then, why would we want to build Castle Interceptors if we can use the Enterprise Library WCF custom Behaviors?.

Thinking in terms of the overall application and not only about the service layer, you might decide to apply cross cutting concerns to your web layer, your controller layer, your data access layer, etc. and for that WCF Custom Behaviours have no use. The bottom line is that if you want to use a unique homogeneous mechanish to handle cross cutting concers across all your application layers, WCF Custom Behaviours are not the solution!

Having said that, in the next post of these series I'll show how to implement a more sophisticated Interceptor than the Logging one I explained in this post; Particularly I'll show what it takes to implement an equivalent of the Enterprise Library WCF Validation Custom Behaviour in a Castle Interceptor.

JSON services in ASP.NET Ajax

2008-05-10T12:20:00.008+02:00

Lately the use of client centric development model in .NET is getting increasingly popular. In contrast to the traditional server model where html tags are rendered in server side and then sent to the browser, the client centric approach consist of the use of asynchronous HTTP requests to retrieve data from server side and then do the html rendering in client side code.

The main advantage of this client centric approach is that the communication between the browser and the server gets much lighter; the browser doesn't need to post the page to get information from the server, it rather issues asynchronous calls to Web Services, which implement the JSON protocol, for retrieving the data. You might be wondering why XML-SOAP or other XML based RPC protocols are not used instead of that JSON...

JSON is a non-markup based language which has some limitations comparing to XML languages (i.e: lack of namespaces) but that simplicity makes it lighter, easier to handle by browsers, and overall more performant and more suitable for this web client scenario.

Unfortunately there is a catch :( ; since the rendering is done in client side, you'd better forget about using your automatically rendered ASP.NET controls and be prepared to start messing around extensively with javascript code for the rendering... No need to go through that pain though, there are some third party client based controls that implement rendering through javascript libraries, particularly you might want to check what this open source control library can offer you.

Well, now that we have gone through the theory, how can we put that in practice in ASP.NET? How can we implement and consume a JSON service?
ASP.NET Ajax framework provides some built-in mechanisms to handle JSON communication and serialization automatically.
These mechanisms are Page Methods, Ajax Web Services and Ajax WCF Services and I'm going to spend the rest of this post to do a brief walkthrough on them.

Page methods

A page method is a static function marked as a web method and declared within the page code behind. This function can be called from javascript code through a predefined class/keyword called PageMethods. Let's take a look in a sample step by step.

First the Page method execution has to be enabled in the asp.net ScriptManager.

<asp:ScriptManager ID="scriptManager" runat="server" EnablePageMethods="true" />

Now it's time to implement the static web method in the page's code behind.

public partial class _Default : System.Web.UI.Page
{
   [WebMethod]
   public static String ToUpper(string name)
   {
       return name.ToUpper();
   }
}

Finally, the method is consumed from a script included in the page. As I said before the call execution follows an asynchronous pattern, therefore in the sample below if the operation succeds the resulting string in upper case is passed to the OnSucceded method, otherwise the OnFailed method receives the .NET exception.

function ToUpper(name)
{
   PageMethods.ToUpper(name, OnSuccedeed, OnFailed);
}
function OnSuccedeed(res)
{
   alert(res);
}
function OnFailed(error)
{
   // Alert user to the error.
   alert(error.get_message());
}

Web Services

One of the main differences between Page Methods and Ajax Web Services is that Page Methods can only be used by a single Page and Web Services can be used from as many pages as it’s needed. Needlees to say, both Ajax Web Services and Page Methods use JSON as communication protocol. Let's rework the previous example to use Web Services.

First the HTTP Handler that will serve AJAX Web services requests and responses needs to be included in the web.config file.

<httpHandlers>
<remove verb="*" path="*.asmx"/>
<add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>

Next step is to create a web service, which I'll call StringHandler.asmx. The Web Service's class needs to be marked with the ScriptService attribute and ToUpper web method to be implemented.

namespace JsonServicesSample
{
   [ScriptService]
   public class StringHandler : System.Web.Services.WebService
   {
       [WebMethod]
       public string ToUpper(String input)
       {
           return input.ToUpper();
       }
   }
}

We are getting there, now it's just to include the server through the ScriptManager...

<asp:ScriptManager ID="ScriptManager1" runat="server">
   <Services>
       <asp:ServiceReference
         Path="~/StringHandler.asmx" />
   </Services>
</asp:ScriptManager>

and everything is ready to retrieve data from the client script.

function ToUpper(name)
{
   JsonServicesSample.StringHandler
   .ToUpper(name, OnSuccedeed, OnFailed);
}
function OnSuccedeed(res)
{
   alert(res);
}
function OnFailed(error)
{
   // Alert user to the error.
   alert(error.get_message());
}

WCF Services

The .NET 3.5 framework release came along with some fixes and extensions upon the early WCF .NET 3.0 version; one of those extensions is the webHttpBinding binding which implements JSON serialization and communication protocol.
So for those who use VS2008 and .NET 3.5 let's rework the sample for the last time.

First of all the service implementation has to be changed to include the WCF contract attributes; for the sake of simplicity I won't create a separate interface for the contract, I'd rather apply the contract attributes in the implementation itself.

namespace JsonServicesSample
{
   [ServiceContract
       (Namespace="JsonServices.Contract.Sample")]
   [AspNetCompatibilityRequirements(
           RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
   public class StringHandler : System.Web.Services.WebService
   {
       [OperationContract]
       public string ToUpper(String input)
       {
           return input.ToUpper();
       }
   }
}

On top of the WCF contract attributes, the AspNetCommpatibilityRequirements attribute is provided. That attribute will allow the WCF service to have access to the HTTP context (i.e.: ASP.NET Session variable) and besides, it will tell the runtime to ensure at Service Host creation time that all the enpoints defined for the JSON contract use the Web http binding.
Now it's time to define the service and its endpoint in Web.config file, notice that the AspNetCompatibilityRequirements attribute needs to be defined at the ServiceHost level as well.

<system.serviceModel>
   <behaviors>
       <endpointBehaviors>
           <behavior name="StringHandlerBehavior">
               <enableWebScript/>
           </behavior>
       </endpointBehaviors>
   </behaviors>
   <serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>
   <services>
       <service name="JsonServicesSample.StringHandler">
           <endpoint address=""
                 behaviorConfiguration="StringHandlerBehavior"
                 binding="webHttpBinding"
                 contract="JsonServicesSample.StringHandler"/>
       </service>
   </services>
</system.serviceModel>

Since the service will be deployed in a IIS environment, the StringHandler.svc is created.

<%@ServiceHost
  Service="JsonServicesSample.StringHandler" %>

The server configuration tasks are done, now the service reference needs to be included in the page's Script Manager

<asp:ScriptManager ID="ScriptManager1" runat="server">
   <Services>
       <asp:ServiceReference
         Path="~/StringHandler.svc" />
   </Services>
</asp:ScriptManager>

And everything is ready to start using the service from client side script code.

function ToUpper(name)
{
   JsonServices.Contract.Sample.StringHandler
   .ToUpper(name, OnSuccedeed, OnFailed);
}
function OnSuccedeed(res)
{
   alert(res);
}
function OnFailed(error)
{
   // Alert user to the error.
   alert(error.get_message());
}

You may have already noticed that instead of using the service .NET class namespace (JsonServicesSample) as we did in the Web Services sample, this proxy uses JsonService.Contract.Sample, but what the ** is that? Well if you go back to the StringHandler implementation you'll notice that the ServiceContract defines a namespace...

[ServiceContract
(Namespace="JsonServices.Contract.Sample")]

So the bottom line is that WCF client-side proxys use the contract namespace in contrast with Ajax Web services which use the .NET class namespace instead..
And that's it, our WCF service and client are ready. Before finishing though, it's worth mentioning the WebScriptServiceHostFactory Service Host Factory and how it can help us to remove configuration from Json WCF services.
Comparing to the Web service solution, in WCF sample an additional step was taken in order to define the service and endpoint configuration. If you want to keep it simple and skip that step you can do it using the WebScriptServiceHostFactory Service Host factory. This factory creates ServiceHosts with the default services, endpoints and behaviours suitable for this Json web environment so explicit configuration is no longer needeed
In order to achieve it, if we look at the sample then, the service factory is declared in the .svc file...

<%@ServiceHost
  Service="JsonServicesSample.StringHandler"
  Factory="System.ServiceModel.Activation.WebScriptServiceHostFactory"%>

...so the WCF configuration can be now wiped out from the web.config file.

That's all folks! I hope that if you weren't familiar with this subject this rather long post has given you an idea of what it takes to implement basic Json services in ASP.NET.

Dependency Injection in WCF Services Part 2

2008-05-03T15:49:00.014+02:00

In the first post of these series, I explained the problems you may run into when applying Dependency Injection in your distributed service layer and some of the available solutions to get them around, mainly focusing WCF services. Let's finish off with the theory and put one of those solutions in practice, shall we? In this post I'll rework the sample that I used in my previous post to show the Service Locator pattern in order to use Dependency Injection instead. As in the project that I'm currently working on we are using Castle, I'll use WCF Castle facility to do the service injection.

Let's take then my Service Locator sample

    public class CustomerService:ICustomerService
   {
       #region ICustomerService Members
       public Customer GetCustomer(long id)
       {
           ICustomerDataAccess da;
           da = Global.Container.Resolve<ICustomerDataAccess>();
           return da.GetCustomer(id);
       }

       #endregion
   }

and rework it to use Dependency Injection

    public class CustomerService:ICustomerService
   {
       #region properties
       private ICustomerDataAccess customerDataAccess;
       public ICustomerDataAccess CustomerDataAccess
       {
           get { return customerDataAccess; }
           set { customerDataAccess = value; }
       }
       #endregion
       #region ICustomerService Members
       public Customer GetCustomer(long id)
       {
      
           return CustomerDataAccess.GetCustomer(id);
       }
  
       #endregion
   }

You can notice that with those changes our service class is no longer dependant on the DI container for resolving the CustomerDataAccess implementation like it is in the Service Locator example. Instead, the Data access dependency is a property that can be injected by an external agent, which can be whatever DI container we want to use or even a simple factory... Let's focus on this sample though!

The next step is to create a Castle configuration file called "Objects.xml" where both service and data access objects are defined.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
 <components>
   <component id="CustomerService"
              service="DISample.Service.ICustomerService, DISample.Service"
              type="DISample.Service.CustomerService, DISample.Service">
   </component>
   <component id="CustomerDataAccess"
              service="DISample.DataAccess.ICustomerDataAccess, DISample.DataAccess"
              type="DISample.DataAccess.CustomerDataAccess, DISample.DataAccess">
   </component>
 </components>
</configuration>

As you can see there is no need to connect the DataAccess dependency to the Service object in the configuration file; Castle automatically wires it up.

Now that the Service code is ready for injection and the objects are defined in a configuration file, it's time to use the WCF facility to do the actual service injection.
In order to install the dependency injection behavior, Castle facility uses a a custom WCF ServiceHost. Then, for a non-IIS 6.0 environment and asuming that the service and the endpoint configuration are located in an external configuration file, our WCF host creation would look something like this.

WindsorContainer container = new WindsorContainer("Objects.xml");
Uri uri = new Uri("net.tcp://localhost/DISample");
WindsorServiceHost host = new WindsorServiceHost(container.Kernel, typeof(CustomerService), uri);
host.Open();

We instantiate the Windsor container with our object configuration file so as to be used by the custom service host... and that's all for non-IIS6.0 hosts!

As you may already know, ServiceHost instatiatation model for WCF services host under II6.0 is different: We don't explictly create the ServiceHost; instead ServiceHosts are created by a ServiceHostFactory on each HTTP request.
WCF castle facility provides a custom ServiceHostFactory that can be specified for its use in IIS6 .svc service files. Let's change the default CustomerService.svc accordingly.

<%@ ServiceHost Service="CustomerService"
Factory="Castle.Facilities.WcfIntegration.WindsorServiceHostFactory, Castle.Facilities.WcfIntegration" %>

Where the value of attribute Service must match either the id of our service in Castle configuration file or the service type itself.
Are we missing anything? We haven't created the Windsor Container yet, have we?. Like I said before in II6.0 environments ServiceHosts are created by http request, but would it be wise to apply the same approach for creating the WindsorContainer? I don't think so! Don't panic though, WCF facility has already covered that. Since we are in a web environment, we can use the Global.asax Application_Start event to create our Windsor Container and then register it through an available method in the custom ServiceHostFactory.

    public class Global : System.Web.HttpApplication
   {
       protected void Application_Start(object sender, EventArgs e)
       {
           WindsorContainer container = new WindsorContainer("Objects.xml");
           WindsorServiceHostFactory.RegisterContainer(container.Kernel);
       }
   }

We are done! What's next then? One of the things that I pointed out in the first post of this series is that no AOP features can be applied upon objects that are not handled by the DI container... That's no longer a problem for us!
In the next post of these series I'll show how we can use castle interceptors to apply cross cutting concerns upon service objects.

Dependency Injection in WCF Services

2008-05-01T18:50:00.037+02:00

To use Dependency Injection in a distributed service layer is not a trivial task. Either if you use Web Services or WCF, your services are created by the .NET engine, so somehow you need to find a way to inject your Dependency Injection Container in there.

You might as well let the engine create your service and then use the Service Locator pattern to hook up the underlying layer.
In the following code snippet we use Castle container as a Service Locator to retrieve the Data Access Layer instance that is used from our WCF service.

    public class CustomerService:ICustomerService
   {
       #region ICustomerService Members
       public Customer GetCustomer(long id)
       {
           ICustomerDataAccess da;
           da = Global.Container.Resolve<ICustomerDataAccess>();
           return da.GetCustomer(id);
       }

       #endregion
   }

In the above example, you'll notice that apart from using a slightly different pattern for creating the Data Access object, the service instantiation is not handled by our DI container and this has some bad implications. Some DI containers, such as Castle or Spring.NET, offer AOP features but those features can only be applied upon objects instantiated by the container. So the bottom line is that in this scenario we can't use those AOP frameworks upon our service objects.

So for some scenarios Service Locator pattern could be just alright, but what if we still want to go for a pure Dependency Injection pattern in our service layer? How can we get around the service creation problem?

If you are using Web Services I'm afraid you don't have many options. Comparing to WCF, Web services is not a very configurable technology and the only way to intercept requests is to replace the ASP.NET default HttpHandler with a custom one, which handles the requests/responses and the service object creation. Good news are that if you are using Spring.NET, you don't need to create the handler yourself; there is a custom HttpHandler implementation in the framework that you can use for that purpose.

If you are using WCF in your service layer, congratulations :) WCF is a highly configurable technology and in fact it provides AOP features through the injection of custom behaviors. Using this extensibility Oran gives us the solution to our problem here. As you can read in that post, for creating new service instances WCF uses a factory, which implements IInstanceProvider ... Great news are that we can create a custom behavior that replaces the default IInstanceProvider factory implementation with our own implementation, and in there we can hook up our DI Container.
To cut a long story short, Oran creates an IInstanceProvider implementation that uses Spring.NET container for service objects creation.

If you are not using Spring.NET, don't panic :) there are also implementations available for Castle (created by Ayende) and for ObjectBuilder (created by Pablo M. Cibraro) that follow similar approaches than Oran's. Even if you are using Spring.NET, you might as well use Stan's ammendments to Oran's solution.

To sum up, in this post we have explored some different options to implement Dependency Injection in our Service Layer depending on the distributed technology (WebServices and WCF) and on the DI container (Spring.NET, Castle..) used.

In the next post of these series, I'll put these concepts in practice using the WCF Dependency Injection Castle facility.

ADO.NET 3.5 Certification exam

2008-04-29T19:56:00.001+02:00

A few days ago I sat for the beta exam 70-561 .NET Framework 3.5 ADO.NET. This is the second exam that I've taken for the new .NET 3.5 certifications generation; at the end of last year I took 70-503 WCF's exam and I recently got the results with a happy end for me :)

In 70-561 exam besides traditional topics such as ADO.NET connected data(Commands, DataReaders, etc) and ADO.NET disconnected data (DataSets, DataTables, etc), there is plenty of new stuff that you'd better be familiar with if you want to pass! One of those things is LINQ and LINQ to SQL, which I didn't find particularly difficult maybe cause I've had the chance to work with it.

If you are not familiar with LINQ to SQL, my buddy Sidar came up with a great introduction post and Scott Guthrie has a very nice series of posts that you don't want to miss out.

Another new topic, (at least for me) was Synchronization services. Maybe it's because I've never used it, but questions about Synchronization Services were by far the most difficult for me! You can find here a bunch of demos for the Synchronization framework that you might find useful.

The last but not the least is the Entity Framework which is still in beta... That's one of the disadvantages of taking beta exams, you are sometimes supposed to have knowledge and experience in technologies that haven't been available long enough... I won't complain though, beta exams do have some advantages (Did I mention that they are free?:)) You can find some code samples for EF Beta 3 version in CodePlex.

The beta period for this exam and ASP.NET exam have been extended until the 5th of May, so if you haven't sat for it yet and you want to take it, hurry up and check Gerry's certification blog!