[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Just Can't Get No REST

satisfaction re
Bullard, Claude L (Len) wrote:
>>Business has friction because business should have a certain amount of 
>>friction (e.g. accountants and auditors). Technology that adds 
>>integration friction to the social friction is just overhead.
> Maybe.  Sometimes it is worth slowing a process down, but that 
> should be built in and not a side effect.  Do remember the Thule 
> Greenland incident in 1960.  Had the process been running in 
> machine time, North America and most of Europe and Asia would 
> still be cinders.  Humans should stay in the loop.

I agree. But as you say, it should be built-in and not a side effect of 
poor technology choices. We shouldn't use 14.4 modems to slow down stock 
traders, we should put in explicit breaks and maybe delays in the system 
whcih cannot be "gamed" merely by upgrading the modem.

>>>It may be just as doable to lie to RPC, but it isn't 
>>>as easy.
>>Why not?
> Because setting up a web service takes a certain amount of 
> savvy.

Not really. Not with the modern tools.

> ....  Almost any idiot can build a web page and plant 
> references to toss google a curve.

The people who do this seriously study it and have even built businesses 
around it. Do you think that the difference between a URI and an RPC 
call or between the ease of putting a page on IIS vs. using ASP are 
going to slow them down?

> Easy for thee.  You are not the average bear.  Obscurity is not 
> security and difficulty won't always make things less likely, 
> but likely to make things less likely.  What the article 
> showed was the ease with which one could game Google.   
> At one point, it was suggested that what Discovery 
> systems were proposed for (eg, UDDI), Google could do.  Google 
> can but the results are worth about what one pays for them.

There are a variety of reasons to dismiss Google as a discovery 
mechanism *in some situations*. But if you are comparing to UDDI then 
trust in the data is not a good reason. Anybody can send random data to 
a UDDI server and in general that data is not vetted. (see 
uddi.microsoft.com). I could register as an arms dealer for all the UDDI 
engine knows or cares.

It would take your average Perl-programming system adminstrator fifteen 
minutes to figure out how to game that system. Google is actually much 
harder because Google aggregates and rates information from so many sources.

Sure, good registries may turn out to be pay-based services rather than 
free. That has nothing to do with whether the centralized UDDI RPC model 
is the right one. IMHO, it clearly isn't. The Web Services world needs a 
trusted *search engine* and *registry*, not *repository*. Yahoo is 
actually the best analogy.

  Paul Prescod


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.