Re: Issue 5; GET vs GetLastTradePrice

hear, hear!

Trust boundaries/ownership boundaries are a key feature of the next big 
thing. This is a point that I tried, somewhat unsuccessfully, to make 
in the september f2f. Perhaps I tried to move too quickly to a solution?

However, to REALLY get a hold of what is going on across such 
boundaries means that one has to:

a. understand the meaning of the terms in the message being transmitted.
b. understand the task, and
c. understand the relationships involved.

Then, and only then IMO, can an automatic system make a reasoned choice 
about whether or not to allow a message to cross the corporate 
`membrane'.

Frank

On Thursday, January 2, 2003, at 09:38  AM, David Orchard wrote:

>
> Mike,
>
> Interesting POV.  I offer my limited analysis.  The web is optimized 
> for
> ad-hoc retrieval of resources, specifically around using GET.  It's the
> default method given only a URI.  Therefore people can easily post 
> (:-) them
> on billboards, send via email etc.
>
> In the web context, it makes huge sense to be able to give around 
> URLs.  And
> the default method of GET is completely required for this success.  I 
> want
> to re-state my position, which is that the web was successful because 
> of the
> combination of URIs and the default use of GET.  And when people use 
> POST on
> web sites, they typically use it interchangeably with GET.  I've 
> proven this
> point in the past.  Therefore the web architecture may be designed 
> around
> REST, but in actually it's almost 100% deployed in a simple one method
> invoke style, and this is the case that the web is brilliantly 
> optimized
> for.  Almost nobody deploys GET/PUT/POST/DELETE methods on the same 
> URI.
> 99.9% of sites treat POST/GET as interchangeable.
>
> The question from a Web services perspective, is does this same 
> optimization
> make sense?  Do we have programs that already have prebuilt "method"s, 
> or
> even a default method, and we simply have to punch in new addresses?  I
> don't think so.
>
> IMO, ad-hoc retrieval of representations doesn't make as much sense in 
> a
> machine to machine world, as compared to a hypermedia world.
>
> The architectural middle ground that I believe we are moving towards 
> is a
> model that is optimized for program creation - hence the necessity of 
> wsdl -
> and allowing for ad-hoc invocation - hence the support for GET.  The
> optimization is different, but the features are supported.  I also 
> believe
> that the default method for web services will be the POST method.
>
> One of the areas that we (Web services) still have work to do is in 
> figuring
> out how to deploy Web services across trust boundaries.  The use of tcp
> ports and port firewalls make sense when it was really hard to create 
> and
> deploy applications.  Think of how long it took to get the protocols 
> over
> the various internet ports figured out.  But now we want to scale this 
> for
> gajillions of applications while wanting the firewall admin to 
> actually do a
> reasonable job at setting up the right policy.
>
> To me, XML is the thing that breaks the previous model of dealing with
> internet level application deployment.  10 years ago, it was fairly 
> hard to
> create document formats and protocols.  XML made it orders of magnitude
> easier to create formats.  SOAP makes it an order of magnitude easier 
> to
> create .... XML based protocols.  People that focus on the use of URIs 
> and
> GET as the focus on app development, IMO tend to ignore the whole
> centralized registry of ports and description of the HTTP protocol as 
> well
> as the commensurate programming that the HTTP developers had to do.
>
> If there is any argument that would convince me that GET is better than
> GetLastTradePrice, it would be the firewall argument.  But having 
> spent a
> few times discussing the realities of deployment of the various 
> options with
> MarkB, I remain unconvinced that the firewall admin has any greater 
> insight
> or control into application of security policy under one or the other
> choice.
>
> Which makes me believe that we still have a hole in the web services
> architecture on what needs to be in soap messages and wsdl definitions 
> in
> order to allow a firewall admin to do their job better.  SOAPAction 
> was one
> attempt at this.  WS-Routing Action was another.  There are various 
> other
> approaches.  But I don't think we've taken a very systematic and 
> thorough
> approach at looking at the use case of a web service being developed 
> and
> deployed by developers and security people.
>
> Cheers,
> Dave
>
>> -----Original Message-----
>> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
>> Behalf Of Champion, Mike
>> Sent: Thursday, January 02, 2003 8:41 AM
>> To: www-ws-arch@w3.org
>> Subject: RE: Issue 5; GET vs GetLastTradePrice
>>
>>
>>
>>
>>
>>> -----Original Message-----
>>> From: Walden Mathews [mailto:waldenm@optonline.net]
>>> Sent: Thursday, January 02, 2003 10:37 AM
>>> To: Newcomer, Eric
>>> Cc: www-ws-arch@w3.org
>>> Subject: Re: Issue 5; GET vs GetLastTradePrice
>>>
>>> I'd like to get clearer on what that middle ground is.  Last
>>> summer I got involved in a project that
>>> had already decided to use XML in a "document" mode as
>>> opposed to a "RPC" mode, but the
>>> distinction was only skin deep, at least according to my
>>> analysis.
>>
>> I sometimes suspect that too.  As someone said in one of these recent
>> threads, it would be hard to distinguish an instance of one
>> from the other
>> using a protocol analyzer. The distinctions do seem more at the design
>> pattern level-- do you CONCEIVE of the message as a method
>> invocation with
>> arguments that gets directly mapped onto a procedure call of
>> some sort, or
>> do you conceive of it as a business document to be acted on by some
>> intermediate software that interprets the data and indirectly
>> invokes the
>> back-end software.
>>
>> I'm  seeing this more and more as an engineering question of
>> finding the
>> optimal degree of coupling in a particular web application
>> than as some huge
>> meta-question of competing paradigms. The tighter coupling of
>> direct mapping
>> of method invocations (synchronous or asynchronous) on one
>> system to another
>> via SOAP messages makes sense in stable, well-managed systems where
>> performance considerations are paramount; the looser coupling
>> of business
>> document exchange makes sense in more dynamic, hapharzardly
>> managed systems
>> where ease of discovery by new "customers" is more important than
>> performance for existing customers.
>>
>>
>>
>>
>>
>>
>>
>>
>

Received on Thursday, 2 January 2003 13:04:31 UTC