Thunderclap, the Newsletter of Rolling Thunder Computing

Volume 2, Number 4 Summer 2000

In this issue:
I'm Late, But I Have a Good Excuse
About Thunderclap
Subscription Information
Feature Article: The SOAP You Don't Wash With -- Using XML for Inter-Machine Function Calls
New Book: The Essence of COM, Third Edition
Blatant Self-Promotion
The Internet Chuckle: Weird Al Yankovic
Contest with Prizes: Geek Greeting Cards  
Results of Last Contest: Geeky Limericks

I'm Late, But I Have a Good Excuse

A subscriber wrote me about a week ago to say, "Where's the Summer 2000 newsletter? Have you given up on us? ... I've received three of them since the lecture [at which he met me] and loved each one of them (hell, even my non-programmer wife loved the humour...)." Yes, I'll admit I'm late. But you can see I had a great excuse:

Annabelle Rose Platt arrived at 4:56 AM on June 30, weighing 8 lb 9 oz (3.9 kg) and being 21 1/2 inches (54.6 cm) long. To anyone who hasn't had a child, I can't begin to explain the complete and total change in your life's orientation when it happens to you. And to anyone who has, I don't have to. Now I get to drive everyone else crazy by talking about nothing else until they want to strangle me, just like I wanted to throttle every besotted new parent until I became one.  Anyone who really gives a damn can find enough pictures of her to bore yourself silly on her own web site, which is, naturally.  You know you're really a geek when you hold off naming your new daughter until you find out if your proposed name is still available as a Web address.

About Thunderclap

This is the eighth  issue of my (more or less) quarterly newsletters. Each will bring you a technical article on current topics in software development, which I hope you will find useful. Each will also bring you a contest, allowing you to show off your intelligence and creativity to win prizes, which I hope you will find funny (although some readers have reported the reverse.) In between you will find my own blatant self promotional material, telling you about the latest ways I've come up with to separate you from your money. (I could have said "carefully selected products and services that we feel might interest you", or other mealy-mouthed horsepuckey. You want the truth or you want me to waste my time and yours dressing it up?)

I'd like to hear what you think about this newsletter and what types of articles you'd like to see in the future.  Send your e-mail comments to

This newsletter may be freely redistributed, provided that it is sent in its entirety. If you enjoyed it, can I ask you to please forward it to a friend who might also enjoy it? The subscription roll has grown to over 1700 for this issue.

Subscription Information

Thunderclap is free, and is distributed via e-mail only. We never rent, sell or give away our mailing list. Subscription and unsubscription are handled by a human operator reading e-mail messages. To subscribe or unsubscribe, jump to the Rolling Thunder Web site and fill in the subscription form.

Feature Article: The SOAP You Don't Wash With

Using XML for Inter-Machine Function Calls

(This article assumes a conceptual familiarity with XML)

