*Words of Wisdom From The Elder

I’ve been working on a new feature for a Smart Client at work and it was time to push it to beta and have QA go over it.  I was speaking to the QA team member and they were certain they could break the new feature with just a single quote.  The reason this QA team member said this is they test a lot of PHP web apps which are notoriuos for this type of mistake because of magic quotes turned on or off or whatever.  As I explained to them, the Smart Client shouldn’t encounter this when saving or deleting data as ADO.Net does a pretty good job of handling this type of thing.

Later in the evening I got an email from the QA team member with a screen shot where they had created an entry with a single quote in it. O’Connel for example.  At first I thought it was a joke and then I confirmed it by doing it myself.  What happened I wondered?  I’ve never seen this before.  So, I dug into the code. 

In this particular application the screen it occured on was a screen where I had applied a DataView filter to narrow the results of a DataSet.  Here is a simple app I built called “Help Desk” to show you what I am talking about.  Below the menu in the sample you’ll notice I added a TextBox and a Filter button to the ToolStrip.  As you type information into the TextBox it filters the dataset by the First Name column.  Here is how that’s done.

private void toolStripTextBox1_TextChanged(object sender, EventArgs e)
{
   DataView dv = adventureWorksDataSet.Contact.DefaultView;
   dv.RowFilter = “FirstName LIKE ‘%”+ toolStripTextBox1.Text + “%'”;
   this.contactBindingSource.DataSource = dv;
}

The problem the QA team member found was not in the datalayer.  It is pretty simple to see that if you have a single quote in the toolStripTextBox1 object it is going to break the syntax of the RowFilter.  So that’s the problem, now let’s fix it.  I solved it quickly by doing this:

private void toolStripTextBox1_TextChanged(object sender, EventArgs e)
{
   DataView dv = adventureWorksDataSet.Contact.DefaultView;
   dv.RowFilter = “FirstName LIKE ‘%”+ toolStripTextBox1.Text.Replace(“‘”, “””) + “%'”;
   this.contactBindingSource.DataSource = dv;
}

This got me to thinking though, what other situations would this come up.  There may be others where you need to be careful to watch out for this but the only other similar situation was whereby you would do a select on a DataTable to return an array of rows.  For example:

