The Best Laid Plans ...

Going as Planned?

I got home from a conference in New Orleans early last May, just in time to catch a nasty cold back in Seattle. I became sick right before I was supposed to hop on a plane to sunny Palm Springs to speak at our first ASP.NET and Web Services Solutions conference. Of course, a cold is usually no big deal for me. I've taught five-day training classes with the flu on only a few hours of sleep. The real problem was that the cold had affected my voice; I was losing what little I had left of it really fast.

I arrived Monday more or less in one piece. On Tuesday, I was supposed to conduct an all-day pre-conference workshop, followed on Wednesday by three 75-minute sessions. My basic plan was to ignore the problem and see if I could tough it out; i.e., I had no backup plan. I (or should I say the audience) suffered through my all-day workshop without any major incidents. Thank goodness for microphones. So far, so good. My new plan was to talk as little as possible Tuesday evening - those of you who know me probably realize this is next to impossible - and with a good night's rest, I hoped to be OK in the morning.

Using the Backup Plan

By Wednesday morning, though, things were looking bleak. I couldn't possibly do those sessions. So that's when I came up with a hastily conceived backup plan. Before he knew what was coming, I quickly asked a groggy Doug Seven if he would help me out by presenting the first of my three talks. Luckily for me, Doug hadn't yet had any coffee. He said "yes" before he understood the ramifications of his reply. Doug, of course, did a fabulous job, giving me enough of a break that I was able to get through the two remaining sessions ... and then collapse in a heap at the end of the day.

Developing Plans

So what does this all have to do with ASP.NET development? Well, not everything goes as planned. We've all seen the bumper stickers: Stuff (or something like that) happens. Run-time errors happen, Web Services move. That's why you need to have a backup plan in place - and not a backup plan made at the last minute, like the one I threw together in Palm Springs. You need to plan for the worst from the start. Two recent articles address this important topic. In Handle Errors in ASP.NET Wayne Freeze introduces beginning programmers to exceptions and Visual Basic .NET's new Try...Catch...Finally statement. If you haven't quite gotten the Try...Catch...Finally statement down, check out Wayne's informative column.

And Web Services guru Yasser Shohoud shows us in Keep Web Service Calls Current how to use the Universal Description, Discovery, and Integration (UDDI) invocation pattern to create robust clients that can recover from relocated Web Services. You've probably heard it is possible to use UDDI to dynamically locate a Web Service that moved at run time. But hearing that something is possible is sometimes a long way from understanding how to get it to work for you. In an enlightening yet practical article, Yasser shows us how to create a UDDI invocation pattern so that our Web Service clients can handle a relocated service with ease. Now that's a backup plan!

Paul Litwin is editor and technical director of asp.netPRO magazine. Readers may contact him at [email protected].

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish