I started working at BuyNothing.com in September of 1998. My first assignment was to enable the existing software with asynchronous messaging functionality. BuyNothing.com was a Microsoft shop, at least within its Houston operations, and so it was decided that MSMQ would be the messaging technology of choice. The idea was that the Houston operation would maintain a centralized database of rationalization rules (pattern matching) and the software that utilized them.
The combination of rules and software would be leased to our customers on a per line item transaction basis. In other words, they would get to use our stuff to cleanup their data, and they would pay us for every line item cleaned. The continuous bi-directional flow of rationalization rules and all the accounting would be handled over the Net.
Technically speaking, the idea sounded more than a little wacky. But hey, when you are the new kid on the block, you don’t start making noise right away. MSMQ 1.0’s API turned out to be fairly robust, but the message management tools and utilities were almost nonexistent. You could definitely create message queues, send and receive messages, and track them (most of the time). However, when messages got lost, or appeared as though they had not been sent, it was difficult to determine exactly what had gone wrong. This was frustrating, but somewhat expected for a 1.0 product.
I convinced my boss, the acquaintance that had recruited me (who was the V.P. of Technology) that we needed to log all in-bound and out-bound messages so that when things went wrong, we could recover by resending. This was not a stroke of genius on my part. The EDI system that my team built for Big Oil Company was built on top of asynchronous messaging technology, and it was a requirement to have full logging and resend capabilities. Convincing my boss that this was a requirement took some doing. I was surprised just how hard he pushed back. After finally convincing him, the procedure later saved both of our asses on more then a few occasions. I was more than justly vindicated.
The V.P. of Marketing had convinced one of his contacts at GorillaB2B.com that this pattern matching technology was the shit, and they agreed to beta test it. A couple of us spent a week on the west coast getting them up and running. With some trials and tribulations, we managed to get the MSMQ messaging stuff to work using a VPN across the net. The actual “product” itself was a completely different story. It had no user’s manual, was buggy, was terribly slow, and was difficult as hell to use. The developer that accompanied me spent a significant amount of time teaching these folks how the Houston operations team used “backed doors” around the software to increase productivity. Needless to say, GorillaB2B.com did not become one of our largest or happiest customers.
Meanwhile, back at the ranch, it seems that I had created a monster. The current incarnation of the software used a Visual Basic DCOM server and an MS Access database to provide multi-user functionality to clients across the network. The problem was that the VB based server was single threaded. As such, it could not support more than three simultaneous users, let alone the 15-20 that we were staffing up for. I had been on the job less than a week when I started recommending that we convert to SQL Server and “fix” the single threaded VB server problem. However, I was soon diverted to do the MSMQ work, and I decided it was best to fight one battle at a time. After the failed beta at GorillaB2B.com, we had egg on our face, to be sure. But we had also proved that the asynchronous messaging technology was viable (more or less).