Javi's technical blog

Using SQL Service Broker in NET applications

2009-03-02T21:52:00.001+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.001+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.000+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.000+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.000+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.007+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.007+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.006+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.005+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.011+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.010+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.005+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.007+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.013+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.036+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!

Welcome to Javi's tech blog!

2008-04-28T19:37:00.000+02:00

So here I am, I've finally decided to have my own technical blog! I've always been very reluctant to start blogging as I’m the kind of tech guy that would rather write code than explain things in a piece of paper or write documentation in general (I'm even very fond of tools like GhostDoc that help you to make the task of commenting code a bit less tough... too lazy I am I must admit, too bad...)

I hope then that having a blog will help me to look at the task of writing documentation and posts in a different way, more as fun and less as a burden, and besides it’ll force me to keep up to date to the latest technologies, so overall it does sound like a good idea, doesn’t it? And, on top of that, if anybody finds my posts useful, that'd be great!!

So as long as I can find some spare time and I have something to say, I’ll be blogging about .NET and related technologies such as ASP.NET, LINQ, WCF, Ajax…

I hope that you'll be around to check wether this experiment works out or not!

Javi