The computing press has written a great deal lately about SOAP, the Simple Object Access Protocol. (Computer geeks usually name their creations with TLA's [Three-Letter Acronyms, TLA itself is a TLA], but they must have run out of them as I predicted a few issues back, and had to start using FLAPs [Four-Letter Acronym Packages, FLAP itself is a FLAP {I created this one. Like it?}] )  Besides more terrible puns than Java -- developers in a lather, marketing airheads blowing bubbles, Microsoft's new proxy library called "ROPE", a failed connection reporting, "No SOAP, radio!" --  what does SOAP actually mean to us and how can we make money with it?

SOAP is a standard for encoding inter-machine function calls in XML so they can be passed among heterogeneous systems. It enables any client app to call a function on any server machine, no matter what operating system each is running on or what language each is written in. It says to Java, "Hey, I'll see your alleged machine independence, and raise you language and protocol independence, too." SOAP is interesting in itself, but even more interesting as the underpinning of Microsoft's new .NET strategy, announced in Orlando in July of 2000. They've essentially bet the company on the Internet, and SOAP is how they're going to get it done. The last time Microsoft bet the company on a technology was 1991, and the technology was Windows.  

My latest column in Byte.Com discusses the problem background and architecture of SOAP at a conceptual level. Unless you've come to this newsletter from the link in that column, you really need to read it first, or you won't understand why I'm going through what seem to be pointless and painful gyrations. Clicking here will open it in a separate window. I'll stop writing until you've read it.  

You're back? Good. You've probably noticed by now that all Internet programming strategies are converging on XML, so that really needs to be the next topic you study in keeping your skill set current. If you don't already know it, I'd suggest hiring me to come teach it to your company. You can find more information on my Web site here

The rest of this article is targeted at programmers, so I won't be offended if managers and architects skim it or skip it. But don't miss the Internet Chuckle (Weird Al Yankovic's Star Wars spoof) or last month's contest (geeky limericks), or I WILL get very offended. Better yet, send in an entry for this issue's Geek Greeting Card contest, and I'll bestow immortality on your words, and if you're the funniest, $100 on your wallet. I wouldn't mind if you read my Blatant Self Promotion section either. 

This article describes a SOAP client at the raw XML level so that you understand what SOAP is really doing in its heart of hearts. The sample programs illustrate a very low level of abstraction, as if I had written a COM object in raw C++. While you won't write much industrial code this way, understanding such an example is ABSOLUTELY ESSENTIAL to using the higher abstraction tools that will eventually evolve. You can't just click Wizard buttons, say "Gee whiz", and expect your product to ship;  not with the MFC, not with the ATL, not with COM+, not even with VB no matter what its advertisements say, and it shouldn't surprise you, not with SOAP either. I get calls every week from clients who hit a deadline crunch and still have bugs that they don't even know where to start looking for because they don't know the underlying operating system. I used to get annoyed at them, before I started counting the money I made bailing them out at the last minute. Then I decided that I agreed with the bandit leader in The Magnificent Seven, who says of the Mexican campesinos he is robbing, "If God hadn't wanted us to shear them, He wouldn't have made them sheep."  

The sample programs for this article are written in Visual Basic version 6.0. You can download them by clicking here. They use the services of  the SOAP server that Microsoft maintains on the Web as part of their new SOAP SDK.  You can download that SDK from this location, but you won't need it for this example.  

The first thing we need to do when programming a client is to find out what functionality is available from the server. When we write COM code, we get this information from a type library that usually came bound into the COM server file, or sometimes stood alone in a separate file. In SOAP, this description is provided by an SDL (Service Description Language) file, generally provided on the Internet by the server vendor. In this case, Microsoft's documentation tells us that it's at SDL is an XML vocabulary used to describe the services provided by a server to external clients. You'll find it somewhat cryptic, but the fact that you can puzzle it out at all demonstrates one of the great strengths of XML. Imagine trying this with a binary type library, and tremble. I've excerpted a bit and removed some uninteresting parts so you can easily see the sorts of things it contains. The first section is a list of the methods provided by the server and the URLs at which they live, which is not necessarily the location of the SDL file. The second section is a list of the parameters required by each method (none in this example) and the data returned by each method. The SDL file on the sample server actually contains three other methods, omitted here for clarity.

<serviceDescription name="SoapService"

    <soap xmlns="urn:schemas-xmlsoap-org:soap-sdl-2000-01-25">
            <requestResponse name="GetServerTime">
                <request ref="ss:GetServerTimeReq" /> 
                <response ref="ss:GetServerTimeRes" /> 
                <location url="" /> 

    <ss:schema id="SimpleStuff">
        <element name="GetServerTimeReq"/>
        <element name="GetServerTimeRes">
                <element name="Now" type="dt:string" /> 

I've written a sample program that opens the SDL file and displays its contents. It fetches the SDL file, puts it into Microsoft's XML parser, and uses DOM to read the contents of the file and put them into a tree control for you to see. I could have formatted it into HTML by means of an XSL style sheet and displayed it in a browser, but I decided that I'd rather demonstrate programmatic access to the file's contents.  It looks like this:

Now we know the methods that this server provides us. An intelligent programming environment would probably spit out a wrapper class for us, and in fact wizards are under development that do exactly that. But this article exists to explain what's happening under the hood, and none of the wrapper wizards is really ready for use yet, so we'll stay at the raw XML level. 

SOAP separates the function call data from the transport protocol used to transmit it. A client program wanting to make a SOAP call creates a SOAP message containing information encoded in SOAP's XML vocabulary, and transmits it to the server via any mutually agreeable transport protocol. You can read the specification of that vocabulary on the W3C web site devoted to SOAP, located at  A SOAP message consists of an outer envelope, which contains an optional header and a required body. The body contains the name of the function to be called, and any parameters that got passed to it. A SOAP message for the GetServerTime method of this server would look like this: 

<?xml version="1.0"?> 



The client program is shown below. It calls the GetStockQuote( ) method of the server, which requires the stock symbol as a parameter. The SDL file says that this method expects another parameter called "description", but I couldn't figure out what that meant, and the server responded just fine without it, so I left it out. The sample program displays the XML strings that it sends to and receives from the server. Anyone who's interested can examine the source code and see how I assemble the XML documents using the Microsoft parser. I hard-coded a template string containing all the elements of the message, because these are the same for every call. I simply change the value of the "symbol" element to reflect the symbol the user has typed in. The "Cause an Error" button deliberately transfers an incorrectly formatted message, so you can see how SOAP handles errors.

SOAP's XML encoding is independent of transfer protocol. It will run over anything that the two parties can share. Often this will mean HTTP for maximum compatibility, and that's the example the I demonstrate here. I know that Microsoft's SOAP server is listening on this protocol, and I wrote the client app to use Microsoft's Internet Transfer Control to actually do the HTTP POST operation. I expect that other protocols will emerge in the future, and IBM actually has a listener that works on SMTP, so you can send and receive your SOAP messages via e-mail.  You can download it from IBM's SOAP site here at 

The response packet comes back from the server in its SOAP-encoded format as specified in the SDL file. It is up to your application to parse the data and make sense of it. In the sample program, I stuck in in the XML parser, read the pieces I cared about, and displayed them to the user. In real life, you will probably write a wrapper class that does these things for you.

We'll continue our discussion of SOAP and the new .NET technologies in the next issue. Enjoy playing with your new SOAP program. Give me a call if I can help you out. Until next time,  as Red Green  would say, "Spare the duct tape, spoil the job."

New Book: The Essence of COM, Third Edition

by David S. Platt, President of Rolling Thunder Computing

Prentice Hall; ISBN: 0130165816

I've updated  my basic COM book and released a new edition, which should be on shelves by mid-May, available at your favorite geek book source. It reflects the way my understanding of COM has changed since I wrote the first edition five years ago (an eternity in computer terms).   The new edition contains two sections. The first deals with the bare guts of COM. The second shows how various development environments (VC, ATL, VB, and VJ) provide higher levels of abstraction that make COM code easier to write.  I've removed all the material dealing with the MFC, that platform being dead for COM development. The table of contents is:

1. Introduction, COM Object Clients

8. Persistent Objects

2. COM Object Servers

9. Monikers

3. Custom VTBL Interfaces

10. Asynchronous COM in Windows 2000

4. Automation and the IDispatch Interface

11. COM Support in Visual C++

5. Type Libraries

12. Active Template Library (ATL)

6. Threading

13. COM Support in Visual Basic


14. COM Support in Visual Java

Blatant Self Promotion

In-House Training Class on XML

You've probably been hearing an enormous amount of hype these days about XML. It sounds like a great idea, and it is indeed a beautiful solution to certain classes of problems.  I developed a training class on it in response to client demand, and I've booked it 12 times since February just by word of mouth. This three- or four-day training class covers the guts of XML, such as well-formed documents, validating documents with DTDs or schemas, programming XML using DOM and SAX, and transforming XML with XSL stylesheets. We look at the portions of XML that don't quite exist today (XLink and XPtr, XQL, and to some extent schemas) and discuss how we'd like to use them. Most important, we talk about how to use XML in real-life applications: the advantages and drawbacks, the places where it fits well, and the places where you'd be trying to bang a square peg into a round hole. Get your reservation in quickly, because this one looks hot. You can read all about the new XML class on Rolling Thunder Computing's web site,

In-House Training Class on COM+

Rolling Thunder Computing is pleased to announce its new in-house training class on COM+. This three or four day training class will cover all portions of COM+, including that catalog, security, synchronization and threading, transactions, queued components, and events. You can read all about it on Rolling Thunder Computing's web site,

Public Three-Day Class on XML for Insurance in Seattle Oct 2-4. 

I'll be presenting this 3-day training course is designed to educate the technical person on XML and the ACORD XML standards for both P&C and Life insurance. It gets beyond the hype and teaches programmers what they need to know about this technology standard. Sponsored by Safeco. Register with

Public One-Day Class on COM+ in Boston on October 28

I'll be presenting a one-day class on COM+ on October 28, sponsored by the Boston chapter of the ACM. Full syllabus and registration information is at Time and location will be posted there when available.

Advance Notice: XML in Sunny Iceland December 11-14. 

I'm going back to the University of Iceland in Reykjavik to teach a 4-day class on XML on December 11-14. I couldn't talk them into August, don't know why. If you've never been to Iceland, they've got great seafood and amazing geothermal hot tubs. If you're on the East Coast, it's closer than California, though not as sunny, I have to admit. I don't have the URL at press time, e-mail me if you're interested. 

The Internet Chuckle

Everyone needs a good laugh, right?  We can't always depend on politicians to provide it, especially now that Bill Clinton's a lame duck and both major political parties have nominated the most boring candidates since Dukakis and Bush Senior. (Where's Dan Quayle when we need him to make fun of? Although Jackie Mason says that Hillary Clinton's Senate run is a joke that not even he can top.) In an effort to make more readers say, "Great, a new ThunderClap," I've added this new section, which will feature a link to an Internet site that tickled my warped sense of humor within the last quarter. 

This issue features Weird Al Yankovic's music video spoofing "Star Wars: The Saga Begins". Set to the tune of "American Pie" ("A long, long time ago ...  " remember?), it features Weird Al himself as young Obi Wan Kenobe.  A good part of the video is set in an interstellar bar, similar to the one that provided perhaps the defining moment of the original movie. You can buy the new song on his album Running With Scissors, (the cover shot is worth a look to anyone that's ever left WinWord's tip of the day feature turned on) but better yet, you can view the entire video online for free. Click the picture below, or surf to This one is worth viewing on a high-speed connection. 

This section will often refer to commercial vendors of products or services. Rolling Thunder Computing receives no benefit from these vendors in any way, shape, form, or manner; and would decline any if offered. The sole criterion for mention in this section is that I laughed at it, and that I think people as sick as I am would do so as well. If you know a good one, send me the URL at If I use it, I'll send you a Rolling Thunder Computing coffee mug, which makes an excellent specimen container when your company implements mandatory drug testing. 

Contest with Prizes: Geek Greeting Cards

Lord, send a man like Robbie Burns to sing the Song o' Steam! 
-- Rudyard Kipling, "McAndrew's Hymn", 1894

I was killing time waiting for yet another delayed flight, and I found myself browsing through the airport card store. I hadn't done that for a while, and I was astounded by the vast array of greeting cards available to the modern tongue-tied sender. I remember receiving "Happy Birthday" cards in my misspent youth, occasionally specializing to "Happy Sixth Birthday, Grandson".   Today's market has hyperspecialized,  to the point of  "Deepest sympathies on the death of your gerbil." "HOORAY! Your herpes test was negative!" or "Congratulations on your successful plea bargain." That's what we geeks need to get some respect -- our own line of greeting cards. You can help. Come up with your best geek greeting cards. For example:

Deepest sympathies on your hard drive crash. Hope you were backed up. 

(Cover) Congratulations on going public! (Inside)  I'LL KILL YOU, YOU SON OF A BITCH!

(Cover: Picture of bull defecating) (Inside) Welcome to management.

If you're really feeling really flush, you can submit artwork along with it. As always, your entries must be computer-related and original. This isn't a family newsletter, so they don't have to be clean or politically correct. Submitting more than one increases your chances of winning. First prize is $100, second prize $50. Winners will be announced in the next issue of Thunderclap, and the judge's decision (mine) is final. In the event of duplicate or similar entries, the earliest wins. All entries become property of Rolling Thunder Computing.  All authors will be identified by first and last names, but not by company. Authors names will be withheld if you so request. Submit your entries via e-mail to

Results of Last Contest: Geeky Limericks 

First prize this month goes to Tana Sabatino, who won the haiku contest a year ago

There once was a geek named Platt
Who swore by his Microsoft hat
He preached every day
About COM and OLE
Until XML knocked him down flat.

He quickly changed his routine
Cause the bills for his house were obscene
And for Annabelle
He decided to sell
Out to the corporate regime.

Tana, I'm insulted. How dare you imply that I sold out since the birth of my child? You should know better than to say such a dumb thing, and ought to retract it. I sold out at least ten years ago, maybe more. 

Second prize goes to Ed Regina, one of my Harvard students:

The web is a mountain of dough 
To fatten three geeks on the go 
With Java they blunder 
Their clients go under 
Meet Curley, Larry, and Moe

I've always considered the Three Stooges to be the pinnacle of American comedy. ("That figures", you say.)  When I was five, I could never understand why hitting my little brother's head with a hammer never produced a loud "bong" like when Moe did it to Curly.  Some say that the Stooges are all dead (except for the National Enquirer, which shows them in a UFO with Elvis and Bigfoot headed for the Bermuda Triangle) . But how else do you explain Windows 95? 

And honorable mention to all:

There once was a server named Mabel 
Who said as she set the v-table 
"When my clients appear, 
For my functions it's clear 
I'm ready, willing, and able."

    -- Ed Regina

A computer exec named Armand
would type with a strong heavy hand.
Six figures he earned,
but he never quite learned
that "RAM disk" was not a command.

Languages that use lots of "for" loops
are derided by many design groups.
But when asked for a substitute
they look rather destitute
for all they can tell us is "OOPs."

One thing that gives me a whirl
is programming web stuff in perl.
But if I see another
CGI redirector
I think that I'm gonna URL.

    -- Wei-Hwa Huang

Programmers learn the technology Well,
Keeping up with all the new things, even XML. 
They practice until the day they die, 
Just so they can keep ahead of the other guy. 
I'm sure this is what it’ll be like in Hell.

    -- Bruce Carson

Garth Wolfendale submitted the following, which aren't really limericks, but I'll bestow immortality on them anyway:

God made the earth in 6 whole days
which is a little week (weak)
He could have done it real soon now
if he'd have been a geek.

DNA2000 is a gas
But complicates our lives, alas.
Acro-nyghtmares for the few.

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 © 2000 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.