XML & Web Services

Radio SiliCow Valley
Moos, news and views from the Heartland...

Home

XML & Web Services

-----Original Message-----
From: Robert Barksdale [mailto:robert@netologies.com]
Sent: Friday, February 08, 2002 9:54 PM
To: radio-dev@yahoogroups.com
Subject: [radio-dev] XML & Web Services

Hello, Everyone!

This is a little off topic, but I thought you would find it interesting.

I ran across an article today called "Top 5 Uses for XML". Dan Wahlin talks about:

1. Data Exchange
2. Web Services
3. Content Management
4. Web Integration
5. Configuration

Everyone see a pattern? Sounds a lot like Radio to me. I've got a link off my blog for those interested.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-----Original Message-----
From: Robert Barksdale [mailto:robert@netologies.com]
Sent: Saturday, February 09, 2002 10:47 AM
To: radio-dev@yahoogroups.com
Subject: Re: [radio-dev] XML & Web Services

Actually, jt, I thought your comments were worth the read. Maybe you could use Radio's Stories feature and post it. Reading the author's comments I saw these parallels:

1. Data Exchange = Radio News Aggregator
2. Web Services = XML-RPC & SOAP equipped
3. Content Management = What Radio is all about
4. Web Integration = E-Mail to Weblog
5. Configuration = Radio's Weather Report

XML is just one component used by Radio to deliver the message.

Thoughts of a Radio Neophyte,

Robert

On Saturday, February 9, 2002, at 07:55 AM, jt wrote:

Oooops... sorry.

What started out as a short comment, turned into (what should have been) a blog...

<Heoooge snip>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I have no intention of starting a ruckus, but I see another pattern. From top to bottom, the least appropriate to the most appropriate uses of XML, except that I'd swap #2 with #4. (I've not studied "Web Integration" much, but I'd take it to be "that which turns into grid computing, once the scientists define what grid computing is").

This is probably not going to be a popular view, but I think it's an extension of the concept that mono-culture is not necessarily a good thing, and frequently is a bad thing. IOW, the world speaking Esperanto makes more sense, to me, than using XML for some of these things.

I understand the theory is that Moore's Law will make all this possible; the inefficiencies of using XML to tranport data won't really matter.

I don't buy into that theory for three reasons:
o   That makes low-end computers useless
o   That robs Moore's law of being able to do other, useful, things
o   It's completely unnecessary, IMV (in my view of the world)

Maybe what I'm saying only applies to business applications. In typical business apps, the effective optimizations are always in minimizing the I/O needed. You're constantly shuffling megabytes of data, day-in and day-out... So business app programmers concentrate all their optimizations on minimizing this I/O bottleneck. It's not an issue of adding CPU cycles to each data transfer. The problem is adding a layer of complexity to each and every one. And I believe the added complexity isn't going to solve the problem it's intended to solve, as I understand it.

This will become an even greater issue as traditional server functions are driven down to the desktop. Plus people, as a general rule, are not going to want to buy extra PCs to handle the mixed workload, the way businesses tend to want to build up server farms.

I believe the goal of SOAP, and XML to a lesser extent, is to eliminate (or automate) the function of different programs needing to know what each expects to receive from, and send to, the other. (The goal may be stated as connecting disparate systems, but that's been available for years, without needing any XML.) Perhaps I just don't know enough about all this, but that appears to be the fundamental goal. Allowing the ability to transmit amorphous data from system to system. If that's the goal, I'm afraid we're in trouble...

Never worked in EDI systems, but know a little more about them than XML. Over the decades EDI has defined almost all the data elements, and all the protocols are in place with EDI... But they're still a royal pain, and very expensive to set up. Because companies (ie people) do not use the data elements consistently. When the two companies don't keep in sync with EXACTLY what data is being passed in what data element, you get screw-ups every time. Then a person has to fix the screw up. They may take the time to identify the screw up and prevent it in the future, or they may not... The labor costs to fix the screw ups are relatively cheap.

But the cost of transactions slipping through the cracks is going to (and has been) escalating. When you're working on JIT inventory and real-time transactions.. having one slip through the cracks for a day or two or more... well that starts getting real expensive, the more you depend on things happening on schedule. I'm sure most have heard the horror stories of what happens when an auto-deposited paycheck doesn't happen on schedule. Inventory is money... Information is money... Things will similarly get disrupted if these things slip through the cracks...

It would be easy to test the assumptions I'm using. Some companies are using XML to transmit EDI formats. Same EDI formats using XML for the transport protocol... (It will definitely be somewhat easier to hook up disparate systems, but that hasn't been the primary problem with EDI for a decade or so...) It should be easy to tell if XML does, in fact, fix the problems that normally come up with EDI transmissions, or whether it's about the same, or whether it actually makes the EDI errors go up... If your error rate doesn't go down significantly, then why spend the CPU cycles, just to transport data.

I'm guessing that more complicated pieces of information would benefit more from XML.

But when I described business apps, earlier... Come to think of it, all Net apps are I/O bound. Yeah sure, we could work on the assumption that the whole world is eventually gonna be wired with G-bit networks, right?

And if I had my druthers, I'd just soon spend my CPU cycles on other things, like keeping my bank accounts safe or voice-recognition or things like that... Not on raw data transport.

Welcome other views, of course... But I'm not up on all the buzz-words, so may not understand it if the views are expressed in terms that are too technical. But this sure smells like mono-culture of the unfortunate kind, to me...

Funny thing is I agree with the basic premise, that all these things sure seem to point to Radio...! The extent to which Radio needs to be optimized and in what areas, of course, is UserLand's call to make.. not mine. Just suggesting the importance of I/O tends to be over-looked. That's one of the primary differences between a Server environment and a single-user environment. I'm guessing a server-on-the-desktop is going to make a single-user environment behave even more like a mixed-load server, than it has in the past.

jt
SiliCow Valley, USA...;-)