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

RE: Re: Why REST? (RE: WSIO- With Name)

  • To: 'Paul Prescod' <paul@p...>, xml-dev@l...
  • Subject: RE: Re: Why REST? (RE: WSIO- With Name)
  • From: "Bullard, Claude L (Len)" <clbullar@i...>
  • Date: Tue, 12 Feb 2002 15:32:59 -0600

process decomps
From: Paul Prescod [mailto:paul@p...]

>That's all the Web does. Ship descriptions (formally known as
>representations) of resources around. It does not move resources. I
>can't download Google's database by trying every URI. All I can get are
>representations of views of it.

If everyone agrees on that, then what does the REST vs WebServicesAsUDDI/WSFL/SOAP 
debate come down to:

1.  Names.  GUIDs vs URIs.
2.  Where to put the names (in the URI, in the SOAP message)
3.  HTTP has all the methods we need if we just used them 
    correctly and could accomodate complex (say rich) actions 
    if we ganged them correctly   (I don't know how this 
    can be proven.) vs we need specific API calls that enable 
    us to discover a business exists, is of a given type, can offer 
    typed services based on public or privately negotiated document 

A URI is a name and a locator.  A URI can have arguments 
appended to the end of it, so it is a hyperlink and a function call 
(which after a lot of years I've come to believe are the same thing 
but we can argue about that).  A URI is supported ubiquitously, so 
web services comes down not to a lot of new technology but to applying 
what we already have.

What am I missing here other than needing to build up a sharable set 
of arguments per process type which may be per business type which 
may be per business which may be per department which may be per 
local desktop?

When we did process decomps in the olden days we found that as 
soon as we dropped below the department level, standardization 
became not only difficult, it became counterproductive.  Almost
heisenbergian uncertainty takes over about what actually is 
going on in these processes, that is, a state might be representable, 
but isn't resolvable.  Even if REST is technically adequate, it 
trips over real time and the unreliable repeatability of certain outcomes. 
For such things, no web service or semantic web will be adequate so 
just don't use the web for those things.


"They got a name for the winners in the world.
I want a name when I lose.
They call Alabama the Crimson Tide.
Call me, Deacon Blues."

Steely Dan


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.