Since my career started after graduating college, I have always maintained a job until two Fridays ago. At that point I had a fear that I had never realized before and that was how I was going to support my family. It really did not even hit me till I sat at the dinner table that night with my family. I actually got choked up while observing my kids and wife. I think it hit me that I did not have a job anymore. All of a sudden I realized that I needed to make some quick decisions. Since I had a side company, I decided to setup a quick website and start working on the dream I had always had... working for myself.

I was laid off on a Friday and the next Monday I was able to land my first consulting gig with a team of great people which was a huge boost for my morale. I owe it all to great friends that helped me find the job and others who helped keep my chin up. When some people lose their job, they get so depressed that it is hard to think positive and bounce back. This is the main reason why I decided to write this post, because for a short period of time I thought the same and I wanted to share with others that they can bounce back too. I never thought this would ever happen to me and it did! This tells me it can happen to anyone but the important thing is to understand that this is a tough economy and it is sometimes not anyone's fault, it is just the side affect of the current market. The most important thing is to never let the skills you are good at fade away. Even if you move into a management role, it is important to keep your chops up to date.

One of the main features that stand out about AppFabric is how simple it is to scale. Multiple servers can be added to cache data called the Cache Cluster. The makeup of the cluster however is something important to get familiar with and understand how it works, so certain situations can be avoided or resolved quickly to minimize downtime. Let's start with a quick background of what I refer to as AFC (AppFabric Caching). The need for caching information in today’s architecture is not foreign. Within ASP.Net information can be cached in/out of process or even within SQL server for scalability. One of the shortcomings of some of today’s current caching models is the scalability and high availability. With AFC, formally codenamed Velocity, it is very simple to set this up. Once you have your caching cluster setup, data no longer has to be pulled from the database consistently. Business downtime is not as high when servers go down, which is sure to happen from time to time from either maintenance or other uncontrollable acts of IT nature. These senarios were the main reasons Microsoft decided to come up with AFC. Most architectures look like below and I have had first hand experience in seeing this type of architecture head south quickly.

Instead, AFC can help out by giving your solution the scalability and availability your business solution demands. By monitoring your business solutions activity, decisions can be made on the fly for scaling out how business data should be cached.

To benefit from cache scalability, it is important to understand the different senarios. There are lead hosts that manage the cache cluster. These hosts are designated through configuration and the more cache servers created, the more lead hosts should be designated to manage them. In order for a cluster not to fail, there always needs to be a majority of lead hosts running to manage the cluster. If not, then the cluster goes down. However, the cluster would continue to run even with all four cache servers shutting down.

Now that we have scalability, what about High Availability? High Availability occurs by creating a secondary copy of the data being cached on another server. This is not activated by default and there must be at least 3 servers in the cache cluster(makes sense for needed cache duplication). Because cached data is duplicated, when one of the servers go down, cached data is no longer lost.

When you see these two features of AFC in action, it becomes very clear how much of a difference AFC can make. Microsoft has made just about every aspect of installing and setting up AFC simple. Once you have a basic understanding of how its configured, cache servers can be stood up and setup for high availability very quick. This Saturday, I will be heading to Tampa, Fl., for SQLSaturday, where I will be giving a 1 hour presenation walking others on how to setup and configure caching and also how to build caching clients that can pull data from the cluster. 

Once again I have been awarded Microsoft MVP! Each year I am humbled to receive it because it is a reward based on giving which makes it better each time, because Microsoft is constantly raising the bar on who gets the reward. It is nice to know Microsoft takes note and rewards its community leaders and people who are constantly try to help other IT professionals. This year I have set goals for supporting the Microsoft Community that will top my previous years. I hope every first blog post for coming years can be titled he same:) 

Next month I will be headed out to Tampa's SQLSaturday to give a presentation titled, "Getting Started with AppFabric Caching (Velocity)". AppFabric offers some new features with the support of SQL Server, and as AppFabric starts gaining attention it is equally important that developers and dba developers are aware of how they could be impacted. Below is the description for my presentation.

"Let's face it, reading and writing data with SQL Server can be expensive and has scaling this type of architecture has its implications that need to be considered upfront. This is one of the reasons Microsoft has included caching within its future AppFabric Framework. Caching is not a new methodology because we can use it currently in applications built on top of ASP.Net out of the box, however there are still scaling issues that AppFabric Caching (ACF), formerly Velocity addresses. As database developers, it is important to identify with new trends that may affect database integration and this presentation does just that. First we will learn the basics of AFC, how to install, how to scale, and how data driven solutions can benefit from it."

If you are interested in learning more about AppFabric Caching this session will be a great starting point demonstrating its architecture, down to best practices for caching different types of data... Or if you are not interested, you still can hang out with Andy Warren, however my session has him beat in the 'sexy' category!

While playing with the new AppFabric Caching Beta 1 formally Velocity, I experienced a couple of things that might save you some time. First of all, I am extremely impressed with the concept of what AppFabric caching brings to the table. The concept of caching data and scaling it across multiple machines is powerful concept. Especially when you look at large amounts of data with high traffic or extreme processing. The cool thing with AFC is that everything can be driven though PowerShell commands. This is particularly important when you start thinking of the possibilities of driving caches through new tools like WF4 and the new capabilities it has with PowerShell. This caching model potentially brings a whole new methodology of how we build solutions geared for performance. So let's look at a couple of things that should save you time if you are running into the same issue or plan in the future of playing with the bits. First I will give you a kick start on how to get things started!

