Off-shoring has been a big buzz word for a few years now and there has been a lot of talk around it. While I do believe there are some very bright people in India (I use India only because it is the most common) I really think off-shoring is hurting companies more then helping them. Sure it is cheaper for them and all that but what is the non-financial toll, and how long will it take before these non-financial aspects start rearing their heads as financial consequences?
 
I have worked for an IT shop for awhile that does a fair amount of off-shoring, paying over 200 people in India and other countries to do work. I have talked to people directly involved in these efforts and all they have to share are headaches. I worked on a project where part of the development was given to an Indian firm and they were eventually booted for poor work and an inability to meet deadlines. This is only on the IT front, the bigger aspect is customer service.
 
Many firms have shipped all their phone support offshore. I cannot stand calling phone support any more because most of the time I get some person I can hardly understand. Even if I can understand them, the most help they can give me is reading word for word from a manual. I have ussually already tried what they are read me, and I normally cannot really make out what they are saying anyway. I have to think that eventually this downgrade of customer service will start to financial hurt companies as customers move to other companies that are willing to support them better. Customer service is a very important part of a company in my opinion. I would pick one company over another (and even pay more) if I knew I would get good customer service.

I have been building a few different ASP.net 2.0 application the past few months and the process of deploying 2.0 web apps has become very frustrating to me. If you are coming from the .Net 1.1 world you are use to deploying your web app and having a dll for all you class files compiled with it and deployed. It 2.0 this is no longer the case. The code behind is not pre-compiled. You can pre-comile the code-behind files and then deploy if you want, but it works a little different now. When you pre-compile a 2.0 web application an assembly is created for each page's code behind. In addition to this by default the name of the assembly generated is random (you can add a parameter to the command for fixed names). To deploy a 2.0 web site you have these approaches:

1 - Use the publish web site option with pre-compile
Problem with this is that lots of times you will not have access to the production web server from the box that has Visual Studio installed on it. Plus now if you want to update just one assembly you either have to do a full re-deploy or do a command line compile, move out just the assembly you want to move out, remove the old one (since pre-compile by default creates random assembly names) and then update the inherits page directive to link the aspx or ascx file to the proper code-behind assembly.

2 - Use the publish web site option without pre-compile
This will push out all the aspx and ascx files and the code-behind file (.cs or .vb files). When each page is requested the code is compiled and run. To me this is just not acceptable. I don't see any performance benefit that justifies the security risk of having your source code on your web server.

3 - Use the command line compiler (aspnet_compiler.exe)
While command line compilers have their place, using it as a standard tool to get precompiled web sites is not one of them. Hasn’t the day of having to fire up a command line tool to compile your project long since past? Plus this tool still leaves you with the issue that you have an assembly for each aspx or ascx you have in your project. If you have a large project with lots of these files you have quite a mess to manage.

4 - Use command line compiler and merge tool (aspnet_compiler.exe and aspnet_merge.exe)
Where is the aspnet_merge.exe you ask? Well MS has gotten enough complaints about all these individual assemblies they have released an add on to VS 2005 called "Web Deployment Projects." This adds a new item to your build menu called "Add Web Deployment Project." It also gives you a new tool called aspnet_merge.exe. With aspnet_merge.exe you can merge all the assemblies the compiler creates into one assembly.

5 – Use a Standard Deployment Project (MSI)
The problem with this is that you are left deploying your source code to the production server again since the deployment project will not let you pre-compiling the code-behind files.

6 – Use the Web Deployment project
Add the Web Deployment project to your solution and use its GUI to configure how you want the site to be built. This lets you create assemblies for each page, combine them all or create an assembly for each folder in the project. Plus additional cool things like set up config file replacements for production servers. You then combine this output with a traditional MSI deployment project and you have a full web deployment MSI that does not include source code.

For more information on all this and screenshots and walk through please read this article

Thought this was a nice little piece of code on how you can control a console app in .Net.

