I think every kid had a Spirograph when I was growing up.  I know that I spent countless hours with my colored pens and those little plastic pieces, trying to overlap figures in different ways to make beautiful designs.  I’d pretty much forgotten about Spirograph until 1995, when my friend and co-author Jeff Duntemann wrote a program he called “Spiromania” for our book Delphi Programming Explorer.  I converted the program to C++ for The C++Builder Programming Explorer, and have played with it from time to time since, even toying with it when I was learning about writing Windows screen savers.  I’m at it again, but this time with completely new code written in C#.  It’s a project for learning .NET programming.

One of the cool things about computers is that you can simulate things that you just can’t do with a physical model.  For example, the two figures shown above were created by simulating a circle of radius 60 rolling around a circle of radius 29, and the pen on the edge of the bigger circle.  The only difference is that the figure on the left is drawn with smooth curves—which is what you’d get with a real Spirograph toy—and the figure on the right is drawn by plotting 5 points for each time the big circle goes around the little circle.  (In actuality, the figure on the left also is drawn using straight lines, but the lines are sufficiently short to give the illusion of smooth curves.)  In any case, the figure on the right would be impossible (well, okay, exceedingly difficult) to create using a physical Spirograph toy.

I’ve written a .NET custom control so I can drop these things on a form and fiddle with their properties.  I’m working now on some animation and a little better user interface, and eventually will have a program that will allow you to create and manipulate multiple images, moving them around and overlapping them.  It’s great way to learn a new programming environment.

The basic idea behind Web services isn’t really new.  Over the years I’ve seen a few IT shops that had standard protocols for their disparate systems to communicate.  They all had problems, though, because the protocols were mostly ad-hoc creations not subjected to rigorous design, and weren’t very easy to modify or extend.  And there was no possible way that systems from company A could talk with systems from company B.

Microsoft’s innovation (and perhaps I’m stepping on a land mine using that word here) isn’t so much the individual ideas of standard protocols, standard language, automatic data description and discovery, or any such technology.  No, Microsoft’s innovation here is in tying all of those individual technologies together, filling in the holes with very solid design work, and pushing for standardization so that any program running on any modern system has the same ability to query any other system for information.

You don’t need .NET in order to write or access Web Services.

Naysayers and Microsoft bashers will complain (mostly unjustly, in my opinion) about the company shoving things down our throats, strong-arming the industry, or coercing standards organizations.  The plain fact of the matter is that our industry has needed something like this for at least 10 years, and no “consortium” has even come close to providing it.  Certainly, Microsoft hasn’t acted alone in this—they’ve had the cooperation of many other companies—but without Microsoft, it wouldn’t have happened.  Microsoft has provided a huge benefit to the industry by spearheading the creation of an open Web services architecture and making it freely available to all.  That they stand to make money from selling applications and development software based on Web Services doesn’t lessen the benefit that they have provided.  To the contrary, it should make them much more interested in ensuring that the standard is complete, consistent, and flexible.  From what I’ve seen of the standards, I believe that it is.

One of the things that impresses me most about Microsoft’s .NET strategy is not so much the technology behind it (although that is impressive), but rather the way they’re going about selling it to businesses.  Microsoft has identified a real concern in the business world:  disparate systems that have to share information.  For example, consider a medium sized bank that has offices throughout southern and central Texas.  Among the systems that they support are:

• Central data processing for posting checks, deposits, loan payments, etc.
• Web site
• Online banking
• Automated clearing house for Fed transactions
• Word processing with central document storage
• Teller terminals
• Automated Teller Machines
• Customer Relationship Management system used by Customer service representatives
• Credit rating and scoring system
• Human Resources

Those are just some of the internal systems.  They also would like to interface with their suppliers and business partners.  Some run on big iron, some on PCs, others on older systems that aren’t even supported by their manufacturers anymore.  Some of the systems are in a single location, and others are spread out over thousands of square miles.  Software is a mix of pre-packaged applications, commercial applications with custom modifications, and in-house custom applications.  Ideally, all of these systems could share data.  That turns out to be very difficult, though, due to incompatible formats (ASCII versus EBCDIC, for example), incompatible communications protocols, or other problems.

It’s certainly possible to modify each system so that it can interact with all the others.  The obvious way is to modify each individual system so that it understands what it needs to know about each of the other systems.  Assuming that each of the 10 systems above needed to interact with all 9 others, you would have to write 90 different interfaces.  Even if you only had to write 1/4 of that (23 interfaces), it’d be a daunting task.

Microsoft’s idea (more on that tomorrow) is simplicity itself:  write just 10 (maybe 11) interfaces.  If you can define a standard communications protocol, and a way for all applications to describe the data that they provide, then all you need to do for System A to talk with System F is to tell System A what data it needs to obtain.  It becomes almost a trivial matter to instruct System A to obtain the current balance information for a particular account.

So why “maybe 11” interfaces?  Ideally, each system would be able to communicate with each of the others using the standard protocol.  If that’s not possible, though (consider an old machine that has no ability to communicate via TCP—they do exist), than an intermediary system will have to serve as a proxy.  The proxy machine accepts requests from the other systems on the standard protocol, and relays those requests to the orphan systems.  Or, vice-versa.

This is the basic idea behind “Web Services.”  Although simple in concept, it still requires much thought and care in design and implementation.  More tomorrow.

I’ve been studying Microsoft .NET for a month now, and I continue to be impressed.  Microsoft put a lot of very serious thought and design work into .NET, and they have produced an incredibly useful development and execution platform.  Finally, I have a unified model for which I can develop all types of Windows applications and components.  Whether I’m writing a standalone Windows application, a console application, a Web site, an XML Web service, or a system service, I use the same development model.  True, I could have done that in the past using straight Windows API calls, but I do like to actually finish projects from time to time.

The other nice thing?  It’s language independent.  You can write modules in C#, Visual Basic, COBOL, FORTRAN, or any other .NET supported language, and (provided you follow some simple rules about standard data types) they’ll all work together.  This is much different than using COM or ActiveX components, which were supposed to be language independent but rarely were.

Overenthusiastic .NET supporters will talk about platform independence, but don’t let them fool you.  Whereas it’s true that Microsoft has submitted the C# language and the Common Language Infrastructure (CLI—a subset of the .NET Framework) to international standards bodies, I find it doubtful that they will actually release a version of .NET for anything other than Windows operating systems.  I suspect that the “platform independence” that is built into .NET is there to support future versions of Windows rather than Linux or some other operating system..

There’s a lot to like about .NET, and in a month of studying it I haven’t found any gaping holes there that would make me not want to use it.  This is the most exciting new thing to come along for developers in a very long time—way more exciting than anything I found in the Linux world (something I’ll discuss another time).