Aaron Stebner has some tips if your service pack setup is failing.

Chris Lyon outlines what does and does not happen when you call Dispose.

Years ago, I helped put two large systems together. We were C++, they were Java. We were Microsoft based, they were Unix based. We were an Internet startup approaching the bursting bubble, they were a Fortune 50 company in the midst of a refinancing boom. During the initial integration we used beta 1 of the Microsoft SOAP Toolkit 2.0 (released in December of 2000). They used the Apache SOAP 2.1 toolkit (pre-AXIS), which I believe the Apache team released in February of 2001.

The toolkits worked. We moved a tremendous amount of information about mortgages back and forth. Of course, there were some hitches here and there, but nothing we couldn’t figure out after a quick search of soap-user. It was simple – just so plain and simple.

Because of this experience, I have great deal of reservations over all of these WS specifications. I believe if I were to approach that same project today, the experience would involve considerably more pain. Someone would want to use a WS toolkit here and there, and we’d be buried just trying to pass an XML fragment back and forth. It is going to take at least 3 to 5 years to shake out everybody’s interpretation and implementation of the specs to reach a plateau of interoperability, as well as revisions and fine-tuning to the specs themselves. You might say I am a member of the loyal opposition.

Do we need more standards? Yes. Do we need them now? Yes. Amazon could use them. Ted says the WS stacks are overkill for Amazon, but even though they may do millions of web service transactions, these are transactions in the loose sense of the word, not transactions in the cash flow sense of the word, just ask Carl. Everyone seems to agree the specifications are bulky and opaque. What company would offer web services for the masses based on specifications the tool vendors can’t keep up with?

After four years of web service hype, simple is still the only approach that works for everyone. It's going to be a long, slow road. It will give everyone time to mix in practical experience with the thoery of specifications.

A source entrusted me with the following paper she found at a Starbucks this summer. The hand written notes are proof of a hidden agenda lurking in the world of SOA.

I’m trying to get this to Dan Rather, but he is not returning my phone calls.

As you read this there is a team of 850 people in India writing software in .NET for the healthcare industry. The company, iSoft, already has a 60% market share in the UK, and a 70% market share in Australia. They plan to target the US market in 2006.

Building enterprise scale health care software is a massive effort. Not only do they need  the general business functionality of inventory, accounting, and payroll, but there are  specialized needs in every corner of the hospital: nursing, radiology, pathology, microbiology, blood bank, admissions, pharmacy, and patient care records, just to name a few. Every one of these areas has specific needs to addresses with software.

I’ll take a wild guess and say that by 2006 this team will have 500 developer-years of work in the project. I know some other established companies in the US market. I’ll make another guess and say they have 5,000 developer-years of work invested in their solutions - but there is a huge difference.

The companies I know work in C++, and they work from scratch. They write their own hardware abstraction layers, their own device drivers, and their own proprietary database formats. It’s easy to burn 5,000 developer-years building software this way, and here is the end result: They give thier customers a custom report building application that requires instructions like the following:

VAL=IF{@account^/R.SEG.TAP %Z.rw.segment("ACT.TAP.cust.first.statement.date.
VAL=",@.db)},/R.SEG.VAL["FIRST"]

That's not from legacy software, that's from the most recent shipping version. It sure keeps the consultants and trainers busy.

On the other hand, if someone builds the software using .NET, an off the shelf relational database engine, third party reporting tools, and lets the a commercial operating system take care of, well, operating the system, they can catch up pretty quickly. At least in theory. It will be interesting to see how far they go by 2010.

Scott Stewart describes a sneaky problem caused by a limit in the size of the UserData property.

Steve Muench has an inside scoop on SP1 for Virtual PC, and why you'll need it with XP SP2.