using System;

using System.Runtime.InteropServices;

 

namespace HideConsole

{

    /// <summary>

    /// Summary description for Class1.

    /// </summary>

    class ConsoleWindow

    {

        // Import the two Win32 API functions you want to use.

        [DllImport("user32.dll")] public static extern int ShowWindow(int Handle, int showState);

        [DllImport("kernel32.dll")] public static extern int GetConsoleWindow();

 

        // These are the constants as defined by the Win32 API you could just use the value if you want.

        const int SW_SHOWNORMAL = 1;

        const int SW_HIDE = 0;

   

        /// <summary>

        /// The main entry point for the application.

        /// </summary>

        [STAThread]

        static void Main(string[] args)

        {

             // Returns an IntPtr to the Console window.

             int win = GetConsoleWindow();

 

             // Hides the Console window.

            ShowWindow(win, SW_HIDE);

          

            // Put the tread to sleep to simulate processing.

      System.Threading.Thread.Sleep(3000);

 

            // Shows the Console window.

            ShowWindow(win, SW_SHOWNORMAL);

        }

    }

}

Here are some highlights from the Service Broker session

Queues are now database objects
Services broker sets everything as a dialog. Using dialogs it can guarantee delivery, exactly-once delivery, in-order delivery as well as the ability to have long (weeks, years) or short transactions.

A dialogue is either activated via Internal Activation or External Activation. External activation you must build on your own and you should do this if you do not want it running on the same box.
Internal activation can have a sproc tied to the services and the services will fire up the sproc when a message is received. It will fire up a new instance for each message up to a configured min max value.

You can set queues up to only except certain contracts. When the contract is created you can tell it to validate the xml format and even give it a schema

Group locking is the key to the services broken and makes sure that all dialogues are handled by the same reader. Only one queue reader can read from a dialog at a time. Once it starts reading a dialog it locks that dialog so no other process can start reading that dialog messages.

I am very excited about the release of SQL Server 2005. There are a lot of added features to this new version that will make life much nicer for developers. Everyone has heard that you will have the ability to write classes in any CLR language and host those assemblies directly in SQL Server 2005 so I will not talk about that (Although I have concerns about developers using that as their passport to write a bunch of Business logic classes and host them in SQL Server).

CTE (Common Table Expression)

The CTE Functionality of SQL Server 2005 is one area I am very excited about. I have always hated writing recursive queries in SQL Server 2000. I am excited now though with how much easier CTE will make this task. I assume that the select that defines the CTE is only run once with the result set cached in memory. I have been unable to confirm this though.

Pivot

Now this is a great addition!! The Pivot command allows you to do just what you think. You can now pivot your values and make them columns in your result set. This will limit greatly the amount of messaging you have to do on your data to return that data in a column report style layout versus a relational layout.

Apply

Apply is a great concept! You can now join a table with a table-value function or even with a sub-select statement. It is an easy way to do things like join your sales person table with a table that list the top 3 sales for each region of your company.

There are of course many others as well (XML Type, Date Type, Time Type, Service Broker, Enhanced FOR XML) I will save those for another day though. These are the ones I am most pumped about.

Ok so I got a little behind on keeping this blog up day to day. I have been in training 14 to 15 hours a day though give me a break. The last two days were really not much new anyways it was just application of Biztalk in real situations. I did a deployment of biztalk to a farm which was really pretty cool. Deployment and installation through out the farm was not at all straight forward and you really have to pay attention to what you are doing. There are a few steps that if you screw up you pretty much have to start all over. One thing is for sure though, if you are doing configuration of Biztalk on a server make sure you save out all the log and configuration files the install processes gives you a link to open and save off. If you do this rolling back and changing configuration will be much easier. The ability for Biztalk to load balance across servers is very impressive. You can quickly and easily start and stop Biztalk hosts through out the farm to process send ports, receive ports and orchestrations. With only two servers in the farm we were able to process about 200 files in about 15 to 20 seconds.

