Hi Jim,

Let me start this one by saying that if one feels confused about this whole .NET thing, it's perfectly justified in my book. I don't know if I'd go so far as using the overused buzz phrase "paradigm shift", but it's certainly a bit of a leap from COM as we know it today. Below, I'll lay out some directions for you to get started today using some of the concepts that you've/'ll be/been hearing about .NET. (BTW, can someone send me a link to the whitepaper to which Jim refers? I haven't had much luck finding it, and I want to make sure I'm sticking with the party line. :-) TIA.)

>While I do not argue with your example for "subscribe" (as we know it today), I do not equate the following excerpt from the white paper to be the same:
>"...With the option of subscribing to these core Microsoft .NET services off the shelf, developers can make a "buy or build" decision as to where they want to spend their development resources".

Ah, but it is the same. I'm just not really good at explaining it, which might explain why you don't see me doing DevCon sessions. :-)

>In addition, the link Marcel provided has the following quote (under the Web Services heading):
>"...No longer will you buy a component. You'll subscribe to it instead! That way, upgrades are immediate and automatic.".

This is exactly what I was talking about. It's just that my last message was hastily written (as are most of my messages here; too little time in the day), and I didn't really take the time to fully explain what I was talking about in such a way that it's crystal clear. So, sit back, relax, and bear with me as I attempt to take a little extra time to explain it.

In the article Marcel posted, note the section heading under which the text you quote resides: "Web Services". So what is a "Web Service"? Perhaps this next analogy will be better than the last. Suppose you want to create a website call "My Concierge". This website gives the user all the info they need on one webpage: sports scores, stock quotes, weather for the user's local city, and we'll even throw in movie listings to boot. You could make such a page today by snarfing info from various other web pages. For instance, you can get the local forecast by going to www.weather.com and parsing the HTML to get the information you need. But what if the Weather Channel(tm) changes the format of the page? No biggie, you just reprogram the parser. But if you've got a dozen web pages from which you pull information, this suddenly becomes a huge pain in the butt because web pages are constantly changing formats (the Weather Channel is a bad example because, thankfully, their format hasn't changed much in years; but you get the idea).

But what if I could go talk to the Weather Channel and say, "I need local weather info so that I can post it to my user's page. What kind of interfaces do you have that will give me local weather info?" Suppose the Weather Channel comes back and says, "well, I've got an interface that gives you the current local temperature, an interface that gives a text forecast, and hey, if you can accept a .BMP, I can even give you a RADAR image." That's Web Services. Guess what? It's not even MSFT-specific. It's a W3C standard. So it doesn't matter if the server is a Linux box, an NT box, a Sun box, or a box running IBM AIX. As long as it conforms to the W3C standard, we can get the info.

So, we could have a "sports score" server dishing up the info from a Linux box, a stock quote server dishing out stock quotes from a Sun machine, and a weather server serving up weather info off of a Win2K server. And all of this information is in a format that anyone can understand. Therefore, to assemble your "My Concierge" web page, you just need to integrate all of the Web Services into your page. No parsing, no keeping up with web page changes, just ask the server what it has to offer, and collect your data from there.

So what's this standardized format? SOAP. Buried somewhere in http://msdn.microsoft.com/vstudio/ is a link to the VS SOAP Toolkit (sorry, I'm too lazy to track down the exact link right now). Download it, learn it, love it; the whole .NET thing will become clearer once you do, IMO. You can create VFP-based Web Services today using the Wizard. Read the docs, and you'll see what I'm on about. This is what I was referring to in my earlier message. IOW, why reinvent a stock quote service when you can just pull it from a Web Services server (which you may or may not pay for) and show it to your user?

How does this relate to the article you quoted? Easy: you can build your own, or you can subscribe (maybe paying for it, maybe not) to a Web Service and get it pre-rolled.

>"Used this way, software becomes a service, with software companies increasingly becoming application service providers (ASPs) that let customers access the most up-to-date versions of their programs over the web."

It is my hope that my description above fits in neatly with this. Using the stock quote example again, at first you may get 20-minute delayed quotes. Later on, the company decides to offer real-time quotes. Therefore, it's an upgrade. Normally, you'd have to download new software. With Web Services, the interface may not even change, but you get upgraded functionality. Even if the interface does change, the standardized SOAP protocol means you can get the upgrade with minimal, if any, changes.

>Basically I see a possible significantly different reading of the white
>paper than you (and others, seemingly) do.

Again, I hope that my above explanation demonstrates how what you're reading and what I'm describing are the same thing.

>For instance, I feel that it could be read as MS itself will become the world-wide repository of DATA that people want/need to exploit .NET. As such MS would take primary responsibility for storage/retrieval, security, performance, etc. etc.

Imagine for the moment that I work for Joe Blow's Software Emporium and not Company MSFT (please refer to .sig :-). Given that, I'd have to say you're spot on...almost. It isn't data that MSFT wants (primarily concerning .NET), it's the application services market. It's my guess that MSFT sees monolithic apps (MS Office, for instance) going the way of the dodo. ASPs (Application Service Providers, not Active Server Pages) are the wave of the future. Personally, I think that model is completly screwed up (anyone remember mainframes and terminals?), but that's the direction everyone seems to want to be heading. MSFT is just along for the ride. I think the Web Services thing is a great idea, but having my Word docs reside on a central server is just plain short-sighted, IMO. 20Gig drives are under US$200. How much, then, would I be willing to pay to store docs on a web server? Or even to run my office apps through a web browser? Nope, local client apps are here to stay, I say. I'm hard pressed to find a business model for ASPs that competes with dirt-cheap local storage.

It's my prediction that the whole ASP thing will slowly die off, much like Net appliances will. But Web Services have a lot of potential, not only with B2B (please, let EDSI die the quick death that it deserves), but with the poor "My Concierge" example I sited above (that was off the top of my head, and not a MSFT marketing example; don't blame MSFT marketing for my poor analogy. :-)

Oh, shoot, I guess I've digressed just a tad...

> It is also possible that XML will be the only "programming" to be done >regarding the .NET services

XML is just data. Programming and interpretation of those data is still necessary.

> (yes, I understand that BASIC or script can be included in XML).

Really? News to me. Doesn't mean it's not true, I just thought XML was stricly data.