Thunderclap, the Newsletter of Rolling Thunder
Computing
Volume 6, Number 2, Winter 2004
In this issue:
Feature Article: Shopping for Web Services,
and the Fallacy of UDDI
Blatant Self-Promotion: I'm a legend in my own mind, New in-house class on Web Services
New Book: The Microsoft Platform Ahead, due out May 2004
A Good Read: Winterdance, the Fine Madness of Running the Iditarod, by Gary Paulsen
If you’re writing a commercial web service, you want potential
clients who might be interested in it to be able to find you. If you’re writing
a client application that needs functionality that a web service could
provide, you want to be able to find a web service that provides it.
As far as I can tell, and as far as any of my customers tell me that they
can tell, finding a web service that does what you need done, with the
level of quality that you need it to have, at a price you can afford, is a
shopping problem similar to any other shopping problem. And you solve it
the same way you solve any other shopping problem. You ask people you
know, you search with Google or another search engine, or both. You winnow
the candidates, examine a short list in more detail, and make a choice. If
you’re a provider, you put up a good web site and buy a Google ad based on
keywords.
For example, I was working on a sample program for my latest book (see
below for more about it), and I
needed a web service the would take a telephone number and give me
the street address of the phone. I searched Google for “reverse phone” and
“web service”. I found a great number of entries that used the term “web
service” to mean anything useful that happened on the Web, not in the
stricter “cross-platform function call using HTTP and SOAP” sense that
I had in mind. Adding the term "SOAP" or "WSDL" to the search
string filtered these out. I found two potential candidates, one at MCI.com and one at
ServiceObjects.com. The latter was easy to understand
and use, with sample code and a free trial, the former wasn’t (so much so
that I won't provide a link to them), so I tried
the latter first. So far I’m happy with it. Problem solved. Their site
looks like this:
“But wait!” I hear you yell. “Isn’t that what UDDI is supposed to be for?”
An awful lot of noise gets made about UDDI (www.uddi.org), which stands
for Universal Data Discovery and Integration. The idea is to have a
centralized repository where providers of web services can register their
offerings so that potential consumers can find them. The web service
descriptions were to be organized in categories, so users can browse for a
particular functionality. The UDDI standard defines a set of SOAP methods
whereby developers can place their information in the database and clients
can read from it. Unfortunately, it doesn’t work well today.
Microsoft, IBM, and several other vendors each run a separate
implementation of the UDDI database. Data entered into one of them is
supposed to be propagated to all of them in under a day. You can see a
screen shot of Microsoft’s entry,
uddi.microsoft.com, below:
I found it quite difficult to use, and never did manage to find a web
service to solve my problem. There’s no place to search for
keywords, such as “phone number”. I stumbled upon the ServiceObjects.com
entry here, but only because it had “phone” in its name, and a wildcard
name search found it. They list categorization schemes and tModels. Have
you ever heard of these things? Is there a reason why we should have to in
order to find a web service we need? Google doesn't require this. What
additional benefits would I reap from investing the time to figure them
out? None that I can see. When a user interface fails so miserably, it's
inevitably because the designers have exposed their internal
implementation model and not taken into account the user's mental model.
And so it proves here.
It’s frustrating to see a potentially useful idea implemented so badly. The site’s FAQ states: “In general, UDDI can locate businesses whose identity you know already so that you can find out what services they are offering and how to interface with them electronically.” That's not what we need to know. We need to know which vendors provide the types of service we want. Knowing how to talk to someone once we've identified the right someone can be made a trivial process if the service publisher gives it ten minutes thought.. Look at ServiceObjects.com. They have a link to the WSDL file, another one to a page describing the cost of the service and an easy way to get a 30-day free trial, and yet another to sample code in many language showing how to connect to and use their service. It took me literally less than 10 minutes to get my sample up and running. I can't, off the top of my head, think of any way they could improve on their communication with potential users.
UDDI solves, or attempts to solve, the wrong problem. The developers have forgotten who their users are. Remember: KNOW THY USER, FOR HE IS NOT THEE! (where have I heard that before? Don't get me started.) The user of a service for locating web services is an application programmer or architect usually with a specific type of service in mind. He wants to get this job done ASAP. Whoever makes it easier will get the business. And so far, Google blows the doors off UDDI.
I occasionally hear UDDI described as being as fundamental to web services
as SOAP and WSDL. Nonsense. Balderdash. Rubbish. Idoicy [sic]. You use SOAP on every web service
call. If it disappeared tomorrow, every web service everywhere would stop
working immediately. You use WSDL every time you create a proxy for a web service.
If it disappeared tomorrow, generating a client-side proxy for consuming a
web service would become much more difficult. If UDDI vanished from the
earth tomorrow, very few people would notice and even fewer would care.
Not me. Not any of my clients, at least not that they’ve told me about.
And probably not you either. Google does it better. The UDDI emperor has no
clothes. You heard it here first.
I invite any of my readers to respond with that, if anything, you're doing
with UDDI, and might publish the response, on
the following condition: that you have actually used UDDI to solve the
problem of getting customers for your production web service or locating
services for a production client application. Not, "But with UDDI you can
X ..." Only "With UDDI my team actually did X in such-and-such a
production situation, and found it more useful than Google because of Y."
Unless you've actually fired UDDI in anger at a target that you needed to
kill in order to eat, save your bytes. So far, the only thing I've ever
seen is a few guys who said, "Well, we registered with UDDI because it was
there. We figured it couldn't hurt, but we never got anything from it."
We'll continue our discussion of .NET and Web Services in the next issue. Give me a call if I can help you out. Until next time, as Red Green would say, "Keep your stick on the ice."
Blatant Self Promotion: Would you buy a used car from this guy?
Public Class on Web Services in Iceland
See You at Tech-Ed San Diego and Amsterdam,
and the ACORD Technology Conference in Las Vegas
New In-House Class on Web Service Enhancements
I'll
be teaching a three-day public class on Web Services in Iceland this May
3-5. Information is online at
http://www.endurmenntun.hi.is/hugb_flokk.asp?ID=191V04
Recognize me? Microsoft is running a new promotion featuring me and a few of their other top independent consultants, calling us "Software Legends." We're doing bookstore events and other promotions, such as events at Tech Ed and PDC. Part of the promotion involved a professional photo shoot in Redmond. I'm astounded that the skill of the photographer, Karen Moskowitz of Seattle (www.moskowitz.com), actually managed to make me look good. I've got posters available, suitable for framing or wrapping fish, and I'll mail you one if you promise to display it. Send me a photo of it on your wall (ideally without darts in it), and the best will win a prize. Here's what I'm up to:
NEW! 5-day In-House Training Class on Web Services
The main article in this newsletter describes Microsoft's new extensions to XML Web Services that actually make them useful for something besides saying, "Hello, World." They security pieces, in particular, are well thought out. Web Services are now sophisticated enough to warrant a topic in themselves, so I've written a 5-day class to do just that. It uses Microsoft's WSE version 2.0. See the syllabus online here, then call me to schedule yours.
5-day In-House Training Class on .NET or .NET for Insurance
.NET is here, and it's hot. It changes everything in the software business, and you can't afford to be without it. Rolling Thunder Computing now offers in-house training classes on .NET, using my book as the text. I've split it up into customized offerings, such as .NET for Existing 3-tier Microsoft Programmers, .NET Framework Serious Geekery, .NET Web Programming, and .NET for the Insurance Industry. See the syllabi online here, then call to schedule yours.
ACORD XML for Insurance In Depth
Insurance carriers, learn ACORD XML from David Platt. This 5-day class will give you everything you need to know to jump-start your application development. Learn about security and plug-and-play. See the syllabus online here. It can be customized to your needs.
New Book: The Microsoft Platform Ahead
To be Published in May 2004 by Microsoft Press
Like idiots, Microsoft asked me to keep on updating my .NET book, and like a bigger idiot, I agreed. I'm working on the fourth edition (Whidbey beta) and fifth (Whidbey RTM). Watch this space for time and content announcements.
It isn't really another edition of my Introducing Microsoft .NET. Instead, it takes the same high-level approach to the emerging technologies now shaping the .NET computing world and talks only about what's new. We're still arguing over what tool will be on the cover; they won't let me have a chain saw or a flamethrower. But the chapter list currently is:
Chapter 1: Introduction
Chapter 2: .NET Framework v2.0
Chapter 3: ASP.NET version 2.0
Chapter 4: Web Service Enhancements, version 2.0
Chapter 5: Compact Framework, Smartphone, and MapPoint Web Service
Chapter 6: Contradiction [sic]
Look for it at bookstores around May. We hope to have it out for Tech Ed in San Diego.
The Iditarod Sled Dog Race is on now (www.iditarod.com). I think it's the toughest on the planet, 1100 miles alone with a dog team in the brutal Alaskan winter. The winners finish it in about 10 days. Musher Jeff King is in the lead, having just reached the Ruby checkpoint on the Yukon River, after about 7 days on the trail. The chief instructor of a kayaking course I once took on Prince William Sound (before that idiot tanker captain dumped oil in it) also has a winter job as Iditarod race manager. You can read about him and his job at http://www.nols.edu/alumni/leader/03fall/makingarace.shtml if you care to. I've been fascinated by that race ever since I heard his stories. Since it deals with the topic, I thought I'd share one of of my all-time favorite books with you again. It's Winterdance: The Fine Madness of Running the Iditarod, by Gary Paulsen. Better known as a children's author, he lived in Minnesota and ran dog sleds as a trapper. The book discussed how he got sled racing into his blood. Early on, he tells us of an almost-fatal mishap in a training run:
[My friend] nodded, and we sat staring into the fire and I thought that any sane man who was in his forties and had a good career going would quit now, would leave the dogs, end it now and go back to the world and sanity and I knew what scared me wasn't the canyon and wasn't the hook hanging by one prong, but the knowledge, the absolute fundamental knowledge that I could not stop, would not stop, would never be able to stop running dogs of my own free will.
I see that Jeff King is now about to run the Yukon River. What do those two words mean, anyway? Just a river, maybe not all that different from the one outside my window as I write these words. Think so? Here's what Paulsen has to say about his run on it:
True cold, deep cold even without wind, intense cold becomes a
barrier as solid as brick. And while I had taken thirty, even forty below
and some wind, and had even become something close to cocksure about my
ability to handle winter, I had absolutely no goddamn idea what was about
to hit me. The Yukon River defines that which is cold.
...
Cold. So cold that when the sun came up and I felt the warmth on my
clothing, I wanted to cry and pray at the same time and when, after a
second vicious night, I finally arrived at the village of Kaltag, where
the trail leaves the Yukon River and heads a hundred miles out to the
Bering Sea, I was as grateful as I was when I got out of the army, or saw
my son born -- soul grateful.
I really want to convey the essence of it to you, because it's some of the most beautiful prose I know.. And I hesitate to publish the next section, because it deals with the end of Paulsen's race. But it's not the end of the book, and all I can tell you is that the following isn't a spoiler, even if it might seem so now. Before reading it, I need to tell you that the race ends in Nome, and that Paulsen had gotten a terrible case of bleeding hemorrhoids about halfway through the race and continued on despite it.
I pulled Cookie [his lead dog] left onto the sea ice where there was easier going and we kept moving until at twenty miles we stopped at the Safety checkpoint, the last checkpoint, and it was dark and in the distance, through the gusts of snow, I could see the lights of Nome.
I didn't want to go in. I thought suddenly of the old main who wanted me to come back and hunt seals and live on the coast, and I wanted to turn.
But Cookie knew. She saw the lights as well, and she knew and she took over then, picked it up and we ran the edge, still fighting the wind until I heard the siren (they set off a siren for every team that comes in) and we left the sea ice on a long ramp use to launch boats.
Front Street was bare and my plastic runners were about gone so I hung on to the sled and trotted alongside as Cookie pulled the team down the street where a crowd of people were waiting by the finish line.
There were lights and cameras and reporters and my wife and son and the Mayor of Nome welcoming me.
"So," a reporter asked. "What have you got to say?"
And I stood in my torn clothing, everything ripped and resewn, a sanitary napkin packed into my bleeding ass, my ability to think gone, my hips and back wrecked from the jolting of the runners; stood in the wreckage of seventeen days, fourteen hours on the trail; stood with spit frozen in my beard and frostbitten cheekbones, two of my toes black; stood in memories of attacking moose and carnivorous wind, the sweeps of the interior out ahead of me; stood in all of that and said with complete belief:
"I'm going to come back, and win this son of a bitch ..."
Disclaimer: This section will often refer to commercial vendors of products or services. Rolling Thunder Computing receives no compensation from these vendors in any way, shape, form, or manner; and would decline any if offered.
And now, the moment for which I know you've all been waiting -- the pictures of my two girls. Thanks to Rosemary for taking them.
Annabelle, the first girl, is now three and a half years old. She loves Winnie The Pooh (original A. A. Milne version, none of this Disney nonsense). She loves looking through the tide pools on the beach for periwinkles. Here she is on Plum Island Sound just below our house:
Lucy Katrina is now fourteen months old. She's gone past walking, now running around, starting to use words like "No!" and "Mine!"
Thunderclap is free, and is distributed via e-mail only. We never rent, sell or give away our mailing list, though occasionally we use it for our own promotions. To subscribe, jump to the Rolling Thunder Web site and fill in the subscription form.
Legal Notices
Thunderclap does not accept advertising; nor do we sell, rent, or give away our subscriber list. We will make every effort to keep the names of subscribers private; however, if served with a court order, we will sing like a whole flock of canaries. If this bothers you, don't subscribe.
Source code and binaries supplied via this newsletter are provided "as-is", with no warranty of functionality, reliability or suitability for any purpose.
This newsletter is Copyright © 2003 by Rolling Thunder Computing, Inc., Ipswich MA. It may be freely redistributed provided that it is redistributed in its entirety, and that absolutely no changes are made in any way, including the removal of these legal notices.
Thunderclap is a registered trademark ® of Rolling Thunder Computing, Inc., Ipswich MA. All other trademarks are owned by their respective companies.