The ability to build custom pipeline components is pretty cool as well. While I have to admit that I don't totally understand how to do it, the little I did to build one was not all that challenging. The mere fact that you can build a custom pipeline component to drop into your pipeline to do some custom processing of a file for whatever you need to do though is pretty nice.

I think the bottom line with Biztalk is this..... It is very powerful and has some very impressive features that can work well to build out a robust and scalable solution. However, configuration, deployment and performance tuning of the product can be a bare and quite challenging for those that have not been around the product for awhile and know the "ins" and "outs" well. The flexibility of the product via configuration files or the like once deployed is also lacking. You really need an architecture for it that once deployed will not change much if at all. It is possible to make the pipelines, mappings, schema's and orchestration dynamic based on configuration files but it is not a straight forward process. If you keep your rules engine as a separate assembly it is fairly easy to pull your dynamic logic from there and simply redeploy the rules assembly if you need to.

BAM (Business Activity Monitoring) - while this is a decent ability the way it is done is a hack. The fact that you have to use Excel plug-ins to create the reports shows that this ability was an after thought. Why use the BAM.xls instead of having it built into BTT.
Configuration of Biztalk on a new box is anything but straight forward. You have to create about 9 new AD groups and about 9 new AD users. Deployment is dependent on a number of other apps. If you mess anything up during the install it is quite the pain to fix it. There is some clean up that you have to do while installing BizTalk and WSS that I am not totally clear on but the fact that you have to manually go through and uninstall some default things of WSS is pretty lame.

Another long day at the Microsoft offices. I am starting to get a really good feel for the architecture of Biztalk 2004. The scalibility of the app is very impressive. Once you get a good feel for how ports, bindings and enlistings work deployment is not to bad. Don't get me wrong it is not pretty either but not as bad as first impression would make you think.

The Message Bus

The message bus is pretty impressive. It handles all the distribution of messages from the message box which is why the app can scale so well. All you have to do is install a new BizTalk server and start subscribing and the message bus will start getting messages to you.

Adapter Architecture

Biztalk comes with a number of built in adapters that lets you work with SQL server, File directories, HTTP and SMTP it also gives you the ability to build your own adapters for your own custom hookups you may need to do.

Transactions

Biztalk introduces you to a new concept of Long Running Transactions. The concept here is that you can wrap some work in a long running transaction that can last hours, days or even weeks. If a response from a client fails or never comes back you can rollback that transaction and even take compensating steps to correct the action you have taken. Transactions like these do not apply to SQL server and other traditional database transactions.

Correlation

Correlation is a very nice feature in Biztalk that allows you to in the middle of your work process send a message out to something/someone and wait for a response from that process.

This is just some quick pretty simple notes of some of the features. There are a lot of them. Maybe to tomorrow I will be able to write down some info on the Rules Engine and Orchestration.

It is the end of day one of five fourteen hour days learning about BizTalk 2004. I don't care what you are doing that is a long day. BizTalk is an interesting product from Microsoft. While they are still fairly new to this space they have built a very powerful product. The current version of BizTalk though still does have struggle is some areas. Deployment of Biztalk 2004 is a pain. Management of port bindings between different environments is anything but straight forward. Changes in any schema or mapping settings forces you to redeploy and go through all the binding issue again. The other side of this story though is the power that Biztalk offers. The functionality and file manipulation ability it offers is quit impressive. The pipeline capability to encrypt/decrypt, split files, validate and disassemble/assemble is very impressive and would add quit a bit of robustness to file interface processes that I have seen on projects before. It also gives you the capability to create data maps between file formats that provide a lot of built in functiods that allow you to manipulate file formats much easier then creating a DTS package and does it much faster then custom .Net classes could do it.

Four more days to go here in LA. I should have much more to tell in the coming days. Right now though it is late and it has been a long day so I am off to bed.