.ContactRow[] rows = adventureWorksDataSet.Contact.Select(“FirstName='” + toolStripTextBox1.Text.Replace(“‘”, “””) + “‘”);

I then started testing all types of other characters in this situation and the single quote is the only thing I came up with that would break it.  I guess in the end we were both right.  I was right in the fact that the datalayer wouldn’t be broken but the QA team memeber did in fact find break it with a single quote.  Note to self.  Self, if you are doing a RowFilter or DataSet Selects with a filter and are getting the input from the user, replace the single quotes.

I’ve attached the sample Help Desk solution to this post for those that want to download and play with it.  All you need is the AdventureWorks database and change the connection string to your own connection string.

A new website launched on MSDN recently for Visual Studio called Servicing.  The site outlines a service pack for VS2003 and VS2005 that will come out in Q3 of 2006.    Here is what the service pack for VS2005 is suppose to include (taken directly from site):

Recently I had to decide which messaging technology I was going to use in an application.  After doing some research on the topic and talking to some fellow developers, it seems others are having the same question I did, which one do you use where.  The answer is of course “it depends”.  Each technology is capable of receiving messages and queing them.  However, they each serve different purposes and one might be overkill over another.

Message Queuing Overview
If you are not familar with messaging in applications that’s OK.  As a developer maybe you’ve never needed to use message queuing in your applications.  More than likely though you have used an application that implemented some type of message queue. The best real world example I can think of where message queues are used would be somewhere like Amazon.Com during Christmas season.  If you have ever placed an order on Amazon.Com you know you do not get an automatic email as soon as you hit the “Place Order” button.  Sometimes an email arrives in 15 minutes, and at other times it may take an 1 hour.   The reason is your order is actually queued up.  When you hit the “Place Order” button a message is sent (probably in XML) to a specific new order queue.  This doesn’t mean that all orders on all web sites are queued up in this similar fashion.  I’ve even written shopping carts that process everything synchronously from start to finish such as:  process credit card, update inventory,  send order to ware house for shipping, email customer, etc.  But for large scale sites message queuing is a must.

There are defineable steps that happen when an order is placed.  If you are a developer and writing a shopping cart, what do you do if you cannot authorize the credit card because the payment processor is down?  Do you tell the customer to come back and try again?  Probably not!  If you stored the order in a message queue, it could simply keep trying to process the order until the payment processor comes back online.  This is a perfect example where messaging in an application can be used.   Let’s not forget congestion on servers either.  In other words if all of sudden your traffic spikes during Christmas rush or because of  a Super Bowl commercial, the more people placing orders, the slower the order process will be if you write things synchronously without message queues.

By sending messages to a queue you do not overload your front-end applications and your backend applications can process the items in a queue as they get to it.  Again, imagine a large ecommerce site that just ran a Super Bowl ad.  People are now placing orders as fast as they can and all of the orders are simply being queued on the backend.  The front-end web site is taking orders as fast as people can enter them.  However, the backend is just taking the next order in the queue and processing it and will continue to do so until the queue empties.  Message queues can be applied to other scenarios as well. 

There are three technologies we can leverage in our .Net applications that support messaging.  Each one serves a different purpose. 

Here is a quick overview of each one:

MSMQ

• Built into Windows and is free
• Primarily recommended for windows to windows applications
• Messages cannot be larger than 4MB in size.  Depending on what type of messages you are queing, this may be a show stopper right there.

Biztalk

• Uses orchestrations to define how a message should be routed
• Great at transforming data from one message to another.
• Built in rules engine
• Hefty learning curve
• Allows system to integrate with other systems

Service Broker

• Provides exactly once, In-order semantics
• Transactional
• Great for data (makes sense since it is apart of the database)
• Built into SQL Server 2005
• Database to database

Recent Service Broker Example
The purpose of this blog post was to get back to my original question, which one do you use where.  Recently I had to tackle this question and ultimately decided the best solution for my application was Service Broker.  It isn’t to say the other two are bad.  Just in this case, I have a really good fit since I am dealing with data.

I have an application that is a Smart Client which uses web services extensively to communicate with the database.  I ran into a situation where I had a very simple message that i needed to send to the web service.  Something like this:

<TransferContacts>
<OriginalOwner>Bob</OriginalOwner>
<NewOwner>Sam</NewOwner>
<TransferType Type=”All” />
</TransferContacts>

This is a very simple XML message.  However, this simple message could mean thousands upon thousands of records in the database have to get updated.  There are audit trails to update, history tracking, etc.  This could obviously take some time to process and I needed to make sure it completed all of the tasks. 

This is where Service Broker comes in.  From the user perspective submitting a transfer request in the application is simple and over at a blink of an eye.  They press a submit transfer request button and the message is sent to the web service and the web service places the message in a transfer request queue within Service Broker.  The user is notified their request has been received and that it will be processed shortly in the user interface.

Service Broker is perfect for this type of message.  As soon as Service Broker sees a message in the queue a stored procedure is called to handle all of the updates.  In my case I used Service Broker because everything is “data driven”.  In other words all the updates are being done in the database.  I am also guaranteed that everything is processed transactionally and in-order. 

Why not MSMQ?
The problem with MSMQ in this case above is that I still have to ultimately call a stored procedure in a database, and make sure everything survives the transaction.  MSMQ could have stored the message perfectly well, but I would be writing more code to process things out of the queue, rather than simply invoking an already written stored procedure.

Why not Biztalk?
In the case against Biztalk, it is just a huge overkill.  I am not transforming data, nor running business rules, nor runnning a long winded orchestration.   If I needed to alert other systems about the transfer, then Biztalk would have been used.  There is a Service Broker Adapter for Biztalk 2006 planned (Jesus Rodriquez mentioned on his blog) so Biztalk and Service Broker can communicate together.

Conclusion
The next time you need to implement message queues in your application be sure you weigh all of the ins and outs of what you are doing before you pick a technology.  You can easily pick by doing this:

Application to Application – MSMQ
System to System – Biztalk
Database to Database – Service Broker

Now of course this may not apply for all of your needs, but it is a good guiding principle to at least start with.  Of course Biztalk can communicate to a database, so it isn’t black and white.  If you have any experience or thoughts on the subject, drop me a line or a comment.

If you have been reading any type of technology news lately you should have stumbled across some Microsoft news recently about Windows Vista, Sparkle, Windows Workflow Foundation, Windows Mobile 5 (Treo 700w), etc. Most all of this news, except the Treo 700, was released during PDC. Or Microsoft week as a lot of writers call it. Two co-workers, Dan and Brad, along with myself got to go to PDC in Los Angeles. Instead of writing about what we did and saw, I put Brad in charge of my camera and had him document the trip. I’ve uploaded all 184 pictures to the site for your viewing pleasure. Here are a few things to help guide you along as you go through the slides:

• We were at the keynote where Bill Gates talked about Windows Vista
• The video with Bill Gates and Napolean Dynamite was hilarious
• You’ll see some eye candy screen shots of the new Windows Vista operating system
• Us playing around in the main vendor room
• Microsoft bought out Universal Studios on Wednesday night so we all went there
• Friday we headed to the beach and ate supper in Malibu!
• I took Brad to Fry’s Electronics (the weird pictures of the aliens and spiders, etc)

Enjoy the pics!

Today was the first day of the Office Developer Convention 2005 in Redmond, Wa. This is the first time Microsoft has put on a convention for developers revolving around their Office products. When most people think of Office they think of three or four basic apps. Usually this includes Word, Excel, Acccess and Powerpoint. There are however a lot more products that round out the Office tools. Other packages include Front Page, InfoPath, One Note, Live Communication, Visio, Outlook, Publisher, Project, and their server counter parts such as Live Communication Server, Sharepoint Portal Server, Content Management Server, and Exchange Server. With this and many other products that make up the total package there is plenty of things to talk about for a conference so let’s get started.