RE: Visibility

Well, I "sort of" retracted it.  I said some things that were incorrect
or based on a misunderstanding, which I greatly regret.  

However, if you are talking about visibility you are talking about
putting things into URL's that can be inspected by servers along the
way, right?  In that case, no retraction -- this is totally unacceptable
to anyone that I have contact with for business purposes.

What I did not know was that -- and I HOPE that this is really true --
HTTPS encrypts everything including the URL.  In that case, no problem
with using GET or whatever you like, as far as security goes, but then
it's not very visible either, is it?  So what's the point?  Visibility
to the servers AFTER the HTTPS is decrypted for use internal to the
companies involved in the transaction?  Somehow I don't think that's
what people are talking about, but if it is our network people are not
really very interested.

One way or the other --  If it's visible, business related information
has no place in the URL, and that MOST DEFINITELY includes the nature of
the operation or request (buy, sell, getstockquote, etc).  If it's not
visible -- well, then visibility is not an advantage, is it?  Might as
well put it in the message as far as I can see.

This whole unending debate has an Alice in Wonderland quality to me.

-----Original Message-----
From: Walden Mathews [mailto:waldenm@optonline.net] 
Sent: Saturday, March 01, 2003 9:28 PM
To: Champion, Mike; www-ws-arch@w3.org
Subject: Re: Visibility



> find persuasive.  Maybe (as Walden in particular has argued on this 
> list) one *could* build RESTful, idempotent interfaces to this 
> complex,
demanding,
> and legacy stuff, and maybe y'all will demonstrate this and convince 
> us
all.
> But, again AFAIK, such demonstrations remain hypothetical.

I'm in no position to claim that *all* complex, demanding legacy
applications can be nicely front-ended with a Web interface; I have
personal experience with exactly ONE of these transformations.  I'm
curious, though.  Can Mike or someone sketch or drop a reference to
requirements of such a system that would, in their opinion, fail to run
acceptably thus adapted?


> say about HTTP and visibility is true and desireable.  Ratchet up the 
> security/reliability requirements and put some complexity on the 
> back-end, however, and it's clear that the Web as we know it is not a 
> great platform for web sevices without the kind of help that the 
> SOAP-based specs offer. All that "visiblity" becomes a liability (as 
> Roger has helped us
understand
> from the IT perspective).

Last I'd read, Roger retracted that report, while adding that his chief
developers weren't particularly interested in the subject of visibility.
Are we all keeping up-to-date?

For the record, our entitlements web service (the one I helped design
the web front end for) was required to be reliable, and also had some
medium to stern requirements for security, since it was for sharing
among competing brokerage houses, trading rooms and institutional
investment management companies.  If any one of those was able to use
the interface to disable someone else's access to real-time pricing &
news, there would be serious business impact to say the least.

>  The SOAP framework and the numerous standards and
> proposals that work within it really do add value for the people 
> working
in
> these areas.  There are costs, of course -- XML/SOAP/WS-Security-aware

> firewalls are clearly going to be more expensive in dollars and 
> resource requirements than vanilla HTTP-aware firewalls are.  This is 
> neither a
Good
> Thing nor a Bad Thing, just one more tradeoff that Web services 
> architects are going to have to take into consideration.

If the higher price of gasoline is a Bad Thing, then why is the higher
price of web services neither?  (Maybe Roger knows? :-)

Walden

Received on Sunday, 2 March 2003 00:08:25 UTC