- From: Champion, Mike <Mike.Champion@SoftwareAG-USA.com>
- Date: Thu, 30 May 2002 17:23:49 -0400
- To: www-ws-arch@w3.org
> -----Original Message----- > From: Mark Baker [mailto:distobj@acm.org] > Sent: Thursday, May 30, 2002 4:56 PM > To: Champion, Mike > Cc: www-ws-arch@w3.org > Subject: Re: D-AR003.1 > > > BTW, I want to emphasize that I don't want to prevent you from doing > things this way, if you feel the need to do so. I just want don't > want the architecture to require/assume that it's a good idea to do > this. Thanks for the clarification. Still, "web services" are frequently touted for "behind the firewall" application integration. That (along with supply chain integration applications where a "web of trust" already exists) describes, as far as I know, the overwhelming majority of actual "web services" deployments to date. Does the WSA *really* want to suggest that this is a bad idea? I strongly agree that Mark's scenarios (where there is no trusted relationship between the parties, where coordination of interface changes is impractical, where the TCP connections are over the "internet" rather than an "intranet") are also critical to our requirements. I agree with most of what he says IF we restrict the use cases to services offered to anyone over the public Web: Either a whole new protocol stack built on top of SOAP (providing routing, cacheing, security, transactions) is developed and widely deployed ... or else RESTful web services are the only practical way to go. I don't think the economic/political/psychological climate is right for Yet Another Next Big Thing, so I'm betting on REST for web services "outside the firewall." [My personal opinion, not the corporate line!] So, I see both sets of use cases, and the requirements they imply, as essential to the WSA.
Received on Thursday, 30 May 2002 18:21:09 UTC