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.