Since my job description was to bring Direct’s software into the fast lane of innovation, we moved closer to becoming a Microsoft shop.  There were some grumbles around the office, but IMHO, Microsoft has ALWAYS provided the best design environment (Visual Studio) mixed with plenty of online documentation (MSDN) and examples (CodePlex).   My predecessor had signed us up for the Microsoft Action Pack  (Microsoft Partners Program) which gave us in-house licenses of nearly every one of their products from Office to Servers.  It only came with 5 licenses of Vista Business and no Windows 7, so we couldn’t test in every environment.   Luckily, our Action Pack subscription was up and we decided to go with the Empower for ISV (Microsoft Partners Program) which is designed for either new businesses or existing businesses who have decided to design their products for Microsoft platforms.  I had to jump through a few hoops to complete enrollment (curse you website requirements!) but it all paid off because an added bonus was 40 hours of support/consultation with MS experts and 5 seats of Visual Studio 2008 Professional AND VS 2010 Beta w/ .NET 4.0.

Microsoft’s .NET technologies first came out right as I was graduating but didn’t catch my eye at that point.  My last shop was using Visual Basic 6.0 with “plans” of moving over to VB.NET.    Upon arrival at Direct Systems, I had free reign  to follow my hearts desire as far as strategies and tools for our system migration.  My vision was to have a fully connected system that was network aware, centrally maintained and able to track the presence of users and services available.  With Windows Communication Foundation (WCF), formerly Indigo, included in all .NET versions since 2.0, I was provided with a structural framework that seemed to fit my needs.

I knew nothing of networking and web services before I started developing with WCF.  I had some good resources, but it was like boot camp trying to wrap my head around some of the different concepts.  The hardest part was deciding on one of the various implementations to be the FRAMEWORK of my new system.  TCP or HTTP or NamedPipes or MSMQ or P2P.  Luckily with WCF it’s easy to implement all of them side by side, but I needed one to be the core.

I had been leaning towards Peer2Peer due to it’s self governing mesh topology and inherent multi-casting.   The main drawback SEEMED to be decentralization.  I wanted to be able to not only monitor but centrally dispatch data and messages to the peers on the mesh.  I decided to move forward and start implementing P2P.  In the process I developed a Logger monitor app and a CentralService service application that maintains the system from the server.

I ran into a stumbling block when I tried to establish a P2P connection from our development Windows Server 2003.  At first I thought it might be firewall settings, but it wasn’t.  Turns out the problem lies in the way the mesh governs itself.  The technology is call Peer Name Resolution Protocol (PNRP) and comes in XP, Vista and Server 2008 under Advanced Networking.  Unfortunately, it didn’t come included in Windows Server 2003!  Microsoft has added the ability to circumvent this and create your own custom resolver that you can self host in a 2003 environment.  This seemed like a headache having to write custom code that an update could have patched.  After some discussion with Bob, I started to implement the custom resolver and had a moment of clarity!  I could just host the resolver inside the CentralService.  The act of looking for the custom resolver was a way for the peer node to make contact with my service and start sharing information.

So in the end, what seemed like a weakness was actually my biggest asset!

Facebook

Facebook

By utilizing the FILESTREAM attribute of the varbinary(MAX)  data type in Microsoft SQL Server 2008 (any edition) we are actually storing the binary file information directly to an NTFS store configured on the same machine as the SQL Server instance.  Studies have shown that data under 256k is better stored and accessed through the SQL Server API in a varbinary(MAX) field and that blob data larger than 1MB performs better when streamed from an NTFS store.  FILESTREAM allows you to access your larger files more efficiently  so it doesn’t have to eat up the buffer in your database and cause massive slowdowns.  The system doesn’t work well with numerous read/writes because it completely replaces the blob data each time, leading to data fragmentation.  Luckily most of our correspondence is set it and forget it.

Here is the  initial list of supported file formats:

• Plain text files (.txt)**
• Rich text files (.rtf)**
• Adobe Acrobat (.pdf)*
• All image files (.jpg/.jpeg/.bmp/.gif/.png/.tif)*
• MS Office Excel (.xls / .xlsx)
• MS Office Word (.doc/.docx)

* Viewable from within the application
** Editable and viewable from with the application

It will feature:

• drag and drop storage or viewing of documents/images/text from the file system or the clipboard
• variable replacement based on database values or business logic
• multiple points of integration: depending on the command line, the file cabinet will be specific to a user, shipment, or account
• assignment of viewing/editing rights to other users

Our previous version of this product was the “Correspondence Manager” which stored paths to file locations but still offered variable replacement and rich text editing.

Facebook

Speaking of the “new software”, we are at a pivotal point in the development process.  One of our main focuses is the migration from a file-based TopSpeed DB to Microsoft SQL Server.  The goal is more reliability and scalability.  While Bob is off somewhere sipping on bahama mamas and NOT thinking about Direct Systems, he has tasked me with setting up a fresh instance of MS SQL Server 2008 Express Edition on our newly re-purposed file server turned development server.  There are many prerequisites like the annoying Web Platform Installer (PI) and .NET 3.5 SP1 among a laundry list of others. The key here is merging our two databases together.  Until now, Bob and I have been working off of essentially the same data hosted on our individual computers.  It’s time to join forces and show everyone how well our two systems work together.  I’ll go into more detail in another post.

For now, just know that the install is complete and the .sql files have all been processed.  And I can rest easy tonight, just like Bob probably is…

Facebook