- From: Burdett, David <david.burdett@commerceone.com>
- Date: Thu, 20 Feb 2003 11:22:38 -0800
- To: "'Mark Baker'" <distobj@acm.org>, "Burdett, David" <david.burdett@commerceone.com>
- Cc: www-ws-arch@w3.org
- Message-ID: <C1E0143CD365A445A4417083BF6F42CC053D1769@C1plenaexm07.commerceone.com>
Mark Comments ... >>>My preference would be for a solution that is designed within the constraints of an architectural style that is suitable for use on the Internet.<<< My preference is for an architectural style that meets the needs of the people/businesses that want to use it. >>>We know that REST is such an architectural style, as it describes the architecture of a good part of the working Web (though of course there are other styles in use on the Internet).<<< I agree, that it works well for *part* of the internet. But there are other uses/audiences that have valid concerns, specifically the needs of business/ecommerce. I am not convinced that REST is the most effective architectural style for meeting their needs. However the only way to validate this is to: 1. Agree that the needs of business/ecommerce must be met 2. Identify what those needs/requirements are - this may have already been done? 3. Compare alternative architectural styles against those needs. >>>We don't know that the style implicit in variant 6 exhibit the properties required for Internet scale use (such as visibility), though I'd be more than happy to learn from you why you think it might, specifically what constraints it uses, what properties those constraints induce, and why you consider those properties to be sufficient for deployment on the Internet.<<< From an eCommerce perspective, privacy and control is more important than visibility. Remember that you are talking about a method of using the web that can potentially have legal and monetary impact on a business. Also do you have a fuller description of what is required for "Internet Scale Use"? If you do, we can then compare those requirements against the requirements of eCommerce to identify the differences. This could also usefully feed in to debate over what architectural style is the most appropriate. Bottom line, I think there two different sets of requirements, one where the Internet is viewed as a massive information resource where a "REST" style approach is very appropriate and another where the Internet is viewed as low-cost ubiquitous medium for transporting messages between businesses in a reliable, secure and private way. David -----Original Message----- From: Mark Baker [mailto:distobj@acm.org] Sent: Thursday, February 20, 2003 11:08 AM To: Burdett, David Cc: www-ws-arch@w3.org Subject: Re: Representing Actions (was RE: AR023.7.1 (was Re: Dead trout On Wed, Feb 19, 2003 at 03:07:05PM -0800, Burdett, David wrote: > MY PERSONAL PREFERENCES > > My personal preference is for variant 6 (sorry Mark it's not URI's!) and > here's why ... I understand what you're saying, and you do make many valid points (though most have been addressed for some time, such as what to do about disclosing information in URIs). But respectfully, you're not looking at this from an architectural POV, which I believe is the only way to propertly evaluate these solutions. My preference would be for a solution that is designed within the constraints of an architectural style that is suitable for use on the Internet. We know that REST is such an architectural style, as it describes the architecture of a good part of the working Web (though of course there are other styles in use on the Internet). We don't know that the style implicit in variant 6 exhibit the properties required for Internet scale use (such as visibility), though I'd be more than happy to learn from you why you think it might, specifically what constraints it uses, what properties those constraints induce, and why you consider those properties to be sufficient for deployment on the Internet. Thanks. MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Web architecture consulting, technical reports, evaluation & analysis
Received on Thursday, 20 February 2003 14:23:11 UTC