Re: [xml-dev] More predictions to mull over

[Rick Marshall <rjm@zenucom.com>]

This conversation is interesting and as usual history will tell us 
whether any of it was correct.

However, my problem (as one of those small companies that can't afford 
to follow every technology path just in case..) is this:

For 20 years now I've been building cooperating servers. Each one has a 
task like back office, shop, warehouse etc and they pass messages around 
to keep each other updated.

In the start I used uucp, then uucp over tcp/ip, then sendmail, then a 
proprietary socket, and now http. The message body hasn't changed much - 
the proprietary message has worked well.

But the world is moving on, I'm approaching dinosaur status, and I need 
to convert all this to something the next generation of programmers will 
understand.

So, amongst all these predictions is anything seen as building momentum 
to be the way for low level server communication? Does anyone really 
care? Is it all now about the user interaction?

Rick


Elliotte Harold wrote:
> Michael Champion wrote:
>
>> Maybe you don't see the problem because you are happy writing custom 
>> integrations, one system at a time. Eric is talking about 
>> standardizing that process so that his customers don't have to figure 
>> out how to map each application's data and protocols laboriously onto 
>> XML+HTTP, reinventing 90% every time. They want to put that common 
>> 90% into the infrastructure and just build on top of it.  
>
> I guess I'm not convinced that there is a 90% or even 50% commonality 
> to these systems that can be taken advantage of. If there is (and 
> there might be) I don't think WS-* has managed to find it. Ws-* adds 
> so much complexity and confusion to the process that it is easily more 
> costly and complex than doing custom integrations one system at a time.
>
> Could somebody find a way to hit the 90% point better without all the 
> extra complexity WS-* brings to the table? Maybe. I haven;t noticed it 
> yet if anyone's done it.
>
> I do think there's a problem with overly generic solutions in our 
> industry, especially when pushed by large organizations. They try and 
> solve all problems even when they only need to solve one. The simple, 
> specific, one-off solutions are usually all most companies need most 
> of the time, and they come in a lot cheaper.
>
> WS-* is hardly the only place where I see this. The problem is rampant 
> in APIs. See 
> http://www.wormus.com/aaron/stories/2007/02/13/interoperability-is-overrated.html 
> for another example and some more discussion.
>
> Sometimes you do need interoperability and a high level of genericity, 
> but more often than not you don't. My problem arises when people tell 
> me I have to pay the cost for genericity even when I don't need the 
> interoperability that buys me.
>
>
>> For example, what if the RSS ecosystem didn't exist, but people 
>> wanted to track changes to a number of websites in a client or server 
>> side aggregator.  One could happily sink one's teeth into the problem 
>> of scraping the HTML of each site of interest, transforming the 
>> common information into a common XML format or database schema, and 
>> sorting/filtering/displaying it on demand.  Then RSS came along and 
>> shoved all that down into the infrastructure. Probably people on this 
>> list did a lot of those custom aggregators a few years ago, and may 
>> have thought RSS was lame and doomed because it was so ugly and 
>> fragmented.  But we all got another reminder that Worse Is Better, 
>> and somehow or other everyone starting syndicating their sites in 
>> some flavor of quasi-XML RSS,  and there are hundreds of free ways to 
>> consume all that stuff. Dave Winer is a millionaire media guru while 
>> people who know how to design proper XML formats still have to work 
>> for a living :-) 
>
> FWIW, I don't think Winer made his millions from RSS. However I don't 
> think it's a coincidence that the successful solution here came from a 
> small developer and one company. For all its flaws, RSS got a lot 
> right. Most importantly it was simple enough for people to grok after 
> a quick reading, and simple enough that they could write their own 
> tools for it.  There was one level of indirection at most in the spec, 
> and Winer's initial version worked for pretty much one web site: his. 
> Netscape had something to do with it, but they were imploding and 
> focused elsewhere so it didn't get much attention from them.
>
> Small developers don't have the option to spend person-years and 
> millions of dollars solving every variation of a problem, and 
> following the waterfall model of spec-design-code-test-deploy. They 
> have to be more agile. They have to solve problems right now with 
> limited resources or they don't meet the payroll or pay the rent. Had 
> AOL, Microsoft, Sun, CNN, the NSA, AW, and a dozen others gotten 
> together to invent something  to track changes to a number of websites 
> they could never have been as successful as RSS was.
>
> There's also an advantage to many options. RSS was not the only 
> solution to syndication available in the late 90s. Microsoft had one. 
> Slashdot had one. Probably others had one too. RSS is just the one 
> that took off.  At early stages, it is much better to have 6 different 
> solutions than 6 organizations working on one solution. This principle 
> is quite relevant to JSR-311 for example, or schema languages.
>
>> What's the real evidence that WS-* has gone off the rails, *if* we 
>> assume that the objective is to shove the common 90% of integration 
>> development down into the infrastructure and that the beauty of the 
>> technology is not a criterion of success?
>>
>
> I think the onus is on the WS-* purveyors to demonstrate that what 
> they're selling is worth the cost, not the other way around.
>
>