Once you get AppFabric Caching installed, the cachehost needs to be started. Below demonstrates the PS commands for viewing that status of the host(s)

Get-cachehost command shows me one host service and notice that it is down by default. I can start it by using the Start-cachehost and specifying a HostName and CachePort. Notice that the Service Status is now UP. Now that your service is up and CacheBaseLibrary.dll and ClientLibrary.dll are referenced and you have your code for pushing/getting from the cache you might run into the same error below upon compiling your solution.

This one had me going around in circles for awhile. First I thought that I had the wrong .Net 4 Framework and after going through my advanced checklist of wasting time, I checked the framework that my project defaulted to and noticed it was pointing to .Net Framework 4 Client Profile which was bad. You want to make sure it is compiling against good ol' .Net Framework 4.

So I am compiling now and ready to cache data. I run my code and get the strangest message I think I have ever received from Microsoft. But not any stranger than I have experienced from other applications

 

If you did not see the PDC09 video, or you did but really did not pay attention to what was being said about the security capabilities, this one sneaks up on you. You need to grant the user permission to hit the cache. Again PS becomes your friend and if you type the command, get-cachehelp you get the following. The important commands for viewing account access are highlighted in yellow.

 

To set access you can call Grant-CacheAllowedClientAccount with the account name like below.

 

Hopefully this post becomes useful to you as you journey down Microsoft's vision for caching data. If nothing else maybe it can start you thinking of the many benefits AFC will be bringing to the table here in the near future.

Just confirmed with the guys in SF that I am speaking at the South Florida Code Camp. Next Febuary, 2010 I will be heading down south to speak on the new WF4 and what to consider for migrating from WF3.x. The last time I have spoken in SF was about 3 years ago and back then I was speaking on WF3. This time I am looking forward to spreading the word on WF4 and catching up with good friends.

When comparing how to handle errors within WF3.x and WF4 you immediately see some significant improvements, not just from a logic perspective but also visually.

 

Some of the pain in WF3.x surfaced from the inconsistent behavior and rooted within the designer, when flipping back and forth from the actual workflow and viewing "Fault Handlers" within embedded activities. WF4 not only improves the look and feel of the designer it also logically makes more sense as to what needs to happen within the workflow/activities, when handling different types of exceptions. Since exceptions are driven from the logic within activities, utilizing the new "TryCatch" Activity becomes very familiar since it mimics how we normally catch exceptions through raw code. Since this post is intended to show off WF4, I will quickly give the foundation for handling exceptions within WF3.x. Fault Handlers are used to handle issues, much like what I am going to show you with WF4's TryCatch, however you will see very shortly that it is not as easy to setup. Once you view the FaultHandler part of the workflow, you add the FaultHandler Activities. Again each handler handles a type of exception.

 

Then you can add a Throw Activity...

 

Now for WF4 this process becomes much easier to implement and makes more sense. 

 

Still there is the same concept that exceptions can be caught at the activity level which means that we can add a TryCatch Activity the same way we added FaultHandlers. The image below shows how activities can be placed within the Try Block of the activity.

 

There are three activities that have been added, first a Sequence Activity and then a WriteLine and custom CodeActivity Activity.  Next we can set the type of Exceptions to catch. By clicking on "Add new catch" a dropdown box gives you the option for selecting the exception type. Once the exception type is selected the next thing to add is a Throw Activity. The Exception Property of the Throw Activity sets the exception to be thrown by the activity

 

In conclusion, it is always important to build in good error handling. Working with WF4 is no "Exception". There were many times I was not sure what the issues were with my workflows in 3.x and I spent many nights banging my head. It seems that identifying errors and handing them is much easier with WF4. If you are used to using WF3.x there is still some things to get used to, and it is sometimes hard to teach a dog new tricks. However most of the changes I have seen are significant improvements, and are well worth the time to understand the change.

Last night we had our final JaxDUG meeting for 2009 and it ended with a fun Microsoft Speaker Idol Contest and a little festive party at the local wing house, sponsored by SNI. We had for speakers compete and selected two with a winner and a runner up. Congratulations to our winner Brian Westover and Ken Koteles. If Brian is unable to attend the regionals competition then Ken gets to compete. Good Luck!

One of the new features you will see in WF4 is the 'Imports' Tab. This tab makes it easier for fully qualifying type names, or should I say, "Not fully qualifying type names". Instead, you can use the import tab and add the namespaces through the Import Designer. The only problem is what happens when you add the wrong one? Simple...well not at first, however one can figure out that since they are added to the xaml, they can be easily removed.

1. Right click on the workflow.xaml file within the Solution Explorer
2. Select "View Code", since you have the file open Visual Studio will ask you if you want to close the existing file so it can be opened up as xml
3. At the very top of the xml, within the main root, "<Activity>" scroll down the name spaces till you see the one or more you would like to remove from the workflow
4. Highlight them and press delete. The cool thing here is if you then view the workflow within the designer it does not go all crazy on you incase you delete one that you still need like it did in 3.x when you messed with the xaml.
5. You should notice that the namespaces are no longer within the Imprt Designer

Happy Days

 

 

Better than the latest movies in theaters now are the videos of what is up Microsofts sleeves. Check it out here.