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

[Greg Hunt <greg@firmansyah.com>]

This is the conflict between tool-based and hand-written approaches.  We 
cannot get away from the problem of handling value transactions using 
non-transactional protocols (sometimes its really nice to have 
transaction coordination across a comms link) and that is harder when 
you have to code the tx restart/rollback yourself. The WS-* stuff is 
tool dependent because of its complexity, and MS and others will provide 
the tools and hide the horrible protocol complexity so programmers can 
get on with the business problems and stop worrying about technical 
ones.  Many developers will not even know that there is an alternative.  
The issue is not interoperability in general, the issue in the longer 
term is the ability to communicate between tools-based worlds and the 
non-tools-based world.  This has implications for schema validation and 
a whole lot of other things too.  In the tools-based universe, tool 
support will drive acceptance of a technology more than function or 
completeness will.  Complexity in the tools case is an issue for two 
groups: tool developers and people wanting to hand-craft things that 
talk to the tools world. 

I agree that the WS-* set is terribly complex and god only knows what 
edge cases some of those standards are really trying to deal with, but I 
don't think that REST is enough of the answer all of the time.  We went 
through this with distributed data transactions years ago until the 
problem (mostly) sank into the infrastructure and as an aside it is 
interesting that concern with transactional integrity seems to have 
declined as the years have gone by. 

Greg

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.
   snip...

> 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 :-) 
>    snip...
>> 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.
>
>